Hi, Greg:
As indicated in the update draft
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10
The motivation behind this draft is for either MPLS LPM FEC binding,
SRv6 etc. tunnel ,or BGP overlay service that are using LPM
forwarding plane where
Hi Aijun,
I cannot figure out how you draw such a conclusion from my comments to
Robert. You may recall that from very early in the discussion, I was not
enthusiastic, to put it lightly, about either of the solutions. Instead, I
believe that multi-hop BFD should be used to monitor the continuity
Then considering both the scalability and possible false negative of BFD based
solution, can we say that the PUA/UPA solution is more preferable?
Best Regards
Aijun Wang
China Telecom
From: lsr-boun...@ietf.org On Behalf Of Greg Mirsky
Sent: Monday, July 18, 2022 8:39 AM
To: Robert
Hi Robert,
top-posting and then my notes in-line under the GIM>> tag:
As mentioned it is still not the same. BFDs on the link tell me that link
is up and part of the line card responder to BFD is alive.
GIM>> I assume you refer to BFD single-hop. Then I have a question What do
you mean by "link is
FWIW, even if you can point to a real example of this bad network
design/operation we should absolutely not feel compelled to design protocols or
solutions to support it.
Thanks,
Chris.
[as wg-member, all my replies were but felt like I should be explicit here]
Christian Hopps writes:
Heh, OK.
When you consider the primary driver for this was this operator that has so
many PEs in each area that they HAVE to use summaries -- otherwise they simply
wouldn't summarize and everything just works! -- except now you have this same
huge operator of this huge network willing to
Because you do not want to destabilize link state protocol. Even in the
area.
You do not want to compute SPF immediately at each link flap.
But you do want to signal to remote guys a hint (remember UPA is a hint not
a solid state) that paths coming with this next hop should be discouraged.
I
I feel like this is so obvious that I must still be misunderstanding you.
Why is it ok for N * multi-hop sessions to run over this crappy-link at
millisecond rates, but *not* ok for a single link local session to do the same?
Thanks,
Chris.
Robert Raszuk writes:
Hi Les,
You seem to be
Hmm
I am not sure I follow what you just said.
1000s of PEs in an area ? Even if so you are worried about 1000s of
multihop BFD sessions to be handled at ABRs ?
But ABRs can be good vendor boxes and offload those 1000s of sessions to
LCs.
I was talking about PEs where they only do less then 10
Robert –
Throughout the discussions of various alternatives to solving this problem we
have been consistently saying that the solution MUST work at scale – up to
thousands of PEs.
That’s because there are customers asking for this.
Les
From: Robert Raszuk
Sent: Sunday, July 17, 2022 1:12
Hi Les,
Your excerpted top posting may not have enough context for everyone to
> easily follow the point being discussed – hopefully that is not the case.
>
Well just trying to respond to the points raised.
*[LES:] Sooo, you apparently think it is OK to declare a node unreachable
> even though
> I believe a lot of the false positive and / or negative issues are helped
with BFD Strict mode.
BFD strict mode is completely irrelevant to this discussion and UPA. At no
point we are here concerned with the interface up event which BFD strict
mode is addressing.
> I agree with Les on the
Hi Les,
> You seem to be suggesting that multi-hop BFD could be more aggressive in
failure detection than single hop BFD in
> the presence of some link with slow single hop BFD timers.
> This makes no sense to me. In order to avoid false failure reports, the
multi-hop BFD session has to allow
I agree with Les on the comments related to BFD.
I believe a lot of the false positive and / or negative issues are helped
with BFD Strict mode.
Thanks
Gyan
On Sun, Jul 17, 2022 at 12:57 PM Les Ginsberg (ginsberg) wrote:
> Robert –
>
>
>
> I continue to be a bit unclear on the relevance of
Hi Christian,
> It seems you saying use multi-hop BFD for fast detection b/c you've gone
and configured one of those same hops along the
> multi-hop path to an incredibly slow link-local BFD rate in comparison to
the BFD multi-hop rate.
Yes. That is exactly the case. What is however missing in
Robert Raszuk writes:
Peter,
In the scenario described there is really nothing to be tuned as you
are limited by the quality of local telco carriers.
Apparently you are not willing to consider it. Thank you.
First, I don't like any of these unreachable things, and so I don't want my
16 matches
Mail list logo
