Re: [Idr] Review of draft-ietf-large-community-06.txt

Job Snijders <job@ntt.net> Fri, 04 November 2016 22:10 UTC

Return-Path: <job@ntt.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 9613E1298B7 for <idr@ietfa.amsl.com>; Fri, 4 Nov 2016 15:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.421
X-Spam-Level:
X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665, T_HTML_ATTACH=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-XLY2SNNOGR for <idr@ietfa.amsl.com>; Fri, 4 Nov 2016 15:10:43 -0700 (PDT)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76271298B2 for <idr@ietf.org>; Fri, 4 Nov 2016 15:10:43 -0700 (PDT)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <job@ntt.net>) id 1c2mgz-000Fgf-D5 (job@us.ntt.net); Fri, 04 Nov 2016 22:10:42 +0000
Date: Fri, 4 Nov 2016 23:10:30 +0100
From: Job Snijders <job@ntt.net>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
Message-ID: <20161104221030.GD37681@Vurt.lan>
References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <C2DABF02-D3CB-4646-B869-FBCE5F05FDA1@apnic.net> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <CED07D95-A426-469C-85B4-DB2FBE52D14A@apnic.net> <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com> <40D942F5-0710-46D1-BF09-76C827377479@cisco.com> <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> <20161104195346.GK961@Vurt.local> <20161104201631.GA35942@Vurt.lan> <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="s9fJI615cBHmzTOP"
Content-Disposition: inline
In-Reply-To: <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Ac3B3nEqJQiD3Rf9Q31bjSGmlyM>
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] Review of draft-ietf-large-community-06.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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, 04 Nov 2016 22:10:48 -0000

On Fri, Nov 04, 2016 at 09:55:49PM +0000, Jakob Heitz (jheitz) wrote:
> All good, except one. You added:
> 
>    There is no significance to the order
>    ...
>    of the BGP Large Communities attributes if two or more such
>    attributes are encoded in the BGP path attribute payload of a single
>    BGP Update message.
> 
> This is in conflict with RFC 7606:
> 
>        If any other attribute (whether
>        recognized or unrecognized) appears more than once in an UPDATE
>        message, then all the occurrences of the attribute other than the
>        first one SHALL be discarded and the UPDATE message will continue
>        to be processed.
> 
> I would leave out any mention of multiple attributes.  What this is
> meant to say is that the order of community values within the
> attribute is irrelevant. I put that in, because it has caused
> confusion in the past. I was thinking to add that "a router may
> reorder the community values when forwarding to the next router",
> because this point was the actual source of confusion in more than one
> instance.

Good catch, Ignas provided text to fix it. Attached are rfcdiff & txt.

Can you double check if that confirms your understanding too with regard
to duplicate attributes & duplicate attribute values.

Kind regards,

Job