Subject: Last call for proposed l2tpext charter

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 27 Mar 2001 14:21:39 -0500

Below is the currenty proposed l2tpext charter, first posted to this
list on Feb 28th. I made a few modifications since then, but overall it
is identical. 

As requested in MN, I am asking the working group for a brief last call
to be sure that there a final chance for review and comment. If there is
no objection, I would like to make this a one week last call, in hopes
of including it on the IESG agenda for the next meeting on Thursday,
April 5, and then on the ballot for the following meeting on April 19
(ADs, please correct me if I am wrong about the dates).

Thanks, 

- 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 tunneled PPP frames between each endpoint.
This includes multiplexing of multiple, discrete, PPP sessions 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 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 PWE3 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 standards 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 PWE3, 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 made obsolete 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 will still
be published in the near term.

Milestones: TBD

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 27 Mar 2001 18:31:04 -0800

> (ADs, please correct me if I am wrong about the dates).

I don't think it's really necessary to denigrate Vines or DECnet here.  How
about "Thus, L2TP is principally a tunneling mechanism for any protocol type
that PPP will support over a traditional WAN link, including IP (RFC 1332)
and IPX (RFC 1552)."

> will not replicate the work within the PWE3 Working Group.

Are they _really_ going to call it PWE3?  A new level of geek has arrived...

> be published in the near term.

How about "that do not require this degree of modularity will continue to be
published in the near term." (reads better, more future-proof)?  Aside from
these nits, looks reasonable to me.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 28 Mar 2001 00:05:45 -0500

Comments fine with me. 

Thanks,

- Mark