The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Dec> msg00398



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Concerns regarding the numerous layer violations in baseMPLS drafts

  • From: Eric Gray <ewgray@mindspring.com>
  • Date: Wed, 20 Dec 2000 12:56:39 -0500
  • CC: Kireeti Kompella <kireeti@juniper.net>, curtis@avici.com, mpls@UU.NET

I agree with Dan on all of his points.  Note that a proposal
to re-organize documents for what are essentially esthetic
reasons are completely inappropriate at this late date.

--
Eric

Dan Tappan wrote:

> At 08:33 PM 12/19/00 -0800, Kireeti Kompella wrote:
> > > The text is therefore fine as is.  Perhaps some minor clarification
> > > can be made, but it does not make sense to remove this.
> >
> >Stating (1), (2) and (3) above, and stating that the L3PID is only valid
> >when the stack depth is 1 would do it for me.
>
> What people keep forgetting in these discussions is that there is no one
> "MPLS", there are at least 3:
>
> 1. MPLS as a way of adding additional capability to IP. This is the
> original, and includes TE, LDP, and VPN
>
> 2. MPLS as a media independent replacement for ATM (Layer 2 VC) signaling
>
> 3. GMPLS TE mechanisms as a mechanism implementing a control plane for
> non-packet capable devices
>
> Folks who remember [1] think that having special procedures for IPv4 LSPs
> is perfectly reasonable.
>
> Folks who focus on [2] worry about "layer violations"
>
> Folks who focus on [3] don't even worry about the issue, since "non-packet
> capable devices" never see packets.
>
> Right now Kireeti is feeling gored because he wants to transfer L2 packets
> over IPv4 LSPs, and doesn't want to worry about IPv4 procedures.
>
> However, if he gets his way on the above then I predict that he, or someone
> else in his company, will feel equally gored the first time a customer
> deploys VPN, or LDP over TE, or Aggregated TE, or ..., and needs to debug a
> problem using traceroute, or wants to apply some other IPv4 procedure.
>
> Regarding the organization of documents. I think it would be reasonable to
> have "MPLS Procedures for IPv4 LSPs" as a separate RFC (or BCP, since many
> of these are local decisions). Similarly for IPv6 or any other protocol
> dependent procedures. However, I don't think it's important enough to hold
> up publication of the current RFCs - the discussed procedures obviously
> apply only to IPv4 LSPs.