Tony - You have chosen to assign a prefix as the "Area Destination". 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. 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. 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. But advertising a prefix-SID in two different places is a bad idea. ..... 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. 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. Les From: Lsr <lsr-boun...@ietf.org> On Behalf Of tony...@tony.li Sent: Monday, August 24, 2020 10:02 AM To: lsr@ietf.org Subject: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt Hi folks, This updated draft has been published for a few weeks now. We would like to solicit your opinion on this. In particular, we have changed the encoding of the Area SID. Do you find this encoding adequate and appropriate? Thanks, Tony Begin forwarded message: From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> Subject: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt Date: August 5, 2020 at 1:17:39 PM PDT To: <i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>> Cc: lsr@ietf.org<mailto:lsr@ietf.org> Reply-To: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>, lsr@ietf.org<mailto:lsr@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : Area Proxy for IS-IS Authors : Tony Li Sarah Chen Vivek Ilangovan Gyan S. Mishra Filename : draft-ietf-lsr-isis-area-proxy-03.txt Pages : 19 Date : 2020-08-05 Abstract: Link state routing protocols have hierarchical abstraction already built into them. However, when lower levels are used for transit, they must expose their internal topologies to each other, leading to scale issues. To avoid this, this document discusses extensions to the IS-IS routing protocol that would allow level 1 areas to provide transit, yet only inject an abstraction of the level 1 topology into level 2. Each level 1 area is represented as a single level 2 node, thereby enabling greater scale. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03 https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
