IETF Logo Mail Archive

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

Zhuangshunwan <zhuangshunwan@huawei.com> Sat, 05 November 2016 10:29 UTC

Return-Path: <zhuangshunwan@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 23E14129688 for <idr@ietfa.amsl.com>; Sat, 5 Nov 2016 03:29:12 -0700 (PDT)
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 J4r78m7R4A6H for <idr@ietfa.amsl.com>; Sat, 5 Nov 2016 03:29:10 -0700 (PDT)
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 30758129675 for <idr@ietf.org>; Sat, 5 Nov 2016 03:29:10 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZS75684; Sat, 05 Nov 2016 10:29:07 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 5 Nov 2016 10:29:07 +0000
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Sat, 5 Nov 2016 18:28:58 +0800
From: Zhuangshunwan <zhuangshunwan@huawei.com>
To: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] Review of draft-ietf-large-community-06.txt
Thread-Index: AQHSNtOFwS3wa5eAwkW/x/SKbM7wb6DItooAgAAGXICAABu+gIAABBoAgAAJoICAAAXFAIABO1Bw
Date: Sat, 05 Nov 2016 10:28:58 +0000
Message-ID: <19AB2A007F56DB4E8257F949A2FB9858C87AFC6E@NKGEML515-MBX.china.huawei.com>
References: <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> <20161104221030.GD37681@Vurt.lan> <0919e676e12d49d1a2ba30f4acc3b273@XCH-ALN-014.cisco.com> <20161104230536.GJ37681@Vurt.lan>
In-Reply-To: <20161104230536.GJ37681@Vurt.lan>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.86.254]
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.0A090206.581DB474.0023, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d8daaf6d9f8b6e413243f5c8ab079b5c
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/p995F0nDv4S8sOkspz-KnTs0oBk>
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: Sat, 05 Nov 2016 10:29:12 -0000

Hi authors,

I have read this document and it looks good to me!

One comment:

In most of the network operating systems, we must enable neighbor/peer send-community command knob in order BGP speaker include community in routes announcement. 
By default, the BGP speaker does not send/transmit community attributes. Even if the COMMUNITIES path attribute is an optional transitive attribute. This is the current reality application.

So the following case describing in draft-ietf-idr-large-community-06 maybe cannot reflect the reality:
   "Because BGP communities are optional
   transitive BGP attributes, BGP communities may be acted upon or
   otherwise used by routing policies in other Autonomous Systems (ASes)
   on the Internet."

Some customers from IDC/OTT complain that ISPs can not transmit their community attributes, because ISPs do not transmit community attributes in most cases.

Should we clearly define whether LargeCommunity should act different from (or the same with) the RFC1997's Community?

Best Regards,
Shunwan

v2.23.0 | Report a Bug | By Email