Subject: re-chartering L2TP

From: Vernon Schryver <[email-masked]>
Date: Tue, 16 Jan 2001 10:52:43 -0700 (MST)

> From: "W. Mark Townsley" <[email-masked]>

> ...
> > > Are you any more clued into the "committee minutia" and such at present?
> > > Are you any less surprised to hear yourself commenting on it now?
> > 
> > That sounds like a misleading statement in the sense that it implies
> > that I did express an opinion on the charter last summer.  I really
> > don't think I did.
>
> This was not a statement, it was a question. Regardless of what you did
> last summer (this sounds like a bad movie already) you were shocked that
> you would have made comment on charter minutia at that time based on
> your admitted lurking position in this group. I am curious as to why now
> is any different than then. You either don't know yourself any better
> now than you did then, or you are paying attention to this group's
> actions more. 

That is an intentionally misleading statement.  I did not express shock
at having previously commented on the charter, but instead politely pointed
out that I had not made such comments.  Moreover, as we all know, "lurking"
does not mean "ignoring," but instead denotes "quietly listening."

If modifications to the charter of the L2TP working group were minor
or required only to complete its work, they would be reasonable and
in my personal view not worth arguing or even talking about.  However,
making the working group a permanent fixture, or more accurately, a
permanently available rubber stamp for proprietary technically bad
ideas are something else.

As far as I can tell, Mr. Townsley has tried to substantially modify the
charter of this working group without obtaining the consensus of mailing
list.  Contrary to his recent statement in another message, a passing
reference to mention of a change in charter in IETF meeting minutes does
not constitute a call for comments on such a change.  I don't think he
meant to do anything bad with the charter and I think he really believes
that the group should last forever to handle tunneling anything over
anything.  I think that would conflict with the charters of other groups,
but even if I'm wrong, it is a substantial enough change to require
consideration by the rest of the IETF.

Where are the words of the new charter, since it is now only proposed
and no longer a fait accompli?

> > > "L2" originally came from L2F, which (From RFC2341) referred to L2 as,
> > > "link layer (i.e., HDLC,
> > > async HDLC, or SLIP frames)."
> > 
> > That is a misleading statement of the history of the working group as I
> > recall it.  The "L2" in the group's name came from the Cisco protocol,
> > not from the reason Cisco named the protocol.  The group was not created
> > to deal with arbitrary L2 packets or protocols, but instead was created
> > to deal with the multi-chassis problem.
>
> The group was created to merge PPTP and L2F. The multi-chassis problem
> was *one* of the motivations for L2F at cisco. The multichassis problem
> certainly was not the widest use of PPTP at the time. 

That is a red herring.  PPTP is still not widely used to handle the 
multichassis problem.

Contrary to Mr. Townsley's implication and to what I recall of his
expressed preferneces over the years, the L2TP group was not chartered to
be a general purpose tunnelling group, handling not only the tunneling of
arbitrary layer 2 packets over IP as in the current issue, but arbitrary
packets over other arbitrary layers.

> > >                       if we have created something that can be built
> > > upon, I see no good reason to start from scratch elsewhere.
> > 
> > Protocols such as the lastest bad idea that has nothing to do with
> > PPP are not building on L2TP.
>
> I think an open mind is a better route to take. That said, I see very
> well crafted arguments in favor of using existing protocols (BCP and PPP
> with L2TP) for the Ethernet over L2TP case. I prefer this type of
> discussion in the group vs. a closed, "we only do PPP, go away if you
> don't like it" approach.

Such "we only do PPP" arguments are appropriate.  IETF working
groups are not supposed to become permanent fiefdoms nor universal
solvents.  They are supposed to do their chartered jobs and finish.

The many years this working group required to approach its chartered
goal and the continuing technically bad ideas such as the current
one are good reasons to disband the working group sooner than later.

Vernon Schryver    [email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 16 Jan 2001 13:20:30 -0700 (MST)

Please note that I did not invent the stealth charter change
complaint.  That the L2TP charter is being changed was pointed out
to me privately by someone who had noticed the passing reference
and thought it at best obscure.

> ...
> Rechartering to include a standard manner for extension of L2TP for
> other transport types very well may extend its life, but does not
> necessarily make it a permanent fixture. There will be no rubber stamps
> in this group.

On the contrary, the reception of the latest bad idea of Ethernet
over IP has been a rubber stamp resisted only by Mr. Carlson's efforts.

I'm sorry to keep saying "bad idea of Ethernet/IP" for the pain that
doubtless causes.  However, it is an unfortunate idea based on a lack of
knowledge of both theoretical and deployed alternatives and of how actual
PPP and L2TP systems work.  That it should not have received the
currency given by the L2TP WG is my intended point.

>                                                    ... If you want to
> talk rubber stamps, let's compare this to an individual submission that
> gets an Informational RFC number with substantially less chance for
> review.

That's a red herring, particularly in view of my excessively repeated 
and longstanding complaints about that problem in forums where such
complaints are less irrelevant than here.

> My goal is to provide a forum for open discussion and technical review
> for items relevant to L2TP. The original and current charter includes:
> "Define and review the definition of any additional IETF AVPs which are
> of interest to the group." So far, the drafts for other L2 types that
> have been accepted into the group have added nothing more than
> additional AVPs to the protocol. No new messages, no change to the state
> machine, no change to the L2TP header, etc. In fact, at the Pittsburgh
> meeting I was adamant about keeping the scope of the work to within this
> range of extension. I believe the meeting synopsis reflects this.

Let's take the next step and start to shut down the WG.

> ...
> That is why the IESG must approve the charter change. It is also why I
> have already discussed this at length with one of our AD. I do not think
> that the IESG will approve anything that will cause undue overlap of
> engineering effort among the various groups. If this work is being done
> elsewhere in the IETF, I will be more than happy to combine forces or
> step aside if it will result in less code for all of us to write, deploy
> and maintain.
> ...

> Check the archive, I posted it just recently.

I've been trying for a while, but have failed to get any packets from
www.ipsec.org, not to mention joy from http://www.ipsec.org/email/l2tp/

> The alternative? No standard for what is now a highly deployed technique
> for access on the Internet (that is, tunneling of PPP). ...

That is an argument for shutting down the L2TP WG, not continuing it.
Anything that is "a highly deployed technique" leaves no room for the IETF
to do more document current practice.  After documenting it, it might be
appropriate to figure out a better replacement, but only after fully
documenting and understanding the status quo.

Instead the L2TP WG is charging off to generate replacements (plural)
without considering that "highly deployed technique."

> In fact, the WG probably stumbled in the past by NOT being more
> open-minded.

We completely disagree.

>              Experience tells me that thinking the WG has the power to
> reduce writing of and deployment of code by telling people to "go away"
> does not reduce the code I ultimately have to write and the number of
> standards I have to support for essentially the same thing.

Experience tells me that a WG has little or no effect on such things.
The IETF and any WG is almost powerless to stop bad ideas.  It's power is
in promoting, not opposing.

> ...
> I think we have spent enough of everyone's time on this thread now. I
> hope that it at least served the purpose for people understanding where
> I am trying to lead this group. Feel free to disagree, but from this
> point on I ask you to take it to the next level rather than waste more
> of our time here.

Given the lack of discussion in the WG mailing list on the de facto new
charter that seems to cover tunneling anything over anything, I
object to your effort to prevent consideration of it.

Ignoring my ranting, so far only those who favor making the L2TP working
group a permanent fixture in charge of all tunnelling in the IETF have
spoken about the de facto charter.

---

From: Wei Luo <[email-masked]>
Date: Wed, 17 Jan 2001 23:11:24 -0800 (PST)

If that's the intent of CEOT, it sounds quite reasonable.  I doubted that
trying to unite any transport over packet oriented network in a single WG
was a realistic thing to do.

---Wei

On Wed, 17 Jan 2001, Danny McPherson wrote:

> 
> And it was explicitly stated in the during the BOF session 
> that the intention was to specify requirement that should 
> be given to the relevant "encapsulation" protocols (e.g., 
> MPLS, L2TP) and the encapsulation protocol-specific work 
> should be conducted in those working groups.
> 
> I believe the CEOT BOF minutes reflect this.
> 
> -danny
> 
> > As for tunneling mechanisms, the BOF charter speaks these as follows:
> > 
> >    The protocols used for tunnel management depend on the type of packet
> >    switch network deployed by the carrier.  For example, LDP or RSVP-TE
> >    may be used to create and manage tunnels across a packet switched
>

---

From: James Carlson <[email-masked]>
Date: Thu, 18 Jan 2001 12:43:42 -0500 (EST)

Danny McPherson writes:
> > MPLS runs over many things, including PPP.  If the circuit emulation
> > protocols are written to run over MPLS, then nothing special needs to
> > be done for L2TP, because CES/MPLS/PPP/L2TP will work.  Again, one
> > mechanism and one specification are better than many.
> 
> One small observation -- this requires that MPLS be 
> deployed ubiquitously throughout the *Internet* (read:
> inter-provider as well).  I assure you, it won't be
> any time soon.  

No, it doesn't necessarily require that at all.  It may require some
mechanisms for tunneling over the non-MPLS portions of the path.  Such
as, for instance, MPLS/PPP/L2TP.  But, then again, it may not.

Who is currently buying CES that crosses provider boundaries?  Why
would we think it's so much more likely to occur with CES over (pick
an IETF protocol)?

I think operational considerations -- such as being able to hold a
single provider to a contracted set of performance parameters -- will
be likely to trump any "ubiquity" argument.  (Besides, the point here
is to displace equipment that happens to carry legacy CES services,
*not* to invent new reasons and ways to carry CES.)

In all of the cases that I know of where real CES is used -- AAL-1
with fancy clock adjustment deltas to carry async timing across the
network -- it's a kludge (such as voice over TDM rather than voice
over IP) that may well disappear in the future.  Finding extended uses
for it seems like a poor optimization.  (Note that frames != circuits,
and tunneling AAL-5 or Frame Relay may be another matter entirely,
although the contractual issues are likely similar.)

> Folks that I see supporting IP-based CES (e.g., ATM, FR & 
> even TDM) can [typically] easily support MPLS-based models.  
> However, folks don't necessarily want solutions that require
> MPLS today.

Can you flesh out the service model that has interprovider CES over IP
as an integral component?  Frankly, I can't say that I've talked to
any carrier that was interested in anything like that, and it's a
little surprising to hear it as a fundamental requirement.  Perhaps I
wasn't paying enough attention during one of those presentations (or
perhaps the answer is proprietary), but I'd still like to know.

-- 
James Carlson, Internet Engineering       <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
Second Edition now available - http://people.ne.mediaone.net/carlson/ppp

---

From: James Carlson <[email-masked]>
Date: Thu, 18 Jan 2001 13:29:48 -0500 (EST)

Danny McPherson writes:
> The problem here is that you're scoping CES to TDM, when 
> my intended representation of the term was meant to encompass
> FR, PPP/cHDLC, ATM, Ethernet/802.n, even MPLS as well.  

Ah, ok.  That's an interesting usage.  I've only used "CES" to mean
ATM Forum af-vtoa-0078.000, "Circuit Emulation Service
Interoperability Specification Version 2.0," or something that
functions in a very similar manner.  That is to say, PDH circuits over
some networking protocol.

For Frame Relay, I suppose you're contemplating something like FRF.5
and FRF.8, and possibly FRF.10.  I think that's doable.  As noted much
further below, I don't know that L2TP is the right home for this, but
the general concept is certainly likely to be a worthwhile thing.
(Consider that by having both MPLS<->ATM mechanical translation and
FRF.8 translation defined, one could imagine a Frame Relay to
MPLS/PPP/L2TP IWF fairly easily.  Anything else will likely have to
deal with the addressing issues from scratch.)

I don't know what you mean by "PPP/cHDLC" (cHDLC?), but I think having
multiple ways of putting PPP over L2TP would be a bad thing for the
many reasons cited earlier.

ATM over L2TP?  I'm not sure what's meant by that.  Something like the
thoroughly dead CIF proposal?  Or something else?  What would be the
need for this?

MPLS and Ethernet, as already noted, already work over L2TP, because
they both run fine over PPP.  New standards for these aren't needed.

> The inter-provider thing was simply an example, more so, 
> consider a network that hasn't or doesn't plan to either 
> deploy MPLS entirely to the edge, or perhaps at all.

I don't happen to think that carriers are too religious about this.  I
don't think they care about pure IP versus IP/MPLS, nor about where
the "edge" boundary is drawn.  What matters is what solves the problem
well and what the vendors (such as Cisco) are selling.  Also, with the
likely practice of bandwidth reselling [leading to interesting
arbitrage situations], MPLS or something very like it *will* go to the
edge of many, if not all, carrier's networks.

> > Perhaps I
> The primary application for IP (or MPLS) CES (C representing either
> TDM or packet-based stuff) is to allow SPs to converge their services
> onto a single core IP or IP/MPLS core network.  The benefits of this 
> are obvious (I believe).

Yes.  However, that doesn't necessarily involve any xES over IP
operation, nor does it say that provider boundaries must be handled,
nor does it say that requiring MPLS as a part of the replacement story
for CES providers is necessarily a bad answer.  MPLS is used in the
core now and is quite likely to spread as its services are needed.

With the new definition of CES to include frame-based stuff, I can see
a definite need to define ways to encapsulate it over IP.  It's not as
immediately obvious to me that L2TP is the absolute right answer, but
it's also not obivous that it's entirely wrong.  (As I think it is for
traditional CES.)

---

From: James Carlson <[email-masked]>
Date: Thu, 18 Jan 2001 15:31:14 -0500 (EST)

Danny McPherson writes:
> > Yes, that's something they would look into.  (I don't think that's the
> > solution, though, since CES includes special cases to forward with
> > partly empty cells in order to minimize delay.  If 47 bytes is
> > sometimes too many, it doesn't bode well for larger amortizations.)
> 
> However, if implementation could realize things such as, for
> example, idle frame suppression or AIS suppression, etc.., 
> there could be great bandwidth savings. 

If you're getting a lot of benefit out of AIS suppression, you've got
some mighty unhappy users.  ;-}

That being said, I mostly agree with your points.  It's a complex
analysis to determine if it works.  (Having tried the statistical gain
argument with more than one bell-person, I'm not wild about trying it
again.  But, hey, I'm fortunately not in that game at this point.)

(For the specific CES case, I don't know if idle suppression buys
anything.  If it's channelized, any one channel active ruins your
day.  If it's unstructured, I suppose you could *guess* at the
upper level protocol used, but what if you're wrong ... ?  Eh, not my
forte anyway.)

> Not to mention it's effecting on grooming in carrier networks,
> and circuit provisioning times, etc...

Grooming becomes, I think, a disaster on IP.  Unless you do some
really unnatural things to your IGP, you end up with no grooming
capability at all.  (Ross Callon has said, in what I interpret as a
Fermat's-last-theorem sort of way [proof too large for this tiny
margin], that TE with datagram routing only and no explicit routing is
doable.  Such things are possible, but they make my lesser brain
spin.)

In contrast, MPLS is perfect for TE applications and grooming.  In
fact, it's even better than ATM, since MPLS allows arbitrary label
stacking, but ATM's "labels" (VPI and VCI) are fixed at two deep.  You
can arrange to push labels to represent groomed chucks of traffic and
engineer them as needed across your network.

(Which likely plays into why the carrier's I've talked to are so
unimpressed with statistical gain.)

---

From: James Carlson <[email-masked]>
Date: Thu, 18 Jan 2001 16:07:42 -0500 (EST)

Danny McPherson writes:
> Yeah, I didn't mean to include that over L2TP, though folks 
> support PPP (and cHDLC - the Cisco variant) over MPLS with 
> the same general model (see the kompella or martini l2vpn 
> drafts).  You're right in that L2TP wouldn't require any work 
> for PPP.

Ah, ok.  Cisco HDLC over L2TP makes some sense to me, in the same way
that SLIP and ARAP over L2TP make sense to me.  Assuming someone wants
to support these old protocols, these are additions I'd certainly
support.  They're obviously in the spirit (if not letter) of the L2TP
charter.

> To get rid of an ATM core network.  I beleive Kireeti does a 
> nice job of providing introductory text explaining "Why?" in
> the first part of his MPLS l2vpn draft.  It could either call 
> for raw cell transport or AAL5 PDUs.

Most of the document deals with the transport of frames and reads like
an IWF proposal.  To that extent, I think it does the job right.

The cell portion is only three sentences in section 5.4.  I as good
about that as I do about CIF.  (Time will tell and perhaps I'm wrong,
but this seems likely to me to be far too little specification to
satisfy the folks who would want to use such a service.)

>  Then general model this
> would be accomplished in L2TP is similar to those defined in
> (again) the kompella and martini MPLS l2vpn drafts.  I hope
> to make the L2TP drafts available RSN.

As I remarked before, I don't see the direction from a CES-related
working group.  If one is starting, shouldn't we take the requirements
from them, rather than bubbling up requirements from the bottom?

In other words, since most of the interesting hard parts are in CES
rather than in the CES<->L2TP mapping, don't those drafts belong in a
CES working group rather than in L2TP?

> Though it won't be inter-provider anytime soon and folks that 
> want to offer multi-services (IP, FR, ATM, Etc..) nationally or 
> internationally and are tier-2 (or don't own their own transport 
> networks) can realize some very compelling savings when using 
> standard IP transport services, rather than a number of 'pipes"
> for each service.

Hmm.  OK, assuming that nested model works for these non-IP services,
I'll agree that Frame Relay over some kind of IP tunnel is a useful
thing.  As I said before, I don't see that L2TP is *the* right way to
do this, but I'm certainly not as adamant in opposition as to EoL2TP.

> There are advantages for TDM over packet-based networks as well,
> though this is obviously even more challenging.  Jim Boyle's STS
> ES draft hints at this, and there are lots of vendors that are
> beginning to suport proprietary solutions.  And these solutions 
> employ IP, MPLS, or both, for transport, and often require things
> like jitter buffers on linecards for reordering and/or replay,
> etc..  

It depends on the application.  If the application happens to be just
data, this shouldn't be too bad.  A little latency isn't too awful.
Voice folks get really nervous about delay really quickly, because it
makes the service awkward to use and wrecks silly things like FAX
(G.114 again).  Voice coders have a lot of delay and tend to squeeze
the margins awfully low.  (After allowing for 5us/mile.)

> There are more providers (tier-*) that haven't deployed MPLS 
> today (at all) than have, I assure you.  As such, I'm not sure
> what "core" you're referring to.

Worldcom/UUnet, for one.  I agree that it's early in the deployment
phase, but (unlike, say, IPv6) it's an easy sell for most tier-1s and
I've yet to talk to one that hasn't talked seriously about deploying
MPLS.  (Cisco's influence is noticable here.)

I just fear we're headed toward a profusion of drafts that ends in
*-over-* (which would be a good April 1st RFC).

---

From: "Mark Jeffrey" <[email-masked]>
Date: Fri, 19 Jan 2001 05:52:24 -0800

I'm concerned that the real QoS requirements of carrying a circuit (E.g.
a European E1 2Mbit/s PDH) are not well understood by everyone here.
There are strong requirements, not only for low latency (to deal with
the familiar echo problems / avoid expensive echo cancellation
requirements), but because the equipment attached to the circuit (e.g. a
PBX) expects the E1 to behave within spec. If there is any significant
jitter in the delay, PDH frame slips will occur. Enough of these (not
very many) and the PBX will take the line out of service as faulty.

QoS has to be solved in every layer underlying MPLS or you can't deliver
it to the circuit. If you don't build the network for QoS control from
the bottom up (as ATM did), you can't add it on the top as an extra.

My 2c.

Mark Jeffrey
Senior Consultant / Network Architect
Microsoft Consulting Services
EMEA Telecom Practice
Tel: (+44) 118 909 3787
Fax: (+44) 118 909 6761
mailto:[email-masked]
http://www.microsoft.com/UK/ 

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]]
> Sent: 18 January 2001 17:44
> To: [email-masked]
> Cc: W. Mark Townsley; Wei Luo; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: re-chartering L2TP 
> 
> 
> Danny McPherson writes:
> Second Edition now available - 
http://people.ne.mediaone.net/carlson/ppp