Subject: Re: [Sidrops] draft-ietf-sidrops-rov-no-rr

From: Nick Hilliard <[email-masked]>
Date: Sat, 2 Apr 2022 14:20:58 +0100

Randy Bush wrote on 31/03/2022 20:46:
> could we do a wglc on draft-ietf-sidrops-rov-no-rr?

This would be good

Nick

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 6 Apr 2022 13:02:28 -0400

Was there some code already that implements the no -route-refresh bits you
want?
(do we know the implications of doing this at scale?)

On Sat, Apr 2, 2022 at 9:21 AM Nick Hilliard <[email-masked]> wrote:

> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops
>

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Apr 2022 10:28:42 -0700

> Was there some code already that implements the no -route-refresh bits you

ios/xr.  jakob did it as soon as he saw the draft.

> (do we know the implications of doing this at scale?)

we have seen the implications of not doing this at scale.  ask mark
tinka, who was depeered by at&t.

as to implications of deploying, you may find section 5. Operational
Recommendations helpful.

randy

---

From: Job Snijders <[email-masked]>
Date: Thu, 7 Apr 2022 15:44:24 +0200

Hi all,

I'd like to start off by offering my compliments to the creators of this
useful concept. I also appreciate the generosity of making the
specification available through the IETF process rather than the US
patent office! :-)

As this Internet-Draft doesn't have an "interopability aspect", rather,
it describes an implementation aspect not visible to external parties,
building an interop matrix doesn't seem applicable.

On Wed, Apr 06, 2022 at 10:28:42AM -0700, Randy Bush wrote:
> > Was there some code already that implements the no -route-refresh
> > bits you want?
> 

Small request for clarification: you mean IOS XR and vanilla IOS? Or IOS
XE?

> tinka, who was depeered by at&t.

Agreed on this being a problem at scale. At a previous employer we also
ended up inadvertently imposing significant strain on neighboring BGP
networks by virtue of sending out ROUTE REFRESH messages more often than
strictly needed. We received various complaints from EBGP peers because
of this. The situation was somewhat ameliorated by running the
validation process three times an hour (rather than every minute, or
even every 10 minutes), but utimately the solution was to instantiate a
fully populated Adj-RIB-In for each EBGP peer. As the I-D mentions,
enabling 'soft-reconfiguration inbound always' (or its equivalent) can
pose a challenge in resource constrained environments.

Other than some editorial polishing, I think this draft is good to
proceed in the publication pipeline.

Kind regards,

Job

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 7 Apr 2022 16:00:40 -0400

(catching back up)

> tinka, who was depeered by at&t.
It also seems that Arrcus has implemented this feature in their stack.
thanks to them for replying :)