Subject: [tsvwg] Review of draft-ietf-tsvwg-gre-in-udp-encap-11

From: Martin Stiemerling <[email-masked]>
Date: Wed, 1 Jun 2016 15:19:27 +0200

Dear all,

Please find here my review of draft-ietf-tsvwg-gre-in-udp-encap-11.

General: The draft is ready to with a few smaller issues.

Issues:
- The text says in multiple places "avoid congestion".
However, I do not see that, for instance, rate limiters, will avoid 
congestion. A rate limiter will cause congestion for affected flows but 
potentially keep congestion away from other parts of the network.
(A bit more) correct would be something along the line of "to detect 
congestion and to mitigate congestion".

- This document uses RFC5405bis as reference in many places, though RFC 
5405 is the only stable anchor at this point of time. I am not sure how 
far RFC 5405bis is right now or asked differently, is there a need to 
wait for RFC 5405 to complete?

- I do disagree with "IP-traffic can be assumed to be 
congestion-controlled.", even though it is stated in RFC 5405, as there 
is a lot of IP traffic that is not congestion controlled, such as 
multicast traffic...
Section 4, even states that multicast and broadcast traffic can be 
carried over GRE-UDP! None of both is in general congestion controlled!

- Section 2.1.1 on page 5, point 7 "it MUST set the same DSCP value to 
all fragments." From what value the DSCP must be set? This isn't stated 
here.

- Section 4.1, first sentence:
"   Regarding packet fragmentation, an encapsulator/decapsulator SHOULD
    be compliant with [RFC7588] and perform fragmentation before the
    encapsulation."
RFC 7588 is mentioned here and the SHOULD implies that a 
reader/implementer has to read RFC 7588. However, RFC 7588 is not listed 
under normative references and it is anyhow an informational document, 
which would require a down-ref in the last call.

Editorials:
- There are multiple occurences in the text "IANA Note: Replace TBD1 and 
TBD2 with the IANA-assigned numbers". I suggest to remove these notes 
and just to say in the IANA considerations section that IANA is 
requested to replace these labels with the appropriate port numbers. And 
tell in the IANA considerations section where to find these labels.

- TBD1/TBD2 in figures: replace with a different labels and say that 
these labels do correspondent to the IANA assigned port numbers. The 
figures do not need to state the actual port numbers, as they will do, 
if the text and the IANA text stays as it is right now.

- Section 1.1: Move TMCE up in the list, as it used in the terminology 
even before it is defined.

Thanks,

   Martin

---

From: "Black, David" <[email-masked]>
Date: Wed, 1 Jun 2016 20:11:00 +0000

Martin,

Thanks for the review - I'll take a couple of the higher-level issues as
draft shepherd ...

[1] Is rfc5405bis draft reference appropriate?

> wait for RFC 5405 to complete?

Yes there is a need to reference the rfc5405bis draft - this GRE/UDP draft
needs to reference the Controlled Environment material in Section 3.6 of the
rfc5405bis draft.  That rfc5405bis draft is reasonably stable, however ...

[2] IP traffic congestion control assumptions.

> carried over GRE-UDP! None of both is in general congestion controlled!

Well, this is actually an issue with the rfc5405bis draft, and this issue needs
to be fixed there, as RFC 5405 is (and the rfc5405bis draft will be) the
Transport Area's statement to the rest of the IETF on congestion control
guidelines and requirements for UDP usage.

I'm going to attempt to take advantage of your ex-TSV-AD status to pull a
"no good deed goes unpunished" trick ;-) and ask you to suggest modifications
to the two crucial paragraphs in the rfc5405bis draft on this topic (I'm happy
to work w/you off-list to develop proposed text).  Those two crucial paragraphs
are in Section 3.1.11 of the rfc5405bis draft:

   IP-based traffic is generally assumed to be congestion-controlled,
   i.e., it is assumed that the transport protocols generating IP-based
   traffic at the sender already employ mechanisms that are sufficient
   to address congestion on the path.  Consequently, a tunnel carrying
   IP-based traffic should already interact appropriately with other
   traffic sharing the path, and specific congestion control mechanisms
   for the tunnel are not necessary.

   However, if the IP traffic in the tunnel is known to not be
   congestion-controlled, additional measures are RECOMMENDED to limit
   the impact of the tunneled traffic on other traffic sharing the path.

Thanks in advance - we need to get this right, IMHO.

This will also definitively resolve the first issue ;-), as after this
rfc5405bis text change, the GRE/UDP draft will have to reference
(normatively) the rfc4505bis draft (which is what it already does).

Thanks, --David (as shepherd for both the GRE/UDP and rfc5405bis drafts).

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Martin Stiemerling
> Sent: Wednesday, June 01, 2016 9:19 AM
> To: [email-masked]
> Subject: [tsvwg] Review of draft-ietf-tsvwg-gre-in-udp-encap-11
> 
> Dear all,
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 2 Jun 2016 11:17:02 -0700

On 6/2/2016 11:14 AM, Joe Touch wrote:
>
> On 6/1/2016 6:19 AM, Martin Stiemerling wrote:
>> reader/implementer has to read RFC 7588. However, RFC 7588 is not
>> listed under normative references and it is anyhow an informational
>> document, which would require a down-ref in the last call. 
> RFC7588 *describes* how existing deployments operate. It does not
> specify requirements.
>
> It doesn't seem appropriate to refer to being "compliant" with a
> description.

FWIW - correction to the following:
> Further, RFC7588 indicates problems with that configuration and
> describes how its use is thus limited. At best, you would need to copy
> those restrictions as well, but that further begs the question of
> needing a copy of GRE without the benefits of the GRE header.
Too many drafts ;-)

In this case, you do need to copy the caveats in RFC7588, but the doc
already elsewhere justifies the GRE in UDP approach sufficiently.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 2 Jun 2016 11:14:28 -0700

Joe

---

From: Lucy yong <[email-masked]>
Date: Mon, 6 Jun 2016 20:47:58 +0000

Hi Marin,

Thank you very much for the review and comments.
See inline below.

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of Martin Stiemerling
Sent: Wednesday, June 01, 2016 8:19 AM
To: [email-masked]
Subject: [tsvwg] Review of draft-ietf-tsvwg-gre-in-udp-encap-11

Dear all,

Issues:
- The text says in multiple places "avoid congestion".
However, I do not see that, for instance, rate limiters, will avoid congestion. A rate limiter will cause congestion for affected flows but potentially keep congestion away from other parts of the network.
(A bit more) correct would be something along the line of "to detect congestion and to mitigate congestion".

- This document uses RFC5405bis as reference in many places, though RFC
5405 is the only stable anchor at this point of time. I am not sure how far RFC 5405bis is right now or asked differently, is there a need to wait for RFC 5405 to complete?

- I do disagree with "IP-traffic can be assumed to be congestion-controlled.", even though it is stated in RFC 5405, as there is a lot of IP traffic that is not congestion controlled, such as multicast traffic...
Section 4, even states that multicast and broadcast traffic can be carried over GRE-UDP! None of both is in general congestion controlled!
[Lucy] David has addressed above comments. Seek to align with RFC5405bis text.

- Section 2.1.1 on page 5, point 7 "it MUST set the same DSCP value to all fragments." From what value the DSCP must be set? This isn't stated here.
[Lucy] how about "it MUST set the same DSCP value as in the DS field of the payload packet to all fragments.[RFC2474] "?

- Section 4.1, first sentence:
"   Regarding packet fragmentation, an encapsulator/decapsulator SHOULD
    be compliant with [RFC7588] and perform fragmentation before the
    encapsulation."
RFC 7588 is mentioned here and the SHOULD implies that a reader/implementer has to read RFC 7588. However, RFC 7588 is not listed under normative references and it is anyhow an informational document, which would require a down-ref in the last call.
[Lucy] Since RFC7588 documents current vendor implementations, how about not reference [RFC7588] in this draft?  

Editorials:
- There are multiple occurences in the text "IANA Note: Replace TBD1 and
TBD2 with the IANA-assigned numbers". I suggest to remove these notes and just to say in the IANA considerations section that IANA is requested to replace these labels with the appropriate port numbers. And tell in the IANA considerations section where to find these labels.

- TBD1/TBD2 in figures: replace with a different labels and say that these labels do correspondent to the IANA assigned port numbers. The figures do not need to state the actual port numbers, as they will do, if the text and the IANA text stays as it is right now.
[Lucy] ack.

- Section 1.1: Move TMCE up in the list, as it used in the terminology even before it is defined.
[Lucy] ack.

Thanks,
Lucy

Thanks,

   Martin