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