The MPLS WG Archive

["Adrian Farrel" <afarrel@movaz.com>]

Talking with Tom about this off-line we arrived at the following (startling?)
conclusion.

> It would, however, appear that we have reached the nub of the matter. The
> problem with the unformatted octet string aproach is in providing write
access,
> and (I'm guessing) the reason why this has become a hot debate is that I have
> been looking to provide write access and you have not been very bothered by
> whether that function works or not.
>
>
> So, there's an easy answer...
> People who use complex formatting of the octet string don't care about write
> access.
> People who use write access don't care about complex formatting of the octet
> string.

The suggestion we have is to add text (somewhere) to highlight this point.
For example...

>      In systems that provide write access to the LSR MIB, the mplsIndexType
>      SHOULD be used as a simple multi-digit integer encoded as an octet
string.
>      No further overloading of the meaning of an index SHOULD be made. The
>      mplsGetNextInSegmentIndex and similar objects should provide a
>      monotonic increasing value of indexes.
>
>      In systems that do not offer write access to the LSR MIB, the
>      mplsIndexType may contain implicit formatting that is specific to the
>      implementation to convey additional information such as interface index,
>      physical card or device, or application id. The interpretation of this
>      additional formatting is implementation dependent and not covered in this
>      document. Such formatting MUST NOT impact the basic functionality of
>      read-only access to the LSR MIB by management applications that are
>      not aware of the formatting rules.

This would address all of the issues about formating of the "index string".

Adrian