Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2)

["Juan Alcaide (jalcaide)" <[e-mail]>]

Authors mention it on section 8, but  I don't think the real 
implications were discussed.
Treating traffic differently based the direction it arrives may be out 
of scope of 5575, but it's the reason of this draft and customer are 
asking for it. I think in some cases it makes sense not treating all 
interfaces equally

For flowspec in particular, you don't have to use a new SAFI. It's an 
extensible NLRI, so we can just define a dummy component that doesn't 
match anything (similar to an RD)

Acee, we didn't make the group-id part of the NLRI per inter-AS 
considerations (imagine AS1 means group-id =1 => customer interfaces, 
but AS2 means group-id=1 provider interfaces; you want to be able to do 
the translation). Look for thread "[Idr] 
draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT" a couple 
years ago (w/o the '(part 2)')

-J

On 7/28/2017 2:15 PM, Robert Raszuk wrote:
>
> To change format of NLRI you need essentially a new SAFI.
>
> Clearly an option for this new draft, but I think authors never 
> envisioned that given set of match rules should have different actions 
> depending on the arriving interfaces for traffic matching such rules. 
> If at all I would recommend it to move it to flowspec v2 discussion.
>
> It is in fact very wired and quite bad to treat on the same router the 
> same traffic differently based on the direction it arrives ... clearly 
> out of scope of original 5575.
>
> The config push part indeed can be interface scoped, but is BGP really 
> a right tool for this ?
>
> Cheers,
> R.
>
>
> On Fri, Jul 28, 2017 at 2:02 PM, Acee Lindem (acee) <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     What was the reason for not making the interface-group part a new
>     component type in the NLRI? It seems that making it just another
>     Flow Spec match condition would  handle all these situations
>     naturally.
>
>      I remember that this was discussed but don’t recall whether it
>     was backward compatibility or that the semantics of interface
>     group-id was a better fit for an extended community.
>
>     Thanks,
>     Acee
>
>     From: Idr <[e-mail] <mailto:[e-mail]>> on
>     behalf of Robert Raszuk <[e-mail] <mailto:[e-mail]>>
>     Date: Friday, July 28, 2017 at 7:52 AM
>     To: "Juan Alcaide (jalcaide)" <[e-mail]
>     <mailto:[e-mail]>>
>     Cc: IDR List <[e-mail] <mailto:[e-mail]>>
>
>     Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset =>
>     NLRI vs EXTCT (part 2)
>
>         Hi Juan,
>
>             (group-id: what to you specify in ext-community;
>             interface-group: what you specify under interface
>             configuration)
>
>
>         ​Obvious. ​
>
>             If you use ADD-PATHS, you can send identical NLRIs and you
>             consider them as valid (no implicit withdraw)
>
>
>         ​If your controller or management station does not support
>         ADD-PATHS this is not the case. Only when you have ADD-PATHS
>         everywhere you may play that game.
>
>         Remember flow-spec was designed to be a DDoS mitigation tool
>         across ASes. Across ASes last time I checked deployment of
>         ADD-PATHS is zero. Now since some folks turned it into config
>         push ​is not something original 5575 can be blamed for.
>
>             There is a requirement that the same flowspec rule, could
>             be used for 2 different interface-groups (let's say
>             interfaces customer-facing and interfaces
>             provider-facing). But also you may want to use different
>             actions based on the group-id (section 8 of the draft)
>
>
>         ​That is just operational mess. To do that you can use SAFI
>         134 where 8 octet RD is part of the NLRI what makes NLRI unique.
>
>             I think we basically need to expand/clarify the ADD-PATHS
>             part. Regarding your points:
>             1. For a given NLRI, we change group-ids or actions based
>             on what we want to achieve. So it's based on how customer
>             sets the rule in the controller. There may be a need to
>             send same NLRI with 2 different sets of action+group-id
>
>
>         ​I think doing this in such way is very messy. Pushing FS
>         routes with RD as indicated above is much cleaner if there
>         such need to apply different actions or group IDs for the same
>         NLRIs. ​
>
>             2. If receiver receives more than one group-id, it should
>             apply all the actions specified to *all* the
>             interface-group associated to all the group-ids it
>             received. Draft does explicitly say what to do when you
>             receive a NLRI with multiple group-ids, but I think it
>             should be applied to all interface-groups (probably it
>             should be clarified)
>
>
>         ​ok.
>
>         Thx,
>         R.​
>
>
>
>
>             -J
>
>
>
>
>             On 7/27/2017 11:43 PM, Robert Raszuk wrote:
>>             Juan,
>>
>>             Sending from single controller (single BGP peer) two
>>             updates with identical NLRIs is an implicit withdraw.
>>             ADD-PATHs has nothing to here.
>>
>>             Likewise RR should treat is as implicit withdraw of the
>>             previous one too.
>>
>>             If you go by your line of thinking what would make
>>             controller to change for given NLRI1 group-id 1 to
>>             group-id 2 if there is need to do so ?
>>
>>             In any case if you decide to add additional text to the
>>             current draft or decide to write new draft to address
>>             this please do make sure to clearly define two things:
>>
>>             1. How for a given NLRI we change either actions or
>>             group-ids
>>
>>             2. What should receiver do when for a given NLRI he
>>             received more then one group-id or more then one set of
>>             actions ?
>>
>>             Thanks,
>>             R.
>>
>>
>>
>>
>>
>>             On Thu, Jul 27, 2017 at 11:37 PM, Juan Alcaide (jalcaide)
>>             <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>                 Robert,
>>
>>                 We may support or not support unsynchronized controllers
>>                 But let's assume for a second we are just using one
>>                 controller
>>                 but can a single controller sending
>>
>>                 NLRI1 + group-id 1
>>                 NLRI1 + group-id 2
>>
>>                 The RR receives both this routes (must be ADD-PATHS,
>>                 as mentioned in the draft). The RR needs to use
>>                 ADD-PATHS itself to send it to the PE (final receiver)
>>
>>                 -J
>>
>>
>>
>>
>>                 On 7/27/2017 9:44 PM, Robert Raszuk wrote:
>>>                 Hi Jakob,
>>>
>>>                     Two flowspec routes with the same NLRI may be
>>>                     originated by different speakers.
>>>
>>>
>>>                 Group-id (scoped application of specific flow-spec
>>>                 rules) is addressing a special case where it is
>>>                 generated carefully by either controller or
>>>                 provisioning tools. I do not see therefor a
>>>                 practical case where the same such rule would be
>>>                 coming from two or more independent sources and
>>>                 would be applicable ​to different interface groups.
>>>
>>>                 It sounds more like a protocol conflict or
>>>                 provisioning bug and not something we should worry
>>>                 about how to carry it across RRs. Standard protocol
>>>                 behavior would be fine here.
>>>
>>>                 Now also notice what would receiver do ... treat the
>>>                 subsequent update with the exactly same NLRI as
>>>                 implicit withdraw or run best path if they come from
>>>                 different peers and still apply single one to local
>>>                 data plane. So really there is no point to give it
>>>                 both such paths with ADD-PATHs. As it is on final
>>>                 receivers the same should be done on RRs ...
>>>
>>>                 ​Cheers,
>>>                 //RR.​
>>>
>>>                     The first route will have one group-id. The
>>>                     second route will have another group-id.
>>>
>>>                     Thanks,
>>>
>>>                     Jakob.
>>>
>>>                     *From:*Idr [mailto:[e-mail]
>>>                     <mailto:[e-mail]>] *On Behalf Of
>>>                     *Robert Raszuk
>>>                     *Sent:* Wednesday, July 26, 2017 4:38 PM
>>>                     *To:* Juan Alcaide (jalcaide)
>>>                     <[e-mail] <mailto:[e-mail]>>
>>>                     *Cc:* idr wg <[e-mail] <mailto:[e-mail]>>
>>>                     *Subject:* Re: [Idr]
>>>                     draft-litkowski-idr-flowspec-interfaceset =>
>>>                     NLRI vs EXTCT (part 2)
>>>
>>>                     Hi Juan,
>>>
>>>                     >  (we assume controller(s) may not want to send multiple
>>>                     ext-communities with same NLRI).
>>>
>>>                     If I recall group-ids are carried in new RT format:
>>>
>>>                     "This new BGP Route Target extended community is
>>>                     encoded as follows :
>>>
>>>                          0           1   2         3
>>>
>>>                          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>                     2 3 4 5 6 7 8 9 0 1
>>>
>>>                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>>                         |  Type (TBD)   |  0x02     |  Autonomous
>>>                     System Number   :
>>>
>>>                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>>                         :     AS Number (cont.)         |O|I|    
>>>                      Group Identifier |
>>>
>>>                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>>                     "
>>>
>>>                     So just like an UPDATE message of SAFI 128 may
>>>                     contain many RTs why would you see any
>>>
>>>                     issue to carry multiple ext communities of the
>>>                     above format here ?
>>>
>>>                     Best,
>>>
>>>                     R.
>>>
>>>                     On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide
>>>                     (jalcaide) <[e-mail]
>>>                     <mailto:[e-mail]>> wrote:
>>>
>>>                         Hi,
>>>
>>>                         From a previous thread, I see from the that
>>>                         using EXTCOMM to carry group-id information
>>>                         the choice. Reason was that every AS could
>>>                         use their own the group-id (perhaps
>>>                         different than another AS). With this
>>>                         choice, ADD-PATHS must be mandatory in order
>>>                         to support multiple group-ids for the same
>>>                         flowspec rule (we assume controller(s) may
>>>                         not want to send multiple ext-communities
>>>                         with same NLRI).
>>>
>>>                         But the draft really does not describe how
>>>                         to use ADD-PATHS, and it does not discuss
>>>                         its problems:
>>>
>>>                         - Usually, ADD-PATHS is used for path
>>>                         diversity, and implementations typically
>>>                         don't advertise 2 paths with the same
>>>                         next-hop (otherwise, we could have path
>>>                         explosion across multiple levels of RRs)
>>>
>>>                         - If ADD-PATHS has to advertise the same
>>>                         NLRI with different ext-communities, one
>>>                         solution would be for ADD-PAHTS not
>>>                         advertise the same set of ext-communities.
>>>                         Unless, I guess, next-hops are different.
>>>                         Otherwise, we would have path explosion.
>>>
>>>                         - Assuming the above, we should define a
>>>                         particular set of ADD-PATHS rules for
>>>                         flowspec AF. And, of course, leave the door
>>>                         open for future specific ADD-PATHs rules for
>>>                         other AFs (it would not be about path
>>>                         diversity anymore, but about propagating
>>>                         different information for forwarding
>>>                         purposes -imagine what we could have done
>>>                         with an IPv4 prefix: send the same net part
>>>                         as a NLRI and multiple ext-communities
>>>                         representing different prefix-lengths -).
>>>
>>>                         - Since paths in a net are typically
>>>                         implemented as a list, there could be
>>>                         scalability problems if we ever want to
>>>                         support many group-ids.
>>>
>>>                         My solution to simplify all these problems
>>>                         would be to add a discriminator on the NLRI
>>>                         (by defining a new dummy type for flowspec).
>>>                         We could still use ext-communities to
>>>                         actually match the NLRIs to interfaces.
>>>                         Similar to RD and RT usage.
>>>
>>>                         Thoughts?
>>>
>>>                         -J
>>>
>>>
>>>                         _______________________________________________
>>>                         Idr mailing list
>>>                         [e-mail] <mailto:[e-mail]>
>>>                         https://www.ietf.org/mailman/listinfo/idr
>>>                         <https://www.ietf.org/mailman/listinfo/idr>
>>>
>>>
>>
>>
>
>
>