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 <wangai...@tsinghua.org.cn> 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 <anupkum...@gmail.com> 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 <daniel.voyer= > 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 <rob...@raszuk.net> >> *Cc: *Gyan Mishra <hayabusa...@gmail.com>, 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-announce”, is describing >> a use case/architecture and what you can do w/ RFC5305/RFC5308 – its >> “informational” 😊 >> >> >> >> G/ >> >> >> >> >> >> *From:* Robert Raszuk <rob...@raszuk.net> >> *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 <hayabusa...@gmail.com>; Voyer, Daniel <daniel.voyer= >> 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 >> >> | | >> >> | | >> >> +--------area#1---ABR#3---area---ABR#4---area#3--------+ >> >> >> >> What if ABR#4 would loose connectivity to egressPE#2 and ABR#2 does not? >> >> In that case ABR#4 will originate a UPA/PUA and ABR#2 does not originate >> a PUA/UPA. >> >> How is ingressPE#1 supposed to handle this situation? The only thing >> ingressPE#1 see is that suddenly there is a PUA/UPA but reachability may >> not have changed at all and remains perfectly reacheable. >> >> >> >> Valid case. But PE1 should only switch when alternative backup path >> exists. If there is a single path it should do nothing in any case of >> receiving UPA. We have discussed that case before and as you know the >> formal answer was "out of scope" or "vendor's secret sauce" :). >> >> >> >> The justification here is that switching to healthy backup is better then >> continue using perhaps semi-sick path. >> >> >> >> Best, >> >> R. >> >> >> ------------------------------ >> >> *External Email:** Please use caution when opening links and attachments >> / **Courriel externe:** Soyez prudent avec les liens et documents joints >> * >> _______________________________________________ >> 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
