John,
On 29/05/2020 16:56, John Scudder wrote:
Peter,
On May 29, 2020, at 10:36 AM, Peter Psenak <ppse...@cisco.com
<mailto: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.)
correct.
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;
no worries, below summary is sufficient.
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.
so if we design for a most general case, it's obvious that the locally
unique CRH identifiers are problematic, at least when distributed
routing protocol is being used to populate CRH-FIB.
Not to mention that the proposed encoding in
draft-bonica-lsr-crh-isis-extensions only allows one to advertise thener
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.
sure, just tried to connect things together, but let's ignore it for a
time being.
thanks,
Peter
—John
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
