Hi, Acee:

Aijun Wang
China Telecom

> On Jul 31, 2020, at 01:45, Acee Lindem (acee) <a...@cisco.com> wrote:
> On 7/30/20, 1:31 PM, "Lsr on behalf of Acee Lindem (acee)" 
> <lsr-boun...@ietf.org on behalf of acee=40cisco....@dmarc.ietf.org> wrote:
>    On 7/30/20, 12:37 PM, "Lsr on behalf of Peter Psenak" 
> <lsr-boun...@ietf.org on behalf of ppsenak=40cisco....@dmarc.ietf.org> wrote:
>>        On 30/07/2020 18:03, Acee Lindem (acee) wrote:
>> So, how do we define a reachable route - is it any route subsumed by the 
>> summary LSA that we knew about in the past that becomes unreachable? When 
>> the PUA is withdrawn, how do we know whether it is because of expiration of 
>> the interval or the route becoming reachable again? This is a slippery slope.
>        I'm not suggesting the unreachable stuff to affect forwarding in any 
> way.

[WAJ] The ultimate aim of PUA is to notify the router to bypass the advertising 
ABR. If not affecting the forwarding, how to avoid the traffic black hole?

>    That would be better. Also, as I stated offline, it would also be better 
> to use encodings that would be ignored by routers that don't support the 
> extension. I tried to dissuade the authors of PUA not to overload the 
> prefix-originator LSA but was unsuccessful. 
[WAJ] We can discuss this later.

> Of course, I meant prefix-originator Sub-TLV and the existing LSAs indicating 
> reachability - 
> https://www.ietf.org/id/draft-ietf-lsr-ospf-prefix-originator-06.txt
> Thanks,
> Acee
>    Thanks,
>    Acee
>        thanks,
>        Peter
>> Thanks,
>> Acee
>> On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak" <lsr-boun...@ietf.org 
>> on behalf of ppsenak=40cisco....@dmarc.ietf.org> wrote:
>>     On 30/07/2020 16:30, Robert Raszuk wrote:
>>> Hey Peter,
>>> Not sure how smart you really want to be here but keep in mind that BGP
>>> say option C may never hear about it all the way to the egress PE in
>>> other domain or area ... It is almost always incongruent with IGP.
>>> So if the BGP path is installed it will indeed be at risk to resolve via
>>> less specific when it is still active BGP path and you too quickly
>>> remove info about unreachability.
>>     again, if you are smart you can use this info to your advantage, even
>>     without putting it in the forwarding and leaving the less specific stuff
>>     intact.

Lsr mailing list

Reply via email to