Subject: RE: [L2CP] Draft charter for Layer 2 Control

From: "Sanjay Wadhwa" <[email-masked]>
Date: Tue, 24 Jan 2006 12:06:44 -0500

Sven
  I see your point that all folks might not agree on all the items on the charter. But, in that case, as long as technically the work makes sense, one goes by the superset. Not including something that has technical feasibility and seems to be in scope is also controversial. I will be a little surprised if the working text for L2C in DSLF does not consider use-cases specified in PD21.
It probably makes sense to put all currently known use cases in the charter upfront, and then based on input from carriers in the first IETF session, we can modify (limit) the charter if required. So far we have seen customer interest in "line config" and atleast some curiousity on scenarios where multicast might make sense. 
Let me know your thoughts on this approach.

Thanks
-Sanjay

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Tuesday, January 24, 2006 11:27 AM
>To: Sanjay Wadhwa
>Cc: [email-masked]; [email-masked]
>Subject: Re: [L2CP] Draft charter for Layer 2 Control
>
>
>Sanjay,
>
>I'm not at all saying that the requirements for L2C must be a 
>subset of 
>those addressed in PD-021. I'm simply saying that we have to 
>be clear on 
>a non-controversial scope if we want to have a successful BOF and get 
>the WG starting.
>
>The way I understand things, PD-021 was sent to the IETF in 2004 with 
>the statement that "this is not an official DSL position or draft, but 
>is still in investigation". Ok, this may be nitpicking but we have to 
>avoid all potential pitfalls if we want to be successful.
>
>Recently, in December we got the green light from the DSL Forum 
>community to establish a Working Text that would be "based on the use 
>cases [topology discovery and OAM] as well as reflecting of existing 
>PD-021 document, starting with:
>·	Introduction
>·	Overall concept of a control channel (architecture and 
>guidelines)
>·	Use cases for Layer 2 Control:
>o	Topology discovery (includes Rate Adaptive Mode)
>o	OAM in a mixed ATM/Ethernet environment
>·	Parameters to be exchanged"
>
>Putting the above in a draft charter would therefore give the green 
>light of the entire DSL Forum community.
>
>I agree that the protocol can have a broader applicability and 
>this must 
>be discussed further in the course of the coming weeks/months. 
>I expect 
>that this will also happen in the DSL Forum community.
>
>Thanks,
>Sven
>
>Sanjay Wadhwa wrote:
>
>> Sven
>>   I haven't heard an arguement on why requirements for L2C in IETF
>> should be a subset of requirements/use-cases in DSLF.. 
>specially since
>> we have sent the PD21 to IETF as part of DSLF liason. Again, not
>> considering "line config" and multicast while talking about
>> requirements/framework clearly limits the applicability of 
>the protocol.
>> If these use cases are considered when defining the 
>requirements, there
>> is a possibility that work can be done in parallel on some 
>of the items
>> in the charter. Not considering these in the requirement 
>definition more
>> or less precludes work on these items. It is hard to buy the 
>arguement
>> that we will be in better standing with ietf if we limit the
>> requirements to fewer use-cases. Usually, the 
>requirements/framework is
>> exhaustive (this is quite evident in other WGs).. 
>> 
>> my $0.02
>> 
>> -Sanjay
>> 
>> 
>> 
>>>-----Original Message-----
>>>From: [email-masked] [mailto:[email-masked]]On 
>Behalf Of
>>>[email-masked]
>>>Sent: Monday, January 23, 2006 2:14 PM
>>>To: [email-masked]; [email-masked]
>>>Subject: Re: [L2CP] Draft charter for Layer 2 Control
>>>
>>>
>>>Peter, all,
>>>
>>>I'm also in favor of getting sure we get IETF acceptance of the
>>>foundation, and then proceed by rechartering the WG as deemed 
>>>appropriate.
>>>
>>>In fact, given that a lot of work has already been done before we
>>>started this thread, the timing wrt delivery of the first documents
>>>could be updated. How about having a stable framework requirements
>>>document and protocol specification for the first use cases by July
>>>2006? This would give us about 4 months to do the work.
>>>
>>>Then we could proceed on the enhancements to accomplish L2CP over a
>>>lightweight transport, as well as potential specifics for 
>other access
>>>technologies.
>>>
>>>Regards,
>>>Sven
>>>
>>>Peter Arberg wrote:
>>>
>>>>Hi,
>>>>
>>>>I think this is a good approach, and also what we see from 
>>>
>>>other WG's,
>>>
>>>>that the charter can be extended when initial goals are delivered,
>>>>and members of the WG agree.
>>>>
>>>>I'm not sure however that "line configuration" need to be treated 
>>>>as a seperate use case. Could it not be included in the 
>>>
>>>Topology Discovery,
>>>
>>>>if we simply extended this to talk about topology discovery and 
>>>>provisioning. Is it really a use case on its own ?
>>>>
>>>>cheers,
>>>>Peter
>>>>
>>>> 
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: [email-masked] [mailto:[email-masked]] On 
>>>>>Behalf Of Kim Hyldgaard (ST/LMD)
>>>>>Sent: 22. januar 2006 23:04
>>>>>To: [email-masked]; [email-masked]
>>>>>Subject: RE: [L2CP] Draft charter for Layer 2 Control
>>>>>
>>>>>Hi Sven,
>>>>>
>>>>>Yes, this is a risk, and that's why i put a secondary suggestion: 
>>>>>
>>>>>
>>>>>
>>>>>>If this is too loose to put in the charter, I'd rather focus on 
>>>>>>topology discovery and OAM only and get these two use cases 
>>>>>
>>>>>in place 
>>>>>
>>>>>
>>>>>>together with the light weight transport and non-DSL 
>>>>>
>>>>>technologies, and
>>>>>
>>>>>
>>>>>
>>>>>>then consider more use cases when re-chartering.
>>>>>
>>>>>Wouldn't this be a way forward? Having light weight transport and
>>>>>non-DSL
>>>>>technologies covered with the two most important use cases 
>is sort of
>>>>>the foundation for L2CP. 
>>>>>
>>>>>Br
>>>>>Kim
>>>>>
>>>>>-----Original Message-----
>>>>>From: [email-masked] [mailto:[email-masked]] 
>>>>>Sent: 20. januar 2006 18:23
>>>>>To: Kim Hyldgaard (ST/LMD); [email-masked]
>>>>>Subject: Re: [L2CP] Draft charter for Layer 2 Control
>>>>>
>>>>>Hi Kim,
>>>>>
>>>>>thanks for the feedback. I've got sympathy for the idea to 
>identify a
>>>>>track on "analyzing additional use cases", and let line 
>configuration
>>>>>fall under that one. At the same time I have some concerns 
>that these
>>>>>newer use cases may lack the level of consensus required to have a
>>>>>successful BOF and agreed upon charter. Having a crisp scope and
>>>>>avoiding loose charter statements key to be able to get started.
>>>>>
>>>>>What do others on this list think?
>>>>>
>>>>>Regards,
>>>>>Sven
>>>>>
>>>>>Kim Hyldgaard (ST/LMD) wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi Sven,
>>>>>>
>>>>>>Just a quick comment:
>>>>>>
>>>>>>You have put the OAM and topology discovery in the description.
>>>>>>This is fine, however, I think you should remove Line 
>Configuration 
>>>>>
>>>>>>from the goals and milestones list and instead add a more general 
>>>>>
>>>>>>track, like "Analyse additional use cases" and "Investigate 
>>>>>
>>>>>a protocol
>>>>>
>>>>>
>>>>>
>>>>>>solution for additional use cases found in the analysis"
>>>>>>
>>>>>>In this way we specify the two first use cases, topology 
>>>>>
>>>>>discovery and
>>>>>
>>>>>
>>>>>
>>>>>>OAM, and make room for more use cases - whether it is line 
>>>>>>configuration or multicast (or something else).
>>>>>>
>>>>>>If this is too loose to put in the charter, I'd rather focus on 
>>>>>>topology discovery and OAM only and get these two use cases 
>>>>>
>>>>>in place 
>>>>>
>>>>>
>>>>>>together with the light weight transport and non-DSL 
>>>>>
>>>>>technologies, and
>>>>>
>>>>>
>>>>>
>>>>>>then consider more use cases when re-chartering.
>>>>>>
>>>>>>Br
>>>>>>Kim
>>>>>>
>>>>>>
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [email-masked] [mailto:[email-masked]] 
>>>>>
>>>>>On Behalf 
>>>>>
>>>>>
>>>>>>Of [email-masked]
>>>>>>Sent: 19. januar 2006 17:19
>>>>>>To: [email-masked]
>>>>>>Subject: [L2CP] Draft charter for Layer 2 Control
>>>>>>
>>>>>>Dear L2CP'ers,
>>>>>>
>>>>>>Here's a first stab at the charter for a new working group 
>>>>>
>>>>>that would 
>>>>>
>>>>>
>>>>>>focus on Layer 2 Control.
>>>>>>
>>>>>>Some remarks:
>>>>>>- I've put initial focus on the *concept* of Layer 2 
>Control rather 
>>>>>>than the *protocol* to achieve that concept. This is done in the 
>>>>>>spirit of pitfall 5) described in 
>draft-narten-successful-bof-00.txt
>>>>>>(Considerations for Having a Successful BOF). Having said 
>>>>>
>>>>>that, I've 
>>>>>
>>>>>
>>>>>>also put focus on GSMPv3 as the starting point for protocol work.
>>>>>>- I've assumed that the working group would fall under the 
>>>>>
>>>>>umbrella of
>>>>>
>>>>>
>>>>>
>>>>>>the Internet Area.
>>>>>>- Positions for Chair(s), Technical Advisor(s) and 
>>>>>
>>>>>Secretary(ies) are 
>>>>>
>>>>>
>>>>>>left open
>>>>>>- Should we somehow refer to the l2cp work performed at the 
>>>>>
>>>>>DSL Forum?
>>>>>
>>>>>
>>>>>
>>>>>>I assume we can only refer to publicly available documents. 
>>>>>
>>>>>The only 
>>>>>
>>>>>
>>>>>>document that has been made visible to the IETF is a 
>>>>>
>>>>>previous version 
>>>>>
>>>>>
>>>>>>of
>>>>>>PD-021v2 (see email on the GSMP exploder, Nov 14, 2004)
>>>>>>
>>>>>>Comments are welcome!
>>>>>>
>>>>>>Regards,
>>>>>>Sven
>>>>>>
>>>>>>Layer 2 Control (l2c)
>>>>>>=====================
>>>>>>
>>>>>>Current Status: Non-existing Working Group
>>>>>>
>>>>>>Chair(s):
>>>>>>TBD <tbd>
>>>>>>TBD <tbd>
>>>>>>
>>>>>>Internet Area Director(s):
>>>>>>Mark Townsley <[email-masked]>
>>>>>>Margaret Wasserman <[email-masked]>
>>>>>>
>>>>>>Internet Area Advisor:
>>>>>>Mark Townsley <[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:
>>>>>>
>>>>>>When deploying value-added services across broadband access 
>>>>>
>>>>>networks 
>>>>>
>>>>>
>>>>>>(e.g. DSL), special care is required to obtain the 
>desired level of 
>>>>>>quality of service and effective service control. With the 
>>>>>>introduction of so-called "triple play services" (i.e. high speed 
>>>>>>Internet access, voice over IP and broadcast TV / Video 
>on Demand), 
>>>>>>some means of coordination between the different network 
>>>>>
>>>>>elements in 
>>>>>
>>>>>
>>>>>>the access network becomes necessary.
>>>>>>
>>>>>>Traditionally, the different network elements are usually 
>>>>>
>>>>>controlled 
>>>>>
>>>>>
>>>>>>by separate element managers, which are connected to one set of 
>>>>>>network and service management systems. Frequently, 
>organizational 
>>>>>>boundaries will be in place between departments operating 
>the local 
>>>>>>loop, the access/aggregation network and the IP network. 
>>>>>
>>>>>One approach 
>>>>>
>>>>>
>>>>>>to obtain the desired level of coordination would thus be 
>>>>>
>>>>>based on the
>>>>>
>>>>>
>>>>>
>>>>>>introduction of standard business-to-business interfaces 
>>>>>
>>>>>between these
>>>>>
>>>>>
>>>>>
>>>>>>domains. This approach may be a challenging one if real 
>>>>>
>>>>>time behavior 
>>>>>
>>>>>
>>>>>>is to be achieved.
>>>>>>
>>>>>>The approach that will be considered by this working group 
>>>>>
>>>>>consists of
>>>>>
>>>>>
>>>>>
>>>>>>the introduction of a dedicated control mechanism between 
>an Access 
>>>>>>Node (e.g. a DSLAM) and a Broadband Network Gateway (e.g. 
>a BRAS). 
>>>>>>This concept is called "Layer 2 Control" (l2c), in line 
>>>>>
>>>>>with the ideas
>>>>>
>>>>>
>>>>>
>>>>>>discussed and being worked out by the DSL Forum (cf. PD-021v2 
>>>>>>submitted to the GSMP exploder on November 14, 2004).
>>>>>>
>>>>>>Different applications can be identified where there is a 
>>>>>
>>>>>desire for a
>>>>>
>>>>>
>>>>>
>>>>>>control plane between an Access Node and a BNG in order 
>to perform 
>>>>>>QoS-related, service-related and subscriber-related operations.
>>>>>>
>>>>>>Firstly, this working group is responsible for writing the 
>>>>>
>>>>>framework 
>>>>>
>>>>>
>>>>>>and requirements for Layer 2 Control. This working group 
>>>>>
>>>>>will consider
>>>>>
>>>>>
>>>>>
>>>>>>the input of the DSL Forum in the definition of the use cases.
>>>>>>
>>>>>>Secondly, this working group will investigate a protocol 
>>>>>
>>>>>solution to 
>>>>>
>>>>>
>>>>>>achieve "Layer 2 Control" between an Access Node and a BNG for 
>>>>>>selected use cases, including the following:
>>>>>>
>>>>>>- Topology discovery
>>>>>>DSL Forum TR-059 identifies various queuing/scheduling 
>>>>>
>>>>>mechanisms to 
>>>>>
>>>>>
>>>>>>avoid congestion in the access network while dealing with 
>multiple 
>>>>>>flows with distinct QoS requirements. Such mechanisms 
>>>>>
>>>>>require that the
>>>>>
>>>>>
>>>>>
>>>>>>BNG gains knowledge of the topology of the access network, 
>>>>>
>>>>>the various
>>>>>
>>>>>
>>>>>
>>>>>>links being used and their respective rates. One approach 
>>>>>
>>>>>to achieve 
>>>>>
>>>>>
>>>>>>this is to send the characteristics of the local loop (e.g. 
>>>>>
>>>>>DSL sync 
>>>>>
>>>>>
>>>>>>rate) at session establishment time. In this case, the 
>>>>>
>>>>>characteristics
>>>>>
>>>>>
>>>>>
>>>>>>would be added to DHCP and/or PPPoE messages by means of 
>>>>>
>>>>>newly defined
>>>>>
>>>>>
>>>>>
>>>>>>sub-options. Another approach consists of sending the 
>>>>>
>>>>>information by 
>>>>>
>>>>>
>>>>>>means of a new Layer 2 Control mechanism, independent of 
>the PPP or 
>>>>>>DHCP session. In this case it is possible to take into 
>account the 
>>>>>>possible dynamic nature of the access loop (e.g. when using 
>>>>>
>>>>>Seamless 
>>>>>
>>>>>
>>>>>>Rate Adaptation).
>>>>>>
>>>>>>- OAM
>>>>>>Traditional DSL broadband access networks employ 
>point-to-point ATM 
>>>>>>circuits between a CPE and a BRAS. In such an environment, 
>>>>>>troubleshooting can be achieved by means of end-to-end ATM 
>>>>>
>>>>>loopbacks.
>>>>>
>>>>>
>>>>>>With Ethernet getting a more important role as layer 2 
>>>>>
>>>>>technology in 
>>>>>
>>>>>
>>>>>>the aggregation network, operators require to keep ways 
>to test and 
>>>>>>troubleshoot connectivity in the case of a mixed Ethernet and ATM 
>>>>>>access network (including the local loop). To reach 
>>>>>
>>>>>consistency with 
>>>>>
>>>>>
>>>>>>ATM based broadband access networks, a layer 2 control 
>>>>>
>>>>>mechanism can 
>>>>>
>>>>>
>>>>>>be introduced between a BNG and an Access Node, allowing 
>to trigger 
>>>>>>the OAM mechanism used on the local loop.
>>>>>>
>>>>>>In the context of PD-021v2, a protocol analysis was 
>>>>>
>>>>>performed to find 
>>>>>
>>>>>
>>>>>>the best solution to achieve "Layer 2 Control". PD-021v2 
>recommends 
>>>>>>achieving these concepts based on the General Switch Management 
>>>>>>Protocol (GSMPv3). It was concluded that the full set of 
>>>>>
>>>>>GSMP was not 
>>>>>
>>>>>
>>>>>>needed to drive Layer 2 Control messages, and that GSMPv3 
>>>>>
>>>>>needed to be
>>>>>
>>>>>
>>>>>
>>>>>>extended with new parameters and message types.
>>>>>>
>>>>>>This working group is responsible for investigating which 
>subset of
>>>>>>GSMPv3 is required for l2c and which extensions are to be 
>specified 
>>>>>>for the selected use cases. It will also respond to 
>protocol issues 
>>>>>>that arise during implementation of the current specifications.
>>>>>>
>>>>>>Finally, this working group will investigate possible 
>extensions of 
>>>>>>the above concepts to obtain broader applicability. In this 
>>>>>
>>>>>context, 
>>>>>
>>>>>
>>>>>>the following will be addressed:
>>>>>>
>>>>>>- Use of l2c over non-DSL access technologies Alternate broadband 
>>>>>>access technologies such as PON, Ethernet and Wimax will 
>>>>>
>>>>>have similar 
>>>>>
>>>>>
>>>>>>challenges to address. These technologies could benefit 
>>>>>
>>>>>from the same 
>>>>
>>>>>>approach, providing a unified control and management 
>>>>>
>>>>>architecture for 
>>>>>
>>>>>
>>>>>>multiple access technologies, hence facilitating migration 
>>>>>
>>>>>from one to
>>>>
>>>>>
>>>>>>the other and/or parallel deployments.
>>>>>>
>>>>>>- l2c support over a lightweight transport The working group will 
>>>>>>investigate the possibility of mapping GSMP over a lighter 
>>>>>
>>>>>transport 
>>>>>
>>>>>
>>>>>>such as IP or UDP.
>>>>>>
>>>>>>Goals and Milestones:
>>>>>>
>>>>>>April 2006	Document l2c Framework and Requirements 
>(based on DSL
>>>>>>Forum work)
>>>>>>May 2006	Initial WG Internet-Draft defining the subset of the
>>>>>>GSMPv3
>>>>>>protocol and extensions to achieve Topology Discovery, 
>OAM and Line 
>>>>>>Configuration in a DSL environment
>>>>>>August 2006	Submit the l2c Framework and 
>Requirements to IESG for 
>>>>>>Proposed Standard
>>>>>>September 2006	Submit the GSMPv3 extensions to achieve Topology
>>>>>
>>>>>>Discovery, OAM and Line Configuration in a DSL environment 
>>>>>
>>>>>to IESG for
>>>>>
>>>>>
>>>>>
>>>>>>Proposed Standard
>>>>>>December 2006	Define GSMPv3 extensions for the mapping over a 
>>>>>>lightweight transport mechanism
>>>>>>February 2007	Submit the extensions of GSMPv3 to 
>>>>>
>>>>>achieve Topology 
>>>>>
>>>>>
>>>>>>Discovery and Line Configuration in a DSL environment to IESG for 
>>>>>>Draft Standard
>>>>>>March 2007	Define GSMPv3 extensions to achieve 
>Topology Discovery
>>>>>>in a
>>>>>>non-DSL environment (e.g. PON, Wimax)
>>>>>>June 2007	Sumbit the GSMPv3 extensions for the mapping over a 
>>>>>>lightweight transport mechanism to IESG for Proposed Standard
>>>>>>September 2007	Sumit GSMPv3 extensions to achieve Topology
>>>>>
>>>>>Discovery in
>>>>>
>>>>>
>>>>>>a non-DSL environment to IESG for Proposed Standard
>>>>>>September 2007	Re-charter or conclude Working Group
>>>>>>
>>>>>>Internet-Drafts:
>>>>>>GSMP extensions for layer2 control (L2C) - Topology 
>>>>>
>>>>>Discovery and Line
>>>>>
>>>>>
>>>>>
>>>>>>Configuration <draft-wadhwa-gsmp-l2control-configuration-02.txt>
>>>>>>
>>>>>>_______________________________________________
>>>>>>L2cp mailing list
>>>>>>[email-masked]
>>>>>>https://www1.ietf.org/mailman/listinfo/l2cp
>>>>>>
>>>>>
>>>>>--
>>>>>.--------------------------------------------------.
>>>>>| Sven Ooghe                                       |
>>>>>| Access Network Division, CTO                     |
>>>>>| Alcatel                                          |
>>>>>| Francis Wellesplein, 1     Tel : + 32 3 240 4226 |
>>>>>| B-2018 Antwerpen, Belgium  Fax : + 32 3 240 9904 |
>>>>>.--------------------------------------------------.
>>>>>
>>>>>_______________________________________________
>>>>>L2cp mailing list
>>>>>[email-masked]
>>>>>https://www1.ietf.org/mailman/listinfo/l2cp
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>-- 
>>>.--------------------------------------------------.
>>>| Sven Ooghe                                       |
>>>| Access Network Division, CTO                     |
>>>| Alcatel                                          |
>>>| Francis Wellesplein, 1     Tel : + 32 3 240 4226 |
>>>| B-2018 Antwerpen, Belgium  Fax : + 32 3 240 9904 |
>>>.--------------------------------------------------.
>>>
>>>
>>>
>>>_______________________________________________
>>>L2cp mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/l2cp
>>>
>> 
>> 
>> _______________________________________________
>> L2cp mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/l2cp
>> 
>
>-- 
>.--------------------------------------------------.
>| Sven Ooghe                                       |
>| Access Network Division, CTO                     |
>| Alcatel                                          |
>| Francis Wellesplein, 1     Tel : + 32 3 240 4226 |
>| B-2018 Antwerpen, Belgium  Fax : + 32 3 240 9904 |
>.--------------------------------------------------.
>

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

---

From: [email-masked]
Date: Wed, 25 Jan 2006 18:41:06 +0100

Sanjay,

what you're suggesting is to put the known use cases upfront and discuss 
during the meeting if there is agreement on all of those. I think that 
this to some extent is a gamble: it might jeopardize the success of the 
BOF, or at least slow down the process of accepting the other use cases.

Having said that, I do think that "line configuration" will not be that 
difficult to agree upon beyond the original "L2CP core team", so adding 
that to the draft charter would probably be ok. But I'm less sure on the 
"transactional multicast" use case. There has been significant 
discussion on this subject at the DSL Forum and I think that there are a 
number of operators that may have other ideas in the context of Ethernet 
aggregation.

I think the best thing to do is derisk these items on this list prior to 
the BOF. If it becomes clear that the above gets acceptance of people 
beyond the original "L2CP core team", then adding it to the proposed 
charter would not jeopardize the BOF.

So, perhaps at this point we should start to get some more people 
involved on this exploder...

Regards,
Sven