Subject: Re: re-chartering L2TP

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).

-- 
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: Danny McPherson <[email-masked]>
Date: Thu, 18 Jan 2001 13:04:32 -0700

> 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?

for raw cell transport or AAL5 PDUs.  Then general model 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.

I don't have strong feelings for this either way.  Based on
the work we've done interally, we opted to strip PPP per as
Rene suggested, 10s or 100s of thousands of sessions and you
will notice a difference.  (though I'm not intending to open
another rathole on this distribution).

> 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.

> 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.)

Agreed.

-danny