Subject: Re: re-chartering L2TP

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

Just FYI: there does seem to have some kind of overlapping between the
newly proposed L2TP charter and CEOT charter description.

http://www.ietf.org/ietf/00dec/ceot-agenda.txt

---Wei

On Tue, 16 Jan 2001, Danny McPherson wrote:

> 
> > I think that we should be held more accountable for our work items, and
> > we should have to justify adding "duplicate" work.
> 
> Note that the only 'questionable duplication' is that of 
> EoL2TP versus L2TP/PPP/BCP.  Even Mark's agreed that this 
> is indeed questionable, and as such, the associated merits 
> are still being debated on the mailing list.  The EoL2TP
> draft was merged with my original L2TP ES draft in order
> to provide a common model for other payload types in L2TP,
> hence the birth of the Service Type AVP.  
> 
> Other work along these lines that employs the Service Type 
> (e.g., FR & ATM over L2TP) are not being duplicated (with 
> IP-based tunneling -- to my knowledge).  
> 
> I guess part of the misunderstanding here lies on my 
> shoulders, as I've promised to make the related I-Ds 
> available by now, and have yet to do so.  I've ran them 
> by some folks already, though I haven't officially posted 
> them as of yet, and their availability is perhaps 
> germane to this discussion.
> 
> 
> -danny
>

---

From: James Carlson <[email-masked]>
Date: Thu, 18 Jan 2001 06:32:55 -0500 (EST)

W. Mark Townsley writes:
> My personal view is that if the IETF decides to take on circuit
> emulation, the new WG should operate in a transport agnostic manner to
> identify requirements for emulation of various circuit types over any
> given packet network (the most obvious examples of which are IP and
> MPLS). These requirements should feed into various working groups (such
> as mpls, l2tpext, diffserv, rsvp, etc.) to provide the necessary
> modifications to existing protocols to best meet the requirements.

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.

(Running CES over MPLS makes a lot of sense.  MPLS is efficient and
scalable enough to displace ATM as a core protocol, and translating
current CES services into an IETF standard is one of the few remaining
barriers to eliminating ATM.)

-- 
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:02:01 -0500 (EST)

W. Mark Townsley writes:
> By the same token, MPLS runs over IP.

(I assume you mean that IP can over MPLS.  MPLS, as far as I know,
can't run directly over IP.)

> So if CES is defined for IP
> (perhaps via L2TP) then CES/L2TP/IP/MPLS will work.

I don't know if that's doable.  CES on ATM incurs one octet of
overhead (for timing adjustment information) in each 48 octet cell.
Running the same cells over L2TP/IP/MPLS will incur (at least) 10
(L2TP without length, but with Ns/Nr) + 8 (UDP) + 20 (IP) + 4 (one
MPLS shim header) = 42 octets of overhead for every 47 (nominal)
octets of data.  Increasing the packet size will increase the
buffering requirements at the endpoints and the resulting link latency
(which is strictly controlled for telephony applications; see G.114).

If it's a tiny proportion of the overall traffic (which is not an
unfair assumption for future applications), 89%+ overhead might not
matter.  For some carriers, it might rule out the application
entirely.

> Also, for CES/MPLS/PPP/L2TP/IP work would have to be done to translate
> QoS parameters from MPLS down to the tunneled IP later. We're not done
> just because the layers stack up. Same with above, though a great deal
> of work has already been done to perform traffic engineering of IP/MPLS.

I agree the QoS issues get very interesting, but I disagree that this
is significantly different from the trouble of getting *any* kind of
PPP QoS over L2TP/IP.  That's a mechanism that needs to exist in L2TP
independently of what protocol(s) a tunneled PPP session is carrying,
and regardless of anything that CES and MPLS might do.

MPLS over PPP over regular wires *does* work for both TE and QoS,
because the mechanisms are obvious enough.  If L2TP/IP can provide the
right features, MPLS/PPP/L2TP/IP is no harder to get right.

Similarly, if for CES/L2TP/IP you assume into existence some
communication between CES and L2TP to demand the right QoS for the
link and then again between L2TP and IP, then that same mechanism will
work for MPLS/PPP/L2TP/IP.

In other words, it's the same work either way.  The only difference is
in how the layers stack up, and what the resulting (in)efficiencies
imply.

---

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

W. Mark Townsley writes:
> You bring up a good point, but to say that because of this problem CES
> over IP is intractable is a bit harsh.

Perhaps.  That's why I wrote "might rule out" rather than "would rule
out."  It would be a complex cost/benefit calculation for any carrier.
(But, then, they're good at that sort of thing.)

> I imagine you can do some kind of
> cell reassembly to combat the cell tax problem that you mention, but I
> am not up on all of the details here. These are the type of requirements
> that CEOT could document.

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

> We are talking 
> CES QoS mapped to L2TP/IP and then to MPLS vs.
> CES QoS mapped to MPLS and then to PPP/L2TP/IP ... which then very well
> may be run over MPLS in parts of the core.

Not exactly.  For IP-only parts of the network, we're talking
CES/MPLS/PPP/L2TP/IP.  For MPLS parts of the network, a simple IWF
should be able to reduce this stack on tunnel entry into CES/MPLS
(with, perhaps, an extra label pushed to represent the tunnel, if
necessary).  (Labels are like indirection.  One more level always
fixes all the problems.  ;-})

> This is certainly an intriguing thought. But, I don't think we can
> overlook that this does require MPLS in at least one point, if not two,
> in your stack. I am not sure I understand why, after all the work the
> IETF has done to build a ubiquitos and interoperable IP network, it
> would require that MPLS exist for all CES scenerios. Talk about charter
> creep...

I'm suggesting that we optimize only those things that are in need of
optimization and ignore the others.  ATM is entrenched in the core not
because it's good for IP and not necessarily for the QoS pixie dust,
but because it makes a dandy Frame Relay transport (using FRF.8 IWF)
and can carry legacy point-to-point circuits with CES, and
(secondarily) because its VPs can be traffic-engineered where needed.
To remove ATM, we must supply something that does approximately as
well on those legacy supports.

The issue is in the "approximately" part.  Perhaps CES on L2TP, as
heavy as it may be, is light enough to do the job with 50% of the
effective bandwidth wasted.  Perhaps not.  Perhaps the lack of TE on
IP isn't a barrier.  That's certainly not a job for this group to
determine, and I hope some other group does consider it carefully.

Thus, we have the situation that we're putting the cart before the
horse.  We don't know that we need this transport mechanism because
the necessary engineering (protocol design and network design) haven't
been done.

Should we expand the L2TP charter to include transport of CES just on
spec or should we wait for the real thing?

> We could continue to take this argument to its extreme as well. Get rid
> of IPCP, IPXCP, BCP, etc. and carry it all over MPLS/PPP and then L2TP
> if need be. MPLSCP becomes the only NCP you need for PPP.

Actually, of course, that's not quite true.  You still need IP in
parallel in order to do MPLS signaling.  MPLS static configuration is
possible, and perhaps even likely in engineered CES applications, but
otherwise not practically so.

As for the others, they have at least the advantage of primacy -- they
were there before MPLS.

There are also practical matters.  Unlike PPP, which is fairly simple
and involves only the two peers, MPLS signaling is non-trivial and
relies on a far more complex suite of protocols, including internal
SPF trees derived from IGP (OSPF or IS-IS) calculations, and the
infamous LDP/RSVP duo.  And, of course, MPLS implies forwarding based
on labels and label stack manipulation.  I don't think it's
unreasonable to argue that running MPLS for the mere sake of
supporting (say) IPX is too much burden, but that running PPP for the
sake of supporting BCP is not.

(On the other hand, if it were helpful, stealing well-known label
values to transport unsupported network protocols over individual PPP
links would be an amusing hack.  :-/  No, please, don't run out and do
this!)

Note, also, that one could choose to run UDP over IP over IP over
Ethernet all the time just to be perverse.  I don't think arbitrary
stackings need to be considered.

> Or, simply
> carry PPP over MPLS to handle the "MP" part of label switching. Then all
> we need to define is ATMCP, FRCP, etc. for each circuit type. We could
> stack layers in a number of ways. I agree that each time we define a
> fork, we should have very good reason to do so as we multiply the number
> of interfaces that we have to support between layers.

Where the layers work naturally without having to create new
specifications, it's probably not bad that the protocols are as
promiscuous as they are.  We probably should think long and hard
before adding yet another stacking combination, though.

> I'm not sure it is precisely the same work either way, but with regard
> to layer stacking I very much agree with you here. 

I was referring to the QoS interface issue.  In your example case, you
need to have (conceptually, at least) CES ask L2TP for a contract,
which asks UDP/IP, which then asks MPLS or some other link layer.  In
my example case, I need to have CES ask MPLS for a contract, which
asks PPP, which asks L2TP, which asks UDP/IP, and the link layer.

QoS interfaces for MPLS are defined (RSVP), and the interaction with
PPP (for non-L2TP systems) is already in place.  Further, PPP already
needs a way to request QoS from L2TP (as it might for any physical
layer), and this need is independent of MPLS.  So, then the work
required is to get QoS parameters in and out of L2TP, which happens to
be the same work needed in your example case, and the work is stuff
that's already needed.

I call that a wash, at least on the QoS front.

The other work is the CES over ? work.  I believe, based on the Kill
ATM argument, the really burning need is for CES over MPLS, not for
CES over L2TP.  Thus, the best leverage is to do CES over MPLS first,
and then either tunnel or reuse for L2TP.  The alternative would
appear to be to do the work twice -- once for MPLS and again for L2TP.
(But, again, this isn't the L2TP wg's issue.)