Subject: RE: [PWE3] MPLS PID

From: "Ferrell, William" <[email-masked]>
Date: Thu, 27 Mar 2003 14:34:44 -0500

Dave 
That was a sound summary , but clarify why the exeption in #6 is so easily
ignored in your opinion.
will
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. 

 

-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: Thursday, March 27, 2003 1:48 PM
To: [email-masked]'; [email-masked]
Cc: 'Scott W Brim'; [email-masked]; [email-masked]
Subject: 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