Subject: RE: suggestion for draft-ietf-mpls-lsr-mib

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 20 Oct 2003 18:42:14 -0400

A little over 6 months ago I published 
a draft draft-nadeau-mpls-lc-if-mib that
addresses this stuff. It was accepted as
an MPLS WG draft, but due to being busy I 
didn't get around to updating it. I just republished
it as a WG document, so it should appear soon.

	--Tom

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stefan Winter
> Sent: Sunday, August 10, 2003 9:32 AM
> To: [email-masked]
> Subject: suggestion for draft-ietf-mpls-lsr-mib
> 
> 
> Hello!
> 
> During implementing a management agent for the
> MPLS-LSR-STD-MIB a minor missing feature in the MIB showed up 
> (at least in my understanding). The issue is about 
> InSegments. When generating a new InSegment, one must specify 
> the type of label, "generic","atm" or "frame relay". The type 
> of label cannot be directly read. The current way to do so is 
> to lookup the mplsInSegmentInterface column of the row, then 
> look into IF-MIB::ifType.x and evaluate the ifType to guess 
> which of the three is appropriate. Apart from the fact that 
> looking up content of another MIB may be expensive, it not at 
> always possible to determine the type of label. If, for 
> example, ifType reports that the device is an ATM device, 
> both the "atm" or the "generic" label types are possible 
> (since "generic" is always an option). To overcome that 
> limitation, two options seem to be possible.
> a) extend the mplsInterfaceTable with a column mplsInterfaceLabelType
> b) extend the mplsInSegmentTable with a column mplsInSegmentLabelType
> 
> where b) is a more general solution as it allows to specify
> the type per-label and not only per-interface, as solution a) 
> would do. The Syntax for such a column could be INTEGER { 
> gen(0), atm(1), frame-relay(2) }. And as I write this, I 
> realize that even OutSegments need to have the type of label 
> specified... so the same limitation applies to OutSegments, too.
> 
> These are just my 2 cents from an implementor´s view, a
> comment would be nice.
> 
> Greetings,
> 
> Stefan Winter
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 27 Oct 2003 09:30:28 -0500

Hi,

>During implementing a management agent for the MPLS-LSR-STD-MIB a minor
>missing feature in the MIB showed up (at least in my understanding).
>The issue is about InSegments. When generating a new 
>InSegment, one must
>specify the type of label, "generic","atm" or "frame relay". 
>The type of label cannot be directly read. 

	I don't understand. You know the interface on which
the label is being allocated, and hense the label space
that it is being allocated from. This tells you whether it
is the per-platform or per-interface space. In any event,
the interface tells you where the label came from.

>The current way to do so is to 
>lookup the
>mplsInSegmentInterface column of the row, then look into 
>IF-MIB::ifType.x
>and evaluate the ifType to guess which of the three is 
>appropriate. Apart
>from the fact that looking up content of another MIB may be 
>expensive, it
>not at always possible to determine the type of label. If, for example,
>ifType reports that the device is an ATM device, both the "atm" or the
>"generic" label types are possible (since "generic" is always 
>an option).

>To overcome that limitation, two options seem to be possible.
>where b) is a more general solution as it allows to specify the type
>per-label and not only per-interface, as solution a) would do. 
>The Syntax
>for such a column could be INTEGER { gen(0), atm(1), frame-relay(2) }.
>And as I write this, I realize that even OutSegments need to 
>have the type of label specified... so the same limitation applies to 
>OutSegments, too.

	The interface table already contains a variable that
indicates the label space participation type which applies
to all labels (segments) allocated using that interface: 

mplsInterfaceLabelParticipationType OBJECT-TYPE
   SYNTAX  BITS {
                  perPlatform (0),
                  perInterface (1)
              }

	--Tom

>comment would be
>nice.