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, 06 October 2023 06:47 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 87A7CC14CE2F; Thu, 5 Oct 2023 23:47:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 GkoWI9E_LSaE; Thu, 5 Oct 2023 23:47:01 -0700 (PDT)
Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 EF21EC14CE24; Thu, 5 Oct 2023 23:46:57 -0700 (PDT)
Received: by mail-ua1-x933.google.com with SMTP id a1e0cc1a2514c-7abbe1067d1so711332241.0; Thu, 05 Oct 2023 23:46:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696574817; x=1697179617; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yY37d/cyAyTA0fjJMVtZYxpQ9azqoHUGbtHqrEpKtrg=; b=BtZSbsPO4BLKRobyDXDtpKizdmVljBp42drSz9rimLJnaLxGs2pFLS8wzQySU+BKBn +Y+qWksnQ3hNEIkYExQGY7ffDVJmMwRs+c2IZex1GZ57AzAQPyY9mcBlV56vdW8mm57K FZI0Dz6tex/ND/x6SlfvgCPO05O4HBwURxlQshLeztkI2a8+uUuyXaz3H3HjafUz49VM 1u60tPHFXDre0IaTfuhObCy90zUT8ApkHB/jybHfpJAFO72rujdZDKmuzxztJYKZ3SEI +6kcTnsvawM3g8gf84PaXor3nR2cnzOyJlby5UZnegElaUT5+Cbyjecn77n0YMK7zEht acEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696574817; x=1697179617; 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=yY37d/cyAyTA0fjJMVtZYxpQ9azqoHUGbtHqrEpKtrg=; b=aCzRr0VPAkLc+r5yoSQwkDVx45rkHYP6YJiUlz6vm9VF/xJVjcI2xI/EEOTTYmiYdC hCKkUzqYNBwtEhQF4D7CNOtaBHLaQIQ2Z+74qgmwJS4Ta3Ige4keijn3BdNOodPtlugL Dy+lrGOnT2ZMz1pevpXtmabHNaayseGiMrMRUrYi0OEEvGNo6bVt0wY3e0sE0J93wD6H cMz/PyMcLmNOFCuKNd8o79EiGVY4zalqiaEFcpQzATDr/3+d1xKDLMn6vqfK0K5jE9S5 SuPo+e45PK8VMFXV0v/L8NjjYWzTNPORs8zwbv6GkbumP8QnyBkOwe5JpK2BMzoqTXqy HohQ==
X-Gm-Message-State: AOJu0YyTp+cCRtw6Q2kkXJ778CHyEjHAGMn2hmW/MSBFqk89WTFPn42W /oPXkjAvarPljF1Y4fPP5hE3s/+GeuC0pCf28Hc=
X-Google-Smtp-Source: AGHT+IHFyk3F1lEUsybNNVqNUzZ6UwQdxJBaBfBqWjPPwu2oVVTEKAMezhBKT8P1u2s0ArWbpu514+eazoD98QdLud8=
X-Received: by 2002:a05:6102:494:b0:452:9b18:b326 with SMTP id n20-20020a056102049400b004529b18b326mr7378774vsa.10.1696574816781; Thu, 05 Oct 2023 23:46:56 -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> <CAPF+HwVR4bJ_BHEgEN8R4B5tVyS--XKn345NHyzS7-HmGvq4fQ@mail.gmail.com> <etPan.645bd3e1.6dde3a1e.ad5c@futurewei.com> <CAPF+HwVDJ5B9bOy+LDFHHRZP4GBKcC2LiGoM8C4eKLbJNx0Ybw@mail.gmail.com> <CABNhwV0+n2s1gtUSOkT=h86DPvFLdryNF6deAizv8xue0bzqEA@mail.gmail.com>
In-Reply-To: <CABNhwV0+n2s1gtUSOkT=h86DPvFLdryNF6deAizv8xue0bzqEA@mail.gmail.com>
From: Donatas Abraitis <donatas.abraitis@gmail.com>
Date: Fri, 06 Oct 2023 09:46:45 +0300
Message-ID: <CAPF+HwVTt25t_JYh075cM=1ZzpD7xT4Ezwv+2hua894A4N409g@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Alvaro Retana <alvaro.retana@futurewei.com>, Robert Raszuk <robert@raszuk.net>, "UTTARO, JAMES" <ju1738@att.com>, "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="0000000000004a12a60607069b34"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/m6TgC54rQ0cETkXAYg8NTr0WpXY>
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, 06 Oct 2023 06:47:05 -0000

https://datatracker.ietf.org/doc/html/draft-uttaro-idr-bgp-oad#name-summary-table

Aren't columns mixed between IBGP/EBGP? For example, LOCAL_PREF should be
mandatory for IBGP, but it's defined for EBGP as mandatory.

On Thu, May 11, 2023 at 2:09 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> I like the EBGP-OAD peering concept as it solves issue with non transitive
> path attributes can now be transitive within the same admin domain and with
> proliferation of BGP Only  domains RFC 7938 can be even more problematic
> and needs a solution like this to resolve.
>
> Good work by the authors proposing this solution!
>
> On Wed, May 10, 2023 at 1:54 PM Donatas Abraitis <
> donatas.abraitis@gmail.com> wrote:
>
>> Yeah, a table would be great, without guessing to miss something (who
>> implements that) :)
>>
>> On Wed, May 10, 2023 at 8:27 PM Alvaro Retana <
>> alvaro.retana@futurewei.com> wrote:
>>
>>> Hi!
>>>
>>> Large Communities are transitive, so there’s no “special” handling
>>> needed for EBGP-OAD.
>>>
>>> Having said that, we’re planning to include a list of all the attributes
>>> in the next version, with a table, etc.  :-)
>>>
>>> Thanks!
>>>
>>> Alvaro.
>>>
>>> On May 9, 2023 at 11:38:16 AM, Donatas Abraitis (
>>> donatas.abraitis@gmail.com) wrote:
>>>
>>> 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?
>>>
>>>
>>
>> --
>> Donatas
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
>
>
> *M 301 502-1347*
>
>

-- 
Donatas