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

[Jeffrey Haas <[e-mail]>]

> On Mar 13, 2023, at 2:42 PM, Alvaro Retana <[e-mail]> wrote:
> 
> On March 13, 2023 at 2:15:42 PM, Jeffrey Haas wrote:
> 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.]

The current session types gate on the exchanged AS number to decide the type.  You're now overloading an existing type (different AS numbers) with an additional semantic that can't be derived from existing config.

In the confederation case, you misconfigure one side of the connection, sessions bounce due to unexpected confederation segments on your ebgp session.

In the absence of mutual capability agreement, each side is free to send stuff that will behave poorly if sent to the other side and it isn't appropriately configured.  Minimally it will result in routes being locally suppressed via treat-as-withdraw.  Potentially some implementations may choose to drop the session via notify depending on what is leaked.

In the presence of mutual capability agreement, a half-configured connection at least has the option to locally suppress at advertisement routes that can be problematic.

Capability or no, visible operational state is going to be needed.  I suggest considering what your patches to the IETF and OC YANG modules look like. 

FWIW, this exact discussion will be playing out for the DPATH feature as well.  That case is more dire since inappropriately accepted leaks will cause route selection problems.


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

I love the smell of optimism in the morning.  It usually smells like the char burn of an escalation later on.

Stated a bit more normatively, you better have absolute faith that two implementations will not exchange routes in a half configured state that can result in a notification.  If notifications happen, they will continue bouncing until corrected, just like with confederations. 

> 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.]

See above.

Also, the author list apparently has had enough of the discussions about uses of this behavior between cooperative ASes run by distinct operators.  In such cases you're going to find that there's a desire to permit partial attribute transitivity.

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

This implementor who has a customer in the author list would be telling that customer that they think it's a rather bad idea to have this feature work on "faith" via configuration.  You want the capability.  I don't want the escalation call when things don't behave as gracefully as you hope they do.

-- Jeff