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

From: [email-masked] (Scott O. Bradner)
Date: Mon, 29 Jun 2009 09:35:36 -0400 (EDT)

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) 

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.  

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

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)

"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
.

"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.

"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

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

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?

"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"?

"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