The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <200303271613.h2RGDOiH028923@rtp-core-1.cisco.com>, Eric Rosen write
s:
> 
> 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. 
> 
>    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.  
> 
> 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.
> 
> 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. 
> 
> 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.
> 
> 5. My further  conclusion is that, as Mark has  suggested, the only possible
>    outcome  of a  discussion in  the MPLS  WG is  a recommendation  that any
>    non-IP application using  MPLS specify a control word  whose first nibble
>    is as Stewart has proposed for PWE3. 
> 
> 6. No one has given  a reason why the first nibble of  any such control word
>    should not be as Stewart has proposed.
> 
> 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 load balancing is done. 
> 
> Encapsulations which do not use the Martini-style control word are therefore
> at a  disadvantage.  We  should make sure  therefore that  any encapsulation
> which actually solves a problem for the industry has a control word with the
> first nibble as Stewart has proposed. 



Eric,

Nice summary.

What we can do is actually use the L3PID in MPLS and specify a value
for traffic with the packet type specified in the nibble, and a value
in this nibble to indicate that an ethertype is in the rest of the
first 32 byte entry rather than a PWE3 encapsulation to allow plain IP
mixed in and/or specify a value of L3PID indicating that a
Martini-style PID will be found.

The problems that we've run into in the past is what to put in L3PID
for hierarchical tunnels that have more than one L3PID in the tunnels
that go inside them.  This solves it.  If we go with the a scheme that
allows the per packet L3PID, then the hierarchical tunnels is the new
kind of "L3PID in the payload" encaps (or an abbreviated form) and
insert the L3PID of the payload if it isn't already there (which it
gets from the LSP it is putting inside the hierarchical tunnel.

We still have the case where a hierarchical tunnel has a setup request
with the L3PID of type MPLS (essentially saying "unknown") and all
that can be done for that type is the L3PID MPLS is put in the payload
so LSR along the way can see this packet as "unknown" type but others
as known types.

If you go with a short (nibble, or 2 byte) PID, or any PID which is
not based on ethertype like L3PID, then you complicate the algorithm
for determining what to put in the encaps at a hierarchical tunnel.

This feature would not have to be available on all LSR in a network,
but the more LSR with this at ingress or at the ingress to a
hierarchical LSP, the better.  The more midpoint LSR trying to do ECMP
that were aware of the new L3PID values, also the better.

Curtis