Subject: Re: [ANCP] TSV review of draft-ietf-ancp-framework-10.txt

From: "OOGHE Sven" <[email-masked]>
Date: Mon, 13 Jul 2009 15:52:54 +0200

Scott

Thanks for reviewing. See inline.

-----Original Message-----
From: Scott O. Bradner [mailto:[email-masked]] 
Sent: maandag 29 juni 2009 15:36
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; OOGHE Sven; [email-masked]
Subject: TSV review of draft-ietf-ancp-framework-10.txt

TSV-dir review of draft-ietf-ancp-framework-10.txt

I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. The authors should consider
this review together with any other last-call comments they receive.

The primary transport-related issue I see with the document is its
some naive assumption that simple prioritization will mean that the
control protocol will not experience congestion.  (See, for example
section 2.3) I would suggest that the document say that use of a IETF
approved congestion aware reliable transport protocol (e.g., TCP or
SCTP) be required for the control protocol wherever the control
protocol is transported on IP.  (Section 4.5) 

<Sven> The intent of the wording in section 2.3 was to prioritize the
ANCP traffic over other sources of traffic. I agree that this does not
by itself avoid packet loss, but it should reduce the likelihood of
dropping packets in a number of cases. I propose to reword the text to
reflect this, e.g.:

"These ATM PVCs would then be given a high priority so that at times of
network congestion, loss of the ATM cells carrying the Access Node
Control Protocol is avoided or minimized."

The abstract says that the purpose of the document is to define a
framework for an Access Node Control Mechanism between a Network
Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line
Access Multiplexer (DSLAM)).

But the document is more than a framework document.   As indicated by
the title, the document also includes a set of requirements for an
Access Node Control Mechanism. The document also includes a set of
functional requirements for devices involved in such a system.  It
seems to me that the document is trying to do too much.  

*** <Sven> I will update the abstract to better reflect the purpose of
the document.

I find that the framework presented in this document to be complex
and, too often, vague.  I also find many of the requirements to be
incomplete.

a few examples - this is not an exhaustive list

I note that there is a mixture of "MUST" and "must" - that could be
confusing - since this is supposed to be  framework & requirements
documents it may be reasonable to not use RFC 2119 termonology

<Sven> This was also noted by Ralph Droms. I will clarify in an updated
version. The main purpose was to only use capitalized words for
protocol-releated requirements. Nodal requirements are written in the
document as guidelines but not as absolute design requirements.
Therefore RFC 2119 was not intended to applly to the nodal requirements.

section 4.1 - 

"The ANCP MUST address all use cases described in this document"  -
there are many use cases in the document -  it seems to me that
requiring support for all use cases is not needed for interoperability
and limits a vendor's ability to design a product for a specific need.
(See RFC 2119 section 6)

<Sven> 

"The ANCP MUST be flexible enough to accommodate the various
technologies that can be used in an access network and in the Access
Node." if this means Ethernet & ATM say so - if it means more - say so
.

<Sven>

"The Access Node Control interactions MUST be reliable (using either a
reliable transport protocol (e.g.  TCP) for the Access Node Control
Protocol messages, or by designing ANCP to be reliable)."  - see
above, I do not think that the time it would take to make the ANCP a
reliable (and congestion responsive) protocol is nearly worth the
effort.

<Sven>

"The ANCP MUST allow fast-paced transactions, in order to provide real
time transactions between a NAS and a fully populated Access Node." -
without a definition of "fast-paced" this is an impossible requirement
to meet

<Sven>

"The ANCP SHOULD support a means to handle sending/receiving a large
burst of messages efficiently." - see previous comment

<Sven>

section 4.2
"In case of Admission Control without AN Bandwidth Delegation, the
ANCP must allow the NAS to reply to a query from the AN indicating
whether or not a multicast flow may be replicated to a particular
Access Port." - is this saying that it has permission or that this
just could happen?

<Sven>

"In case of Admission Control with AN Bandwidth Delegation, the ANCP
must allow the NAS to delegate a certain amount of bandwidth to the AN
for a given Access Port for multicast services only." - "delegate " or
"dedicate"?

<Sven>
"In case of Admission Control with AN Bandwidth Delegation, the ANCP
must allow the AN to autonomous release redundant multicast bandwidth
on a given Access Port." - meaning that the protocol must include a
way for the AN to say that it did this? - otherwise not sure how the
requirement applies to the control protocol. - e.g. sections 4.6 and
4.7 are mixtures of protocol requirements and device requirements

section 4.3 
"The ANCP MUST be simple and lightweight enough to allow an
implementation on Access Nodes with limited control plane resources
(e.g.  CPU and memory)." - see previous two comments

section 4.4 - Access Node Control Adjacency Requirements

please be specific as to what this section is talking about - DSLAMs
figuring out that ANs exist? adjacent DSLAMs? adjacent control
systems?   in same provider or different providers?

section 4.6.1 - I did not understand the 1st paragraph in section
4.6.1

section 4.6.2 - 

"The Access Node must process control transactions in real-time." -
what does this mean?  a specific data rate? a specific response
latency?

"The Access Node should mark Access Node Control Protocol messages
with a high priority (e.g.  VBR-rt for ATM cells, p-bit 6 or 7 for
Ethernet packets) in order for the packets not to be dropped in case
of congestion."  - see 1st comment - this is a naive assumption

section 4.6.5 
2nd pp - sentence is not quite English and needs references for PPPoE
and DHCP messages

section 4.7.1

"The NAS must support learning of access loop attributes (e.g. net
data rate), from its peer Access Node partitions via the Access Node
Control Mechanism." - this is one way to phrase this but it seems to
me that "learning" is not the right concept - it may be better to say
that the access loop attributes used by the NAS are configured by the
ANCP - this applies in a number of other cases

"The NAS must correlate Access Node Control information with the
RADIUS authorization process and related subscriber data." - I have no
idea what this means

"The NAS should support shaping traffic directed towards a particular
access loop to include layer-1 and layer-2 encapsulation overhead
information received for a specific access loop from the AN via the
Access Node Control Mechanism." - no do I understand what this means

there are many other requirements in this document that I find to be
vague or incomplete - the above are just some examples

Scott

---

From: "OOGHE Sven" <[email-masked]>
Date: Tue, 14 Jul 2009 08:22:07 +0200

Scott

Sorry, hit the send button too quickly.

-----Original Message-----
From: Scott O. Bradner [mailto:[email-masked]] 
Sent: maandag 29 juni 2009 15:36
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];

<Sven> The intent of the wording in section 2.3 was to prioritize the
ANCP traffic over other sources of traffic. I agree that this does not
by itself avoid packet loss, but it should reduce the likelihood of
dropping packets. I propose to reword the text to reflect this, e.g.:

<Sven> I will update the abstract to better reflect the purpose of the
document.

<Sven> This was also noted by Ralph Droms. I will clarify this in an
updated version. The intent is to only use capitalized words for
protocol-releated requirements. Nodal requirements are written in the
document as guidelines but not as absolute design requirements.
Therefore RFC 2119 does not to apply to the nodal requirements.

section 4.1 - 

<Sven> This is a protocol requirement, not a nodal requirement. It is
intended to ensure that the protocol design done by the ANCP WG covers
all the use cases defined in the ANCP framework document. It is NOT
intended as a nodal requirement.

<Sven> I will edit to clarify that it refers to ATM and Ethernet. 

<Sven> The requiement is written in such a way that it may be TCP based.
The framework document doesn't want to take a stance on what approach
needs to be selected; that's up to the ANCP protocol team to decide.

<Sven> Correct. I will solicit feedback on the ANCP exploder and ask if
this should be dropped.

<Sven> See above.

section 4.2

<Sven> It refers to having permission to replicate. I will reword to
clarify.

<Sven> Delegate.

<Sven> This is indeed a protocol requirement, allowing the Access Node
to inform the NAS that a certain portion of bandwdith has been freed up
on an Access Port. I will reword/clarify.

section 4.3 

<Sven> I will solicit feedback on the list.

<Sven> The "Access Node Control Adjacency" is defined in the Definitions
section. I'll add a reference.

<Sven> Proposed rewording:

"The Access Node Control Mechanism is defined to operate between an
Access Node (AN) and a NAS. In some cases, one AN can be connected to
more than one physical NAS devices (e.g. in case different wholesale
service providers have different NAS devices). In such a model, the
physical AN needs to be split in virtual ANs, each having its own Access
Node Control reporting and/or enforcement function."

section 4.6.2 - 

<Sven> The latter. I will edit the requirement to clarify ("i.e. with a
specific response latency"). Admittedly, this is again a vague
requirement, so I will bring it to the list.

<Sven> I will reword to: "The Access Node should mark Access Node
Control Protocol messages with a high priority (e.g. VBR-rt for ATM
cells, p-bit 6 or 7 for Ethernet packets) in order to avoid or reduce
the likelihood of dropping packets in case of network congestion. "

section 4.6.5 

<Sven> Proposed rewording: "In a Broadband Forum TR-101 network
arcitecture, an Access Circuit Identifier (ACI), identifying an AN and
Access Port, is added to DHCP and PPPoE messages. The NAS must use the
same ACI format in ANCP messages in order to allow the NAS to correlate
this information with the information present in DHCP and PPPoE
messages."
 
section 4.7.1

<Sven> How about "The NAS must support *obtaining* access loop
information (e.g. net data rate..." ? IMHO, the requirement leans more
towards "learning" than towards "configuring".

<Sven> I will bring this to the list.

<Sven> Proposed rewording: "In a TR-059/TR-101 network architecture, the
NAS shapes traffic sent to a particular Access Port according to the
bitrate available on that port. The NAS should take into account the
layer-1 and layer-2 encapsulation overhead on the Access Port, retrieved
from the AN via the Access Node Control Mechanism."

<Sven> I appreciate your comments - they will help to improve the
quality of the document. How do you suggest to proceed at this point?
Are there other critical items in the document that must be tackled?
 
Regards
Sven

Scott

---

From: [email-masked] (Scott O. Bradner)
Date: Tue, 14 Jul 2009 09:34:19 -0400 (EDT)

these proposed changes loook fine to me

> How do you suggest to proceed at this point?

I suggest drafting someone new to walk through each requirement 
to be sure they make sense and are implementable

Scott