Tony – The statement “the … Prefix SID does NOT have the semantics that we want and causes deleterious side-effects” is FALSE.
Other than that, we understand each other and we disagree. You have my input. There is an alternative here: Given that there isn’t any defined use case for the Area Prefix/SID, you could choose to defer its definition until such time as a use case arises. I agree that the concept is appealing and is potentially useful – which is why I thought it worthwhile to invest time in defining it. But a conservative approach might be to wait until we actually need it before defining it. It is always possible that when the use case arises we will find that there are some other issues which have been overlooked which might alter how this would be advertised. Les From: Tony Li <tony1ath...@gmail.com> On Behalf Of tony...@tony.li Sent: Thursday, August 27, 2020 8:19 AM 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 Les, [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. Noted and enhanced. 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. This is exactly why it says SHOULD and not MUST. 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. I am well aware of that. Perhaps it would help if I tell you that I am 100% impervious to Persuasion by Repetition. I understand what you want. I disagree with you on the tradeoffs. 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. No, since the IERs are supposed to ignore the Proxy LSP for any purpose other than flooding. I’m adding an explicit statement to this effect. The only source of truth is the Area Proxy TLV generated by the Area Leader. The existing ones do not have the required semantics. [Les:] That’s wasn’t the point. That is the entire point. You insist that we advertise the Area SID as a Prefix SID in addition to the a prefix in the Area Proxy TLV. The additional Prefix SID does NOT have the semantics that we want and causes deleterious side-effects. The point was that when a SID is advertised in prefix reachability it is used in preference to advertisements in other TLVs. Except when it is part of the Proxy LSP, in which case we want the Inside Routers to ignore it. We do NOT want Inside Routers creating forwarding state or SPF state for every prefix and SID in the Proxy LSP. [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? You’re asking me to use another mechanism. I don’t see how it applies. I’m open to you educating me. IERs do NOT process Proxy LSP content other than to flood it. Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
