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

From: Gyan Mishra <[email-masked]>
Date: Fri, 4 Sep 2020 03:41:33 -0400

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 <[email-masked]>
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:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Gyan
> Mishra
>
>
> *Sent:* Thursday, August 6, 2020 4:44 PM
> *To:* Aijun Wang <[email-masked]>
> *Cc:* Peter Psenak <ppsenak=[email-masked]>; Robert Raszuk <
> [email-masked]>; Huzhibo <[email-masked]>; Aijun Wang <
> [email-masked]>; lsr <[email-masked]>; Acee Lindem (acee) <
> [email-masked]>; Xiaoyaqun <[email-masked]>
> *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 <[email-masked]>
> wrote:
>
> Hi, Robert:
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Friday, July 31, 2020 6:21 PM
> *To:* Aijun Wang <[email-masked]>
> *Cc:* Peter Psenak <ppsenak=[email-masked]>; Huzhibo <
> [email-masked]>; Aijun Wang <[email-masked]>; lsr <
> [email-masked]>; Acee Lindem (acee) <[email-masked]>; Xiaoyaqun <
> [email-masked]>
> *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
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-134713101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g> *Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 4 Sep 2020 20:12:24 +0200

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 4 Sep 2020 19:00:03 +0000

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 <[email-masked]> On Behalf Of Tony Przygienda
Sent: Friday, September 04, 2020 11:12 AM
To: Aijun Wang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Robert Raszuk <[email-masked]>; Huzhibo <[email-masked]>; Aijun Wang <[email-masked]>; Peter Psenak <ppsenak=[email-masked]>; lsr <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Xiaoyaqun <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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.

Best Regards

Aijun Wang
China Telecom

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

Hi Aijun and authors

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Robert:

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Friday, July 31, 2020 6:21 PM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: Peter Psenak <ppsenak=[email-masked]<mailto:[email-masked]>>; Huzhibo <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; Xiaoyaqun <[email-masked]<mailto:[email-masked]>>
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 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 ☺

Many thx,
R.
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr
--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 4 Sep 2020 20:03:33 +0000

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)" <[email-masked]>
Date: Friday, September 4, 2020 at 3:00 PM
To: Tony Przygienda <[email-masked]>, Aijun Wang <[email-masked]>
Cc: Gyan Mishra <[email-masked]>, Robert Raszuk <[email-masked]>, Huzhibo <[email-masked]>, Aijun Wang <[email-masked]>, Peter Psenak <ppsenak=[email-masked]>, lsr <[email-masked]>, Acee Lindem <[email-masked]>, Xiaoyaqun <[email-masked]>
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

   Les

-- tony

Best Regards

Aijun Wang
China Telecom

Hi Aijun and authors

Kind Regards

Gyan

Many thx,
R.

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 4 Sep 2020 16:30:38 -0400

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) <[email-masked]> 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)" <[email-masked]>
> *Date: *Friday, September 4, 2020 at 3:00 PM
> *To: *Tony Przygienda <[email-masked]>, Aijun Wang <
> [email-masked]>
> *Cc: *Gyan Mishra <[email-masked]>, Robert Raszuk <
> [email-masked]>, Huzhibo <[email-masked]>, Aijun Wang <
> [email-masked]>, Peter Psenak <ppsenak=[email-masked]>,
> lsr <[email-masked]>, Acee Lindem <[email-masked]>, Xiaoyaqun <
> [email-masked]>
> *Subject: *RE: [Lsr] New Version Notification for
> 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.
>
>
>
> *From:* Lsr <[email-masked]> *On Behalf Of *Tony Przygienda
> *Sent:* Friday, September 04, 2020 11:12 AM
> *Cc:* Gyan Mishra <[email-masked]>; Robert Raszuk <
> [email-masked]>; Peter Psenak <ppsenak=[email-masked]>;
> lsr <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Xiaoyaqun <
> [email-masked]>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>

-- 

*Gyan Mishra*

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 7 Sep 2020 11:44:22 +0800

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:[email-masked]] 
Sent: Saturday, September 5, 2020 4:31 AM
To: Acee Lindem (acee) <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Tony Przygienda <[email-masked]>; Aijun Wang <[email-masked]>; Robert Raszuk <[email-masked]>; Huzhibo <[email-masked]>; Aijun Wang <[email-masked]>; Peter Psenak <ppsenak=[email-masked]>; lsr <[email-masked]>; Xiaoyaqun <[email-masked]>
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) <[email-masked] <mailto:[email-masked]> > wrote:

Speaking as WG member…. 

[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)" <[email-masked] <mailto:[email-masked]> >
Date: Friday, September 4, 2020 at 3:00 PM
To: Tony Przygienda <[email-masked] <mailto:[email-masked]> >, Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: Gyan Mishra <[email-masked] <mailto:[email-masked]> >, Robert Raszuk <[email-masked] <mailto:[email-masked]> >, Huzhibo <[email-masked] <mailto:[email-masked]> >, Aijun Wang <[email-masked] <mailto:[email-masked]> >, Peter Psenak <ppsenak=[email-masked] <mailto:[email-masked]> >, lsr <[email-masked] <mailto:[email-masked]> >, Acee Lindem <[email-masked] <mailto:[email-masked]> >, Xiaoyaqun <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

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

   Les

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

-- tony 

On Mon, Aug 24, 2020 at 11:11 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Gyan:

 

Best Regards

Aijun Wang

China Telecom

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

Hi Aijun and authors

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.  

 

Kind Regards 

Gyan

On Tue, Aug 4, 2020 at 11:25 PM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Robert:

From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Robert Raszuk
Sent: Friday, July 31, 2020 6:21 PM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: Peter Psenak <ppsenak=[email-masked] <mailto:[email-masked]> >; Huzhibo <[email-masked] <mailto:[email-masked]> >; Aijun Wang <[email-masked] <mailto:[email-masked]> >; lsr <[email-masked] <mailto:[email-masked]> >; Acee Lindem (acee) <[email-masked] <mailto:[email-masked]> >; Xiaoyaqun <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

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

[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
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/lsr

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

_______________________________________________
Lsr mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/lsr

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 7 Sep 2020 10:53:32 +0200

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

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 7 Sep 2020 17:31:41 +0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, September 7, 2020 4:54 PM
To: Aijun Wang <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <[email-masked]>; Peter Psenak <ppsenak=[email-masked]>; Huzhibo <[email-masked]>; Aijun Wang <[email-masked]>; lsr <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Xiaoyaqun <[email-masked]>; Tony Przygienda <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi Aijun,

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

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

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 7 Sep 2020 11:35:45 +0200

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 <[email-masked]>
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.
>
> *Sent:* Monday, September 7, 2020 4:54 PM
> *Cc:* Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <
> [email-masked]>; Peter Psenak <ppsenak=[email-masked]>;
> Huzhibo <[email-masked]>; Aijun Wang <[email-masked]>; lsr <
> [email-masked]>; Tony Przygienda <[email-masked]>
> *It**’s the same as the beginning, as not all of the prefixes can be
> 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
>
>
>

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 9 Sep 2020 09:22:50 +0800

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

Sent: Monday, September 7, 2020 5:36 PM

Hi Aijun,

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 <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Robert:

Best Regards

Aijun Wang

China Telecom

Cc: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> >; Gyan Mishra <[email-masked] <mailto:[email-masked]> >; Peter Psenak <ppsenak=[email-masked] <mailto:[email-masked]> >; Huzhibo <[email-masked] <mailto:[email-masked]> >; Aijun Wang <[email-masked] <mailto:[email-masked]> >; lsr <[email-masked] <mailto:[email-masked]> >; Acee Lindem (acee) <[email-masked] <mailto:[email-masked]> >; Xiaoyaqun <[email-masked] <mailto:[email-masked]> >; Tony Przygienda <[email-masked] <mailto:[email-masked]> >

Hi Aijun,

Kind regards,
Robert

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 9 Sep 2020 09:08:04 +0200

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 <[email-masked]> wrote:

> For inter-area scenario, it covers the situation that the next-hop is
> reachable via one ABR but unreachable via another ABR.
>
> *Sent:* Monday, September 7, 2020 5:36 PM
> 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.
>
>
>
>
>

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 9 Sep 2020 15:40:10 +0800

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: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, September 9, 2020 3:08 PM
To: Aijun Wang <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <[email-masked]>; Peter Psenak <ppsenak=[email-masked]>; Huzhibo <[email-masked]>; Aijun Wang <[email-masked]>; lsr <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Xiaoyaqun <[email-masked]>; Tony Przygienda <[email-masked]>
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.

 

Thx

R.

On Wed, Sep 9, 2020, 03:22 Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Robert:

 

Best Regards

Aijun Wang

China Telecom

Hi Aijun,

Best,

Robert.

Hi, Robert:

Best Regards

Aijun Wang

China Telecom

Hi Aijun,

Kind regards,
Robert