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. (!!!!??!?!?!) > 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. > 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). Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
