Subject: [Idr] Genart LC review: draft-ietf-idr-large-community-11

From: Robert Sparks <[email-masked]>
Date: Mon, 12 Dec 2016 12:43:33 -0600

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-idr-large-community-11
Reviewer: Robert Sparks
Review Date: 12 Dec 2016
IETF LC End Date: 16 Dec 2016
IESG Telechat date: 5 Jan 2017

Summary: Ready with nits

First a question (I don't know if this should lead to a change in the 
document). You say the use of reserved ASNs is NOT RECOMMENDED and later 
that the attribute MUST NOT be considered malformed if it has a reserved 
ASN in it. Is it clear what a recipient is supposed to do if one of 
these reserved ANSs shows up here? If so (for my own education) could 
you point me to where that's described?

Nits:

Section 11.3 in the references is only referenced by the implementation 
status section which you instruct the rfc-editor to delete. Do you 
intend for the reference to also be deleted? If so, save yourself a 
round-trip with the RFC-editor and add instructions now. If not, you'll 
need to find a way to work a reference in that won't be deleted.

David Farmer makes a suggestion at 
https://mailarchive.ietf.org/arch/msg/idr/wHOtQfblIiTPqqXsgcGHZOfMQ_s 
that looks reasonable to me. Please consider it.

The security consideration section start out with a sentence that 
strongly implies the reader might learn something about the security 
considerations for this document by reading RFC1997. That document's 
security considerations section says only that "Security issues are not 
discussed in this memo." I suggest simply deleting this first sentence. 
Please also consider if there are other BGP documents with substantive 
security considerations sections that you can point to instead.

---

From: Job Snijders <[email-masked]>
Date: Mon, 12 Dec 2016 20:11:59 +0100

Dear Robert,

On Mon, Dec 12, 2016 at 12:43:33PM -0600, Robert Sparks wrote:
> Review Team (Gen-ART) reviews all IETF documents being processed by
> the IESG for the IETF Chair.  Please treat these comments just like
> any other last call comments.

Thank you for taking the time to review this document! 

> document). You say the use of reserved ASNs is NOT RECOMMENDED and
> later that the attribute MUST NOT be considered malformed if it has a
> reserved ASN in it. Is it clear what a recipient is supposed to do if
> one of these reserved ANSs shows up here? If so (for my own education)
> could you point me to where that's described?

If two ASNs agree to exchange Large Communities with each other where
the mutually agreed upon Global Administrator value happens to be a
reserved ASN, that is something for those two networks to decide. The
key point here is that implementations must not impose any restrictions
on the uint32 value in the Global Administrator field. It is entirely at
the operator's discretion what to do with any Large Community, this
applies to reserved and non-reserved values.

The document recommends people to use their globally unique ASN, but
this will not be enforced through implementations. 

The security section refers to "Network administrators should note the
recommendations in Section 11 of BGP Operations and Security [RFC7454]."
There is some wisdom there to be gleaned.

> status section which you instruct the rfc-editor to delete. Do you intend
> for the reference to also be deleted? If so, save yourself a round-trip with
> the RFC-editor and add instructions now. If not, you'll need to find a way
> to work a reference in that won't be deleted.

Yes, the intention is that the reference to RFC7942 is to be deleted
before publication.

This is my mistake: I mistook the hyperlink in
https://tools.ietf.org/html/rfc7942#section-2.1 to be a reference, but
its just an automagically converted hyperlink. We'll remove the
reference in the next version.

> https://mailarchive.ietf.org/arch/msg/idr/wHOtQfblIiTPqqXsgcGHZOfMQ_s that
> looks reasonable to me. Please consider it.

I do not believe there is consensus at this moment to make a blanket
recommendation based on the contents of the registry (whatever they
may be in the future), but rather work with the precise and concise
approach which is currently described.

Jakob Heitz responded to the suggestion to extend the reserved Global
Administrator values, but for some reason I can't find that email in the
IETF IDR archive, I've copy+pasted it here:

-------------
	Date: Mon, 05 Dec 2016 03:16:52 +0100
	From: "Jakob Heitz (jheitz)" <[email-masked]>
	To: David Freedman <[email-masked]>
	Cc: "[email-masked]" <[email-masked]>
	Subject: Re: [Idr] New Version Notification for draft-ietf-idr-large-community-11.txt

    No new text is required to cover this: 23456 is not an ASN.
    Besides, if anyone were to put it into a large community, no harm
    would be done other than what would happen if any other unassigned
    ASN were used.

    About reserving values, we don't reserve values because the values
    are unusable, but because we may want to use them for other purposes
    later. There is no need to reserve another value. 3 is more than
    enough.

	Thanks,
	Jakob.
--------------

In addition to the above, although the document does not define any
Special-Use BGP Large Communities, the Global Administrator values
specified in Section 2 (0, 65535, 4294967295) could be used if there is
a future need for them. The purpose of recommending that these values
are not to be used is not because there is harm in doing so, but to
leave the door open for future things (should they ever arise). From
this perspective a blanket reservation based on the ASN registry
wouldn't make sense for me.

> security considerations section says only that "Security issues are
> not discussed in this memo."

The reference to RFC 1997 was meant to leverage 20 years of experience
with implementing and operating networks which use RFC 1997 communities.
I agree that the security section of RFC 1997 is somewhat sparse, but
the principle still applies: RFC 1997 and Large Communities have similar
security implications, even if they are not properly documented in RFC
1997.

> I suggest simply deleting this first sentence. Please also consider if
> there are other BGP documents with substantive security considerations
> sections that you can point to instead.

A reference to RFC 7454 is included, I am not aware of other specific
resources that can be pointed at. 

Kind regards,

Job

---

From: Robert Sparks <[email-masked]>
Date: Mon, 12 Dec 2016 13:52:41 -0600

> this will not be enforced through implementations.
Thanks for the explanation. It would have avoided the question if the 
document said that - consider explicitly adding the key point you point to.
> IETF IDR archive, I've copy+pasted it here:
  WFM, but please get your chairs to chase down why the message didn't 
make it to the archive.
> with implementing and operating networks which use RFC 1997 communities.
Well, sure, but where is that 20 years of experience written down for 
the next implementer or operator?
The existing pointer essentially has the semantic of "if you need to 
know you already know"...
> security implications, even if they are not properly documented in RFC
So, I _think_ your intent was to document them here.
>
>> I suggest simply deleting this first sentence.
I still think that's the right thing to do.
>>   Please also consider if

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 12 Dec 2016 19:57:19 +0000

A little more context regarding reserved communities:

The RFC 1997 reserved community values 65535:* will be
presented to the routing policy when received, just like
any other community values. The routing policy can match
on them and set or delete them, just like any other
community values.

The only difference is that the router takes the
action prescribed by an assigned reserved community value,
in most cases. I.e., it is not even required that the
routing software take the prescribed action. The routing
policy could do it just as well.

This carries over to large communities.

Thanks,
Jakob.

> -----Original Message-----
> From: Job Snijders [mailto:[email-masked]]
> Sent: Monday, December 12, 2016 11:12 AM
> To: Robert Sparks <[email-masked]>
> Cc: General Area Review Team <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Idr] Genart LC review: draft-ietf-idr-large-community-11
> 
> Dear Robert,
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 12 Dec 2016 20:32:27 +0000

>   WFM, but please get your chairs to chase down why the message didn't

It shows up in the other archive:
https://www.ietf.org/mail-archive/web/idr/current/msg17255.html

Thanks,
Jakob.

---

From: [email-masked]
Date: Wed, 14 Dec 2016 16:59:59 +0800

Hi all,

    About RFC5575, it seems like that the definition of "Terminal 
Action bit" is blurred. 

    In section 7, the "Terminal Action bit" is defined as follows:
Terminal Action (bit 47): When this bit is set, the traffic filtering 
engine will apply any subsequent filtering rules (as defined by the 
ordering procedure).  If not set, the evaluation of the traffic filter 
stops when this rule is applied.

    How can routers do when many rules that define variant actions 
are applied to a same flow?

   For example, there are four rules that can be applied to one same flow. 

And the sequence has been determined as below. When router executes rule 
1,
the "Terminal Action Bit" is set. It indicated that next rule should be 
executed. When router execute rule 2, which action should be executed? 
Only redirect? Or/and traffic-marking? Which traffic-rate should be 
selected?

rule 1

   traffic-rate: 10Mbps

   traffic-marking: DSCP=10

   traffic-action: T=1 S=1 

rule 2

   traffic-rate: 20Mbps

   redirect: nexthop = 192.168.1.2

   traffic-action: T=0 S=0 

rule 3

   traffic-rate: 30Mbps

   traffic-marking: DSCP=30

   redirect: nexthop = 192.168.2.2

   traffic-action: T=1 S=1 

rule 4

   traffic-rate: 40Mbps

   traffic-marking: DSCP=40

   traffic-action: T=0 S=0

---

From: Christoph Loibl <[email-masked]>
Date: Wed, 14 Dec 2016 11:58:53 +0100

Hi,

Your example perfectly makes sense to me, and I understand that there are several sections in RFC5575 that are a little unclear. RFC5575 does not explain what should happen in your case, nor does it explain anything in case of action-interference.

This is why we currently working on a rfc557bis that should help us to fix those problems and improve interoperability for flowspec. Have a look at:

https://datatracker.ietf.org/doc/draft-hr-idr-rfc5575bis/ <https://datatracker.ietf.org/doc/draft-hr-idr-rfc5575bis/>
Section 7.6. Rules on Traffic Action Interference

During writing this section we were actually discussing single flowspec NLRIs with conflicting actions like:

rule 1
    traffic-rate: 10Mbps
    traffic-rate: 20Mbps

or

rule 1
   redirect: A
   redirect: B

I think we shall extend this section to also explain your case. Currently this is not explained even in our submitted draft draft-hr-idr-rfc5575bis <https://datatracker.ietf.org/doc/draft-hr-idr-rfc5575bis/> latest revision. In that case it may make sense to have a "latest" action wins behaviour. I suggest the following behaviour (this is nowhere written yet):

>    traffic-action: T=1 S=1 

after this rule 2 gets applied

>    redirect: nexthop = 192.168.1.2 

The resulting action for that flow is:

    traffic-rate: 20Mbps
    traffic-marking: DSCP=10

Since on the second rule the terminal-bit is 0 there is no other rule to be evaluated.

To the "latest" applied action wins. However this is only one suggested behaviour. There are plenty of other options. It should also be considered that implementing such a behaviour may not be trivial.

Christoph

> On 14 Dec 2016, at 09:59, [email-masked] wrote:
> 
> 
> Hi all, 
> 
> And the sequence has been determined as below. When router executes rule 1, 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

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

---

From: Robert Sparks <[email-masked]>
Date: Wed, 14 Dec 2016 08:20:10 -0600

> https://www.ietf.org/mail-archive/web/idr/current/msg17255.html
There was an issue (for about 200 messages) in the indexing in the 
mailarchive tool that has been repaired.
This particular message is at
<https://mailarchive.ietf.org/arch/msg/idr/tg_gVjNwrFWklo4dTRUHo7Rkqos>

Thanks again for spotting the issue.

---

From: [email-masked]
Date: Thu, 15 Dec 2016 17:34:21 +0800

Hi Christoph,

    Thank you very much for your response. Glad to hear that the RFC 
will be revised Clearly.

    From your specification, I have two questions for it:

1, If it is valid that define the same action with different 
values in one same rule?

2, What’s the benefit of "Terminal Action bit"? I think that your 
action merging may be one of the solutions. But the network manager 
cannot get the result from the same rule directly. It may cause the 
confusion of network manager, isn't it?

Thanks,
Sandy

Christoph Loibl <[email-masked]> 写于 2016/12/14 18:58:53:

> Hi,
> 
> Your example perfectly makes sense to me, and I understand that 
> there are several sections in RFC5575 that are a little unclear. 
> RFC5575 does not explain what should happen in your case, nor does 
> it explain anything in case of action-interference.
> 
> This is why we currently working on a rfc557bis that should help us 
> to fix those problems and improve interoperability for flowspec. 
> Have a look at:
> 
> https://datatracker.ietf.org/doc/draft-hr-idr-rfc5575bis/
> During writing this section we were actually discussing single 
> flowspec NLRIs with conflicting actions like:
> 
> rule 1
>     traffic-rate: 10Mbps
>     traffic-rate: 20Mbps
> 
> or
> 
> rule 1
>    redirect: A
>    redirect: B
> 
> I think we shall extend this section to also explain your case. 
> Currently this is not explained even in our submitted draft draft-
> hr-idr-rfc5575bis latest revision. In that case it may make sense to
> have a "latest" action wins behaviour. I suggest the following 
> behaviour (this is nowhere written yet):
> 
> Suggestion: In your example the action for a flow matching all your 
> rules should be a merge of rule 1 and rule 2:
> 
> rule 1 
> 
>    traffic-rate: 10Mbps 
> 
>    traffic-marking: DSCP=10 
> 
>    traffic-action: T=1 S=1 

> To the "latest" applied action wins. However this is only one 
> suggested behaviour. There are plenty of other options. It should 
> also be considered that implementing such a behaviour may not be 
trivial.
1, 
> [email-masked] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 15 Dec 2016 16:56:58 +0100

Hi Sandy,

​​>
2, What’s the benefit of "Terminal Action bit"?

The meaning of this flag was to indicate requirement analogy of "continue"
statement when executing your traffic filtering actions on the matched
traffic. Example - you may want to redirect to a vrf with or without
remarking the traffic with different. Not really much more to it.

Best regards,
R.

On Thu, Dec 15, 2016 at 10:34 AM, <[email-masked]> wrote:

> ​​
> > also be considered that implementing such a behaviour may not be trivial.
> >
> > Christoph
> >

---

From: [email-masked]
Date: Fri, 16 Dec 2016 16:25:34 +0800

Hi Robert,

    Thank you for your response. I understand the meaning of your 
example. But I am not known very clearly about where this function 
will be used. If we want to redirect one flow to one vrf, why don't 
we define the associated actions in the vrf’s rules? Once there is 
something wrong with one flow, it may be hard to find out the wrong 
rule, because many rules may influence the flow’s action, isn't it?

Thanks,
Sandy

[email-masked] 写于 2016/12/15 23:56:58:

> Hi Sandy,
> 
> ​​> 2, What’s the benefit of "Terminal Action bit"?
> 
> The meaning of this flag was to indicate requirement analogy of 
> "continue" statement when executing your traffic filtering actions 
> on the matched traffic. Example - you may want to redirect to a vrf 
> with or without remarking the traffic with different. Not really 
> much more to it.
> 
> Best regards,
> R. 
> 
> ​​2, What’s the benefit of "Terminal Action bit"? I think that your 
trivial.