Eric:
> Let's try to focus a little.
>
> 1. The only reason for a
PID field in MPLS and/or PWE3 is to allow
> intermediate routers to determine
whether a particular MPLS payload is an
> IP packet or not.
Actually at the moment it appears to be to stop ECMP
implementations from buggering non-IP flows. However sticking with having to
use additional labels to discriminate protocol flows or router alert or
whatever gets similarely broken by ECMP. A pid plus one or two bits obviates
the need for ALL reserved labels in order to perform the same functions.
Seeing as folks were opposed to codifying things like not
hashing reserved labels and excluding the 's' bit in NHLFE selection in
Atlanta, adding the option of an extended label with a PID and some control
bits looks very attractive.
>
> There are a number of reasons why this is
useful, and no one has argued
> that this is not useful.
>
> No one has
provided a reason why it might be useful for
intermediate
> routers to know,
if the payload is not IP, what kind of packet it is.
You're not a student of OAM. Tom's VCCV stuff and my
guidelines draft are all about trying to carry protocols across the network
without having ECMP 'exceed its mandate'....Some of us would love to have
segment OAM ability as well.
>
> 2. The reason there is no PID field in the MPLS header
is that there was a
> consensus
to keep the header as short as possible.
And that's wonderful for the high running case (v4/v6), beyond
that having to use another 32 bits exclusively as a PID is not that
efficient.
>
> 3. The reason the PWE3
control word is optional is that there is a consensus
> (apparently a continuing one) to allow
service providers to specify that
> the header be kept as short as possible.
>
> 4. My conclusion
from 2 and 3 is that there isn't much hope for any solution
> which includes both a PWE3 control word AND a
4-byte MPLS PID field.
I'm certainly not suggesting that.
>
> 5.
There is anyway no way for the IETF to change the basic MPLS
forwarding
> logic, at
least not in the time frame over which one would like to
see
> PWE3 deployments.
Don't think anyone is suggesting that either.
> 6. No one has given a reason why the first nibble
of any such control word
>
should not be as Stewart has proposed.
Except that it breaks some implementations that may have 0x04
in the first nybble without being IP packets.
> 7. The PWE3 control word can be specified as a
mandatory-to-implement option
>
which a SP can disable if his environment is such he doesn't care
about
> the absence of the PID.
> So I really think there is only one possible
outcome. The only issue is how much time and breath we want
to waste
> until we get there. A SP is faced with
the choice of either:
> a. Requiring the use of a Martini-style PID, or
> b. Ensuring that his pseudowires only carry
non-order-sensitive traffic, or
> c. Ensuring that his PWE3 packets do not pass
through any MPLS environment
> in
which IP payload based load balancing is done.
^^^^^^^^^^^^^^^^
d. load balancing limited to the label stack is also an
option, having an alternative to reserved labels for LSP specific functions
works even better.....esp. w.r.t. the genie already out there
Dave