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

Jeffrey Haas <jhaas@pfrc.org> Mon, 11 July 2022 19:56 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 E432EC14F75F; Mon, 11 Jul 2022 12:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable 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 KHT16RZVQSQB; Mon, 11 Jul 2022 12:56:55 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 65F7BC18872F; Mon, 11 Jul 2022 12:56:55 -0700 (PDT)
Received: from smtpclient.apple (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id F36101E34B; Mon, 11 Jul 2022 15:56:53 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2234EA37-109F-40A2-BF22-32AEAAFE0F6D"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <52B1B5E4-ABF6-40DC-8BD4-875A613B8068@cisco.com>
Date: Mon, 11 Jul 2022 15:56:53 -0400
Cc: Robert Raszuk <robert@raszuk.net>, "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>
Message-Id: <8826B995-4044-4706-9165-2A10C6271315@pfrc.org>
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> <CAOj+MMExYuXfPAjkZkgdTFPPfuMNPxFXtO0inUgZKZetCzbU=g@mail.gmail.com> <52B1B5E4-ABF6-40DC-8BD4-875A613B8068@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zixMizLf0fnzOw2Q1DbsiBM-JTY>
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 19:57:00 -0000

Acee,

The following sentence in 4.4.2 is in error and should be deleted:

   If the semantics of a given Atom is undefined for the community in
   question, this Atom MUST be ignored.

I'll queue the change for this for -09 for when the draft submission window re-opens.

-- Jeff



> On Jul 11, 2022, at 9:51 AM, Acee Lindem (acee) <acee@cisco.com> wrote:
> 
> Hi Robert,
>  
> From: Robert Raszuk <robert@raszuk.net>
> Date: Monday, July 11, 2022 at 9:31 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,
>  
> 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. 
>  
> Good point.
>  
> 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 agree. I guess this would also be true in the exclude case that it would be better to exclude at least the routes for the understood atoms. Would it make sense to note that this should be logged (subject to rate-limiting)?
>  
> 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. 
>  
> I certainly agree if it can’t be parsed and I can accept similar behavior if it is unrecognized. My comment was more toward why unrecognized atoms didn’t result in ignoring the wide community (as discussed above). I can see the distinction of the parameters applying to the community actions and not recognizing one would dictate ignoring the community.
>  
> Thanks,
> Acee
>  
>  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 <mailto:acee@cisco.com>> wrote:
>> Hi Robert, Jeff,
>>  
>> From: Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
>> Date: Monday, July 11, 2022 at 8:09 AM
>> To: Acee Lindem <acee@cisco.com <mailto:acee@cisco.com>>
>> Cc: Jeff Haas <jhaas@pfrc.org <mailto:jhaas@pfrc.org>>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org <mailto:40cisco.com@dmarc.ietf.org>>, "draft-ietf-idr-wide-bgp-communities@ietf.org <mailto:draft-ietf-idr-wide-bgp-communities@ietf.org>" <draft-ietf-idr-wide-bgp-communities@ietf.org <mailto:draft-ietf-idr-wide-bgp-communities@ietf.org>>, IDR List <idr@ietf.org <mailto:idr@ietf.org>>, Routing Directorate <rtg-dir@ietf.org <mailto: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?
>>  
>>  
>> <image001.png>
>>  
>> 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.
>>