Subject: Re: [tsvwg] partial review of draft-ietf-tsvwg-gre-in-udp-encap-03

From: Lucy yong <[email-masked]>
Date: Wed, 17 Dec 2014 17:04:39 +0000

Hi Bob,

Thank you very much for the review. Sorry for the very late response due to my two week vacation and a pile of stuff to work on after that.  

Please see inline below.

-----Original Message-----
From: Bob Briscoe [mailto:[email-masked]] 
Sent: Friday, November 21, 2014 11:30 AM
To: Lucy yong
Cc: Black, David; [email-masked]
Subject: partial review of draft-ietf-tsvwg-gre-in-udp-encap-03

Lucy,

I'll wait for David's promised proposal to the list before commenting on the checksum issue.
[Lucy] We need some work in IPv6 zero-checksum. Please share your comments and suggestions. 

1) Regarding congestion control, I do not share the position of some others in tsvwg. Congestion responsiveness is determined by how the source spaces out the packets (i.e. their instantaneous rate). Just because a tunnel ingress encapsulates a packet with a UDP header does not suddenly make it unresponsive to congestion. The spacing between packets is still determined by the source. So there is no need to even mention congestion control considerations in a tunnelling document, except to say in the scoping at the start that the addition of tunnel headers is completely orthogonal to congestion avoidance and control.

[Lucy] does David's response make sense to you? The draft will not specify congestion control at the tunnel, rather gre-in-udp applicability where congestion is not a concern for the tunnel and recommended filters to block traffic from going where it should not.

2)
Please replace:
    Tunnel end points that support
    ECN MUST use the method described in [RFC6040] for ECN marking
    propagation.
With:
    Tunnel end points need to use the method described in [RFC6040] for ECN marking
    propagation.
Rationale:
    i) There is no such thing as a tunnel end point that does not support ECN - it has to put something in the ECN field, and it would not be appropriate to put anything in there other than what RFC6040 says.
   ii) Generally it is not a good idea to fill one draft with normative statements that repeat normative statements made in other drafts. Otherwise updating an RFC gets very difficult - we have to update all the other RFCs that gratuitously repeat what it says.
[Lucy] will take your suggestion.

3) Nit in section 3.1.
    Section 5 of RFC6936 [RFC6936] specifies the additional requirements
    that implementation of UDP zero-checksum over IPv6 MUST compliant
    with. To compliant with it, the following additional requirements
    apply
s/compliant/comply/ (twice)
[Lucy] Thx. will fix it in next version.

There are other nits, but they can be dealt with later.
[Lucy] will correct them.

Thanks,
Lucy

Cheers

Bob

________________________________________________________________
Bob Briscoe,                                                  BT