Subject: [ANCP] Access topology discovery

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Mon, 19 Feb 2007 17:54:49 +0100

Hi All,

First off, thanks to the editor for posting the latest version of the
draft.

I would like to propose some modifications to Section 3.1 of the latest
draft-ancp-framework-01 text to better deal with the nature of the
problem of hierarchical scheduling and access-loop discovery. 

Section 3.1 - Dynamic Access Loop Attributes
The section describes the role of the Hierarchical Scheduling in the
context of access loop and aggregation uplink discovery, and correctly
states that in order to build a 3 level HS information about the
access-loop and access-node uplink is useful. With this in mind, I would
like to propose to change the title of this section back to "Access
topology discovery" (Admittedly not too far off from the title this
section had in the past...)

The section proceeds to list a number of attributes for the access loop
that are desirable to be sent. However it does not provide a similar
attribute list for the access-node uplink, and I would like to propose
that the following be included as an initial set:
- The unique identification (interface-id) of the uplink.
- The type of the access-node uplink (eg Ethernet, ATM, PON, ...)
- The encaps of the access-node uplink (eg n/a, 802.1Q, 802.1ad, ...)
- The up-speed of the access-node uplink
- The down-speed of the access-node uplink
- The state of the access-node uplink

Furthermore, for the purpose of deriving an accurate HS in the presence
of uplink bundling  (eg 802.3ad), it would be useful for the access-node
to report information about the such bundling being active. This would
minimally require that for each uplink that is configured and active in
a link bundle the protocol conveys information about the link's bundle
membership, eg - Member of link-bundle-id.

Since some types of access-nodes can have multiple uplinks, including a
mix of ATM and Ethernet, I think it would make sense to also be able to
convey info from the access-node about the active mapping of access-loop
to access-node uplink, eg DSL port 1/1 maps to uplink 1, DSL port 2/1
maps to uplink 2. For this it would probably make sense to introduce an
additional information element in both the access-loop and uplink
characteristics, which can be used to tie the two together. A simple
proposal one could make is to add the uplink's id as a characteristic of
the access-loop, i.e. - "Access-node uplink id" added to the access-loop
attribute lists.

This however has the downside that should the uplink for a particular
access-loop change, eg due to the activation of a standby up-link
mechanism commonly found on access-nodes, all access-loops would need to
be re-signalled. Thus, it would appear to be better to introduce a
parameter that would avoid such re-signalling, and I would like to
propose the following:
1) including in the access-loop the uplink VLAN or VP/VC to which that
access-loop is currently mapped to, 
2) include in the uplink's description a list of currently active and
forwarding VLANs or VP/VCs.

If an access-node uplink should fail, eg a standby link become
activated, all that would be required to be communicated would be an
update of the uplink status.

Looking forward to the discussion and/or inclusion of these additions in
the ANCP framework draft.

Regards,
Woj.

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

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Thu, 22 Feb 2007 19:55:10 -0500

Hi Woj

   I am ok with uplink attributes in ANCP. The protocol draft alludes to
it when describing certain TLVs. However, I am not convinced LAG
membership info belongs in ANCP. H-QOS in case of LAG (possibly spanning
different line modules on a chassis) can be aided by two ends of a LAG
agreeing upon a common mapping of a subscriber (or access-loop) to a
link in a LAG. However, the LAG can be between DSLAM and BSR (in a
direct-connect model), between DSLAM and aggregation elements, between
aggregation elements themselves, and between aggregation elements and
BSR.  ANCP doesn't apply to all the cases. I consider LACP (with
suitable extensions) to be more generally applicable.

Regards

-Sanjay

________________________________

From: Wojciech Dec (wdec) [mailto:[email-masked]] 
Sent: Monday, February 19, 2007 11:55 AM
To: [email-masked]
Subject: [ANCP] Access topology discovery

Hi All, 

Regards, 
Woj.

---

From: [email-masked]
Date: Mon, 26 Feb 2007 21:40:09 +0100

Hi Woj,

Updating the topolgy discovery discussion in the ANCP framework would
indeed make it in line with the protocol draft.

I support Sanjay's statement below: LAG membership should not be part of 
ANCP - the use of link aggregation should be shielded from the ANCP 
protocol operation. This eases the operational model.

About multiple Access Node uplinks: I'm a bit confused about why we want 
to introduce new info in the ANCP messages that allows linking a port to 
an Access Node uplink. Here are the scenarios I have in mind:

1) multiple uplinks go to different NAS. Access ports are associated 
with a particular ATM VP or Ethernet VLAN on a specific uplink to a 
specific NAS. In this case, I assume the Access Node establishes an ANCP 
Adjacency with each NAS, and uses separate ANCP signaling to each NAS.

As a special case of 1) there's the use of an ATM and an Ethernet uplink

2) multiple uplinks go to the same NAS.

2a] Both uplink ports on the Access Node belong to the same Ethernet 
VLAN. In this case, the Spanning Tree Protocol will most likely put one 
of both links into a blocking state to avoid loops. That means that all 
traffic will be sent to the NAS using the "active" Access Node uplink. 
Upon failure of the active link, the other link will be put out of the 
blocking state and traffic will be directed to the NAS using the new link.

In this scenario, the NAS should only care about differences in 
bandwidth between both uplinks. But there's no need to provide info 
saying "port x/y is now associated with uplink a"

2b] Both uplink ports on the Access Node belong to different VLANs. In 
this case, each access port on the Access Node will be associated with a 
specific uplink by configuration. Upon failure of an uplink, 
connectivity to/from all access ports associated with that link is lost.

In this scenario, one can use a different ANCP Adjacency for each 
uplink. This is like Access Node partitioning but both partitions are 
associated with the same NAS. ANCP topology discovery messages are sent 
on the correct Adjacency.

Is there a scenario with multiple Access Node uplinks, which requires 
further additions to the ANCP topology discovery messaging?

Regards,
Sven

Sanjay Wadhwa wrote:
> BSR.  ANCP doesn’t apply to all the cases. I consider LACP (with 
> ------------------------------------------------------------------------
> 
> *From:* Wojciech Dec (wdec) [mailto:[email-masked]]
> *Sent:* Monday, February 19, 2007 11:55 AM
> *To:* [email-masked]
> *Subject:* [ANCP] Access topology discovery
> 
>  
> 
> Hi All,
> 
> - The type of the access-node uplink (eg Ethernet, ATM, PON, …)
> ------------------------------------------------------------------------
>