Re: [Idr] question about BGP extended community

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