Re: [Idr] question about BGP extended community

li zhenqiang <li_zhenqiang@hotmail.com> Tue, 18 April 2017 02:50 UTC

Return-Path: <li_zhenqiang@hotmail.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 3885D12941C; Mon, 17 Apr 2017 19:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.116
X-Spam-Level:
X-Spam-Status: No, score=-1.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 PksHteXnrwv4; Mon, 17 Apr 2017 19:50:45 -0700 (PDT)
Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254037.outbound.protection.outlook.com [40.92.254.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203ED12940E; Mon, 17 Apr 2017 19:50:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Og3xdFKjB5R8wrP4f1VCwGl4nfgm19iZYLItaflnlsg=; b=YccOLj2+S2rCoV45Xl4j8UKgfX+EYUJYbyHO6gL3CvgFXW/3+fyzIwuzOfuiYORN21H/sIjt8rNuBmUyETSIoA2wxRkNCkQ7GO/zAy9+De9e0IB3l3DOSl3ViY8SX1sTU3+quhrNKG8fCcTJTX5rrdBD5Td7ukjFwGAOFStI9B6XpJki2AJIzXj+5wNCY60s40sUdP1ibedWGLrWEUi5ZOzCDZjuhkA0CD6Ua3SgKHjtSByAtJAyLKe/G3lo3HYDwW6FYDA/nr90O4+WNg1yjf+89p+hGCaMX1IUN+nw29qH0UTYrlDN9x4d28s/QrHdUP40SUqi6WNJw7Ua3iClKw==
Received: from PU1APC01FT041.eop-APC01.prod.protection.outlook.com (10.152.252.59) by PU1APC01HT172.eop-APC01.prod.protection.outlook.com (10.152.253.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1019.14; Tue, 18 Apr 2017 02:50:38 +0000
Received: from HK2PR0601MB1361.apcprd06.prod.outlook.com (10.152.252.56) by PU1APC01FT041.mail.protection.outlook.com (10.152.253.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.14 via Frontend Transport; Tue, 18 Apr 2017 02:50:37 +0000
Received: from HK2PR0601MB1361.apcprd06.prod.outlook.com ([10.165.182.19]) by HK2PR0601MB1361.apcprd06.prod.outlook.com ([10.165.182.19]) with mapi id 15.01.1034.015; Tue, 18 Apr 2017 02:50:37 +0000
From: li zhenqiang <li_zhenqiang@hotmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, idr <idr@ietf.org>, draft-ietf-idr-rfc5575bis.all <draft-ietf-idr-rfc5575bis.all@ietf.org>
CC: wangruixue <wangruixue@chinamobile.com>, rv <rv@NIC.DTAG.DE>, Zhuangshunwan <zhuangshunwan@huawei.com>, Jimmy <jie.dong@huawei.com>
Thread-Topic: Re: [Idr] question about BGP extended community
Thread-Index: AQHSt+6Ovr20nhyBykmQlSd+6X8JLA==
Date: Tue, 18 Apr 2017 02:50:37 +0000
Message-ID: <HK2PR0601MB1361E6C3282B51E3D8EC4C86FC190@HK2PR0601MB1361.apcprd06.prod.outlook.com>
References: <D51634BE.A89FB%acee@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=hotmail.com;
x-incomingtopheadermarker: OriginalChecksum:8FC0871369CEF632D1A88AAD5DF6E0A3E4C6BA733364C3BE9B3BD2A006FB63B2; UpperCasedChecksum:AC6FBC7374EAC0525564E1A47D24E2D4055192568C74A83D7E424550C7358CBD; SizeAsReceived:8020; Count:39
x-ms-exchange-messagesentrepresentingtype: 1
x-microsoft-exchange-diagnostics: 1; PU1APC01HT172; 5:RJy4g+H6NsMPHiiCb+gX8JjFQl4c9VK2RJHJW6ToPBYODDnhJ+ncYBUq4ugOJsGURikSNZfpa4JVlYeuCQLpwFYtE2zkTgDjBgTZKvKjK7ixO0lcHxyUYXekPBFHx498qFjXDWwPJ9iD3bkyE/bhPw==; 24:yxweFPenrZrwsaRz3PDknVMk/prb6E2Q+hma0WiGIhb53S7vv/TEH0IqNyhCjqNzfVaFD1FkQQ1l1MXgkjlyptNTCR2AjYiZEKhxV5x3Xf8=; 7:+HP8sy69ZchzfqgvSdqYtYp/6zYGepoO/iJsgQYXyPXnT+5UiUzNIzMQsmx9cAfqrRkGoD17ID8omVEwxrmar4EZu8bjDikiUVgmUWEZ7Y8UjgdaPT2GZlVQCRRPjxifEcMEbM40jPY0SYXJk4tKGMxI7f4IEGHZU+ooxJl4jp+ajqnaKAF2uTx7fIFarasnRDHQMEHOuXhL+r+A2kSz9gYGCm8bOUzfNP5DigZW0j+/fKRsIcnYBktW4kIMwW3Y4naaqaITrfcbO5kXg0RIDcqJKqk+FWM14fnVMB3r6daPA3H/oJ7l5O5VLVQfHui2
x-incomingheadercount: 39
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT172; H:HK2PR0601MB1361.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:en;
x-ms-office365-filtering-correlation-id: c56d5166-ba5c-4569-f01e-08d48605af25
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1603101448)(1601125374)(1701031045); SRVR:PU1APC01HT172;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:PU1APC01HT172; BCL:0; PCL:0; RULEID:; SRVR:PU1APC01HT172;
x-forefront-prvs: 028166BF91
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HK2PR0601MB1361E6C3282B51E3D8EC4C86FC190HK2PR0601MB1361_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2017 02:50:37.5680 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT172
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/4byGF4mdz37hbTm08X0nsn4BDlk>
Subject: Re: [Idr] question about BGP extended community
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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, 18 Apr 2017 02:50:47 -0000

Hi Acee,

Thank you very much for your answer. The implication is not declared explicitly in corresponding specifications. So some professionals raised this question when the draft  https://datatracker.ietf.org/doc/draft-li-idr-flowspec-populate-to-fib was presented in IETF98. I think it is better to specify explicitly that " A BGP speaker supports FlowSpec SHOULD support the filter actions defined with these extended communities" before table 2 in RFC5575bis since it is under discussion, we have the chance. Comments from the authors of RFC5575bis are expected. Thanks.

Best Regards,
________________________________
li_zhenqiang@hotmail.com

From: Acee Lindem (acee)<mailto:acee@cisco.com>
Date: 2017-04-14 20:22
To: li zhenqiang<mailto:li_zhenqiang@hotmail.com>; idr<mailto:idr@ietf.org>
CC: wangruixue<mailto:wangruixue@chinamobile.com>
Subject: Re: [Idr] question about BGP extended community
Hi Zhenqiang,

See inline.

From:  Idr <idr-bounces@ietf.org> on behalf of li zhenqiang
<li_zhenqiang@hotmail.com>
Date:  Friday, April 14, 2017 at 5:16 AM
To:  IDR List <idr@ietf.org>
Cc:  wangruixue <wangruixue@chinamobile.com>
Subject:  [Idr] question about BGP extended community


>Hi all,
>
>As per RFC4360, BGP extended community is a transitive optional attribute
> and RFC4271 specifies it is not required or expected that all BGP
>implementations support all optional attributes.
>  If we do want the BGP peer supports some kinds of extended communities,
>how to determine this? Check all the peers in advance? MPLS level 3 VPN,
>for example, uses the extended community
> to carry route target information, all the relevant BGP peers should
>support the RT extended community, but we can not expect this according
>to RFC4360 and RFC4271. The traffic action extended community
> as defined in RFC5575 (BGP flowspec) and updated in
>https://datatracker.ietf.org/doc/draft-li-idr-flowspec-populate-to-fib/
><file:///C:/Users/cmcc/AppData/Roaming/Foxmail7/Temp-9608-20170414150941/%
>C2%A0https://datatracker.ietf.org/doc/draft-li-idr-flowspec-populate-to-fi
>b/>,
> for another example, is expected to be supported by the receiver, which
>is not guaranteed by the transitive optional attribute.
> Do we need to do something here? Thank you very much for your help.

In general, if a BGP speaker supports an address family (RFC 4760), it
should support the required extended communities. The MP capability
negotiation will assure that only BGP speakers supporting the AF will
exchange the associated NLRI and attendant attributes including extended
communities. Of course, many extended communities are, in fact, optional
and the specifications for those extended communities should specify the
details of partial deployment.

So, I don’t believe we need anything here.

Thanks,
Acee
>
>
>Best Regards,
>________________________________________
>li_zhenqiang@hotmail.com