> 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. (!!!!??!?!?!)

> 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 

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


Lsr mailing list

Reply via email to