The MPLS WG Archive

["W. Mark Townsley" <townsley@cisco.com>]

Andrew G. Malis wrote:
> Shahram and Alia both make excellent points:
> 
> At 3/25/2003 02:18 PM -0800, Shahram Davari wrote:
> 
>> >1.  Dealing with ECMP behavior
>> >2.  Inband OAM flows
>> >3.  Identifying flows for netmanagement applications.
>>
>> I don't think any of them justifies adding PID.
>>
>> 1) ECMP could use only label hashing and not hash IP header.
>> 2) OAM flows could use IPv4/V6 null or MPLS Alert label
>> 3) Netmanagment could identify the flow at the ingress.
> 
> 
> At 3/25/2003 06:15 PM -0500, Alia Atlas wrote:
> 
>> How does requiring a PID in the PWE3 L2 control word solve or handle 
>> the case where a control word is not mandatory?
>>
>> There are pseudo-wires, such as ethernet, where a control word is not 
>> mandatory.  This would imply that the first nibble (which would be 
>> identified as the suggested PID) would be that from the ethernet frame.
> 
> 
> We're going to have to change the PWE3 drafts to require the control 
> word, and change both the SONET/SDH and some of the ATM encapsulations, 
> to support a hack.  If you REALLY want multi-protocol identification, 
> then have the MPLS WG put a REAL multiprotocol identifier, a la RFC 2427 
> or 2684, between the labels and the payload.  See, for example, 
> draft-moreels-multiproto-mpls-00.txt for a much more general (and 
> useful) method than just a four-bit hack.  And sorry for the cross-post, 
> but this really does affect both WGs.

Andy,

The draft you reference here (which, incidently, simply seems to focus on 
multiple new ways to carry PPP and PPPoE over MPLS vs. just using RFC2661) 
doesn't directly address the problem at hand as one is still faced with 
inspecting the first nibble after the bottom of the label stack to determine if 
the payload is IPv4, IPv6, LLC/NLPID (0xf...) or LLC/SNAP (0xa...).

If we are going to be essentially allocating from the first nibble anyway (and I 
can't see how we could get around this considering existing deployments) we 
should go ahead and be explicit about it. If the MPLS WG wants to have a more 
broad and extensive protocol ID than just this first nibble, that is fine, but I 
do not think you can avoid explicitly taking these 4 bits into account without 
deprecating the whole of all MPLS/IP deployments today.

One possibility for an extended PID that comes to mind is defining one of the 
remaining 14 values within the first nibble as "extended PID" and follow it with 
whatever PID definition you like.

- Mark

> 
> Cheers,
> Andy
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>