The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] 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 > >Nic > >> >> In my opinion the current MIB structure perfectly makes sense. >> >> JP. >> > |
|