Tony – Inline.
From: Tony Li <tony1ath...@gmail.com> On Behalf Of tony...@tony.li Sent: Wednesday, August 26, 2020 5:40 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 Les, As per the draft: Area Proxy TLV is advertised by IERs in their L2 LSP. Area Proxy TLV is NOT advertised in the Proxy LSP. So how do the OERs become aware of the “prefix and SID that represents the entirety of the Inside Area to the Outside Area” ??? I assume that they learn this because the Proxy LSP (at least) contains a Prefix Reachability TLV with the same prefix/SID that was advertised in the Area Proxy TLV. Is this correct? If not, please correct me. That’s correct. If this isn’t crystal clear from the draft, please work with me to get it clarified to your satisfaction. Also explain why it is necessary for something other than a prefix reachability advertisement to cause an entry to be created in forwarding for a prefix – and ONLY when received in an L2 LSP? This is unprecedented. It is unprecedented because there we are proposing something unprecedented. I repeat: "There is no other mechanism whereby system A can advertise a prefix SID to a number of other systems and have them install receive/POP forwarding entries.” It is NOT creating forwarding TO a prefix. It’s reception. [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. 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. If I am right, you then have multiple TLVs which advertise duplicate advertisements – even if not in the same LSP - which exposes you to the problems I mentioned. My goal is to have one – and only one – advertisement which creates forwarding state. Well, I’m sorry, but your goal is unachievable. The Proxy LSP is only relevant outside of the area. The Inner Node LSPs aren’t circulated outside of the area. [Les:] Agreed. Nothing I have asserted suggests otherwise. My second goal is not to invent a new SID type/advertisement when the object associated with it (a prefix) already has a defined SID type. 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. 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. What I object to – and am concerned about – is that you seem to invent your version of SR for Area Proxy even when you use the same object (a prefix) that SR already supports. Again, SR does not support the semantics that we require. [Les:] The semantics you require are functionally equivalent to anycast behavior – which is supported already. Les As you know, I was prepared to support a new type of SID when you actually were defining a new object type. The fact that you decided NOT to invent a new object type is fine with me – but please do not claim that you need a new SID type when you don’t. I’m sorry that you still don’t understand. We do need something different. Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
