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

From: "Simpson, Adam 1. (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 2 May 2018 16:32:23 +0000

Hi Pavana,

I view draft-ietf-idr-bgp-flowspec-oid-06 as a more general specification of validation procedures – that would apply to all flow-spec routes, whatever actions they encode.

The validation procedure described in draft-ietf-idr-flowspec-redirect-ip-02.txt is very specific to flow-spec routes carrying this specific action.

So to me the recommendations layer on top of each other. If you think there is an inconsistency then we can try to address it in one or the other draft.

-Adam

From: PVLR Pavana Murthy <[email-masked]>
Date: Monday, April 30, 2018 at 1:14 PM
To: "Simpson, Adam 1. (Nokia - CA/Ottawa)" <[email-masked]>
Cc: idr wg <[email-masked]>
Subject: Re: Validation for BGP Flow-Spec Redirect to IP Action

Hi Adam,
   In draft-ietf-idr-bgp-flowspec-oid-06(Revised Validation Procedure for BGP Flow Specifications), the following is mentioned.  Probably this could be the reason to use the  peer-as.

"Note, comparing only the last ASes is
sufficient for EBGP learned flow specification NLRIs. Requiring a
full AS_PATH match would limit origination of inter-domain flow
specifications to the origin (or first) AS of the best-match unicast
route for the destination prefix embedded in the flow specification
only. As such, a full AS_PATH validity check may prevent transit
ASes from originating inter-domain flow specifications which is not
desirable."

Also in draft-ietf-idr-flowspec-redirect-ip-00.txt, the term 'las AS' is used instead of 'Origin As'. Even the CISCO document (https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-2/routing/configuration/guide/b_routing_cg52xasr9k/b_routing_cg52xasr9k_chapter_011.html)  uses the term 'last AS'.

Anyways, thanks for explaining the philosophy behind the validation.

-Pavana.

On Mon, Apr 30, 2018 at 9:00 PM, Simpson, Adam 1. (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pavana,

Peer-AS is not a consideration in draft -02. I don’t recall why it was mentioned in an earlier version of the draft.

If the routers inside B and C enable the extra validation check (it is optional as explained in the draft) then they would only install a flowspec route originated by a router inside A ,with a redirect-to-IP action, if the redirect IP address itself was observed to originate inside A as well.

So flow-spec routes originated by one AS can be valid in another AS, but only under restrictive circumstances.

-Adam

From: PVLR Pavana Murthy <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 30, 2018 at 2:24 AM
To: "Simpson, Adam 1. (Nokia - CA/Ottawa)" <[email-masked]<mailto:[email-masked]>>
Cc: "David Smith (djsmith)" <[email-masked]<mailto:[email-masked]>>, idr wg <[email-masked]<mailto:[email-masked]>>, Pradosh Mohapatra <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Subject: Re: Validation for BGP Flow-Spec Redirect to IP Action

Hi Adam,
  Thanks for the reply. If its the first AS that is added to the AS_PATH, then "the redirect IP" action received from the AS's that are not directly connected may be invalid always.

eg:
    A---B----C

A, B and C are 3 routers in different AS's  1, 2 and 3 respectively.
A advertises a route for target X and also a Flowspec route with "redirect  IP(target X)". C receives these routes via B.
Now the the origin AS or first AS in the AS_PATH of the route to target X is 1 but the peer-AS is 2 since the route is received from B.
Since the peer-AS does not match the first AS of the best route target X,  this redirect IP action is considered invalid.

Please let me know if that's expected.

--Pavana.

On Mon, Apr 30, 2018 at 1:12 AM, Simpson, Adam 1. (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pavana,

The purpose of this text in the draft was to close the door on the ability for an accidental/malicious originator of a flow-spec route in AS=x from redirecting flows towards a target IP address in some other AS=y.

So, in this context we are interested in looking at the first AS in AS_PATH of the flow-spec route, not the most recently added AS in the AS_PATH (which would be the ‘neighbor AS’).

The route that resolves the target redirect IP address could be a BGP route or it could be a non-BGP route, despite the wording in the draft. If it is a BGP route the origin AS is determined as described above. If is a non-BGP route it would probably be appropriate to consider the route as locally originated (i.e. the same as a BGP route with null/empty AS_PATH or having only confed related elements).

I hope this helps.

-Adam

From: PVLR Pavana Murthy <[email-masked]<mailto:[email-masked]>>
Date: Saturday, April 28, 2018 at 12:45 AM
To: "David Smith (djsmith)" <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>, Pradosh Mohapatra <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Simpson, Adam 1. (Nokia - CA/Ottawa)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Validation for BGP Flow-Spec Redirect to IP Action

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 <[email-masked]<mailto:[email-masked]>> 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  draft-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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pavana,

Your points are valid. With that said, I’ll defer you to draft-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 draft-ietf-idr-bgp-flowspec-oid-06 yesterday.

Regards,

/dave

From: PVLR Pavana Murthy <[email-masked]<mailto:[email-masked]>>
Sent: Friday, April 13, 2018 1:51 AM
To: idr wg <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; David Smith (djsmith) <[email-masked]<mailto:[email-masked]>>
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.

---

From: "David Smith (djsmith)" <[email-masked]>
Date: Thu, 3 May 2018 17:38:16 +0000

Hi Pavana,

>I went through the latest draft-ietf-idr-bgp-flowspec-oid-06. It calls the first AS the Origin AS. Is it so?

Correct, first AS = first AS added = last AS in AS_PATH_SEQ hex-string = origin AS.
last AS = last AS added = first AS in AS_PATH_SEQ hex-string = neighboring AS.
neighbor AS = peering AS: if update is coming from EBGP and enforce-first-AS used -as mandated by RFC 5575.

Note that draft-ietf-idr-bgp-flowspec-oid-06 uses 'last  AS *added*' in most cases, and when it does just use 'last AS', it can be inferred.

>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?

The RFC 5575 validation procedure required that for EBGP learned flowspecs the ‘neighboring AS’ be in the left-most (or last) position of the AS_PATH attribute. Since this is not valid for all topologies, draft-ietf-idr-bgp-flowspec-oid-06 redefines the BGP flowspec validation procedures including AS_PATH attribute. Further, the redirect-ip draft imposes an additional AS_PATH validation check (specific for redirect-ip flowspecs only) to validate that the best matching route to the redirect-ip 'target address' is a BGP route with origin AS matching the last AS added within the AS_PATH attribute of the redirect-ip flowspec. As

>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?

See feedback above. Draft-ietf-idr-bgp-flowspec-oid-06 only needs to consider last AS while redirect-ip draft needs to consider both per above.

>Regarding my second doubt, I could not get any pointers from  draft-ietf-idr-bgp-flowspec-oid-06 .  Do we need to consider only BGP routes always (for redirect-ip target address)?

The redirect-ip draft allows for its added validation check to be disabled via configuration. This allows for a non-BGP route to the redirect-ip target address.

Regards,

/dave

From: PVLR Pavana Murthy <[email-masked]>
Sent: Saturday, April 28, 2018 12:40 AM
To: David Smith (djsmith) <[email-masked]>
Cc: idr wg <[email-masked]>; Pradosh Mohapatra <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Validation for BGP Flow-Spec Redirect to IP Action

Hi Dave,

Thanks,
Pavana.

Regards,

/dave

Hello,

Thanks,

Pavana.

---

From: PVLR Pavana Murthy <[email-masked]>
Date: Fri, 4 May 2018 21:11:44 +0530

Hi Dave and Adam,
  Thanks for the reply.

Lets take the example as I gave earlier.

    A----B----C

A, B and C are 3 routers in different AS's  1, 2 and 3 respectively.
A advertises a route for target X and also a Flowspec route with "redirect
IP(target X)". C receives these routes via B.
Now the the origin AS or first AS in the AS_PATH of the route to target X
is 1 but the peer-AS of Flowspec route is 2

According to Dave,since the peer-AS 2 does not match the origin AS 1 of the
best route for target X,  this redirect IP action will be  considered
invalid for the flowspec route received at C.
This is a typical scenario. Like this, we can't propagate the Flowspec
routes with "redirect IP" action, more than one AS. I think, that's not
expected.

I feel, we should compare origin AS or neighbor-as for both Flowspec route
and the best match route of target X. We should not be using peer-AS for
flowspec route and nbr-as for best match route of target x. Otherwise the
above typical scenarios never work.
Probably, we need to edit the draft for "redirect-ip" action.

Thanks,
Pavana.

On Thu, May 3, 2018 at 11:08 PM, David Smith (djsmith) <[email-masked]>
wrote:

> neighbor AS = peering AS: if update is coming from EBGP and
> enforce-first-AS used -as mandated by RFC 5575.
>
> Note that draft-ietf-idr-bgp-flowspec-oid-06 uses 'last  AS *added*' in
> most cases, and when it does just use 'last AS', it can be inferred.
>
>
>
> >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?
>
>
>
> The RFC 5575 validation procedure required that for EBGP learned flowspecs
> the ‘neighboring AS’ be in the left-most (or last) position of the AS_PATH
> attribute. Since this is not valid for all topologies,
> draft-ietf-idr-bgp-flowspec-oid-06 redefines the BGP flowspec validation
> procedures including AS_PATH attribute. Further, the redirect-ip draft
> imposes an additional AS_PATH validation check (specific for redirect-ip
> flowspecs only) to validate that the best matching route to the redirect-ip
> 'target address' is a BGP route with origin AS matching the last AS added
> within the AS_PATH attribute of the redirect-ip flowspec. As
>
>
>
> >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?
>
>
>
> See feedback above. Draft-ietf-idr-bgp-flowspec-oid-06 only needs to
> consider last AS while redirect-ip draft needs to consider both per above.
>
>
>
> >Regarding my second doubt, I could not get any pointers from
> draft-ietf-idr-bgp-flowspec-oid-06 .  Do we need to consider only BGP
> routes always (for redirect-ip target address)?
>
>
>
> The redirect-ip draft allows for its added validation check to be disabled
> via configuration. This allows for a non-BGP route to the redirect-ip
> target address.
>
>
>
> Regards,
>
>
>
> /dave
>
>
>
>
>
> *From:* PVLR Pavana Murthy <[email-masked]>
> *Sent:* Saturday, April 28, 2018 12:40 AM
> *To:* David Smith (djsmith) <[email-masked]>
> *Cc:* idr wg <[email-masked]>; Pradosh Mohapatra <[email-masked]>;
> [email-masked]; draft-ietf-idr-bgp-flowspec-
> [email-masked]
> *Subject:* Re: Validation for BGP Flow-Spec Redirect to IP Action
>
>
>
> Hi Dave,
>
> 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
> draft-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) <[email-masked]>
> wrote:
>
> Hi Pavana,
>
>
>
> Your points are valid. With that said, I’ll defer you to
> draft-ietf-idr-bgp-flowspec-oid-05 (and later) and, specifically, section
> 4 (revised validation procedure) which addresses your points below.
>
>
>
> *From:* PVLR Pavana Murthy <[email-masked]>
> *Sent:* Friday, April 13, 2018 1:51 AM
> *To:* idr wg <[email-masked]>; [email-masked]; David Smith
> (djsmith) <[email-masked]>
> *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'.
>
>
>
>
>
>    route to X is not a BGP route with *origin AS* matching the peer AS
>
> *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.
>
>
>
>
>
>
>
>
>

---

From: "David Smith (djsmith)" <[email-masked]>
Date: Fri, 4 May 2018 17:53:23 +0000

Hi Pavana,

The redirect-ip draft specifies this additional validation step as the default behavior, however, it also allows it to be disabled via configuration.

Regards,

/dave

From: PVLR Pavana Murthy <[email-masked]>
Sent: Friday, May 04, 2018 11:42 AM
To: David Smith (djsmith) <[email-masked]>
Cc: idr wg <[email-masked]>; Pradosh Mohapatra <[email-masked]>; [email-masked]; Simpson, Adam 1. (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: Validation for BGP Flow-Spec Redirect to IP Action

Hi Dave and Adam,
  Thanks for the reply.

    A----B----C

A, B and C are 3 routers in different AS's  1, 2 and 3 respectively.
A advertises a route for target X and also a Flowspec route with "redirect  IP(target X)". C receives these routes via B.
Now the the origin AS or first AS in the AS_PATH of the route to target X is 1 but the peer-AS of Flowspec route is 2

According to Dave,since the peer-AS 2 does not match the origin AS 1 of the best route for target X,  this redirect IP action will be  considered invalid for the flowspec route received at C.
This is a typical scenario. Like this, we can't propagate the Flowspec routes with "redirect IP" action, more than one AS. I think, that's not expected.

I feel, we should compare origin AS or neighbor-as for both Flowspec route and the best match route of target X. We should not be using peer-AS for flowspec route and nbr-as for best match route of target x. Otherwise the above typical scenarios never work.
Probably, we need to edit the draft for "redirect-ip" action.

Thanks,
Pavana.

On Thu, May 3, 2018 at 11:08 PM, David Smith (djsmith) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pavana,

Regards,

/dave

From: PVLR Pavana Murthy <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, April 28, 2018 12:40 AM
To: David Smith (djsmith) <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>; Pradosh Mohapatra <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Validation for BGP Flow-Spec Redirect to IP Action

Hi Dave,

Thanks,
Pavana.

Regards,

/dave

Hello,

Thanks,

Pavana.

---

From: PVLR Pavana Murthy <[email-masked]>
Date: Sun, 6 May 2018 19:02:18 +0530

Hi Dave,
  What is the possible reason or explanation for comparing the origin AS of
best match route of target X with the peer-as of the flowspec route instead
of comparing origin AS of both the routes?

Thanks,
Pavana.

On Fri, May 4, 2018 at 11:23 PM, David Smith (djsmith) <[email-masked]>
wrote:

> Hi Pavana,
>
>
>
> The redirect-ip draft specifies this additional validation step as the
> default behavior, however, it also allows it to be disabled via
> configuration.
>
>
>
> Regards,
>
>
>
> /dave
>
>
>
>
>
> *Sent:* Friday, May 04, 2018 11:42 AM
> [email-masked]; Simpson, Adam 1. (Nokia -
> CA/Ottawa) <[email-masked]>
>
> A advertises a route for target X and also a Flowspec route with
> "redirect  IP(target X)". C receives these routes via B.
>
> According to Dave,since the peer-AS 2 does not match the origin AS 1 of
> the best route for target X,  this redirect IP action will be  considered

---

From: "David Smith (djsmith)" <[email-masked]>
Date: Tue, 8 May 2018 22:10:22 +0000

Hi Pavana,

This is a good question and not currently described in the redirect-ip draft so I’ll defer to the authors for additional comments. In the meantime, I’ll also mention the following:

·        “IF” transit ASes are able to modify a redirect-ip flowspec “target address”, then it would make sense to compare with the peer AS of the redirect-ip flowspec. However, this isn’t covered in the current draft.

·        Otherwise, it would make sense to compare the origin ASes or the whole AS-PATHs for a redirect-ip flowspec.

Regards,

/dave

Sent: Sunday, May 06, 2018 9:32 AM

Hi Dave,
  What is the possible reason or explanation for comparing the origin AS of best match route of target X with the peer-as of the flowspec route instead of comparing origin AS of both the routes?

Thanks,
Pavana.

On Fri, May 4, 2018 at 11:23 PM, David Smith (djsmith) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pavana,

Regards,

/dave

From: PVLR Pavana Murthy <[email-masked]<mailto:[email-masked]>>
Sent: Friday, May 04, 2018 11:42 AM
To: David Smith (djsmith) <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>; Pradosh Mohapatra <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Simpson, Adam 1. (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>

Hi Dave and Adam,
  Thanks for the reply.

    A----B----C

Thanks,
Pavana.

Regards,

/dave

Hi Dave,

Thanks,
Pavana.

Regards,

/dave

Hello,

Thanks,

Pavana.

---

From: PVLR Pavana Murthy <[email-masked]>
Date: Thu, 17 May 2018 13:02:39 +0530

Hi Dave,
  Did you get comments or reply from any author?

Thanks,
Pavana.

On Wed, May 9, 2018 at 3:40 AM, David Smith (djsmith) <[email-masked]>
wrote:

> Hi Pavana,
>
>
>
> This is a good question and not currently described in the redirect-ip
> draft so I’ll defer to the authors for additional comments. In the
> meantime, I’ll also mention the following:
>
> ·        “IF” transit ASes are able to modify a redirect-ip flowspec
> “target address”, then it would make sense to compare with the peer AS of
> the redirect-ip flowspec. However, this isn’t covered in the current draft.
>
> ·        Otherwise, it would make sense to compare the origin ASes or the
> whole AS-PATHs for a redirect-ip flowspec.
>
>
>
> Regards,
>
>
>
> /dave
>
>
>
>
>
> *Sent:* Sunday, May 06, 2018 9:32 AM
>
>   What is the possible reason or explanation for comparing the origin AS
> of best match route of target X with the peer-as of the flowspec route
> instead of comparing origin AS of both the routes?
>
>
>
> Thanks,
>
> Pavana.
>
>
>

---

From: "David Smith (djsmith)" <[email-masked]>
Date: Fri, 18 May 2018 17:01:10 +0000

Hi Pavana, None thus far. Regards /dave

Sent: Thursday, May 17, 2018 3:33 AM

Hi Dave,

Thanks,
Pavana.

On Wed, May 9, 2018 at 3:40 AM, David Smith (djsmith) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pavana,

•        “IF” transit ASes are able to modify a redirect-ip flowspec “target address”, then it would make sense to compare with the peer AS of the redirect-ip flowspec. However, this isn’t covered in the current draft.

•        Otherwise, it would make sense to compare the origin ASes or the whole AS-PATHs for a redirect-ip flowspec.

Regards,

/dave

Hi Dave,

Thanks,
Pavana.

Regards,

/dave

Hi Dave and Adam,
  Thanks for the reply.

    A----B----C

Thanks,
Pavana.

Regards,

/dave

Hi Dave,

Thanks,
Pavana.

Regards,

/dave

Hello,

Thanks,

Pavana.