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

[Gyan Mishra <[e-mail]>]

Hi Greg

PUA Section 5 really helps describe a primary use case for both PUA and
event notification draft, tracking of egress PE BGP next hop attribute
component prefixes that are part of a summary and I used the example of RFC
5283 MPLS LDP Inter-area extension LPM matching but can apply to any use
case even IP data plane or SRv6 forwarding plane improvements in
convergence.

Kind Regards

Gyan
On Wed, Oct 13, 2021 at 9:05 PM Greg Mirsky <[e-mail]> wrote:

> 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 <[e-mail]> 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 <[e-mail]>
>> 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:* [e-mail] <[e-mail]> *On Behalf Of *Greg
>>> Mirsky
>>> *Sent:* Wednesday, October 13, 2021 10:43 AM
>>> *To:* Aijun Wang <[e-mail]>
>>> *Cc:* [e-mail]; Robert Raszuk <[e-mail]>; Acee Lindem
>>> (acee) <acee=[e-mail]>
>>> *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 <[e-mail]>
>>> wrote:
>>>
>>> Hi, Robert:
>>>
>>>
>>>
>>> Answers to your comments are inline below.
>>>
>>>
>>>
>>>
>>>
>>> Best Regards
>>>
>>>
>>>
>>> Aijun Wang
>>>
>>> China Telecom
>>>
>>>
>>>
>>> *From:* [e-mail] <[e-mail]> *On Behalf Of *Robert
>>> Raszuk
>>> *Sent:* Wednesday, October 13, 2021 3:52 AM
>>> *To:* Acee Lindem (acee) <acee=[e-mail]>
>>> *Cc:* [e-mail]
>>> *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=
>>> [e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>>> _______________________________________________
>>> Lsr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>>> _______________________________________________
>>> Lsr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email [e-mail] <[e-mail]>*
>>
>>
>>
>> *M 301 502-1347*
>>
>> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*