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

["Van De Velde, Gunter (Nokia - BE/Antwerp)" <[e-mail]>]

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

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.

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”

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.