Subject: MPLS Capability Set document

From: CATANZARITI Sergio FTR&D/TI <[email-masked]>
Date: Fri, 12 Nov 1999 16:02:56 -0800

In trying to dig into the plethora of MPLS implementations floating around,
I was thinking that this magic Capability Set document, applied to MPLS,
could have been an useful tool. Other than resembling some other environment
(another way of "ITUing" the IETF) where, at least, the documents look to
have a rationale behind that (not always necessarily market-driven), this
IETF Capability Set MPLS document looks to me confusing, complex and
incomplete.

Confusing. I do not understand why it has been created (ITU-T capability set
concept in general maps a capability set into a specific set of application
requirements/services).

In fact, from the IETF MPLS Capability Set document....
>Although there sometimes/frequently is an obviously a relationship between
the Capability set and an intended use, this draft doesn't state the
intended use of or the application possible to support by the capability
set>>
And then, inside the specific capability set 1...
> The capability set supports explicit routed LSP set up...
So, is or is not the capability set 1 supposed to support an explicit routed
LSP? Is this a requirement of a TE application or what?
Also, I read...
> The intention is instead to give a reference framework that offers a
possibility to classify compatibility of MPLS implementations
But, I thought that tools such as ICS (Implementation Conformance Statement)
are more tailored to this goal (I am not soliciting them.....).
Capability Set-x implementation verification and MPLS implementation
compatibility/conformance/interoperability/compliance are not quite the same
thing (at least from an operational standpoint).

Complex. How many capability set does MPLS have??? I do not believe that
MPLS had so many true implementation profiles. If you do not see
implementation profiles in a relationship with application usage, I am sure
you will end up with lots and lots of possible capability set.

Incomplete. Again, because you have not started from an MPLS application
requirements classification, but from an enumeration of protocol and
mechanisms, it is easy not to take into account all the possible usage that
different pieces of an MPLS implementation can provide. An example, I can
have a differentiated service transport capabilities (kind of CoS,
QoS-type), just by using IP DS byte or shim header CoS bits, and mapping
these to a different pool of LSPs without necessarily using CR-LDP. Also, I
do not understand why, by using RSVP in your capability set x/y, I cannot
leverage its reservation engine in using DS/CoS services semantic, to obtain
a differentiated IP service transport application, characteristic that from
the document looks possible only by using CR-LDP.
So, I have a suggestion to revisit the document, by doing in this way: 
1) singling out the different MPLS applications (they are no more than 2/3).
2) Mapping these to different capability set, supporting the specific
applications, without instantiating yet with specific protocol and
mechanisms.
3) Focus on ALL the possible mechanisms capable to support the step 1
application requirements.
4) Populate the step 2 capability set with the step 3 protocol and
mechanisms.

Sergio

> -------------------------------------------------------------------
> Sergio Catanzariti
> Senior Project Manager, Technology Integration
> France Telecom R&D 
> 1000 Marina Boulevard Suite 300 
> Brisbane CA 94005
> Tel. 650-875-1526
> Fax. 650-875-1505
> email:[email-masked] 
> --------------------------------------------------------------------
> 
>

---

From: "Loa Andersson" <[email-masked]>
Date: Mon, 15 Nov 1999 16:28:32 +0100

Sergio,

I'll try to do this in steps.

1. "I'm not not now and have never been a member of the ITU-T...", if
the
"cap-set draft" makes it impossible for you to think out of the ITU box
I'm quite willing to change the name. Suggestions?

2. Our intention was simply to try to group the rather piecemeal
functions
described in e.g. the label distribution in several specifications, in
larger
sets as a way of describing what MPLS is capable of. We called these
larger sets "capability sets".

3. The draft states that there's sometimes/frequently an intended use
and the cap set, but it never states that this is the only use
of the cap set.

4. for the next version we decided to include applications as examples
of how they match the cap sets.

5. some more comments in the text below   

CATANZARITI Sergio FTR&D/TI wrote:
> 
> In trying to dig into the plethora of MPLS implementations floating
> around, I was thinking that this magic Capability Set document,
> applied to MPLS, could have been an useful tool. Other than resembling
> some other environment (another way of "ITUing" the IETF) where, at
> least, the documents look to have a rationale behind that (not always
> necessarily market-driven), this IETF Capability Set MPLS document
> looks to me confusing, complex and incomplete.
> 
> Confusing. I do not understand why it has been created 

describe the capabilities of MPLS

>(ITU-T
> capability set concept in general maps a capability set into a
> specific set of application requirements/services).

don't know anything of ITU cap sets

> >Although there sometimes/frequently is an obviously a relationship
> between the Capability set and an intended use, this draft doesn't
> state the intended use of or the application possible to support by
> the capability set>>

there is probably a many to many relationship

> So, is or is not the capability set 1 supposed to support an explicit
> routed LSP? Is this a requirement of a TE application or what?

I'm trying to make heads and tails of this statement. Implementations
according to cap set 1 supports a strict "explicit routed LSP set up",
this may be one way of doing a TE application?

> But, I thought that tools such as ICS (Implementation Conformance
> Statement) are more tailored to this goal (I am not soliciting
> them.....).

Possibly we differ on "framework" and ICS?

> compatibility/conformance/interoperability/compliance are not quite
> the same thing (at least from an operational standpoint).
> 
> Complex. How many capability set does MPLS have??? I do not believe
> that MPLS had so many true implementation profiles. If you do not see
> implementation profiles in a relationship with application usage, I am
> sure you will end up with lots and lots of possible capability set.

I agree upon complex! That was one of the reason we started to think 
about this. But personally I don't think it is the number of cap sets
that is the problem, but rather that there is (might be) functions
that is described that won't be used. 

> 
> Incomplete. Again, because you have not started from an MPLS
> application requirements classification, but from an enumeration of
> protocol and mechanisms, it is easy not to take into account all the
> possible usage that different pieces of an MPLS implementation can
> provide. An example, I can have a differentiated service transport
> capabilities (kind of CoS, QoS-type), just by using IP DS byte or shim
> header CoS bits, and mapping these to a different pool of LSPs without
> necessarily using CR-LDP. Also, I do not understand why, by using RSVP
> in your capability set x/y, I cannot leverage its reservation engine
> in using DS/CoS services semantic, to obtain a differentiated IP
> service transport application, characteristic that from the document
> looks possible only by using CR-LDP.

The RSVP is the RSVP-TE

> 1) singling out the different MPLS applications (they are no more than

We intend to do that, but I'm after discussions I had as a result of
this
draft so very hopeful that we can limit the number of applications to
only
two or three. A modest suggestion is that we should go for:
a. traffic engineering 
b. VPN's
c. hop-by-hop routing
d. ip over atm/fr

> 4) Populate the step 2 capability set with the step 3 protocol and

OK, as far as it goes ... 

-- 

Loa Andersson
Director Technology Center, EMEA
St Eriksgatan 115, PO Box 6701
113 85 Stockholm, Sweden
phone: +46 8 50 88 36 34,   mobile + 46 70 522 78 34
e-mail: [email-masked]