The MPLS WG Archive

[Dan Tappan <tappan@cisco.com>]

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.