IETF Logo Mail Archive

Re: [Idr] question about BGP extended community

"Acee Lindem (acee)" <acee@cisco.com> Fri, 14 April 2017 12:22 UTC

Return-Path: <acee@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 B24D512EBF3 for <idr@ietfa.amsl.com>; Fri, 14 Apr 2017 05:22:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 uSRL2ZkztSiU for <idr@ietfa.amsl.com>; Fri, 14 Apr 2017 05:22:13 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19ED112EBE3 for <idr@ietf.org>; Fri, 14 Apr 2017 05:22:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2788; q=dns/txt; s=iport; t=1492172533; x=1493382133; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Vn3a03fzNHJ1dPoAR78LzI7Wb7n2fbyN0o7p3+EukNs=; b=bP5vXdE7G5NfRoZjUsh5/EqvcxB67CxNwkiEnsXy+A89Mvpzanl88a0x 4+anMRWv0DbIR9UpUe1HxcW3i0IxYTdt15xvmJQmDonkuo3lUxEZ0BUqN kpQXEuDKu+V00EKdrVd28OukE2vJH1VLw3jZMB1VN7cm2KSjxY5Xclvu7 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B7BAB2vvBY/4oNJK1cGQEBAQEBAQEBAQEBBwEBAQEBg1NhgQsHg1+bcm+BS4VhjUKCDyyFeByDZEAXAQIBAQEBAQEBayiFFQEDAyMRRRIBCBEDAQIDAiYCBDAVCAoEAQ0FFIlrAxUOqHaCJosRAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELhyOCYzSCUYIFF4Jvgl8FnFw7AYcDhx6EQ4JUjnKLB4kCASECNIEFYxVBhGcXgWN1iC6BDQEBAQ
X-IronPort-AV: E=Sophos;i="5.37,198,1488844800"; d="scan'208";a="410274407"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Apr 2017 12:22:12 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v3ECMBV8030252 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Apr 2017 12:22:12 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 14 Apr 2017 08:22:11 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 14 Apr 2017 08:22:11 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: li zhenqiang <li_zhenqiang@hotmail.com>, idr <idr@ietf.org>
CC: wangruixue <wangruixue@chinamobile.com>
Thread-Topic: [Idr] question about BGP extended community
Thread-Index: AQHStRm9W1kRV8yls0G3tRqW2Vw51A==
Date: Fri, 14 Apr 2017 12:22:11 +0000
Message-ID: <D51634BE.A89FB%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.197]
Content-Type: text/plain; charset="utf-8"
Content-ID: <B49134CF2F32CA43B8916A611658B6DE@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/thnmC6L4ygtPD3rIuuhUUApav7k>
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: Fri, 14 Apr 2017 12:22:15 -0000

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

v2.23.0 | Report a Bug | By Email