The MPLS WG Archive

[David Charlap <David.Charlap@marconi.com>]

Loa Andersson wrote:
> 
> let me see if I understand this correctly.
> 
> I think that the general problem is -given the definitions by Kireeti
> below - that:
> 
> - something specified in a ccamp spec makes perfect sense
>   for something in vanilla ;) mpls (using signaling type B)
> 
> - the ccamp spec specifies more than what is needed (makes sense) for
>   the vanilla mpls that has to be implemented to comply to the with the
>   spec

This was my original question.

> Then the issue is, how do we handle this?
> 
> Is this the background for the question? If so, I can see several
> ways of doing things
> 
> - split documents, one mpls and another ccamp one, where the ccamp
>   include the mpls doc (by reference)
> - do it by applicability statements, from the mpls side saying "what is
>   specified in the ccamp if doc is a great idea, but if you apply it to
>   packet mpls you don need to implement ..."
> - include info in the ccamp doc on what is needed in packet mpls

Any one of these would be fine for me.  My main concern here is that 
MPLS vendors will start implementing those features, and some may ignore 
the GMPLS approach, thinking that those drafts are not applicable to 
non-generalized MPLS.  This may lead to interop issues.

Of course, vendors often ignore drafts anyway, but at least this way 
they'll know that there is something out there that they can choose to 
implement or ignore.  And those that need to pull pieces of GMPLS into 
their MPLS implementations will know how much must be pulled in to 
properly support the features under development.

-- David