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> Tue, 09 May 2023 18:38 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 B3318C151532; Tue, 9 May 2023 11:38:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Ik8JUR_wB8Pf; Tue, 9 May 2023 11:38:12 -0700 (PDT)
Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 4E184C14CE4B; Tue, 9 May 2023 11:38:12 -0700 (PDT)
Received: by mail-qv1-xf2a.google.com with SMTP id 6a1803df08f44-61b60d0c5b8so29619746d6.0; Tue, 09 May 2023 11:38:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683657491; x=1686249491; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RRwQDxWPLijvW3iLNWp3gg7XFIufbUgcb4M5kCZ4IlQ=; b=pGl5XgGDMOpyYKN5QkpFc0yjry7wy8+eqXit1n3B4xN8+1fSr28gj1kmEWHptpP3rp +i8tOgcdXM8I5BgiL6CE5C0dBMphWtreeSymIeY5xFI2pUfGKWRbJILXT+pRTnWVhAUF tP4NLtA7rIiNG7t8FBgZCVDRv93F/l0pUzsX/VSRGRX6E9Q44qR/n0Enlw3x/JCXAQbG WmDYMsBUPuDxLknrpTW50gSyvF9b44CVRbXBZ0v+TqCC+VldAwY8T8HAhY3U8S92mQDw dF0H20rdjGHxchwryT7oubT9s6JpPpPddQkMThhT0u8cLl79Y++CU4Mt4oDpT6qa2llK NyzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683657491; x=1686249491; 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=RRwQDxWPLijvW3iLNWp3gg7XFIufbUgcb4M5kCZ4IlQ=; b=fpW+4GC+xfJlh+Pr6nr1cUVkwDMR9dXqyMGw6VZoYWJf9zEwkkvNINCyVMLRta7suU r+TbrlV+6iUzfReEmQF16dGl8B9h9YwdDu1XxMoWHuQSdLCHh9Yf8EsCddUOyzROgfan wClb2ufrMCZichoPKaPbEiiRaLhWplO3W8RGixpgvFEN1mHHRaga0ic8EXd4OPZhGrTj wn6EfnZKCEslTlxZw/eENi/DBCUa6v2HAsFncXb0aMsOuENj9Fcunuru9OxTdzt7VTQ+ gwpXs63SPk474uoTSkOyeJt7b1G5kCv+C/9ReRNgrVstFa0kYVgafRS3JNZ9bh8fIGwI 1BsQ==
X-Gm-Message-State: AC+VfDxKRqUk8VX27qV/kryxX9xd5wfrg25ohZHvBtJhT6hlUHRgYKtN hg0MgGD1IsqegxA9oTmDD9dI9wbndShbt1KWEUEmjRj5DQE=
X-Google-Smtp-Source: ACHHUZ50sbI1vyXOsDREkhOghQq2a7tKqn2HHtMJLN/iRP/LRzPGtY4zJfzs7PYWiVWicFUyYSiL0/nrvBVTuzX2upk=
X-Received: by 2002:a05:6214:301a:b0:621:265e:f724 with SMTP id ke26-20020a056214301a00b00621265ef724mr9638625qvb.17.1683657491203; Tue, 09 May 2023 11:38:11 -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> <CAPF+HwU9J6r71iCs5U7e+AcT5uu4OF1V-7Qw=7rU0kG196XY=A@mail.gmail.com> <etPan.645502b4.2b7e94d7.b220@futurewei.com>
In-Reply-To: <etPan.645502b4.2b7e94d7.b220@futurewei.com>
From: Donatas Abraitis <donatas.abraitis@gmail.com>
Date: Tue, 09 May 2023 21:37:59 +0300
Message-ID: <CAPF+HwVR4bJ_BHEgEN8R4B5tVyS--XKn345NHyzS7-HmGvq4fQ@mail.gmail.com>
To: Alvaro Retana <alvaro.retana@futurewei.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>, "UTTARO, JAMES" <ju1738@att.com>, Robert Raszuk <robert@raszuk.net>, "draft-uttaro-idr-bgp-oad@ietf.org" <draft-uttaro-idr-bgp-oad@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000afcc3305fb470ede"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/9Y7_daI7h9m-sXQFk_XdttsWSw4>
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: Tue, 09 May 2023 18:38:12 -0000

Also, I see that COMMUNITY/EXTCOMMUNITY attribute is defined on how to
handle them for BGP-AOD sessions, but not for LARGE-COMMUNITY. Or am I
missing something?

On Fri, May 5, 2023 at 4:20 PM Alvaro Retana <alvaro.retana@futurewei.com>
wrote:

> Donatas:
>
> Hi!
>
> My first reaction is that we want to keep the per-AS uniqueness, at least
> as we’re defining the per-session behavior.
>
> Making the BGP ID unique across the OAD, vs within an AS, sounds more like
> tightening the requirement (making it harder) than “relaxing” it.  ;-)
>
> In either case, I’ll add it to the list of items to consider for the next
> version.
>
> Thanks for bringing it up!
>
> Alvaro.
>
> On May 5, 2023 at 2:44:29 AM, Donatas Abraitis (donatas.abraitis@gmail.com)
> wrote:
>
> 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?
>
>

-- 
Donatas

v2.23.0 | Report a Bug | By Email