The MPLS WG Archive

[Kireeti Kompella <kireeti@juniper.net>]

Hi Andy,

> Given that there is little application difference between your draft and 
> draft-martini-l2circuit-trans-mpls-03.txt, I'm curious why you didn't just 
> build upon it rather than start from scratch.  Certainly draft-martini-... 
> didn't go as far as you did regarding on the procedures for building sets 
> of L2 connections into VPNs, but it has much more detail on the basics, 
> including encapsulation, label stacking, and LDP/RSVP-TE interactions.

Actually, you might be missing some history, especially if you are
under the impression that draft-martini predates draft-kompella-...
Yes, draft-martini does predate draft-kompella.  However, the notion of
FR/ATM transport over MPLS has been _shipping_ in certain routers for
nearly two years now.  The notion of label stacking for such transport
has been discussed internally for over a year, and communicated to
one of your co-authors over a year ago ... which is not to say that
they didn't think of it themselves, or that yet others didn't.

Finally, draft-kompella was discussed with one of your co-authors
almost two months ago; and at the time we suggested merging.  The
co-author had reservations.  You should ask him for more background.

Note that the main point of draft-kompella is not simply transport
of layer 2 frames, but simplifying the configuration needed for such
a scheme.  Our approach is so much simpler from a configuration point
of view: if there are n "sites" that want FR connections, you need not
configure (n-1) separate connections at each PE, a single statement
suffices.  Your co-author's argument was that in his case, n was small
(2 or 3) which negated the advantages of draft-kompella.  However, we
have several customers who like this approach, and for whom n >> 1.

Further note that encapsulation and label stacking are covered briefly
in section 4.4; this section will be expanded and more details supplied
in a later version.

> Some things are also missing from your draft.  draft-martini... handled 
> some cases that you haven't included, such as the need in some cases to 
> include a L2 length field.

We didn't see a need for this.  However, we are always open to input.

> It also includes how to signal the association 
> of L2 identifiers, such as DLCIs, VPI/VCIs, etc, with particular LSPs, and 
> the mechanics of such an association weren't immediately obvious in your 
> draft other than handwaving.

You may call a fairly detailed algorithm and examples "handwaving".
That's your prerogative.  However, several folks have both read and
understood the method, to the extent of pointing out typos and offering
improvements.  If you have specific questions about the algorithm in
section 4.3.1, please let us know, and we'll be happy to provide more
details or explanations.

> Finally, it's important to include the 
> details on how to interface to the appropriate L2 status signaling, such as 
> FR LMI/PVC status signaling, and ATM OAM.  I didn't see that in your draft 
> at all.

You haven't read carefully, if you say that this isn't there "at all".
I agree that there isn't a lot of detail; there will be more in a 
future version.  Meanwhile, see end of section 4.2; step 7 of the
algorithm of section 4.3.1; and the following paragraph.

> I noticed at least one obvious bug in your spec - for FR, you completely 
> strip out the DLCI octets.  However, there is not only address information 
> in those octets, but the C/R, DE, BECN, and FECN bits.  FR standards 
> require that these be transported unchanged through a network.  Dropping 
> C/R in particular will break FRADs and other non-IP FR applications.

Perhaps.  We do this in our current implementation, and this is
deployed and works very well, and we have seen no complaints.  If
this is an issue, we will work to resolve it.  I am no Frame Relay
expert while you certainly are, so I appreciate your comments.

In particular, DE is under consideration; FECN and BECN are also being
considered.

However, the point of stripping/switching the DLCI is very important: 
independence in DLCI numbering at both ends of the circuit.  This is
of crucial importance to several of our customers, especially in a
VPN environment.  If C/R, DE, BECN, and FECN bits must be preserved,
we will carry them; but switching the DLCI is a must.

> I highly suggest that you give draft-martini-.... another look.  I for one 
> would be happy to work with you on including what's already been specified 
> there in your own draft, either by reference or by inclusion.  There's no 
> reason to reinvent the wheel.

Like I said, talk to your co-authors and get a better understanding
of the history of this topic.  We think draft-kompella is a more
complete solution; your opinion may differ.  We'll let the
appropriate WG decide; hopefully, customers (service providers) will
provide guidance as well.

Kireeti.