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

[Jeffrey Haas <[e-mail]>]

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