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

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 <robert@raszuk.net> wrote:
> 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