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

From: [email-masked]
Date: Mon, 06 Nov 2006 15:52:47 +0100

Hi Woj,

Having reviewed all of your comments, please find below our answers.

Regards,
Sven

Wojciech Dec (wdec) wrote:
> 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.

<Sven> The Control Channel basically is nothing more than an IP
interface over which the messages are sent. Section 2.3 lateron
describes ways of mapping this on an ATM or Ethernet channel. I think it
is fair to reword parts of that section so that the use of a separate
PVC or a separate VLAN or certain QoS settings for the Control Channel
are given as typical scenarios yet not as mandatory requirements.
Section 4.4.2 should be written in this spirit as well. In fact for
section 4.4.2 I believe this is the case: both the QoS settings and the
transmission of the messages across the same physical plant are SHOULD
requirements instead of MUSTs.
</Sven>

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

<Sven>
In case of e.g. LDP, one talks about an "LDP session" and an "LDP Link
Hello Adjacency." An LDP session that exists between two routers is
called an LDP Link Hello Adjacency.

Similarly, we could talk about the ANCP Session (covering all message
exchanges of the use cases) and the ANCP adjacency (which is up or down,
depending on the result of the ANCP adjacency protocol operation).

We suggest to keep both terms and clarify the relation between both in
the beginning of the document. We will perform a detailed check across
the document to be sure that we're using the right term (adjacency or
session) in every case.
</Sven>

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

<Sven>
As I mentioned above, I suggest to reword the section so that the text
describes typical scenarios, without mandating a specific scenario or
excluding other schemes.
</Sven>

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

<Sven>
I believe higher-grade connections refers to access networks with many
access nodes and large amounts of aggregation. We will reword according
to your suggested text.
</Sven>

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

<Sven>
Suggested rewording:
"The ANCP adjacency interactions need to be reliable. In addition to
this, some of the use cases described in section 3.1 also require the
interactions to be performed in a transactional fashion."
</Sven>

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

<Sven>
Agreed with the suggested rewording.
</Sven>

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

<Sven>
Suggested rewording:
"Based on this property, the NAS typically includes a NAS-Port-Id or a
NAS-Port attribute in RADIUS authentication & accounting packets sent to
the RADIUS server(s)."
</Sven>

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

<Sven>
Agreed to remove.
</Sven>

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

<Sven>
Suggested rewording of this requirement and the immediately following
requirement:
"- The ANCP adjacency interactions MUST be reliable.
- The ANCP MUST be able to recover from loss of ANCP messages.
- The ANCP MUST support "request/response" transaction-based
interactions for the NAS to communicate control decisions or request
information from the Access Node. Transactions MUST be either fully
completed, or rolled-back to the previous state.
- The ANCP MUST be able to recover from loss of the ANCP adjacency (e.g.
due to link or node failure) and automatically resynchronize state upon
re-establishing the ANCP adjacency.
"
</Sven>

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

<Sven>
Agreed, we will keep the second requirement (with MUST) and remove the
first one.
</Sven>

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

<Sven>
See above for suggested change. With this change, we suggest to drop the
above requirement.
</Sven>

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

<Sven>
See above for suggested change: "The ANCP adjacency interactions MUST be
reliable."
With this change, we suggest to drop the above requirement.
</Sven>

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

<Sven>
Correct, end-user, we'll make the change.
</Sven>

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

<Sven>
The requirement should be reworded to indicate the capability for both
endpoints of the ANCP adjacency to detect loss of adjacency. Given this
capability, the endpoints can then report to the Element Manager or
Network Manager.

So we suggest to change the requirement to:
"The ANCP adjacency MUST be designed such that loss or malfunction of
the adjacency can be automatically detected by its peers."

In the Access Node and NAS sections, there should then be a requirement
for the nodes to report the loss/malfunction to the Element Manager or
Network Manager.
</Sven>

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

<Sven>
We agree to change "DSL port" to "Access Port".

Many of the requirements in this section are requirements for the
framework/architecture in which ANCP is used. As such they may not be
ANCP protocol requirements but still they are important in order to use
the protocol in the overall network scenario.

We suggest to review the section and update where appropriate to reflect
protocol requirements, and at the same time keep the non-protocol
requirements that are important for the framework.
</Sven>

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

<Sven>
We agree that many requirements are not linked to the protocol as such.
However they are important as guidance for the deployment in an access
network. We therefore recommend to keep them.
</Sven>

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

<Sven>
Section 4.4.3, 4.4.4 should be reworded to protocol requirements.

Section 4.4.5 is a bit trickier, since it links the port identification
schemes used by an Access Node amongst a number of protocols. This is an
Access Node specific requirement in my mind.

In secion 4.4.6, the first requirement is not a protocol requirement.
The second one (message bundling) is, and can be moved to the protocol
section.
</Sven>

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

<Sven>
We suggest to keep section 4.4.7 in its current form. Next to this, we
should discuss about the potential protocol requirement you indicated.
</Sven>

> 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

<Sven>
We suggest to review the section and update where appropriate to reflect
protocol requirements, and at the same time keep the non-protocol
requirements that are important for the framework.
</Sven>

> P27 - Section 7
> 
> Again, these are node functional not protocol requirements.

<Sven>
Agreed, but we also feel they should be kept since they guide in
deploying the protocol in the framework/architecture.
</Sven>

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

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