Subject: [L2CP] Draft WG charter

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Fri, 3 Feb 2006 21:22:34 +0100

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