The MPLS WG Archive

[Nic Neate <Nic.Neate@dataconnection.com>]

> -----Original Message-----
> From: Cisco - Thomas Nadeau 
> Sent: Tuesday, September 30, 2003 5:02 PM
> To: Nic Neate; 'Jean Philippe Vasseur'
> Cc: mpls@uu.net; riza.cetin@alcatel.be; stefaan.de_cnodder@alcatel.be;
> Juniper - Der-Hwa Gan
> Subject: RE: JP Please Look At this
> 
> 
> 
> 
> >-----Original Message-----
> >From: Nic Neate [mailto:Nic.Neate@dataconnection.com] 
> >Sent: Tuesday, September 30, 2003 11:42 AM
> >To: 'Jean Philippe Vasseur'
> >Cc: mpls@uu.net; riza.cetin@alcatel.be; 
> >stefaan.de_cnodder@alcatel.be; Juniper - Der-Hwa Gan; Cisco - 
> >Thomas Nadeau
> >Subject: RE: JP Please Look At this
> >
> >
> >JP,
> >
> >Responses are inline.  My main concern here is that the FRR 
> >MIB should be
> >consistent with the FRR draft.
> >
> >Thanks, Nic
> >
> >> -----Original Message-----
> >> From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com]
> >> Sent: Tuesday, September 30, 2003 1:49 PM
> >> To: Nic Neate
> >> Cc: mpls@uu.net; riza.cetin@alcatel.be; 
> >stefaan.de_cnodder@alcatel.be;
> >> Juniper - Der-Hwa Gan; Cisco - Thomas Nadeau
> >> Subject: Fwd: JP Please Look At this
> >> 
> >> 
> >> Nic,
> >> 
> >> See comments in line,
> >> 
> >
> ><snip>
> >
> >> > >mplsFrrConstProtectionMethod scalar
> >> > >===================================
> >> > >
> >> > >This scalar configures the protection method that is to be
> >> > >used.  Currently,
> >> > >this applies to all LSPs traversing the LSR, however this
> >> > >option should be
> >> > >configurable per-LSP.  Hence the mplsFrrConstProtectionMethod
> >> > >should rather be a field in the mplsFrrConstTable.  This 
> >> allows an LSR
> >> >to
> >> > >simultaneously support LSPs using both protection methods, and
> >> >interoperate
> >> > >between them, as allowed by the Fast Reroute draft.
> >> 
> >> The FRR draft allows to support both one-to-one and facility 
> >> backup and the 
> >> preference for one method or the other can be signalled in 
> >> the FAST REROUTE 
> >> object but on a single hop, one *or* the other will be used 
> >> to protect a 
> >> single fast reroutable, not *both*.
> >
> >That's exactly my point - each LSP will use a single FRR 
> >protection method,
> >which hence should be configured in the mplsFrrConstTable.
> >
> >> Moreover, bear in mind 
> >> that from a 
> >> realistic standpoint, the likelihood that both method are 
> >> deployed in the 
> >> same network is not very high, except during a transition period.
> >
> >Yes, I agree, but the FRR draft does nonetheless allow for a 
> >single LSR to
> >simultaneously support both protection methods.  The FRR MIB 
> >must therefore allow that as well.
> 
> 	Well, it does in a very clean way. It just doesn't in
> the way you are asking for. *) Let me reiterate the reasoning
> behind the current structure which splits the mib into
> three pieces: a common piece, one2one, and facility sections.
> 
> 	1) 	This separation makes it more easy to implement.
> 		If you support one mechanism or another,
> 		you can pick and choose which tables to implement.
> 		The code you generate from the MIB is very
> 		straight-forward. If you for example, want to
> 		implement one2one, you delete all of the facillity-
> 		related code that your compiler generates.
> 
> 	2) 	This separation makes it easier for a device to 
> 		comply with	the standard MIB.  There is no confusion
> 		about which objects apply to which mechanism.
> 
> 	3)	There is less potential for error on the authors'
> 		parts too, because we don't have to worry about
> 		having special parts of description clauses for
> 		each mechanism, or worry about discussing which
> 		object applies depending on the FRR mode.
> 
> 	4)	This makes implementations more efficient because
> 		they will not return columns that do not make
> 		sense for a particular FRR mode. The assumption
> 		is that most implementations will deploy one mode
> 		or another at any given time, so having them
> 		return useless columns wastes CPU time, network
> 		bandwidth, and generally is a waste.
> 
> 	5)	It makes it very convienent for a manager
> 		to quickly and easily go and look at tables
> 		specific to the FRR mechanism they are employing
> 		in their network. If they happen to be in a transition
> 		from one type to another, the device can certainly
> 		return entries from the other mechanism's table
> 		until the transition is completed.
> 
> 	--Tom
> 

That all makes perfect sense.  The mplsFrrConstTable belongs in the common
section of the MIB though.  I should have made that clear from the
beginning.  Without that, there is no way to configure the FAST_REROUTE
object when using facility backup.

All of the fields in this table apply equally to facility and one to one
backup, with no special "Description" clauses required.  That makes it the
natural place to also say whether this tunnel uses facility or one to one
backup.

Nic

> 
> 
> >
> >Nic
> >
> >> 
> >> In my opinion the current MIB structure perfectly makes sense.
> >> 
> >> JP.
> >> 
> >
>