Subject: prequeal to WG lat call om the LSR mib module

From: Loa Andersson <[email-masked]>
Date: Fri, 06 Jun 2003 09:04:46 +0200

MPLSers,

included are two major items that the authors, wg-chairs and ADs
want specific comments on when the LSR mib module is published and
last called. The MIB will be sent to the Internet Drafts today (Friaday)
but will take a few days before it is announced. The last call will be
started by a specific mail, as soon as we see it publiched, and will be
limitied to changes since the last version. The discussion on the items
below could take place as a part of the wg last call.

The items are:

1) The indexing of the in/out/XC
    tables has changed from Unsigned32s
    to Octet Strings of up to 24 bytes
    in length.

    The reason this was done was to facilitate
    LSRs that support multiple applications of
    MPLS in a distribute fashion. Use of a
    flat 32 bit indexing space on these platforms
    ends up with VERY slot N^2+ GetNext searches
    due to the fact that labels are distributed
    among different applications. The GetNext
    routine must then query each application's
    "bag" of labels to determine the next index.
		
    This change is compatible with implementations
    that wish to remain with the 4 byte indexing;
    they just use a 4 byte octet string, while others
    are free to use the more specific indexing.

2) The addition of a RowPointer to the in/out/label
    stack tables to support "long" or GMPLS-style
    labels. The RowPointer is normally set to zeroDotZero
    except when the MIB needs to refer to an external
    table that defines labels that exceed the 32bits
    of space alloted in the tables today.  This
    in essence, future-proofs the MIB and makes
    it compatible immediately with the GMPLS MIBs
    defined in CCAMP.

-- 
/Loa

mobile + 46 739 81 21 64
email: [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 6 Jun 2003 10:51:01 -0400

Loa,
Thanks for the opportunity to comment publicly about this issue.

I believe there is a degree of cyclic redundancy about this debate.

In my view, part of the problem is caused by an attempt to place a tight
association between labels and segment indexing which is not a requirement for
successful implementation.

For the sake of history...

At the MIB meeting in Atlanta there was reluctant agreement to accept an octet
string. This octet string, however, was agreed as a combination of the two
fields (and three functions) that are now being proposed. That is, it provided
an identifier of the label, acted as an index into segment tables, and provided
an index into an external table containing labels. In effect it circumvented
issues of making a rowPointer an index (yuck) and provided a place to store
labels 'in line'.
This was a compromise designed to help implementers who believed that they
needed a more complex index than a single integer equivalent to the label
because the labels might be distributed across multiple label management
components *and* who believed that adding a secondary integer index to point to
the appropriate label management component was not sufficient - they needed an
'arbitrary' secondary index which could only be held in an octet string.

The value of that solution was that an non-32 bit label could be held 'in line'
in the octet string without needing to implement a label table provided that it
was clear from the context how the label should be interpreted.

Looking at the inSegmentTable

The old solution (version 9) had
- an interface index that was an index into the inSegmentTable
- a 23-bit label value that was an index into the inSegmentTable

The requirements are
- to be future-proofed ready to upgrade to GMPLS
- to support distributed solutions

For a while the proposal was
- an interface index that was an index into the inSegmentTable
- a 32-bit value that could be interpreted as
   - a label and an index into the inSegmentTable
   OR
   - an index into a labelTable and an index into the inSegmentTable

This went by the board because
- the labelTable may need to be distributed across components
   making a single 32-bit index hard to implement

The Atlanta solution was
- an interface index that was an index into the inSegmentTable
- an octet string that could be interpreted as
   - a label and an index into the inSegmentTable
   OR
   - an index into a labelTable and an index into the inSegmentTable

This was discarded (as far as I can tell) at least because
- arbitrary indexing of the inSegmentTable was preferred (matches the
   outSegmentTable)
- finding a 23-bit label in an octet string is not nice

This new solution (it is hard to be specific without seeing the relevant
bits of the MIB, but I was allowed to see some early versions) appears
to include
- an arbitrary octet string index for the segment table
- an object to contain the label if it will fit into a 23(sic)-bit value
- a pointer into an external table to hold labels otherwise
- an object to contain the interface index

I do not understand why an octet string index is needed. If you need your
insegment index to identify the location of the component that maintains the
segment, and you need that location to dictate the index, why do you not simply
use two integers? Integer searches are cheaper to implement - octet string
searches are a mess. (Yes, I know you can encode two integers into an octet
string, but that is hardly the point.)

Why not have
- an arbitrary primary integer index for the segment table
   this could be used as the component id or set to zero
   this could be used to contain the interface index if you want
- an arbitrary secondary integer index for the segment table
   this could be used as the label value if that is how your mind works
- a 32-bit object to contain the label if it will fit
   thus MPLS 23-bit labels and GMPLS 32-bit labels will fit
- a pointer into an external table to hold labels otherwise
- an object to contain the interface index

Adrian

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Sat, 7 Jun 2003 08:43:51 -0400

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Friday, June 06, 2003 10:51 AM
> To: Loa Andersson; MPLS WG
> Cc: Thomas D. Nadeau; Bert Wijnen
> Subject: Re: prequeal to WG lat call om the LSR mib module
> 
> 
> Loa,
> In my view, part of the problem is caused by an attempt to 
> place a tight association between labels and segment indexing 
> which is not a requirement for successful implementation.
> 
> At the MIB meeting in Atlanta there was reluctant agreement 
> to accept an octet string. This octet string, however, was 
> agreed as a combination of the two fields (and three 
> functions) that are now being proposed. That is, it provided 
> an identifier of the label, acted as an index into segment 
> tables, and provided an index into an external table 
> containing labels. In effect it circumvented issues of making 
> a rowPointer an index (yuck) and provided a place to store 
> labels 'in line'. This was a compromise designed to help 
> implementers who believed that they needed a more complex 
> index than a single integer equivalent to the label because 
> the labels might be distributed across multiple label 
> management components *and* who believed that adding a 
> secondary integer index to point to the appropriate label 
> management component was not sufficient - they needed an 
> The value of that solution was that an non-32 bit label could 
> be held 'in line' in the octet string without needing to 
> implement a label table provided that it was clear from the 
> context how the label should be interpreted.
> 
> This new solution (it is hard to be specific without seeing 
> the relevant bits of the MIB, but I was allowed to see some 
> early versions) appears to include
> I do not understand why an octet string index is needed. If 
> you need your insegment index to identify the location of the 
> component that maintains the segment, and you need that 
> location to dictate the index, why do you not simply use two 
> integers? 

	Because it may be insufficient to identify the 
application's indexing. Although I agree with you that 
having an integer indicate the application's internal ID,
I don't see this as having any advantage over using
a longer addressing space. The reason being that if you allow 
each application to index its entries as it may (i.e.: LDP 
might use destination IPv4 or IPv6 prefixes), then it is 
a straight O(1) indexing operation to get to both the 
application's bag of labels and the entry itself.  The
semantical meaning between an octet string or two integers
is the same, but the flexibility that the octet string affords
you is much better.

> Integer searches are cheaper to implement - octet 
> string searches are a mess. (Yes, I know you can encode two 
> integers into an octet string, but that is hardly the point.)

	I wouldn't characterize it that way. Personally, having 
implemented this and many other MIBs, I will say that octet 
strings are not necessarily a mess, especially in this case
since the octet string truly represents just a potentially
large unsigned integer (or a really small one if that is all
you want to support).

> - an object to contain the interface index

	This scheme will not work unless we also include an
ifIndex. The reason being that the same application may 
want to distribute the same label on different interfaces
(per-interface label spaces). Using only those two indexes
will not uniquely identify both instances of the same label.
I think that we had arrived at this in Atlanta:

	(ifIndex, appId, label)

	So using this scheme, we now have a triple index
to iterate over, making your GetNext way less efficient
and straight-forward than just using a single octet 
string.  I think this is what pushed us towards using
an octet string.

	--Tom

> > included are two major items that the authors, wg-chairs 
> and ADs want 
> > specific comments on when the LSR mib module is published and last 
> > called. The MIB will be sent to the Internet Drafts today (Friaday) 
> > started by a specific mail, as soon as we see it publiched, 
> and will 
> > be limitied to changes since the last version. The 
> discussion on the 
> > items below could take place as a part of the wg last call.
> >
> >
> > The items are:
> >

---

From: Marcus Brunner <[email-masked]>
Date: Mon, 16 Jun 2003 15:37:31 +0200

>     to Octet Strings of up to 24 bytes

I find the 24 byte octet string as index really wired. The Unsigned32 was 
exactly the right thing for me. So I can not support the change.

>     "bag" of labels to determine the next index.

This sounds like a problem of information management on the box and has 
IMHO nothing to do with a MIB design to be useful for Management 
Applications.

Indexing always has implications on sorting in the management application. 
If the sorting based on different applications is needed I would favor the 
approach with an app index. I assume the app index will be coded into the 
24 octet string anyway so why not making it explicit?

>     are free to use the more specific indexing.

Sounds like an offer for incompatible implementations.

>     it compatible immediately with the GMPLS MIBs

I like this approach the most from the three listed by Adrian some time 
ago. All have some problems, but this one works for me.

Marcus
--------------------------------------
Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
Mobile: +49 (0) 163 275 17 43
personal home page: http://www.brubers.org/marcus

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 16 Jun 2003 14:37:01 -0400

> From: Marcus Brunner [mailto:[email-masked]] 
> Sent: Monday, June 16, 2003 9:38 AM
> This sounds like a problem of information management on the 
> box and has IMHO nothing to do with a MIB design to be useful for
Management 
> Applications.

	Do you have an implementation of this MIB 
and is it distributed that you would care to 
return implementation experience on?

> Indexing always has implications on sorting in the management 

	Generally negative ones when the indexing 
is created to be ideal.

> approach with an app index. I assume the app index will be 
> coded into the 24 octet string anyway so why not making 
> it explicit?

	Becuause it adds another index to the indexes.
This has the unfortunate side-effect of making other MIBs
that might reference these indexes (i.e.: LDP/TE/FTN)
more complex.  If you implement MIBs then you understand
that the addition of indexes often leads to more work
on the agent's part and thus a slower implementation. If
you can achieve the same things with a single index,
this seems like the right thing to do.

> Sounds like an offer for incompatible implementations.

	You need to be more specific about what you mean
by that, because I did not imply that this lead to 
incompatabilities. It seems pretty clear to me that whether 
you encode 4 bytes as an Unsigned32 or an octet string,
you get the same semantic meaning.  

	--Tom