Subject: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt

From: "BOCCI Matthew" <[email-masked]>
Date: Mon, 8 Dec 2008 13:41:55 +0100

> This email is to start a two week working group last call for
> draft-ietf-ancp-framework-07.txt
> Please review and provide comments to the list by Monday 22nd
> December.
> 
> The following have also kindly offered to review the document:
> - Roberta Maglione
> - Alan Kavanagh
> - John Zhao
> - Tom Taylor
> - Sven Ooghe
> - Francois LeFaucher
> 
> 
> Best regards
> 
> Matthew
> 
> 
> 
> 
_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: Maglione Roberta <[email-masked]>
Date: Fri, 12 Dec 2008 10:25:44 +0100

Hello,
         I did a comparison between draft draft-ietf-ancp-framework-07.txt and latest version of BBF WT-147 in order to identify the differences between the two documents introduced with recent changes in WT-147.
Please find my comments for draft draft-ietf-ancp-framework-07.txt below.
Thanks,
Best Regards,
Roberta

Section 1.2 page 5
I suggest the following changes in order to reflect BBF WT-147 definitions:

      "Net Data Rate: defined by ITU-T G.993.2, section 3.39, i.e. the
      portion of the total data rate that can be used to transmit user
      information (e.g.  ATM cells or Ethernet frames).  It excludes
      overhead that pertains to the physical transmission mechanism
      (e.g. trellis coding in case of DSL)."

   Add:
     "It includes TPS-TC (Transport Protocol Specific - Transmission Convergence)
      encapsulation; this is zero for ATM encapsulation, and non-zero for 64/65
     encapsulation. "

    Replace:
    Line Rate: the total data rate including overhead.

   By:

  Line Rate: defined by ITU-T G.993.2. It contains the complete overhead
  including RS and trellis coding.

Section 2.1 Page 8.
To be consistent with latest changes in BBF WT-147 I propose to split reporting and enforcement functions in two separate bullets

Section 2.2.2 Page 9 line 466: for each technology there is a reference to RFC I would suggest adding:
 IPoE defined in RFC 894

Section 2.4 page 12 line 630:
Replace:
"Also, there is a possibility to integrate this with a Policy Server
   (e.g.  RADIUS server) that keeps track of the different Subscriber
   related parameters."

By:
"Also, there is a possibility to integrate this with a Policy Server or an AAA/RADIUS server that keeps track of the different Subscriber related parameters."

Section 3.2 page 15 line 818:
Replace
"the NAS could query a Policy Server (e.g.
   RADIUS server) to retrieve Access Loop configuration data."

by
"the NAS could query a Policy Server or an AAA/RADIUS server to retrieve Access Loop configuration data."

Section 3.4.2 Page 22 line 1209:
Replace:
"perform CAC for unicast and multicast
      flows and perform video bandwidth accounting."
By
"perform CAC for unicast and multicast
      flows and perform video bandwidth management"

Section 3.4.3 Page 26 line 1424
I would suggest rephrasing this sentence as ANCP Bulk message has been removed from the protocol draft.

"In case of very fast channel changes, the amount of Information
   Report messages to be sent to the NAS could become high.  In order to
   reduce the number of messages, the AN may bundle several Information
   Reports together in a single "bulk transaction"."

Section 4.1
Page 28  line 1555
To be consistent with recent changes in BBF WT-147 replace:
" In large scale networks, Access Nodes are provisioned but not
      always fully populated.  Therefore the ANCP MUST be scalable
      enough to allow a given NAS to control thousands of Access Nodes
      (e.g. typically 5000 to 10000)."

By
" The protocol must be scalable enough to allow a given NAS to control at least
5000 Access Nodes."

The following requirement has been removed from WT-147:
" The ANCP SHOULD minimize sources of configuration mismatch, help
      automation of the overall operation of the systems involved
      (Access Nodes and NAS) and be easy to troubleshoot.

Page 29 line 1578:
"The ANCP SHOULD support a means to handle sending/receiving a
      large burst of messages efficiently (e.g. using "message
      bundling")."

I suggest removing "(e.g. using "message bundling")."

Do we really need three different sections (4.3, 4.7.9 and 4.8.9) for security (plus section 7 "Security considerations") all of them pointing to the draft draft-ietf-ancp-security-threats? Would not be possible to remove sections  4.3, 4.7.9 and 4.8.9 as the text contained in these sections is already in section 7?

Section 4.8.1
Line 2045:
As per BBF comments replace:
" The NAS must only communicate to authorized Access Node Control
      peers."
By:
" The NAS must establish ANCP Adjacencies only with authorized ANCP peers. "

Section 5.
" This document does not consider the specific details of the
   communication with a Policy Server (e.g. using RADIUS)."

I would remove "(e.g. using RADIUS)."

Missing References to the following RFCs mentioned in the text:
RFC2684, RFC2516, RFC2225, RFC 894

- editorial: replace everywhere in the  document "DSL Forum" with "Broadband Forum"

Thanks,
Regards,
Roberta

-----------------------------------------------------
Roberta Maglione  - CCIE #18425
Telecom Italia
Broadband Network Services Innovation
-----------------------------------------------------

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of BOCCI Matthew
Sent: Monday, December 08, 2008 1:42 PM
To: [email-masked]
Subject: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt

This email is to start a two week working group last call for draft-ietf-ancp-framework-07.txt
Please review and provide comments to the list by Monday 22nd December.
The following have also kindly offered to review the document:
- Roberta Maglione
- Alan Kavanagh
- John Zhao
- Tom Taylor
- Sven Ooghe
- Francois LeFaucher

Best regards
Matthew

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

Rispetta l'ambiente. Non stampare questa mail se non e' necessario.

www.avoicomunicare.it      Ogni giorno, il tuo luogo di dialogo.
_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: "OOGHE Sven" <[email-masked]>
Date: Fri, 12 Dec 2008 15:26:17 +0100

Hi Roberta,

Many thanks for doing the full review. I still need to do this as well -
for now I am ok with all of your suggested changes.

I'm ok to have one security section and remove the "dummy" sections that
all point to section 7.

Regards,
Sven

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]] 
Sent: vrijdag 12 december 2008 10:26
To: OOGHE Sven; [email-masked]
Cc: BOCCI Matthew
Subject: RE: WG last call for draft-ietf-ancp-framework-07.txt

Hello,
         I did a comparison between draft
draft-ietf-ancp-framework-07.txt and latest version of BBF WT-147 in
order to identify the differences between the two documents introduced
with recent changes in WT-147.
Please find my comments for draft draft-ietf-ancp-framework-07.txt
below.
Thanks,
Best Regards,
Roberta

Section 1.2 page 5
I suggest the following changes in order to reflect BBF WT-147
definitions:

   Add:
     "It includes TPS-TC (Transport Protocol Specific - Transmission
Convergence)
      encapsulation; this is zero for ATM encapsulation, and non-zero
for 64/65
     encapsulation. "

    Replace:

   By:

Section 2.1 Page 8.
To be consistent with latest changes in BBF WT-147 I propose to split
reporting and enforcement functions in two separate bullets

Section 2.2.2 Page 9 line 466: for each technology there is a reference
to RFC I would suggest adding:
 IPoE defined in RFC 894

By:
"Also, there is a possibility to integrate this with a Policy Server or
an AAA/RADIUS server that keeps track of the different Subscriber
related parameters."

by
"the NAS could query a Policy Server or an AAA/RADIUS server to retrieve
Access Loop configuration data."

Section 3.4.3 Page 26 line 1424
I would suggest rephrasing this sentence as ANCP Bulk message has been
removed from the protocol draft.

Section 4.1
Page 28  line 1555

By
" The protocol must be scalable enough to allow a given NAS to control
at least 5000 Access Nodes."

Page 29 line 1578:

Do we really need three different sections (4.3, 4.7.9 and 4.8.9) for
security (plus section 7 "Security considerations") all of them pointing
to the draft draft-ietf-ancp-security-threats? Would not be possible to
remove sections  4.3, 4.7.9 and 4.8.9 as the text contained in these
sections is already in section 7?

Section 4.8.1
Line 2045:
As per BBF comments replace:
" The NAS must only communicate to authorized Access Node Control
      peers."
By:
" The NAS must establish ANCP Adjacencies only with authorized ANCP
peers. "

Section 5.

- editorial: replace everywhere in the  document "DSL Forum" with
"Broadband Forum"

Thanks,
Regards,
Roberta

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of
BOCCI Matthew
Sent: Monday, December 08, 2008 1:42 PM
To: [email-masked]
Subject: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt

This email is to start a two week working group last call for
draft-ietf-ancp-framework-07.txt Please review and provide comments to
the list by Monday 22nd December.
The following have also kindly offered to review the document:
- Roberta Maglione
- Alan Kavanagh
- John Zhao
- Tom Taylor
- Sven Ooghe
- Francois LeFaucher

Best regards
Matthew

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione
derivante dalla conoscenza di queste informazioni sono rigorosamente
vietate. Qualora abbiate ricevuto questo documento per errore siete
cortesemente pregati di darne immediata comunicazione al mittente e di
provvedere alla sua distruzione, Grazie.

---

From: "Reith, Lothar" <[email-masked]>
Date: Tue, 16 Dec 2008 09:00:34 +0100

Hi Roberta and Sven,

I would like to suggest a minor change to Roberta's proposal:

Roberta proposed:

by

however, I would suggest to Replace the word "or" by the word "such as" 

by
"the NAS could query a Policy Server such as an AAA/RADIUS server to retrieve Access Loop configuration data."

There are many reasons for this, which I will be happy to explain if need be.

Best Regards, Lothar

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von OOGHE Sven
Gesendet: Freitag, 12. Dezember 2008 15:26
An: Maglione Roberta; [email-masked]
Betreff: Re: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt

Hi Roberta,

Many thanks for doing the full review. I still need to do this as well - for now I am ok with all of your suggested changes.

I'm ok to have one security section and remove the "dummy" sections that all point to section 7.

Regards,
Sven

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]]
Sent: vrijdag 12 december 2008 10:26
To: OOGHE Sven; [email-masked]
Cc: BOCCI Matthew
Subject: RE: WG last call for draft-ietf-ancp-framework-07.txt

Hello,

Section 1.2 page 5

   Add:

    Replace:

   By:

Section 2.1 Page 8.

By:

by

Section 4.1
Page 28  line 1555

By
" The protocol must be scalable enough to allow a given NAS to control at least 5000 Access Nodes."

Page 29 line 1578:

Section 4.8.1
Line 2045:

Section 5.

Thanks,
Regards,
Roberta

This email is to start a two week working group last call for draft-ietf-ancp-framework-07.txt Please review and provide comments to the list by Monday 22nd December.
The following have also kindly offered to review the document:
- Roberta Maglione
- Alan Kavanagh
- John Zhao
- Tom Taylor
- Sven Ooghe
- Francois LeFaucher

Best regards
Matthew

---

From: "OOGHE Sven" <[email-masked]>
Date: Wed, 17 Dec 2008 17:31:56 +0100

Hi Fortune,

I'm generally ok with making the changes you propose in both of your emails. It allows capturing the different architectures that were mentioned in the framework.

Regards,
Sven

-----Original Message-----
From: Fortune HUANG [mailto:[email-masked]] 
Sent: dinsdag 16 december 2008 8:11
To: OOGHE Sven; 'Maglione Roberta'; [email-masked]
Subject: 答复: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt

Hi all,

Another comment on the following paragraph in session 3.4.2:

   o  The above model could be enhanced with the notion of "Delegation
      of Authorization".  In such a model, the NAS delegates authority
      to the Access Node to perform multicast Admission Control on the
      Access Loop.  This is sometimes referred to as "Bandwidth
      Delegation", referring to the portion of the total Access Loop
      bandwidth which can be used by the Access Node for multicast
      Admission Control.  In this model, the NAS (possibly with
      interactions with a Policy Server) manages the total access line
      bandwidth, performs unicast admission control and uses ANCP to
      authorize the Access Node to perform multicast Admission Control
      within the bounds of the "delegated bandwidth".  Upon receiving a
      join to a multicast flow which matches an entry in the White or
      Grey List, the AN performs the necessary bandwidth admission
      control check for the new multicast flow, before starting the
      multicast flow replication.  At this point, there is typically no
      need for the Access Node to communicate with the NAS.  The ANCP
      requirements to support this approach are also specified in this
      document. 

Comment: There should be another scenaro where the Policy Server (besides the NAS) manages the total bandwidth and delegates a portion of the bandwidth to the AN. I would propose to change the paragraph like the
following:
   o  The above model could be enhanced with the notion of "Delegation
      of Authorization".  In such a model, the NAS or the Policy Server delegates authority
      to the Access Node to perform multicast Admission Control on the
      Access Loop.  This is sometimes referred to as "Bandwidth
      Delegation", referring to the portion of the total Access Loop
      bandwidth which can be used by the Access Node for multicast
      Admission Control.  In this model, the NAS or the Policy Server manages the total access line
      bandwidth, performs unicast admission control and uses ANCP to
      authorize the Access Node to perform multicast Admission Control
      within the bounds of the "delegated bandwidth".  Upon receiving a
      join to a multicast flow which matches an entry in the White or
      Grey List, the AN performs the necessary bandwidth admission
      control check for the new multicast flow, before starting the
      multicast flow replication.  At this point, there is typically no
      need for the Access Node to communicate with the NAS or the Policy Server via the NAS.  The ANCP
      requirements to support this approach are also specified in this
      document. 

Best Regards,
Fortune

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 OOGHE Sven
发送时间: 2008年12月12日 22:26
收件人: Maglione Roberta; [email-masked]
主题: Re: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt

Hi Roberta,

Regards,
Sven

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]]
Sent: vrijdag 12 december 2008 10:26
To: OOGHE Sven; [email-masked]
Cc: BOCCI Matthew
Subject: RE: WG last call for draft-ietf-ancp-framework-07.txt

Hello,

Section 1.2 page 5

   Add:
     "It includes TPS-TC (Transport Protocol Specific - Transmission
Convergence)
      encapsulation; this is zero for ATM encapsulation, and non-zero for
64/65
     encapsulation. "

    Replace:

   By:

Section 2.1 Page 8.

By:

by

Section 4.1
Page 28  line 1555

By

Page 29 line 1578:

Section 4.8.1
Line 2045:

Section 5.

Thanks,
Regards,
Roberta

Best regards
Matthew

---

From: "OOGHE Sven" <[email-masked]>
Date: Wed, 17 Dec 2008 17:39:40 +0100

I Lothar,

I think Roberta's rationale was to align between the ANCP framework and Broadband Forum WT-147. In WT-147, we consistently made use of "AAA or Policy Server" terminology. 

So, while I agree that a AAA server can be regarded as a kind of Policy Server, I would favor Roberta's proposal.

Regards,
Sven

-----Original Message-----
From: Reith, Lothar [mailto:[email-masked]] 
Sent: dinsdag 16 december 2008 9:01
To: OOGHE Sven; Maglione Roberta; [email-masked]
Subject: AW: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt

Hi Roberta and Sven,

Roberta proposed:

by

by

Best Regards, Lothar

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von OOGHE Sven
Gesendet: Freitag, 12. Dezember 2008 15:26
An: Maglione Roberta; [email-masked]
Betreff: Re: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt

Hi Roberta,

Regards,
Sven

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]]
Sent: vrijdag 12 december 2008 10:26
To: OOGHE Sven; [email-masked]
Cc: BOCCI Matthew
Subject: RE: WG last call for draft-ietf-ancp-framework-07.txt

Hello,

Section 1.2 page 5

   Add:

    Replace:

   By:

Section 2.1 Page 8.

By:

by

Section 4.1
Page 28  line 1555

By

Page 29 line 1578:

Section 4.8.1
Line 2045:

Section 5.

Thanks,
Regards,
Roberta

Best regards
Matthew

---

From: "Reith, Lothar" <[email-masked]>
Date: Fri, 19 Dec 2008 18:46:29 +0100

Hi Sven,

from an architecture perspective, I think the ANCP framework should not mandate things outside of its scope.

ANCP is a protocol between AN and NAS.

ANCP Framework should not mandate a northbound protocol of the NAS, or a northbound communication partner of the NAS from where the NAS has received the authority to perform the delegation of authority downwards towards the AN.

WT-147 is another story. There it is fully okay to say "AAA or Policy Server" which is in my mind is intentionally vague enough to allow implementing whatever protocol you want. 

We should avoid having to update the ANCP framework, just because someone wants to use some other protocol on the northbound interface of the NAS.

 I agree with you, that Roberta's proposal should be changed to "AAA or Policy Server" to align it with WT-147 (currently it refers to RADIUS - a protocol -  not to AAA - a collection of functions)

I think the ANCP Framework should not care about the northbound protocol of the NAS - it could be anything - as long as it is fit for the purpose of implementing a delegation of authority.

The important thing is only, that the NAS is legitimately performing the delegation of authority, which implies, that it has received a delegation of authority itself (originated from a principal according to principal-agent theory). 

Best Regards

Lothar 

-----Ursprüngliche Nachricht-----
Von: OOGHE Sven [mailto:[email-masked]] 
Gesendet: Mittwoch, 17. Dezember 2008 17:40
An: Reith, Lothar; Maglione Roberta; [email-masked]
Betreff: RE: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt

I Lothar,

Regards,
Sven

-----Original Message-----
From: Reith, Lothar [mailto:[email-masked]]
Sent: dinsdag 16 december 2008 9:01
To: OOGHE Sven; Maglione Roberta; [email-masked]
Subject: AW: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt

Hi Roberta and Sven,

Roberta proposed:

by

by

Best Regards, Lothar

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von OOGHE Sven
Gesendet: Freitag, 12. Dezember 2008 15:26
An: Maglione Roberta; [email-masked]
Betreff: Re: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt

Hi Roberta,

Regards,
Sven

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]]
Sent: vrijdag 12 december 2008 10:26
To: OOGHE Sven; [email-masked]
Cc: BOCCI Matthew
Subject: RE: WG last call for draft-ietf-ancp-framework-07.txt

Hello,

Section 1.2 page 5

   Add:

    Replace:

   By:

Section 2.1 Page 8.

By:

by

Section 4.1
Page 28  line 1555

By

Page 29 line 1578:

Section 4.8.1
Line 2045:

Section 5.

Thanks,
Regards,
Roberta

Best regards
Matthew

---

From: Maglione Roberta <[email-masked]>
Date: Mon, 22 Dec 2008 09:56:44 +0100

Hi Lothar,
    For some reasons I didn't receive your previous email, that's why I didn't reply earlier.

I agree with you that ANCP is a protocol between AN and NAS, thus the ANCP framework should not mandate things outside of its scope.
The rational behind my comment was that the RADIUS can be seen as one example of Policy Server; I made a similar comments first for WT-147 because in many places  WT-147 mentioned only "Policy Server" and not the Radius Server, but I believe your text is more precise than mine, thus I support your proposal:

Thanks,
Regards,
Roberta

-----Original Message-----
From: Reith, Lothar [mailto:[email-masked]]
Sent: Friday, December 19, 2008 6:46 PM
To: OOGHE Sven; Maglione Roberta; [email-masked]
Subject: AW: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt

Hi Sven,

Best Regards

Lothar

-----Ursprüngliche Nachricht-----
Von: OOGHE Sven [mailto:[email-masked]]
Gesendet: Mittwoch, 17. Dezember 2008 17:40
An: Reith, Lothar; Maglione Roberta; [email-masked]
Betreff: RE: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt

I Lothar,

Regards,
Sven

-----Original Message-----
From: Reith, Lothar [mailto:[email-masked]]
Sent: dinsdag 16 december 2008 9:01
To: OOGHE Sven; Maglione Roberta; [email-masked]
Subject: AW: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt

Hi Roberta and Sven,

Roberta proposed:

by

by

Best Regards, Lothar

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von OOGHE Sven
Gesendet: Freitag, 12. Dezember 2008 15:26
An: Maglione Roberta; [email-masked]
Betreff: Re: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt

Hi Roberta,

Regards,
Sven

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]]
Sent: vrijdag 12 december 2008 10:26
To: OOGHE Sven; [email-masked]
Cc: BOCCI Matthew
Subject: RE: WG last call for draft-ietf-ancp-framework-07.txt

Hello,

Section 1.2 page 5

   Add:

    Replace:

   By:

Section 2.1 Page 8.

By:

by

Section 4.1
Page 28  line 1555

By

Page 29 line 1578:

Section 4.8.1
Line 2045:

Section 5.

Thanks,
Regards,
Roberta

Best regards
Matthew