Thanks Bruno for the reference and clarification. Gyan On Fri, Jan 7, 2022 at 9:02 AM <[email protected]> wrote:
> Hi Gyan, > > > > Please see inline [Bruno] > > > > > > Orange Restricted > > *From:* Gyan Mishra <[email protected]> > *Sent:* Thursday, January 6, 2022 7:52 PM > *To:* DECRAENE Bruno INNOV/NET <[email protected]> > *Cc:* Aijun Wang <[email protected]>; Christian Hopps < > [email protected]>; Greg Mirsky <[email protected]>; Hannes Gredler < > [email protected]>; Les Ginsberg (ginsberg) <[email protected]>; Peter > Psenak <[email protected]>; Robert Raszuk <[email protected]>; Shraddha > Hegde <[email protected]>; Tony Li <[email protected]>; lsr <[email protected] > > > *Subject:* Re: [Lsr] BGP vs PUA/PULSE > > > > > > Hi Bruno > > > > As far as BGP PIC (edge) it is completely orthogonal to summarization > framework the PUA/PULSE solutions is addressing. > > [Bruno] Not completely because BGP PIC edge relies on the presence of a > FIB structure specific to each BGP next-hop (typically loopback when BGP > next-hop self is used) > > > > 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. > > [Bruno] I was referring to BGP PIC edge on the ingress PE. Please refer to > iPE in > https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-bgp-pic-17#section-2.2 > > > > King regards, > > --Bruno > > > > 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 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
