Re: [Idr] Routing Directorate Review for draft-ietf-idr-wide-bgp-communities-07 - BGP Community Container

Robert Raszuk <robert@raszuk.net> Mon, 11 July 2022 13:32 UTC

Return-Path: <robert@raszuk.net>
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 8025DC06D18D for <idr@ietfa.amsl.com>; Mon, 11 Jul 2022 06:32:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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=raszuk.net
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 KmOgVZeIhJu4 for <idr@ietfa.amsl.com>; Mon, 11 Jul 2022 06:32:15 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 4AF1FC06B990 for <idr@ietf.org>; Mon, 11 Jul 2022 06:31:28 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id r9so688534lfp.10 for <idr@ietf.org>; Mon, 11 Jul 2022 06:31:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9EKRyFGGUsrKA8341BG7AdP7DDbN4UMmjExwgrnzDLc=; b=OAp8Jhkd8rbwdKTbh+7KE2vVdQ/CQON/NPN0hOrLkGL7TzOKYXqwql2M2JDSWHuGiS 0Z7Dew9JpUbfGKL0elQvQuOzezjVzV5GBjepwmi03zlpNxIbb7+w4UHNX7NmXIdQNmzV SW7dWl5w5+VDlNwOYYw7KK3HoZMy3tDHda1LXSkI8huxQlDn47TdPtU0eWrCc0uo4SNq LRpbE3Ladzdi9FsIPjp628kmHJ+IGpSEQWb9cCn7OVyaGwmlbmxq3jsDPRCxWJiuF6TN CJgwrb06QbDOmKHjqKxZFCAaCpmiW17PqCxv+sOqhfMk/1oz9qOa/dRXYglGexW4c06M 5VWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9EKRyFGGUsrKA8341BG7AdP7DDbN4UMmjExwgrnzDLc=; b=ooEzoiat7w7jKoJnWc7H+8PmEVFMezlM3t4RjWh04DJcLwTMZv9RN1F570iaCuPPO9 xL1HQ+U4oj45hsaTUn9BC62IhA232KSvh8RgmLKUZ3DUMIUDisW/HPkYciinOaRtlF1V mB5v8UMgS7IOyX97BQOlw56Gk8juh/g5fBcXs9iaZIXE8ZJ6MOQKKUG4g84SBBCp3foX /wWpJRtbI3PxVLzCCAOcq+P+gFpPnKHjtDpP9qp9CpHzde4dAc2jeB6x/iRH+axtnA0p qAcwxQjV7WY4+OWzjBBA1/MtoCxKzEafjyeCtKSZ5aiOrKnhvzpb4mebYArx6lPY0eMQ TDDg==
X-Gm-Message-State: AJIora9gxIslOm7HuYF546swMoQpvYk71kgUYSbvzL1/16M1FGjg4rwU kqtbH9jd/F1cFlSfKeQpDkmEorPkLoBwdWlTat9Kno/Hudg=
X-Google-Smtp-Source: AGRyM1uHRfOlZBj9CbdCguJ1WcKt89PEb4CQ3t1OtRogKwYoAPEs4ApA6oKPBYKBKZwmoWMIRoi1sZr1Ixg8hegkhy0=
X-Received: by 2002:a05:6512:e9b:b0:489:e034:cfc9 with SMTP id bi27-20020a0565120e9b00b00489e034cfc9mr2575576lfb.366.1657546284731; Mon, 11 Jul 2022 06:31:24 -0700 (PDT)
MIME-Version: 1.0
References: <31784442-7A03-46E2-B255-7D7FF46FD88F@cisco.com> <20220708195701.GB29763@pfrc.org> <E109F29A-8701-443E-BCFA-14A370E6B736@cisco.com> <CAOj+MMGXCZ674h=XuF0AqV4o0n+-wBVzfpLuihGcQh7VOktaew@mail.gmail.com> <E094DB91-02E5-4C33-82EB-CB3995521589@cisco.com>
In-Reply-To: <E094DB91-02E5-4C33-82EB-CB3995521589@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 11 Jul 2022 15:31:13 +0200
Message-ID: <CAOj+MMExYuXfPAjkZkgdTFPPfuMNPxFXtO0inUgZKZetCzbU=g@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "draft-ietf-idr-wide-bgp-communities@ietf.org" <draft-ietf-idr-wide-bgp-communities@ietf.org>, IDR List <idr@ietf.org>, Routing Directorate <rtg-dir@ietf.org>
Content-Type: multipart/related; boundary="00000000000080398005e387910a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/kIWhdz0CyC9XMA6K9P3XbSlxO6Y>
Subject: Re: [Idr] Routing Directorate Review for draft-ietf-idr-wide-bgp-communities-07 - BGP Community Container
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, 11 Jul 2022 13:32:19 -0000

Hi Acee,

Ok I was not really clear on your comment if it applies to entire diff or
just to the part of "ignoring" elements. Was just trying to show that the
-08 diff shows lots of changes :)

Anyhow to your point. First let's observe that use of any BGP Community is
advisory. We have no mechanism in BGP to force to apply any action on BGP
speaker when receiving given extended, large or wide community. For
standard well-knows there is exception that they will be obeyed but this is
an exception here.

With that being said as Jeff mentioned semantics if target is to match any
so if one implementation does not recognize  one atom type yet can
successfully parse entire community there is no reason why applying partial
match of ANY form would be worse then not applying it at all. That is in
context of Sub-Type 1 section 4.4.1

I am discussing with co-authors if the same applies to 4.4.2 as currently
written. Especially in the light of section 8.2 which stands in contrast to
4.4.2.

On the topic of ignoring entire community section 4.4.3 provides such
example - when parameter is not recognized or not being able to be
correctly parsed.

 For treat as withdraw section 8.1 provides a description. In general when
we can not parse the attribute it should undergo procedures as described in
RFC7606 section 7.14

Many thx,
R.

On Mon, Jul 11, 2022 at 2:17 PM Acee Lindem (acee) <acee@cisco.com> wrote:

> Hi Robert, Jeff,
>
>
>
> *From: *Robert Raszuk <robert@raszuk.net>
> *Date: *Monday, July 11, 2022 at 8:09 AM
> *To: *Acee Lindem <acee@cisco.com>
> *Cc: *Jeff Haas <jhaas@pfrc.org>, "Acee Lindem (acee)" <acee=
> 40cisco.com@dmarc.ietf.org>, "draft-ietf-idr-wide-bgp-communities@ietf.org"
> <draft-ietf-idr-wide-bgp-communities@ietf.org>, IDR List <idr@ietf.org>,
> Routing Directorate <rtg-dir@ietf.org>
> *Subject: *Re: [Idr] Routing Directorate Review for
> draft-ietf-idr-wide-bgp-communities-07 - BGP Community Container
>
>
>
> Hi Acee,
>
>
>
>     Otherwise, we can resume comments vs. the published -08 on Monday.
>
> I'm looking at the version just published - I'm missing any changes here
> in the diff?
>
>
>
>
>
>
>
> Can you be more specific ? The diff shows all of those changes made.
>
>
>
> This why I hate when people who prune my Emails beyond comprehension…. I
> mean specifically the changes relative to my comment on undefined atoms vs
> undefined parameters that immediately preceded my response.
>
>
>
>
>     >    2. It wasn't clear to me why undefined Atoms are ignored and the
> BGP Wide Community
>
>     >       is still used. Similarly, undefined parameters result in the
> BGP Wide Community
>
>     >       being ignored. I think the draft should explain impetus for
> the three error actions –
>
>     >       ignore Atom only, ignore  BGP Wide Community, and treat as
> malformed.
>
>
>
>
>
> Thanks,
>
> Acee
>
>
>
> Thx,
>
> R.
>
>
>