Subject: RE: [L2CP] Draft WG charter

From: "Sanjay Wadhwa" <[email-masked]>
Date: Fri, 3 Feb 2006 17:13:04 -0500

Hi Woj
 As part of defining the charter we are outlining problems that we
intend to solve with L2C. The use cases mentioned are reasonable. It is
expected that the "requiements" document will consider various
dimensions of the protocol e.g. scalability, reliability,
configurability, latency, convergence etc.
I don't think that the charter should explicitly list and single out a
possible mechanism/solution to satisfy one or more of these
requirements. It seems "light weight transport" falls under the category
of a solution. There could be other mechanisms (e.g. "L2C proxy") that
can satisfy one or more requirements e.g. scalability. Instead of
explicitly calling each one out as seperate work item in the charter,
why don't we just add a line to indicate that "mechanisms to make
protocol robust, reliable and scalable" are in scope. 
Operational experience with real world deployments will help decide some
of these mechanisms. On the other hand, we might want to explicitly call
out well known considerations e.g. "graceful restart" and MIBs that are
relevant to any control protocol, and in all likelyhood will have to
done for L2C.

Thanks
-Sanjay 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Wojciech Dec (wdec)
>Sent: Friday, February 03, 2006 3:23 PM
>To: [email-masked]
>Cc: Sven Ooghe
>Subject: [L2CP] Draft WG charter
>
>
>Hi All,
>
>Here's a re-worked version of the draft charter based on Sven's initial
>draft and the numerous opinions voice on the alias. I also post some of
>the comments I have and have collected from various sources that
>resulted in a change to the initial draft. Feedback is more than
>welcome.
>
>I would like to submit this charter as a draft to the ADs 
>along with the
>agenda I sent out earlier today. We can tidy up the charter if 
>needed as
>the date of the BOF approaches.
>
>My impression is that the charter has to contain a well formulated
>problem statement and a realistic timeline of delivery.  I sense that
>adding statements like "analyzing additional use cases" would appear to
>propose an open-ended charter and an indefinite time-line. 
>Importantly, we should also explain WHY we need a WG, not solely
>assuming that we have a WG and show WHEN will we be doing WHAT.
>Quoting from the BOF best practices doc. A successful BOF is able to
>show that:
>    - there is a problem that needs solving, and the IETF is the right
>      group to attempt solving it.
>    - there is a critical mass of participants willing to work on the
>      problem (e.g., write drafts, review drafts, etc.)
>    - the scope of the problem is well defined and understood, that is,
>      people generally understand what the WG will work on (and what
>      not) and what its actual deliverables will be
>    - there is agreement that the specific deliverables (i.e., proposed
>      documents) are the right set
>    - it is believed that the WG has a reasonable probability of having
>      success (i.e., in completing the deliverables in its charter in a
>      timely fashion)
>
>As to the WHAT the WG will be doing, when given a transport 
>protocol one
>could re-invent everything to ride on it - we should be clear that the
>WG is not trying to do this. We should rather identify the 
>problem space
>that L2CP tries to address and focus the WG efforts on defining the
>protocol mechanisms/extensions that offer solutions. It's of quite some
>importance to get multiple SPs input on the problem areas rather than
>mainly from vendors. These areas could well be:
>- Simplification of large scale access edge provisioning.
>- Transmission of access line information and status to nodes requiring
>such info.
>- Transport of RPCs and result messages for access line OAM functions
>between a subscriber management point and access node.
>
>I would thus suggest that the use-cases, or rather examples of problems
>in each of the areas above space, be fleshed out - PD21 is probably the
>place where this has been done so far. The WG then needs to define the
>protocol extensions and encoding schemas for accomplishing the
>use-cases. 
>
>Some more general items that the WG should cover are:
>- L2CP MIBs
>- Alternative light weight L2CP transport protocol. 
>
>Given all of the above, here's the new draft. 
>
>
>Layer 2 Control (l2c)
>=====================
>
>Current Status: Non-existing Working Group
>
>Chair(s):
>TBD <tbd>
>TBD <tbd>
>
>Operations and Management Area Director(s):
>Bert Wijnen <[email-masked]>
>David Kessens [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 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 DSL Access Nodes and
>Broadband Network Gateways. The rationale for introducing such 
>a Layer 2
>control protocol has been analyzed in DSL Forum Proposed Draft 
>PD-021v2,
>which was liaised to the IETF in December 2005, and sent to the IETF
>GSMP discussion list in November 2004. A number of use cases have been
>identified that are now progressing as an official DSL Forum working
>text item. These use cases require thus specific protocol design and
>extensions. 
>The DSL Forum work recommends using General Switch Management Protocol
>(GSMPv3) as a base protocol for Layer 2 control messages. This working
>group will be 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.
>
>The goal of a Layer 2 control protocol message exchange is to convey
>status and control information from access devices to one or more other
>devices that require the information for executing local functions. An
>example of this is the transmission of an access loop rate 
>from the edge
>access node to a Broadband Network gateway device tasked with shaping
>traffic to that rate. Another goal of a Layer 2 control 
>protocol message
>exchange is to trigger a local action on access devices. An example of
>this being the initiation of a local port testing mechanism.
>The protocol will ensure the transmission of the information does not
>need to go through distinct element managers but rather using 
>the direct
>device-device control protocol defined. This direct transmission method
>is intended to offer the possibility of effecting quicker functional
>changes in response to dynamic events.
>
>Efforts of the WG will focus on addressing the following problem areas:
>- Transmission of access line control and status information to network
>elements tasked with coordinating policy decision and enforcement
>- Reduction, through the use of the protocol, of multiple points of
>access edge network element provisioning.
>- Transmission of control RPCs and result messages for access node OAM
>functions.
>
>The protocol will address the information transmission requirements of
>the following use-cases:
>
>- 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 
>Broadband Network gateway gains knowledge of the topology of the access
>network, in particular the edge access-loop characteristics e.g. DSL
>sync Rate. The l2 control protocol is intended to convey this
>information. 
>
>- Line Configuration
>Following dynamic line identification (subscriber local loop) as
>assisted by the mechanism described in the topology discovery case, the
>Broadband Network Gateway could then query a subscriber management OSS
>system (e.g. RADIUS server to retrieve subscriber service profiles
>relating to the subscriber line. Using an the L2 control protocol could
>simplify the OSS infrastructure for service management, allowing to
>fully centralize subscriber-related service data (e.g. RADIUS server
>back-end) and avoiding complex cross-organization B2B interactions.
>
>- 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 a
>remote procedure for the OAM mechanism used on the local loop.
>
>
>The working group will set itself the goal for defining a light-weight
>IP transport mechanism for GSMP based L2 control messages and result in
>an appropriate RFC.
>
>The L2CP WG is open to receiving new work items, whenever it is
>considered appropriate to be homed in the L2CP WG. Such drafts will be
>matured in conjunction with the L2CP base documents.
>
>
>
>Goals and Milestones:
>
>April 2006	 Document l2c Framework and Requirements (based on DSL
>Forum work) 
>
>May 2006	 First WG I-D on defining 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
>publication as RFC 
>
>September 2006	 Submit the GSMPv3 protocol and extensions to achieve
>Topology Discovery, OAM and Line Configuration in a DSL environment to
>IESG for publication as Proposed Standard 
>
>December 2006	 First WG I-D on GSMPv3 protocol extensions for mapping
>over a lightweight transport mechanism 
>
>December 2006	 Submit the GSMPv3 protocol and extensions to achieve
>Topology Discovery, OAM and Line Configuration in a DSL environment to
>IESG for publication as Draft Standard 
>
>March 2007	 Submit the GSMPv3 protocol extensions for mapping over
>a lightweight transport mechanism to IESG for publication as Proposed
>Standard 
>
>June 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>
>
>
>Regards,
>Woj.
>
>_______________________________________________
>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: "Peter Arberg" <[email-masked]>
Date: Sat, 4 Feb 2006 01:26:41 +0100

Hi Woj,

good work finalizing on the agenda and the draft charter.

I do not think it harms to talk about the lightweight protocol, but
I do agree with Sanjay that the last section could be left more open
to alternate solutions.

Section as it stands in draft charter:
---
The working group will set itself the goal for defining a light-weight
IP transport mechanism for GSMP based L2 control messages and result in
an appropriate RFC.
---

Maybe we could say something like:
---
The working group will set itself the goal to investigate and define
a solution for the IP based Layer 2 control protocol which is robust, 
reliable and scalable. This work will result in the appropriate RFCs
for 
 - a light-weight IP transport mechanism for GSMP based L2 control 
   messages or other suited scalability solutions.
 - a graceful restart capability to the Layer 2 control protocol.
---

cheers,
Peter

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sanjay Wadhwa
> Sent: 3. februar 2006 23:13
> To: Wojciech Dec (wdec); [email-masked]
> Cc: Sven Ooghe
> Subject: RE: [L2CP] Draft WG charter
> 
> Hi Woj