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

2020-09-09 Thread Aijun Wang
Hi, Robert:

 

Summary on ABRs.  Please see the description in section-3.3 
<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-3.3>
  of this draft.

 

 

From: rob...@raszuk.net [mailto:rob...@raszuk.net] 
Sent: Wednesday, September 9, 2020 3:08 PM
To: Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
; Peter Psenak ; 
Huzhibo ; Aijun Wang ; lsr 
; Acee Lindem (acee) ; Xiaoyaqun 
; Tony Przygienda 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

Hi,

 

Intra area ?

 

If we are flooding host routes I have never seen a case where intra area those 
are not flooded.

 

Where would you summarise ? On a node within area ?

 

 

Very unreal scenario IMHO.

 

Thx

R.

 

On Wed, Sep 9, 2020, 03:22 Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Robert:

 

PUA covers both the intra-area and inter-area scenarios. 

For inter-area scenario, it covers the situation that the next-hop is reachable 
via one ABR but unreachable via another ABR.

For such situation, BGP nexthop tracking, route withdraw or aggregate withdraw 
will not work.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>  
[mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> ] On Behalf Of 
Robert Raszuk
Sent: Monday, September 7, 2020 5:36 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn> >
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> >; 
Gyan Mishra mailto:hayabusa...@gmail.com> >; Peter 
Psenak mailto:40cisco@dmarc.ietf.org> 
>; Huzhibo mailto:huzh...@huawei.com> >; Aijun Wang 
mailto:wang...@chinatelecom.cn> >; lsr mailto:lsr@ietf.org> >; Acee Lindem (acee) mailto:a...@cisco.com> >; Xiaoyaqun mailto:xiaoya...@huawei.com> >; Tony Przygienda mailto:tonysi...@gmail.com> >
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

Hi Aijun,

 

> the BGP next-hop is reachable  

 

Nope you missed the crux of the message. 

 

The next hop will be unreachable in the source area/level. That would be where 
the BGP service route withdraw or aggregate withdraw would originate at. Same 
as PUA. 

 

Best,

Robert.

 

 

On Mon, Sep 7, 2020 at 11:31 AM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Robert:

For BGP next-hop tracking, it will help when the BGP next-hop is unreachable. 
But in our situation, the BGP next-hop is reachable, but should pass another 
ABR.

Then, in such situation, the mechanism of BGP next-hop tracking will not take 
effect?

And thanks for your draft information, maybe we can refer to it later J

 

Best Regards

 

Aijun Wang

China Telecom

 

 

From: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>  
[mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> ] On Behalf Of 
Robert Raszuk
Sent: Monday, September 7, 2020 4:54 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn> >
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> >; 
Gyan Mishra mailto:hayabusa...@gmail.com> >; Peter 
Psenak mailto:40cisco@dmarc.ietf.org> 
>; Huzhibo mailto:huzh...@huawei.com> >; Aijun Wang 
mailto:wang...@chinatelecom.cn> >; lsr mailto:lsr@ietf.org> >; Acee Lindem (acee) mailto:a...@cisco.com> >; Xiaoyaqun mailto:xiaoya...@huawei.com> >; Tony Przygienda mailto:tonysi...@gmail.com> >
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

Hi Aijun,

[WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for the 
hold of PUA information on the nodes) among the area.

If one node connect to the network after the disappearance of the PUA 
destination,  there will be no services can be established/run on these failure 
node/link prefix. 

It’s the same as the beginning, as not all of the prefixes can be reachable 
within the summary address.

 

>From my pov the only advantage of negative routes in IGP would be to very 
>quickly invalidate service routes (within the IGP domain) typically carried by 
>BGP. 

 

When this is accomplished the PUA can indeed time out with no harm. 

 

Said this - now considering tools like next hop tracking which can trigger 
withdraw or aggregated withdraw(*) proposal in src area I am  really curious 
how much (if anything) we would be gaining here. 

 

(*) The original proposal for this was written over 15 years ago: 
https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00  We could extend it 
with next hop which would be the same as IGP PUA prefix. 

 

Kind regards,
Robert

 

___
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-09-09 Thread Robert Raszuk
Hi,

Intra area ?

If we are flooding host routes I have never seen a case where intra area
those are not flooded.

Where would you summarise ? On a node within area ?

Very unreal scenario IMHO.

Thx
R.

On Wed, Sep 9, 2020, 03:22 Aijun Wang  wrote:

> Hi, Robert:
>
>
>
> PUA covers both the intra-area and inter-area scenarios.
>
> For inter-area scenario, it covers the situation that the next-hop is
> reachable via one ABR but unreachable via another ABR.
>
> For such situation, BGP nexthop tracking, route withdraw or aggregate
> withdraw will not work.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of 
> *Robert
> Raszuk
> *Sent:* Monday, September 7, 2020 5:36 PM
> *To:* Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
> hayabusa...@gmail.com>; Peter Psenak ;
> Huzhibo ; Aijun Wang ; lsr <
> lsr@ietf.org>; Acee Lindem (acee) ; Xiaoyaqun <
> xiaoya...@huawei.com>; Tony Przygienda 
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hi Aijun,
>
>
>
> > the BGP next-hop is reachable
>
>
>
> Nope you missed the crux of the message.
>
>
>
> The next hop will be unreachable in the *source area/level. *That would
> be where the BGP service route withdraw or aggregate withdraw would
> originate at. Same as PUA.
>
>
>
> Best,
>
> Robert.
>
>
>
>
>
> On Mon, Sep 7, 2020 at 11:31 AM Aijun Wang 
> wrote:
>
> Hi, Robert:
>
> For BGP next-hop tracking, it will help when the BGP next-hop is
> unreachable. But in our situation, the BGP next-hop is reachable, but
> should pass another ABR.
>
> Then, in such situation, the mechanism of BGP next-hop tracking will not
> take effect?
>
> And thanks for your draft information, maybe we can refer to it later J
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of 
> *Robert
> Raszuk
> *Sent:* Monday, September 7, 2020 4:54 PM
> *To:* Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
> hayabusa...@gmail.com>; Peter Psenak ;
> Huzhibo ; Aijun Wang ; lsr <
> lsr@ietf.org>; Acee Lindem (acee) ; Xiaoyaqun <
> xiaoya...@huawei.com>; Tony Przygienda 
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hi Aijun,
>
> *[WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for
> the hold of PUA information on the nodes) among the area.*
>
> *If one node connect to the network after the disappearance of the PUA
> destination,  there will be no services can be established/run on these
> failure node/link prefix. *
>
> *It**’s the same as the beginning, as not all of the prefixes can be
> reachable within the summary address.*
>
>
>
> From my pov the only advantage of negative routes in IGP would be to very
> quickly invalidate service routes (within the IGP domain) typically carried
> by BGP.
>
>
>
> When this is accomplished the PUA can indeed time out with no harm.
>
>
>
> Said this - now considering tools like next hop tracking which can trigger
> withdraw or aggregated withdraw(*) proposal in src area I am  really
> curious how much (if anything) we would be gaining here.
>
>
>
> (*) The original proposal for this was written over 15 years ago:
> https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00  We could
> extend it with next hop which would be the same as IGP PUA prefix.
>
>
>
> Kind regards,
> Robert
>
>
>
>
___
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-09-08 Thread Aijun Wang
Hi, Robert:

 

PUA covers both the intra-area and inter-area scenarios. 

For inter-area scenario, it covers the situation that the next-hop is reachable 
via one ABR but unreachable via another ABR.

For such situation, BGP nexthop tracking, route withdraw or aggregate withdraw 
will not work.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Robert 
Raszuk
Sent: Monday, September 7, 2020 5:36 PM
To: Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
; Peter Psenak ; 
Huzhibo ; Aijun Wang ; lsr 
; Acee Lindem (acee) ; Xiaoyaqun 
; Tony Przygienda 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

Hi Aijun,

 

> the BGP next-hop is reachable  

 

Nope you missed the crux of the message. 

 

The next hop will be unreachable in the source area/level. That would be where 
the BGP service route withdraw or aggregate withdraw would originate at. Same 
as PUA. 

 

Best,

Robert.

 

 

On Mon, Sep 7, 2020 at 11:31 AM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Robert:

For BGP next-hop tracking, it will help when the BGP next-hop is unreachable. 
But in our situation, the BGP next-hop is reachable, but should pass another 
ABR.

Then, in such situation, the mechanism of BGP next-hop tracking will not take 
effect?

And thanks for your draft information, maybe we can refer to it later J

 

Best Regards

 

Aijun Wang

China Telecom

 

 

From: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>  
[mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> ] On Behalf Of 
Robert Raszuk
Sent: Monday, September 7, 2020 4:54 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn> >
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> >; 
Gyan Mishra mailto:hayabusa...@gmail.com> >; Peter 
Psenak mailto:40cisco@dmarc.ietf.org> 
>; Huzhibo mailto:huzh...@huawei.com> >; Aijun Wang 
mailto:wang...@chinatelecom.cn> >; lsr mailto:lsr@ietf.org> >; Acee Lindem (acee) mailto:a...@cisco.com> >; Xiaoyaqun mailto:xiaoya...@huawei.com> >; Tony Przygienda mailto:tonysi...@gmail.com> >
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

Hi Aijun,

[WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for the 
hold of PUA information on the nodes) among the area.

If one node connect to the network after the disappearance of the PUA 
destination,  there will be no services can be established/run on these failure 
node/link prefix. 

It’s the same as the beginning, as not all of the prefixes can be reachable 
within the summary address.

 

>From my pov the only advantage of negative routes in IGP would be to very 
>quickly invalidate service routes (within the IGP domain) typically carried by 
>BGP. 

 

When this is accomplished the PUA can indeed time out with no harm. 

 

Said this - now considering tools like next hop tracking which can trigger 
withdraw or aggregated withdraw(*) proposal in src area I am  really curious 
how much (if anything) we would be gaining here. 

 

(*) The original proposal for this was written over 15 years ago: 
https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00  We could extend it 
with next hop which would be the same as IGP PUA prefix. 

 

Kind regards,
Robert

 

___
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-09-07 Thread Robert Raszuk
Hi Aijun,

> the BGP next-hop is reachable

Nope you missed the crux of the message.

The next hop will be unreachable in the *source area/level. *That would be
where the BGP service route withdraw or aggregate withdraw would originate
at. Same as PUA.

Best,
Robert.


On Mon, Sep 7, 2020 at 11:31 AM Aijun Wang 
wrote:

> Hi, Robert:
>
> For BGP next-hop tracking, it will help when the BGP next-hop is
> unreachable. But in our situation, the BGP next-hop is reachable, but
> should pass another ABR.
>
> Then, in such situation, the mechanism of BGP next-hop tracking will not
> take effect?
>
> And thanks for your draft information, maybe we can refer to it later J
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of 
> *Robert
> Raszuk
> *Sent:* Monday, September 7, 2020 4:54 PM
> *To:* Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
> hayabusa...@gmail.com>; Peter Psenak ;
> Huzhibo ; Aijun Wang ; lsr <
> lsr@ietf.org>; Acee Lindem (acee) ; Xiaoyaqun <
> xiaoya...@huawei.com>; Tony Przygienda 
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hi Aijun,
>
> *[WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for
> the hold of PUA information on the nodes) among the area.*
>
> *If one node connect to the network after the disappearance of the PUA
> destination,  there will be no services can be established/run on these
> failure node/link prefix. *
>
> *It**’s the same as the beginning, as not all of the prefixes can be
> reachable within the summary address.*
>
>
>
> From my pov the only advantage of negative routes in IGP would be to very
> quickly invalidate service routes (within the IGP domain) typically carried
> by BGP.
>
>
>
> When this is accomplished the PUA can indeed time out with no harm.
>
>
>
> Said this - now considering tools like next hop tracking which can trigger
> withdraw or aggregated withdraw(*) proposal in src area I am  really
> curious how much (if anything) we would be gaining here.
>
>
>
> (*) The original proposal for this was written over 15 years ago:
> https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00  We could
> extend it with next hop which would be the same as IGP PUA prefix.
>
>
>
> Kind regards,
> Robert
>
>
>
___
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-09-07 Thread Aijun Wang
Hi, Robert:

For BGP next-hop tracking, it will help when the BGP next-hop is unreachable. 
But in our situation, the BGP next-hop is reachable, but should pass another 
ABR.

Then, in such situation, the mechanism of BGP next-hop tracking will not take 
effect?

And thanks for your draft information, maybe we can refer to it later J

 

Best Regards

 

Aijun Wang

China Telecom

 

 

From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Robert 
Raszuk
Sent: Monday, September 7, 2020 4:54 PM
To: Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
; Peter Psenak ; 
Huzhibo ; Aijun Wang ; lsr 
; Acee Lindem (acee) ; Xiaoyaqun 
; Tony Przygienda 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

Hi Aijun,

[WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for the 
hold of PUA information on the nodes) among the area.

If one node connect to the network after the disappearance of the PUA 
destination,  there will be no services can be established/run on these failure 
node/link prefix. 

It’s the same as the beginning, as not all of the prefixes can be reachable 
within the summary address.

 

>From my pov the only advantage of negative routes in IGP would be to very 
>quickly invalidate service routes (within the IGP domain) typically carried by 
>BGP. 

 

When this is accomplished the PUA can indeed time out with no harm. 

 

Said this - now considering tools like next hop tracking which can trigger 
withdraw or aggregated withdraw(*) proposal in src area I am  really curious 
how much (if anything) we would be gaining here. 

 

(*) The original proposal for this was written over 15 years ago: 
https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00  We could extend it 
with next hop which would be the same as IGP PUA prefix. 

 

Kind regards,
Robert

 

___
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-09-07 Thread Robert Raszuk
Hi Aijun,

> *[WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for
> the hold of PUA information on the nodes) among the area.*
>
> *If one node connect to the network after the disappearance of the PUA
> destination,  there will be no services can be established/run on these
> failure node/link prefix. *
>
> *It’s the same as the beginning, as not all of the prefixes can be
> reachable within the summary address.*
>
>
>From my pov the only advantage of negative routes in IGP would be to very
quickly invalidate service routes (within the IGP domain) typically carried
by BGP.

When this is accomplished the PUA can indeed time out with no harm.

Said this - now considering tools like next hop tracking which can trigger
withdraw or aggregated withdraw(*) proposal in src area I am  really
curious how much (if anything) we would be gaining here.

(*) The original proposal for this was written over 15 years ago:
https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00  We could extend
it with next hop which would be the same as IGP PUA prefix.

Kind regards,
Robert
___
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-09-06 Thread Aijun Wang
Hi, Gyan, Acee, Les, Tony:

 

Thanks for your comments on this draft. 

Although the topology in RIFT is different from ISIS/OSPF, if some thoughts can 
be referred from RIFT, it’s better.

Anyway, let’s focus the scenarios that described in this draft.

 

This draft discuss mainly the influence of summary networks in intra-area and 
inter-area situation, describes the PUA mechanisms when the failure of 
node/link that located within in the summary address occurs. The main purposes 
of PUA mechanism is to decrease the traffic black hole for the services that 
run on these failure node/link. 

 

Based on the description of section-6 
<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-6>
 ,we think the behavior of node on PUA mechanism is determined.(section 6.3 has 
also state the node within the area should all support this mechanism to avoid 
possible traffic loop). The PUA information need only keep one configurable 
time to allow the service that run on it converged, or bypass the failed 
node/link.

 

If there is any issues for the current solution, would you like to describe it 
in more detail? Based on the figure of this draft, or other figures that you 
consider may exist.

 

More detail responses are inline.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

 

From: Gyan Mishra [mailto:hayabusa...@gmail.com] 
Sent: Saturday, September 5, 2020 4:31 AM
To: Acee Lindem (acee) 
Cc: Les Ginsberg (ginsberg) ; Tony Przygienda 
; Aijun Wang ; Robert Raszuk 
; Huzhibo ; Aijun Wang 
; Peter Psenak ; 
lsr ; Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

Agreed that Rift negative  disaggregation and PUA proposed are  in no way 
comparable.   Sorry to make that analogy but unfortunately it was the first 
thing that came to mind when reading the draft.

 

I was I will work with Aijun to help fill the gaps & points noted in this 
thread  without adding more complexity.  

 

>From an operators perspective I agree backwards compatibility is requirement. 

[WAJ] Welcome Gyan to join us, and also welcome other experts.

 

 

Kind Regards

 

Gyan

 

On Fri, Sep 4, 2020 at 4:03 PM Acee Lindem (acee) mailto:a...@cisco.com> > wrote:

Speaking as WG member…. 

 

This is in no way comparable. This solution presented in the draft is full of 
holes and non-backward compatible. The problem may be solvable but the question 
is whether or not the required complexity is  worse than a problem that could 
be solved with proper network design. 

 

[WAJ]  Hi, Acee, with PUA, we just want to fill in the invisible hole that be 
covered by the summary address.  It should be supported by all the nodes within 
the area. 

And whatever the network design, the summary address will be used in the 
network, especially for the IPv6 era.

Would you like to point out in what situation that the current solution can’t 
resolve? We can refine and fix it then.

 Thanks,
Acee

 

From: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com> 
>
Date: Friday, September 4, 2020 at 3:00 PM
To: Tony Przygienda mailto:tonysi...@gmail.com> >, Aijun 
Wang mailto:wangai...@tsinghua.org.cn> >
Cc: Gyan Mishra mailto:hayabusa...@gmail.com> >, Robert 
Raszuk mailto:rob...@raszuk.net> >, Huzhibo 
mailto:huzh...@huawei.com> >, Aijun Wang 
mailto:wang...@chinatelecom.cn> >, Peter Psenak 
mailto:40cisco@dmarc.ietf.org> >, lsr 
mailto:lsr@ietf.org> >, Acee Lindem mailto:a...@cisco.com> >, Xiaoyaqun mailto:xiaoya...@huawei.com> >
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

In support of what Tony has said, I think any comparison between what RIFT is 
doing and what is proposed in this draft is inappropriate.

 

RIFT is able to determine what destinations exist in the network but are not 
reachable via a certain subset of the topology – and then generate negative 
advertisements appropriately. There is also full determinism in knowing when 
the negative advertisement should be removed.

 

draft-wang-lsr-prefix-unreachable-announcement by contrast tries to provide an 
advertisement for a destination that no longer exists. This leads to the lack 
of determinism which necessitates arbitrary timers and creates problems for 
nodes who connect to the network after the disappearance of the destination.

[WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for the 
hold of PUA information on the nodes) among the area.

If one node connect to the network after the disappearance of the PUA 
destination,  there will be no services can be established/run on these failure 
node/link prefix. 

It’s the same as the beginning, as not all of the prefixes can be reachable 
within the summary address.

 

Not comparable at all IMO…

 

   Les

 

From: Lsr mailto:lsr-boun...@iet

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

2020-09-04 Thread Gyan Mishra
Agreed that Rift negative  disaggregation and PUA proposed are  in no way
comparable.   Sorry to make that analogy but unfortunately it was the first
thing that came to mind when reading the draft.

I was I will work with Aijun to help fill the gaps & points noted in this
thread  without adding more complexity.

>From an operators perspective I agree backwards compatibility is
requirement.

Kind Regards

Gyan

On Fri, Sep 4, 2020 at 4:03 PM Acee Lindem (acee)  wrote:

> Speaking as WG member….
>
>
>
> This is in no way comparable. This solution presented in the draft is full
> of holes and non-backward compatible. The problem may be solvable but the
> question is whether or not the required complexity is  worse than a problem
> that could be solved with proper network design.
>
>
>
> Thanks,
> Acee
>
>
>
> *From: *"Les Ginsberg (ginsberg)" 
> *Date: *Friday, September 4, 2020 at 3:00 PM
> *To: *Tony Przygienda , Aijun Wang <
> wangai...@tsinghua.org.cn>
> *Cc: *Gyan Mishra , Robert Raszuk <
> rob...@raszuk.net>, Huzhibo , Aijun Wang <
> wang...@chinatelecom.cn>, Peter Psenak ,
> lsr , Acee Lindem , Xiaoyaqun <
> xiaoya...@huawei.com>
> *Subject: *RE: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> In support of what Tony has said, I think any comparison between what RIFT
> is doing and what is proposed in this draft is inappropriate.
>
>
>
> RIFT is able to determine what destinations exist in the network but are
> not reachable via a certain subset of the topology – and then generate
> negative advertisements appropriately. There is also full determinism in
> knowing when the negative advertisement should be removed.
>
>
>
> draft-wang-lsr-prefix-unreachable-announcement by contrast tries to
> provide an advertisement for a destination that no longer exists. This
> leads to the lack of determinism which necessitates arbitrary timers and
> creates problems for nodes who connect to the network after the
> disappearance of the destination.
>
>
>
> Not comparable at all IMO…
>
>
>
>Les
>
>
>
> *From:* Lsr  *On Behalf Of *Tony Przygienda
> *Sent:* Friday, September 04, 2020 11:12 AM
> *To:* Aijun Wang 
> *Cc:* Gyan Mishra ; Robert Raszuk <
> rob...@raszuk.net>; Huzhibo ; Aijun Wang <
> wang...@chinatelecom.cn>; Peter Psenak ;
> lsr ; Acee Lindem (acee) ; Xiaoyaqun <
> xiaoya...@huawei.com>
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> I read the draft since the longish thread triggered my interest. As Peter
> said very thin ice walking with magic soft-state-timers for (to me)
> entirely unclear benefit and lots of interesting questions completely
> omitted like e.g. what will happen if a mix of old and new routers are in
> the network.
>
>
>
> RIFT works completely differently BTW (and I don't think we _also_ noticed
> the problem, AFAIK RIFT is the first protocol that defined the concept of
> at least negative disaggregation to deal with black-hole avoidance in
> presence of summaries). RIFT defines precisely how negative disaggregation
> state is transitively propagated (if necessary) and next-hop resolved via
> recursive inheritance to provide black-hole and loop free routing in case
> of links failures on IP fabrics. No soft-timers or undescribed magic there.
> However, to do what RIFT is doing a sense of direction on the graph is
> needed (this is relatively easy on semi-lattice RIFT supports but would
> precondition uniform topological sorting on generic graphs, probably ending
> up in RPL type of solutions [which still need a direction indicator on arc
> to work and would take out a lot of links out of the topology possibly {but
> Pascal is better to judge that}]).
>
>
>
> -- tony
>
>
>
> On Mon, Aug 24, 2020 at 11:11 AM Aijun Wang 
> wrote:
>
> Hi, Gyan:
>
>
>
> Sorry for replying you so late.
>
> You are right about the summary address behavior, but the summary address
> is configured by manually, and if one of the specific prefix within this
> summary range is down, the black hole(route to this specific prefix) will
> be formed.  PUA mechanism just want to amend this.
>
> Glad to know Rift has also noticed such issues.  In OSPF/ISIS, such
> problem needs also be solved.
>
>
>
> If you are interested this topic, welcome to join us to the solution.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gyan
> Mishra
> *Sent:* Thur

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

2020-09-04 Thread Acee Lindem (acee)
Speaking as WG member….

This is in no way comparable. This solution presented in the draft is full of 
holes and non-backward compatible. The problem may be solvable but the question 
is whether or not the required complexity is  worse than a problem that could 
be solved with proper network design.

Thanks,
Acee

From: "Les Ginsberg (ginsberg)" 
Date: Friday, September 4, 2020 at 3:00 PM
To: Tony Przygienda , Aijun Wang 

Cc: Gyan Mishra , Robert Raszuk , 
Huzhibo , Aijun Wang , Peter 
Psenak , lsr , Acee Lindem 
, Xiaoyaqun 
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

In support of what Tony has said, I think any comparison between what RIFT is 
doing and what is proposed in this draft is inappropriate.

RIFT is able to determine what destinations exist in the network but are not 
reachable via a certain subset of the topology – and then generate negative 
advertisements appropriately. There is also full determinism in knowing when 
the negative advertisement should be removed.

draft-wang-lsr-prefix-unreachable-announcement by contrast tries to provide an 
advertisement for a destination that no longer exists. This leads to the lack 
of determinism which necessitates arbitrary timers and creates problems for 
nodes who connect to the network after the disappearance of the destination.

Not comparable at all IMO…

   Les

From: Lsr  On Behalf Of Tony Przygienda
Sent: Friday, September 04, 2020 11:12 AM
To: Aijun Wang 
Cc: Gyan Mishra ; Robert Raszuk ; 
Huzhibo ; Aijun Wang ; Peter 
Psenak ; lsr ; Acee Lindem 
(acee) ; Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

I read the draft since the longish thread triggered my interest. As Peter said 
very thin ice walking with magic soft-state-timers for (to me) entirely unclear 
benefit and lots of interesting questions completely omitted like e.g. what 
will happen if a mix of old and new routers are in the network.

RIFT works completely differently BTW (and I don't think we _also_ noticed the 
problem, AFAIK RIFT is the first protocol that defined the concept of at least 
negative disaggregation to deal with black-hole avoidance in presence of 
summaries). RIFT defines precisely how negative disaggregation state is 
transitively propagated (if necessary) and next-hop resolved via recursive 
inheritance to provide black-hole and loop free routing in case of links 
failures on IP fabrics. No soft-timers or undescribed magic there. However, to 
do what RIFT is doing a sense of direction on the graph is needed (this is 
relatively easy on semi-lattice RIFT supports but would precondition uniform 
topological sorting on generic graphs, probably ending up in RPL type of 
solutions [which still need a direction indicator on arc to work and would take 
out a lot of links out of the topology possibly {but Pascal is better to judge 
that}]).

-- tony

On Mon, Aug 24, 2020 at 11:11 AM Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:
Hi, Gyan:

Sorry for replying you so late.
You are right about the summary address behavior, but the summary address is 
configured by manually, and if one of the specific prefix within this summary 
range is down, the black hole(route to this specific prefix) will be formed.  
PUA mechanism just want to amend this.
Glad to know Rift has also noticed such issues.  In OSPF/ISIS, such problem 
needs also be solved.

If you are interested this topic, welcome to join us to the solution.


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
[mailto:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>] On Behalf Of Gyan 
Mishra
Sent: Thursday, August 6, 2020 4:44 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Peter Psenak 
mailto:40cisco@dmarc.ietf.org>>; Robert 
Raszuk mailto:rob...@raszuk.net>>; Huzhibo 
mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Xiaoyaqun 
mailto:xiaoya...@huawei.com>>
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi Aijun and authors

I am catching up with this thread after reading through this draft.

I understand the concept that we are trying to send a PUA advertisement which 
sounds similar to Rift Negative Disaggregation prefix now with a  null setting 
when a longer match component prefix that is part of a summary range is down to 
detect prefix down conditions with longer match component prefixes that are 
part of a summary.

Basically how summarization works with both OSPF and ISIS is that at minimum a 
single longer match within the defined IA summary range must exist for the IA 
summary to be sent.  So the summary is sent conditionally similar to a BGP 
conditional advertisement or even a

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

2020-09-04 Thread Les Ginsberg (ginsberg)
In support of what Tony has said, I think any comparison between what RIFT is 
doing and what is proposed in this draft is inappropriate.

RIFT is able to determine what destinations exist in the network but are not 
reachable via a certain subset of the topology – and then generate negative 
advertisements appropriately. There is also full determinism in knowing when 
the negative advertisement should be removed.

draft-wang-lsr-prefix-unreachable-announcement by contrast tries to provide an 
advertisement for a destination that no longer exists. This leads to the lack 
of determinism which necessitates arbitrary timers and creates problems for 
nodes who connect to the network after the disappearance of the destination.

Not comparable at all IMO…

   Les

From: Lsr  On Behalf Of Tony Przygienda
Sent: Friday, September 04, 2020 11:12 AM
To: Aijun Wang 
Cc: Gyan Mishra ; Robert Raszuk ; 
Huzhibo ; Aijun Wang ; Peter 
Psenak ; lsr ; Acee Lindem 
(acee) ; Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

I read the draft since the longish thread triggered my interest. As Peter said 
very thin ice walking with magic soft-state-timers for (to me) entirely unclear 
benefit and lots of interesting questions completely omitted like e.g. what 
will happen if a mix of old and new routers are in the network.

RIFT works completely differently BTW (and I don't think we _also_ noticed the 
problem, AFAIK RIFT is the first protocol that defined the concept of at least 
negative disaggregation to deal with black-hole avoidance in presence of 
summaries). RIFT defines precisely how negative disaggregation state is 
transitively propagated (if necessary) and next-hop resolved via recursive 
inheritance to provide black-hole and loop free routing in case of links 
failures on IP fabrics. No soft-timers or undescribed magic there. However, to 
do what RIFT is doing a sense of direction on the graph is needed (this is 
relatively easy on semi-lattice RIFT supports but would precondition uniform 
topological sorting on generic graphs, probably ending up in RPL type of 
solutions [which still need a direction indicator on arc to work and would take 
out a lot of links out of the topology possibly {but Pascal is better to judge 
that}]).

-- tony

On Mon, Aug 24, 2020 at 11:11 AM Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:
Hi, Gyan:

Sorry for replying you so late.
You are right about the summary address behavior, but the summary address is 
configured by manually, and if one of the specific prefix within this summary 
range is down, the black hole(route to this specific prefix) will be formed.  
PUA mechanism just want to amend this.
Glad to know Rift has also noticed such issues.  In OSPF/ISIS, such problem 
needs also be solved.

If you are interested this topic, welcome to join us to the solution.


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
[mailto:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>] On Behalf Of Gyan 
Mishra
Sent: Thursday, August 6, 2020 4:44 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Peter Psenak 
mailto:40cisco@dmarc.ietf.org>>; Robert 
Raszuk mailto:rob...@raszuk.net>>; Huzhibo 
mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Xiaoyaqun 
mailto:xiaoya...@huawei.com>>
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi Aijun and authors

I am catching up with this thread after reading through this draft.

I understand the concept that we are trying to send a PUA advertisement which 
sounds similar to Rift Negative Disaggregation prefix now with a  null setting 
when a longer match component prefix that is part of a summary range is down to 
detect prefix down conditions with longer match component prefixes that are 
part of a summary.

Basically how summarization works with both OSPF and ISIS is that at minimum a 
single longer match within the defined IA summary range must exist for the IA 
summary to be sent.  So the summary is sent conditionally similar to a BGP 
conditional advertisement or even a ospf default originate which requires a 
default in the RIB to exist before the advertisement is sent.  A good example 
of non conditional analogy with BGP if you have a null0 static for a summary 
for an exact match BGP advertisement the prefix is always advertised no matter 
what even if no component prefixes exist.  This can result in black hole 
routing. BGP has conditional feature to conditionally advertisement based on 
existence of a route advertisement of downstream neighbor in the BGP RIB.  So 
with ospf and Isis the summary is in fact conditional similar to a BGP 
conditional advertisement and in the example given in the draft in secti

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

2020-09-04 Thread Tony Przygienda
I read the draft since the longish thread triggered my interest. As Peter
said very thin ice walking with magic soft-state-timers for (to me)
entirely unclear benefit and lots of interesting questions completely
omitted like e.g. what will happen if a mix of old and new routers are in
the network.

RIFT works completely differently BTW (and I don't think we _also_ noticed
the problem, AFAIK RIFT is the first protocol that defined the concept of
at least negative disaggregation to deal with black-hole avoidance in
presence of summaries). RIFT defines precisely how negative disaggregation
state is transitively propagated (if necessary) and next-hop resolved via
recursive inheritance to provide black-hole and loop free routing in case
of links failures on IP fabrics. No soft-timers or undescribed magic there.
However, to do what RIFT is doing a sense of direction on the graph is
needed (this is relatively easy on semi-lattice RIFT supports but would
precondition uniform topological sorting on generic graphs, probably ending
up in RPL type of solutions [which still need a direction indicator on arc
to work and would take out a lot of links out of the topology possibly {but
Pascal is better to judge that}]).

-- tony

On Mon, Aug 24, 2020 at 11:11 AM Aijun Wang 
wrote:

> Hi, Gyan:
>
>
>
> Sorry for replying you so late.
>
> You are right about the summary address behavior, but the summary address
> is configured by manually, and if one of the specific prefix within this
> summary range is down, the black hole(route to this specific prefix) will
> be formed.  PUA mechanism just want to amend this.
>
> Glad to know Rift has also noticed such issues.  In OSPF/ISIS, such
> problem needs also be solved.
>
>
>
> If you are interested this topic, welcome to join us to the solution.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gyan
> Mishra
> *Sent:* Thursday, August 6, 2020 4:44 PM
> *To:* Aijun Wang 
> *Cc:* Peter Psenak ; Robert Raszuk <
> rob...@raszuk.net>; Huzhibo ; Aijun Wang <
> wang...@chinatelecom.cn>; lsr ; Acee Lindem (acee) <
> a...@cisco.com>; Xiaoyaqun 
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hi Aijun and authors
>
>
>
> I am catching up with this thread after reading through this draft.
>
>
>
> I understand the concept that we are trying to send a PUA advertisement
> which sounds similar to Rift Negative Disaggregation prefix now with a
>  null setting when a longer match component prefix that is part of a
> summary range is down to detect prefix down conditions with longer match
> component prefixes that are part of a summary.
>
>
>
> Basically how summarization works with both OSPF and ISIS is that at
> minimum a single longer match within the defined IA summary range must
> exist for the IA summary to be sent.  So the summary is sent conditionally
> similar to a BGP conditional advertisement or even a ospf default originate
> which requires a default in the RIB to exist before the advertisement is
> sent.  A good example of non conditional analogy with BGP if you have a
> null0 static for a summary for an exact match BGP advertisement the prefix
> is always advertised no matter what even if no component prefixes exist.
> This can result in black hole routing. BGP has conditional feature to
> conditionally advertisement based on existence of a route advertisement of
> downstream neighbor in the BGP RIB.  So with ospf and Isis the summary is
> in fact conditional similar to a BGP conditional advertisement and in the
> example given in the draft in section 3.1 when node T2 is down and pt2
> becomes unreachable and let’s say that prefix is 1.1.1.1/32 and the
> summary is 1.1.1.0/30 and no other component prefix exists within the
> summary range the prefix will not get adversed.  So there will not be any
> black hole.
>
>
>
> The summary represents all prefixes within the range that would be
> suppressed with the summary when advertised into the backbone area.
> However only at a minimum one prefix must exist in the range for the
> summary to be generated.  That is done by design as the summary represents
> all prefixes within the range.  So let’s say there are a 100 prefixes and
> let’s say a few devices are down and so now only 5 prefixes exist within
> the range.  By design it is OK for router to generate the summary for the 5
> prefixes it is representing and that will not cause any routing loop or
> black hole.
>
>
>
>
>
> I am trying to understand wage gap exists and what we are trying to solve
> related to summa

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

2020-09-04 Thread Gyan Mishra
Hi Aijun

Sure  I would be interested in joining as co-author of the draft.

This an interesting topic as how PUA or negative disaggretion can prevent
black hole routing of summaries when “Longest prefix match” does not exist
due to link or router down event, and how to signal via negative
advertisement PUA to suppress summary advertisement when components
prefixes are not in the rib.

Let me read through the thread and help provide some comments to assist in
progressing the draft.

Thanks

Gyan


On Mon, Aug 24, 2020 at 5:12 AM Aijun Wang 
wrote:

> Hi, Gyan:
>
>
>
> Sorry for replying you so late.
>
> You are right about the summary address behavior, but the summary address
> is configured by manually, and if one of the specific prefix within this
> summary range is down, the black hole(route to this specific prefix) will
> be formed.  PUA mechanism just want to amend this.
>
> Glad to know Rift has also noticed such issues.  In OSPF/ISIS, such
> problem needs also be solved.
>
>
>
> If you are interested this topic, welcome to join us to the solution.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gyan
> Mishra
>
>
> *Sent:* Thursday, August 6, 2020 4:44 PM
> *To:* Aijun Wang 
> *Cc:* Peter Psenak ; Robert Raszuk <
> rob...@raszuk.net>; Huzhibo ; Aijun Wang <
> wang...@chinatelecom.cn>; lsr ; Acee Lindem (acee) <
> a...@cisco.com>; Xiaoyaqun 
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hi Aijun and authors
>
>
>
> I am catching up with this thread after reading through this draft.
>
>
>
> I understand the concept that we are trying to send a PUA advertisement
> which sounds similar to Rift Negative Disaggregation prefix now with a
>  null setting when a longer match component prefix that is part of a
> summary range is down to detect prefix down conditions with longer match
> component prefixes that are part of a summary.
>
>
>
> Basically how summarization works with both OSPF and ISIS is that at
> minimum a single longer match within the defined IA summary range must
> exist for the IA summary to be sent.  So the summary is sent conditionally
> similar to a BGP conditional advertisement or even a ospf default originate
> which requires a default in the RIB to exist before the advertisement is
> sent.  A good example of non conditional analogy with BGP if you have a
> null0 static for a summary for an exact match BGP advertisement the prefix
> is always advertised no matter what even if no component prefixes exist.
> This can result in black hole routing. BGP has conditional feature to
> conditionally advertisement based on existence of a route advertisement of
> downstream neighbor in the BGP RIB.  So with ospf and Isis the summary is
> in fact conditional similar to a BGP conditional advertisement and in the
> example given in the draft in section 3.1 when node T2 is down and pt2
> becomes unreachable and let’s say that prefix is 1.1.1.1/32 and the
> summary is 1.1.1.0/30 and no other component prefix exists within the
> summary range the prefix will not get adversed.  So there will not be any
> black hole.
>
>
>
> The summary represents all prefixes within the range that would be
> suppressed with the summary when advertised into the backbone area.
> However only at a minimum one prefix must exist in the range for the
> summary to be generated.  That is done by design as the summary represents
> all prefixes within the range.  So let’s say there are a 100 prefixes and
> let’s say a few devices are down and so now only 5 prefixes exist within
> the range.  By design it is OK for router to generate the summary for the 5
> prefixes it is representing and that will not cause any routing loop or
> black hole.
>
>
>
>
>
> I am trying to understand wage gap exists and what we are trying to solve
> related to summarization in the context of IPv6.  Both IPv4 and IPV6
> summarization operates the similarly as far as the requirement of at
> minimum a single component route within the summary range must exist  as a
> condition to be present in the RIB before the summary can be advertised.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Tue, Aug 4, 2020 at 11:25 PM Aijun Wang 
> wrote:
>
> Hi, Robert:
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of 
> *Robert
> Raszuk
> *Sent:* Friday, July 31, 2020 6:21 PM
> *To:* Aijun Wang 
> *Cc:* Peter Psenak ; Huzhibo <
> huzh...@huawei.com>; Aijun Wang ; lsr <
> l

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

2020-08-24 Thread Aijun Wang
Hi, Gyan:

 

Sorry for replying you so late.

You are right about the summary address behavior, but the summary address is 
configured by manually, and if one of the specific prefix within this summary 
range is down, the black hole(route to this specific prefix) will be formed.  
PUA mechanism just want to amend this.

Glad to know Rift has also noticed such issues.  In OSPF/ISIS, such problem 
needs also be solved.

 

If you are interested this topic, welcome to join us to the solution.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Gyan 
Mishra
Sent: Thursday, August 6, 2020 4:44 PM
To: Aijun Wang 
Cc: Peter Psenak ; Robert Raszuk 
; Huzhibo ; Aijun Wang 
; lsr ; Acee Lindem (acee) 
; Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

Hi Aijun and authors

 

I am catching up with this thread after reading through this draft.

 

I understand the concept that we are trying to send a PUA advertisement which 
sounds similar to Rift Negative Disaggregation prefix now with a  null setting 
when a longer match component prefix that is part of a summary range is down to 
detect prefix down conditions with longer match component prefixes that are 
part of a summary.  

 

Basically how summarization works with both OSPF and ISIS is that at minimum a 
single longer match within the defined IA summary range must exist for the IA 
summary to be sent.  So the summary is sent conditionally similar to a BGP 
conditional advertisement or even a ospf default originate which requires a 
default in the RIB to exist before the advertisement is sent.  A good example 
of non conditional analogy with BGP if you have a null0 static for a summary 
for an exact match BGP advertisement the prefix is always advertised no matter 
what even if no component prefixes exist.  This can result in black hole 
routing. BGP has conditional feature to conditionally advertisement based on 
existence of a route advertisement of downstream neighbor in the BGP RIB.  So 
with ospf and Isis the summary is in fact conditional similar to a BGP 
conditional advertisement and in the example given in the draft in section 3.1 
when node T2 is down and pt2 becomes unreachable and let’s say that prefix is 
1.1.1.1/32 <http://1.1.1.1/32>  and the summary is 1.1.1.0/30 
<http://1.1.1.0/30>  and no other component prefix exists within the summary 
range the prefix will not get adversed.  So there will not be any black hole.  

 

The summary represents all prefixes within the range that would be suppressed 
with the summary when advertised into the backbone area.  However only at a 
minimum one prefix must exist in the range for the summary to be generated.  
That is done by design as the summary represents all prefixes within the range. 
 So let’s say there are a 100 prefixes and let’s say a few devices are down and 
so now only 5 prefixes exist within the range.  By design it is OK for router 
to generate the summary for the 5 prefixes it is representing and that will not 
cause any routing loop or black hole.

 

 

I am trying to understand wage gap exists and what we are trying to solve 
related to summarization in the context of IPv6.  Both IPv4 and IPV6 
summarization operates the similarly as far as the requirement of at minimum a 
single component route within the summary range must exist  as a condition to 
be present in the RIB before the summary can be advertised.

 

Kind Regards 

 

Gyan

 

On Tue, Aug 4, 2020 at 11:25 PM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Robert:

 

From: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>  
[mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> ] On Behalf Of 
Robert Raszuk
Sent: Friday, July 31, 2020 6:21 PM
To: Aijun Wang mailto:wang...@chinatelecom.cn> >
Cc: Peter Psenak mailto:40cisco@dmarc.ietf.org> >; Huzhibo mailto:huzh...@huawei.com> >; Aijun Wang mailto:wangai...@tsinghua.org.cn> >; lsr mailto:lsr@ietf.org> 
>; Acee Lindem (acee) mailto:a...@cisco.com> >; Xiaoyaqun 
mailto:xiaoya...@huawei.com> >
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

[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?

 

Well if we look at this problem from a distance while on surface it seems like 
an IGP issue (not to mention some which use BGP as IGP :) IMO it is only 
hurting when you have some service overlay on top utilizing the IGP. 

[WAJ] There are situations that the PUA mechanism apply when no service overlay 
running over IGP.  Scenarios described in  
<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-3>
 draft-wang-lsr-prefix-unreachable-anno

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

2020-08-06 Thread Gyan Mishra
Hi Aijun and authors

I am catching up with this thread after reading through this draft.

I understand the concept that we are trying to send a PUA advertisement
which sounds similar to Rift Negative Disaggregation prefix now with a
 null setting when a longer match component prefix that is part of a
summary range is down to detect prefix down conditions with longer match
component prefixes that are part of a summary.

Basically how summarization works with both OSPF and ISIS is that at
minimum a single longer match within the defined IA summary range must
exist for the IA summary to be sent.  So the summary is sent conditionally
similar to a BGP conditional advertisement or even a ospf default originate
which requires a default in the RIB to exist before the advertisement is
sent.  A good example of non conditional analogy with BGP if you have a
null0 static for a summary for an exact match BGP advertisement the prefix
is always advertised no matter what even if no component prefixes exist.
This can result in black hole routing. BGP has conditional feature to
conditionally advertisement based on existence of a route advertisement of
downstream neighbor in the BGP RIB.  So with ospf and Isis the summary is
in fact conditional similar to a BGP conditional advertisement and in the
example given in the draft in section 3.1 when node T2 is down and pt2
becomes unreachable and let’s say that prefix is 1.1.1.1/32 and the summary
is 1.1.1.0/30 and no other component prefix exists within the summary range
the prefix will not get adversed.  So there will not be any black hole.

The summary represents all prefixes within the range that would be
suppressed with the summary when advertised into the backbone area.
However only at a minimum one prefix must exist in the range for the
summary to be generated.  That is done by design as the summary represents
all prefixes within the range.  So let’s say there are a 100 prefixes and
let’s say a few devices are down and so now only 5 prefixes exist within
the range.  By design it is OK for router to generate the summary for the 5
prefixes it is representing and that will not cause any routing loop or
black hole.


I am trying to understand wage gap exists and what we are trying to solve
related to summarization in the context of IPv6.  Both IPv4 and IPV6
summarization operates the similarly as far as the requirement of at
minimum a single component route within the summary range must exist  as a
condition to be present in the RIB before the summary can be advertised.

Kind Regards

Gyan

On Tue, Aug 4, 2020 at 11:25 PM Aijun Wang 
wrote:

> Hi, Robert:
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of 
> *Robert
> Raszuk
> *Sent:* Friday, July 31, 2020 6:21 PM
> *To:* Aijun Wang 
> *Cc:* Peter Psenak ; Huzhibo <
> huzh...@huawei.com>; Aijun Wang ; lsr <
> lsr@ietf.org>; Acee Lindem (acee) ; Xiaoyaqun <
> xiaoya...@huawei.com>
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> [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?
>
>
>
> Well if we look at this problem from a distance while on surface it seems
> like an IGP issue (not to mention some which use BGP as IGP :) IMO it is
> only hurting when you have some service overlay on top utilizing the IGP.
>
> *[WAJ] There are situations that the PUA mechanism apply when no service
> overlay running over IGP.  Scenarios described in
> draft-wang-lsr-prefix-unreachable-annoucement-03#section-3
> <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-3>
> are not tightly coupled with the overlay service.*
>
>
>
> So typically today if I am running any service with BGP I do count on BGP
> to remove routes which are no longer reachable. IGP just tells me how to
> get to the next hop, which direction to go and not if the endpoint (service
> CPE or PE connected to given CE) is up or down.
>
>
>
> So today smart BGP implementations in good network design can use RD based
> withdraws to very fast (milliseconds) remove the affected service routes.
> When I said should we do it in BGP I meant to ask WG if this is good enough
> to quickly remove service routes. If not maybe we should send such affected
> next hop in BGP to even faster invalidate all routes with such next hop as
> failing PE.
>
>
>
> Bottom line if you think the problem is IGP then I think Acee's comments
> apply.
>
> *[WAJ] Which comment is not addressed yet?*
>
>
>
> Last - See today you are bringing the case to signal transition to DOWN
> ... but for some people and applications it may be not enough. In fact
&g

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

2020-08-04 Thread Aijun Wang
Hi, Robert:

 

From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Robert 
Raszuk
Sent: Friday, July 31, 2020 6:21 PM
To: Aijun Wang 
Cc: Peter Psenak ; Huzhibo 
; Aijun Wang ; lsr 
; Acee Lindem (acee) ; Xiaoyaqun 

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

 

[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?

 

Well if we look at this problem from a distance while on surface it seems like 
an IGP issue (not to mention some which use BGP as IGP :) IMO it is only 
hurting when you have some service overlay on top utilizing the IGP. 

[WAJ] There are situations that the PUA mechanism apply when no service overlay 
running over IGP.  Scenarios described in  
<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-3>
 draft-wang-lsr-prefix-unreachable-annoucement-03#section-3 are not tightly 
coupled with the overlay service.

 

So typically today if I am running any service with BGP I do count on BGP to 
remove routes which are no longer reachable. IGP just tells me how to get to 
the next hop, which direction to go and not if the endpoint (service CPE or PE 
connected to given CE) is up or down. 

 

So today smart BGP implementations in good network design can use RD based 
withdraws to very fast (milliseconds) remove the affected service routes. When 
I said should we do it in BGP I meant to ask WG if this is good enough to 
quickly remove service routes. If not maybe we should send such affected next 
hop in BGP to even faster invalidate all routes with such next hop as failing 
PE. 

 

Bottom line if you think the problem is IGP then I think Acee's comments apply. 

[WAJ] Which comment is not addressed yet?

 

Last - See today you are bringing the case to signal transition to DOWN  
but for some people and applications it may be not enough. In fact UP/DOWN they 
can get via BGP. But if you have two ABRs and one will due to topology changes 
in its area suddenly will be forced to reach atomic destination covered by 
summary over much higher metric path that for applications running above may be 
much more severe case and not acceptable one too. 

[WAJ] Or else, the application traffic will be broken.

 

And BGP will not remove service routes nor modify best path in any way as 
summary is masking the real metric to some next hops. So while in the network 
you may have alternate better native transit paths with a lot of free capacity 
if you only switch to a different bgp next hop (not talking about any TE at 
all) you are stuck offering much worse service to your customers. 

[WAJ] if there are other links to reach the affected prefix via the ABR, then 
this ABR will not send the PUA information.

 

Those cases are starting to be solved by performance routing both at the 
service itself or at BGP nh levels. Should IGP assist here ... I am not sure.

[WAJ] when node become down, it can only depend on other nodes within the same 
IGP to send such unreachability information. IGP can certainly help here J

 

 

Many 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-31 Thread Robert Raszuk
>
> [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?
>

Well if we look at this problem from a distance while on surface it seems
like an IGP issue (not to mention some which use BGP as IGP :) IMO it is
only hurting when you have some service overlay on top utilizing the IGP.

So typically today if I am running any service with BGP I do count on BGP
to remove routes which are no longer reachable. IGP just tells me how to
get to the next hop, which direction to go and not if the endpoint (service
CPE or PE connected to given CE) is up or down.

So today smart BGP implementations in good network design can use RD based
withdraws to very fast (milliseconds) remove the affected service routes.
When I said should we do it in BGP I meant to ask WG if this is good enough
to quickly remove service routes. If not maybe we should send such affected
next hop in BGP to even faster invalidate all routes with such next hop as
failing PE.

Bottom line if you think the problem is IGP then I think Acee's comments
apply.

Last - See today you are bringing the case to signal transition to DOWN ...
but for some people and applications it may be not enough. In fact UP/DOWN
they can get via BGP. But if you have two ABRs and one will due to topology
changes in its area suddenly will be forced to reach atomic destination
covered by summary over much higher metric path that for applications
running above may be much more severe case and not acceptable one too.

And BGP will not remove service routes nor modify best path in any way as
summary is masking the real metric to some next hops. So while in the
network you may have alternate better native transit paths with a lot of
free capacity if you only switch to a different bgp next hop (not talking
about any TE at all) you are stuck offering much worse service to your
customers.

Those cases are starting to be solved by performance routing both at the
service itself or at BGP nh levels. Should IGP assist here ... I am not
sure.

Many 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 Aijun Wang
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

2020-07-30 Thread Aijun Wang
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

2020-07-30 Thread Acee Lindem (acee)

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

2020-07-30 Thread Acee Lindem (acee)


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

2020-07-30 Thread Acee Lindem (acee)
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

2020-07-30 Thread Huzhibo
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

2020-07-30 Thread Peter Psenak

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

2020-07-30 Thread Huzhibo
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

2020-07-30 Thread Acee Lindem (acee)
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

2020-07-30 Thread Peter Psenak

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

2020-07-30 Thread Peter Psenak

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

2020-07-30 Thread Huzhibo
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

2020-07-30 Thread Peter Psenak

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 of this PUA(Pre

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

2020-07-30 Thread Huzhibo
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 connected areas
>>&

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

2020-07-30 Thread Peter Psenak
sage-
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

2020-07-30 Thread Huzhibo
;> 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

2020-07-30 Thread Peter Psenak

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:   
http

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

2020-07-30 Thread Aijun Wang
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

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

2020-07-30 Thread Peter Psenak

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
h

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

2020-07-30 Thread Aijun Wang
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

2020-07-30 Thread Peter Psenak

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

2020-07-29 Thread Robert Raszuk
Not sure I follow your below comment or how it relates to my
deployment scenario ... I specifically said that 1.1.1.1/32 will be a
negative route (there is "-" minus there) advertised in BGP.

If you mean that reception of negative routes in the presence of summary
requires changes to RIB route tracking (or local RIB twist) it sure does.

Thx,
R.

On Wed, Jul 29, 2020 at 10:07 AM Huzhibo  wrote:

> Hi Robert:
>
>
>
> BGP next hop validation can solve some but not all problems. In your
> example, if PE1 has learned only 1.1.1.0/24 but not 1.1.1.1/32, BGP
> cannot detect the reachability of 1.1.1.1/32.
>
>
>
> Thanks
>
>
>
> Zhibo Hu
>
> *From:* Robert Raszuk [mailto:rob...@raszuk.net]
> *Sent:* Tuesday, July 28, 2020 5:18 PM
> *To:* Acee Lindem (acee) 
> *Cc:* Aijun Wang ; lsr@ietf.org; Huzhibo <
> huzh...@huawei.com>; Xiaoyaqun 
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hello Acee,
>
>
>
> I would like to question your assessment that signalling unreachable
> routes is unnecessary.
>
>
>
> Imagine hierarchical network with areas. Under no failures area 1
> advertises to area 0 summary LSA with 1.1.1.0/24. That block covers PE's
> loopbacks which within the area are /32s. Those loopbacks are also BGP next
> hops.
>
>
>
> Now imagine PE1 with 1.1.1.1/32 fails. Well till BGP reconverges all
> paths advertised by this PE with 1.1.1.1/32 are still valid as this next
> hop is still reachable entire network wide. That means that traffic is
> being sent to this failed PE1 for relatively long period of time.
>
>
>
> It seems natural that without breaking benefits of summarization across
> areas or domains in the above scenario we could continue to advertise
> 1.1.1.0/24 - 1.1.1.1/32. That is when I see most benefits of advertising
> unreachability aka negative routing.
>
>
>
> Of course said all of the above - if you search your employer's archives -
> you will see a proposal where the above mechanism can be done within BGP
> itself with no touch to the IGP - just using a bit of twisted next hop
> validation steps and BGP native recursion. I am not going to make any
> judgements here which method is better or easier - naturally I personally
> like BGP one more :).
>
>
>
> But I hope this is clear why at least discussion on the subject is
> important. It also illustrates why the below statement is not
> necessarily correct:
>
>
>
> "Note that the unreachability of a given summarized prefix is only
> relevant if it is reachable through another ABR. "
>
>
>
> Kind regards,
> Robert.
>
>
>
>
>
> On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
>
> Speaking as an LSR Working Group member:
>
> Asking the WG precisely how to advertise prefix unreachability is the
> wrong question - it is analogous to asking whether to use a car or truck to
> drive off the edge of a cliff. Rather than messing up OSPF and IS-IS with
> these complex and unnecessary mechanisms, it would be better to address the
> requirement in your network design. Note that the unreachability of a given
> summarized prefix is only relevant if it is reachable through another ABR..
> In this case, the network design should provide adequate intra-area
> redundancy to provide communications between the ABRs. If this cannot be
> accomplished, an intra-area adjacency should be established over a tunnel
> between the ABRs in the backbone. Contrary to section 6.1, Looping is
> normally not a problem as ABRs should add back hole routes for their
> advertised summaries.
>
> Acee
>
> On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang"  on behalf of wang...@chinatelecom.cn> 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
>
>  

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

2020-07-29 Thread Aijun Wang
Hi, Robert:

 

Agree with you J

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: rob...@raszuk.net [mailto:rob...@raszuk.net] 
Sent: Tuesday, July 28, 2020 5:18 PM
To: Acee Lindem (acee) 
Cc: Aijun Wang ; lsr@ietf.org; Zhibo Hu 
; Yaqun Xiao 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

Hello Acee,

 

I would like to question your assessment that signalling unreachable routes is 
unnecessary. 

 

Imagine hierarchical network with areas. Under no failures area 1 advertises to 
area 0 summary LSA with 1.1.1.0/24 <http://1.1.1.0/24> . That block covers PE's 
loopbacks which within the area are /32s. Those loopbacks are also BGP next 
hops. 

 

Now imagine PE1 with 1.1.1.1/32 <http://1.1.1.1/32>  fails. Well till BGP 
reconverges all paths advertised by this PE with 1.1.1.1/32 <http://1.1.1.1/32> 
 are still valid as this next hop is still reachable entire network wide. That 
means that traffic is being sent to this failed PE1 for relatively long period 
of time. 

 

It seems natural that without breaking benefits of summarization across areas 
or domains in the above scenario we could continue to advertise 1.1.1.0/24 
<http://1.1.1.0/24>  - 1.1.1.1/32 <http://1.1.1.1/32> . That is when I see most 
benefits of advertising unreachability aka negative routing. 

 

Of course said all of the above - if you search your employer's archives - you 
will see a proposal where the above mechanism can be done within BGP itself 
with no touch to the IGP - just using a bit of twisted next hop validation 
steps and BGP native recursion. I am not going to make any judgements here 
which method is better or easier - naturally I personally like BGP one more :). 

 

But I hope this is clear why at least discussion on the subject is important. 
It also illustrates why the below statement is not necessarily correct: 

 

"Note that the unreachability of a given summarized prefix is only relevant if 
it is reachable through another ABR. " 

 

Kind regards,
Robert.

 

 

On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org> > wrote:

Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex 
and unnecessary mechanisms, it would be better to address the requirement in 
your network design. Note that the unreachability of a given summarized prefix 
is only relevant if it is reachable through another ABR. In this case, the 
network design should provide adequate intra-area redundancy to provide 
communications between the ABRs. If this cannot be accomplished, an intra-area 
adjacency should be established over a tunnel between the ABRs in the backbone. 
Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries. 

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" mailto:lsr-boun...@ietf.org>  on behalf of wang...@chinatelecom.cn 
<mailto:wang...@chinatelecom.cn> > 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>  
[mailto:internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> ] 
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu mailto:huzh...@huawei.com> >; Aijun Wang 
mailto:wang...@chinatelecom.cn> >; Yaqun Xiao 
mailto:xiaoya...@huawei.com> >
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:  Indi

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

2020-07-29 Thread Aijun Wang
Interesting but complex/not efficient solution.  How to solve the problem in 
IPv6 network?

 

From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com] 
Sent: Tuesday, July 28, 2020 10:18 PM
To: Acee Lindem (acee) ; Robert Raszuk 
Cc: Aijun Wang ; Zhibo Hu ; Yaqun 
Xiao ; lsr@ietf.org
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

 

 

From: Acee Lindem (acee) [mailto:a...@cisco.com] 



 

An interesting encoding – note that the draft doesn’t use it for forwarding. 

[Bruno] Agreed that the distinction between routing and reachability 
information is a key point.

--Bruno

Acee

 

From: Bruno Decraene mailto:bruno.decra...@orange.com> >
Date: Tuesday, July 28, 2020 at 5:51 AM
To: Robert Raszuk mailto:rob...@raszuk.net> >, Acee Lindem 
mailto:a...@cisco.com> >
Cc: Aijun Wang mailto:wang...@chinatelecom.cn> >, 
Zhibo Hu mailto:huzh...@huawei.com> >, Yaqun Xiao 
mailto:xiaoya...@huawei.com> >, "lsr@ietf.org 
<mailto:lsr@ietf.org> " mailto:lsr@ietf.org> >
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

Another data point about advertising more detailed reachability/unreachability: 
https://tools.ietf.org/html/draft-swallow-isis-detailed-reach-01

 

(for IPv6 some form of compression may be beneficial).

 

--Bruno

 

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Tuesday, July 28, 2020 11:18 AM
To: Acee Lindem (acee) mailto:acee=40cisco@dmarc.ietf.org> >
Cc: Aijun Wang mailto:wang...@chinatelecom.cn> >; 
Zhibo Hu mailto:huzh...@huawei.com> >; Yaqun Xiao 
mailto:xiaoya...@huawei.com> >; lsr@ietf.org 
<mailto:lsr@ietf.org> 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

Hello Acee,

 

I would like to question your assessment that signalling unreachable routes is 
unnecessary. 

 

Imagine hierarchical network with areas. Under no failures area 1 advertises to 
area 0 summary LSA with  <http://1.1.1.0/24> 1.1.1.0/24. That block covers PE's 
loopbacks which within the area are /32s. Those loopbacks are also BGP next 
hops. 

 

Now imagine PE1 with  <http://1.1.1.1/32> 1.1.1.1/32 fails. Well till BGP 
reconverges all paths advertised by this PE with  <http://1.1.1.1/32> 
1.1.1.1/32 are still valid as this next hop is still reachable entire network 
wide. That means that traffic is being sent to this failed PE1 for relatively 
long period of time. 

 

It seems natural that without breaking benefits of summarization across areas 
or domains in the above scenario we could continue to advertise  
<http://1.1.1.0/24> 1.1.1.0/24 -  <http://1.1.1.1/32> 1.1.1.1/32. That is when 
I see most benefits of advertising unreachability aka negative routing. 

 

Of course said all of the above - if you search your employer's archives - you 
will see a proposal where the above mechanism can be done within BGP itself 
with no touch to the IGP - just using a bit of twisted next hop validation 
steps and BGP native recursion. I am not going to make any judgements here 
which method is better or easier - naturally I personally like BGP one more :). 

 

But I hope this is clear why at least discussion on the subject is important. 
It also illustrates why the below statement is not necessarily correct: 

 

"Note that the unreachability of a given summarized prefix is only relevant if 
it is reachable through another ABR. " 

 

Kind regards,
Robert.

 

 

On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee) mailto:40cisco@dmarc.ietf.org> 40cisco@dmarc.ietf.org> wrote:

Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex 
and unnecessary mechanisms, it would be better to address the requirement in 
your network design. Note that the unreachability of a given summarized prefix 
is only relevant if it is reachable through another ABR. In this case, the 
network design should provide adequate intra-area redundancy to provide 
communications between the ABRs. If this cannot be accomplished, an intra-area 
adjacency should be established over a tunnel between the ABRs in the backbone. 
Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries. 

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" < 
<mailto:lsr-boun...@ietf.org> lsr-boun...@ietf.org on behalf of  
<mailto:wang...@chinatelecom.cn> wang...@chinatelecom.cn> wrote:

Hi, LSR experts:

We have uploaded the new version of this PUA(Prefix Unreachable 
Announcement) draft. The main upda

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

2020-07-29 Thread Aijun Wang
Hi, Acee:

 

From: a...@cisco.com [mailto:a...@cisco.com] 
Sent: Tuesday, July 28, 2020 9:22 PM
To: Aijun Wang ; 'Aijun Wang' 
; lsr@ietf.org
Cc: 'Zhibo Hu' ; 'Yaqun Xiao' 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

Hi Aijun, 

 

You did misunderstand me so let me be brief. 

 

1.   By summarized prefix, I mean an unreachable prefix subsumed by the 
summary advertisement. I thought this would be clear from the context of your 
draft. So my point is that signaling unreachability from one ABR is only useful 
if the subsumed prefix is reachable though another ABR. 

[WAJ] Signaling unreachability is also useful when the specified prefix isn’t 
reachable through all of ABRs.

2.   What I’m suggesting is provide connectivity between the ABRs. For 
example, you use the tunneling defining in section 6.1 whenever a subsumed 
prefix is unreachable. Please don’t come back with another circular argument. 

[WAJ] Zhibo has answered this in another mail.  Tunnel solution can’t solve BGP 
route convergence scenario.

Thanks,
Acee

 

From: Aijun Wang mailto:wangai...@tsinghua.org.cn> >
Date: Monday, July 27, 2020 at 9:57 PM
To: Acee Lindem mailto:a...@cisco.com> >, 'Aijun Wang' 
mailto:wang...@chinatelecom.cn> >, "lsr@ietf.org 
<mailto:lsr@ietf.org> " mailto:lsr@ietf.org> >
Cc: 'Zhibo Hu' mailto:huzh...@huawei.com> >, 'Yaqun Xiao' 
mailto:xiaoya...@huawei.com> >
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

Hi, Acee:

Let me try to answer your concerns.

Please see the below inline.

If I missed your comments, please correct me.

 

Best Regards

 

Aijun Wang

China Telecom

 

-Original Message-
From: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>  
[mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, July 28, 2020 1:51 AM
To: Aijun Wang mailto:wang...@chinatelecom.cn> >; 
lsr@ietf.org <mailto:lsr@ietf.org> 
Cc: 'Zhibo Hu' mailto:huzh...@huawei.com> >; 'Yaqun Xiao' 
mailto:xiaoya...@huawei.com> >
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

Speaking as an LSR Working Group member:

 

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff.

[WAJ] Let’s confirm it is not cliff J, but traffic black hole that should be 
notified and repaired. 

 

Rather than messing up OSPF and IS-IS with these complex and unnecessary 
mechanisms, it would be better to address the requirement in your network 
design.

[WAJ] section 3 of this draft 
<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-3>
  has demonstrated the problem/scenarios that needs to be addressed. We think 
this will be normal phenomena in the IPv6 era. 

 

Note that the unreachability of a given summarized prefix is only relevant if 
it is reachable through another ABR. 

[WAJ] it is not the unreachability of a given summarized prefix, but the more 
specific prefix that within the summary address.

 

In this case, the network design should provide adequate intra-area redundancy 
to provide communications between the ABRs. 

[WAJ] Even there is adequate intra-area redundancy communication between the 
ABRs, the failure of one specific prefix within the summary address that 
advertised by the ABR will lead to traffic black hole.

 

If this cannot be accomplished, an intra-area adjacency should be established 
over a tunnel between the ABRs in the backbone. 

[WAJ] Section 6.1 introduces the tunnel solution to redirect the traffic to 
another ABR, when such ABR router can reach the specified prefix.  But this 
additional mechanism will be used only when the ABR all reach the PUA limit. If 
not, the PUA mechanism described in section 4 
<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-4>
  can be used to guide the traffic. 

 

Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries. 

[WAJ] Yes, you are right. Normally the ABR will drop the traffic that it can’t 
reach.  But there is situation that when the tunnel that is pre-established 
among ABRs, and each tunnel claim it can reach the specified prefix, the 
traffic loop may arise if the received ABR send traffic via another tunnel.  

 

Acee

 

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" < 
<mailto:lsr-boun...@ietf.org%20on%20behalf%20of%20wang...@chinatelecom.cn> 
lsr-boun...@ietf.org on behalf of wang...@chinatelecom.cn> wrote:

 

Hi, LSR experts:

 

We have uploaded the new version of this PUA(Prefix Unreachable 
Announcement) draft. The main updates are the followi

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

2020-07-29 Thread Huzhibo
Hi Robert:

BGP next hop validation can solve some but not all problems. In your 
example, if PE1 has learned only 1.1.1.0/24 but not 1.1.1.1/32, BGP cannot 
detect the reachability of 1.1.1.1/32.

Thanks

Zhibo Hu
From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Tuesday, July 28, 2020 5:18 PM
To: Acee Lindem (acee) 
Cc: Aijun Wang ; lsr@ietf.org; Huzhibo 
; Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hello Acee,

I would like to question your assessment that signalling unreachable routes is 
unnecessary.

Imagine hierarchical network with areas. Under no failures area 1 advertises to 
area 0 summary LSA with 1.1.1.0/24<http://1.1.1.0/24>. That block covers PE's 
loopbacks which within the area are /32s. Those loopbacks are also BGP next 
hops.

Now imagine PE1 with 1.1.1.1/32<http://1.1.1.1/32> fails. Well till BGP 
reconverges all paths advertised by this PE with 1.1.1.1/32<http://1.1.1.1/32> 
are still valid as this next hop is still reachable entire network wide. That 
means that traffic is being sent to this failed PE1 for relatively long period 
of time.

It seems natural that without breaking benefits of summarization across areas 
or domains in the above scenario we could continue to advertise 
1.1.1.0/24<http://1.1.1.0/24> - 1.1.1.1/32<http://1.1.1.1/32>. That is when I 
see most benefits of advertising unreachability aka negative routing.

Of course said all of the above - if you search your employer's archives - you 
will see a proposal where the above mechanism can be done within BGP itself 
with no touch to the IGP - just using a bit of twisted next hop validation 
steps and BGP native recursion. I am not going to make any judgements here 
which method is better or easier - naturally I personally like BGP one more :).

But I hope this is clear why at least discussion on the subject is important. 
It also illustrates why the below statement is not necessarily correct:

"Note that the unreachability of a given summarized prefix is only relevant if 
it is reachable through another ABR. "

Kind regards,
Robert.


On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex 
and unnecessary mechanisms, it would be better to address the requirement in 
your network design. Note that the unreachability of a given summarized prefix 
is only relevant if it is reachable through another ABR. In this case, the 
network design should provide adequate intra-area redundancy to provide 
communications between the ABRs. If this cannot be accomplished, an intra-area 
adjacency should be established over a tunnel between the ABRs in the backbone. 
Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries.

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" 
mailto:lsr-boun...@ietf.org> on behalf of 
wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>> 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> 
[mailto:internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>]
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; Yaqun Xiao 
mailto:xiaoya...@huawei.com>>
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

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

2020-07-29 Thread Huzhibo
Hi Acee:

In the scenario mentioned by Robert, the section 6.1 solution doesn't work. 
When BGP needs to detect the reachability of the next hop to trigger BGP 
convergence.

Thanks
Zhibo Hu

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Tuesday, July 28, 2020 9:24 PM
To: Huzhibo ; Aijun Wang ; 
lsr@ietf.org
Cc: Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

See my response to Aijun... Please provide topologies where the section 6.1 
solution doesn't work. 
Acee

On 7/27/20, 10:03 PM, "Huzhibo"  wrote:

Hi Acee:

In fact, we have meet some scenarios where redundant paths cannot be 
deployed within a area. Especially when the access area uses the nearby access 
principle, ABRs form disordered combinations, which makes it difficult to 
deploy physical or tunnel connections. In addition, advertising unreachable 
prefixes can prevent traffic detours. Of course, This draft also has some other 
attempts to use Segment Routing to automatically establish connections between 
ABRs.

Thanks

Zhibo Hu

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Tuesday, July 28, 2020 1:51 AM
To: Aijun Wang ; lsr@ietf.org
Cc: Huzhibo ; Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex 
and unnecessary mechanisms, it would be better to address the requirement in 
your network design. Note that the unreachability of a given summarized prefix 
is only relevant if it is reachable through another ABR. In this case, the 
network design should provide adequate intra-area redundancy to provide 
communications between the ABRs. If this cannot be accomplished, an intra-area 
adjacency should be established over a tunnel between the ABRs in the backbone. 
Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries. 

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of 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.

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

2020-07-28 Thread bruno.decraene


From: Acee Lindem (acee) [mailto:a...@cisco.com]


An interesting encoding – note that the draft doesn’t use it for forwarding.
[Bruno] Agreed that the distinction between routing and reachability 
information is a key point.
--Bruno
Acee

From: Bruno Decraene 
mailto:bruno.decra...@orange.com>>
Date: Tuesday, July 28, 2020 at 5:51 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>, Acee Lindem 
mailto:a...@cisco.com>>
Cc: Aijun Wang mailto:wang...@chinatelecom.cn>>, Zhibo 
Hu mailto:huzh...@huawei.com>>, Yaqun Xiao 
mailto:xiaoya...@huawei.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Another data point about advertising more detailed reachability/unreachability: 
https://tools.ietf.org/html/draft-swallow-isis-detailed-reach-01

(for IPv6 some form of compression may be beneficial).

--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Tuesday, July 28, 2020 11:18 AM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Cc: Aijun Wang mailto:wang...@chinatelecom.cn>>; Zhibo 
Hu mailto:huzh...@huawei.com>>; Yaqun Xiao 
mailto:xiaoya...@huawei.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hello Acee,

I would like to question your assessment that signalling unreachable routes is 
unnecessary.

Imagine hierarchical network with areas. Under no failures area 1 advertises to 
area 0 summary LSA with 1.1.1.0/24<http://1.1.1.0/24>. That block covers PE's 
loopbacks which within the area are /32s. Those loopbacks are also BGP next 
hops.

Now imagine PE1 with 1.1.1.1/32<http://1.1.1.1/32> fails. Well till BGP 
reconverges all paths advertised by this PE with 1.1.1.1/32<http://1.1.1.1/32> 
are still valid as this next hop is still reachable entire network wide. That 
means that traffic is being sent to this failed PE1 for relatively long period 
of time.

It seems natural that without breaking benefits of summarization across areas 
or domains in the above scenario we could continue to advertise 
1.1.1.0/24<http://1.1.1.0/24> - 1.1.1.1/32<http://1.1.1.1/32>. That is when I 
see most benefits of advertising unreachability aka negative routing.

Of course said all of the above - if you search your employer's archives - you 
will see a proposal where the above mechanism can be done within BGP itself 
with no touch to the IGP - just using a bit of twisted next hop validation 
steps and BGP native recursion. I am not going to make any judgements here 
which method is better or easier - naturally I personally like BGP one more :).

But I hope this is clear why at least discussion on the subject is important. 
It also illustrates why the below statement is not necessarily correct:

"Note that the unreachability of a given summarized prefix is only relevant if 
it is reachable through another ABR. "

Kind regards,
Robert.


On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex 
and unnecessary mechanisms, it would be better to address the requirement in 
your network design. Note that the unreachability of a given summarized prefix 
is only relevant if it is reachable through another ABR. In this case, the 
network design should provide adequate intra-area redundancy to provide 
communications between the ABRs. If this cannot be accomplished, an intra-area 
adjacency should be established over a tunnel between the ABRs in the backbone. 
Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries.

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" 
mailto:lsr-boun...@ietf.org> on behalf of 
wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>> 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?

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

2020-07-28 Thread Acee Lindem (acee)
An interesting encoding – note that the draft doesn’t use it for forwarding.
Acee

From: Bruno Decraene 
Date: Tuesday, July 28, 2020 at 5:51 AM
To: Robert Raszuk , Acee Lindem 
Cc: Aijun Wang , Zhibo Hu , Yaqun 
Xiao , "lsr@ietf.org" 
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Another data point about advertising more detailed reachability/unreachability: 
https://tools.ietf.org/html/draft-swallow-isis-detailed-reach-01

(for IPv6 some form of compression may be beneficial).

--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Tuesday, July 28, 2020 11:18 AM
To: Acee Lindem (acee) 
Cc: Aijun Wang ; Zhibo Hu ; Yaqun 
Xiao ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hello Acee,

I would like to question your assessment that signalling unreachable routes is 
unnecessary.

Imagine hierarchical network with areas. Under no failures area 1 advertises to 
area 0 summary LSA with 1.1.1.0/24<http://1.1.1.0/24>. That block covers PE's 
loopbacks which within the area are /32s. Those loopbacks are also BGP next 
hops.

Now imagine PE1 with 1.1.1.1/32<http://1.1.1.1/32> fails. Well till BGP 
reconverges all paths advertised by this PE with 1.1.1.1/32<http://1.1.1.1/32> 
are still valid as this next hop is still reachable entire network wide. That 
means that traffic is being sent to this failed PE1 for relatively long period 
of time.

It seems natural that without breaking benefits of summarization across areas 
or domains in the above scenario we could continue to advertise 
1.1.1.0/24<http://1.1.1.0/24> - 1.1.1.1/32<http://1.1.1.1/32>. That is when I 
see most benefits of advertising unreachability aka negative routing.

Of course said all of the above - if you search your employer's archives - you 
will see a proposal where the above mechanism can be done within BGP itself 
with no touch to the IGP - just using a bit of twisted next hop validation 
steps and BGP native recursion. I am not going to make any judgements here 
which method is better or easier - naturally I personally like BGP one more :).

But I hope this is clear why at least discussion on the subject is important. 
It also illustrates why the below statement is not necessarily correct:

"Note that the unreachability of a given summarized prefix is only relevant if 
it is reachable through another ABR. "

Kind regards,
Robert.


On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex 
and unnecessary mechanisms, it would be better to address the requirement in 
your network design. Note that the unreachability of a given summarized prefix 
is only relevant if it is reachable through another ABR. In this case, the 
network design should provide adequate intra-area redundancy to provide 
communications between the ABRs. If this cannot be accomplished, an intra-area 
adjacency should be established over a tunnel between the ABRs in the backbone. 
Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries.

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" 
mailto:lsr-boun...@ietf.org> on behalf of 
wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>> 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> 
[mailto:internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>]
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; Yaqun Xiao 
mailto:xiaoya...@huawei.com>>
Subject: New Version Notification f

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

2020-07-28 Thread Acee Lindem (acee)
See my response to Aijun... Please provide topologies where the section 6.1 
solution doesn't work. 
Acee

On 7/27/20, 10:03 PM, "Huzhibo"  wrote:

Hi Acee:

In fact, we have meet some scenarios where redundant paths cannot be 
deployed within a area. Especially when the access area uses the nearby access 
principle, ABRs form disordered combinations, which makes it difficult to 
deploy physical or tunnel connections. In addition, advertising unreachable 
prefixes can prevent traffic detours. Of course, This draft also has some other 
attempts to use Segment Routing to automatically establish connections between 
ABRs.

Thanks

Zhibo Hu

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Tuesday, July 28, 2020 1:51 AM
To: Aijun Wang ; lsr@ietf.org
Cc: Huzhibo ; Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex 
and unnecessary mechanisms, it would be better to address the requirement in 
your network design. Note that the unreachability of a given summarized prefix 
is only relevant if it is reachable through another ABR. In this case, the 
network design should provide adequate intra-area redundancy to provide 
communications between the ABRs. If this cannot be accomplished, an intra-area 
adjacency should be established over a tunnel between the ABRs in the backbone. 
Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries. 

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of 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

2020-07-28 Thread Acee Lindem (acee)
Hi Aijun,

You did misunderstand me so let me be brief.


  1.  By summarized prefix, I mean an unreachable prefix subsumed by the 
summary advertisement. I thought this would be clear from the context of your 
draft. So my point is that signaling unreachability from one ABR is only useful 
if the subsumed prefix is reachable though another ABR.
  2.  What I’m suggesting is provide connectivity between the ABRs. For 
example, you use the tunneling defining in section 6.1 whenever a subsumed 
prefix is unreachable. Please don’t come back with another circular argument.
Thanks,
Acee

From: Aijun Wang 
Date: Monday, July 27, 2020 at 9:57 PM
To: Acee Lindem , 'Aijun Wang' , 
"lsr@ietf.org" 
Cc: 'Zhibo Hu' , 'Yaqun Xiao' 
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt


Hi, Acee:

Let me try to answer your concerns.

Please see the below inline.

If I missed your comments, please correct me.



Best Regards



Aijun Wang

China Telecom



-Original Message-
From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, July 28, 2020 1:51 AM
To: Aijun Wang ; lsr@ietf.org
Cc: 'Zhibo Hu' ; 'Yaqun Xiao' 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt



Speaking as an LSR Working Group member:



Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff.

[WAJ] Let’s confirm it is not cliff ☺, but traffic black hole that should be 
notified and repaired.



Rather than messing up OSPF and IS-IS with these complex and unnecessary 
mechanisms, it would be better to address the requirement in your network 
design.

[WAJ] section 3 of this 
draft<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-3>
 has demonstrated the problem/scenarios that needs to be addressed. We think 
this will be normal phenomena in the IPv6 era.



Note that the unreachability of a given summarized prefix is only relevant if 
it is reachable through another ABR.

[WAJ] it is not the unreachability of a given summarized prefix, but the more 
specific prefix that within the summary address.



In this case, the network design should provide adequate intra-area redundancy 
to provide communications between the ABRs.

[WAJ] Even there is adequate intra-area redundancy communication between the 
ABRs, the failure of one specific prefix within the summary address that 
advertised by the ABR will lead to traffic black hole.



If this cannot be accomplished, an intra-area adjacency should be established 
over a tunnel between the ABRs in the backbone.

[WAJ] Section 6.1 introduces the tunnel solution to redirect the traffic to 
another ABR, when such ABR router can reach the specified prefix.  But this 
additional mechanism will be used only when the ABR all reach the PUA limit. If 
not, the PUA mechanism described in section 
4<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-4>
 can be used to guide the traffic.



Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries.

[WAJ] Yes, you are right. Normally the ABR will drop the traffic that it can’t 
reach.  But there is situation that when the tunnel that is pre-established 
among ABRs, and each tunnel claim it can reach the specified prefix, the 
traffic loop may arise if the received ABR send traffic via another tunnel.



Acee



On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" mailto:lsr-boun...@ietf.org%20on%20behalf%20of%20wang...@chinatelecom.cn>>
 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> 
[mailto:internet-dra...@ietf.org]

Sent: Monday, July 27, 2020 9:16 AM

To: Zhibo Hu mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; Y

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

2020-07-28 Thread bruno.decraene
Another data point about advertising more detailed reachability/unreachability: 
https://tools.ietf.org/html/draft-swallow-isis-detailed-reach-01

(for IPv6 some form of compression may be beneficial).

--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Tuesday, July 28, 2020 11:18 AM
To: Acee Lindem (acee) 
Cc: Aijun Wang ; Zhibo Hu ; Yaqun 
Xiao ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hello Acee,

I would like to question your assessment that signalling unreachable routes is 
unnecessary.

Imagine hierarchical network with areas. Under no failures area 1 advertises to 
area 0 summary LSA with 1.1.1.0/24<http://1.1.1.0/24>. That block covers PE's 
loopbacks which within the area are /32s. Those loopbacks are also BGP next 
hops.

Now imagine PE1 with 1.1.1.1/32<http://1.1.1.1/32> fails. Well till BGP 
reconverges all paths advertised by this PE with 1.1.1.1/32<http://1.1.1.1/32> 
are still valid as this next hop is still reachable entire network wide. That 
means that traffic is being sent to this failed PE1 for relatively long period 
of time.

It seems natural that without breaking benefits of summarization across areas 
or domains in the above scenario we could continue to advertise 
1.1.1.0/24<http://1.1.1.0/24> - 1.1.1.1/32<http://1.1.1.1/32>. That is when I 
see most benefits of advertising unreachability aka negative routing.

Of course said all of the above - if you search your employer's archives - you 
will see a proposal where the above mechanism can be done within BGP itself 
with no touch to the IGP - just using a bit of twisted next hop validation 
steps and BGP native recursion. I am not going to make any judgements here 
which method is better or easier - naturally I personally like BGP one more :).

But I hope this is clear why at least discussion on the subject is important. 
It also illustrates why the below statement is not necessarily correct:

"Note that the unreachability of a given summarized prefix is only relevant if 
it is reachable through another ABR. "

Kind regards,
Robert.


On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex 
and unnecessary mechanisms, it would be better to address the requirement in 
your network design. Note that the unreachability of a given summarized prefix 
is only relevant if it is reachable through another ABR. In this case, the 
network design should provide adequate intra-area redundancy to provide 
communications between the ABRs. If this cannot be accomplished, an intra-area 
adjacency should be established over a tunnel between the ABRs in the backbone. 
Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries.

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" 
mailto:lsr-boun...@ietf.org> on behalf of 
wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>> 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> 
[mailto:internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>]
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; Yaqun Xiao 
mailto:xiaoya...@huawei.com>>
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 Unreach

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

2020-07-28 Thread Robert Raszuk
Hello Acee,

I would like to question your assessment that signalling unreachable routes
is unnecessary.

Imagine hierarchical network with areas. Under no failures area 1
advertises to area 0 summary LSA with 1.1.1.0/24. That block covers PE's
loopbacks which within the area are /32s. Those loopbacks are also BGP next
hops.

Now imagine PE1 with 1.1.1.1/32 fails. Well till BGP reconverges all paths
advertised by this PE with 1.1.1.1/32 are still valid as this next hop is
still reachable entire network wide. That means that traffic is being sent
to this failed PE1 for relatively long period of time.

It seems natural that without breaking benefits of summarization across
areas or domains in the above scenario we could continue to advertise
1.1.1.0/24 - 1.1.1.1/32. That is when I see most benefits of advertising
unreachability aka negative routing.

Of course said all of the above - if you search your employer's archives -
you will see a proposal where the above mechanism can be done within BGP
itself with no touch to the IGP - just using a bit of twisted next hop
validation steps and BGP native recursion. I am not going to make any
judgements here which method is better or easier - naturally I personally
like BGP one more :).

But I hope this is clear why at least discussion on the subject is
important. It also illustrates why the below statement is not
necessarily correct:

"Note that the unreachability of a given summarized prefix is only relevant
if it is reachable through another ABR. "

Kind regards,
Robert.


On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee)  wrote:

> Speaking as an LSR Working Group member:
>
> Asking the WG precisely how to advertise prefix unreachability is the
> wrong question - it is analogous to asking whether to use a car or truck to
> drive off the edge of a cliff. Rather than messing up OSPF and IS-IS with
> these complex and unnecessary mechanisms, it would be better to address the
> requirement in your network design. Note that the unreachability of a given
> summarized prefix is only relevant if it is reachable through another ABR..
> In this case, the network design should provide adequate intra-area
> redundancy to provide communications between the ABRs. If this cannot be
> accomplished, an intra-area adjacency should be established over a tunnel
> between the ABRs in the backbone. Contrary to section 6.1, Looping is
> normally not a problem as ABRs should add back hole routes for their
> advertised summaries.
>
> Acee
>
> On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang"  on behalf of wang...@chinatelecom.cn> 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
>

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

2020-07-27 Thread Huzhibo
Hi Acee:

In fact, we have meet some scenarios where redundant paths cannot be deployed 
within a area. Especially when the access area uses the nearby access 
principle, ABRs form disordered combinations, which makes it difficult to 
deploy physical or tunnel connections. In addition, advertising unreachable 
prefixes can prevent traffic detours. Of course, This draft also has some other 
attempts to use Segment Routing to automatically establish connections between 
ABRs.

Thanks

Zhibo Hu

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Tuesday, July 28, 2020 1:51 AM
To: Aijun Wang ; lsr@ietf.org
Cc: Huzhibo ; Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex 
and unnecessary mechanisms, it would be better to address the requirement in 
your network design. Note that the unreachability of a given summarized prefix 
is only relevant if it is reachable through another ABR. In this case, the 
network design should provide adequate intra-area redundancy to provide 
communications between the ABRs. If this cannot be accomplished, an intra-area 
adjacency should be established over a tunnel between the ABRs in the backbone. 
Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries. 

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of 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

2020-07-27 Thread Aijun Wang
Hi, Acee:

Let me try to answer your concerns.

Please see the below inline.

If I missed your comments, please correct me.

 

Best Regards

 

Aijun Wang

China Telecom

 

-Original Message-
From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, July 28, 2020 1:51 AM
To: Aijun Wang ; lsr@ietf.org
Cc: 'Zhibo Hu' ; 'Yaqun Xiao' 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

Speaking as an LSR Working Group member:

 

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff.

[WAJ] Let’s confirm it is not cliff J, but traffic black hole that should be 
notified and repaired. 

 

Rather than messing up OSPF and IS-IS with these complex and unnecessary 
mechanisms, it would be better to address the requirement in your network 
design.

[WAJ] section 3 of this draft 
<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-3>
  has demonstrated the problem/scenarios that needs to be addressed. We think 
this will be normal phenomena in the IPv6 era. 

 

Note that the unreachability of a given summarized prefix is only relevant if 
it is reachable through another ABR. 

[WAJ] it is not the unreachability of a given summarized prefix, but the more 
specific prefix that within the summary address.

 

In this case, the network design should provide adequate intra-area redundancy 
to provide communications between the ABRs. 

[WAJ] Even there is adequate intra-area redundancy communication between the 
ABRs, the failure of one specific prefix within the summary address that 
advertised by the ABR will lead to traffic black hole.

 

If this cannot be accomplished, an intra-area adjacency should be established 
over a tunnel between the ABRs in the backbone. 

[WAJ] Section 6.1 introduces the tunnel solution to redirect the traffic to 
another ABR, when such ABR router can reach the specified prefix.  But this 
additional mechanism will be used only when the ABR all reach the PUA limit. If 
not, the PUA mechanism described in section 4 
<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-4>
  can be used to guide the traffic. 

 

Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries. 

[WAJ] Yes, you are right. Normally the ABR will drop the traffic that it can’t 
reach.  But there is situation that when the tunnel that is pre-established 
among ABRs, and each tunnel claim it can reach the specified prefix, the 
traffic loop may arise if the received ABR send traffic via another tunnel.  

 

Acee

 

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" < 
<mailto:lsr-boun...@ietf.org%20on%20behalf%20of%20wang...@chinatelecom.cn> 
lsr-boun...@ietf.org on behalf of wang...@chinatelecom.cn> 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:  <mailto:internet-dra...@ietf.org> internet-dra...@ietf.org [ 
<mailto:internet-dra...@ietf.org> mailto:internet-dra...@ietf.org] 

Sent: Monday, July 27, 2020 9:16 AM

To: Zhibo Hu < <mailto:huzh...@huawei.com> huzh...@huawei.com>; Aijun Wang 
< <mailto:wang...@chinatelecom.cn> wang...@chinatelecom.cn>; Yaqun Xiao < 
<mailto:xiaoya...@huawei.com> xiaoya...@huawei.com>

    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: 
<htt

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

2020-07-27 Thread Acee Lindem (acee)
Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex 
and unnecessary mechanisms, it would be better to address the requirement in 
your network design. Note that the unreachability of a given summarized prefix 
is only relevant if it is reachable through another ABR. In this case, the 
network design should provide adequate intra-area redundancy to provide 
communications between the ABRs. If this cannot be accomplished, an intra-area 
adjacency should be established over a tunnel between the ABRs in the backbone. 
Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries. 

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of 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] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-26 Thread Aijun Wang
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