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 <[email protected]> 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 >> <[email protected]> wrote: >> Hi Gunter, see [DV] >> >> >> >> From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" >> <[email protected]> >> Date: Thursday, June 16, 2022 at 6:38 AM >> To: Robert Raszuk <[email protected]> >> Cc: Gyan Mishra <[email protected]>, Dan Voyer <[email protected]>, >> "[email protected]" >> <[email protected]>, >> draft-wang-lsr-prefix-unreachable-annoucement >> <[email protected]>, "[email protected]" >> <[email protected]> >> 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: >> >> No summarization at all at ABRs >> Summarize on ABR all prefixes that can be summarized >> Summarize all prefixes that are not associated with PEs and remain >> advertising individual PE addresses >> 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 <[email protected]> >> Sent: Thursday, June 16, 2022 11:54 AM >> To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email protected]> >> Cc: Gyan Mishra <[email protected]>; Voyer, Daniel >> <[email protected]>; >> [email protected]; >> draft-wang-lsr-prefix-unreachable-annoucement >> <[email protected]>; [email protected] >> 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 >> [email protected] >> 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
