Subject: RE: [L2CP] Revised WG Charter Draft

From: "Sanjay Wadhwa" <[email-masked]>
Date: Thu, 30 Mar 2006 05:13:13 -0500

Knud
 IMHO, the charter should explicitly include "controller redundancy". We in principle agreed to include it at the BOF. The fact that GSMPv3 provides for redundancy is just another reason why it is a good fit for L2CP. However, building on top of what base GSMPv3 provices, we will still need to define precise procedures/actions on controller failover (e.g. re-creation of state on the redundant controller). 

-Sanjay     

>-----Original Message-----
>From: Knud Gjørup (AH/LMD) [mailto:[email-masked]]
>Sent: Thursday, March 30, 2006 4:07 AM
>To: Andrew G. Malis
>Cc: [email-masked]
>Subject: RE: [L2CP] Revised WG Charter Draft
>
>
>Andy,
>
>We don't need to mention "communication between redundant 
>CSMSes" in the charter as this problem is "solved" in GSMP 
>(and GAMP is an extended subset of GSMPv3++)
>
>The GSMP approach is to introduce an "Adjacency Update 
>message" (Message Type = 85). It informs the controller/CSMS 
>when adjacencies, i.e., other controllers/CSMSes controlling a 
>specific partition/AN, are joining or leaving.
>And the overall concept is (quoted): "Multiple switch 
>controllers/CSMSes may jointly control a single switch 
>partition/AN.  The controllers/CSMSes may control a switch 
>partition/AN either in a primary/standby fashion or as part of 
>multiple controllers/CSMSes providing load-sharing for the 
>same partition/AN. It is the responsibility of the 
>controllers/CSMSes to co-ordinate their interactions with the 
>switch partition/AN". (I especially like the last sentence)
>
>This concept fits us (as manufacturer of big ANs) very well. 
>Our equipment (DSLAMs) are e.g. bought and deployed by an 
>Access Provider. The ports on a DSLAM are split up into 
>several partitions=ANs, one for each Network Access Provider 
>(NAP). The NAP handles one or several CSMSes used for General 
>Access Management on there part of a DSLAM, i.e. on there 
>partition. This implies that multiple CSMSes handling the same 
>AN/partition belongs to one and only one organization (capable 
>of doing the necessary co-ordination between the CSMSes).
>A NAP handling access ports on a DSLAM is not aware of the 
>other NAPs handling access ports on the same physical DSLAM.
>
>I general (I think) we tend to invent everything by ourselves 
>from scratch, in stead of looking for inspiration in GSMPv3++ 
>(or in WT-101).
>
>Cheers,
>Knud
>
>
>> -----Original Message-----
>> From: Andrew G. Malis [mailto:[email-masked]] 
>> Sent: 29. marts 2006 16:31
>> To: Knud Gjørup (AH/LMD)
>> Cc: Wojciech Dec (wdec); [email-masked]
>> Subject: RE: [L2CP] Revised WG Charter Draft
>> 
>> Knud,
>> 
>> Assuming you take this approach to the architecture, should 
>> the L2CP/BAMP/BANCo protocol also be required to handle 
>> communication between redundant CSMSes, so that the CSMS 
>> doesn't become a potential single point of failure?  This 
>> would be necessary if the CSMS retains knowledge of the state 
>> of the AN.  Should this become part of the charter?
>> 
>> Cheers,
>> Andy
>> 
>> -------------
>> 
>> At 3/29/2006 13:50 +0200, AH/LMD wrote:
>> >Hi All,
>> >
>> >Let me first apologise for being "a bull in a china shop", 
>> but I think 
>> >our charter is much too specific and is perhaps disguising 
>> our actual 
>> >task.
>> >
>> >The must important sentence in the charter is:
>> > > The goal of a L2CP message exchange is to convey status 
>> and control 
>> > > information between access devices and one or more other 
>> NAS devices 
>> > > without going through intermediate element managers.
>> >
>> >In general I consider L2CP an application protocol between a 
>> Customer 
>> >Service Management System (CSMS) and an Access Node (AN).
>> >The CSMS may be situated in a BRAS, NAS, BNG or even 
>together with a 
>> >Radius server, but the important task for the CSMS is to  
>> communicate 
>> >the content of the Customer Service DB (like agreed
>> >QoS) to the AN and to communicate the actual QoS back to the 
>> accounting 
>> >system and the Customer Service DB. This communication is 
>> done by L2CP.
>> >The AN implements (or understands) some standardised L2CP primitives
>> >e.g.: Access-Line-Status, Access-Line-Configuration (profiles), and 
>> >Access-Line-Test. These primitives should be as independent of the 
>> >actual access technology as possible! The primitives are invoked (or
>> >communicated) by the L2CP application protocol as described 
>> in the use 
>> >cases in the below charter.
>> >
>> >If you agree in this overall reference architecture for 
>L2CP, I also 
>> >think you must agree in the following points:
>> >1) L2CP is independent of the actual communication technology (as 
>> >application protocols in general) between the CSMS and the AN,
>> >implying: L2CP is not IP based! But the WG will analyse and 
>> define the 
>> >different comm. technologies including IP, UDP, TCP, 
>> Ethernet etc and 
>> >specify the necessary encapsulation methods.
>> >2) In spite L2CP is comm. techn. independent it is decided to be 
>> >connection less based (like GSMP). If it is not defined as 
>> connection 
>> >less it will be impossible/difficult to use UDP or Ethernet as 
>> >communication technology.
>> >3) The standardised L2CP primitives (in the AN) are 
>> independent of the 
>> >actual access technology, and when not, this should be explicitly 
>> >specified. The WG will emphasise on DSL Ether based and DSL 
>> ATM based 
>> >access, but will not preclude the use of other access technologies. 
>> >(This is why I personally don't like to use Layer-2 or 
>> Broadband in the 
>> >WG name e.g. BAMP -  but prefer GAMP as I consider L2CP to 
>> be a sort of 
>> >umbrella for different Access Management Protocols)
>> >
>> >But as always when you specify something, you try to make your 
>> >specification and definitions very general and 
>> comprehensive, and when 
>> >you end up with your specification you will realise that you 
>> have found 
>> >a reasonable compromise and a result much more specific and limited 
>> >than originally planned.
>> >
>> >What I want to emphasize by this note is that we have to 
>TRY to make 
>> >L2CP a GENERAL application protocol to ensure it's future 
>> applicability!
>> >
>> >Regards
>> >Knud
>> >
>> >
>> > > -----Original Message-----
>> > > From: Wojciech Dec (wdec) [mailto:[email-masked]]
>> > > Sent: 27. marts 2006 16:15
>> > > To: [email-masked]
>> > > Subject: [L2CP] Revised WG Charter Draft
>> > >
>> > > Hello All,
>> > >
>> > > Following last week's BoF and the collected feedback we 
>have gone 
>> > > and revised the charter which is now re-proposed below.
>> > > The name of the WG is in the process of being discussed and it's 
>> > > clear that it will NOT be L2CP, so please substitute L2CP with 
>> > > whatever is your preferred acronym while reading the draft.
>> > >
>> > > In order to put together the charter into shape in a reasonably 
>> > > timely manner I would encourage all interested parties to 
>> provide a 
>> > > prompt review, feedback and discussion.
>> > > Once we have a proposal that's acceptable we will be putting the 
>> > > draft to a group "final call", tentatively aiming for 
>> approximately 
>> > > 2 weeks from now.
>> > >
>> > > Regards,
>> > > Woj.
>> > >
>> > > -------------------WG CHARTER (DRAFT)------------------------
>> > >
>> > > Layer 2 Control Protocol (L2CP)
>> > >
>> > >
>> > > Current Status: Non-existing Working Group
>> > >
>> > > Chair(s):
>> > > Matthew Bocci ([email-masked]) Wojciech Dec
>> > > ([email-masked])
>> > >
>> > > Internet Area Director(s):
>> > > Mark Townsley <[email-masked]>
>> > > Jari Arkko <[email-masked]>
>> > >
>> > > Technical Advisor(s):
>> > > TBD <tbd>
>> > >
>> > > Secretary(ies):
>> > > TBD <tbd>
>> > >
>> > > Area Specific Mailing List:
>> > > [email-masked]
>> > >
>> > > Mailing Lists:
>> > > General Discussion: [email-masked]
>> > > To Subscribe: [email-masked]
>> > > In Body: subscribe your_email_address
>> > > Archive: http://www.ietf.org/mail-archive/web/l2cp/index.html
>> > >
>> > > Description of the charter for this WG:
>> > >
>> > > The purpose of the L2CP WG is to standardize an IP based Layer 2 
>> > > control protocol (L2CP) for use in service provider access and 
>> > > aggregation type networks. The protocol is to be inter-operable 
>> > > among a wide set of multi-vendor devices, including but 
>> not limited 
>> > > to Access Nodes and Network Access Server (NAS) nodes 
>> e.g. Broadband 
>> > > Network Gateways (BNGs).
>> > >
>> > > L2CP is intended to addresses the requirement for a 
>> bidirectional, 
>> > > IP-based protocol that operates across a number of access and 
>> > > aggregation network technologies e.g.
>> > > Ethernet, ATM. The goal of a L2CP message exchange is to convey 
>> > > status and control information between access devices and one or 
>> > > more other NAS devices without going through 
>intermediate element 
>> > > managers. An example of this is the transmission of an 
>> access loop 
>> > > rate information from the edge access node to a NAS 
>device tasked 
>> > > with shaping traffic to that rate. A further example is 
>> to trigger a 
>> > > local action on an access device, such as the initiation 
>> of a local 
>> > > port testing mechanism.
>> > >
>> > > L2CP will address the following use-cases:
>> > >
>> > > - Access Link Discovery
>> > > Various queuing and scheduling mechanisms are used in access 
>> > > networks to avoid congestion while dealing with multiple 
>> flows with 
>> > > distinct QoS requirements. Such mechanisms require that a 
>> NAS node 
>> > > gains knowledge of particular access-loop characteristics 
>> e.g. DSL 
>> > > sync Rate. The layer 2 control protocol is intended to 
>> convey this 
>> > > information between the access node and a NAS node.
>> > >
>> > > - Line Configuration
>> > > Following dynamic line identification (subscriber local loop), 
>> > > assisted by the mechanism described in the access link 
>> discovery use 
>> > > case, a NAS node could then query a subscriber OSS system (e.g. 
>> > > RADIUS server) to retrieve subscriber service profiles 
>> relating to 
>> > > the subscriber line.
>> > > L2CP is intended to simplify the OSS infrastructure for service 
>> > > management, allowing subscriber-related service data to be 
>> > > maintained in fewer repositories (e.g. RADIUS server back-end 
>> > > database) while avoiding complex cross-organization interactions.
>> > >
>> > > - Remote Connectivity Test
>> > > Traditional DSL broadband access networks employ 
>> point-to-point ATM 
>> > > circuits between a DSL modem and a NAS. In such an environment, 
>> > > troubleshooting of the local loop and aggregation network can be 
>> > > achieved by means of end-to-end ATM loopbacks. With the 
>> increasing 
>> > > deployment of Ethernet in the aggregation network, 
>> operators require 
>> > > consistent methods to test and troubleshoot connectivity 
>> for mixed 
>> > > Ethernet and ATM access networks (including the local 
>loop). L2CP 
>> > > will allow a remote procedure for the local loop 
>> connectivity test 
>> > > to be triggered from the NAS and the results 
>communicated back to 
>> > > the NAS.
>> > >
>> > > - Multicast
>> > > Various mechanisms have been defined to create multicast 
>> replication 
>> > > in the access nodes. There is a need to control multicast 
>> > > replication in the access node, and to communicate 
>> multicast state 
>> > > between the access node and the NAS node in order to allow, for 
>> > > example, centralized policy control.
>> > > L2CP will address security aspects of the control protocol, 
>> > > including the trust model between NAS nodes and access nodes.
>> > > The protocol will work with typical redundancy schemes for 
>> > > subscriber service nodes and will be resilient to network 
>> failures.
>> > >
>> > > The protocol design will not preclude other uses of L2CP.
>> > >
>> > > The working group will define a framework and set of 
>> requirements, 
>> > > and will investigate and define a solution for an IP 
>> based Layer 2 
>> > > control protocol that is robust, reliable and scalable. 
>> L2CP will be 
>> > > based on extensions to existing protocols, although the working 
>> > > group must justify its choice. The initial proposal for L2CP is 
>> > > based on a subset of GSMPv3.
>> > >
>> > > L2CP will not address the signaling of any type of VCs 
>> used in the 
>> > > underlying aggregation network.
>> > >
>> > >
>> > > Goals and Milestones:
>> > >
>> > > July 2006           Accept WG I-D for L2CP Framework / 
>> Requirements
>> > > July 2006           Accept WG I-D for L2C Protocol extensions
>> > > September 2006  Framework and requirements last call
>> > > November 2006   Accept WG I-D for L2C MIBs
>> > > December 2006   Protocol extensions last call
>> > > January 2007    MIBs last call
>> > > March 2007    Re-charter or conclude Working Group
>> > >
>> > > Internet-Drafts:
>> > >
>> > > _______________________________________________
>> > > L2cp mailing list
>> > > [email-masked]
>> > > https://www1.ietf.org/mailman/listinfo/l2cp
>> > >
>> >
>> >_______________________________________________
>> >L2cp mailing list
>> >[email-masked]
>> >https://www1.ietf.org/mailman/listinfo/l2cp
>> 
>> 
>
>_______________________________________________
>L2cp mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/l2cp
>

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 30 Mar 2006 11:44:56 -0500

Knud and Sanjay,

This was my point exactly.

Cheers,
Andy

-----------

At 3/30/2006 05:13 -0500, Sanjay Wadhwa wrote:
>Knud
>  IMHO, the charter should explicitly include "controller 
> redundancy". We in principle agreed to include it at the BOF. The 
> fact that GSMPv3 provides for redundancy is just another reason why 
> it is a good fit for L2CP. However, building on top of what base 
> GSMPv3 provices, we will still need to define precise 
> procedures/actions on controller failover (e.g. re-creation of 
> state on the redundant controller).
>
>-Sanjay
>
>