Subject: Re: [Idr] Question on forwarding behavior in draft-ietf-idr-flowspec-redirect

From: "Simpson, Adam (Adam)" <[email-masked]>
Date: Wed, 7 Aug 2013 01:46:22 +0000

Hi Jeff,

Somehow your email escaped our notice and we neglected to respond.
Apologies for that..

Your observation is valid. The way we have chosen to encode the redirect
destination means that if we want to send IPv6 traffic over an IPv4 tunnel
we need to express the IPv4 tunnel destination in a special way (e.g. an
IPv4-mapped IPv6 address) and vice versa; if that is our intent it should
of course be defined in the draft and we will certainly look into that for
the next revision. The alternative is to encode the tunnel destination
(and possibly associated tunnel parameters) using an entirely new path
attribute but we thought that was overkill for the main use cases we were
targeting.

Regards,
Adam

On 2013-06-18 3:51 PM, "Jeffrey Haas" <[email-masked]> wrote:

>Authors,
>
>:   When a BGP speaker receives an UPDATE message with the redirect-to-
>:   IP extended community it is expected to create a traffic filtering
>:   rule for every flow-spec NLRI in the message that has this path as
>:   its best path. The filter entry matches the IP packets described in
>:   the NLRI field and redirects them (C=0) or copies them (C=1) towards
>:   the IPv4 or IPv6 address specified in the 'Network Address of Next-
>:   Hop' field of the associated MP_REACH_NLRI. More specifically: if an
>:   IPv4 [or IPv6] packet with destination address D that is normally
>:   forwarded to a next-hop A matches a filter entry of the type
>:   described above it MUST instead be redirected (C=0) or mirrored
>:   (C=1) to next-hop B, where B is found by FIB lookup of the IPv4 [or
>:   IPv6] address contained in the MP_REACH_NLRI next-hop field (i.e. a
>:   longest-prefix-match lookup). Signaling and applying constraints
>:   beyond longest-prefix-match on the types of interfaces or tunnels
>:   that can be used as the redirection next-hop B are not precluded by
>:   this specification but are nevertheless outside its scope.
>
>The text above raises some question with regard to mixed-address family
>behavior.  To illustrate, we have four examples of IP-based forwarding:
>
>*IPv4 traffic over IPv4 forwarding
> IPv6 traffic over IPv4 forwarding
> IPv4 traffic over IPv6 forwarding
>*IPv6 traffic over IPv6 forwarding
>
>The cases noted with an asterisk aren't exciting - you'd expect them to
>just
>work regardless of whether the nexthop sent in the flowspec route is
>either
>an adjacent IP system or a tunnel covering the same address family.
>
>The other two cases are the interesting ones.
>
>One normally wouldn't expect IPv6 traffic to be IP forwarded to an IPv4
>nexthop, or vice-versa.  When the nexthop actually maps to a tunnel (e.g.
>MPLS), the case is perhaps a bit more ambiguous: Does the egress of the
>tunnel inspect the traffic to determine the proper ethertype for the
>traffic?
>
>This is admittedly not an immediate problem today.  5575 and the matching
>extension to do IPv6 currently expect the address family of the flowspec
>route to have an appropriate same-family MP-NEXTHOP.
>
>Put a somewhat different way, if the expected behavior is that you'll
>always
>have a nexthop for redirect that is of the same address family as the
>flowspec route, we're perhaps done.
>
>Until we decide we want to do flowspec for something besides plain IP.
>
>But that is perhaps a different problem to worry about later.
>
>-- Jeff
>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 7 Aug 2013 16:54:53 +0200

Hi Jeff & Adam,

Reading via your mails I am a bit confused if you are talking about
"match" or "actions".

"Redirect" is an action and 5575 just specifies redirect to a VRF
based on the RT. Such VRF can have any AFI/SAFI enabled and in
particular can be a start of encap (of any form) to some external
device (very often traffic deep inspection/screening).

While we are discussing some other forms of actions but so far this is
out of scope of proposed documents.

Reg "match" the MP_REACH next hop field is of the length zero.

Rgs,
R.

> On Wed, Aug 7, 2013 at 3:46 AM, Simpson, Adam (Adam) <adam.simpson@alcatel-
> lucent.com> wrote:
> Hi Jeff,
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 7 Aug 2013 17:02:43 +0200

And for the draft-simpson-idr-flowspec-redirect during last IETF there
were number of corridor discussions that there are scenarios where
flowspec could highly benefit if we would attach BGP Vector Node Path
Attribute as described in draft-patel-raszuk-bgp-vector-routing-00.

Hence it would be perhaps beneficial to talk to authors of
draft-simpson-idr-flowspec-redirect in consideration of using more
general solution to the problem they expressed and replaced proposed
ext community with BGP Vector Node attribute.

Best regards,
R.

> On Wed, Aug 7, 2013 at 4:54 PM, Robert Raszuk <[email-masked]> wrote:
> Hi Jeff & Adam,
>

---

From: "Simpson, Adam (Adam)" <[email-masked]>
Date: Thu, 8 Aug 2013 18:45:30 +0000

Hi Robert,

Thanks for the pointer to the BGP vector routing draft. I agree it could
be complementary (but not a complete alternative) to the solution we are
proposing. Let me discuss this with the other authors.

-Adam

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Sun, 11 Aug 2013 00:35:54 +0000

I briefly looked over the draft. I have some general concerns about its use i.e 

- Single AS scope. We envision a world where DCs use different ASes from each other and from the WAN..
- Inconsistent routing due to incorrect programming of the vector attr by an SDN controller
- SDN control across admin boundaries i.e 3rd party provides DC services and partners with a WAN provider.. How would the WAN SDN controller no about the interior addr scheme of the DC? A number of variations on this theme.. 
- How does the reprogramming of the FIB to be in line with the vector attr behave in various fast re-route scenarios
- Consistent view from an edge perspective.. This is sort of OpenFlowish in that all participants need to get and program the same behavior..i.e MicroLooping, inconsistent forwarding

etc...

Jim Uttaro
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simpson, Adam (Adam)
Sent: Thursday, August 08, 2013 2:46 PM
To: Robert Raszuk
Cc: [email-masked]
Subject: Re: [Idr] Question on forwarding behavior in draft-ietf-idr-flowspec-redirect

Hi Robert,

-Adam