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

James,

Looks like my reading of the document wasn't careful enough. Despite from
one point of view collapsing all OAD's ASN into a single on the edge may
solve some problems, I don't think that's a good idea. At first, I wasn't
sure about the intention of this draft on this point. So there aren't any
limiting concerns from my side now.

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

> *Igor,*
>
>
>
> *          We still have all the ASNs today. Are you suggesting we
> collapse them all into one AS ? There are significant obstacles to going in
> that direction.. Not sure I understand the concern is there a limit that
> you are suggesting? What is the pain point(s)?*
>
>
>
> *Thanks,*
>
> *          Jim Uttaro*
>
>
>
> *From:* Igor Malyushkin <gmalyushkin@gmail.com>
> *Sent:* Monday, March 13, 2023 1:17 PM
> *To:* UTTARO, JAMES <ju1738@att.com>
> *Cc:* Robert Raszuk <robert@raszuk.net>; Alvaro Retana <
> alvaro.retana@futurewei.com>; 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 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
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!BhdT!kE7yvRYMUMeHwyPRQJEBiE7q0vOSiQz9RfAouZt4GdTacv1UkV2Vo6Zwv9g0Pgq7xMO6FOojxoXMEzyCsr8$>
>
>