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 <wangaijun@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 <anupkumart@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.ca@dmarc.ietf.org> wrote:
>
>> Hi Gunter, see [DV]
>>
>>
>>
>> *From: *"Van De Velde, Gunter (Nokia - BE/Antwerp)" <
>> gunter.van_de_velde@nokia.com>
>> *Date: *Thursday, June 16, 2022 at 6:38 AM
>> *To: *Robert Raszuk <robert@raszuk.net>
>> *Cc: *Gyan Mishra <hayabusagsm@gmail.com>, Dan Voyer <
>> daniel.voyer@bell.ca>, "
>> draft-ppsenak-lsr-igp-ureach-prefix-announce@ietf.org" <
>> draft-ppsenak-lsr-igp-ureach-prefix-announce@ietf.org>,
>> draft-wang-lsr-prefix-unreachable-annoucement <
>> draft-wang-lsr-prefix-unreachable-annoucement@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 <robert@raszuk.net>
>> *Sent:* Thursday, June 16, 2022 11:54 AM
>> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) <
>> gunter.van_de_velde@nokia.com>
>> *Cc:* Gyan Mishra <hayabusagsm@gmail.com>; Voyer, Daniel <daniel.voyer=
>> 40bell.ca@dmarc.ietf.org>;
>> draft-ppsenak-lsr-igp-ureach-prefix-announce@ietf.org;
>> draft-wang-lsr-prefix-unreachable-annoucement <
>> draft-wang-lsr-prefix-unreachable-annoucement@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
>
>