Tony – Sigh…
I introduced the term “Area Destination” only as a means of demonstrating that this could have been something other than a prefix – as had been proposed in earlier versions of the draft. I am not asking you to introduce the term in the draft and as it seemed to confuse you I won’t use it any more in this thread. 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. 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. 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. 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. 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. 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. Les From: Tony Li <tony1ath...@gmail.com> On Behalf Of tony...@tony.li Sent: Wednesday, August 26, 2020 4:02 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, You have chosen to assign a prefix as the “Area Destination”. Are you sure you have the right document? The word “Destination” does not appear anywhere within https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03 This is fine with me. But having done that, forwarding should be based on the existing mechanisms for advertising a prefix and the associated prefix SID. Which is exactly what we’re doing: we’re advertising a prefix SID in the Proxy LSP. If you’re referring to the Area SID advertisement, then there is no existing mechanism for advertising that today, that’s why we’re having to create an additional subTLV. 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. By doing that you avoid a number of problems: * Duplicate SID advertisements for the same prefix and the possibility of inconsistency * Differing forwarding behavior for routers (IERs) who understand the Area Proxy TLV and those routers which don’t (everyone else) You can still include a sub-TLV in the Area Proxy TLV to identify the Area Prefix, but there is no need to also advertise the SID there. This makes the “Area Prefix” advertisement functionally equivalent to the “Router-ID” advertisement. It’s a convenient way to identify the prefix associated with the area, but it does not eliminate the need to also advertise prefix reachability information for that prefix in order to enable forwarding. You seem to be asking that the Area Leader also advertise a Prefix SID in its own LSP, as well as a prefix in the Area Proxy TLV. This is not just duplication of advertisement, it’s duplication plus a prefix. By your own criteria, this suggestion is worse than what we’ve proposed. All Inside Nodes need to understand the Area Proxy TLV and respond accordingly. Only the Inside Edge Nodes need to install forwarding state for the Area SID. Advertising a separate Prefix SID to the Inside Nodes forces them to create additional forwarding state that may not be desired by the network administrator. I have also suggested that an additional bit could be assigned in the Prefix-Attributes sub-TLV (RFC 7794) to mark a prefix as an Area Prefix if you wish. Thank you, but no thanks. As you’ve seen, a large driver for doing it this way is backward compatibility. Adding a bit would not be helpful in that regard. But advertising a prefix-SID in two different places is a bad idea. Advertising it in 2.5 places is worse. In an unrelated matter, https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03#section-2 states: “An Inside Edge Router may be elected the DIS for a Boundary LAN. In this case using the Area Proxy System Id as the basis for the LAN pseudonode identifier could create a collision, so the Insider Edge Router SHOULD compose the pseudonode identifier using its native system identifier.” I understand the potential collision that could arise if the Area Proxy System-Id were to be used in the pseudonode-id. However, what you propose is incompatible with a strict interpretation of ISO 10589 Section 8.4.5: “If this system, as a result of the Designated Intermediate System election process, considers itself to be designated Intermediate System, the LAN ID field shall be set to the concatenation of this system’s own system ID and the locally assigned one octet Local Circuit ID.” This raises the possibility that some of the non-DIS neighbors might not honor the pseudo-node ID since it does not match the system-id associated with their adjacency to the pseudo-node. At a minimum this possibility should be mentioned in the text. This is fair and I will add a mention. I should also point out that we have tested this against other implementations and not found a problem. One way to mitigate this is to have the IERs advertise a LAN Priority of 0 in their IIHs so as to avoid this case. True, or avoiding edge LANs entirely. As you’ve previously remarked elsewhere, true multi-access LANs are on the decline. Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
