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
