The MPLS WG Archive

[Dan Tappan <tappan@cisco.com>]

At 06:25 PM 12/20/00 +0000, neil.2.harrison@bt.com wrote:
>Eric/Dan I don't see it quite like this.....I see MPLS as having 2 main
>components:
>-       a user-plane trail OH component for packet networks........which
>creates new layer networks whether one understands/accepts this or not;
>-       a control-plane component for *all* forms of CO network.......which
>effectively has a noble goal of control-plane harmonisation to avoid
>re-inventing the (control-plane) wheel for each new technology.  However,
>whether the target control-plane is 'correct' is a different issue.
>These are quite distinct and different and should not be seen as the 'same
>thing'.  However, this split does at least allow me to understand/state the
>key functional differences, which the explantion below does not.


Neil,

I believe you are saying that in your view my classifications [2] and [3] 
are related. Whether or not that's true, it's irrelevant for application 
[1] which is _not_ necessarily CO, and need not create a new layer network.

Part of my point was exactly that "GMPLS TE" (Connection Oriented MPLS) is 
a subset of "MPLS".


>neil
>
>
> > -----Original Message-----
> > From: Eric Gray [SMTP:ewgray@mindspring.com]
> > Sent: Wednesday, December 20, 2000 5:57 PM
> > To:   Dan Tappan
> > Cc:   Kireeti Kompella; curtis@avici.com; mpls@UU.NET
> > Subject:      Re: Concerns regarding the numerous layer violations in
> > baseMPLS drafts
> >
> > 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.