Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

[Anup MalenaaDu <[e-mail]>]

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=
[e-mail]> wrote:

> Hi Gunter, see [DV]
>
>
>
> *From: *"Van De Velde, Gunter (Nokia - BE/Antwerp)" <
> [e-mail]>
> *Date: *Thursday, June 16, 2022 at 6:38 AM
> *To: *Robert Raszuk <[e-mail]>
> *Cc: *Gyan Mishra <[e-mail]>, Dan Voyer <[e-mail]>,
> "[e-mail]" <
> [e-mail]>,
> draft-wang-lsr-prefix-unreachable-annoucement <
> [e-mail]>, "[e-mail]" <
> [e-mail]>
> *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 <[e-mail]>
> *Sent:* Thursday, June 16, 2022 11:54 AM
> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) <
> [e-mail]>
> *Cc:* Gyan Mishra <[e-mail]>; Voyer, Daniel <daniel.voyer=
> [e-mail]>;
> [e-mail];
> draft-wang-lsr-prefix-unreachable-annoucement <
> [e-mail]>; [e-mail]
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>