Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
Thanks Aijun. So, in places where BFD can be reasonably deployed, would PUA really help? - Anup On Mon, Jun 20, 2022 at 4:06 PM Aijun Wang wrote: > Hi, Anup: > > The advantage of PUA over BFD is that the operator needs not deploy o(n^2) > BFD sessions for the services that rely on the IGP reachablity. > Such comparisons have been discussed on the list. > > Aijun Wang > China Telecom > > On Jun 18, 2022, at 12:55, Anup MalenaaDu wrote: > > > Hi, > > BGP uses BFD to track the remote PEs. > So, how does PUA really help? > > To be precise, > 1. what are the advantages of having PUAs for IGPs > 2. what are the advantages for services like BGP, Tunnels, LSPs etc going > over IGPs > > Thanks, > Anup > > On Thu, Jun 16, 2022 at 7:41 PM Voyer, Daniel 40bell...@dmarc.ietf.org> wrote: > >> Hi Gunter, see [DV] >> >> >> >> *From: *"Van De Velde, Gunter (Nokia - BE/Antwerp)" < >> gunter.van_de_ve...@nokia.com> >> *Date: *Thursday, June 16, 2022 at 6:38 AM >> *To: *Robert Raszuk >> *Cc: *Gyan Mishra , Dan Voyer < >> daniel.vo...@bell.ca>, " >> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org" < >> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>, >> draft-wang-lsr-prefix-unreachable-annoucement < >> draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org>, "lsr@ietf.org" < >> lsr@ietf.org> >> *Subject: *[EXT]RE: [Lsr] Thoughts about PUAs - are we not >> over-engineering? >> >> >> >> Hi Robert, Peter, Bruno >> >> >> >> You wrote: >> >> “Aas there is no association between node_id (perhaps loopback) and SIDs >> (note that egress can use many SIDs) UPA really does not signal anything >> about SIDs reachability or liveness. “ >> >> >> >> Sure, but UPA signals that a locator is unreachable, would that not >> result for the SRv6 SID to become unreachable as well? >> >> >> >> I understood that UPA have increased value add benefit when using with >> SRv6. If suddenly a locator becomes unreachable, then it I guess the >> associated 128 bit SIDs become unreachable too, causing an event for >> something to happen in the transport network to fix the problem. >> >> >> >> That being said, Peter makes a good point stating that UPA is not solving >> the problem of partitioning areas, and hence, maybe my use-case is not >> overly relevant. >> >> >> >> So progressing, an operator using ABR based summarization then there are >> few options: >> >>1. No summarization at all at ABRs >>2. Summarize on ABR all prefixes that can be summarized >>3. Summarize all prefixes that are not associated with PEs and remain >>advertising individual PE addresses >>4. Summarize all prefixes and use UPA’s to advertise unreachability >>of protected prefixes >> >> >> >> [DV] if “an operator using ABR based summarization” then option 1 is >> out, right ? Also, option 4 is the point of this draft – but furthermore, >> if an aggregation device, inside a domain, is also being summarized – as >> the entire domain get summarized – but this agg device doesn’t have any >> services, because it’s an aggregation device, “then it’s up to the operator >> designing the network to implement” a form of policy/filter. So if that agg >> device reload, due to a maintenance, we don’t care about the unreachability >> advertisement (adding unnecessary LSP in the LSDB). >> >> >> >> We all know that option 1 -3 work well and has been working well for long >> time. Behavior is very well understood >> >> >> >> With the new option 4, to add value, applications need to get what is >> being referenced as ‘vendor secret sauce’ … I can already see the fun >> caused by inconsistent behavior and interop issues due to under >> specification. >> >> [DV] not sure I am following your “secret sauce” point here. Following >> the RFC5305/RFC5308 should be clear. >> >> >> >> The question I remain to have is if the UPA provide higher benefit as the >> tax it introduces. I can see operators suffer due to under specification, >> causing interop and inconsistent behaviors. >> >> >> >> I agree with Bruno’s statement “If you believe that all you need is >> RFC5305/RFC5308 I guess this means that we don't need >> draft-ppsenak-lsr-igp-ureach-prefix-announce” >> >> >> >> [DV] well, “draft-ppsenak-lsr-igp-ureach-prefix-an
Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
Hi, BGP uses BFD to track the remote PEs. So, how does PUA really help? To be precise, 1. what are the advantages of having PUAs for IGPs 2. what are the advantages for services like BGP, Tunnels, LSPs etc going over IGPs Thanks, Anup On Thu, Jun 16, 2022 at 7:41 PM Voyer, Daniel wrote: > Hi Gunter, see [DV] > > > > *From: *"Van De Velde, Gunter (Nokia - BE/Antwerp)" < > gunter.van_de_ve...@nokia.com> > *Date: *Thursday, June 16, 2022 at 6:38 AM > *To: *Robert Raszuk > *Cc: *Gyan Mishra , Dan Voyer , > "draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org" < > draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>, > draft-wang-lsr-prefix-unreachable-annoucement < > draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org>, "lsr@ietf.org" < > lsr@ietf.org> > *Subject: *[EXT]RE: [Lsr] Thoughts about PUAs - are we not > over-engineering? > > > > Hi Robert, Peter, Bruno > > > > You wrote: > > “Aas there is no association between node_id (perhaps loopback) and SIDs > (note that egress can use many SIDs) UPA really does not signal anything > about SIDs reachability or liveness. “ > > > > Sure, but UPA signals that a locator is unreachable, would that not result > for the SRv6 SID to become unreachable as well? > > > > I understood that UPA have increased value add benefit when using with > SRv6. If suddenly a locator becomes unreachable, then it I guess the > associated 128 bit SIDs become unreachable too, causing an event for > something to happen in the transport network to fix the problem. > > > > That being said, Peter makes a good point stating that UPA is not solving > the problem of partitioning areas, and hence, maybe my use-case is not > overly relevant. > > > > So progressing, an operator using ABR based summarization then there are > few options: > >1. No summarization at all at ABRs >2. Summarize on ABR all prefixes that can be summarized >3. Summarize all prefixes that are not associated with PEs and remain >advertising individual PE addresses >4. Summarize all prefixes and use UPA’s to advertise unreachability of >protected prefixes > > > > [DV] if “an operator using ABR based summarization” then option 1 is out, > right ? Also, option 4 is the point of this draft – but furthermore, if an > aggregation device, inside a domain, is also being summarized – as the > entire domain get summarized – but this agg device doesn’t have any > services, because it’s an aggregation device, “then it’s up to the operator > designing the network to implement” a form of policy/filter. So if that agg > device reload, due to a maintenance, we don’t care about the unreachability > advertisement (adding unnecessary LSP in the LSDB). > > > > We all know that option 1 -3 work well and has been working well for long > time. Behavior is very well understood > > > > With the new option 4, to add value, applications need to get what is > being referenced as ‘vendor secret sauce’ … I can already see the fun > caused by inconsistent behavior and interop issues due to under > specification. > > [DV] not sure I am following your “secret sauce” point here. Following the > RFC5305/RFC5308 > should be clear. > > > > The question I remain to have is if the UPA provide higher benefit as the > tax it introduces. I can see operators suffer due to under specification, > causing interop and inconsistent behaviors. > > > > I agree with Bruno’s statement “If you believe that all you need is > RFC5305/RFC5308 I guess this means that we don't need > draft-ppsenak-lsr-igp-ureach-prefix-announce” > > > > [DV] well, “draft-ppsenak-lsr-igp-ureach-prefix-announce”, is describing > a use case/architecture and what you can do w/ RFC5305/RFC5308 – its > “informational” > > > > G/ > > > > > > *From:* Robert Raszuk > *Sent:* Thursday, June 16, 2022 11:54 AM > *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) < > gunter.van_de_ve...@nokia.com> > *Cc:* Gyan Mishra ; Voyer, Daniel 40bell...@dmarc.ietf.org>; > draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; > draft-wang-lsr-prefix-unreachable-annoucement < > draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org>; lsr@ietf.org > *Subject:* Re: [Lsr] Thoughts about PUAs - are we not over-engineering? > > > > Gunter, > > > > (1) Multiple-ABRs > > > > I was wondering for example if a ingress router receives a PUA signaling > that a given locator becomes unreachable, does that actually really signals > that the SID ‘really’ is unreachable for a router? > > > > Aas there is no association between node_id (perhaps loopback) and SIDs > (note that egress can use many SIDs) UPA really does not signal anything > about SIDs reachability or liveness. > > > > For example (simple design to illustrate the corner-case): > > > > ingressPE#1---area#1---ABR#1---area---ABR#2---area#3---egressPE#2 > > | | > > | | > >
