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

Mach Chen <mach.chen@huawei.com> Wed, 09 November 2016 02:29 UTC

Return-Path: <mach.chen@huawei.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 4CB601293F8 for <idr@ietfa.amsl.com>; Tue, 8 Nov 2016 18:29:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.718
X-Spam-Level:
X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] 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 EW9q5eV1LFDO for <idr@ietfa.amsl.com>; Tue, 8 Nov 2016 18:29:26 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAF33127071 for <idr@ietf.org>; Tue, 8 Nov 2016 18:29:25 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUU34952; Wed, 09 Nov 2016 02:29:23 +0000 (GMT)
Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Nov 2016 02:29:22 +0000
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.175]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0235.001; Wed, 9 Nov 2016 10:29:18 +0800
From: Mach Chen <mach.chen@huawei.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>, Job Snijders <job@instituut.net>
Thread-Topic: [Idr] Review of draft-ietf-large-community-06
Thread-Index: AdI5iIlDv+X8FqL1SIqxamyskn+T7///zqcAgABd/QD//u534A==
Date: Wed, 9 Nov 2016 02:29:18 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28F2A575C@SZXEMA510-MBX.china.huawei.com>
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28F2A4BDA@SZXEMA510-MBX.china.huawei.com>, <20161108112616.GD2473@Hanna.local> <658B78AB-70F9-43CB-B2FA-2A14ACC6A273@cisco.com>
In-Reply-To: <658B78AB-70F9-43CB-B2FA-2A14ACC6A273@cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.102.135]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.58228A03.01F1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4f7be1e766ba6a8201d281b04e98e920
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/8S-9JVZj1bN4v2KG6luXroeRglI>
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: Wed, 09 Nov 2016 02:29:28 -0000

Hi Jakob,

Thanks for your prompt response!

Please see my reply inline...

> -----Original Message-----
> From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com]
> Sent: Wednesday, November 09, 2016 1:03 AM
> To: Job Snijders
> Cc: Mach Chen; IETF IDR WG
> Subject: Re: [Idr] Review of draft-ietf-large-community-06
> 
> 
> > 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.

Yes, this is true and I agree.

> 
> What actually happens in two code bases that I have worked on: A receiving
> speaker will sort the received communities and remove duplicates. This

This also aligns with my worked codes. But the point is that it does not remove the duplicate values from the received message. The duplicate values should be ignored and dropped.
Normally, a BGP message will be terminated at the receiving speaker, when it needs to send messages to other speakers, the messages are actually new generated ones. Of cause, this is more about implementation details.

I am fine with the new text Job proposed in the upcoming version 07.

Thanks,
Mach

> 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.