The MPLS WG Archive

[Ina Minei <ina@juniper.net>]

	Stefan,

	Please see inline ###.

			Ina

On Wed, 17 Mar 2004 stefaan.de_cnodder@alcatel.be wrote:

> >
> > 1) Problem expressing a situation where no frr is configured on any interface
> >
> > mplsFrrConfIfs OBJECT-TYPE
> >        SYNTAX        Unsigned32
> >        MAX-ACCESS    read-only
> >        STATUS        current
> >        DESCRIPTION
> >          "Indicates the number of MPLS interfaces configured for
> >           protection by the FRR feature, otherwise this value
> >           MUST return 0 to indicate that LSPs traversing any
> >           interface may be protected."
> >          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >        DEFVAL { 0 }
> >        ::= { mplsFrrScalars 5 }
> >
> > The defval = 0 is misleading in this case. If I have no frr on any of
> > the interfaces, there is no way for me to express that, unless the
> > descrioption should say "may not be protected".

### I still don't get it. 0 means all interfaces then? And I would have to
look at the protection type to determine that the value of the interface
variable is valid? Why not simply say "0 means none of the interfaces is
protected". Either way, the current description is confusing and should be
updated.

-----------------------------

> > 2) Regarding the values of oneToOneBackup and
> >    facilityBackup.
[snip]
> >
> > However, the definition is different:
> >
> > mplsFrrConstProtectionMethod OBJECT-TYPE
> >        SYNTAX        INTEGER { oneToOneBackup(0),
> >                                facilityBackup(1)
> >
> > The same values of 1 and 2 appear in the description of other
> > variables, such as mplsFrrDetourOutgoing.
> >
> > Also I was wondering why "none" was not a valid value for
> > mplsFrrConstProtectionMethod, it would seem to make sense as well.
> >
>
> Having such a none makes nense to me as well. It solves also comment
> 1 above: e.g., mplsFrrConfIfs is only meaningful when
> mplsFrrConstProtectionMethod is none. In fact, having such a "none"
> option means that the whole MIB is not meaningful, with the
> exception of the LogTable: if the configuration is moved to none,
> there could still be entries in the LogTable. Do you agree with
> this?
>
### Yes, agreed. The log table may be lingering from a time when the
feature was configured.
However, I have quite a few reservations about the definition and use of
the log table. Please see my original mail.


> The numbering is indeed not correct.
>

### Which way are you going to change it? (I vote for the non-zero
values)


> > -----------------------
> >
> > 3) Notifications
> >
> > Do we really want to have notifications emitted with msec granularity?
> >
> > mplsFrrProtected
> > mplsFrrUnProtected
> >
> > The way these two are currently defined, it will be very hard to
> > correlate protect/unprotect traps, and indeed it is not
> > guaranteed that the unprotect trap will be sent.
> > The least we could do is to require that if you sent a protect for
> > a particular tunnel, make sure to send the unprotect. This is after
> > all just one trap.
> >
> > From previous experience with lsp up/down traps, what customers
> > want is to be able to correlate the events. The rate limiting that is
> > applied creates havoc in this correlation. But a simple mechanism can
> > be set in place to ensure the correlation in the software.
> >
> > Perhaps an operator will also comment on this.
> >

### Any comment on this one?


> > ----------------
> > 6) Question on protection type
> >
> >  mplsFrrConstProtectionType OBJECT-TYPE
> >        SYNTAX        INTEGER { none(0),
> >                                linkProtection(1),
> >                                nodeProtection(2)
> >                              }
> >        MAX-ACCESS    read-create
> >        STATUS        current
> >        DESCRIPTION
> >          "Indicates type of the resource protection."
> >        DEFVAL { nodeProtection }
> >        ::= { mplsFrrConstEntry 4 }
> >
> > Why do we have the value of "none" defined here? Isn't this for an
> > entry that represents either a detour or a bypass? Then how can there
> > be no protection?
> >
>
> Good question. It looks like an LSP having
> mplsFrrConstProtectionType equal to none(0) should not have an entry
> is this table.

### We should either remove the "none" or say that it is an invalid value.