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

[Bob Briscoe <[e-mail]>]

Lucy,

I'll wait for David's promised proposal to the list before commenting 
on the checksum issue.

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.

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.

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)

There are other nits, but they can be dealt with later.


Cheers


Bob




________________________________________________________________
Bob Briscoe,                                                  BT