Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Hi Gyan,
thank you for the most detailed information. With the addition of the
single-hop BFD the puzzle is complete. Or almost complete. What I am
wondering, is the fact that a PE is likely to be a part of a mesh network
that provides more resilient service. As a result, a single BFD session
going down would not mean that the PE is disconnected from the network and
generating an update seems sub-optimal. I've likely missed how such a
scenario is handled in the drafts. Need to read more carefully.

Regards,
Greg

On Wed, Oct 13, 2021 at 5:38 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> Hi Greg
>
> This draft would utilize the same IGP optimizations used today such as IGP
> single hop BFD for core link failure detection tuning down to sub second.
> Most modern routers LC’s are to process BFD control packet processing in
> hardware.  We are assuming all typical optimizations are in utilized for
> close to hitless convergence such as LFA, RLFA, BGP PIC etc.
>
> Even with all the optimizations, we still need a method of tracking
> component prefixes when summarization is employed in very large domains
> carved up into many areas or levels.
>
> The goal of the PUA and Event Notification draft is to be able to track
> the component prefixes of ASBR summary advertisement in the use case of BGP
> next hop attribute set to self loopback0 on each PE. With the PUA mechanism
> a negative advertisement PUA is flooded to force the control plane to
> converge when the PE goes down and loopback0 component prefix.  This same
> mechanism of PUA component prefix tracking of a summary advertisement is
> also done via the Event Notification draft IGP extension.
>
> So an alternative has been proposed to use loopback to loopback multi hop
> BFD to track the iBGP peering directly as a mechanism of tracking the same
> component prefixes of a summary advertisement if the individual iBGP PE-RR
> peering went down.  That would be more complicated and convoluted and maybe
> not as scalable is the thought for large scale network with 1000s of PEs.
>
>
> Kind Regards
>
> Gyan
>
> On Wed, Oct 13, 2021 at 12:07 AM Aijun Wang <wangaijun@tsinghua.org.cn>
> wrote:
>
>> Hi, Greg:
>>
>>
>>
>> The defect detection time should be same as the IGP flooding speed. 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.
>>
>>
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> *From:* lsr-bounces@ietf.org <lsr-bounces@ietf.org> *On Behalf Of *Greg
>> Mirsky
>> *Sent:* Wednesday, October 13, 2021 10:43 AM
>> *To:* Aijun Wang <wangaijun@tsinghua.org.cn>
>> *Cc:* lsr@ietf.org; Robert Raszuk <robert@raszuk.net>; Acee Lindem
>> (acee) <acee=40cisco.com@dmarc.ietf.org>
>> *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 <wangaijun@tsinghua.org.cn> wrote:
>>
>> Hi, Robert:
>>
>>
>>
>> Answers to your comments are inline below.
>>
>>
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> *From:* lsr-bounces@ietf.org <lsr-bounces@ietf.org> *On Behalf Of *Robert
>> Raszuk
>> *Sent:* Wednesday, October 13, 2021 3:52 AM
>> *To:* Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>
>> *Cc:* lsr@ietf.org
>> *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) <acee=
>> 40cisco.com@dmarc.ietf.org> 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
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>> _______________________________________________
>> 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
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
>
>
> *M 301 502-1347*
>
>