Hi Bruno As far as BGP PIC (edge) it is completely orthogonal to summarization framework the PUA/PULSE solutions is addressing.
Let’s say for example you have ingress area A and egress area B and both have summaries of the other area. So all LPM longer matches for ingress area A exist within ingress area A and the summary for area A only exists in area B and vice versa. I will call source area the area where the prefixes reside. I will call the destination area the area where the loopbacks are summarized into the alternate area. As far as BGP PIC edge the pre programmed backup path backup path is installed to BGP RIB on source Area eBGP PE-CE peering for alternate backup path for instantaneous convergence. So summarization does not come into play here with PIC Edge as it is on the source AS where the LPM routes exists locally to PE. Also with BGP PIC Edge the backup path next hop that gets pre programmed is the eBGP external link subnet that is not advertised into the IGP as next-hop-self next hop rewrite to loopback0 is what is advertised into IGP for PE-RR peering iBGP peering. So the host routes being summarized are completely orthogonal to BGP PIC Edge. BGP PIC (core) H-FIB updates would have the loopbacks in the H-FIB on PE and P routers which would get updated when PE failover occurs. For the source Area the LPM host routes would already exist so no change here. For the destination area the summary routes would be programmed into the H-FIB instead of host routes. I don’t see any issue here as well or change to current behavior. For BGP next hop tracking IGP callback, BGP is making a callback to IGP so that process would be the same. But now the IGP would have the ephemeral PUA/Pulse bad info to now send back to BGP would be the net change. Kind Regards Gyan On Thu, Jan 6, 2022 at 3:09 AM <[email protected]> wrote: > Hi Gyan, > > > > You are referring to both summarization and BGP PIC (edge). > > BGP PIC is quite old story, but if my memory serve me well, BGP PIC edge > relies on the presence of the specific (/32) prefix information in the FIB. > Hence it’s not clear to me how you can have both prefix summarization and > BGP PIC edge benefits in the FIB on the BGP ingress node. > > > > Taking the example from [1], below is a typical FIB chain for BGP Pic edge: > > > > IP Leaf: Pathlist: IP Leaf: Pathlist: > > -------- +-------+ -------- +----------+ > > VPN-IP1-->|BGP-NH1|-->IGP-IP1(BGP NH1)--->|IGP-NH1,I1|--->Adjacency1 > > | |BGP-NH2|-->.... | |IGP-NH2,I2|--->Adjacency2 > > | +-------+ | +----------+ > > | | > > | | > > v v > > OutLabel-List: OutLabel-List: > > +----------------------+ +----------------------+ > > |VPN-L11 (VPN-IP1, NH1)| |IGP-L11 (IGP-IP1, NH1)| > > |VPN-L21 (VPN-IP1, NH2)| |IGP-L12 (IGP-IP1, NH2)| > > +----------------------+ +----------------------+ > > > > Figure 2 Shared Hierarchical Forwarding Chain at iPE > > > > > > [1] > https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-bgp-pic-17#section-2.2 > > > > To help me get the picture, could you please highlight/draw the change(s) > that you have in mind assuming IGP prefix summarization and PULSE? (More > specifically regarding the IGP leaf “IGP-IP1(BGP NH1)") > > > > Thanks, > > Regards, > > -Bruno > > > > > > Orange Restricted > > *From:* Lsr <[email protected]> *On Behalf Of *Gyan Mishra > *Sent:* Thursday, January 6, 2022 12:27 AM > *To:* Robert Raszuk <[email protected]> > *Cc:* Greg Mirsky <[email protected]>; Les Ginsberg (ginsberg) < > [email protected]>; Christian Hopps <[email protected]>; Aijun Wang < > [email protected]>; Shraddha Hegde <[email protected]>; Tony > Li <[email protected]>; Hannes Gredler <[email protected]>; lsr < > [email protected]>; Peter Psenak <[email protected]> > *Subject:* Re: [Lsr] BGP vs PUA/PULSE > > > > Hi Robert > > > > The goal of the draft is providing egress protection when summarization is > used similar to RFC 8679 Egress protection framework, but without the > complexities. > > > > An IGP RIB within a domain is made up on connected interfaces and > loopbacks. Of the two types, the critical prefix to be tracked is the /32 > or /128 host routes on egress PE which is the BGP next-hop attribute via > next-hop-self rewrite. So both connected and loopbacks can be placed in > the same range for large aggregation domains, however due to the > criticality of the next hop attribute the loopbacks are placed in a > separate range, and so not summarized and flooded domain wide. > > > > The BGP next hop attribute is an MPLS exact match FEC binding for the > LSP. Flooding of loopbacks workaround is typically done for MPLS domain > due to issue with RFC 5283 inter area extension feature not being viable > solution for LPM summary matching, thus all the prefixes still have to be > flooded in LDP, so no net reduction in host route flooding. > > > > With the PUA/Pulse feature allows the domain wide flooding of the loopback > host routes is now possible as can now we take advantage and of > summarization. > > > > Even independent of MPLS in an IPv4, IPv6 or SRv6 environment the tracking > of BGP next-hop-attribute component prefixes is critically important to > improved convergence and not rely on BGP dead timers to expire. Even with > BFD, LFA/RLFA/TILFA local protection , PIC and other optimizations we still > need an optimization to track the summary route component prefixes to speed > up convergence providing egress PE protection. > > > > Kind Regards > > > > Gyan > > > > On Tue, Jan 4, 2022 at 6:55 PM Robert Raszuk <[email protected]> wrote: > > Hi Aijun, > > > > In most deployments summary routes are already crafted carefully to only > cover those destinations which are important and should be reachable from > outside of the area. > > > > So I see no point in building yet another policy to select a subset of > summaries to be PUA eligible. > > > > Along those lines I do not buy into the notion of "some prefixes within > summaries to be more important than others" - it is simply impossible to > say that this PE is more important than the other one in all > practical cases. > > > > If we are to roll out a mechanism to signal unreachability it better be > robust and dependable - not just an optional hint. With that I would > welcome solution which says - if we have more then X prefixes (or % of > prefixes) to be advertised by ABR we stop advertising the summary covering > them (or deaggregate the summary). > > > > Thx, > > R. > > > > > > > > > > > > > > On Wed, Jan 5, 2022 at 12:06 AM Aijun Wang <[email protected]> > wrote: > > I think the mentioned solution can also address Robert and Christian’s > concerns. > > Aijun Wang > > China Telecom > > > > On Jan 5, 2022, at 07:02, Aijun Wang <[email protected]> wrote: > > Hi, Greg: > > > > > https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-8 > has > some description for such considerations: > > “ In order to reduce the unnecessary advertisements of PUAM > > messages on ABRs, the ABRs should support the configuration of the > > protected prefixes. Based on such information, the ABR will only > > advertise the PUAM message when the protected prefixes(for example, > > the loopback addresses of PEs that run BGP) that within the summary > > address is missing.” > > > > > > Aijun Wang > > China Telecom > > > > On Jan 5, 2022, at 03:56, Greg Mirsky <[email protected]> wrote: > > > > Hi Peter, > > thank you for your response. I'm looking forward to the new version of the > draft. It will be interesting to learn the criteria that enable an ABR to > reliably identify the scenarios you've suggested are outside the scope of > the PULSE draft and should be handled differently. > > > > Regards, > > Greg > > > > On Tue, Jan 4, 2022 at 10:08 AM Peter Psenak <[email protected]> wrote: > > Hi Greg, > > On 04/01/2022 18:13, Greg Mirsky wrote: > > Hi Peter, > > I'm probably missing something in the current PULSE but I cannot find > > the mechanism that limits the number of the pulses. Do you envision that > > being like a throttling mechanism? But delaying the propagation of > > notification for some events might cause more instability in a network. > > no. It's a limit not a delay. If too many edge nodes loose connectivity > to the ABR in its area, it's a result of the severe event like area > partition or loss of area connectivity from ABR. These are not types of > events that we are trying to address with pulses. > > The limit is not described in the published version of the draft. > We are working on the updated version that will include the description > of it. > > thanks, > Peter > > > > > Regards, > > Greg > > > > On Tue, Jan 4, 2022 at 1:52 AM Peter Psenak <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi Greg, > > > > On 03/01/2022 23:17, Greg Mirsky wrote: > > > Happy New Year to All! > > > > > > Hi Peter, > > > Top-pasting: > > > In 99,99% of cases there will be only single pulse generated when > > one PE > > > goes down. That itself is a very rare event itself. > > > > > > We can easily limit the number of pulses generated on ABR to a > single > > > digit number to cover the unlikely case of many PEs in area > becoming > > > unreachable at the same time. > > > > > > I think that it is possible for the summarizing ABR to get > > disconnected > > > from the IGP area in such a way that the summarization is still > > valid. > > > If such a case is valid, would the ABR generate PULSE for each > > > disconnected PE? > > > > obviously not. That's why I mentioned the number of pulses will be > > limited on every ABR. > > > > thanks, > > Peter > > > > > > > > Regards, > > > Greg > > > > > > On Mon, Jan 3, 2022 at 8:56 AM Peter Psenak > > > <[email protected] > > <mailto:[email protected]> > > <mailto:[email protected] > > <mailto:[email protected]>>> > > > wrote: > > > > > > Chris, > > > > > > On 03/01/2022 17:18, Christian Hopps wrote: > > > > > > > > Peter Psenak <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> writes: > > > > > > > >> On 03/01/2022 16:21, Christian Hopps wrote: > > > >>> > > > >>>> On Nov 29, 2021, at 7:39 PM, Les Ginsberg (ginsberg) > > > <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>> wrote: > > > >>>> > > > >>>> Tony – > > > >>>> Let me try one example – see if it helps. > > > >>>> Summarization is used in the network. > > > >>>> But customer identifies a modest number of key nodes > > where it > > > wants to detect loss of reachability ASAP. Unfortunately, > > customer > > > is unable to assign addresses which are outside of the > summary to > > > these nodes. > > > >>> > > > >>> I think this does in fact capture the problem trying to > be > > > solved here, nicely. > > > >> > > > >> not really. > > > >> In fact assigning addresses to the nodes in a way that > > they are > > > part of the > > > >> summary is the right thing to do. > > > > > > > > No, not if you want more detailed information about > specific > > > reachability it's not. And .... > > > > > > > > > typically you want to summarize all prefixes inside the area > when > > > advertising outside the area. And you want to know about some > > of these > > > prefixes when they are lost to help convergence. > > > > > > > > > > > > > >> The problem we are trying to solve is to use the > > summarization > > > but without the > > > >> loss of the fast notification of the node down event. > > > > > > > > You want more specific information about reachability, but > you > > > just want to do it when the network is stressed and > > undergoing change. > > > > > > > > So the "works now" way of not summarizing these important > > > prefixes has the state in the network when it's working, so > > you know > > > adding and removing it is something the network is already > > capable > > > of handling. > > > > > > > > New signaling that *only* is created when things start > > failing, > > > tests the infrastructure at exactly the wrong time. > > > > > > In 99,99% of cases there will be only single pulse generated > when > > > one PE > > > goes down. That itself is a very rare event itself. > > > > > > We can easily limit the number of pulses generated on ABR to > > a single > > > digit number to cover the unlikely case of many PEs in area > > becoming > > > unreachable at the same time. > > > > > > > > > > > > > > If a failing network can handle the extra state, then a > > > functioning stable network of course can too. > > > > > > no, that's not what we claim. We want network to be > > summarized all > > > times > > > and generate limited number of pulses at any given time to > > help the > > > network converge fast in case where single (or very few) PEs > > in an area > > > go down. > > > > > > thanks, > > > Peter > > > > > > > > > > > > > > > > > Thanks, > > > > Chris. > > > > > > > >> > > > >> thanks, > > > >> Peter > > > >> > > > >> > > > >>> One solution very simple solution that works today is: > > > >>> - Tell the customer they can't do this, but they *can* > > modify > > > their addressing > > > >>> (this is literally what they do for a living) so that > they > > > don't have this > > > >>> problem. > > > >>> Do we *really* want modify our IGPs (a BIG ask) with some > > > pretty questionable > > > >>> changes, just to save the operators the trouble of doing > > their > > > job correctly? > > > >>> Maybe the answer here is this isn't a good idea, and we > > should > > > move on... > > > >>> Thanks, > > > >>> Chris. > > > >>> [as wg member] > > > >>> _______________________________________________ > > > >>> Lsr mailing list > > > >>> [email protected] <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>> > > > >>> https://www.ietf.org/mailman/listinfo/lsr > > <https://www.ietf.org/mailman/listinfo/lsr> > > > <https://www.ietf.org/mailman/listinfo/lsr > > <https://www.ietf.org/mailman/listinfo/lsr>> > > > >>> > > > > > > > > > > > > > > _______________________________________________ > > > Lsr mailing list > > > [email protected] <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>> > > > https://www.ietf.org/mailman/listinfo/lsr > > <https://www.ietf.org/mailman/listinfo/lsr> > > > <https://www.ietf.org/mailman/listinfo/lsr > > <https://www.ietf.org/mailman/listinfo/lsr>> > > > > > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
