Subject: RE: [PWE3] MPLS PID

From: "David Allan" <[email-masked]>
Date: Wed, 26 Mar 2003 14:47:54 -0500

Hi Scott:

I'm sure you can guarantee coordination. Not sure as to how folks feel about
a 4 bit version number being subsumed as a protocol id as it is a rather
scarce resource, therefore the "few we need" actually consititues
potentially a significant amount of that resource (and one will note that
there is already pressure on it just in this discussion). Yes, sure we can
chain bits (if MSbit set then it's really an 8 bit value) bit that's not
pretty if we're planning on it up front, its simply how you get around a
long standing situation.

If we go on the assertion that MPLS should have had a PID (as opposed to
current practice of binding protocols to labels) then we need to scope what
we are really trying to achieve....

1) Make the payload self describing to end points.
2) Multiplex payloads over a single LSP.
3) Make the payload self-describing to intermediate systems.

At the moment, 3 appears to be the exclusive motivation for this but has
implications in 1 & 2 as we already have mechanisms for achieving those
goals today (indirectly via signalling (1) & label stacking (2)). 

IMHO if we were to add a payload identification to MPLS in particular for
intermediate systems to inspect (bottom label is now really 36 or more bits
that happen to overlap with payload), I would want a lot more from it. For
example, it was a problem folks wrestled with when trying to figure out how
to identify OAM flows (where we went with reserved label as a PID and
therefore only had e2e significance), and I'm sure other applications will
come up.

cheers
Dave

> -----Original Message-----
> From: Scott W Brim [mailto:[email-masked]] 
> Sent: Wednesday, March 26, 2003 1:56 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [PWE3] MPLS PID
> 
> 
> On Wed, Mar 26, 2003 01:38:20PM -0500, David Allan allegedly wrote:
> > We don't have 14 values, we are talking inferring payload 
> on the basis 
> > of defacto IETF protocol payloads (IPv4 and IPv6). PWE3 and MPLS do 
> > not own IPv4/v6 or any subsequent network layer protocols 
> the IETF may 
> > choose to develop.
> 
> Are you trying to say that we can't guarantee coordination 
> between a group developing new versions of IP and the MPLS 
> community?  This is a small logistical problem.  In the 
> absolute worst case we get assignments from IANA to cover the 
> few we need.
> 
> (See http://www.iana.org/assignments/version-numbers).
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: [email-masked]
Date: Thu, 27 Mar 2003 10:49:10 +0100

Dave, all,

> If we go on the assertion that MPLS should have had a PID (as opposed
> to current practice of binding protocols to labels) then we need to
> scope what we are really trying to achieve....
> 
> At the moment, 3 appears to be the exclusive motivation for this but
> has implications in 1 & 2 as we already have mechanisms for achieving
> those goals today (indirectly via signalling (1) & label stacking
> (2)).

If MPLS should have a PID, is it something that would be mandatory on
every LSP, or is the presence of this to be signaled (e.g. using a new
'PW type' in draft-ietf-pwe3-control-protocol (e.g. "type
Multi-Protocol")) ? I think that if MPLS PID is defined, the use of it
should be optional and signaled. So not "as opposed to binding protocols
to labels", but "as an optional alternative to binding protocols to
labels".

Applications for motivation 1) are described in
draft-moreels-multiproto-mpls-00.txt and in
draft-sajassi-l2vpn-interworking-01.txt.

thanks,
Jeremy.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 27 Mar 2003 11:13:23 -0500

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.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 27 Mar 2003 13:39:10 -0500

In message <[email-masked]>, Eric Rosen write
> 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

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 31 Mar 2003 00:10:46 +0100 (BST)

>    intermediate routers to determine whether a particular MPLS payload is an

which is a layer violation, and shouldn't be done.

>    There are a number  of reasons why this is useful, and  no one has argued

not appropriate, more like.

if you're going to sniff for an IP packet (so you can sniff TCP/UDP or
higher) you might want to ask why you even have any form of mpls
label stack in there in the first place.

if you're not separating out your ip flows via explicit mpls label,
why not?

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>