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

[Robert Raszuk <[e-mail]>]

Also take case of extended community transitiveness which is defined as
function of ASN boundary.

   "It also
   allows one to specify whether a particular community is transitive or
   non-transitive across an Autonomous System (AS) boundary."

Is this going to be transitive or not across the ASN boundary with OAD
session ? One could think single administrative boundary should allow even
non-transitive ECs to be sent, but this is again not defined.

And I am not worried about missing paragraphs. I am worried about solving
such cases going forward.

Personally you could just define not a new session type but a new ASN type:
OAM-ASN (in parallel to existing ASNs) and build plane vanilla  IBGP
sessions.

Best,
R.

On Mon, Mar 13, 2023 at 5:50 PM Robert Raszuk <[e-mail]> wrote:

> Hi,
>
> Not sure what you mean by "allow all". Some BGP attributes are only for
> IBGP and some only for EBGP. With that what does it mean
> considering future protocol extensions ?
>
> Thx,
> R.
>
> On Mon, Mar 13, 2023 at 5:40 PM Alvaro Retana <[e-mail]>
> wrote:
>
>> On March 13, 2023 at 12:09:26 PM, Robert Raszuk wrote:
>>
>>
>> Robert:
>>
>> Hi!
>>
>> > Today a lot of implementations already support features like
>> > next-hop-unchanged on EBGP, or AIGP attribute etc ...
>> >
>> > Would it not be just much cleaner to enumerate explicitly those
>> features on
>> > today's EBGP sessions between ASNs under the same administrative
>> domains ?
>> >
>> > Practical aspect is that while you can define the expected behaviour of
>> OAD
>> > session today - but tomorrow we will likely introduce more BGP protocols
>> > extensions which will not going to be reflected in this OAD document.
>> So it is
>> > going to be really hard to keep track on what sides really intend to do
>> when
>> > declaring on their edge OAD session type.
>> >
>> > IMHO explicitly enabling exceptions for plane EBGP sessions will be far
>> more
>> > practical approach.
>>
>> The intent is for the EBGP-OAD session to "allow all" so that as new
>> extensions are introduces we don't need to update the document. ;-)  For
>> specific applications an operator may want to only propagate certain
>> extensions -- that can be controlled through policy.
>>
>> Any exceptions or different behavior to be called out in the draft should
>> be for specific items only.
>>
>>
>> There are possibly multiple ways to obtain the same (or similar) outcome.
>> :-)
>>
>> Thanks!
>>
>> Alvaro.
>
>