Hi, Les: I do a short search work and find even for P2MP stub-link type, the process can be same as the numbered p2p interface.
Please see the reference at your company’s doc site: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/xe-2/iro-xe-2-book/iro-cfg.html In these cases, you can configure the OSPF network type as a point-to-multipoint network. Routing between two routers not directly connected will go through the router that has VCs to both routers. Note that you need not configure neighbors when using this feature. An OSPF point-to-multipoint interface is defined as a numbered point-to-point interface having one or more neighbors. It creates multiple host routes. An OSPF point-to-multipoint network has the following benefits compared to NBMA and point-to-point networks: Point-to-multipoint is easier to configure because it requires no configuration of neighbor commands, it consumes only one IP subnet, and it requires no designated router election. Then all the neighbor should also under one common prefixes. So, the proposed draft can meet the scenarios for all kinds of numbered interfaces. Do you have other concerns then? Also ask for John? Robert? Or other experts? Aijun Wang China Telecom > On Jan 15, 2022, at 09:34, Aijun Wang <[email protected]> wrote: > > Hi, Les: > Thanks for your analysis. If these are your main concerns, here is my > responses: > > I am hearing your every opposition points(also from others, same points or > not.) > I am always trying to address the comments, although reluctant to some corner > cases(sorry if it irritated you). But as you insist the solution should cover > all possible scenarios, then how about the following considerations: > > 1) We have updated the draft to reflect the solution to “unnumbered link”. > > 2) P2MP stub-link type, we can take the same approach.(the stub link type > “P2MP” should be added) > > 3) For broadcast stub link, the nodes that share the same prefix can > certainly be connected together. > > Are the above considerations solve your concerns? If so, we can update the > draft again to reflect this. > > > Aijun Wang > China Telecom > >>> On Jan 15, 2022, at 08:49, Les Ginsberg (ginsberg) <[email protected]> >>> wrote: >>> >> >> Aijun – >> >> I believe there is a fundamental disagreement here which derives from your >> belief that it is correct/sufficient to describe a link interconnecting two >> or more nodes using a prefix. >> This has been discussed on the list for a long time now. It has been pointed >> out to you that this is a broken model. It does not work for multiple cases >> (true broadcast links, unnumbered links, point to MP links). >> Your response to date when this is pointed out to you is either: >> >> “I don’t care about those cases” >> >> Or >> >> “I don’t think those cases are important.” >> >> But I (and others) do not see the value of adopting a model that has limited >> applicability – especially when we already have a model that is much more >> robust. >> >> Sure – if you think a prefix is enough to define the connection between two >> nodes, then you can view the identifiers for the neighbor as “unnecessary”. >> But this is the wrong model. >> >> So long as we disagree on this fundamental point, we are never going to >> agree on anything else and rehashing details is a waste of time for everyone. >> >> Les >> >> >> From: Aijun Wang <[email protected]> >> Sent: Friday, January 14, 2022 4:10 PM >> To: Robert Raszuk <[email protected]> >> Cc: Les Ginsberg (ginsberg) <[email protected]>; lsr <[email protected]>; John E >> Drake <[email protected]> >> Subject: Re: [Lsr] WG Adoption Call for >> draft-wang-lsr-stub-link-attributes-02 >> >> Hi, Robert: >> >> Sorry, the correct description should be “For inter-AS stub link, we must >> generate unnecessary Remote-AS, Remote ASBR Router ID for scenarios that >> described in >> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5.1 >> For non inter-AS stub link, we must generate Bogus-AS, and Bogus Remote >> ASBR Router ID” >> >> Aijun Wang >> China Telecom >> >> >> On Jan 15, 2022, at 07:59, Robert Raszuk <[email protected]> wrote: >> >> >> >> For the current scenarios and solutions, we have analyzed that RFC 5316 and >> RFC5392 are not suitable for such purposes—we must generate bogus AS, bogus >> Remote ASBR Router ID on every inter-AS, or non inter-AS boundary links. >> >> Why do you think those values need to be "bogus" ? And Inter-AS is just a >> perfect example on what you call a "stub link" so I would not hold on that >> much to the nomenclature. >> >> I would like to hear the constructive comments, or other solutions that >> better the the one in this draft. >> >> I think what has been suggested is just that, but of course you are entitled >> to have your own opinion. >> >> Kind regards, >> Robert >> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
