Subject: Re: re-chartering L2TP

From: Danny McPherson <[email-masked]>
Date: Thu, 18 Jan 2001 10:54:52 -0700

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

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.  

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.

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

If CES includes packet-based stuff, absolutely.  And just 
because you not talked to any carrier that was interested 
in anything like that certainly doesn't preclude it.

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

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

-danny

---

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

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

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

> onto a single core IP or IP/MPLS core network.  The benefits of this 

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

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