[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: How many can administrative groups assigned?



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:curtis@workhorse.fictitious.org]
> 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 
> <OFB9A0B479.64961C82-ONC1256BB3.002CC49C@net.alcatel.be>, sven.van_d
> en_bosch@alcatel.be 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
>