The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Title: RE: [PWE3] MPLS PID

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