Subject: Re: [OSPF] OSPFv2 No Transit Capability - draft-pillay-esnault-ospf-rbit-00

From: Acee Lindem <[email-masked]>
Date: Tue, 4 May 2010 12:33:02 -0400

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.

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 :^(. 

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-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: Paul Wells <[email-masked]>
Date: Tue, 04 May 2010 12:12:52 -0500

Hi Acee,

> 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 capabil…

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.

> 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…

It would be nice, but I don't see any alternative that can be 
guaranteed to be correct for all topologies.

Thanks,
Paul

---

From: Acee Lindem <[email-masked]>
Date: Tue, 4 May 2010 17:30:44 -0400

Hi Paul,

> 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. 

> 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