Subject: [ANCP] RE: draft-ieft-ancp-framework-00.txt

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Wed, 25 Oct 2006 18:52:45 +0200

Hi Sven and co-authors,

Here are my comments regarding the current draft-ietf-ancp-framework
draft. Feel free to discuss.

P4 - Control channel and ANC Session definition

This terminology has me rather uncomfortable. The control channel is
effectively the logical path along which the IP packet flow happens
between the two ANCP end-points. I don't quite see why there's a need to
ascribe particular requirements to the control channel used by the
protocol, beyond those that are deemed suitable for it by the end users.
Just like a BGP peering could be made using a dedicated VLAN, etc, in
many/most it's not and peer-peer security is still achieved using other
means, and QoS is taken care of by having the BGP packet priority set to
an appropriate protocol control value - yet I do not recall that any BGP
spec mandates the use of any such path, etc.

The ANC Session is really the ANCP adjacency between a controller and a
controlled-node. Isn't the term "ANCP adjacency" sufficient?

P8 - Access Node Control Mechanism Transport methods section
This section doesn't use the terminology defined previously, but
seemingly is referring to the control channel.
Such a "control channel" shouldn't preclude the idea of using a
dedicated interface on the Access-Node, and thus the definition of the
transport as seemingly requiring a logical multiplexer in the form of a
VLAN tag isn't quite right. One could very well have an untagged
ethernet interface, if that's one's choice, and VLAN tagging done
upstream. 

Also, what is meant by "for higher-grade connections..." on P9? 
It also seems to me that the whole sentence could be replaced by
something simpler like: "Depending on network design, this can be a
simple VLAN for each Access Node or, one Customer VLAN (C-VLAN) for each
Access Node within a Service VLAN (S-VLAN) construct".

P9 - "The control plane interactions are transactional in nature and
imply a reliable communication channel to share states."

Terminology: What is the "communication channel"? Do you mean the ANC
session?

Not all of the control plane interactions appear to require a
transactional nature. It would seem that we generally want reliable
communication, but not necessarily transactional state for all
interactions eg knowledge of line rate changes is nice to have reliably,
but doesn't require the protocol to offer a transaction which I
associate with the ability to acknowledge/deny and revert to some
previous state or continue with some operation.
Thus, it appears to me that some of the control plane interactions have
a transactional nature, and all of the communication is desired to be
transmitted reliably.

P9 - "Also, when using the Access Node Control Mechanism for performing
a
   reporting action, there is a possibility to integrate this with a
   central Policy Management system that keeps track of the different
   Subscriber related parameters"

The type of policy system is really secondary - it's whatever system
that wants to consume the info. Suggest replacing the text by;
"Also, when using the Access Node Control Mechanism for performing a
reporting action, there is a possibility to integrate this with a
subscriber policy system that keeps track of the different subscriber
related parameters"

P10 - "In deployments using an ATM aggregation network, the ATM PVC on
an
   Access Loop connects the Subscriber to a NAS.  Based on such
   property, in a PPP scenario, the NAS typically includes a NAS-Port-Id
   (or NAS-Port in some cases) attribute in RADIUS authentication &
   accounting packets sent to the RADIUS server(s).  "

The scenario doesn't necessitate PPP, it's valid for IPoA as well (or
IPoEoA, etc). Also, these are two different radius attributes, and both
are commonly used.

P15 - "The ANCP MUST be an open protocol, either an existing protocol
      endorsed by an appropriate standard body (e.g.  IETF) or a new
      protocol which will be submitted for standardization to an
      appropriate standard body."

Seems that this requirement is rather obsolete, given that we are in the
IETF trying to define it.

"The ANCP MUST be transaction-oriented, allowing to reliably share
      states between the NAS and the Access Node, and recover from loss
      of synchronization (e.g. node or link failure).  Transactions MUST
      be either fully completed, or rolled-back to the previous state."

As per my comment above. It's quite clear that not all transactions need
to be rolled-back. Thus ANCP MUST allow for transaction-oriented
processing of selected information exchanges.
Also, it seems that the immediately following requirement already
captures the "recover from loss of synchronisation" characteristic, thus
this is no longer needed here.

Section 4.2

"The ANCP SHOULD have a "boot" sequence allowing to inform the peer
      about control capabilities supported by the two peers (Access
      Node, NAS) and negotiate a common subset. "

And
"The ANCP MUST provide a means for the AN and the NAS to perform
      capability negotiation.
"

These two seem to state the same thing, but yet one is a MUST while the
other a SHOULD. IMO, the MUST is more appropriate.

"   o  The ANCP SHOULD include a "request/response" transaction-oriented
      model for the NAS to communicate control decisions or request
      information from the Access Node.  If the response is negative,
      then the state of the Access Node MUST be unchanged (roll-back)."

Much has been said about the transactional requirement in the preceding
paragraphs (and I added some more). Shouldn't this requirement be
actually a MUST requirement and furthermore expanded to address that
certain message exchanges are required to be transactional, while others
don't?

P17 - "The transport protocol used for the Access Node Control Messages
      MUST be reliable and scalable."

The requirement is for ANCP to deliver it's payload info reliably. The
transport protocol could be unreliable and the ANCP protocol could
provide the reliability.

P17 - "A loss of the Access Node Control Session MUST NOT affect user
      connectivity and element operation."

End user?

P17 - "For maintenance purpose the Access Node Control Session MUST be
      designed in a way that any malfunction of the session is
      automatically detected and reported from the Access Node or NAS to
      the Element Manager or Network Manager to support the network
      operator in troubleshooting the network."

What has the ANC session design got to do reporting failures?

P17 - Section 4.4 Access Node Requirements

This whole section should IMO be redrafted around to reflect the
protocol requirements arising due to various access-node uses, rather
than actual access-node requirements. Also, the use of terms like "DSL
port" would be best avoided if we still want the notion of supporting
other media types.

P18 - Section 4.4.2

We've defined ANCP to be an IP based control protocol between one node
and a controller. IMO this whole section is superfluous, since it
prescribes functionality that is attributed to the way of configuring a
node and largely independent of the actual protocol requirements. Think
it can be removed.

P18& 19 - Section 4.4.3, 4.4.4 - .6

Here we're actually duplicating a protocol requirement as an access node
requirement. Again, all of this section appears to be redundant as far
as the protocol is concerned. If there any protocol requirements, as I
seem to read in sect 4.4.4, then I think we should turn them into such
as opposed to node requirements. 
Also the use of the term "link" doesn't quite square up to the
terminology.

Eg 
Current req: The Access Node MUST support an adjacency protocol used to
      synchronize states across the link, discover the identity of the
      entity at the other end of a link, and detect when it changes.

Protocol req: The protocol MUST allow the discovery by each end point
the identity of the other end point.
The protocol MUST include a mechanism for synchronising protocol state
information between two end-points.
Etc.

P19 - Section 4.4.7

Again, these are not protocol requirements, at least in their current
form. What *may* be a protocol requirement is actually informing a
controller which issued a command for the change of a setting that is
not administratively allowed, i.e. an appropriate error message.

P20 - section 4.5

Not protocol requirements in their current form - if that some of these
that may have a relation be turned into protocol requirements. The only
one I'm able to see as a potential protocol requirement is the one for
having peer authorization. If we want a node to communicate to only
"authorized nodes" then we need a mechanism for determining such
authorization, or simply assume that the direct configuration of a peer
is sufficient for that peer to be authorized.

The above comment applies to all subsequent sub-sections of 4.5

P27 - Section 7

Again, these are node functional not protocol requirements.

Hope that the above provides some useful input.

Cheers,
Woj.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 13 October 2006 15:59
To: [email-masked]
Cc: Sanjay Wadhwa; Haag, T; [email-masked]; Voigt Norbert;
Matthew Bocci; Wojciech Dec (wdec)
Subject: draft-ieft-ancp-framework-00.txt

Please find below an I-D titled "Framework and Requirements for an
Access Node Control Mechanism in Broadband Multi-Service Networks".

This draft is based on draft-ooghe-ancp-framework-00.txt, which was
accepted by the ANCP community to be moved to a Working Group document. 
It also reflects a few changes/additions resulting from the latest DSL
Forum meeting where this topic was discussed.

Best regards,
Sven Ooghe

_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp

---

From: [email-masked]
Date: Fri, 27 Oct 2006 08:19:54 +0200

Hi Woj,

Thanks for giving the document a good read. We will review the comments 
and provide a consolidated answer on this exploder as soon as we can.

Regards,
Sven