The MPLS WG Archive

[stefaan.de_cnodder@alcatel.be]

Hi Ina,

see below...

> 
> 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".
> 
> Same for
>  mplsFrrActProtectedIfs OBJECT-TYPE
>        SYNTAX        Unsigned32
>        MAX-ACCESS    read-only
>        STATUS        current
>        DESCRIPTION
>          "Indicates the number of interfaces currently being protected
>           by the FRR feature if mplsFrrConstProtectionMethod is set to
>           facilityBackup(2), otherwise this value should return 0 to
>           indicate that LSPs traversing any interface may be protected.
>           This value MUST be less than or equal to mplsFrrConfIfs."
>        DEFVAL { 0 }
>        ::= { mplsFrrScalars 6 }
> 
> --------------------
> 
> 2) Confusion regarding the values of oneToOneBackup and
>    facilityBackup.
> 
> mplsFrrDetourIncoming
> "The number of detour LSPs originating at this PLR if
>          mplsFrrConstProtectionMethod is set to oneToOneBackup(1).
>          This object MUST return 0 if the mplsFrrConstProtectionMethod
>          is set to facilityBackup(2)."
> 
> From this I understand that the values are oneToOneBackup(1),
> facilityBackup(2).
> 
> 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? 

The numbering is indeed not correct.

> -----------------------
> 
> 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.
> 
> ---------------------
> 4) Question - Properties of mplsFrrConstEntry
> 
> mplsFrrConstEntry OBJECT-TYPE
>        SYNTAX        MplsFrrConstEntry
>        MAX-ACCESS    not-accessible
>        STATUS        current
>        DESCRIPTION
>          "An entry in this table represents detour LSP or bypass tunnel
>           setup constraints for a tunnel instance to be protected by detour
>           LSPs or a tunnel.
> 
>           Agents must allow entries in this table to be
>           created only for tunnel instances that require fast-reroute.
>           Entries indexed with mplsFrrConstIfIndex set to 0 apply to all
>           interfaces on this device for which the FRR feature can operate
>           on."
> 
> Why do we want to have the properties of the tunnel instance instead
> of the constraints for the tunnel itself?
> 

2 tunnel instances can have different properties. For instance I
have two instances and I am loadbalancing the traffic between them,
but these two have different bandwidths, then it might be useful to
have an entry is this table per instance and not per tunnel. Does
this answer your question?


> -------------------
> 5) Question on the tunnel index
> 
>  mplsFrrConstTunnelIndex OBJECT-TYPE
>        SYNTAX        MplsTunnelIndex
>        MAX-ACCESS    not-accessible
>        STATUS        current
>        DESCRIPTION
>          "Uniquely identifies a tunnel for which fast reroute is
>           requested."
>        ::= { mplsFrrConstEntry 2 }
> 
>     mplsFrrConstTunnelInstance OBJECT-TYPE
>        SYNTAX        MplsTunnelInstanceIndex
>        MAX-ACCESS    not-accessible
>        STATUS        current
>        DESCRIPTION
>          "Uniquely identifies an instance of this tunnel for which fast
>           reroute is requested.
> 
>          - lower 16 bits : protected tunnel instance
>          - higher 16 bits: must be all zeros"
>        ::= { mplsFrrConstEntry 3 }
> 
> mplsFrrConstTunnelIndex OBJECT-TYPE - what would be the required value here?
> 

Not really clear what you mean: the TunnelIndex is the tunnel index
of the tunnel being protected...



> ----------------
> 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. 


> --------------
> 7) Typo (sorry of nitpicking)
> mplsFrrTunARHopEntry  OBJECT-TYPE
>        SYNTAX             MplsFrrTunARHopEntry
>        MAX-ACCESS         not-accessible
>        STATUS             current
>        DESCRIPTION
>          "This entry contains fast-reroute protection status of a signle
>                                                                  ^^^^^^^
> 
> -------------------
> 8) Question on mplsFrrLogEntry
> 
> It seems we have two choices - no logging or log until reaching the
> limit. Why not also have an option for wrapaournd ? What is the value
> of holding on to old log entries forever? Would an operator comment of how
> this is used? Wouldn't the nms pick up the values from here and store them
> remotely?
> 
> ---------------
> 9) Questions on One2one backup
> 
> We don't have a variable that specifies the bw on the detour. Don't we
> need one?
> 
> There are no notifications for the 1-to-1 backup. Wouldn't we want to
> track when an lsp starts using the detour and when it stops using it?

I checked the TE MIB and there are up and down notifications defined
at the tunnel level. There are no up/down notifications at the
instance level and since also notifications for the one2one case
would be at the instance level I believe it is better not to have
notifications.

I have not checked with the co-authors but I would like to hear
their opinion as well, as well as other people's opinion of course.

regards,

Stefaan