IETF Logo Mail Archive

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

Jeffrey Haas <jhaas@pfrc.org> Thu, 16 March 2023 13:38 UTC

Return-Path: <jhaas@pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F54C15C533; Thu, 16 Mar 2023 06:38:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Br1qgcBmQJg9; Thu, 16 Mar 2023 06:38:18 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A8727C14CE5D; Thu, 16 Mar 2023 06:38:18 -0700 (PDT)
Received: from smtpclient.apple (104-10-90-238.lightspeed.livnmi.sbcglobal.net [104.10.90.238]) by slice.pfrc.org (Postfix) with ESMTPSA id 7AE061E037; Thu, 16 Mar 2023 09:38:17 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D343412E-DDBB-4AE7-8DAD-4378B26DBC1D"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <CAPF+HwWxXt5Ly9d=DHjk4d1DUh4wC8qifm5dwuTiJ=uO5uENuA@mail.gmail.com>
Date: Thu, 16 Mar 2023 09:38:16 -0400
Cc: Nick Hilliard <nick@foobar.org>, Robert Raszuk <robert@raszuk.net>, "UTTARO, JAMES" <ju1738@att.com>, Alvaro Retana <alvaro.retana@futurewei.com>, "idr@ietf.org" <idr@ietf.org>, "draft-uttaro-idr-bgp-oad@ietf.org" <draft-uttaro-idr-bgp-oad@ietf.org>
Message-Id: <4B99F20B-2E4C-4881-8B76-DBAA9DB67FFC@pfrc.org>
References: <etPan.640f456e.1281d5e1.245@futurewei.com> <BYAPR11MB32075FB5B3A0B9FF529A19ADC0BF9@BYAPR11MB3207.namprd11.prod.outlook.com> <SJ0PR02MB774487AA8915D597BD6D9914C6BF9@SJ0PR02MB7744.namprd02.prod.outlook.com> <AB52F4C3-053E-4837-AE62-C25719E6BFE8@cisco.com> <SJ0PR02MB7744E0C6101C9162BE224B03C6BF9@SJ0PR02MB7744.namprd02.prod.outlook.com> <CAOj+MMEgixrY9JsKzn8Ab33kfzNpRrFwHLWU7MO-D6YbBrrM=g@mail.gmail.com> <b86f19f5-7f32-353b-f181-dc1f26d09618@foobar.org> <CAOj+MMHV_MR+gxn6rnkrEP-e_oCr7qXBME=DHJAP6N-xgBE=0A@mail.gmail.com> <a0a678f8-6c1c-6612-7e75-dfe35769596e@foobar.org> <CAPF+HwWxXt5Ly9d=DHjk4d1DUh4wC8qifm5dwuTiJ=uO5uENuA@mail.gmail.com>
To: Donatas Abraitis <donatas.abraitis@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/lzi5UW7ilcARqZjRFfmobYtnTWE>
Subject: Re: [Idr] One Administrative Domain using BGP (Fwd: I-D Action: draft-uttaro-idr-bgp-oad-00.txt)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Mar 2023 13:38:20 -0000

Donatas,


> On Mar 16, 2023, at 3:29 AM, Donatas Abraitis <donatas.abraitis@gmail.com> wrote:
> 
> Hi all,
> 
> >Is this going to be transitive or not across the ASN boundary with OAD session ? 
> 
> This draft https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-attribute-announcement-03 <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-attribute-announcement-03> would be a handful in such a situation.

I'd love to see this integrated into core BGP and deployed.  However, it's likely to only be seen if we eventually change it as part of main procedures rather than as an optional extension.


> 
> >We considered the need for a capability from a couple of different points of view, and both resulted in not wanting to require one.
> 
> For instance, BGP role capability does almost the same as it should in this proposal (OAD).

I flagged this as one of the RFCs that need additional comment for OAD for a reason. :-)

-- Jeff

v2.23.0 | Report a Bug | By Email