Subject: [Idr] WGLC for draft-ietf-idr-rfc5575bis-04

From: John Scudder <[email-masked]>
Date: Fri, 6 Oct 2017 13:39:04 -0400

Hi All,

A working group last call has been requested for draft-ietf-idr-rfc5575bis-04. Please reply to the list with your comments. As usual note we cannot advance the draft without participation from the group. Please get your comments in before October 20, 2017.

Authors, please confirm that any relevant IPR has been disclosed. 

https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-04

Thanks,

--John

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 6 Oct 2017 20:24:47 +0200

I am not aware about any IPR associated with draft-ietf-idr-rfc5575bis-04.

Thx
Robert Raszuk.

On Fri, Oct 6, 2017 at 7:39 PM, John Scudder <[email-masked]> wrote:

> Hi All,
>
> A working group last call has been requested for
> draft-ietf-idr-rfc5575bis-04. Please reply to the list with your comments.
> As usual note we cannot advance the draft without participation from the
> group. Please get your comments in before October 20, 2017.
>

---

From: "McPherson, Danny" <[email-masked]>
Date: Fri, 6 Oct 2017 18:45:57 +0000

Me either..

-danny

From: <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Friday, October 6, 2017 at 2:24 PM
To: John Scudder <[email-masked]>
Cc: idr wg <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: WGLC for draft-ietf-idr-rfc5575bis-04
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Friday, October 6, 2017 at 2:24 PM

Thx

Robert Raszuk.

Hi All,

Thanks,

--John

---

From: Christoph Loibl <[email-masked]>
Date: Fri, 6 Oct 2017 22:08:02 +0200

Hi,

Christoph

--
Christoph Loibl
[email-masked] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

> On 6 Oct 2017, at 20:24, Robert Raszuk <[email-masked]> wrote:
> 
> On Fri, Oct 6, 2017 at 7:39 PM, John Scudder <[email-masked] <mailto:[email-masked]>> wrote:
> Hi All,
> 
> https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-04 <https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-04>
> 
> Thanks,
> 
> --John
>

---

From: Martin Bacher <[email-masked]>
Date: Fri, 6 Oct 2017 22:28:25 +0200

I am also not aware about any IPR associated with draft-ietf-idr-rfc5575bis-04.

Martin

> Am 06.10.2017 um 20:24 schrieb Robert Raszuk <[email-masked]>:
>

---

From: Martin Bacher <[email-masked]>
Date: Sat, 7 Oct 2017 16:04:36 +0200

Martin

---

From: Martin Bacher <[email-masked]>
Date: Sat, 7 Oct 2017 16:07:56 +0200

Martin

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 7 Oct 2017 11:45:33 -0400

I know of no IPR related to this draft as a co-author.  I believe this draft
is ready for publication. 

 Sue Hares 

-----Original Message-----
From: John Scudder [mailto:[email-masked]] 
Sent: Friday, October 6, 2017 1:39 PM
To: [email-masked]
Cc: [email-masked]
Subject: WGLC for draft-ietf-idr-rfc5575bis-04

Hi All,

Thanks,

--John

---

From: "Simpson, Adam 1. (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 11 Oct 2017 19:43:08 +0000

Support.

On 2017-10-06, 1:39 PM, "Idr on behalf of John Scudder" <[email-masked] on behalf of [email-masked]> wrote:

    Hi All,

    
    
    Thanks,
    
    --John
    _______________________________________________
    Idr mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/idr

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 13 Oct 2017 13:10:18 +0000

Support, the document provides a stronger foundation for the "Flowspec Indirection-id Redirect" draft under progress, as it adds normative reference to a wider set of use-cases.

G/

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of John Scudder
Sent: Friday, October 6, 2017 19:39
To: [email-masked]
Cc: [email-masked]
Subject: [Idr] WGLC for draft-ietf-idr-rfc5575bis-04

Hi All,

Thanks,

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 13 Oct 2017 14:00:03 -0400

Hi All,

An update on this one -- in addition to the authors' assumed and in one case explicit support, I see support for advancing the doc from Adam Simpson, Justin Ryburn, Gaurav Dawra and Gunter Van De Velde. There haven't been any technical suggestions or opposition to advancement.

As a reminder, the comment period runs for one more week.

Thanks,

--John
 
> On Oct 6, 2017, at 1:39 PM, John Scudder <[email-masked]> wrote:
> 
> Hi All,
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Didr-2Drfc5575bis-2D04&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=NRg6_yNI-6NZWDLw-zlZgRFr4-nJyZP1wcETHv334ZA&s=pTEOe5Gx7V82hZEFL-fqS4fGYTtzNCYM5O5HKc51c8w&e= 
> 
> Thanks,
> 
> --John

---

From: Job Snijders <[email-masked]>
Date: Sat, 14 Oct 2017 17:34:02 +0200

On Fri, Oct 06, 2017 at 01:39:04PM -0400, John Scudder wrote:
> draft-ietf-idr-rfc5575bis-04. Please reply to the list with your
> comments. As usual note we cannot advance the draft without
> participation from the group. Please get your comments in before
> October 20, 2017.
> 

I read the document and support publication.

Some comments: 

s/automate of inter-domain/automate inter-domain/
s/application which control/applications which control/
s/Some of deployments of these/Some deployments of these/

I see use of the strings 'flowspec', 'flow-spec' and 'flow spec'; which
one is the preferred one to use? :)

section 4.2.3
OLD:  The bits lt, gt, and eq can be combined to produce "less or
       equal", "greater or equal", and inequality values.
NEW:  The bits lt, gt, and eq can be combined to produce common
      relational operators such as "less or equal", "greater or equal",
      and "not equal to".

section 5.1:
    I have trouble parsing: "For IP prefix values (IP destination and source
    prefix) precedence is given to the lowest IP value of the common prefix
    length;"

    If a packet destined for 10.5.0.1 is covered by a rule for
    destination 10.0.0.0/8 and a rule covering destination 10.5.0.0/24 -
    the 10.0.0.0/8 rule would 'win' because '10.0.0.0' is a lower IP
    value?

    Another question, and I realise this is a big ask: Is it possible to
    replace the pseudocode with an actual code example? Pseudo languages
    tend to not follow any specific set of rules and therefor oftentimes
    are hard to read. Awk, lua, python, ruby, perl, or really anything
    that actually can be compiled and inspected would be better than
    pseudocode. I've been part of discussions where we tried to
    deconstruct the pseudocode author's intentions and rules of
    precedence.

Section 13: remove 'Note: Any original author...' ?

This concludes my review, thank you for your work on this document.

Kind regards,

Job

---

From: Christoph Loibl <[email-masked]>
Date: Mon, 16 Oct 2017 13:05:27 +0200

Hi Job,

Thanks for you excellent feedback on this draft.

See my comments inline.

> On 14 Oct 2017, at 17:34, Job Snijders <[email-masked]> wrote:

Noted for a update that I will publish by the end of the week.

> one is the preferred one to use? :)

I was looking into configurations of different manufacturers, documentations, … there is a mix of flow, flow-spec, flowspec in various documents. I suggest to use “flowspec” since this seems to have the widest spread already in most of the documentation found on the web.

>      and "not equal to”.

I understand that your major point here is that the bit combinations produce an _operator_ not a _value_, which is true.

>    length;”

Same with me - I try to come up with something better but it still lacks a definition what the common prefix is (I will need some more time to think about this):

For IP prefix values (IP destination and source prefix) the common prefixes are compared (common prefix: the prefixes up to the minimal prefix-length those two share). If those are equal the prefix with the longer prefix-length has higher precedence. If the common prefix is different the one with the lowest IP value has higher precedence.

-> Maybe we can even put it this way - I need to spend more time to think if this is equal to the above definition, but looks _much_ more elegant (what do you think?):

If the prefixes are overlapping, the one with the longer prefix-length has higher precedence. If they are not overlapping the one with the lowest IP value has higher precedence.

>    the 10.0.0.0/8 rule would 'win' because '10.0.0.0' is a lower IP

No. What actually should happen is:

1) compare the “common” prefix (in this case the common prefix length = 8)

10.0.0.0/8 == 10.5.0.0/8 -> the common prefix is equal.

2) if the common prefix is equal (which is the case) the prefix with the longest match takes precedence:

10.0.0.0/8 <- 8 bit
10.5.0.0/24 <- 24 bit <- this one wins!

Another example:

9.0.0.0/8 vs 10.5.0.0/24

1) compare the “common” prefix (in this case the common prefix length = 8)

9.0.0.0/8 == 10.5.0.0/24 -> the common prefix is _not_ equal

2) lower value takes precedence:

9.0.0.0 < 10.5.0.0/24

9.0.0.0/8 wins!

>    deconstruct the pseudocode author's intentions and rules of

I also think that actual code that can be interpreted/compiled may be helpful in some cases. The complexity of such a code may sometimes not be very beneficial and some of the environment (variables, modules, helper-functions…)  needed to actually run the code may just not fit into such a draft.

However, I uploaded a python-script containing a python version of the flow_rule_cmp(a, b) plus unit-test with 100% code coverage:

https://github.com/stoffi92/flowspec-cmp/blob/master/flow-cmp.py <https://github.com/stoffi92/flowspec-cmp/blob/master/flow-cmp.py>

IF the group thinks we shall use this - please carefully analyse the behaviour. I am sure I have hidden some bugs in there and I am sure it is possible to beautify what I came up with (I am not the programmer).

> Section 13: remove 'Note: Any original author…’

Can/should be done, if no objections.

> This concludes my review, thank you for your work on this document.

Thanks a lot for reading thru this.

Cheers Christoph

---

From: Job Snijders <[email-masked]>
Date: Mon, 16 Oct 2017 14:05:20 +0200

(snipping some pieces)

On Mon, Oct 16, 2017 at 01:05:27PM +0200, Christoph Loibl wrote:
> I was looking into configurations of different manufacturers,
> documentations, … there is a mix of flow, flow-spec, flowspec in
> various documents. I suggest to use “flowspec” since this seems to
> have the widest spread already in most of the documentation found on
> the web.

ok!

> I understand that your major point here is that the bit combinations
> produce an _operator_ not a _value_, which is true.

yes

> Same with me - I try to come up with something better but it still
> lacks a definition what the common prefix is (I will need some more
> time to think about this):
> 
> For IP prefix values (IP destination and source prefix) the common
> prefixes are compared (common prefix: the prefixes up to the minimal
> prefix-length those two share). If those are equal the prefix with the
> longer prefix-length has higher precedence. If the common prefix is
> different the one with the lowest IP value has higher precedence.
> 
> -> Maybe we can even put it this way - I need to spend more time to
> think if this is equal to the above definition, but looks _much_ more
> elegant (what do you think?):
> 
> If the prefixes are overlapping, the one with the longer prefix-length
> has higher precedence. If they are not overlapping the one with the
> lowest IP value has higher precedence.
> 

Why would you ever see 10.5.0.0/8 - that looks like an incorrect CIDR
notation to me? 

> Another example: 9.0.0.0/8 vs 10.5.0.0/24
> 

I'm sorry, but I still don't understand. 9.0.0.0/8 and 10.5.0.0/24 don't
overlap, shouldn't they both be installed as ACLs? Maybe I don't
understand when this algorithm is used?

> I also think that actual code that can be interpreted/compiled may be
> helpful in some cases. The complexity of such a code may sometimes not
> be very beneficial and some of the environment (variables, modules,
> helper-functions…)  needed to actually run the code may just not fit
> into such a draft.
> 
> However, I uploaded a python-script containing a python version of the
> flow_rule_cmp(a, b) plus unit-test with 100% code coverage:
> 
> https://github.com/stoffi92/flowspec-cmp/blob/master/flow-cmp.py
> 
> IF the group thinks we shall use this - please carefully analyse the
> behaviour. I am sure I have hidden some bugs in there and I am sure it
> is possible to beautify what I came up with (I am not the programmer).

I think this is a very good direction and I hope the WG sees this as
path forward too.

In the I-D I'd leave out the unittest part for the sake of brevity. I'd
also specify what version of python this code was tested against. And
of course you can include a link to that github repository in the I-D.
For other drafts we've taken a similar approach.

Kind regards,

Job

---

From: Christoph Loibl <[email-masked]>
Date: Mon, 16 Oct 2017 15:00:26 +0200

Hi Job,

> Why would you ever see 10.5.0.0/8 - that looks like an incorrect CIDR

Yes - 10.5.0.0/8 - no “correct” cidr notation. I just wanted to express that we look at the first 8 bits of the 10.5.0.0 - and compare it to the first 8 bit of 10.0.0.0 - both times this is 10 => they match.

> understand when this algorithm is used?

Both are actually installed (but the order is determined). This algorithm is used for sorting the ACL terms. In our case 9.0.0.0/8 will get sorted “above” 10.5.0.0/24. (In case of overlapping prefix the match behaviour is changed to longest prefix-length “first").

Since the arrival-time of the BGP updates is non predictable some sorting is needed to have a consistent order of ACL-terms in the network.

When programming a “sorting” algorithm you usually need a compare function that allows to compare items. In python I think you need to implement __lt__ for classes that you want the built-in sort() to work. The code that I put on github can be easily adopted to be used for sorting “flowspec_nlri” objects.

> For other drafts we've taken a similar approach.

Can you point me to some I-Ds that use a similar approach - maybe one can learn from that.

Cheers Christoph

---

From: Job Snijders <[email-masked]>
Date: Mon, 16 Oct 2017 18:30:46 +0200

On Mon, Oct 16, 2017 at 01:00:26PM +0000, Christoph Loibl wrote:
> Both are actually installed (but the order is determined). This
> algorithm is used for sorting the ACL terms. 

Ah! I see now, thank you for your patience and clarification. For some
reason I derailed into the LPM routing mindset. OK, back to the original
issue. 

OLD: For IP prefix values (IP destination and source prefix) precedence
     is given to the lowest IP value of the common prefix length; if the
     common prefix is equal, then the most specific prefix has
     precedence

PERHAPS:
    For IP prefix values (destination or source) the common high-order
    bits are compared. The number of common bits to compare is the
    lowest prefix-length of the two prefixes. If the high-order bits are
    equal, the prefix with the longer prefix-length has higher
    precedence. If the common high-order bits are different, the prefix
    with the lowest numeric value takes higher precedence.

> >>>   Another question, and I realise this is a big ask: Is it
> >>>   possible to replace the pseudocode with an actual code example?
> >>>   Pseudo languages tend to not follow any specific set of rules
> >>>   and therefor oftentimes
> >> 
> >> IF the group thinks we shall use this - please carefully analyse
> >> the behaviour. I am sure I have hidden some bugs in there and I am
> >> sure it is possible to beautify what I came up with (I am not the
> >> programmer).
> > 
> > In the I-D I'd leave out the unittest part for the sake of brevity.
> > I'd also specify what version of python this code was tested
> > against. And of course you can include a link to that github
> > repository in the I-D.  For other drafts we've taken a similar
> > approach.
> 

You can put the relevant python code inside CDATA block to preserve
formatting.

    <figure>
    <artwork><![CDATA[
    
    my python code ..

    ]]></artwork>
    </figure>

And in the paragraph introducing the code reference the full codebase as
following:

    The full python implementation of 'flowspec-cmp' is available at
    <eref target="https://github.com/stoffi92/flowspec-cmp">https://github.com/stoffi92/flowspec-cmp</eref>.

Be sure to add something liberal like a BSD-2 Clause LICENSE file to the
repository.

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Mon, 16 Oct 2017 19:07:01 +0200

>     with the lowest numeric value takes higher precedence.

Still feels wonky, maybe this:

PERHAPS:
    For IP prefix values (destination or source) the common high-order
    bits are compared. The number of common bits to compare is the
    lowest prefix-length value of the two prefixes. If the high-order
    bits are equal, the prefix with the longer prefix-length has higher
    precedence. If the common high-order bits are different, the prefix
    with the set of bits that represent the lowest numeric value takes
    higher precedence.

If others chime in here that would be appreciated.

Kind regards,

Job

---

From: Christoph Loibl <[email-masked]>
Date: Mon, 16 Oct 2017 19:30:51 +0200

Hi Job,

> On 16 Oct 2017, at 19:07, Job Snijders <[email-masked]> wrote:
> 

Maybe you missed this in one of my previous emails, but this seems to be very easy to read and is the same behaviour:

PERHAPS:
For IP prefix values (IP destination or source prefix): If the prefixes are overlapping, the one with the longer prefix-length has higher precedence. If they are not overlapping the one with the lowest IP value has higher precedence.

Christoph

---

From: Job Snijders <[email-masked]>
Date: Mon, 16 Oct 2017 19:49:54 +0200

On Mon, Oct 16, 2017 at 05:30:51PM +0000, Christoph Loibl wrote:
> PERHAPS: For IP prefix values (IP destination or source prefix): If
> the prefixes are overlapping, the one with the longer prefix-length

Works for me!

Kind regards,

Job

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 18 Oct 2017 18:31:33 +0300

A short update on this WGLC.

Authors Robert Raszuk, Danny McPherson, Christoph Loibl, Martin Bacher, and Sue Hares have all responded that they know of no IPR to declare.

Support from Adam Simpson, Justin Ryburn, Gaurav Dawra, Gunter Van De Velde, and Job Snijders (and assumed or explicit from authors). A review from Job and ensuing discussion with Christoph -- seems like you guys reached consensus on some edits, if so it would be good to publish a revision. The polishing around the textual bits is fine IMO but I would like to know that the WG has had a chance to review the proposed revision to the pseudo-code as it would be published (i.e., edited into the draft, not just on github) before we proceed forward. 

Thanks,

--John

> On Oct 6, 2017, at 8:39 PM, John Scudder <[email-masked]> wrote:
> 
> Hi All,
>

---

From: Christoph Loibl <[email-masked]>
Date: Thu, 19 Oct 2017 10:48:31 +0200

Hi,

I will try to upload a new revision for review by tomorrow.

BTW: the URL for the python example has changed slightly in the meantime you can have a look at this github project for review:

https://github.com/stoffi92/flowspec-cmp <https://github.com/stoffi92/flowspec-cmp>

Christoph

> On 18 Oct 2017, at 17:31, John G. Scudder <[email-masked]> wrote:
> 
> Support from Adam Simpson, Justin Ryburn, Gaurav Dawra, Gunter Van De Velde, and Job Snijders (and assumed or explicit from authors). A review from Job and ensuing discussion with Christoph -- seems like you guys reached consensus on some edits, if so it would be good to publish a revision.

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 20 Oct 2017 21:50:21 +0300

Just for completeness, following up to this thread too --

This WGLC is extended til next Wednesday, October 25, to allow the WG time to review the updates in -05.

--John

> Authors, please confirm that any relevant IPR has been disclosed. 
...

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 24 Oct 2017 15:47:54 +0300

Hi Christoph,

I don't think the -05 version specifies the version of python?

On Oct 16, 2017, at 3:05 PM, Job Snijders <[email-masked]> wrote:
> also specify what version of python this code was tested against.

Seems like a good idea to do that. I see you specified "python3" but I was imagining something along the lines of "this code was tested with Python 3.2.3" or whatever.

Thanks,

--John

---

From: Christoph Loibl <[email-masked]>
Date: Tue, 24 Oct 2017 15:23:12 +0200

Hi John,

Thanks for pointing that out. Giving the complete Python version can be useful.

I suggest to replace:

The code below shows a python3 implementation of the comparison
   algorithm described above.  The full python3 implementation including
   unittests can be optained at https://github.com/stoffi92/flowspec-cmp
   [1].

with something like this:

The code below shows a Python3 implementation of the comparison
   algorithm. The full code was tested with Python 3.6.3 and can be
   optained at https://github.com/stoffi92/flowspec-cmp
   [1].

a) adding the full Python version (not only 3) I was running the tests on
b) not mentioning the unittests as Job suggested (I somehow missed that)

I suggest I wait for some more feedback (if any) on the current -5 document and upload a -6 by the end of the week.

Christoph

> On 24 Oct 2017, at 14:47, John G. Scudder <[email-masked]> wrote:
> 
> Hi Christoph,
>

---

From: John Scudder <[email-masked]>
Date: Wed, 25 Oct 2017 11:05:12 +0300

>   optained at https://github.com/stoffi92/flowspec-cmp

Works for me.

> I suggest I wait for some more feedback (if any) on the current -5 document and upload a -6 by the end of the week.

I'm OK with that but for that matter, I don't see any special reason to wait, you can go ahead and upload -6 whenever you have it. It is easy to do a -7 if needed, after all.

Thanks,

--John

---

From: Christoph Loibl <[email-masked]>
Date: Wed, 25 Oct 2017 12:11:27 +0200

Hi,

I just uploaded the -6 version as requested. The change is exactly what I suggested below (adding exact python version + removing statement about unit-tests).

https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ <https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/>

Cheers

Christoph

> On 25 Oct 2017, at 10:05, John Scudder <[email-masked]> wrote:
> 
> On Oct 24, 2017, at 4:23 PM, Christoph Loibl <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi John,
>>