Hi Paul, On May 4, 2010, at 1:12 PM, Paul Wells wrote:
> Hi Acee, > > Acee Lindem wrote: >> Speaking as WG member: >> >> I am not opposed to this capability. However, I'm not sure if it justifies >> taking two of the remaining router bits. The Router-Information LSA (RFC >> 4970) is really the place for advertising capabilities. > > We understand this concern and are in the process of drafting a > new revision that moves the "S" bit to the RI opaque LSA. Note, > though, that the definition of the Router Informational > Capabilities TLV in RFC 4970 explicitly says "...the informational > capabilities advertised have no impact on the OSPF protocol's > operation..." so we're defining a new "operational capabilities" > TLV to hold this and any future "important" bits. I remember we made the RFC 4970 statement due to debate during IESG review regarding backward compatibility for existing capabilities. Adding a new TLV for new capabilities that do impact protocol operation sounds like a great idea. > >> It would be ideal if this could be done without an implicit backward >> compatibility mechanism. Doing an election just to see if all routers in the >> area are able to recognize the R-bit is complexity that would be nice to >> avoid. The draft recommends both setting the R-bit and advertising any >> transit links with 0xffff cost. Hence, It would be an odd topology where the >> differences in R-bit capability could cause a routing loop. Unfortunately, >> it is possible to draw one if you there is a valid path to a destination D, >> and that destination is accessible via multiple routers with varying R-bit >> capabilities :^(. > > It would be nice, but I don't see any alternative that can be > guaranteed to be correct for all topologies. We discussed this over a beer and the only thing we could come up with was putting the configuration and responsibility in the hands of the system administrator (since IGPs are under the control of a single administrative domain). However, this would be a departure from what we've done heretofore in the OSPF WG. Thanks, Acee > > Thanks, > Paul > >> >> Thanks, >> Acee >> >> >> On Apr 16, 2010, at 4:44 PM, Acee Lindem wrote: >> >>> At the OSPF WG meeting in Anaheim, the subject draft was presented and >>> there seemed to be some interest in such a capability (similar to the >>> overload bit in ISIS). Please indicate whether or not you support making >>> this draft a WG document. >>> >>> http://www.ietf.org/id/draft-pillay-esnault-ospf-rbit-00.txt >>> >>> Thanks, >>> Acee - (as OSPF WG Co-chair) >>> _______________________________________________ >>> OSPF mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ >> OSPF mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
