Tony – Inline.
From: Tony Li <tony1ath...@gmail.com> On Behalf Of tony...@tony.li Sent: Wednesday, August 26, 2020 8:56 PM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> Cc: lsr@ietf.org Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt Hi Les, [Les:] Any one of the IERs can be elected Area Leader, therefore all of them have to be configured with the Area Prefix and associated SID. The Area Leader may not be an IER. In fact, in an important use case for us, the area is a leaf-spine topology. The Area Leader is one of the spines. The leaves are the edge routers. For resource reasons, we do NOT want the Area Leader to be a leaf. [Les:] Thanx for clarifying this. A careful reading of the draft supports what you say, but as this point could be easily overlooked it might be worth emphasizing this in the draft. In any case this isn’t significant for the points we are debating here. We do NOT require that the Area Leader candidates have identical configurations. In fact, if there is a configuration change, it may be beneficial to configure one candidate differently and then raise its priority. It’s a simple way of effecting an area-wide configuration change. [Les:] Section 4.2 states: “For consistency, all Area Leader candidates SHOULD be configured with the same Proxy System Id, Proxy Hostname, and any other information that may be inserted into the Proxy LSP.” I would agree that the flexibility to easily propagate a config change to be reflected in the Proxy LSP content requires relaxation of this rule. But again, not significant for the points we are debating here. Perhaps you are allowing that each IER could choose a different Area Prefix/SID. Not sure why you would want to do that – but even if you did, the behavior of the winning prefix/SID is analogous to an anycast address. The difference here is that the advertisement of the Prefix Reachability associated with the area prefix is within the Proxy LSP – which appears to OERs as if it was originated by all of the IERs i.e., the set of IERs appears as a single node to the OERs. Still, all IERs are aware of the winning prefix reachability advertisement and will do what is required in forwarding based on that content. They will not be aware of it unless we tell them via the Area Proxy TLV. For obvious reasons, the Inside Nodes do NOT do anything with the Proxy LSP other than flood it. Which is why we’re using the Prefix SID. [Les:] You are using the prefix-SID, but the advertisement is not associated with a prefix reachability advertisement, yet you want nodes to install forwarding entries based on this advertisement. This is what seems inappropriate. We want outside nodes to install forwarding entries on the Prefix SID. This is entirely backward compatible. How is that inappropriate? [Les:] Installation of forwarding entries today is based on Prefix Reachability advertisements. You are proposing to extend that by requiring a forwarding entry to be installed based on the context of the Area Proxy TLV. I would prefer that you not introduce this. In addition, since there will also be a Prefix Reachability Advertisement for the Area Prefix in the Proxy LSP, the IERs will have two sources of information for the SID associated with the Area prefix (Area SID sub-TLV from Area leader L2 LSP and Prefix Reachability advertisement in the Proxy LSP). Which introduces the possibility of inconsistency. If you do NOT advertise the SID in the Area Proxy TLV then you both eliminate the introduction of installing forwarding entries based on non-reachability advertisements and you eliminate the possibility of inconsistency. That is what I am asking you to do. The only current case where a prefix-SID is advertised and is NOT associated with prefix reachability is in the Binding TLVs. This has two use cases: * Advertising SIDs for prefixes associated with nodes which are NOT SR capable * As an alternative to per prefix advertisement if the operator prefers to use a centralized SID assignment service In both of these cases if a SID were to be advertised in prefix reachability TLV for the same prefix the SID in the prefix reachability advertisement would be preferred. You don’t discuss this at all in the draft i.e., what happens if the SID in the prefix reachability advertisement for the Area Prefix differs from that advertised in the Area Proxy TLV. What I am pushing for is eliminating the need to do so by relying on the existing prefix SID advertisements and not introducing a new one in the Area Proxy TLV. The existing ones do not have the required semantics. [Les:] That’s wasn’t the point. The point was that when a SID is advertised in prefix reachability it is used in preference to advertisements in other TLVs. [Les:] The semantics you require are functionally equivalent to anycast behavior – which is supported already. Please point me to anycast semantics that will ONLY be selected by IERs. [Les:] You have specified that only IERs and Outside Routers process Proxy LSP content. So why do you ask this question? Les Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
