Re: [Idr] WG adoption call for draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules"

Hi Robert,

Thanks for your prompt reply: yes makes sense.

I tend to believe that for this particular type 12 fragment nlri, it could make sense, from an implementation point of view, to allow only certain combinations that doesn’t exclude each other.

Thanks for helping me to come to a conclusion on this !

Matthieu.

> On 24 Aug 2017, at 16:26, Robert Raszuk <robert@raszuk.net> wrote:
> 
> Hi Matthieu,
> 
> IMO the RFC is quite clear that "A specific packet is considered to match the flow specification when it matches the intersection (AND) of all the components present in the specification." 
> 
> That effectively means to me that to match packets which will be last fragment or first fragment one would need to inject two separate NLRIs. At this is guarantee to work. 
> 
> Making assumption that implementation does OR among type 12 bitmask values would actually remove ability to match on broken packets on the wire which may actually have messed up IP headers and both bits set in the respect of fragmentation - don't you think ? 
> 
> Kind regards,
> R.
> 
> 
> On Thu, Aug 24, 2017 at 4:00 PM, Matthieu Texier <matthieu@texier.tv> wrote:
> Hi John and All,
> 
> I would like to apologise re-opening this quite old mail thread but as I am working on a development, I am questioning myself on a very specific aspect of flowspec filtering.
> 
> I would like to discuss nlri filtering type 12 - Fragment. This discussion is valid for both the existing RFC and this proposed draft.
> 
> In all filtering nlri that requires bitmask (tcp flags, DSCP), the RFC 5575 is defining the encoding of the nlri value as the exact same way as it is encoded in the IP header itself.
> 
> For the bitmask type 12, the RFC rather propose to use “pre-defined” values like IsF, FF, DF, LF.
> 
> There are two observations I would like to highlight:
> 
> 1) This approach creates a sort of inconsistency between filters: I tend to believe that the approach of Flowspec filters was to filter according to a header pattern (just like with DSCP and TCP flags flowspec nlri). If we follow the same approach for fragments, we should normally propose a nlri value made of the fragment flags (3 bits) and eventually 1 bit to specify if fragment offset have to null or not.
> 
> 2) The bitmask of nlri type 12 as define could create odd router behavior or misalignment between implementations:
> 
> Assuming that routers identifies the first fragment by checking that MF bit is set to 1 and that the offset set to 0. How a router could consider a nlri with a bitmask having Isf and FF set to one ? Does it have to do an implicit OR between the Isf and FF ?
> 
> Considering my first observation and following the same logic as with DSCP and TCP flags, if I want to filter packets that are fragments or first fragments, I should normally send two values with an explicit OR operator between the two.
> 
> It might be implemented that way in certain OS but I am afraid that RFC is not perfectly clear on this particular situation.
> 
> Does it make sense to other people of the group or it is only me torturing myself ?
> 
> Thanks,
> Matthieu.
> 
> 
> 
> 
> > On 21 Jan 2017, at 16:03, John G. Scudder <jgs@juniper.net> wrote:
> >
> > Hi All,
> >
> > The authors have requested IDR working group adoption of draft-hr-idr-rfc5575bis-02 "Dissemination of Flow Specification Rules". Please send your comments to the list.
> >
> > This adoption call will conclude on Monday, February 6.
> >
> > Thanks,
> >
> > —John
> > _______________________________________________
> > 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
> 