Re: [Idr] One Administrative Domain using BGP (Fwd: I-D Action: draft-uttaro-idr-bgp-oad-00.txt)

[Alvaro Retana <[e-mail]>]

On March 13, 2023 at 2:15:42 PM, Jeffrey Haas wrote:

Jeff:

Hi!

Thanks for all the comments!  Yes, there’s still significant work to be done — this is just the initial version. ;-)

It is too early to ask for adoption — we will take care of the author list.


Just one specific reply:

> I suspect you're also going to want a mutually exchanged BGP capability to be
> defined that enables this behavior. Minimally you need such mutual
> configuration for this behavior to behave correctly in all of the bypasses in
> the code at the "is this from ebgp" checks we do today. Knowing that it's
> mutually configured means you don't end up with A sending to B something that
> bounces the session or triggering treat-as-withdraw because they're following
> the existing rules.

We considered the need for a capability from a couple of different points of view, and both resulted in not wanting to require one.  Just offering some of our thoughts for discussion (not implying a hard "no"):

- other session types don't require a capability; the local configuration takes care of that [Yes, we need to add more about possible configuration requirements.]

- migration may be easier without a capability, and the type could be changed "on the fly" (+ re-advertisement/refresh)


In all cases, the EBGP-OAD session would be configured towards "internal" (to the OAD) routers.  The failure scenarios do exist, but they would be closer to continuing with an EBGP session (if only one side is configured).  [Yes, we need to finish walking through all the attributes.]


There are tradeoffs.  Either way would work -- what does the WG prefer? 


Alvaro.