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

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<mailto: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<mailto:robert@raszuk.net>>
Sent: Monday, March 13, 2023 12:51 PM
To: Alvaro Retana <alvaro.retana@futurewei.com<mailto:alvaro.retana@futurewei.com>>
Cc: idr@ietf.org<mailto:idr@ietf.org>; draft-uttaro-idr-bgp-oad@ietf.org<mailto: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<mailto: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<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!BhdT!kE7yvRYMUMeHwyPRQJEBiE7q0vOSiQz9RfAouZt4GdTacv1UkV2Vo6Zwv9g0Pgq7xMO6FOojxoXMEzyCsr8$>