Subject: Re: re-chartering L2TP

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

First, this is a BOF charter, not a WG charter. As far as I know, the
actual WG charter is still being discussed.

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
   network based on MPLS.

   New protocols or modifications to existing protocols are required to
   coordinate service-specific information between edge devices.  More
   than one protocol may prove viable for coordinating service-specific
   information.  For example, BGP or LDP may be modified for this
   purpose.

The work within L2TPEXT would fall under "modifications to existing
protocols" if CEOT were to adopt circuit emulation over IP and wished to
use an existing tunneling mechanism. I suspect CEOT would want to work
with the various working groups on modifications to existing protocols
rather than operate in a vacuum.

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. If
any new protocols need to be developed for which there is no existing
WG, they should be done so within the circuit emulation group, or
(preferably) within a new WG with a charter to develop that particular
protocol.

- Mark

Wei Luo wrote:
> 
> 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:
> 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: "W. Mark Townsley" <[email-masked]>
Date: Thu, 18 Jan 2001 14:03:47 -0500

James Carlson wrote:
> 
> 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.)

Yes, that is what I meant. I am traveling and was just waking up when I
wrote that :-)

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

You bring up a good point, but to say that because of this problem CES
over IP is intractable is a bit harsh. 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.

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

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.

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

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

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

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

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.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 18 Jan 2001 11:16:33 -0500

By the same token, MPLS runs over IP. So if CES is defined for IP
(perhaps via L2TP) then CES/L2TP/IP/MPLS will work.

---

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

---

From: Xing Chen <[email-masked]>
Date: Fri, 19 Jan 2001 15:33:12 -0600

> Yes, that is what I meant. I am traveling and was just waking up when I

Anything could happen :-)
Actually, there was an i-d proposing MPLS over IP directly. Please
see ftp://www.ietf.org/internet-drafts/draft-worster-mpls-in-ip-02.txt

Regards,
--                           ___
Xing                         \ /
(Chen)                        v
===========================================================
Xing Chen
NSGAP, Alcatel USA; 972-519-4142; [email-masked]
===========================================================

---

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

W. Mark Townsley writes:
> 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

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

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

> would require that MPLS exist for all CES scenerios. Talk about charter

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?

> 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

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.

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

---

From: Shane Amante <[email-masked]>
Date: Thu, 25 Jan 2001 23:06:59 -0700

i've been watching this thread from the sidelines for a while and
finally feel compelled to inject a service provider's perspective ...

On Thu, Jan 18, 2001 at 02:56:56PM -0500, James Carlson wrote:
> which asks UDP/IP, which then asks MPLS or some other link layer.

CES -> L2TP -> UDP/IP (-> optionally MPLS)

ok, so i have to manage three, perhaps four (if you count MPLS at the
very bottom of the stack), layers here to deploy CES over a
packet-switched network.

> In

CES -> MPLS -> PPP -> L2TP -> UDP/IP (-> optionally MPLS)

in this case i would have to manage five, perhaps six (if you count
MPLS again), layers to deploy CES over the _same_ packet-switched
network.  it seems pretty clear this is *double* the overhead.  even
if i dismiss the fact that i'm carrying all that extraneous
encapsulation overhead around on my network, have you ever considered
the signalling complexity?

in this case, i'd have to manage a signalling layer for: CES, MPLS
(perhaps twice), PPP, L2TP and IP.  it's hard enough to get *IP* (just
by itself) to work reasonably well in some svc provider's networks!
now, you're asking to add in MPLS (maybe twice) and PPP on top of
that?  why?  keep in mind, i'm all for re-using existing
protocols/mechanisms where feasible, but in this case i don't see any
advantages to doing so unless the only end-goal is time-to-market
... and, even then it's questionable.

just my $0.02,