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

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

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

On 2013-08-07 11:02 AM, "Robert Raszuk" <[e-mail]> wrote:

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