Re: [Idr] question about BGP extended community

[li zhenqiang <[e-mail]>]

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,
________________________________
[e-mail]

From: Acee Lindem (acee)<mailto:[e-mail]>
Date: 2017-04-14 20:22
To: li zhenqiang<mailto:[e-mail]>; idr<mailto:[e-mail]>
CC: wangruixue<mailto:[e-mail]>
Subject: Re: [Idr] question about BGP extended community
Hi Zhenqiang,

See inline.

From:  Idr <[e-mail]> on behalf of li zhenqiang
<[e-mail]>
Date:  Friday, April 14, 2017 at 5:16 AM
To:  IDR List <[e-mail]>
Cc:  wangruixue <[e-mail]>
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,
>________________________________________
>[e-mail]