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
