The MPLS WG Archive

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

I was reviewing a pre-release of revision 8 and ran into
a serious issue, which I have reported to the authors/editors.

The same issue exists in revision 07, so for the record
I want to alert the WG about it. Here we go.

I am not done with review of this doc yet.
But I see one SERIOUS issue that I rather point out
now than later.

Back with revision 6 or so I wrote:

> > The mplsFTNMapEntry DESCRIPTION clause says:
> > 
> >         entry. This linked-list indexing style structure allows
> >         FTN entries to be inserted at arbitrary positions in
> >         the list. 
> > Maybe it is me, but I still fail to see how this can be true.
> > Can you explain that for me?
> 
And Cheenu (I believe) answered:

> I have included all relevant explanation about this table's indexing
> (essentially material from section 5.2 but making the MIB module self
> contained) in the DESCRIPTION clause of mplsFTNMapTable. Please take
> a look at that and tell me if this is clear now.
> 

Well, I look at the new MIB and the new descriptions in section 5.
And all I can conclude is that according to the SNMP protocol
this is completely unacceptable.
If I understand it correctly, then to insert a row, you issue
(in your example in sect 6.3) a SNMP SET command as follows:
(I know this is not the exact format, but you get the idea)

   SNMP SET ( mplsFTNMapIndex = 1,
              mplsFTNPrevIndex = 1,
              mplsFTNMapCurrIndex = 3
              -- it also has a rowStatus and a StorageType
             ) -- so you create mplsFTNMapEntry  1.1.3

Before you do so, the table had these entries (the number are the
indices for the entries)

   1.0.1
   1.1.2

The normal SNMP SET result is these 3 entries:

   1.0.1
   1.1.2
   1.1.3

But you seem to describe that the side effects of you creating row
1.1.3, the other entry 1.1.2 gets changed, and that the resulting
table will have these entries:

  1.0.1
  1.1.3
  1.3.2

That to me seems a TOTALLY UNACCEPTABLE behaviour for the SNMP
SET operation that was received.

Similar, once you have that set of 3 tables entries that you describe,
you suggest that a SNMP SET to destroy entry 1.1.3

The normal SNMP SET result would be a table of these 2 entries,

  1.0.1
  1.3.2

but you describe that the SNMP agent should have some side effect
which results in a table with these entries:

   1.0.1
   1.1.2

First, did I understand the descriptions correctly?
If not pls tell me where I am wrong.

If I did understand it correctly, how do you think that a normal
SNMP agent or manager can deal with the side-effects you are
describing. It seems totally against the normal behaviour of
SNMP SET operation and SNMP agent and manager behaviour.

Once you tell me that my reading of section 5.2 and the examples
in section 6 is correct, I will check with the rest of the MIB
doctors, but I suspect that they will unanimously agree with me.

Thanks,
Bert