The MPLS WG Archive

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



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

Concerns regarding the numerous layer violations in base MPLS drafts

  • From: "Thomas D. Nadeau" <tnadeau@cisco.com>
  • Date: Wed, 20 Dec 2000 13:12:55 -0500
  • Cc: curtis@avici.com, mpls@UU.NET


         I totally agree with Dan on this. There is
no practical reason to reorganize the drafts at this
late stage of the game.

         --Tom


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