Subject: RE: MPLS PID

From: "David Allan" <[email-masked]>
Date: Wed, 26 Mar 2003 17:05:46 -0500

Tom:

Why not simply a PID for multi-protocol instead of explicitly for OAM, and a
subsequent field could identify if it was ICMP, LSP-PING, 1711, SIP,
whatever. Stunt doubles for a normal/reserved label just fine. Probably
about the same implementation complexity though for any individual
application. 

At that point it may be useful to deprecate many of the reserved labels as
we could now move functions like "router alert" out of the stack. If every
node is snooping payload and we've made the bottom of stack some kind of
extended label entry, it make make sense to do some things differently. IMHO
this could clean up some loose areas in the architecture in particular w.r.t
label semantics.

Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]] 
> Sent: Wednesday, March 26, 2003 10:18 AM
> To: George Swallow; W. Mark Townsley
> Cc: Andrew G. Malis; [email-masked]; [email-masked]
> Subject: Re: [PWE3] MPLS PID 
> 
> 
> At 03:38 PM 3/25/2003 -0500, George Swallow wrote:
> > > 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.
> 
>          It is a good thing from a counting/flow perspective 
> because it means that the PW traffic takes the same switching 
> path(s) as the OAM for that PW that might be used to test the 
> PW. OTOH, this will not work for tracing; however, there are 
> other tools that can be used for tracing the PSN already, so 
> this is not a big issue IMHO.
> 
> >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.
> 
>          For the last point, wouldn't an option be to just 
> have a single PID for OAM and then have sub-types follow 
> inside the packet to identify the apps?  This only requires 
> us to allocate a single PID for OAM.  This is incidentally, 
> how we have defined VCCV.
> 
>          --Tom
> 
> 
> 
> >...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
> 
> 
http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3