Subject: [ANCP] Comments on draft-ietf-ancp-framework-02

From: <[email-masked]>
Date: Tue, 28 Aug 2007 14:44:19 +0530

Hello Sven et al.,
 
Please find below my comments on ANCP protocol framework draft.
Covers most of the sections of the framework draft and points to
specific improvements required.
 
Page 6:
 
>From figure 1, it appears that the controller would reside in NAS
generally.
Not sure if a one-directional controller-reporter model would be the
best possible mechanism.  This needs to take into account the
possibility of extending this mechanism to US QoS control. With the new
evolving access model and architecture, possibility of more
user-generated content and highbandwidth streams are foreseen, moving
away from a provider-centric model. It would help to have provisions for
this, by having the control at either endpoints of ANCP adjacency.
 
Page 7:
 
Reporting and/or enforcement function - Here enforcement should probably
be a separate function as it can be in AN or NAS.
e.g. In NAS traffic shaping based on access loop rate report, the
enforcement function is in NAS.
Also, enforcement should be based on a policy decision or report. Hence,
port testing initiation may not be classified as an example of
enforcement.
 
Page 8:
 
2.2.2 - The term NID may be replaced with a term consistent with the
figure (HGW). More important than the protocol encapsulations, I think,
is the physical layer
technologies that may be used in access loop, i.e. different DSL types:
ADSL2+, VDSL2, VDSL, SHDSL, etc. (Assuming that this draft considers
just DSL as explained in introduction and not WiMAX or PON based access
networks)
 
2.2.3 - Paragraph 4 - Enforcement need not be in access node alone (e.g.
traffic shaping in NAS)
 
Page 12:
 
3.1 - Section title - could be along the lines of "Access node
capabilities report", there seems to be no discovery involved.
Paragraph 2 - "topology of the access network" can be removed - it seems
to me that NAS does not have any knowledge of the network topology.
If needed, it can be addressed in a separate section -Access topology
discovery.
 
Paragraph 3 - Reference to "Access port discovery" - needs to be made
consistent with section title.
 
Paragraph 5 - Not sure if NAS hierarchical scheduling based on DSL sync
rate would be the best possible thing to do. It may help to some extent.
But, ANs typically apply rate limiting per DSL port that may be far too
lower than the actual DSL sync rate. In such a case, it would make sense
to communicate the lesser of the two (sync rate or rate limit). This
again may not take into account the bandwidth consumed by multicast
traffic replicated locally at AN.
 
Paragraph 6 - Access loop characteristics - Would be a good idea to add
DSL port bonding status. If ports are bonded at PHY level or at ATM or
ethernet level,
it is important that NAS is aware of this to determine the rate for
shaping.
 
Page 15:
 
3.2 Access loop configuration - It would be useful to make the result of
configuration always communicated back to NAS/controller. This is needed
to ensure synchronization between the elements as a configuration may
fail or may be denied by an AN.
 
Paragraph 4 - QoS profile for an access loop - it would be good to have
an example profile and/or an illustration of this as it is an important
functionality.
 
Page 18:
 
4.1 - A requirement is needed to specify the bandwidth limit for
protocol message overhead.
(ANCP protocol message overhead must not exceed x% of link capacity or x
kbps).
 
Page 20:
 
4.4 - ANCP transport requirements - Redundant paths (VLAN/VC) for the
control channel can be made a requirement.
 
Page 21:
 
4.5.1 - Last requirement - "AN should be able to work with redundant
controllers" - Elaborate on requirement for maintaining redundant
adjacencies and the failover mechanisms.
 
Page 22:
 
4.5.2 - ANCP capability negotiation procedure - framework and rationale
for this needs to be provided separately.
 
Page 23:
 
4.6.1 - Minimum/maximum number of ANCP adjacencies to be supported by
NAS needs to be identified. Number of ANCP instances supported at NAS
can also be specified.
 
Page 28:
 
6. - Management related requirements - When ANCP adjacency is up in AN,
any configuration parameter successfully updated by ANCP should not be
allowed to be changed by local EMS. This is required to ensure
consistency of data and operation.
 
A general comment:
 
On using the AN uplink attributes in ANCP, it might be necessary to
consider other bottlenecks in aggregation network. The links between AN
and NAS could be a direct-connect in which case, it is straightforwad.
However, when there are aggregation elements involved, it would help to
provide for extensions in the framework to identify any link bottleneck.
The capacity of links between aggregation elements or the links betweek
an aggregation node and NAS can be static or dynamic (link aggregation).
Identifying bottlenecks in the link capacity here would help do a more
accurate traffic scheduling or shaping at NAS as compared to having just
the AN uplink attributes.
 
Thanks,
Kirubaharan
_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp