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

Jeffrey Haas <jhaas@pfrc.org> Mon, 13 March 2023 18:15 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 4713DC1522AD; Mon, 13 Mar 2023 11:15:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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_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 IriC5TN41XVM; Mon, 13 Mar 2023 11:15:36 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D2C77C152561; Mon, 13 Mar 2023 11:15:35 -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 E12211E037; Mon, 13 Mar 2023 14:15:34 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_99847369-5669-4F65-BF2F-837CFD43A293"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <etPan.640f456e.1281d5e1.245@futurewei.com>
Date: Mon, 13 Mar 2023 14:15:33 -0400
Cc: "idr@ietf.org" <idr@ietf.org>, "draft-uttaro-idr-bgp-oad@ietf.org" <draft-uttaro-idr-bgp-oad@ietf.org>
Message-Id: <C179E2E2-820A-456C-8766-AD0E5F1E27E2@pfrc.org>
References: <etPan.640f456e.1281d5e1.245@futurewei.com>
To: Alvaro Retana <alvaro.retana@futurewei.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/17K9z9pWy2WWQCI9cq45nb94q48>
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: Mon, 13 Mar 2023 18:15:37 -0000

Alvaro,


> On Mar 13, 2023, at 11:46 AM, Alvaro Retana <alvaro.retana@futurewei.com> wrote:
> 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.

I'll echo a portion of the comments previously mentioned in a different form: Do yourselves a favor and spend the time to enumerate which path attributes from a transitivity standpoint you want to behave as OAD and which don't.

I suspect you're also going to want a mutually exchanged BGP capability to be defined that enables this behavior.  Minimally you need such mutual configuration for this behavior to behave correctly in all of the bypasses in the code at the "is this from ebgp" checks we do today.  Knowing that it's mutually configured means you don't end up with A sending to B something that bounces the session or triggering treat-as-withdraw because they're following the existing rules.

See also inconsistent configuration of confederation boundaries for where we have similar headaches.

RFC 9234 will likely require maintenance to define new roles, or at least where roles are no longer exchanged.

We are also continuing to deal with "attribute leak" as a headache in global BGP.  Scoping ASes are no longer a cleanly viable mechanism for dealing with such attribute leaks in a global fashion.

Similarly at the local level, knowing what ASes as a set are available in an OAD becomes important for some scope checks and not solely whether a neighbor is present.  The example in the draft on MEDs is one example of that.  In confederations, the configuration of the member ASes consistently is the required element.  Something similar will be required for this feature, but with additional fragility: In confederations, when you mess up configuration, the AS_PATH (and sometimes session resets) will show you were the breakage is.  That isn't true here since this isn't manifesting in the AS_PATH.

Personal opinion: I know many of the reasons why this feature is desired.  IMO, making confederations more flexible to accomplish the few pieces of "let the participating ASes show up in global BGP" is a better fix.

Final note: You and Keyur know better about the 5 author limit on the draft.  I strongly suggest the authors agree on where the trim line is before you ask for adoption.  I'm at the point where I'll be asking at rtg-chairs whether we can ask for per-WG author limits during datatracker submission.

-- Jeff




> 
> Thanks in advance!
> 
> 
> Alvaro.
> 
> 
> 
> [1] https://datatracker.ietf.org/doc/html/draft-uttaro-idr-bgp-oad <https://datatracker.ietf.org/doc/html/draft-uttaro-idr-bgp-oad> 
> 
> On March 13, 2023 at 10:38:39 AM, internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> (internet-drafts@ietf.org <mailto: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://datatracker.ietf.org/doc/draft-uttaro-idr-bgp-oad/> 
>> 
>> There is also an HTML version available at: 
>> https://www.ietf.org/archive/id/draft-uttaro-idr-bgp-oad-00.html <https://www.ietf.org/archive/id/draft-uttaro-idr-bgp-oad-00.html> 
>> 
>> Internet-Drafts are also available by rsync at rsync.ietf.org <http://rsync.ietf.org/>::internet-drafts 
>> 
>> 
>> _______________________________________________ 
>> I-D-Announce mailing list 
>> I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org> 
>> https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announce> 
>> Internet-Draft directories: http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html> 
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org <mailto:Idr@ietf.org>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>