John, Draft under the adoption call as well as its author sent 10s if not more messages stating that CRH-SIDs are **locally significant*. *
Now after few discussions about scaling aspects of such design choice you are suddenly stating: *" one exemplary solution to your objection is to make use of globally-unique (per domain, of course) identifiers"* so at this point the main characteristics of the proposal seems at least very elastic. With that what exactly is the proposal 6man is subject to adopt if it is fundamentally changing every day ? Note that if IDs are globally domain wide significant then you suddenly need to worry about ID space collision. Would next the index would be introduced just like SR-MPLS addresses that problem ? I remain with my opinion that current draft is not even stable enough for adoption in any WG. Regards, Robert. On Fri, May 29, 2020 at 4:56 PM John Scudder <jgs= 40juniper....@dmarc.ietf.org> wrote: > Peter, > > On May 29, 2020, at 10:36 AM, Peter Psenak <ppse...@cisco.com> wrote: > > well, advertising the local CRH identifier for every node and adjacency > in the network from every other node is clearly a no-go from the IGP > perspective. > > > (Of course this objection only applies to the final (“distributed routing > protocol”) bullet point.) > > We’re recapitulating conversation that has been done on-list at least > once. If I had time I’d find the reference and post, but as we know the > conversation is hundreds of messages deep (at least!) and I don’t; sorry. > Maybe someone else has a reference handy? If I recall correctly (and I may > not) one exemplary solution to your objection is to make use of > globally-unique (per domain, of course) identifiers, and yes, I do mean > something semantically similar to a SR Node-SID. Other solutions are > possible, depending on the use case — if the use case doesn’t require > any-to-any connectivity within the domain, you potentially don’t need > O(N^2) CRH identifiers to be present in the LS(P)DB even absent any kind of > global uniqueness. Granted that any-to-any is the most general case. > > Not to mention that the proposed encoding in > draft-bonica-lsr-crh-isis-extensions only allows one to advertise the > CRH identifier for a local prefix and adjacency, not for the remote ones. > > > That seems out of scope for discussion of CRH per se, unless you mean to > say “this problem cannot be solved” instead of “this particular solution is > deficient”. If it’s the latter, I think the LSR mailing list seems like a > better place to take it up with the authors > of draft-bonica-lsr-crh-isis-extensions. > > —John > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
