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

From: "OOGHE Sven" <[email-masked]>
Date: Mon, 5 Jan 2009 11:30:04 +0100

All,

With a bit of delay, here are my last call comments on the famework.

* Section 4.5

Change the requirements as follows:

"- The ANCP MUST support an adjacency protocol in order to automatically
synchronize its operational state between its peers, to agree on which
version of the protocol to use, to discover the identity of its peers,
and detect when they change.
- The ANCP MUST include a mechanism to automatically detect adjacency
loss.
- A loss of the Access Node Control Adjacency MUST NOT affect subscriber
connectivity.
- If the Access Node Control Adjacency is lost, it MUST result in
deterministic behavior on all network elements involved.
- The ANCP MUST support a mechanism to synchronize access port
configuration and status information between ANCP peers as part of
establishing or recovering the Access Node Control Adjacency."

* Section 4.7.1

Change
   o  Each AN partition must have a separate Access Node Control
      Adjacency to a NAS and should be able to enforce access control on
      the controllers to only designated partitions being bound to one
      controller.
To
"- Each AN partition must have a separate Access Node Control Adjacency
to a NAS
- Each AN partition must be able to enforce access of the controllers to
their designated partitions."
 
Remove the following requirements:
   o  For security purposes, the Access Node Control Protocol messages
      sent over the channel MUST NOT be sent towards the customer
      premises.

   o  The Access Node must not support the capability to configure
      sending Access Node Control Protocol messages towards the customer
      premises.

Add the following requirement to Section 7:

"- The Access Node MUST NOT allow the sending of Access Node Control
Messages towards the customer premises."

* Section 4.7.2

Change
   o  If ATM interfaces are used, VPI as well as VCI value must be
      configurable in the full range.

   o  If Ethernet interfaces are used, C-Tag as well as S-Tag must be
      configurable in the full range.

To
"- If ATM interfaces are used then any VPI and VCI value must be able to
be used for the purpose of supporting the Access Node Control Channel.
- If Ethernet interfaces are used then any C-VID and S-VID must be able
to be used for the purpose of supporting the Access Node Control
Channel."

* Section 4.8.1

Change
   o  The NAS should support a reduction or disabling of such shaping
      limit, derived from Policy/Radius per-subscriber authorization
      data.

To
"- The NAS should support reducing or disabling the shaping limit used
in the Hierarchical Scheduling process, according to per-subscriber
authorization data retrieved from a AAA or Policy Server."

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:

      "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: "Shridhar Rao (shrirao)" <[email-masked]>
Date: Sun, 11 Jan 2009 20:52:14 +0530

Hi,
Based on section 5.2 of ANCP protocol draft, both server and client have
to send keep-alives. To help reduce the unnecessary message exchange
between server and client and for a better utilization of bandwidth we
are proposing that only client send the keep-alives and server just ack
it.  

The client side can assume that server is dead when it doesn't receive
acknowledgements for 3 successive keep-alives and similarly server can
assume client is not alive when it doesn't get 3 consecutive keep-alives
on time. The code changes required for this from the current scheme of
both ends sending keep-alives is very minimal (runs to few lines and is
easy to implement). But if someone feels that we need to still retain
the older scheme, then we can make this negotiable by introducing one
more capability.

regards,
-shridhar-

---

From: "Shridhar Rao (shrirao)" <[email-masked]>
Date: Sun, 11 Jan 2009 21:04:00 +0530

Hi all,

regards,
-shridhar-

---

From: "Shridhar Rao (shrirao)" <[email-masked]>
Date: Thu, 19 Feb 2009 11:58:14 +0530

Hi all,
To make this proposal backwards compatible with older client/server
implementations, I propose to add a new capability for exchanging the
keep-alives. 

Capability Type : Keep-alive-exchange-scheme = 0x06 

          Length (in bytes) : 4

          Capability Data :  
	
	0x01 : Only client sends Keep-alives
	0x02 : No Keep alives are to be exchanged

If this capability is not negotiated, then the default option is both
ends send keep alives. Any end may send the above capability in it's
adjacency message and if it is not acknowledged, then implementation
that sent the capability will fall back to the default option. If
stations are unable to agree on this capability, they will again fall
back to the default method.

If this option is negotiated as "0x02 => No Keep alives are to be
exchanged", then there is no need for any end to send Keep-alives and
each station is free to choose any method to determine if the other end
is down. One possible option is to use idle timer. 

I also propose to change the timer granularity to seconds instead of 100
msec. To help scale even better, I propose to have a Hello-multiplier
TLV. The TLV can be 8 bit integer that need not be negotiated but any
end sends it to other end along with it's Hello interval time.

We have seen very significant problems in maintaining ANCP adjacencies
under high bandwidth conditions because Hellos are not delivered on
time. We have also used the above schemes and discovered that it
eliminates this problem.

Thanks,
-regards-

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Shridhar Rao (shrirao)
Sent: Sunday, January 11, 2009 9:04 PM
To: [email-masked]
Subject: [ANCP] Proposing that keep-alives be sent only from client

Hi all,

regards,
-shridhar-

---

From: Sanjay Wadhwa <[email-masked]>
Date: Thu, 19 Feb 2009 21:56:15 -0500

Hi Shridhar
  I don't quite see how the suggestion below lessens message exchange or
improves utilization. It requires two messages each keep-alive interval
(keep-alive and ACK). With what we have today in the draft, both AN &
NAS send their own keep-alive message. Note that this is not an echo
function i.e. no ACK is required. It is a single message in each
direction generated asynchronously (i.e. still two messages each
keep-alive cycle). The interval on either end can be configurable and
the draft doesn't preclude asymmetric values. Each side retains controls
of how long it takes for the other side to declare it dead on not seeing
any activity. In your proposal the NAS has no control on this. 
If indeed an echo behavior is desired, I would argue it should be
bi-directional and independent in each direction, but that doubles the
number of messages.

Regards
-Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Shridhar Rao (shrirao)
Sent: Sunday, January 11, 2009 10:34 AM
To: [email-masked]
Subject: [ANCP] Proposing that keep-alives be sent only from client

Hi all,

regards,
-shridhar-