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

Jim,

If the requirement is continuity of OAD ASNs this is fragile.

Take a simple case of IXP and RS hop for starter. Physically at the data
plane you can claim continuity, but in respect to the control plane you can
not.

I think this is just too much to change here. Cost of OAD as proposed is
way over the benefit - especially if you consider alternative solutions (be
it virtual OAD ASN or Jakob's idea of attribute stack).

Besides I am really not sure what declaring an OAD peer will buy you what
you can not accomplish today already by BGP extensions or by policy
configuration towards your partner's ASN ?

Can you list few functional benefits not possible today ?

Thx,
R.

On Wed, Mar 15, 2023 at 4:23 PM UTTARO, JAMES <ju1738@att.com> wrote:

> *The middle AS is not part of the same administrative authority, so the
> draft does not apply. *
>
>
>
> *Thanks,*
>
> *          Jim Uttaro*
>
>
>
> *From:* Jakob Heitz (jheitz) <jheitz@cisco.com>
> *Sent:* Wednesday, March 15, 2023 8:51 AM
> *To:* UTTARO, JAMES <ju1738@att.com>
> *Cc:* Alvaro Retana <alvaro.retana@futurewei.com>; idr@ietf.org;
> draft-uttaro-idr-bgp-oad@ietf.org
> *Subject:* Re: One Administrative Domain using BGP (Fwd: I-D Action:
> draft-uttaro-idr-bgp-oad-00.txt)
>
>
>
> Somebody surely will.
>
> Regards,
>
> Jakob.
>
>
>
>
>
> On Mar 15, 2023, at 4:09 AM, UTTARO, JAMES <ju1738@att.com> wrote:
>
> 
>
> *Jakob,*
>
>
>
> *          In that case we would not want the attributes transferred as
> the middle AS is not part of the existing OAD. *
>
>
>
> *Thanks,*
>
> *          Jim Uttaro*
>
>
>
> *From:* Jakob Heitz (jheitz) <jheitz@cisco.com>
> *Sent:* Tuesday, March 14, 2023 8:50 PM
> *To:* Alvaro Retana <alvaro.retana@futurewei.com>; idr@ietf.org
> *Cc:* draft-uttaro-idr-bgp-oad@ietf.org
> *Subject:* Re: One Administrative Domain using BGP (Fwd: I-D Action:
> draft-uttaro-idr-bgp-oad-00.txt)
>
>
>
> If two ASes that are part of an OAD are separated by an AS that is not in
> the OAD, then the internal attributes will not be transferred.
>
> Why don't you invent an ATTR_SET?
>
>
>
> Kind Regards,
>
> Jakob
>
>
>
>
>
> *From: *Idr <idr-bounces@ietf.org> on behalf of Alvaro Retana <
> alvaro.retana@futurewei.com>
> *Date: *Monday, March 13, 2023 at 8:47 AM
> *To: *idr@ietf.org <idr@ietf.org>
> *Cc: *draft-uttaro-idr-bgp-oad@ietf.org <draft-uttaro-idr-bgp-oad@ietf.org
> >
> *Subject: *[Idr] One Administrative Domain using BGP (Fwd: I-D Action:
> draft-uttaro-idr-bgp-oad-00.txt)
>
> [Individual Participant]
>
>
>
>
>
> Dear WG:
>
>
>
> We just published a draft [1] to propose a new BGP session type called
> EBGP-OAD.
>
>
>
> As the name suggests, it is a session between two different ASNs that
> belong to the same operator.  Many idr documents call this grouping a
> Single Administrative Domain, we're calling it One Administrative Domain
> (OAD).
>
>
>
> An EBGP-OAD session combines properties of EBGP and IBGP: it is an EBGP
> session with the ability to also announce and receivex IBGP-only or
> non-transitive attributes.
>
>
>
> I'm sure this first version needs some more work, so we would really
> appreciate comments on the list.  We have requested agenda time at IETF
> 116, but, as we all know, that may be tight.
>
>
>
> Thanks in advance!
>
>
>
>
>
> Alvaro.
>
>
>
>
>
>
>
> [1] https://datatracker.ietf.org/doc/html/draft-uttaro-idr-bgp-oad
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-uttaro-idr-bgp-oad__;!!BhdT!nDt32HTdf9KSMoCMKZj-CAKPpy719C7j1R2AeTe5UZQ1OTen2POEiTlVDYds6bjqaAMaZSclBwIy$>
>
>
>
>
> On March 13, 2023 at 10:38:39 AM, internet-drafts@ietf.org (
> internet-drafts@ietf.org) wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> Title : One Administrative Domain using BGP
> Authors : Jim Uttaro
> Avinash Lingala
> Keyur Patel
> Dhananjaya Rao
> Bin Wen
> Alvaro Retana
> Srihari Sangli
> Pradosh Mohapatra
> Filename : draft-uttaro-idr-bgp-oad-00.txt
> Pages : 8
> Date : 2023-03-10
>
> Abstract:
> This document defines a new External BGP (EBGP) peering type known as
> EBGP-OAD. EBGP-OAD peering is used between two EBGP peers that
> belong to One Administrative Domain (OAD).
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-uttaro-idr-bgp-oad/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-uttaro-idr-bgp-oad/__;!!BhdT!nDt32HTdf9KSMoCMKZj-CAKPpy719C7j1R2AeTe5UZQ1OTen2POEiTlVDYds6bjqaAMaZdloB0Mc$>
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-uttaro-idr-bgp-oad-00.html
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-uttaro-idr-bgp-oad-00.html__;!!BhdT!nDt32HTdf9KSMoCMKZj-CAKPpy719C7j1R2AeTe5UZQ1OTen2POEiTlVDYds6bjqaAMaZZw94g5n$>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/i-d-announce__;!!BhdT!nDt32HTdf9KSMoCMKZj-CAKPpy719C7j1R2AeTe5UZQ1OTen2POEiTlVDYds6bjqaAMaZeXERBSL$>
> Internet-Draft directories: http://www.ietf.org/shadow.html
> <https://urldefense.com/v3/__http:/www.ietf.org/shadow.html__;!!BhdT!nDt32HTdf9KSMoCMKZj-CAKPpy719C7j1R2AeTe5UZQ1OTen2POEiTlVDYds6bjqaAMaZWq24Kjw$>
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> <https://urldefense.com/v3/__ftp:/ftp.ietf.org/ietf/1shadow-sites.txt__;!!BhdT!nDt32HTdf9KSMoCMKZj-CAKPpy719C7j1R2AeTe5UZQ1OTen2POEiTlVDYds6bjqaAMaZUEYBZXZ$>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>