Subject: Proposed new l2tpext charter

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 28 Feb 2001 17:27:21 -0500

Apologies for the time it has taken to put this together.

I have been working with the area directors and members of some of the
new "sub-IP" working groups to come up with a descriptive and definitive
charter that best represents the current role of L2TP. I believe this to
best represent where L2TP is headed now. L2TP has already been embraced,
extended and is currently being deployed for more than just tunneling of
PPP today. We can either try to work together on this as a group, or
allow it to happen in a fragmented fashion without our experience to
draw upon. 

Note that this presumes the existence of PWOT, one of the new "sub-IP"
WGs currently being chartered within the General Area of the IETF. The
plan is for L2TPEXT, PWOT and other WGs such as PPVPN, MPLS, etc. to
work in a coordinated fashion.

I also included the task of splitting RFC2661 into separate L2TP and PPP
over L2TP documents here. This was suggested at the last L2TPEXT meeting
and reflected in the minutes posted to this list. Regardless of whether
or not L2TP ever tunnels anything other than PPP in a standards track
document, this exercise has merit based on modularity alone.

Comments welcome,

- Mark

------------------------------------------------------------------

This group is responsible for extensions to the Layer 2 Tunneling
Protocol. 

L2TP, as defined in RFC2661, is a product of the PPP Extensions working
group. RFC2661 defines:

- An extensible signaling protocol for dynamic setup, maintenance, and
teardown of multiple layer 2 packet steams between two logical
endpoints.

- An encapsulation method for sending tunneled PPP frames between each
endpoint.

- The necessary signaling of parameters between endpoints to permit
frames to be tunneled with as much transparency to each PPP peer as
possible.

- The base encapsulation method for sending L2TP control and data
packets over IP (further documents from this working group have or will
define sending L2TP control and data packets directly over ATM and Frame
Relay networks as well).

- A basic shared secret challenge/handshake authentication method
between tunnel endpoints.

L2TP establishes a virtual point to point link which PPP may send
packets over. Thus, L2TP is principally a tunneling mechanism for any
protocol type that PPP will support over a traditional WAN link,
including IP (RFC 1332), IPX (RFC 1552), and other increasingly obscure
protocols such as Banyan Vines (RFC 1763) or DECnet Phase IV (RFC 1762).
PPP also defines the ability to bridge layer two protocols, such as
Ethernet frames via BCP (RFC 2878) or NBFCP (RFC 2097). 

As much as possible, L2TP will attempt to look like just another point
to point link to PPP and thereby take advantage of the work done for any
protocol over a traditional PPP WAN link. It should be noted, however,
that the ability to dynamically establish a PPP connection between any
two IP connected endpoints brings new applications and challenges of
scale to existing PPP implementations and protocol definitions that must
be considered. 

L2TP has attracted considerable attention beyond its initial application
as a dial-centric protocol for extending PPP sessions across a packet
network. As its name implies, other layer two protocols may be
transported in a similar fashion as PPP sessions are via extensions to
control messages already defined in RFC2661. As such, this group will be
responsible for publishing extensions to L2TP for tunneling of other
protocols, including circuit oriented protocols such as ATM and Frame
Relay or bridging applications such as tunneling of Ethernet frames. The
scope of this work will be limited to that necessary to provide a
tunneling transport mechanism based upon L2TP only. This group will not
define requirements for circuit transparency or translation across a
packet network (e.g. real-time clock synchronization methods).
Specifically, it will not replicate the work within the PWOT Working
Group. 

As mentioned above, L2TP as defined in RFC2661 alone is a tunneling
mechanism for a variety of protocol types via the multiprotocol support
present in PPP. When evaluating new protocols for L2TP to tunnel
natively, if an existing PPP-based mechanism already exists which could
be utilized for the same end result, the working group will evaluate the
application and make recommendations as to whether existing protocols
are suitable or extension to L2TP is necessary. For instance, layer two
Ethernet frames may be tunneled directly over L2TP via extension to L2TP
itself, or indirectly without explicit extension of L2TP via tunneling
of PPP frames with BCP (RFC 2878). 

RFC2661 bundles data transport, protocol signaling, and PPP emulation
methods into a single document. This working group will separate RFC2661
into stand-alone documents for greater modularity. At a minimum, this
will consist of a base L2TP document defining common tunneling
constructs, and a PPP document defining the use of these constructs for
tunneling of PPP sessions as defined in RFC2661.

Continued coordination with the PPPEXT Working Group, and coordination
with the PWOT, PPVPN and other "sub-IP" groups will be ensured.

In addition to its broader scope, L2TP Extensions has ongoing work to
complete from its inception as a tunneling protocol for PPP only. While
RFC2661 will be ultimately be obsoleted by a new L2TP base specification
and companion PPP over L2TP specification, documents based on RFC2661
which do not require this new degree of modularity may still be
published in the near term.

Milestones: TBD