Subject: RE: How many can administrative groups assigned?

From: "Don Fedyk"<[email-masked]>
Date: Wed, 8 May 2002 16:14:40 -0400

Curtis

You state the definitions are clear but last time I read a couple of
implementations
from vendor specification they were different. While I agree we should keep
the 
complexity to a minimum, when I floated a simple request to define the bits
the 
pushback we got was it was too inflexible. So in my opinion administrative
bits
are purposely under specified by design and hence not so clear. 

Don 
> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Subject: Re: How many can administrative groups assigned? 
> 
> [ post by non-subscriber.  with the massive amount of spam, 
> it is easy to
>   miss and therefore delete mis-posts.  so fix subscription 
> addresses! ]
> 
> In message 
> <[email-masked]>, sven.van_d
> [email-masked] writes:
> > Naidu, Kim,
> > 
> > I think it depends a little bit on the interpretation. In principle the
> > resource classes can be interpreted either as a bit mask (in which case
32
> > 'base' classes can be defined) or as an integer value (in which case
2^32
> > values can be used). Even with the bit mask interpretation, derived
> > resource classes can be built by combining multiple non-mutually
exclusive
> > 'base' classes (you could have 32 generic classes called 1, 2, 3 and so
on
> > and then build your resource classes on top of those). The problem lies
of
> > course in the processing of the resource class information. If they are
not
> > used in a simple bitmask, an AND operation is not sufficient to
determine
> > the resource class of a link. Also, if a link would have multiple
derived
> > classes, different TLVs would be needed. It would make sense to expand a
> > little bit on these issues in the appropriate documents. In my opinion,
> > this is a general issue with the TE extensions, so it should be
explained
> > there.
> > 
> > Sven.
> 
> 
> The definitions are currently very clear.  What you have described
> differs from the current definitions and therefore would not be a
> clarification to the use of admin class but a change in semantics.
> 
> I do not know of anyone using more than a handful of admin class bits
> and many who do not use them at all.  Lets not take any MPLS
> capability and make it any more complicated than it needs to be or
> introduce arbitrary change for no good reason.
> 
> Curtis
>

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 08 May 2002 17:07:10 -0400

In message <[email-masked]>, "
> are purposely under specified by design and hence not so clear. 

AFAIK the vendors at ISOCORE interoperability testing all interpret
these as bitmaps and all support at least the include-any and exclude
(which is interpreted as exclude-all).  Some do not support the
include-all operation but it is easy to add.

What meaning is assigned to each bit is something that should not be
specified since it is local to the MPLS domain and up to the service
provider to choose.

No need for any change.

Curtis

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 8 May 2002 23:18:41 -0700 (PDT)

On Wed, 8 May 2002, Don Fedyk wrote:

> You state the definitions are clear

Here's what the OSPF TE doc says:

2.5.9. Resource Class/Color

   The Resource Class/Color sub-TLV specifies administrative group
   membership for this link, in terms of a bit mask.

The ISIS TE doc has:

4.1 Sub-TLV 3: Administrative group (color, resource class)

   The administrative group sub-TLV contains a 4-octet bit mask assigned
   by the network administrator.  Each set bit corresponds to one
   administrative group assigned to the interface.

Seems perfectly clear to me that both are talking about *bits*; the
OSPF doc uses the term 'bit mask', which makes it crystal clear.

> but last time I read a couple of
> implementations
> from vendor specification they were different.

Since when does a vendor's "specification" define a standard?

> While I agree we should keep the complexity to a minimum,
> when I floated a simple request to define the bits the
> pushback we got was it was too inflexible.

Different issue altogether.  The semantics of *bits* is perfectly
clear.  The *use* of bits should be left completely up to the user.

Kireeti.

---

From: "Ravi, Attili" <[email-masked]>
Date: Fri, 10 May 2002 18:01:23 +0530

Hi,

	I have one query.  Assume the case where we have policy based management
system that manages the complete network that supports MPLS .  my question
is, when LER (PEP) sends a request to PDP for LSP setup what are all the
different type of capabilities/limitations that LER (PEP) needs to send to
PDP.  Is there any PIB which is having this information.  If there is no
PIB, how to send this information to PDP ?

Could any body throw light on it ?

Thanks in advance
Ravi

---

From: "Ravi, Attili" <[email-masked]>
Date: Fri, 10 May 2002 18:01:23 +0530

Hi,

Thanks in advance
Ravi

---

From: "Ravi, Attili" <[email-masked]>
Date: Fri, 10 May 2002 18:01:23 +0530

Hi,

Thanks in advance
Ravi