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

Hi folks,

Another sad outcome of having multiple ASes united into a single
administrative domain is a longer AS_PATH which includes all OAD ASNs. On
the one hand, it's perilous to crop arbitrary ASN from the AS_PATH, but on
the other hand, sometimes longer AS_PATH values cause a lot of pain.

пн, 13 мар. 2023 г. в 21:06, UTTARO, JAMES <ju1738@att.com>:

> *Robert, *
>
>
>
> *eBGP-OAD sessions would by default propagate all non-transitive
> attributes that exist and ones created in the future.  As operators we will
> decide which ones we would like to see disseminated across our
> administrative domains.. *
>
>
>
> *Thanks,*
>
> *          Jim Uttaro*
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* Monday, March 13, 2023 12:51 PM
> *To:* Alvaro Retana <alvaro.retana@futurewei.com>
> *Cc:* idr@ietf.org; draft-uttaro-idr-bgp-oad@ietf.org
> *Subject:* Re: [Idr] One Administrative Domain using BGP (Fwd: I-D
> Action: draft-uttaro-idr-bgp-oad-00.txt)
>
>
>
> 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 <alvaro.retana@futurewei.com>
> 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.
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>