Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

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

Tony -

From: Tony Li <[e-mail]>
Sent: Wednesday, August 05, 2020 4:26 PM
To: Les Ginsberg (ginsberg) <[e-mail]>
Cc: Acee Lindem (acee) <[e-mail]>; Bruno Decraene <[e-mail]>; [e-mail]
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02


Les,

This would make the Area Prefix mandatory for Area Proxy, which is not desired.  We would prefer it to remain optional and thus part of the Area SID sub-TLV.

[Les2:] You can advertise the Area Prefix in an optional sub-TLV – just as you did with the Area SID. That is what I expected you would do.


Good.  I’ve just submitted -03, which does exactly that.  Please review.  Note that tools.ietf.org<http://tools.ietf.org> appears to be down at this instant. (!!!!??!?!?!)

[Les3:] Yes – I saw that after my reply. My comments still stand.

b)The remaining info (reachability and SID) can then be provided using existing Prefix Reachability advertisements – no need for new sub-TLV for “Area SID”. This eliminates any potential issues if the SID advertised by “Area SID sub-TLV” were to differ from the SID advertised in Prefix Reachability for the same prefix.


As we discussed privately, we view this as a non-issue.  The Area Leader is the one advertising both the Area SID sub-TLV and the Proxy LSP. If there’s a coding error, there’s a coding error. There is a single source of truth (the Area Leader’s config) and we cannot protect against every possible coding error.  Reconciling the prefix with a separate advertisement has a non-trivial chance of being broken too, and IMHO, much larger.

[Les2:] You can define the advertisements in a way which reduces the possibility of ambiguity – which seems like a good thing to me.
And rest assured that you will be asked by someone to define the expected behavior when there is an inconsistency. 😊


Same question: same answer. :-)



Since prefix SID and Prefix reachability are directly related in forwarding, it makes far more sense to me to have those two together.
If you find correlating information in two different TLVs too challenging, you could opt for a new bit in the prefix attributes sub-TLV to identify a prefix as an “Area Prefix”. Then you would not need any additional info advertised in the Area Proxy TLV at all.


We prefer to keep it in the Area Proxy TLV so that its semantics are crystal clear.

[Les3:] This will make it more awkward (at best) to reuse the concept outside of the  Area Proxy use case. The prefix attributes option would make it very easy for any use case to be supported.


 There then remains the question as to whether the “Area Prefix” is anycast or unicast i.e., is it common to all IERs or is it unique to whomever gets elected Area Leader?

Does it matter? We have no clear semantics for this prefix. A difference that makes no difference is no difference.

[Les:] This question needs to be directed at those who prefer the Area Prefix approach. It matters as it impacts configuration and advertisement semantics. An anycast prefix is NOT a Node Prefix.
And it impacts how traffic is forwarded into the area.



How so?  Traffic will be directed to the SID value (modulo PHP).
[Les3:] If the prefix is private to a single router then traffic has to pass through that router. If it is anycast the traffic could arrive at any one of the routers supporting the anycast address.

   Les

Tony