Re: [Idr] Validation for BGP Flow-Spec Redirect to IP Action

[PVLR Pavana Murthy <[e-mail]>]

Hello,
  Including all the authors mentioned
in draft-ietf-idr-flowspec-redirect-ip-02, as the alias did not work. Also
pasting doubts again here.

In the draft  draft-ietf-idr-flowspec-redirect-ip-02.txt, the following
procedure is mentioned to validate the extended community of 'Flowspec
redirect to IP'.

   BGP speakers that support the extended communities defined in this
   draft MUST also, by default, enforce the following check when
   receiving a flow-spec route from an EBGP peer: if the received flow-

   spec route has a 'redirect to IP' extended community with a 'target
   address' X (in the global administrator field) and the best matching
   route to X is not a BGP route with *origin AS* matching the peer AS
   then the extended community should be discarded and not propagated
   along with the flow-spec route to other peers.


*I have 2 doubts related to this statement.*


*What is 'origin AS' here? Is it the AS no. that is first added to the
AS_PATH? *
*In the previous version of the draft its mentioned as the last AS in
the AS_PATH.*
*Is it the last AS no. that has been added to the AS_PATH or the last
AS no. from left in AS_PATH? *


*What if the redirect target X is directly connected or reachable by a
static route and its not advertised by EBGP?*

*Do we need to consider that action invalid in that case?*


Thanks,
Pavana.


On Sat, Apr 28, 2018 at 10:10 AM, PVLR Pavana Murthy <[e-mail]>
wrote:

> Hi Dave,
>    Thanks for the reply and including respective draft author aliases.
>
> I went through the latest draft-ietf-idr-bgp-flowspec-oid-06. It calls
> the first AS the Origin AS. Is it so?
> If that's the case, the validation will fail for any 'redirect IP' actions
> coming from the AS other than neighbor AS. Is that the intention?
> Also In  draft-ietf-idr-flowspec-redirect-ip-00.txt, instead of 'origin
> AS', the word 'last AS' is used.It is confusing.   Does the validation need
> to consider the first AS or last AS?
>
> Regarding my second doubt, I could not get any pointers from  d
> raft-ietf-idr-bgp-flowspec-oid-06 .  Do we need to consider only BGP
> routes always?
>
> Thanks,
> Pavana.
>
>
> On Sat, Apr 28, 2018 at 3:37 AM, David Smith (djsmith) <[e-mail]>
> wrote:
>
>> Hi Pavana,
>>
>>
>>
>> Your points are valid. With that said, I’ll defer you to d
>> raft-ietf-idr-bgp-flowspec-oid-05 (and later) and, specifically, section
>> 4 (revised validation procedure) which addresses your points below.
>>
>>
>>
>> Co-incidentally, a WG last call was issued for d
>> raft-ietf-idr-bgp-flowspec-oid-06 yesterday.
>>
>>
>>
>> Regards,
>>
>>
>>
>> /dave
>>
>>
>>
>>
>>
>> *From:* PVLR Pavana Murthy <[e-mail]>
>> *Sent:* Friday, April 13, 2018 1:51 AM
>> *To:* idr wg <[e-mail]>; [e-mail]; David Smith
>> (djsmith) <[e-mail]>
>> *Subject:* Validation for BGP Flow-Spec Redirect to IP Action
>>
>>
>>
>> Hello,
>>
>>   In the draft  draft-ietf-idr-flowspec-redirect-ip-02.txt, the
>> following procedure is mentioned to validate the extended community of
>> 'Flowspec
>>
>> redirect to IP'.
>>
>>
>>
>>
>>
>>    BGP speakers that support the extended communities defined in this
>>
>>    draft MUST also, by default, enforce the following check when
>>
>>    receiving a flow-spec route from an EBGP peer: if the received flow-
>>
>>    spec route has a 'redirect to IP' extended community with a 'target
>>
>>    address' X (in the global administrator field) and the best matching
>>
>>    route to X is not a BGP route with *origin AS* matching the peer AS
>>
>>    then the extended community should be discarded and not propagated
>>
>>    along with the flow-spec route to other peers.
>>
>>
>>
>> *I have 2 doubts related to this statement.*
>>
>>
>>
>> *What is 'origin AS' here? Is it the AS no. that is first added to the AS_PATH? *
>> *In the previous version of the draft its mentioned as the last AS in the AS_PATH.*
>> *Is it the last AS no. that has been added to the AS_PATH or the last AS no. from left in AS_PATH? *
>>
>>
>>
>> *What if the redirect target X is directly connected or reachable by a static route and its not advertised by EBGP?*
>>
>> *Do we need to consider that action invalid in that case?*
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Pavana.
>>
>>
>>
>>
>>
>>
>>
>
>