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 <lsr-boun...@ietf.org> On Behalf Of Tony Przygienda
Sent: Friday, September 04, 2020 11:12 AM
To: Aijun Wang <wangai...@tsinghua.org.cn>
Cc: Gyan Mishra <hayabusa...@gmail.com>; Robert Raszuk <rob...@raszuk.net>;
Huzhibo <huzh...@huawei.com>; Aijun Wang <wang...@chinatelecom.cn>; Peter
Psenak <ppsenak=40cisco....@dmarc.ietf.org>; 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
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<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 <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>
Cc: Peter Psenak
<ppsenak=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>>; Robert
Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>; Huzhibo
<huzh...@huawei.com<mailto:huzh...@huawei.com>>; Aijun Wang
<wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>>; lsr
<lsr@ietf.org<mailto:lsr@ietf.org>>; Acee Lindem (acee)
<a...@cisco.com<mailto:a...@cisco.com>>; Xiaoyaqun
<xiaoya...@huawei.com<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 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
<wangai...@tsinghua.org.cn<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 <wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>>
Cc: Peter Psenak
<ppsenak=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>>;
Huzhibo <huzh...@huawei.com<mailto:huzh...@huawei.com>>; Aijun Wang
<wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>; lsr
<lsr@ietf.org<mailto:lsr@ietf.org>>; Acee Lindem (acee)
<a...@cisco.com<mailto:a...@cisco.com>>; Xiaoyaqun
<xiaoya...@huawei.com<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
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
Lsr@ietf.org<mailto:Lsr@ietf.org>
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
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
