The MPLS WG Archive

[Loa Andersson <loa.andersson@utfors.se>]

All,

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

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

/Loa

Kireeti Kompella wrote:
> Hi David,
> 
> On Thu, 21 Nov 2002, David Charlap wrote:
> 
> 
>>During the course of development, I have noticed that there are several
>>features of generalized-RSVP (draft-ietf-mpls-generalized-rsvp-te-09)
>>that are applicable to non-generalized MPLS networks.
> 
> 
> There are those who refer to generalized and non-generalized MPLS
> networks, those who talk about GMPLS and classical MPLS, etc.
> 
> I would prefer to view this at two levels:
>   o (A) generalized signaling and (B) non-generalized/classical signaling
>   o (i) non-packet and (ii) packet LSPs (or MPLS networks)
> 
> (A) can be used for both (i) and (ii)
> (B) can be used for (ii), but does rather poorly for (i)
> 
> If an applicability statement is needed to say this, so be it.
> 
> Kireeti.
> 


-- 
     /Loa


     Loa Andersson
     Utfors AB
     Råsundavägen 12
     Box 525, 169 29 Solna
     Mobile          +46 70 848 5038
     Email           loa.andersson@utfors.se