subject:"\"\\\[Lsr\\\] New Version Notification for draft\\\-wang\\\-lsr\\\-prefix\\\-unreachable\\\-annoucement\\\-03.txt\""

Hi, Acee:

Aijun Wang
China Telecom

> On Jul 31, 2020, at 01:45, Acee Lindem (acee)  wrote:
> 
> 
> On 7/30/20, 1:31 PM, "Lsr on behalf of Acee Lindem (acee)" 
>  wrote:
> 
> 
> 
>On 7/30/20, 12:37 PM, "Lsr on behalf of Peter Psenak" 
>  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" > 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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi, Robert:

Aijun Wang
China Telecom

> On Jul 31, 2020, at 00:23, Robert Raszuk  wrote:
> 
> 
> Hi,
> 
> Imagine I have two ABRs connecting area 1 to area 0. One is signalling 
> transition to down for subset of summary and the other does not .. maybe it 
> is slow ... maybe it does not support this new feature. 
> 
> So all routers in the area 0 are receiving a full summary from one ABR and a 
> summary with hole from the other one. Should that be logical AND or OR ? 

[WAJ] It should be OR. All routers in the area 0 should prefer to the ABR that 
not advertising PUA to forward traffic.
> 
> Then on the other side there is area 2. Should the transition to down be 
> leaked ?

[WAJ] The PUA should be leaked.

> If so in a nicely stable network we may see instead of few /20 summaries jump 
> to 1M transitions to down yet summary continues - would that not have a bit 
> negative effect on the entire network ? Where would ABR remove summary itself 
> - when all atomic routes subsumed by the summary transition to down ? 

[WAJ] 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-6
 has described the extreme conditions for advertising PUA+Summary, Detail 
Reachable Prefixes only, or Summary Address with Max metric.
Is there any other graceful advertising in these conditions? 

> 
> - - - 
> 
> I am supportive of the idea to signal unreachable network elements. But I am 
> not sure if we should do it in IGP and BGP or only in BGP. 

[WAJ] Such information is for underlay link state and should be flooded via 
IGP? The ambiguity arises from IGP summary behavior and should be solved by 
itself?
> 
> Thx,
> R.
> 
> 
>> On Thu, Jul 30, 2020 at 6:08 PM Huzhibo  wrote:
>> HI acee：
>> 
>> PUA does not advertise reachable or unreachable details, it advertise events 
>> with prefix from up to down.
>> 
>> 
>> 
>> thanks
>> 
>> Zhibo
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> 胡志波 Hu Zhibo
>> Mobile: +86-18618192287
>> Email: huzh...@huawei.com
>> 
>> 发件人：Acee Lindem (acee) 
>> 收件人：Peter Psenak ;Robert Raszuk 
>> 
>> 抄 送：Aijun Wang ;Xiaoyaqun 
>> ;Huzhibo ;Aijun Wang 
>> ;lsr 
>> 时 间：2020-07-31 00:04:02
>> 主 题：Re: [Lsr] New Version Notification for 
>> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>> 
>> 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. 
>> Thanks,
>> Acee
>> 
>> On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak" > 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.
>> 
>> Peter
>> 
>> 
>> > 
>> > Thx
>> > R.
>> > 
>> > On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak > > <mailto:ppse...@cisco.com>> wrote:
>> > 
>> > On 30/07/2020 16:14, Robert Raszuk wrote:
>> >  >  > 2：For bgp example，when the pe node down，the bgp peer
>> > must down
>> >  > within
>> >  >  > 30 mintus，It will not get it up via cancle advertise pua.
>> >  >
>> >  > for the above it is sufficient to advertise the
>> > unreachability for few
>> >  > seconds from each ABR independently. That would be a much
>> > more solid
>> >  > proposal.
>> >  >
>> >  >
>> >  > Not sure about &qu

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt


On 7/30/20, 1:31 PM, "Lsr on behalf of Acee Lindem (acee)" 
 wrote:



On 7/30/20, 12:37 PM, "Lsr on behalf of Peter Psenak"  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.

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. 

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" 
 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.
> 
>  Peter
> 
> 
>  >
>  > Thx
>  > R.
>  >
>  > On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak   > > wrote:
>  >
>  > On 30/07/2020 16:14, Robert Raszuk wrote:
>  >  >  > 2：For bgp example，when the pe node down，the bgp 
peer
>  > must down
>  >  > within
>  >  >  > 30 mintus，It will not get it up via cancle 
advertise pua.
>  >  >
>  >  > for the above it is sufficient to advertise the
>  > unreachability for few
>  >  > seconds from each ABR independently. That would be 
a much
>  > more solid
>  >  > proposal.
>  >  >
>  >  >
>  >  > Not sure about "few seconds" ... IBGP def hold time in 
number of
>  >  > implementations is 180 sec :) .. but few minutes will 
work for sure.
>  >
>  > depends how you use it.
>  >
>  > If you can use the unreachable info in a smart way, it's 
sufficient if
>  > it is present for a very short time interval.
>  >
>  > thanks,
>  > Peter
>  >
>  >  >
>  >  > Thx,
>  >  > R.
>  >  >
>  >
> 
>  ___
>  Lsr mailing list
>  Lsr@ietf.org
>  https://www.ietf.org/mailman/listinfo/lsr
> 
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt



On 7/30/20, 12:37 PM, "Lsr on behalf of Peter Psenak"  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.

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. 

Thanks,
Acee

thanks,
Peter


> Thanks,
> Acee
> 
> On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak" 
 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.
> 
>  Peter
> 
> 
>  >
>  > Thx
>  > R.
>  >
>  > On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak   > > wrote:
>  >
>  > On 30/07/2020 16:14, Robert Raszuk wrote:
>  >  >  > 2：For bgp example，when the pe node down，the bgp peer
>  > must down
>  >  > within
>  >  >  > 30 mintus，It will not get it up via cancle advertise 
pua.
>  >  >
>  >  > for the above it is sufficient to advertise the
>  > unreachability for few
>  >  > seconds from each ABR independently. That would be a 
much
>  > more solid
>  >  > proposal.
>  >  >
>  >  >
>  >  > Not sure about "few seconds" ... IBGP def hold time in 
number of
>  >  > implementations is 180 sec :) .. but few minutes will work 
for sure.
>  >
>  > depends how you use it.
>  >
>  > If you can use the unreachable info in a smart way, it's 
sufficient if
>  > it is present for a very short time interval.
>  >
>  > thanks,
>  > Peter
>  >
>  >  >
>  >  > Thx,
>  >  > R.
>  >  >
>  >
> 
>  ___
>  Lsr mailing list
>  Lsr@ietf.org
>  https://www.ietf.org/mailman/listinfo/lsr
> 
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi Zhibo,

From: Lsr  on behalf of Huzhibo 
Date: Thursday, July 30, 2020 at 12:14 PM
To: Acee Lindem , Peter Psenak 
, Robert Raszuk 
Cc: lsr , Aijun Wang , Xiaoyaqun 
, Aijun Wang 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt


HI acee：

PUA does not advertise reachable or unreachable details, it advertise events 
with prefix from up to down.

I don’t see the distinction here and it is not described in the latest version 
of the draft (posted Monday). You must be envisioning some protocol behavior 
that is yet to be documented.

Thanks,
Acee



thanks

Zhibo







--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com<mailto:huzh...@huawei.com>
发件人：Acee Lindem (acee) 
收件人：Peter Psenak ;Robert Raszuk 

抄 送：Aijun Wang ;Xiaoyaqun 
;Huzhibo ;Aijun Wang 
;lsr 
时 间：2020-07-31 00:04:02
主 题：Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

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.
Thanks,
Acee

On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak"  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.

Peter


>
> Thx
> R.
>
> On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak  <mailto:ppse...@cisco.com>> wrote:
>
> On 30/07/2020 16:14, Robert Raszuk wrote:
>  >  > 2：For bgp example，when the pe node down，the bgp peer
> must down
>  > within
>  >  > 30 mintus，It will not get it up via cancle advertise pua.
>  >
>  > for the above it is sufficient to advertise the
> unreachability for few
>  > seconds from each ABR independently. That would be a much
> more solid
>  > proposal.
>  >
>  >
>  > Not sure about "few seconds" ... IBGP def hold time in number of
>  > implementations is 180 sec :) .. but few minutes will work for 
sure.
>
> depends how you use it.
>
> If you can use the unreachable info in a smart way, it's sufficient if
> it is present for a very short time interval.
>
> thanks,
> Peter
>
>  >
>  > Thx,
>  > R.
>  >
>

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

hi：

if abr1 advertise pua but abr2 not，other node will think the prefix is 
reachable via abr2. and will not advertise pua to other area.

I am not idea how bgp can work？keepalive expire？bfd？maybe bfd can work.local 
policy verification？some usecase maybe yes.

--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com<mailto:huzh...@huawei.com>

发件人：Robert Raszuk 
收件人：Huzhibo 
抄 送：Acee Lindem (acee) ;Peter Psenak 
;Aijun Wang 
;Xiaoyaqun ;Aijun Wang 
;lsr 
时 间：2020-07-31 00:18:27
主 题：Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi,

Imagine I have two ABRs connecting area 1 to area 0. One is signalling 
transition to down for subset of summary and the other does not .. maybe it is 
slow ... maybe it does not support this new feature.

So all routers in the area 0 are receiving a full summary from one ABR and a 
summary with hole from the other one. Should that be logical AND or OR ?

Then on the other side there is area 2. Should the transition to down be leaked 
? If so in a nicely stable network we may see instead of few /20 summaries jump 
to 1M transitions to down yet summary continues - would that not have a bit 
negative effect on the entire network ? Where would ABR remove summary itself - 
when all atomic routes subsumed by the summary transition to down ?

- - -

I am supportive of the idea to signal unreachable network elements. But I am 
not sure if we should do it in IGP and BGP or only in BGP.

Thx,
R.

On Thu, Jul 30, 2020 at 6:08 PM Huzhibo 
mailto:huzh...@huawei.com>> wrote:

HI acee：

PUA does not advertise reachable or unreachable details, it advertise events 
with prefix from up to down.

thanks

Zhibo

--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com<mailto:huzh...@huawei.com>

发件人：Acee Lindem (acee) mailto:a...@cisco.com>>
收件人：Peter Psenak 
mailto:40cisco@dmarc.ietf.org>>;Robert 
Raszuk mailto:rob...@raszuk.net>>
抄 送：Aijun Wang 
mailto:wang...@chinatelecom.cn>>;Xiaoyaqun 
mailto:xiaoya...@huawei.com>>;Huzhibo 
mailto:huzh...@huawei.com>>;Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>;lsr 
mailto:lsr@ietf.org>>
时 间：2020-07-31 00:04:02
主 题：Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

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.
Thanks,
Acee

On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak" 
mailto:lsr-boun...@ietf.org> on behalf of 
ppsenak=40cisco@dmarc.ietf.org<mailto: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.

Peter

>
> Thx
> R.
>
> On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak 
mailto:ppse...@cisco.com>
> <mailto:ppse...@cisco.com>> wrote:
>
> On 30/07/2020 16:14, Robert Raszuk wrote:
>  >  > 2：For bgp example，when the pe node down，the bgp peer
> must down
>  > within
>  >  > 30 mintus，It will not get it up via cancle advertise pua.
>  >
>  > for the above it is sufficient to advertise the
> unreachability for few
>  > seconds from each ABR independently. That would be a much
> more solid
>  > proposal.
>  >
>  >
>  > Not sure about "few seconds" ... IBGP def hold time in number of
>  > implementations is 180 sec :) .. but few minutes will work for 
sure.
>
> depends how you use it.
>
> If you can use the unreachable info in a smart way, it's sufficient if
> it is present for a very short time interval.
>
> thanks,
> Peter
>
>  >
>  > Thx,
>  > R.
>  >
>

___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Robert Raszuk

Hi,

Imagine I have two ABRs connecting area 1 to area 0. One is signalling
transition to down for subset of summary and the other does not .. maybe it
is slow ... maybe it does not support this new feature.

So all routers in the area 0 are receiving a full summary from one ABR and
a summary with hole from the other one. Should that be logical AND or OR ?

Then on the other side there is area 2. Should the transition to down be
leaked ? If so in a nicely stable network we may see instead of few /20
summaries jump to 1M transitions to down yet summary continues - would that
not have a bit negative effect on the entire network ? Where would ABR
remove summary itself - when all atomic routes subsumed by the summary
transition to down ?

- - -

I am supportive of the idea to signal unreachable network elements. But I
am not sure if we should do it in IGP and BGP or only in BGP.

Thx,
R.


On Thu, Jul 30, 2020 at 6:08 PM Huzhibo  wrote:

> HI acee：
>
> PUA does not advertise reachable or unreachable details, it advertise
> events with prefix from up to down.
>
>
> thanks
>
> Zhibo
>
>
>
>
> --
> 胡志波 Hu Zhibo
> Mobile: +86-18618192287
> Email: huzh...@huawei.com
> *发件人：*Acee Lindem (acee) 
> *收件人：*Peter Psenak ;Robert Raszuk <
> rob...@raszuk.net>
> *抄 送：*Aijun Wang ;Xiaoyaqun 
> ;Huzhibo
> ;Aijun Wang ;lsr <
> lsr@ietf.org>
> *时 间：*2020-07-31 00:04:02
> *主 题：*Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
> 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.
> 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.
>
> Peter
>
>
> >
> > Thx
> > R.
> >
> > On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak  > <mailto:ppse...@cisco.com >> wrote:
> >
> > On 30/07/2020 16:14, Robert Raszuk wrote:
> >  >  > 2：For bgp example，when the pe node down，the bgp peer
> > must down
> >  > within
> >  >  > 30 mintus，It will not get it up via cancle advertise
> pua.
> >  >
> >  > for the above it is sufficient to advertise the
> > unreachability for few
> >  > seconds from each ABR independently. That would be a much
> > more solid
> >  > proposal.
> >  >
> >  >
> >  > Not sure about "few seconds" ... IBGP def hold time in number
> of
> >  > implementations is 180 sec :) .. but few minutes will work
> for sure.
> >
> > depends how you use it.
> >
> > If you can use the unreachable info in a smart way, it's
> sufficient if
> > it is present for a very short time interval.
> >
> > thanks,
> > Peter
> >
> >  >
> >  > Thx,
> >  > R.
> >  >
> >
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt


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.

thanks,
Peter



Thanks,
Acee

On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak"  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.

 Peter


 >
 > Thx
 > R.
 >
 > On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak  > wrote:
 >
 > On 30/07/2020 16:14, Robert Raszuk wrote:
 >  >  > 2：For bgp example，when the pe node down，the bgp peer
 > must down
 >  > within
 >  >  > 30 mintus，It will not get it up via cancle advertise pua.
 >  >
 >  > for the above it is sufficient to advertise the
 > unreachability for few
 >  > seconds from each ABR independently. That would be a much
 > more solid
 >  > proposal.
 >  >
 >  >
 >  > Not sure about "few seconds" ... IBGP def hold time in number of
 >  > implementations is 180 sec :) .. but few minutes will work for 
sure.
 >
 > depends how you use it.
 >
 > If you can use the unreachable info in a smart way, it's sufficient 
if
 > it is present for a very short time interval.
 >
 > thanks,
 > Peter
 >
 >  >
 >  > Thx,
 >  > R.
 >  >
 >

 ___
 Lsr mailing list
 Lsr@ietf.org
 https://www.ietf.org/mailman/listinfo/lsr





___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

HI acee：

PUA does not advertise reachable or unreachable details, it advertise events 
with prefix from up to down.


thanks

Zhibo




--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com<mailto:huzh...@huawei.com>

发件人：Acee Lindem (acee) 
收件人：Peter Psenak ;Robert Raszuk 

抄 送：Aijun Wang ;Xiaoyaqun 
;Huzhibo ;Aijun Wang 
;lsr 
时 间：2020-07-31 00:04:02
主 题：Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

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.
Thanks,
Acee

On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak"  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.

Peter


>
> Thx
> R.
>
> On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak  <mailto:ppse...@cisco.com>> wrote:
>
> On 30/07/2020 16:14, Robert Raszuk wrote:
>  >  > 2：For bgp example，when the pe node down，the bgp peer
> must down
>  > within
>  >  > 30 mintus，It will not get it up via cancle advertise pua.
>  >
>  > for the above it is sufficient to advertise the
> unreachability for few
>  > seconds from each ABR independently. That would be a much
> more solid
>  > proposal.
>  >
>  >
>  > Not sure about "few seconds" ... IBGP def hold time in number of
>  > implementations is 180 sec :) .. but few minutes will work for 
sure.
>
> depends how you use it.
>
> If you can use the unreachable info in a smart way, it's sufficient if
> it is present for a very short time interval.
>
> thanks,
> Peter
>
>  >
>  > Thx,
>  > R.
>  >
>

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

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. 
Thanks,
Acee

On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak"  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.

Peter


> 
> Thx
> R.
> 
> On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak  > wrote:
> 
> On 30/07/2020 16:14, Robert Raszuk wrote:
>  >  > 2：For bgp example，when the pe node down，the bgp peer
> must down
>  > within
>  >  > 30 mintus，It will not get it up via cancle advertise pua.
>  >
>  > for the above it is sufficient to advertise the
> unreachability for few
>  > seconds from each ABR independently. That would be a much
> more solid
>  > proposal.
>  >
>  >
>  > Not sure about "few seconds" ... IBGP def hold time in number of
>  > implementations is 180 sec :) .. but few minutes will work for 
sure.
> 
> depends how you use it.
> 
> If you can use the unreachable info in a smart way, it's sufficient if
> it is present for a very short time interval.
> 
> thanks,
> Peter
> 
>  >
>  > Thx,
>  > R.
>  >
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

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.

Peter

Thx
R.

On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak > wrote:

On 30/07/2020 16:14, Robert Raszuk wrote:
 >      > 2：For bgp example，when the pe node down，the bgp peer
must down
 >     within
 >      > 30 mintus，It will not get it up via cancle advertise pua.
 >
 >     for the above it is sufficient to advertise the
unreachability for few
 >     seconds from each ABR independently. That would be a much
more solid
 >     proposal.
 >
 >
 > Not sure about "few seconds" ... IBGP def hold time in number of
 > implementations is 180 sec :) .. but few minutes will work for sure.

depends how you use it.

If you can use the unreachable info in a smart way, it's sufficient if
it is present for a very short time interval.

thanks,
Peter

 >
 > Thx,
 > R.
 >

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Robert Raszuk

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.

Thx
R.

On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak  wrote:

> On 30/07/2020 16:14, Robert Raszuk wrote:
> >  > 2：For bgp example，when the pe node down，the bgp peer must down
> > within
> >  > 30 mintus，It will not get it up via cancle advertise pua..
> >
> > for the above it is sufficient to advertise the unreachability for
> few
> > seconds from each ABR independently. That would be a much more solid
> > proposal.
> >
> >
> > Not sure about "few seconds" ... IBGP def hold time in number of
> > implementations is 180 sec :) .. but few minutes will work for sure.
>
> depends how you use it.
>
> If you can use the unreachable info in a smart way, it's sufficient if
> it is present for a very short time interval.
>
> thanks,
> Peter
>
> >
> > Thx,
> > R.
> >
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

On 30/07/2020 16:14, Robert Raszuk wrote:

 > 2：For bgp example，when the pe node down，the bgp peer must down
within
 > 30 mintus，It will not get it up via cancle advertise pua.

for the above it is sufficient to advertise the unreachability for few
seconds from each ABR independently. That would be a much more solid
proposal.

Not sure about "few seconds" ... IBGP def hold time in number of 
implementations is 180 sec :) .. but few minutes will work for sure.

depends how you use it.

If you can use the unreachable info in a smart way, it's sufficient if 
it is present for a very short time interval.

thanks,
Peter

Thx,
R.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Robert Raszuk

> > 2：For bgp example，when the pe node down，the bgp peer must down within
> > 30 mintus，It will not get it up via cancle advertise pua.
>
> for the above it is sufficient to advertise the unreachability for few
> seconds from each ABR independently. That would be a much more solid
> proposal.


Not sure about "few seconds" ... IBGP def hold time in number of
implementations is 180 sec :) .. but few minutes will work for sure.

Thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

HI Peter：

sure，we will cansider all the possible better solution.thanks for your 
suggestion.


zhibo

--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com<mailto:huzh...@huawei.com>

发件人：Peter Psenak 
收件人：Huzhibo ;Aijun Wang 
抄 送：Aijun Wang ;lsr ;Xiaoyaqun 

时 间：2020-07-30 21:32:45
主 题：Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi Zhibo,

On 30/07/2020 15:18, Huzhibo wrote:
> HI Peter：
>
> 1：No problem is a problem that never can be proved.
>
> 2：For bgp example，when the pe node down，the bgp peer must down within
> 30 mintus，It will not get it up via cancle advertise pua.

for the above it is sufficient to advertise the unreachability for few
seconds from each ABR independently. That would be a much more solid
proposal.

thanks,
Peter


>
>
> ZHIBO
>
> --
> 胡志波 Hu Zhibo
> Mobile: +86-18618192287 
> Email: huzh...@huawei.com <mailto:huzh...@huawei.com>
>
> *发件人：*Peter Psenak 
> *收件人：*Huzhibo ;Aijun Wang 
> *抄 送：*Aijun Wang ;lsr
> ;Xiaoyaqun 
> *时 间：*2020-07-30 21:02:49
> *主 题：*Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
> Huzhibo,
>
> On 30/07/2020 14:49, Huzhibo wrote:
>>
>> Hi peter：
>>
>> On 30/07/2020 14:28, Aijun Wang wrote:
>>> Hi, Peter:
>>>
>>> Aijun Wang
>>> China Telecom
>>>
>>>> On Jul 30, 2020, at 20:00, Peter Psenak  wrote:
>>>>
>>>> Hi Aijun,
>>>>
>>>>> On 30/07/2020 13:44, Aijun Wang wrote:
>>>>> Hi, Peter:
>>>>> Currently, we have the following consideration:
>>>>> 1. If not all of the ABRs announce the unreachability of the specified 
>>>>> prefix(the specified prefix is still up), such PUA information will 
>>>>> continue advertising by the unreachable ABRs.
>>>>
>>>> so the behavior of ABR is going to be dependent on the behavior of the the 
>>>> other ABR(s)? That is a very thin ice you are dancing on.
>>>
>>> [WAJ] it is easy for ABR to get these information and make the judgment. 
>>> All ABRs locate within the same area.
>>
>> having that info is not the issue. The cyclic dependency is the one.
>>> [HZB] The cyclic dependency does not occur. The PUA advertisement behavior 
>>> of an ABR is not affected by the transient status of other ABRs. The 
>>> condition for canceling PUA advertisement is that all ABRs advertise the 
>>> PUA information with a certain prefix for 30 minutes.
>
> you have not convinced me with the above statement. You are making a
> dependency on the ABR behavior based on the other ABRs' behavior. That's
> a call for a trouble.
>
>
>>>
>>>>
>>>>> 2. If all of the ABRs announce the PUA of the specified prefix, such 
>>>>> information will be announced for a configurable duration, to make sure 
>>>>> other protocol(for example BGP) that based on the specified prefix has 
>>>>> converged.
>>>>
>>>> well, the problem is that no mater what is your configured time to 
>>>> advertise the un-reachability, you have no way of knowing whether the 
>>>> resource that became unreachable have done so intentionally and whether it 
>>>> will ever come back. And guessing based on the timer is not going to make 
>>>> it much better I'm afraid.
>>>>
>>>
>>> [WAJ] We need not care bout the reason for the unreachability. When ABR get 
>>> the PUA information from also all other ABRs, it will start one timer to 
>>> count the duration of following PUA message. After the duration, all ABRs 
>>> will stop the advertisement.
>>
>> once you stop advertising the un-reachability, you are back to square one as 
>> you were with the summary only.
>>> [HZB] There are two scenarios: First: The node is actually Down. In this 
>>> case, upper-layer services will be converged 30 minutes earlier.
>
> once you stop the unreachable advertisement, the resource will be seen
> as reachable outside of its area, even when it is down. That is a
> problem that you are trying to solve in a first place.
>
>
> thanks,
> Peter
>
> Even if the PUA is canceled, the problem will not occur. Second: If the
> node is not Down and only an ABR is unreachable, the ABR will
> continuously advertises PUA.
>>
>> thanks,
>> peter
>>
>>>
>>>
>>>> thanks

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi Zhibo,

On 30/07/2020 15:18, Huzhibo wrote:

HI Peter：

1：No problem is a problem that never can be proved.

2：For bgp example，when the pe node down，the bgp peer must down within
30 mintus，It will not get it up via cancle advertise pua.

for the above it is sufficient to advertise the unreachability for few
seconds from each ABR independently. That would be a much more solid
proposal.

thanks,
Peter

ZHIBO

--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com <mailto:huzh...@huawei.com>

*发件人：*Peter Psenak
*收件人：*Huzhibo ;Aijun Wang
*抄 送：*Aijun Wang ;lsr
;Xiaoyaqun

*时 间：*2020-07-30 21:02:49
*主 题：*Re: [Lsr] New Version Notification for
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Huzhibo,

On 30/07/2020 14:49, Huzhibo wrote:

Hi peter：

On 30/07/2020 14:28, Aijun Wang wrote:

Hi, Peter:

Aijun Wang
China Telecom

On Jul 30, 2020, at 20:00, Peter Psenak wrote:

Hi Aijun,

On 30/07/2020 13:44, Aijun Wang wrote:
Hi, Peter:
Currently, we have the following consideration:
1. If not all of the ABRs announce the unreachability of the specified
prefix(the specified prefix is still up), such PUA information will continue
advertising by the unreachable ABRs.

so the behavior of ABR is going to be dependent on the behavior of the the
other ABR(s)? That is a very thin ice you are dancing on.

[WAJ] it is easy for ABR to get these information and make the judgment. All
ABRs locate within the same area.

having that info is not the issue. The cyclic dependency is the one.

[HZB] The cyclic dependency does not occur. The PUA advertisement behavior of
an ABR is not affected by the transient status of other ABRs. The condition for
canceling PUA advertisement is that all ABRs advertise the PUA information with
a certain prefix for 30 minutes.

you have not convinced me with the above statement. You are making a
dependency on the ABR behavior based on the other ABRs' behavior. That's
a call for a trouble.

2. If all of the ABRs announce the PUA of the specified prefix, such
information will be announced for a configurable duration, to make sure other
protocol(for example BGP) that based on the specified prefix has converged.

well, the problem is that no mater what is your configured time to advertise
the un-reachability, you have no way of knowing whether the resource that
became unreachable have done so intentionally and whether it will ever come
back. And guessing based on the timer is not going to make it much better I'm
afraid.

[WAJ] We need not care bout the reason for the unreachability. When ABR get the
PUA information from also all other ABRs, it will start one timer to count the
duration of following PUA message. After the duration, all ABRs will stop the
advertisement.

once you stop advertising the un-reachability, you are back to square one as
you were with the summary only.
[HZB] There are two scenarios: First: The node is actually Down. In this case, upper-layer services will be converged 30 minutes earlier.

once you stop the unreachable advertisement, the resource will be seen
as reachable outside of its area, even when it is down. That is a
problem that you are trying to solve in a first place.

thanks,
Peter

Even if the PUA is canceled, the problem will not occur. Second: If the
node is not Down and only an ABR is unreachable, the ABR will
continuously advertises PUA.

thanks,
peter

thanks,
Peter

How about the above consideration and Do you have other thoughts ?
Aijun Wang
China Telecom

On Jul 30, 2020, at 17:21, Peter Psenak
wrote:

Hi Ajun,

one additional problem on top of others that have been mentioned is
how are you going to get rid of "old" un-reachability
announcements/

Let's imagine you have the following prefixes in your area 1:

- 10.10.0.1/32 - 10.0.0.255/32 - used for loopback adresses
- 10.10.1.0/30 - 10.10.10.252/32 - used for transit links

For simplicity your summary for area 1 is 10.0.0.0/16

1. Everything is up, you generate 10.0.0.0/16 on the ABR that
connects to area 1 to all remaining connected areas

2. A router in area 1 with loopback 10.10.0.25/32 goes down.

3. ABR in area 1 generates un-reachable announcement for
10.0.0.25/32 to all other connected areas

4. When does ABR stop generating the un-reachable announcement for 10.0.0.25/32? In section 6 you
mention that "The receiver router should keep the black hole routes for PUA as one
configurable time(MAX_T_PUA)", but the draft does not say anything about when the
un-reachability announcements should be removed by ABR. We can not rely on 10.10.0.25/32 ever
coming back, as the user may have simply removed it for good. Keeping the "stale"
un-reachability announcements may result in the LSDB growth over the period of time.

thanks,
Peter

On 27/07/2020 03:32, Aijun Wang wrote:
Hi, LSR experts:
We have uploaded the new version

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

HI Peter：

1：No problem is a problem that never can be proved.

2：For bgp example，when the pe node down，the bgp peer must down within 30 
mintus，It will not get it up via cancle advertise pua.


ZHIBO

--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com<mailto:huzh...@huawei.com>

发件人：Peter Psenak 
收件人：Huzhibo ;Aijun Wang 
抄 送：Aijun Wang ;lsr ;Xiaoyaqun 

时 间：2020-07-30 21:02:49
主 题：Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Huzhibo,

On 30/07/2020 14:49, Huzhibo wrote:
>
> Hi peter：
>
> On 30/07/2020 14:28, Aijun Wang wrote:
>> Hi, Peter:
>>
>> Aijun Wang
>> China Telecom
>>
>>> On Jul 30, 2020, at 20:00, Peter Psenak  wrote:
>>>
>>> Hi Aijun,
>>>
>>>> On 30/07/2020 13:44, Aijun Wang wrote:
>>>> Hi, Peter:
>>>> Currently, we have the following consideration:
>>>> 1. If not all of the ABRs announce the unreachability of the specified 
>>>> prefix(the specified prefix is still up), such PUA information will 
>>>> continue advertising by the unreachable ABRs.
>>>
>>> so the behavior of ABR is going to be dependent on the behavior of the the 
>>> other ABR(s)? That is a very thin ice you are dancing on.
>>
>> [WAJ] it is easy for ABR to get these information and make the judgment. All 
>> ABRs locate within the same area.
>
> having that info is not the issue. The cyclic dependency is the one.
>> [HZB] The cyclic dependency does not occur. The PUA advertisement behavior 
>> of an ABR is not affected by the transient status of other ABRs. The 
>> condition for canceling PUA advertisement is that all ABRs advertise the PUA 
>> information with a certain prefix for 30 minutes.

you have not convinced me with the above statement. You are making a
dependency on the ABR behavior based on the other ABRs' behavior. That's
a call for a trouble.


>>
>>>
>>>> 2. If all of the ABRs announce the PUA of the specified prefix, such 
>>>> information will be announced for a configurable duration, to make sure 
>>>> other protocol(for example BGP) that based on the specified prefix has 
>>>> converged.
>>>
>>> well, the problem is that no mater what is your configured time to 
>>> advertise the un-reachability, you have no way of knowing whether the 
>>> resource that became unreachable have done so intentionally and whether it 
>>> will ever come back. And guessing based on the timer is not going to make 
>>> it much better I'm afraid.
>>>
>>
>> [WAJ] We need not care bout the reason for the unreachability. When ABR get 
>> the PUA information from also all other ABRs, it will start one timer to 
>> count the duration of following PUA message. After the duration, all ABRs 
>> will stop the advertisement.
>
> once you stop advertising the un-reachability, you are back to square one as 
> you were with the summary only.
>> [HZB] There are two scenarios: First: The node is actually Down. In this 
>> case, upper-layer services will be converged 30 minutes earlier.

once you stop the unreachable advertisement, the resource will be seen
as reachable outside of its area, even when it is down. That is a
problem that you are trying to solve in a first place.


thanks,
Peter

Even if the PUA is canceled, the problem will not occur. Second: If the
node is not Down and only an ABR is unreachable, the ABR will
continuously advertises PUA.
>
> thanks,
> peter
>
>>
>>
>>> thanks,
>>> Peter
>>>
>>>
>>>> How about the above consideration and Do you have other thoughts ?
>>>> Aijun Wang
>>>> China Telecom
>>>>>> On Jul 30, 2020, at 17:21, Peter Psenak 
>>>>>>  wrote:
>>>>>
>>>>> Hi Ajun,
>>>>>
>>>>> one additional problem on top of others that have been mentioned is
>>>>> how are you going to get rid of "old" un-reachability
>>>>> announcements/
>>>>>
>>>>> Let's imagine you have the following prefixes in your area 1:
>>>>>
>>>>> - 10.10.0.1/32 - 10.0.0.255/32 - used for loopback adresses
>>>>> - 10.10.1.0/30 - 10.10.10.252/32 - used for transit links
>>>>>
>>>>> For simplicity your summary for area 1 is 10.0.0.0/16
>>>>>
>>>>> 1. Everything is up, you generate 10.0.0.0/16 on the ABR that
>>>>> connects to area 1 to all remaining conne

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt


Huzhibo,

On 30/07/2020 14:49, Huzhibo wrote:


Hi peter：

On 30/07/2020 14:28, Aijun Wang wrote:

Hi, Peter:

Aijun Wang
China Telecom


On Jul 30, 2020, at 20:00, Peter Psenak  wrote:

Hi Aijun,


On 30/07/2020 13:44, Aijun Wang wrote:
Hi, Peter:
Currently, we have the following consideration:
1. If not all of the ABRs announce the unreachability of the specified 
prefix(the specified prefix is still up), such PUA information will continue 
advertising by the unreachable ABRs.


so the behavior of ABR is going to be dependent on the behavior of the the 
other ABR(s)? That is a very thin ice you are dancing on.


[WAJ] it is easy for ABR to get these information and make the judgment. All 
ABRs locate within the same area.


having that info is not the issue. The cyclic dependency is the one.

[HZB] The cyclic dependency does not occur. The PUA advertisement behavior of 
an ABR is not affected by the transient status of other ABRs. The condition for 
canceling PUA advertisement is that all ABRs advertise the PUA information with 
a certain prefix for 30 minutes.


you have not convinced me with the above statement. You are making a 
dependency on the ABR behavior based on the other ABRs' behavior. That's 
a call for a trouble.








2. If all of the ABRs announce the PUA of the specified prefix, such 
information will be announced for a configurable duration, to make sure other 
protocol(for example BGP) that based on the specified prefix has converged.


well, the problem is that no mater what is your configured time to advertise 
the un-reachability, you have no way of knowing whether the resource that 
became unreachable have done so intentionally and whether it will ever come 
back. And guessing based on the timer is not going to make it much better I'm 
afraid.



[WAJ] We need not care bout the reason for the unreachability. When ABR get the 
PUA information from also all other ABRs, it will start one timer to count the 
duration of following PUA message. After the duration, all ABRs will stop the 
advertisement.


once you stop advertising the un-reachability, you are back to square one as 
you were with the summary only.
[HZB] There are two scenarios: First: The node is actually Down. In this case, upper-layer services will be converged 30 minutes earlier. 


once you stop the unreachable advertisement, the resource will be seen 
as reachable outside of its area, even when it is down. That is a 
problem that you are trying to solve in a first place.



thanks,
Peter

Even if the PUA is canceled, the problem will not occur. Second: If the 
node is not Down and only an ABR is unreachable, the ABR will 
continuously advertises PUA.


thanks,
peter





thanks,
Peter



How about the above consideration and Do you have other thoughts ?
Aijun Wang
China Telecom

On Jul 30, 2020, at 17:21, Peter Psenak  
wrote:


Hi Ajun,

one additional problem on top of others that have been mentioned is
how are you going to get rid of "old" un-reachability
announcements/

Let's imagine you have the following prefixes in your area 1:

- 10.10.0.1/32 - 10.0.0.255/32 - used for loopback adresses
- 10.10.1.0/30 - 10.10.10.252/32 - used for transit links

For simplicity your summary for area 1 is 10.0.0.0/16

1. Everything is up, you generate 10.0.0.0/16 on the ABR that
connects to area 1 to all remaining connected areas

2. A router in area 1 with loopback 10.10.0.25/32 goes down.

3. ABR in area 1 generates un-reachable announcement for
10.0.0.25/32 to all other connected areas

4. When does ABR stop generating the un-reachable announcement for 10.0.0.25/32? In section 6 you 
mention that "The receiver router should keep the black hole routes for PUA as one 
configurable time(MAX_T_PUA)", but the draft does not say anything about when the 
un-reachability announcements should be removed by ABR. We can not rely on 10.10.0.25/32 ever 
coming back, as the user may have simply removed it for good. Keeping the "stale" 
un-reachability announcements may result in the LSDB growth over the period of time.


thanks,
Peter





On 27/07/2020 03:32, Aijun Wang wrote:
Hi, LSR experts:
We have uploaded the new version of this PUA(Prefix Unreachable Announcement) 
draft. The main updates are the followings:
1) Describes the solution that using tunnel to redirect traffic among ABRs, 
when all ABRs reaches the PUA limit.
2) Describe fast rerouting to avoid routing black hole.
3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS.
There are also some arguments about the current solution for PUA, for example:
1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to indicate 
the prefix is unreachable?
2) if not, what's the consideration? What's the other convincible solution?
Wish to hear comments and suggestions on the above issues. We will also have 
the presentation on the coming IETF LSR meeting.
Best Regards
Aijun Wang
China Telecom
-Original Message-
From: internet-dra...@ietf.org [mailto:inter

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt


Hi peter：

On 30/07/2020 14:28, Aijun Wang wrote:
> Hi, Peter:
> 
> Aijun Wang
> China Telecom
> 
>> On Jul 30, 2020, at 20:00, Peter Psenak  wrote:
>>
>> Hi Aijun,
>>
>>> On 30/07/2020 13:44, Aijun Wang wrote:
>>> Hi, Peter:
>>> Currently, we have the following consideration:
>>> 1. If not all of the ABRs announce the unreachability of the specified 
>>> prefix(the specified prefix is still up), such PUA information will 
>>> continue advertising by the unreachable ABRs.
>>
>> so the behavior of ABR is going to be dependent on the behavior of the the 
>> other ABR(s)? That is a very thin ice you are dancing on.
> 
> [WAJ] it is easy for ABR to get these information and make the judgment. All 
> ABRs locate within the same area.

having that info is not the issue. The cyclic dependency is the one.
> [HZB] The cyclic dependency does not occur. The PUA advertisement behavior of 
> an ABR is not affected by the transient status of other ABRs. The condition 
> for canceling PUA advertisement is that all ABRs advertise the PUA 
> information with a certain prefix for 30 minutes.
> 
>>
>>> 2. If all of the ABRs announce the PUA of the specified prefix, such 
>>> information will be announced for a configurable duration, to make sure 
>>> other protocol(for example BGP) that based on the specified prefix has 
>>> converged.
>>
>> well, the problem is that no mater what is your configured time to advertise 
>> the un-reachability, you have no way of knowing whether the resource that 
>> became unreachable have done so intentionally and whether it will ever come 
>> back. And guessing based on the timer is not going to make it much better 
>> I'm afraid.
>>
> 
> [WAJ] We need not care bout the reason for the unreachability. When ABR get 
> the PUA information from also all other ABRs, it will start one timer to 
> count the duration of following PUA message. After the duration, all ABRs 
> will stop the advertisement.

once you stop advertising the un-reachability, you are back to square one as 
you were with the summary only.
> [HZB] There are two scenarios: First: The node is actually Down. In this 
> case, upper-layer services will be converged 30 minutes earlier. Even if the 
> PUA is canceled, the problem will not occur. Second: If the node is not Down 
> and only an ABR is unreachable, the ABR will continuously advertises PUA.

thanks,
peter

> 
> 
>> thanks,
>> Peter
>>
>>
>>> How about the above consideration and Do you have other thoughts ?
>>> Aijun Wang
>>> China Telecom
> On Jul 30, 2020, at 17:21, Peter Psenak 
>  wrote:

 Hi Ajun,

 one additional problem on top of others that have been mentioned is 
 how are you going to get rid of "old" un-reachability 
 announcements/

 Let's imagine you have the following prefixes in your area 1:

 - 10.10.0.1/32 - 10.0.0.255/32 - used for loopback adresses
 - 10.10.1.0/30 - 10.10.10.252/32 - used for transit links

 For simplicity your summary for area 1 is 10.0.0.0/16

 1. Everything is up, you generate 10.0.0.0/16 on the ABR that 
 connects to area 1 to all remaining connected areas

 2. A router in area 1 with loopback 10.10.0.25/32 goes down.

 3. ABR in area 1 generates un-reachable announcement for 
 10.0.0.25/32 to all other connected areas

 4. When does ABR stop generating the un-reachable announcement for 
 10.0.0.25/32? In section 6 you mention that "The receiver router should 
 keep the black hole routes for PUA as one configurable time(MAX_T_PUA)", 
 but the draft does not say anything about when the un-reachability 
 announcements should be removed by ABR. We can not rely on 10.10.0.25/32 
 ever coming back, as the user may have simply removed it for good. Keeping 
 the "stale" un-reachability announcements may result in the LSDB growth 
 over the period of time.


 thanks,
 Peter




> On 27/07/2020 03:32, Aijun Wang wrote:
> Hi, LSR experts:
> We have uploaded the new version of this PUA(Prefix Unreachable 
> Announcement) draft. The main updates are the followings:
> 1) Describes the solution that using tunnel to redirect traffic among 
> ABRs, when all ABRs reaches the PUA limit.
> 2) Describe fast rerouting to avoid routing black hole.
> 3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS.
> There are also some arguments about the current solution for PUA, for 
> example:
> 1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to 
> indicate the prefix is unreachable?
> 2) if not, what's the consideration? What's the other convincible 
> solution?
> Wish to hear comments and suggestions on the above issues. We will also 
> have the presentation on the coming IETF LSR meeting.
> Best Regards
> Aijun Wang
> China Telecom
> -Original Message-
> From: internet-dra...@ietf

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt


Aijun,

On 30/07/2020 14:28, Aijun Wang wrote:

Hi, Peter:

Aijun Wang
China Telecom


On Jul 30, 2020, at 20:00, Peter Psenak  wrote:

Hi Aijun,


On 30/07/2020 13:44, Aijun Wang wrote:
Hi, Peter:
Currently, we have the following consideration:
1. If not all of the ABRs announce the unreachability of the specified 
prefix(the specified prefix is still up), such PUA information will continue 
advertising by the unreachable ABRs.


so the behavior of ABR is going to be dependent on the behavior of the the 
other ABR(s)? That is a very thin ice you are dancing on.


[WAJ] it is easy for ABR to get these information and make the judgment. All 
ABRs locate within the same area.


having that info is not the issue. The cyclic dependency is the one.






2. If all of the ABRs announce the PUA of the specified prefix, such 
information will be announced for a configurable duration, to make sure other 
protocol(for example BGP) that based on the specified prefix has converged.


well, the problem is that no mater what is your configured time to advertise 
the un-reachability, you have no way of knowing whether the resource that 
became unreachable have done so intentionally and whether it will ever come 
back. And guessing based on the timer is not going to make it much better I'm 
afraid.



[WAJ] We need not care bout the reason for the unreachability. When ABR get the 
PUA information from also all other ABRs, it will start one timer to count the 
duration of following PUA message. After the duration, all ABRs will stop the 
advertisement.


once you stop advertising the un-reachability, you are back to square 
one as you were with the summary only.


thanks,
peter





thanks,
Peter



How about the above consideration and
Do you have other thoughts ?
Aijun Wang
China Telecom

On Jul 30, 2020, at 17:21, Peter Psenak  
wrote:


Hi Ajun,

one additional problem on top of others that have been mentioned is how are you going to 
get rid of "old" un-reachability announcements/

Let's imagine you have the following prefixes in your area 1:

- 10.10.0.1/32 - 10.0.0.255/32 - used for loopback adresses
- 10.10.1.0/30 - 10.10.10.252/32 - used for transit links

For simplicity your summary for area 1 is 10.0.0.0/16

1. Everything is up, you generate 10.0.0.0/16 on the ABR that connects to area 
1 to all remaining connected areas

2. A router in area 1 with loopback 10.10.0.25/32 goes down.

3. ABR in area 1 generates un-reachable announcement for 10.0.0.25/32 to all 
other connected areas

4. When does ABR stop generating the un-reachable announcement for 10.0.0.25/32? In section 6 you 
mention that "The receiver router should keep the black hole routes for PUA as one 
configurable time(MAX_T_PUA)", but the draft does not say anything about when the 
un-reachability announcements should be removed by ABR. We can not rely on 10.10.0.25/32 ever 
coming back, as the user may have simply removed it for good. Keeping the "stale" 
un-reachability announcements may result in the LSDB growth over the period of time.


thanks,
Peter





On 27/07/2020 03:32, Aijun Wang wrote:
Hi, LSR experts:
We have uploaded the new version of this PUA(Prefix Unreachable Announcement) 
draft. The main updates are the followings:
1) Describes the solution that using tunnel to redirect traffic among ABRs, 
when all ABRs reaches the PUA limit.
2) Describe fast rerouting to avoid routing black hole.
3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS.
There are also some arguments about the current solution for PUA, for example:
1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to indicate 
the prefix is unreachable?
2) if not, what's the consideration? What's the other convincible solution?
Wish to hear comments and suggestions on the above issues. We will also have 
the presentation on the coming IETF LSR meeting.
Best Regards
Aijun Wang
China Telecom
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu ; Aijun Wang ; Yaqun Xiao 

Subject: New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt
A new version of I-D, draft-wang-lsr-prefix-unreachable-annoucement-03.txt
has been successfully submitted by Aijun Wang and posted to the IETF repository.
Name:draft-wang-lsr-prefix-unreachable-annoucement
Revision:03
Title:Prefix Unreachable Announcement
Document date:2020-07-27
Group:Individual Submission
Pages:11
URL:
https://www.ietf.org/internet-drafts/draft-wang-lsr-prefix-unreachable-annoucement-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
Htmlized:   
https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-03
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-wang-l

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi, Peter:

Aijun Wang
China Telecom

> On Jul 30, 2020, at 20:00, Peter Psenak  wrote:
> 
> Hi Aijun,
> 
>> On 30/07/2020 13:44, Aijun Wang wrote:
>> Hi, Peter:
>> Currently, we have the following consideration:
>> 1. If not all of the ABRs announce the unreachability of the specified 
>> prefix(the specified prefix is still up), such PUA information will continue 
>> advertising by the unreachable ABRs.
> 
> so the behavior of ABR is going to be dependent on the behavior of the the 
> other ABR(s)? That is a very thin ice you are dancing on.

[WAJ] it is easy for ABR to get these information and make the judgment. All 
ABRs locate within the same area.

> 
>> 2. If all of the ABRs announce the PUA of the specified prefix, such 
>> information will be announced for a configurable duration, to make sure 
>> other protocol(for example BGP) that based on the specified prefix has 
>> converged.
> 
> well, the problem is that no mater what is your configured time to advertise 
> the un-reachability, you have no way of knowing whether the resource that 
> became unreachable have done so intentionally and whether it will ever come 
> back. And guessing based on the timer is not going to make it much better I'm 
> afraid.
> 

[WAJ] We need not care bout the reason for the unreachability. When ABR get the 
PUA information from also all other ABRs, it will start one timer to count the 
duration of following PUA message. After the duration, all ABRs will stop the 
advertisement. 


> thanks,
> Peter
> 
> 
>> How about the above consideration and
>> Do you have other thoughts ?
>> Aijun Wang
>> China Telecom
 On Jul 30, 2020, at 17:21, Peter Psenak 
  wrote:
>>> 
>>> Hi Ajun,
>>> 
>>> one additional problem on top of others that have been mentioned is how are 
>>> you going to get rid of "old" un-reachability announcements/
>>> 
>>> Let's imagine you have the following prefixes in your area 1:
>>> 
>>> - 10.10.0.1/32 - 10.0.0.255/32 - used for loopback adresses
>>> - 10.10.1.0/30 - 10.10.10.252/32 - used for transit links
>>> 
>>> For simplicity your summary for area 1 is 10.0.0.0/16
>>> 
>>> 1. Everything is up, you generate 10.0.0.0/16 on the ABR that connects to 
>>> area 1 to all remaining connected areas
>>> 
>>> 2. A router in area 1 with loopback 10.10.0.25/32 goes down.
>>> 
>>> 3. ABR in area 1 generates un-reachable announcement for 10.0.0.25/32 to 
>>> all other connected areas
>>> 
>>> 4. When does ABR stop generating the un-reachable announcement for 
>>> 10.0.0.25/32? In section 6 you mention that "The receiver router should 
>>> keep the black hole routes for PUA as one configurable time(MAX_T_PUA)", 
>>> but the draft does not say anything about when the un-reachability 
>>> announcements should be removed by ABR. We can not rely on 10.10.0.25/32 
>>> ever coming back, as the user may have simply removed it for good. Keeping 
>>> the "stale" un-reachability announcements may result in the LSDB growth 
>>> over the period of time.
>>> 
>>> 
>>> thanks,
>>> Peter
>>> 
>>> 
>>> 
>>> 
 On 27/07/2020 03:32, Aijun Wang wrote:
 Hi, LSR experts:
 We have uploaded the new version of this PUA(Prefix Unreachable 
 Announcement) draft. The main updates are the followings:
 1) Describes the solution that using tunnel to redirect traffic among 
 ABRs, when all ABRs reaches the PUA limit.
 2) Describe fast rerouting to avoid routing black hole.
 3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS.
 There are also some arguments about the current solution for PUA, for 
 example:
 1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to 
 indicate the prefix is unreachable?
 2) if not, what's the consideration? What's the other convincible solution?
 Wish to hear comments and suggestions on the above issues. We will also 
 have the presentation on the coming IETF LSR meeting.
 Best Regards
 Aijun Wang
 China Telecom
 -Original Message-
 From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
 Sent: Monday, July 27, 2020 9:16 AM
 To: Zhibo Hu ; Aijun Wang ; 
 Yaqun Xiao 
 Subject: New Version Notification for 
 draft-wang-lsr-prefix-unreachable-annoucement-03.txt
 A new version of I-D, draft-wang-lsr-prefix-unreachable-annoucement-03.txt
 has been successfully submitted by Aijun Wang and posted to the IETF 
 repository.
 Name:draft-wang-lsr-prefix-unreachable-annoucement
 Revision:03
 Title:Prefix Unreachable Announcement
 Document date:2020-07-27
 Group:Individual Submission
 Pages:11
 URL:
 https://www.ietf.org/internet-drafts/draft-wang-lsr-prefix-unreachable-annoucement-03.txt
 Status: 
 https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
 Htmlized:   
 https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt


Hi Aijun,

On 30/07/2020 13:44, Aijun Wang wrote:

Hi, Peter:
Currently, we have the following consideration:
1. If not all of the ABRs announce the unreachability of the specified 
prefix(the specified prefix is still up), such PUA information will continue 
advertising by the unreachable ABRs.


so the behavior of ABR is going to be dependent on the behavior of the 
the other ABR(s)? That is a very thin ice you are dancing on.



2. If all of the ABRs announce the PUA of the specified prefix, such 
information will be announced for a configurable duration, to make sure other 
protocol(for example BGP) that based on the specified prefix has converged.


well, the problem is that no mater what is your configured time to 
advertise the un-reachability, you have no way of knowing whether the 
resource that became unreachable have done so intentionally and whether 
it will ever come back. And guessing based on the timer is not going to 
make it much better I'm afraid.


thanks,
Peter



How about the above consideration and
Do you have other thoughts ?

Aijun Wang
China Telecom


On Jul 30, 2020, at 17:21, Peter Psenak  
wrote:

Hi Ajun,

one additional problem on top of others that have been mentioned is how are you going to 
get rid of "old" un-reachability announcements/

Let's imagine you have the following prefixes in your area 1:

- 10.10.0.1/32 - 10.0.0.255/32 - used for loopback adresses
- 10.10.1.0/30 - 10.10.10.252/32 - used for transit links

For simplicity your summary for area 1 is 10.0.0.0/16

1. Everything is up, you generate 10.0.0.0/16 on the ABR that connects to area 
1 to all remaining connected areas

2. A router in area 1 with loopback 10.10.0.25/32 goes down.

3. ABR in area 1 generates un-reachable announcement for 10.0.0.25/32 to all 
other connected areas

4. When does ABR stop generating the un-reachable announcement for 10.0.0.25/32? In section 6 you 
mention that "The receiver router should keep the black hole routes for PUA as one 
configurable time(MAX_T_PUA)", but the draft does not say anything about when the 
un-reachability announcements should be removed by ABR. We can not rely on 10.10.0.25/32 ever 
coming back, as the user may have simply removed it for good. Keeping the "stale" 
un-reachability announcements may result in the LSDB growth over the period of time.


thanks,
Peter





On 27/07/2020 03:32, Aijun Wang wrote:
Hi, LSR experts:
We have uploaded the new version of this PUA(Prefix Unreachable Announcement) 
draft. The main updates are the followings:
1) Describes the solution that using tunnel to redirect traffic among ABRs, 
when all ABRs reaches the PUA limit.
2) Describe fast rerouting to avoid routing black hole.
3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS.
There are also some arguments about the current solution for PUA, for example:
1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to indicate 
the prefix is unreachable?
2) if not, what's the consideration? What's the other convincible solution?
Wish to hear comments and suggestions on the above issues. We will also have 
the presentation on the coming IETF LSR meeting.
Best Regards
Aijun Wang
China Telecom
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu ; Aijun Wang ; Yaqun Xiao 

Subject: New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt
A new version of I-D, draft-wang-lsr-prefix-unreachable-annoucement-03.txt
has been successfully submitted by Aijun Wang and posted to the IETF repository.
Name:draft-wang-lsr-prefix-unreachable-annoucement
Revision:03
Title:Prefix Unreachable Announcement
Document date:2020-07-27
Group:Individual Submission
Pages:11
URL:
https://www.ietf.org/internet-drafts/draft-wang-lsr-prefix-unreachable-annoucement-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
Htmlized:   
https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-03
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-prefix-unreachable-annoucement-03
Abstract:
This document describes the mechanism that can be used to announce
the unreachable prefixes for service fast convergence.

   Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr






___

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi, Peter:
Currently, we have the following consideration:
1. If not all of the ABRs announce the unreachability of the specified 
prefix(the specified prefix is still up), such PUA information will continue 
advertising by the unreachable ABRs.
2. If all of the ABRs announce the PUA of the specified prefix, such 
information will be announced for a configurable duration, to make sure other 
protocol(for example BGP) that based on the specified prefix has converged.
How about the above consideration and 
Do you have other thoughts ?

Aijun Wang
China Telecom

> On Jul 30, 2020, at 17:21, Peter Psenak  
> wrote:
> 
> Hi Ajun,
> 
> one additional problem on top of others that have been mentioned is how are 
> you going to get rid of "old" un-reachability announcements/
> 
> Let's imagine you have the following prefixes in your area 1:
> 
> - 10.10.0.1/32 - 10.0.0.255/32 - used for loopback adresses
> - 10.10.1.0/30 - 10.10.10.252/32 - used for transit links
> 
> For simplicity your summary for area 1 is 10.0.0.0/16
> 
> 1. Everything is up, you generate 10.0.0.0/16 on the ABR that connects to 
> area 1 to all remaining connected areas
> 
> 2. A router in area 1 with loopback 10.10.0.25/32 goes down.
> 
> 3. ABR in area 1 generates un-reachable announcement for 10.0.0.25/32 to all 
> other connected areas
> 
> 4. When does ABR stop generating the un-reachable announcement for 
> 10.0.0.25/32? In section 6 you mention that "The receiver router should keep 
> the black hole routes for PUA as one configurable time(MAX_T_PUA)", but the 
> draft does not say anything about when the un-reachability announcements 
> should be removed by ABR. We can not rely on 10.10.0.25/32 ever coming back, 
> as the user may have simply removed it for good. Keeping the "stale" 
> un-reachability announcements may result in the LSDB growth over the period 
> of time.
> 
> 
> thanks,
> Peter
> 
> 
> 
> 
>> On 27/07/2020 03:32, Aijun Wang wrote:
>> Hi, LSR experts:
>> We have uploaded the new version of this PUA(Prefix Unreachable 
>> Announcement) draft. The main updates are the followings:
>> 1) Describes the solution that using tunnel to redirect traffic among ABRs, 
>> when all ABRs reaches the PUA limit.
>> 2) Describe fast rerouting to avoid routing black hole.
>> 3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS.
>> There are also some arguments about the current solution for PUA, for 
>> example:
>> 1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to indicate 
>> the prefix is unreachable?
>> 2) if not, what's the consideration? What's the other convincible solution?
>> Wish to hear comments and suggestions on the above issues. We will also have 
>> the presentation on the coming IETF LSR meeting.
>> Best Regards
>> Aijun Wang
>> China Telecom
>> -Original Message-
>> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
>> Sent: Monday, July 27, 2020 9:16 AM
>> To: Zhibo Hu ; Aijun Wang ; 
>> Yaqun Xiao 
>> Subject: New Version Notification for 
>> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>> A new version of I-D, draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>> has been successfully submitted by Aijun Wang and posted to the IETF 
>> repository.
>> Name:draft-wang-lsr-prefix-unreachable-annoucement
>> Revision:03
>> Title:Prefix Unreachable Announcement
>> Document date:2020-07-27
>> Group:Individual Submission
>> Pages:11
>> URL:
>> https://www.ietf.org/internet-drafts/draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
>> Htmlized:   
>> https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-03
>> Htmlized:   
>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement
>> Diff:   
>> https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-prefix-unreachable-annoucement-03
>> Abstract:
>>This document describes the mechanism that can be used to announce
>>the unreachable prefixes for service fast convergence.
>>  
>>  Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>> The IETF Secretariat
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt