Thanks Anton - I agree with that this enhancement should support P2MP as well. Note that the disclosed IPR abstracts the LSA scoping to a stub-site specific database so P2MP and other use cases, e.g. parallel links to the same site, can be accommodated.
http://www.google.com/patents/US20140010117 Acee On 1/31/16, 3:14 PM, "Anton Smirnov (asmirnov)" <[email protected]> wrote: > Hello, > Hub-and-Spoke topology is a known topology where OSPF traditionally >performed poorly and in my opinion work in this area is very important. > On the other hand, I have number of concerns regarding usability of >approach chosen in this draft and I think in its current state the draft >is not ready for WG adoption. > I have big concerns regarding implementation simplicity and solution >applicability (i.e. hub-and-spoke networks where proposed solution >doesn't work). But first of all I want to make a comment on the text as >it is. > Some hub-and-spoke topologies are point-to-multipoint networks. 10 >years ago it was a fraction of all hub-and-spoke WAN, nowadays it is a >majority. Draft doesn't consider multipoint operations (at least it >doesn't have word 'multipoint' in it). But multipoint has very big >implications on having multiple spoofed Router LSAs and their filtering >- since all stub neighbors are on the same interface, one can't use >per-interface filtering (which is tightly related to per-interface >flooding). Spoofed Router LSA will have a new type of flooding behavior >- per-neighbor. This is doable but it is not specified anywhere and is >not coded by any implementation I am aware of (i.e. existing filtering >mechanisms are between different interfaces, not between neighbors on >the same multipoint interface). > So the draft needs to define new LSA flooding scope - per-neighbor >flooding scope, much like interface-scope flooding had to be devised for >Opaque LSAs. > This is not all for implementation complexity not covered in the >draft but it will be a good start. > >Anton > > >On 01/26/2016 05:39 PM, Acee Lindem (acee) wrote: >> This draft was has gone through some refinements after being presented >>in >> Hawaii and in Yokohama there was some support of this protocol >>extension. >> Here is a URL for you convenience. >> >> https://datatracker.ietf.org/doc/draft-raza-ospf-stub-neighbor/ >> >> Please indicate your support (or concerns) for adopting this as a WG >> Document. The WG Adoption call will end in 2 weeks. >> >> Thanks, >> Acee >> >> >> _______________________________________________ >> OSPF mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ospf >> _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
