Russ - Having reviewed the draft, I have the following high level comments:
1)Section 3 defines an algorithm which is used to "calculate" the flooding topology. As such, this draft is not an alternative to draft-ietf-lsr-dynamic-flooding. It is simply one of potentially many drafts which may be written which will define such an algorithm, Note that definition of algorithms is outside the scope of draft-ietf-lsr-dynamic-flooding. The algorithm defined in your draft is by its nature a distributed algorithm i.e., your algorithm cannot be supported in centralized mode as defined by draft-ietf-lsr-dynamic-flooding. However, nodes could advertise/agree on using this algorithm as a distributed algorithm using the signaling mechanisms defined in draft-ietf-lsr-dynamic-flooding. I think this should be made clear in your draft. 2)The use of Circuit Scoped LSPs (RFC 7356) to flood standard L1/L2 LSPs to "DNR" nodes as defined in Section 3.1 of the draft is an invalid usage of CS-LSPs. The content of CS-LSPs is NOT identical to standard LSPs and the 1:1 equivalence you seem to require is inconsistent with RFC 7356. 3)The adjacency formation logic discussed in Section 2 isn’t directly relevant to calculating a flooding topology. There are existing implementations which use the techniques you define as a means of reducing redundant flooding associated with adjacency bringup when there are parallel links between two nodes. Note this can be (and is) done without requiring protocol extensions/specification i.e., a node can do this today without introducing any interoperability issues. So while this is definitely a good idea, it isn’t directly related to the work on flooding topologies and I think is better removed from the draft. Les > -----Original Message----- > From: Lsr <[email protected]> On Behalf Of [email protected] > Sent: Sunday, March 31, 2019 6:18 PM > To: Les Ginsberg (ginsberg) <[email protected]>; [email protected] > Subject: Re: [Lsr] FW: New Version Notification for draft-white-distoptflood- > 00.txt > > > > The WG just went through a lengthy consideration of multiple flooding > > optimization drafts and selected https://datatracker.ietf.org/doc/draft- > ietf- > > lsr-dynamic-flooding/ as the vehicle for the WG to use to move forward in > > this area. > > Yep. > > > It would be good if, in the context of the above, you articulated why it > makes > > sense for the WG to do yet another round of such discussion. > > == > In this idea, the flooding topology is computed within an IGP area > with the dense topology either centrally on an elected node, termed > the Area Leader, or in a distributed manner on all nodes that are > supporting Dynamic Flooding. > == > > Because this is only one way to solve the problem... The process outlined in > the draft I just published is a different and simpler way that applies to a > wider > range of topologies than the dynamic flooding draft does, afaict. > > 😊 /r > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
