Subject: [RTG-DIR] RTG-DIR review of draft-ietf-tsvwg-rfc5405bis-13

From: Ronald Bonica <[email-masked]>
Date: Sun, 5 Jun 2016 17:30:49 +0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: 
Reviewer: Ron Bonica
Review Date: 6/5/16
IETF LC End Date: 
Intended Status: BCP

Summary: 
Choose from this list...

This document is basically ready for publication, but has nits that should be considered prior to publication.

Comments:

Major Issues:

Minor Issues:

- General: If Section 4 is called "Multicast UDP Usage Guidelines", Section 3 should be called "Unicast UDP Usage Guidelines"

- Section 3.1.3: What value is there for implementing congestion control on an application that exchanges only a few packets? Maybe this section exists because the value of "a few" may vary greatly?

- Section 3.1.11: It will come as a surprise to most tunnel developers that the ECN bits need to be copied. You might want to call this out explicitly (rather than through a reference).

- Section 3.2: You say, "Due to these issues, an application SHOULD NOT send UDP datagrams that result in IP packets that exceed the Maximum Transmission Unit  (MTU) along the path to the destination." While I agree with this goal, it may cause problems for DNSSEC.

- Section 3.4.1: This section is difficult to parse. I think I agree with what you are saying, but I am not sure that the words on the page are actually saying.

- Section 3.4.1: Please scan for grammatical errors.

- Section 4.1.2 : What value is there for implementing congestion control on an low volume multicast application ? Maybe this section exists because the value of "a few" may vary greatly?

Nits:

-- Obsolete informational reference (is this intentional?): RFC  896
     (Obsoleted by RFC 7805)

  -- Obsolete informational reference (is this intentional?): RFC 2309
     (Obsoleted by RFC 7567)

---

From: Ronald Bonica <[email-masked]>
Date: Sun, 5 Jun 2016 20:11:21 +0000

BTW, one more question about the draft.....

In the draft, you make a distinction between tunnels that carry IP and tunnels that do not carry IP. Can a tunnel be said to carry IP if there are several layers of encapsulation between IP and the tunnel? For example, consider the following stack:

 TCP/IP/Ethernet/PW/UDP/IP

According to your definition, does this tunnel carry IP, even though Ethernet is between IP and the PW tunnel?

                                                     Ron

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Sunday, June 5, 2016 1:31 PM
To: <[email-masked]> <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [RTG-DIR] RTG-DIR review of draft-ietf-tsvwg-rfc5405bis-13

Hello,

Document: 
Reviewer: Ron Bonica
Review Date: 6/5/16
IETF LC End Date: 
Intended Status: BCP

Summary: 
Choose from this list...

Comments:

Major Issues:

Minor Issues:

Nits:

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 6 Jun 2016 08:13:55 +0000

On 2016-06-05, at 22:11, Ronald Bonica <[email-masked]> wrote:
> In the draft,

This was actually already in RFC5405.

> you make a distinction between tunnels that carry IP and tunnels that do not carry IP. Can a tunnel be said to carry IP if there are several layers of encapsulation between IP and the tunnel? For example, consider the following stack:
> 

Yes, it carries IP. What matters is that the sources of traffic into this tunnel construct see an IP path and so generate IP traffic, which we can assume to be as congestion-controlled as normal Internet traffic is.

If the traffic sources where, e.g., generating non-IP Ethernet or some other L2 traffic, that assumption cannot be made.

Lars

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 6 Jun 2016 13:26:57 +0000

Lars,

This is high goodness! In alleviates most of my concerns about the document!

Would it be possible to make this explicit in the document?

                                                         Ron

-----Original Message-----
From: Eggert, Lars [mailto:[email-masked]] 
Sent: Monday, June 6, 2016 4:14 AM
To: Ronald Bonica <[email-masked]>
Cc: <[email-masked]> <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: RTG-DIR review of draft-ietf-tsvwg-rfc5405bis-13

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 7 Jun 2016 07:54:50 +0000

Hi,

> This is high goodness! In alleviates most of my concerns about the document!

happy to hear.

> Would it be possible to make this explicit in the document?

This is what the current text already tries to express. DO you have any specific suggestions on what is unclear?

Lars