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

[[e-mail]]

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 <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 <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