Russ -
I think you have too many email addresses. đ Inline. > -----Original Message----- > From: op...@riw.us <op...@riw.us> > Sent: Monday, January 04, 2021 10:01 AM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; 7ri...@gmail.com; > 'Shraddha Hegde' <shrad...@juniper.net>; lsr@ietf.org > Subject: RE: [Lsr] New Version Notification for draft-white-lsr-distoptflood- > 00.txt > > > > [Les:] Signaling is required in your solution to indicate whether the > neighbor > > should/should not propagate the LSP(s) received from a given neighbor. > > But Circuit Scoped LSPs as defined in RFC 7356 do not provide this > functionality. > > > > A Circuit Scoped LSP is to be used to send information originated by a node > to a > > specific neighbor of that node. This information has circuit scope - meaning > it is > > NEVER meant to be flooded on other circuits. > > It is not an encapsulation mechanism to forward area/domain scoped LSPs > > originated by other nodes in the network. > > I guess I'm not seeing the conflict here ... I'm okay with defining a new way > to > signal an LSP should not be reflooded, but it seems like re-using the existing > mechanism is a better way to move forward. > [Les:] There is no "existing mechanism". Please look a bit closer. https://www.rfc-editor.org/rfc/rfc7356.html#section-3.1 defines the format of the header of a FS-LSP. In particular, the LSP-ID is defined as: +-------------------------+ | Source ID | ID Length +-------------------------+ | Pseudonode ID | 1 +-------------------------+ | FS LSP Number | 1 +-------------------------+ Now, suppose node A needs to originate both: a)A Level-1 LSP (Scope 4) b)A Level-1 Circuit Scoped LSP (Scope 1) The LSP-ID for both of these LSPs will be: A.00-00 Since you propose that both of these LSPs be sent as a Circuit Scoped LSP the receiver will be unable to tell the difference. You simply cannot do what you propose. > > [Les:] I assume what you are referring to here is MANET and the Multipoint > > Relay (MPR) functionality. > > No -- RFC5820, which was implemented by Cisco, and is widely deployed. [Les:] RFC5820 is titled âExtensions to OSPF to Support Mobile Ad Hoc Networkingâ And there are signaling extensions defined in the RFC for which you jave no equivalents in your draft. As I previously commented, in your proposal, how do you know whether a node supports the extensions or not? This seems quite necesssary to your proposal. > > > [Les:] It does seem that you do NOT want to use dynamic flooding > extensions. > > Which makes me wonder why you suggest (Section 3) the election of an > Area > > Leader. What purpose does this serve in your solution? > > When this draft was first proposed, I received several emails stating it MUST > fit within the framework of the larger framework document, so I proposed a > way to indicate this type of flooding reduction within that larger framework. > There is no "leader" in this draft of any kind. > > There seem to be two general criticisms here. The first is that it doesn't fit > into the general pattern of "elect a leader of some kind." IMHO, this is not a > bug but a feature. The method described in this draft has been proven to > work--there are two implementations, both of which show large reductions > in flooding. Further, the general concept has been proven to work in > implementations deployed in the real world. I'm not entirely certain what to > make of this criticism -- we aren't trying to replace the existing proposals, > but > rather provide a complimentary option. I don't see why it should be that > every possible solution must elect a leader in some way to be valid or > acceptable. > [Les:] If your intention is NOT to fit into dynamic flooding framework, you can state that. But stating that and then saying âgo ahead and elect an Area Leader if your wantâ makes no sense. Pleasel be clear and internally consistent. Les > The second criticism seems to be that it doesn't use signaling correctly ... > While I don't really understand this criticism, I think we can work together > to > resolve it. > > đ /r
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
