The MPLS WG Archive

[Kireeti Kompella <kireeti@juniper.net>]

Hi Loa,

On Thu, 21 Nov 2002, 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

and sometimes less than what is needed.

CCAMP's charter is to produce specs that apply across a multitude
of technologies, *one* of them being MPLS.

> 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)

Excellent idea: CCAMP produces the COMMON document, MPLS refines it
to tailor it to MPLS.  Actually, this was the idea all along.

Important change: the mpls doc cites the ccamp doc, not vice versa.

Case in point: CCAMP produces a spec for (symmetric bw) bidirectional
LSPs.  You *can* signal a bidir LSP in MPLS with that.  However, you
can't do MPLS LSPs with fast reroute (as George pointed out).  That's
where the second *MPLS* document (check charter first!) that builds
on the CCAMP doc comes in.  However, a document that does bidir LSPs
*another* way helps no one.

> - 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 ..."

That would be fine, if no protocol changes/additions are needed.

> - include info in the ccamp doc on what is needed in packet mpls

We've spent a lot of time removing technology-specific work from the
COMMON specs.  I don't think we want to go this way.

Kireeti.