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

["Simpson, Adam (Adam)" <[e-mail]>]

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" <[e-mail]> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/idr