IETF Logo Mail Archive

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

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Tue, 08 November 2016 17:02 UTC

Return-Path: <jheitz@cisco.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 24DAB129619 for <idr@ietfa.amsl.com>; Tue, 8 Nov 2016 09:02:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.018
X-Spam-Level:
X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 LKSh5Elytr4k for <idr@ietfa.amsl.com>; Tue, 8 Nov 2016 09:02:43 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E7912956C for <idr@ietf.org>; Tue, 8 Nov 2016 09:02:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2204; q=dns/txt; s=iport; t=1478624562; x=1479834162; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KyKxdE2xqd8+oQWr+3R/5P1waxDelRDdBsO3JFEXiwc=; b=dEQVQsnpl6+8nMQuQW0p29aHr8Lof8up4MmvXXxeidEJCsLSKOn+ruaV chWEoQT1Ok3xQ5P6tw0P35Pmwai3fd9eDC+cPWwt09W7+n6yhim6T+KAo eBQR01KVyBaSKqOnfyUNYl2jn8X/HzPw7twyi2TESG4Tu+mkW8dwT1QjH E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AVAQD1AyJY/5BdJa1dGQEBAQEBAQEBAQEBBwEBAQEBgy8BAQEBAR+BV405lwWUU4IIhiQCgg8/FAECAQEBAQEBAWIohGEBAQEDATotEgULAgEIGB4QMiUBAQQOBRQFiDsItHKLSgEBAQEBAQEBAQEBAQEBAQEBAQEBARyGPoF9glqESIMxgi8Fmi8BiUCHB4FujiaHMoV+hAUBHjd6hSpyhH4GgjYBAQE
X-IronPort-AV: E=Sophos;i="5.31,462,1473120000"; d="scan'208";a="344095925"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2016 17:02:41 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uA8H2f0c003428 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Nov 2016 17:02:41 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 8 Nov 2016 11:02:40 -0600
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Tue, 8 Nov 2016 11:02:40 -0600
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Job Snijders <job@instituut.net>
Thread-Topic: [Idr] Review of draft-ietf-large-community-06
Thread-Index: AdI5iIlDv+X8FqL1SIqxamyskn+T7wAXKyIA///5aAI=
Date: Tue, 08 Nov 2016 17:02:40 +0000
Message-ID: <658B78AB-70F9-43CB-B2FA-2A14ACC6A273@cisco.com>
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28F2A4BDA@SZXEMA510-MBX.china.huawei.com>, <20161108112616.GD2473@Hanna.local>
In-Reply-To: <20161108112616.GD2473@Hanna.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/DNXBxouigJ-3PLfYvgaxpolNSvE>
Cc: IETF IDR WG <idr@ietf.org>
Subject: Re: [Idr] Review of draft-ietf-large-community-06
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: Tue, 08 Nov 2016 17:02:44 -0000

> On Nov 8, 2016, at 3:26 AM, Job Snijders <job@instituut.net> wrote:
> 
>> On Tue, Nov 08, 2016 at 06:22:54AM +0000, Mach Chen wrote:
>> 
>> Section 2, the last sentence:
>> "A receiving speaker SHOULD silently remove duplicate Large BGP
>> Communities from a BGP UPDATE message."
>> 
>> IMHO, whether remove the duplicate communities from a BGP UPDATE
>> message is not significant, since the life of the message is over once
>> the message processed.

That's not what happens. After a route is originated, it passes through many BGP speakers and typically ends up in most routing tables on earth. Each speaker that sees the route may or may not interpret all the communities and may or may not propagate the communities. However, any BGP speaker that receives a community attribute SHOULD remove duplicate communities before propagating the attribute. Also any BGP speaker is free to propagate communities in a different order than it received them.

What actually happens in two code bases that I have worked on: A receiving speaker will sort the received communities and remove duplicates. This happens even if the receiving speaker simply propagates the communities without interpretation. This applies to legacy communities and the same behavior is carried on in my large community code.


>> The key point is that the receiving speaker
>> should ignore the duplicate Large BGP Communities. 
>> 
>> How about:
>> 
>> "A receiving speaker SHOULD silently ignore the duplicate Large BGP
>>   Communities within a Large BGP Communities attribute. "
> 
> After the latest round of review from Geoff Huston and Jakob Heitz the
> following text was produced.
> 
> The below text is queued to be in -07 of the draft, but -07 can't be
> posted yet as we are in the 'cutoff' period before the IETF meeting in
> Seoul.
> 
> """
>    Duplicate BGP Large Community values SHOULD NOT be transmitted. A
>    receiving speaker SHOULD silently remove duplicate BGP Large
>    Community values from a BGP Large Community attribute.
> """
> 
> I think the above text aligns with your suggestion, right?


Thanks,
Jakob.

v2.23.0 | Report a Bug | By Email