Greg,
On 13/10/2021 15:36, Greg Mirsky wrote:
Hi Aijun,
thank you for your quick response. Please find my further notes in-line
below tagged GIM>>.
Regards,
Greg
On Tue, Oct 12, 2021 at 9:06 PM Aijun Wang <[email protected]
<mailto:[email protected]>> wrote:
Hi, Greg:____
__ __
The defect detection time should be same as the IGP flooding speed.
GIM>> I think that that would not be the only component that
contributes to the overall detection delay. An instance of IGP needs
something to detect the local failure that triggers the LSA update and
flooding. AFAIK, if that process is based on IGP, it is in the
single-second, at the minimum, range. As a result, that time will
determine overall time to detect and propagate the notification of a
defect in the IGP domain.
It can achieve such goals via the PUA mechanism.____
Or else, we must depends on other mechanism, such as BFD, which
requires configuration overhead, and the process pressure especially
when the timer is decreased in multi-hop BFD mode.
GIM>> I agree that using an additional protocol increases complexity. On
another hand, if the IGP-based solution cannot guarantee the required
defect detection time, it seems that an operator is more likely to
choose the BFD-based solution.
the requirement here is not for sub-50ms, it has never been the case
with BGP PIC anyway. The target is sub-second which is doable with IGP
based solution.
thanks,
Peter
____
__ __
__ __
Best Regards____
__ __
Aijun Wang____
China Telecom____
__ __
*From:*[email protected] <mailto:[email protected]>
<[email protected] <mailto:[email protected]>> *On Behalf Of
*Greg Mirsky
*Sent:* Wednesday, October 13, 2021 10:43 AM
*To:* Aijun Wang <[email protected]
<mailto:[email protected]>>
*Cc:* [email protected] <mailto:[email protected]>; Robert Raszuk
<[email protected] <mailto:[email protected]>>; Acee Lindem (acee)
<[email protected] <mailto:[email protected]>>
*Subject:* Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS
and OSPF Extension for Event Notification"____
__ __
Hi Aijun,____
could you help me to understand the requirement for defect
detection time for the method you propose? Single seconds? Tens of
seconds?____
__ __
Regards,____
Greg____
__ __
On Tue, Oct 12, 2021, 18:27 Aijun Wang <[email protected]
<mailto:[email protected]>> wrote:____
Hi, Robert:____
____
Answers to your comments are inline below.____
____
____
Best Regards____
____
Aijun Wang____
China Telecom____
____
*From:*[email protected] <mailto:[email protected]>
<[email protected] <mailto:[email protected]>> *On Behalf
Of *Robert Raszuk
*Sent:* Wednesday, October 13, 2021 3:52 AM
*To:* Acee Lindem (acee) <[email protected]
<mailto:[email protected]>>
*Cc:* [email protected] <mailto:[email protected]>
*Subject:* Re: [Lsr] "Prefix Unreachable Announcement" and
"IS-IS and OSPF Extension for Event Notification"____
____
Hi Acee,____
____
I would like to make a comment on your point #1. ____
____
You said: ____
____
"Is this a problem that needs to be solved in the IGPs? The use
case offered in both drafts is signaling unreachability of a BGP
peer. Could this better solved with a different mechanism
(e.g., BFD)..."____
____
That is not a very precise statement - simply due to the fact
that to signal anything in any solution requires a peer to
detect giben network event. ____
____
In both cases such an event will likely be detected using BFD
(if we are talking about unreachability of a BGP or IGP peer). ____
*/[WAJ] No. Link or Node Failures are not detected via BFD
within one IGP domain. It just rely on the normal IGP flooding
procedures. Once the ABRs receive the updated LSA, they will
make the calculation and find the missing prefixes./*____
____
Neither of the drafts mentioned here replaces local BFD
detection. ____
*/[WAJ] Deploy such mechanisms can replace the BFD for BGP
configuration between PEs that located in different IGP
domains./*____
____
I do infer from your message that what was meant to be said was
an alternative to support BFD sessions across areas/levels for
example between PEs. Clearly that would get very ugly very
quickly. ____
____
However IMO the natural signalling in this case would be to use
BGP itself. Here are the few reasons: ____
*/[WAJ] How the BGP peer be detected that the peer has been
unreachable? Via BFD for BGP?/*____
____
* detection time will be the same for IGP or BGP____
*/[WAJ] It is the ABR/**/’s summarization action hides the
unreachable prefixes, then BGP peers located in different IGP
domains can’t know the failure as quickly as IGP within the same
domain./*____
____
* only those network elements which keep "interesting" state
will be notified____
*/[WAJ] To be more accurate, your above statement should be /**
/【* only those network elements which keep "interesting" state
will _act upon the PUA messages.__】_/*____
____
* speed of withdraw can be argued to be as fast as IGP flooding
especially considering hierarchical IGP design ____
*/[WAJ] When we let ABR send the PUA messages, not hide them,
the speed of withdraw can certainly be accelerated./*____
____
* withdraws can be easily aggregated (when we loose PE single
prefix can be used to remove all paths advertised by given PE)____
*/[WAJ] This is the effects PUA mechanism. when the BGP peer
receives the PUA message that includes the PE itself, all the
path advertised by the given PE can certainly be removed./*____
* withdraws can be injected as the next hop /32 or /128 prefixes
and remote next hop validation can be set not to consider less
specific routes to resolve next hops (in any case due to MPLS
data plane host routes are used in many networks today to
resolve BGP service routes to LSPs in spite of efforts to make
this more scalable). ____
*/[WAJ]This the effect of PUA mechanism./*____
____
Only when we prove that BGP based solutions are not sufficient
we could/should explore moving such signalling to IGPs. ____
*/[WAJ] Do the above responses prove the BGP based solution are
not sufficient?/*____
____
Kind regards,____
R.____
____
____
____
____
____
____
____
____
____
____
____
____
____
On Tue, Oct 12, 2021 at 9:06 PM Acee Lindem (acee)
<[email protected]
<mailto:[email protected]>> wrote:____
Speaking as WG Chairs: ____
____
The authors of “Prefix Unreachable Announcement”have
requested an adoption. The crux of the draft is to signal
unreachability of a prefix across OSPF or IS-IS areas when
area summarization is employed and prefix is summarised. We
also have “IS-IS and OSPF Extension for Event
Notification”which can be used to address the same use case.
The drafts take radically different approaches to the
problem and the authors of both drafts do not wish to
converge on the other draft’s method so it is understandable
that merging the drafts really isn’t an option. ____
____
Before an adoption call for either draft, I’d like to ask
the WG: ____
____
1.Is this a problem that needs to be solved in the IGPs? The
use case offered in both drafts is signaling unreachability
of a BGP peer. Could this better solved with a different
mechanism (e.g., BFD) rather than flooding this negative
reachability information across the entire IGP domain?____
2.Assuming we do want to take on negative advertisement in
the IGP, what are the technical merits and/or detriments of
the two approaches? ____
____
We’ll reserve any further discussion to “WG member”comments
on the two approaches.____
____
Thanks,
Acee and Chris____
____
____
_______________________________________________
Lsr mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr____
_______________________________________________
Lsr mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr____
_______________________________________________
Lsr mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
