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

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,
>
> 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" <jhaas@pfrc.org> 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
>>Idr@ietf.org
>>https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr