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

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 <wangaijun@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-bounces@ietf.org [mailto:lsr-bounces@ietf.org] *On Behalf Of *Gyan
> Mishra
>
>
> *Sent:* Thursday, August 6, 2020 4:44 PM
> *To:* Aijun Wang <wangaijun@tsinghua.org.cn>
> *Cc:* Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>; Robert Raszuk <
> robert@raszuk.net>; Huzhibo <huzhibo@huawei.com>; Aijun Wang <
> wangaj3@chinatelecom.cn>; lsr <lsr@ietf.org>; Acee Lindem (acee) <
> acee@cisco.com>; Xiaoyaqun <xiaoyaqun@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 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 <wangaijun@tsinghua.org.cn>
> wrote:
>
> Hi, Robert:
>
>
>
> *From:* lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] *On Behalf Of *Robert
> Raszuk
> *Sent:* Friday, July 31, 2020 6:21 PM
> *To:* Aijun Wang <wangaj3@chinatelecom.cn>
> *Cc:* Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>; Huzhibo <
> huzhibo@huawei.com>; Aijun Wang <wangaijun@tsinghua.org.cn>; lsr <
> lsr@ietf.org>; Acee Lindem (acee) <acee@cisco.com>; Xiaoyaqun <
> xiaoyaqun@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
> 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
>
> --
>
> <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