Subject: RE: MPLS PID

From: "Ron Cohen" <[email-masked]>
Date: Tue, 1 Apr 2003 16:59:07 +0200

George and all,

Would reserving two PID values for PWE3 flows be ok? The current SONET
CEP header is by default 1 word long (4 bytes), but also supports
several optional modes that uses an extended (longer) control word. The
CEP header has an extension bit that tells the receiver whether the
incoming flow carries an extended control word or not. 

Two PID values that differentiate between the two, and provides the same
functionality as the E bit would be of great help, something along:

PID = 0000 : PW Short/Default Control Word
PID = xxxx : PW Extended Control Word

This would take only 2 out of the 16 values, and can be used by all PW
to support similar functions. 

Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of George Swallow
> Sent: Tuesday, March 25, 2003 10:39 PM
> To: W. Mark Townsley
> Cc: Andrew G. Malis; [email-masked]; [email-masked]
> Subject: Re: [PWE3] MPLS PID 
> 
> 
> > Regarding whether the MPLS WG has discussed this before, Eric Rosen 
> > suggested at
> > the microphone in SF that it had, but at that time the 
> decision obviously was to 
> > not include a PID within MPLS. The bottom line is that 
> perhaps we are seeing 
> > that in hindsight this was an error, and if so this should 
> be openly resolved 
> > within the MPLS WG.
> 
> For a few of us is was foresight, but that didn't carry the 
> day.  I would be most happy to have this discussed in MPLS.
> 
> It would seem that there three identified uses for the PID.
> 
> 1.  Dealing with ECMP behavior
> 2.  Inband OAM flows
> 3.  Identifying flows for netmanagement applications.
> 
> The first seems fairly straightforward.
> 
> Define IPv4 and v6, reserve a few more values for possible 
> future versions of IP.  Figure out whether there is any ST 
> left in the world. 
> 
> For the second define a single PID for any OAM flow.  It 
> would be imprudent to had out pair of PIDs to apps that want 
> inband OAM. Something collecting flow information in the 
> middle of the network won't be able to identify the inband 
> OAM, but that may be a good thing as the result will be just 
> counting the data.
> 
> The third is a bit tickier.  Given the resolution of (1&2) 
> we'll have a small number of PID values to play with to use 
> for flow identification.  What that small set should be needs 
> to be resolved. I look to operators of networks for input.
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
>