The MPLS WG Archive

[neil.2.harrison@bt.com]

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


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