The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Suggested improvements to the Fast Reroute MIB definition in draft-ietf-mpls-fastreroute-mib-01
>-----Original Message-----
>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf
>Of Nic Neate
>Sent: Friday, October 10, 2003 11:12 AM
>To: 'riza.cetin@alcatel.be'
>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
>
>
>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?
Only if they can report that information. :P
--Tom
>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.
>
|
|