The MPLS WG Archive[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
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.
>
>
|
|