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 for IGP FRR > to occur, which
means it cannot be more aggressive than worst case link protection
mechanisms for the links which
may be used to reach the multi-hop destination.
Not quite.
Your and Chris comment is correct when both links connecting such PE
would be having the same metric and would be equal class citizens as
far as IGP connectivity to PE.
This is however not the case I am presenting.
To illustrate further:
Good link PE-P has BFD timbers 10 ms x 3 = 30 ms
Bad link has timers 2 s x 3 = 6 sec detection.
Good link is always preferred IGP wise.
So when bad link fails and good link is ok - no false positive is
triggered.
When good link fails multihop session must be just slower then this
link so it's timers would be 20 ms x 3 = 60 ms.
When bad link remains the only one active multihop will detect the PE
down 100 times faster !
But this would affect multi-hop BFD as well as single hop BFD.
Not if multihop BFD is going to RP/RE. Perhaps some vendors can
handle it on LCs.
And, I would argue, your issue is really with the vendor who ships
such a product which
has a serious functionality gap.
I would not be that fast. PEs today are compute nodes and I am yet to
see distributed BFD supported on the NICs.
Many thx !
Robert
On Sun, Jul 17, 2022 at 6:57 PM Les Ginsberg (ginsberg) <
[email protected]> wrote:
Robert –
I continue to be a bit unclear on the relevance of the points you
are making.
And I do want to express my agreement with the points Peter and
Chris have made.
In that vein, some top posted comments.
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 for IGP FRR to
occur, which means it cannot be more aggressive than worst case
link protection mechanisms for the links which may be used to
reach the multi-hop destination.
You also seem to be concerned about headless Line Cards
continuing to maintain BFD sessions even after control plane
failures.
But this would affect multi-hop BFD as well as single hop BFD.
And, I would argue, your issue is really with the vendor who
ships such a product which has a serious functionality gap.
Finally, I am not certain you are saying this – but you seem to
be saying that BFD itself does not tell you whether the BFD
client is fully sane. This I agree with – but again it applies to
Multi-hop BFD as well as single hop BFD.
Thanx.
Les
From: Lsr <[email protected]> On Behalf Of Robert Raszuk
Sent: Sunday, July 17, 2022 4:49 AM
To: Christian Hopps <[email protected]>
Cc: Peter Psenak (ppsenak) <[email protected]>; lsr <[email protected]
>
Subject: Re: [Lsr] UPA
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 your
picture is that UPA is not only about signalling that all links
to a node went down.
UPA is also about signalling node down while links are still up -
continue responding to BFD in the line cards.
See what we need here is not a signalling moment when all peers
of PE see all links to it going down. What is really needed is to
signal when such PE can not perform its service function any
more. And that BFD to interfaces will not tell you.
> Why would you do that? In fact you're defeating a fundamental
scaling aspect of link-state protocols here.
Since I have no physical alternative to use as backup other then
crappy carrier's backup link.
> Now you have N multi-hop BFDs sessions (one per ABR) running
over the link instead of just *1* session running on that link.
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.
Multihop BFD sessions will tell me that PE is up or down and that
at least one connection to it is still up. That is subtle but
there is an important difference.
> If your (possible multiple sessions of) multi-hop BFD can be
sent over this "slow link" at fast rate X then why not do it just
once using a link local BFD session at the same rate instead?
As described, BFD over a link is not the same as BFD to the
node.
And to project a bigger picture why I asked this ...
If I would do the fast signalling of PE going down in BGP RRs
would likely have some form of detecting PE liveness anyway.
Multihop BFD could be one such option. So I was thinking
if the same can be done with IGP detection wise.
Note also that there are folks who do recommend PE to PE full
mesh of BFD. That orders of magnitude more BFD sessions then
within an area.
Many thx,
R.
On Sun, Jul 17, 2022 at 8:48 AM Christian Hopps <
[email protected]> wrote:
Robert Raszuk <[email protected]> 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 comment to reflect in any way on them one way
or the other.
On a more fundamental level though, I don't see why Peter's
answers are not sufficient here. In particular, unless I am
misunderstanding your scenario it seems ... unrealistic --
but maybe I've missed something.
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. Why would you do that?
In fact you're defeating a fundamental scaling aspect of
link-state protocols here. Now you have N multi-hop BFDs
sessions (one per ABR) running over the link instead of just
*1* session running on that link.
If your (possible multiple sessions of) multi-hop BFD can be
sent over this "slow link" at fast rate X then why not do it
just once using a link local BFD session at the same rate
instead?
If you configure the "down-detect" timer to a slow rate, then
it'll be slow detecting the link down. It's sort of
tautological, right?
Thanks,
Chris.
>
> Cheers,
> R.
>
>
> On Thu, Jul 7, 2022 at 2:43 PM Peter Psenak <
[email protected]>
> wrote:
>
> Robert,
>
> people know how to tune IGPs for faster convergence.
They may or
> may do,
> it's their decision based on their requirements. BFD is
a
> standard
> mechanism used by IGPs for fast detection of the
adjacency loss.
> I see
> no reason to require anything more or special for the
UPA.
>
> thanks,
> Peter
>
> On 07/07/2022 14:28, Robert Raszuk wrote:
> > Peter,
> >
> > I think you are still not clear on some deployment
scenarios.
> >
> > So allow me to restate ...
> >
> > It is pretty often (if not always) a valid
requirement to
> redundantly
> > connect your PEs over different physical paths to the
P nodes
> in the area.
> >
> > For simplicity let's assume there are two links (it
could be
> more then
> > two which only makes the situation worse from
perspective of
> UPA).
> >
> > One link belongs to telko A and is clean and solid
BFD runs on
> it and
> > can detect link/peer down in 10s or 100s of
milliseconds. The
> other link
> > is pretty bad (yet is used as backup as there is no
physical
> > alternative) and BFD timers on it are set to 2 sec
probing x 3
> = 6 sec
> > detection of link/peer down.
> >
> > I think we all agree (including Aijun) that you MUST
not
> advertise UPA
> > before you receive all flooding from all adjacent to
failed PE
> nodes -
> > that in the above case may take 6 sec.
> >
> > So I was asking if you see it feasible to run
multihop BFD from
> ABRs to
> > PEs to detect node down much faster then long BFD
timers would
> otherwise
> > permit you to achieve.
> >
> > And it can be just say milliseconds slower then
fastest BFD
> timers so
> > effectively you get much faster detection then
slowest BFD on
> links
> > would expose.
> >
> > That's the real life scenario which I am trying to
map to UPA
> (or in
> > fact also DROID) mechanism.
> >
> > Many thx,
> > Robert
> >
> >
> > On Thu, Jul 7, 2022 at 2:03 PM Peter Psenak <
[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > On 07/07/2022 12:26, Robert Raszuk wrote:
> > > That's true.
> > >
> > > I am pointing out that this in some networks
may be much
> slower then
> > > invalidating the next hops from BGP route
reflectors by
> running
> > *local*
> > > multihop BFD sessions to subject PEs (all
within an
> area).
> > >
> > > So I have a question ... Let's forget about
BGP and RRs
> and just
> > stay
> > > focused on IGP:
> > >
> > > Would it be feasible to trigger UPA on ABRs by
running
> multihop BFD
> > > sessions between ABRs and local area PEs and
not wait
> for PE-P
> > detection
> > > of link down as well as flooding to carry the
> information to ABRs ?
> >
> > I would think running BFD on each individual link
in the
> local area
> > would be a much better solution. And people
already often
> do that.
> >
> > thanks,
> > Peter
> >
> > >
> > > Thx,
> > > R.
> > >
> > >
> > > On Thu, Jul 7, 2022 at 12:18 PM Peter Psenak <
> [email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected] <mailto:
[email protected]>>>
> wrote:
> > >
> > > Robert,
> > >
> > > BGP PIC depends on the IGP convergence. We
are not
> changing
> > any of that
> > > by UPA.
> > >
> > > thanks,
> > > Peter
> > >
> > >
> > > On 07/07/2022 12:02, Robert Raszuk wrote:
> > > > Peter,
> > > >
> > > > All I am saying is that this may be
pretty slow
> if even
> > directly
> > > > attached P routers must way say 6
seconds (3 x 2
> sec BFD)
> > to declare
> > > > peer down.
> > > >
> > > > And that is in contrast to running BFD
from say
> BGP RR to
> > all PEs
> > > in an
> > > > area.
> > > >
> > > > The fundamental point is that in the
case of PUA
> you MUST wait
> > > for all P
> > > > routers to tell you that PE in fact
went down.
> While in
> > case of
> > > > invalidating service routes the first
trigger is
> good enough.
> > > >
> > > > To me this is significant architectural
> difference.
> > > >
> > > > Many thx,
> > > > R.
> > > >
> > > >
> > > > On Thu, Jul 7, 2022 at 11:54 AM Peter
Psenak
> > <[email protected] <mailto:[email protected]>
> > > <mailto:[email protected] <mailto:
[email protected]
> >>
> > > > <mailto:[email protected] <mailto:
> [email protected]>
> > <mailto:[email protected] <mailto:
[email protected]>>>>
> wrote:
> > > >
> > > > On 07/07/2022 11:38, Robert Raszuk
wrote:
> > > > >
> > > > > > there is no such thing.
> > > > >
> > > > > By far away ABR I mean ABR far
away from
> failing PE
> > > connecting local
> > > > > are to the area 0. There can be
number of
> P routers in
> > > between.
> > > >
> > > > ABR has the full visibility of the
local area
> and
> > knows when any
> > > > node or
> > > > prefix becomes unreachable. It is
determined
> by the SPF
> > > computation and
> > > > prefix processing that is triggered
as a
> result of the
> > change
> > > in the
> > > > local area.
> > > >
> > > > thanks,
> > > > Peter
> > > >
> > > > >
> > > > > Let me provide you with an
illustration:
> > > > >
> > > > > PE can be in Honolulu. ABR in
Huston. All
> in one
> > area. For me
> > > > this ABR
> > > > > is far away from PE.
> > > > >
> > > > > On Thu, Jul 7, 2022 at 11:35 AM
Peter
> Psenak
> > > <[email protected] <mailto:
[email protected]>
> > <mailto:[email protected] <mailto:
[email protected]>>
> > > > <mailto:[email protected] <mailto:
> [email protected]>
> > <mailto:[email protected] <mailto:
[email protected]>>>
> > > > > <mailto:[email protected]
> > <mailto:[email protected]> <mailto:
[email protected]
> > <mailto:[email protected]>>
> > > <mailto:[email protected] <mailto:
[email protected]>
> > <mailto:[email protected] <mailto:
[email protected]>>>>>
> wrote:
> > > > >
> > > > > Robert,
> > > > >
> > > > > On 07/07/2022 11:25, Robert
Raszuk
> wrote:
> > > > > > Hi Peter,
> > > > > >
> > > > > > > Section 4:
> > > > > > >
> > > > > > > "The intent of UPA is
to provide
> an event
> > driven
> > > signal
> > > > of the
> > > > > > > transition of a
destination
> from
> > reachable to
> > > > unreachable."
> > > > > >
> > > > > > That is too vague.
> > > > >
> > > > > it's all that is needed.
> > > > >
> > > > > >
> > > > > > I am asking how you
detect that
> transition on a
> > > far away ABR.
> > > > >
> > > > > there is no such thing. The
detection
> is done
> > based on
> > > the prefix
> > > > > transition from reachable to
> unreachabile in a
> > local
> > > area by
> > > > local
> > > > > ABRs.
> > > > > Remote ABRs just propagate
the UPA.
> > > > >
> > > > > thanks,
> > > > > Peter
> > > > >
> > > > > >
> > > > > > For example, are you
tracking
> flooding on
> > all links to
> > > > subject PE
> > > > > from
> > > > > > all its neighbours and
only when
> all of them
> > remove
> > > that
> > > > link from
> > > > > > topology you signal PUA ?
> > > > > >
> > > > > > If so practically such
trigger may
> be pretty
> > slow and
> > > > > inconsistent as in
> > > > > > real networks as links
over which
> PEs are
> > connected are
> > > > often of a
> > > > > > very different quality,
coming from
> different
> > > carriers and may
> > > > > have for
> > > > > > stability varying BFD
timers. So
> here you
> > would have to
> > > > wait for the
> > > > > > slowest link to be
detected on the
> > neighbouring P
> > > router
> > > > as down.
> > > > > >
> > > > > > Thx,
> > > > > > R.
> > > > > >
> > > > > > On Thu, Jul 7, 2022 at
10:16 AM
> Peter Psenak
> > > > <[email protected] <mailto:
[email protected]>
> > <mailto:[email protected] <mailto:
[email protected]>>
> > > <mailto:[email protected] <mailto:
[email protected]>
> > <mailto:[email protected] <mailto:
[email protected]>>>
> > > > > <mailto:[email protected]
> > <mailto:[email protected]> <mailto:
[email protected]
> > <mailto:[email protected]>>
> > > <mailto:[email protected] <mailto:
[email protected]>
> > <mailto:[email protected] <mailto:
[email protected]>>>>
> > > > > > <mailto:[email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected] <mailto:
[email protected]
> >>
> > <mailto:[email protected] <mailto:
[email protected]>
> > > <mailto:[email protected] <mailto:
[email protected]
> >>>
> > > > <mailto:[email protected] <mailto:
> [email protected]>
> > <mailto:[email protected] <mailto:
[email protected]>>
> > > <mailto:[email protected] <mailto:
[email protected]>
> > <mailto:[email protected] <mailto:
[email protected]>>>>>>
> wrote:
> > > > > >
> > > > > > Robert,
> > > > > >
> > > > > > On 06/07/2022 15:07,
Robert
> Raszuk wrote:
> > > > > > > Hi Peter,
> > > > > > >
> > > > > > > Can you please
point me in
> the draft
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt
> > <https://www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>
> > >
> > <https://www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>
> > > >
> > >
> > <https://www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>
> > > > >
> > > >
> > >
> > <https://www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>>
> > > > > >
> > > > >
> > > >
> > >
> > <https://www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>
<https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
>
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>>>
> > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > <https://www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>
<https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>>
> > > > > >
> > > > >
> > > >
> > >
> > <https://www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>
<https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
https://
> www.ietf.org/id/
> draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
https://
> www.ietf.org/id/
>
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>>>>
> > > > > >
> > > > > > > to some section
which
> specifies based
> > on exactly
> > > > what network
> > > > > > flooding
> > > > > > > changes UPA will
be
> generated by ABRs ?
> > > > > >
> > > > > > Section 4:
> > > > > >
> > > > > > "The intent of UPA is
to
> provide an
> > event driven
> > > > signal of the
> > > > > > transition of a
destination
> from
> > reachable to
> > > > unreachable."
> > > > > > >
> > > > > > > I think such text
is not an
> > implementation
> > > detail,
> > > > but it is
> > > > > > critical
> > > > > > > for mix vendor
> interoperability.
> > > > > > >
> > > > > > > Can UPA also be
generated by
> P node(s) ?
> > > > > >
> > > > > > only if they are ABRs
or ASBRs.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Specifically I was
looking
> to find some
> > > information on
> > > > > how do you
> > > > > > >
achieve assurance that UPA
> really
> > needs to
> > > be generated
> > > > > when using
> > > > > > > various vendor's
nodes with
> very
> > different
> > > flooding
> > > > behaviours
> > > > > > and when
> > > > > > > subjects PEs may
have a
> number of
> > different
> > > links
> > > > each with
> > > > > > different
> > > > > > > node/link down
detection
> timer ?
> > > > > >
> > > > > > sorry, I don't
understand the
> above.
> > > > > >
> > > > > > thanks,
> > > > > > Peter
> > > > > >
> > > > > > >
> > > > > > > Many thx,
> > > > > > > R.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
>
>
> _______________________________________________
> Lsr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lsr
