Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

["Les Ginsberg (ginsberg)" <[e-mail]>]

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 <[e-mail]> On Behalf Of [e-mail]
Sent: Monday, August 24, 2020 10:02 AM
To: [e-mail]
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: [e-mail]<mailto:[e-mail]>
Subject: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
Date: August 5, 2020 at 1:17:39 PM PDT
To: <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Reply-To: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>


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
[e-mail]<mailto:[e-mail]>
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