The MPLS WG Archive

[Ben Black <ben@layer8.net>]

I was under the impression that the purpose of the IETF was to
engineer, not simply to generate documentation.  The date is
irrelevant if there is a problem with a specification.  What
you consider merely aesthetic, others consider fundamental to
good protocol design.


Ben

On Wed, Dec 20, 2000 at 12:56:39PM -0500, Eric Gray wrote:
> 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.
> 
>