IETF Logo Mail Archive

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

Donatas Abraitis <donatas.abraitis@gmail.com> Fri, 05 May 2023 06:44 UTC

Return-Path: <donatas.abraitis@gmail.com>
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 A5DB8C151984; Thu, 4 May 2023 23:44:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 7HjjyLXMfjde; Thu, 4 May 2023 23:44:15 -0700 (PDT)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C0BC1516EB; Thu, 4 May 2023 23:44:15 -0700 (PDT)
Received: by mail-qk1-x731.google.com with SMTP id af79cd13be357-75131c2997bso849499685a.1; Thu, 04 May 2023 23:44:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683269053; x=1685861053; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=H4dcwugkoO9rjwQoDGyocgcmpLGiQoXuRahVgDZfxMw=; b=jixCWIVF8c6oToKTOZwYSa71xIFA4n+PGQnDu4S00Kg45Z8ALiD+VP2+9p8QzR36t1 ECfMOnCjyTBdCRCLjmCAPYlEA8lsvhrKddyJXI3W+BL0I2pbUJoXKhReYB3ljboVP3aj F9fRM+qki52aWRKhAb/bAxR8iNE8iEXKwS7meUVZrUv7/rF9galLe2N0nEJn434Nr5Gg +KzWeuGhWS2fUbDTHT78QJHK8IDxb4tUG5omTpCELGUCp263OqjkOy7DN4eXtzMiZPZL ymiwLhBA2vKXfURzzGucEERIuDe+/Fx+mQThkuoMhyy6lwZyNYToFUh53R5KoGng8t5C u3IA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683269053; x=1685861053; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=H4dcwugkoO9rjwQoDGyocgcmpLGiQoXuRahVgDZfxMw=; b=O2j0jUiSVNF959WNkTEedei3tXJ1Nfxs+73Af4Wz9kUkylGoQM31ptzGObaeIoKJDr OWexQYeuCGTmca+0FpDZSUAeMnECwRmRf7yDSv4mt2QbSxSDZuJ6KX7+lLxWyLByKYwn X+SRRc7nxQw9JAKQoMhgw+fPFkSoibH6b+QlUwMOHHqyvWaOM74H+8HAJygM2Hgk8OCl YwGNHL+usJ/5eGeaNJCBmhWQ8U3+btnCwyKotQPvSnvxUwesHjb5saLa/L0WjSzUjCGp kiMG0jmJ1bi3Hb2VQGOijzwAsiMuh07+xThbUbcj7tXcI6OpjSpB4OFTkp32D4tLi1VE dOkw==
X-Gm-Message-State: AC+VfDwCq3Pyv7EH8GAZi/xYvdI1RnreFYVT0BO6279Qhp/v27Vjbtek o7mKfJPDiJEmYX94/qgohV8Sa2ruoSHqKHptZ3A=
X-Google-Smtp-Source: ACHHUZ5O5zyRxzGI2uyVZGQtG5k96CbsuTlJSL7PZwwNsNT5SiuklBxgshYH78jvckbc6dZNH5De16r4Ne2hVKNUtlE=
X-Received: by 2002:a05:6214:29c7:b0:56e:c066:3cd2 with SMTP id gh7-20020a05621429c700b0056ec0663cd2mr710631qvb.2.1683269053070; Thu, 04 May 2023 23:44:13 -0700 (PDT)
MIME-Version: 1.0
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> <4B99F20B-2E4C-4881-8B76-DBAA9DB67FFC@pfrc.org>
In-Reply-To: <4B99F20B-2E4C-4881-8B76-DBAA9DB67FFC@pfrc.org>
From: Donatas Abraitis <donatas.abraitis@gmail.com>
Date: Fri, 05 May 2023 09:44:01 +0300
Message-ID: <CAPF+HwU9J6r71iCs5U7e+AcT5uu4OF1V-7Qw=7rU0kG196XY=A@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
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>
Content-Type: multipart/alternative; boundary="000000000000f846fd05faec9dd7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/vudiktboc_8fbXQK3BnycVDVk2A>
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: Fri, 05 May 2023 06:44:15 -0000

Also, I noticed that it's not taken into account how AOD should be handled
together with RFC6286.
If using multiple AS numbers inside a single AOD, BGP Identifier should be
relaxed even more per AOD, not per AS-wide, correct?


On Thu, Mar 16, 2023 at 3:38 PM Jeffrey Haas <jhaas@pfrc.org> wrote:

> 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
> 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
>
>

-- 
Donatas

v2.23.0 | Report a Bug | By Email