The MPLS WG Archive

[riza.cetin@alcatel.be]

Hi Nic,

It is good to see that version 02 solves most of your issues.

Concerning mplsFrrConsTable:
It does not make sense to have this table also in the transit detour nodes. In
version 02, every detour LSP will have an entry in the mplsTunnelTable (TE-MIB)
and an entry in the mplsFrrDetourTable (FRR-MIB). The constraints of the detour
LSP (which are signaled via RSVP) will be available in the detour entry of the
mplsTunnelTable. These are actually the constraints configured at the PLR (in
the mplsFrrConstTable).

This means that detour FRR constraints are already available in the
mplsTunnelTable at the detour transit nodes, so no need to replicate them.

Concerning the protection method, I will take it up with Tom asap.

Riza.

Nic Neate wrote:

> Thanks Riza,
>
> It is helpful to see version 02 of the draft.  In particular
>  - explicitly stating the advertising of detour LSPs in the mplsTunnelTable
> makes things a lot clearer
>  - you clarify that the mplsFrrConstTable is used for both facility and
> one-to-one backup, so that clears up my first suggested change.
>
> Your comment that the mplsFrrConstTable is only intended for configuration
> at ingress makes the indexing clearer.  It would be good to have that
> clarified in the draft as well.  However, this seems like an unnecessary
> restriction to me - would it not also be useful to have this information
> reported at transit nodes on the protected LSP?
>
> That leaves just one outstanding suggestion - that the protection method be
> configurable per-LSP in the mplsFrrConstTable, as supported by the FRR
> draft.  I look forward to hearing the outcome of your discussions with Tom.
>
> Nic
>
> -----Original Message-----
> From: riza.cetin@alcatel.be [mailto:riza.cetin@alcatel.be]
> Sent: Friday, October 10, 2003 2:06 PM
> To: Nic Neate
> Cc: Cisco - Thomas Nadeau; 'stefaan.de_cnodder@alcatel.be'; Juniper -
> Der-Hwa Gan; 'jvasseur@cisco.com'; 'mpls@uu.net'
> Subject: Re: Suggested improvements to the Fast Reroute MIB definition
> in draft-ietf-mpls-fastreroute-mib-01
>
> Nic,
>
> We have done a lot of changes mainly on the detour related tables. The new
> version has not been submitted yet. Please find attached the new version and
> my
> answers to your questions below.
>
> Riza.
>
> Nic Neate wrote:
>
> > Hi all,
> >
> > I've not had any further discussion on this for a while.  This is a
> summary
> > of what I'm suggesting, taking into account the points people have made,
> and
> > what we've already resolved.  Please get back to me with any disagreement
> or
> > new arguments.
> >
> > Thanks,
> >
> > Nic
> >
> > Agreed corrections to the draft
> > ===============================
> >
> > 1.  Reflect in the description of the mplsFrrConstHopLimit field that the
> > information is not available at transit detour nodes.  Suggested text:
> >
> >       DESCRIPTION
> >         "The maximum number of hops that the detour LSP may traverse.
> >          This field is not relevant and should be ignored if this
> >          entry in the mplsFrrConstTable is being used in the context
> >          of representing a detour LSP."
>
> This table is ONLY used at the ingress node of the protected tunnel instance
> to
> configure backup LSP setup constraints. So it is not relevant for the detour
> transit nodes.
>
> >
> >
> > 2.  Typo: change mplsFrrConstExclAllAffinity to
> mplsFrrConstExclAnyAffinity.
>
> Done.
>
> >
> >
> > 3.  In section 5.3, change "mplsFrrDetourXCPointer" to
> > "mplsTunnelXCPointer".  In the DESCRIPTION of mplsFrrDetourActive, change
> > "mplsFrrDetourRole" to "mplsTunnelRole".
> >
>
> This object has been removed from the new version of the draft.
>
> >
> > Outstanding suggested changes
> > =============================
> >
> > 1.  The mplsFrrConstTable should be a common table for both facility and
> > detour backup.  Currently it is defined to show "detour setup
> constraints".
> > However, the fields map precisely to those in the RSVP FAST_REROUTE object
> > and the FRR draft specifies that the FAST_REROUTE object applies equally
> to
> > both facility and detour backup.  Thus the table is required equally for
> > facilty and detour backup.
> >
>
> To be discussed with Tom Nadeau.
>
> >
> > 2.  The mplsFrrConstProtectionMethod should be a field in the
> > mplsFrrConstTable, not a scalar.  The FRR draft allows an LSR to
> > simulateously support LSPs using both facility and detour backup.  This is
> > likely to happen in real world networks, in particular when a network is
> > being migrated from one protection type to another.  Hence the protection
> > method needs to be configurable/reportable per-LSP, not just per-LSR.  I
> > suggest the follow text for the MIB.
> >
> >    mplsFrrConstProtectionMethod OBJECT-TYPE
> >       SYNTAX        INTEGER { oneToOneBackup(0),
> >                               facilityBackup(1)
> >                             }
> >       MAX-ACCESS    read-write
> >       STATUS        current
> >       DESCRIPTION
> >         "Indicates which protection method is to be used for fast
> >          reroute."
> >       ::= { mplsFrrConstEntry 4 }
> >
>
> To be discussed with Tom Nadeau.
>
> >
> > 3.  The indexing of the mplsFrrConstTable needs fixing.  The current three
> > indicies (interface index, tunnel index and tunnel instance) are
> > insufficient.  For example, two protected LSPs could meet at a transit
> node,
> > both with different ingress and egress but the same values for each of the
> > existing mplsFrrConstTable indices.  If those protected LSPs have a
> > different value for, say, the mplsFrrConstSetupPrio then they need
> different
> > entries in the mplsFrrConstTable.
> >
> > Rather than adjusting the current indexing, I suggest replacing the three
> > existing indices with a single integer index, mplsFrrConstIndex.  This
> index
> > can then be referenced from the mplsTunnelTable, establishing a simple
> > indexing system with clear relationships between the tables (which is also
> > in line with existing relationships between tables in the TE-MIB and
> > LSR-MIB).
> >
> > Briefly, this would require the following.
> > - New mplsFrrConstIndex field in the mplsFrrConstTable, replacing the
> three
> > existing indices.
> > - New mplsFrrTunnelFrrConstIndex/Pointer field in the mplsTunnelTable,
> > pointing to the mplsFrrConstTable entry for this tunnel.
> >
> > Some full suggested text follows.
> >
> > For the mplsFrrConstTable:
> >
> >    MplsFrrConstIndex ::= TEXTUAL-CONVENTION
> >       STATUS        current
> >       DESCRIPTION
> >         "Index into mplsFrrConstTable."
> >       SYNTAX  Integer32 (1..65535)
> >
> >    mplsFrrConstIndex OBJECT-TYPE
> >       SYNTAX        MplsFrrConstIndex
> >       MAX-ACCESS    not-accessible
> >       STATUS        current
> >       DESCRIPTION
> >            "Uniquely identifies this row."
> >       ::= { mplsFrrConstEntry 1 }
> >
> > For the mplsTunnelTable:
> >
> >    -- MPLS Fast Reroute Tunnel Table
> >
> >    mplsFrrTunnelTable            OBJECT-TYPE
> >       SYNTAX                     SEQUENCE OF MplsFrrTunnelEntry
> >       MAX-ACCESS                 not-accessible
> >       STATUS                     current
> >       DESCRIPTION
> >          "This table extends the mplsTunnelTable defined in the
> >           MPLS-TE MIB to provide Fast Reroute configuration."
> >       ::= { mplsFrrGeneralObjects 1 }
> >
> >    mplsFrrTunnelEntry            OBJECT-TYPE
> >       SYNTAX                     MplsFrrTunnelEntry
> >       MAX-ACCESS                 not-accessible
> >       STATUS                     current
> >       DESCRIPTION
> >          "This entry provides Fast Reroute configuration for the
> >           tunnel."
> >       AUGMENTS { mplsTunnelEntry }
> >       ::= {mplsFrrTunnelTable 1}
> >
> >    MplsFrrTunnelEntry ::= SEQUENCE {
> >       mplsFrrTunnelFrrConstPointer      RowPointer
> >    }
> >
> >    mplsFrrTunnelFrrConstPointer   OBJECT-TYPE
> >       SYNTAX                      RowPointer
> >       MAX-ACCESS                  read-create
> >       STATUS                      current
> >       DESCRIPTION
> >            "This variable represents a pointer to the Fast Reroute
> >              parameter specification for this tunnel.  This value may
> >              point at an entry in the mplsFrrConstTable to indicate
> >              which mplsFrrConstEntry is to be assigned to this LSP
> >              instance.  This value may optionally point at an
> >              externally defined Fast Reroute parameter specification
> >              table.  A value of zeroDotZero indicates default Fast
> >              Reroute parameters if the fastReroute bit in the
> >              mplsTunnelSessionAttributes is set, and otherwise no Fast
> >              Reroute protection."
> >       DEFVAL        { zeroDotZero }
> >       ::= { mplsFrrTunnelEntry 1 }
> >
> >    END
>
> This table is only intended to be used at the ingress nodes initiating the
> backup LSPs. It will not be present at the transit detour LSPs. So, I don't
> see
> a need to change the indexing.