> 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.
Correct. This was my initial impression when I read draft-ietf-lsr-dynamic-flooding. > I think this should be made clear in your draft. Sure -- I can add this bit. > 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. Hm... I will need to look at this -- it might be worth chatting about this off line to see how to bring this in line. > 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. Okay -- it seems like this technique is not documented anyplace, and could be used for all adjacencies. 😊 /r _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
