Re: [Idr] question about BGP extended community

Joel Jaeggli <joelja@bogus.com> Tue, 18 April 2017 03:11 UTC

Return-Path: <joelja@bogus.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 1A7FA126B72; Mon, 17 Apr 2017 20:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.889
X-Spam-Level:
X-Spam-Status: No, score=-6.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 eYdLypV6ibxi; Mon, 17 Apr 2017 20:11:36 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC3A12940E; Mon, 17 Apr 2017 20:11:36 -0700 (PDT)
Received: from [IPv6:2607:fb90:2287:64d7:d85b:4d25:2776:d384] ([IPv6:2607:fb90:2287:64d7:d85b:4d25:2776:d384]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v3I3BM2s067203 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Apr 2017 03:11:23 GMT (envelope-from joelja@bogus.com)
Content-Type: multipart/alternative; boundary=Apple-Mail-62D3EE55-2C52-46A6-BF89-97799D95F20C
Mime-Version: 1.0 (1.0)
From: Joel Jaeggli <joelja@bogus.com>
X-Mailer: iPhone Mail (14E304)
In-Reply-To: <HK2PR0601MB1361E6C3282B51E3D8EC4C86FC190@HK2PR0601MB1361.apcprd06.prod.outlook.com>
Date: Mon, 17 Apr 2017 20:11:21 -0700
Cc: "Acee Lindem (acee)" <acee@cisco.com>, idr <idr@ietf.org>, "draft-ietf-idr-rfc5575bis.all" <draft-ietf-idr-rfc5575bis.all@ietf.org>, wangruixue <wangruixue@chinamobile.com>
Content-Transfer-Encoding: 7bit
Message-Id: <C55DFF44-1BDE-4501-95B3-9C663F8EDC7D@bogus.com>
References: <D51634BE.A89FB%acee@cisco.com> <HK2PR0601MB1361E6C3282B51E3D8EC4C86FC190@HK2PR0601MB1361.apcprd06.prod.outlook.com>
To: li zhenqiang <li_zhenqiang@hotmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/QaGG4YE_f1wakjVrb6jYRkJToPQ>
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 03:11:38 -0000


Sent from my iPhone

> On Apr 17, 2017, at 19:50, li zhenqiang <li_zhenqiang@hotmail.com> wrote:
> 
> 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.

Flowspec tends to be something implemented by mutual agreement. E.G. my provider indicates support for flowspec and what parameters they expect or support and I implement my export policy accordingly. 

> Best Regards,
> li_zhenqiang@hotmail.com
>  
> From: Acee Lindem (acee)
> Date: 2017-04-14 20:22
> To: li zhenqiang; idr
> CC: wangruixue
> 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
>  
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr