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 <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] *On Behalf Of *Gyan
> Mishra
> *Sent:* Thursday, August 6, 2020 4:44 PM
> *To:* Aijun Wang <wangai...@tsinghua.org.cn>
> *Cc:* Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org>; Robert Raszuk <
> rob...@raszuk.net>; Huzhibo <huzh...@huawei.com>; Aijun Wang <
> wang...@chinatelecom.cn>; lsr <lsr@ietf.org>; Acee Lindem (acee) <
> a...@cisco.com>; Xiaoyaqun <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 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 <wangai...@tsinghua.org.cn>
> 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 <wang...@chinatelecom.cn>
> *Cc:* Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org>; Huzhibo <
> huzh...@huawei.com>; Aijun Wang <wangai...@tsinghua.org.cn>; lsr <
> lsr@ietf.org>; Acee Lindem (acee) <a...@cisco.com>; 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
> 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 *Silver Spring, MD
>
>
> _______________________________________________
> 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
