The MPLS WG Archive

[Eric Gray <ewgray@mindspring.com>]

Danny,

    Please.  I submit that no one has yet convinced me, at
least, that a problem exists.  Therefore, I'm not suggesting
that "we fix things that are broken" at all.  I merely suggest
that - if someone (not me) feels that there is something they
would like to "fix" - they should "fix" it in future work.

    What goes against the I-D process is the idea of trying
to word-smith an I-D a full year after last call. And that is
exactly what I see being proposed.  I have not see any one
suggest that people will not be able to implement MPLS
because of the fact that it seems to be tied into IP.  Such a
suggestion would be ridiculous.  And I have seen at least
one person show how any "misunderstanding" of MPLS
specifications is explainable as a perspective problem.

    Many people have - over the last 2 or 3 (thousand, it
seems) years suggested that an MPLS header is a form
of short hand for an IP header.  So, while some people
feel that words should be added to the specification to
make it clear that an IPv4 L3PID applies only if the stack
depth is 1, others may think that stack depth is not only
irrelevant, but not something they want to check all of the
time (or maybe even know any of the time).  For the latter
group, the analogy that an MPLS label "stands in" for an
IP header (similar to the way that a compressed IP header
does) is more than sufficient justification for the wording
as is.

    For those people who have wanted to use MPLS to
transport something other than IPv4 packets, from the
beginning of time it seems, it might seem irrelevant that
MPLS labels "stand in" for an IP header.  But it makes
how things other than IPv4 packets are to be carried
across an IPv4 network much more intuitive if we look
at it this way.

    Finally, considering how many revisions many of the
base MPLS drafts have been through, not to mention one
or more last calls, calling for closure is not the same as
generating documents.  In reviewing the original posting
on this subject, I believe the whole discussion derives
from a misunderstanding of what it means when you say
"SHOULD" in a protocol specification.  I suggest that
we eventually reach a point where we are clarifying a
thing to death.

    Perhaps that is the goal?

--
Eric Gray

You wrote:

> ...
>
> Sure they are, even as they exist today -- in draft form.
>
> However, fundamental problems brushed off as aesthetics in
> order to more promptly publish a specification is a clear
> indication that some folks are more concerned about generating
> documents than they are about generating clean protocol
> specifications.
>
> Suggesting that we fix things that are broke in this draft
> later, with yet another patchwork of I-Ds, goes against the
> entire I-D process.
>
> -danny