Subject: [tsvwg] TSVWG Status

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 04 Feb 2014 17:57:34 +0000

The list below shows the status of the working group documents as we see 
it. Please check below and comment on drafts using the list. Please do 
send any corrections/omissions to the chairs.

Best wishes,

Gorry, David & James
(TSVWG Chairs)
Feb 2014

-------------------------------------------------------------------
Recently published:
draft-ietf-tsvwg-sctp-sack-immediately was published as RFC 7053.

-------------------------------------------------------------------
IDs in RFC Editor Queue:
http://www.rfc-editor.org/queue.html
draft-ietf-tsvwg-byte-pkt-congest - Document Shepherd: Gorry

-------------------------------------------------------------------
IDs in IESG processing:

None.

-------------------------------------------------------------------

WG Drafts with Chairs:
---
Adding Congestion Notification to Protocols that Encapsulate IP
draft-briscoe-tsvwg-ecn-encap-guidelines
- Note would be needed to ieee-ietf-coord
- WG Adoption call pending (early responses received).
---
‘Multicast UDP Guidelines’ as a BCP RFC - Document Shepherd: Gorry
draft-shepherd-multicast-udp-guidelines
- WG needs to consider draft(s) and identify reviewers.
-------------------------------------------------------------------

Active WG Drafts:
---
draft-ietf-tsvwg-rsvp-pcn - Document Shepherd: James
Replaces: draft-karagiannis-pcn-tsvwg-rsvp-pcn
DUE: New ID required to address RSVP model and then repeat WGLC
---
draft-ietf-tsvwg-rsvp-app-id-vv-profiles
Replaces: draft-polk-tsvwg-rsvp-app-id-vv-profiles
DUE: Reviewers are needed to prepare for a WGLC.
---
draft-ietf-tsvwg-port-use - Document Shepherd: Gorry
Replaces: draft-touch-tsvwg-port-use-00
DUE: Please read sections and provide feedback!
DUE: Next step WGLC
---
draft-ietf-tsvwg-natsupp-tsvwg - Document Shepherd: James
DUE: Authors please update following comments
DUE: Align to related draft on SCTP NAT.
DUE: Please comment on list
---
draft-ietf-tsvwg-sctp-prpolicies
replaces: draft-tuexen-tsvwg-sctp-prpolicies
DUE: Discussion needed on list.
---
draft-ietf-tsvwg-sctp-ndata
replaces: draft-stewart-tsvwg-sctp-ndata-03
DUE: Discussion needed on list.
---
draft-ietf-tsvwg-sctpnat
Replaces: draft-ietf-behave-sctpnat-03.txt
Former BEHAVE WG work item that defines SCTP NAT support
DUE: Authors please update to align to related draft on SCTP NAT.
---
draft-ietf-tsvwg-sctp-failover - Document Shepherd: James
Replaces: draft-nishida-tsvwg-sctp-failover
DUE: Please comment on list.
---
draft-ietf-tsvwg-sctp-dtls-encaps - Document Shepherd: Gorry
Replaces: draft-tuexen-tsvwg-sctp-dtls-encaps-01
DUE: Please comment on list.
---
draft-ietf-tsvwg-intserv-multiple-tspec - Document Shepherd: David
DUE: Discussion needed on list.
---
draft-ietf-tsvwg-requirements-update-00
Replaces: draft-ietf-behave-requirements-update-00
Former BEHAVE WG work item intended for publication as a BCP
DUE: Please comment on list
---
draft-tsvwg-gre-in-udp-encap
replaces: draft-yong-tsvwg-gre-in-udp-encap
DUE: New ID required to address issues.

------------------------------------------------------------------
The following have received recent discussion at TSVWG meetings or on
the list. Inclusion in the list below does not indicate support for
these specific drafts and other contributions are also warmly welcomed.
---------------------------------------------------------------
Authors request to be considered for adoption:
draft-shepherd-multicast-udp-guidelines  (see above)
draft-briscoe-tsvwg-ecn-encap-guidelines  (see above)
draft-geib-tsvwg-diffserv-intercon (revised ID needed)
draft-dhesikan-tsvwg-rtcweb-qos (revised ID needed)
-------

---

From: <[email-masked]>
Date: Wed, 5 Feb 2014 00:00:40 +0000

draft-IETF-tsvwg-gre-in-udp-encap
replaces: draft-yong-tsvwg-gre-in-udp-encap
DUE: New ID required to address issues.

http://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-00

I still have issues with the UDP checksum text; zero checksums with IPv6 poses problems for other possible recipients - port/address pollution that the rest of the internet has to protect against, basically. (RFC6936 states and details this problem, but gently; RFC6935 is all 'hey, tunnels performance is great!' and ignore the problem)

There was a long discussion on the mpls mailing list about the parallel mpls-in-udp draft and its checksum text. That draft text has been updated, discussion is still ongoing.

As there's author overlap between the mpls and gre drafts so editors are aware, I would expect to see similar updates here.

regards

Lloyd Wood
http://about.me/lloydwood

---

From: Lucy yong <[email-masked]>
Date: Thu, 6 Feb 2014 15:51:02 +0000

Hi Lloyd,

Yes, we plan to update the draft before the cut-off days to address the concerns from you and Lars and are aware of all the discussions in mpls mailing list. We will do our best to fact in the conclusion/consent from the discussions in the update. Thank you for the input.

Regards,
Lucy  

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, February 04, 2014 6:01 PM
To: [email-masked]; [email-masked]
Subject: [tsvwg] draft-ietf tsvwg-gre-in-udp-encap was RE: TSVWG Status

regards

Lloyd Wood

---

From: Lucy yong <[email-masked]>
Date: Fri, 7 Feb 2014 16:26:24 +0000

During WG adoption of the draft, we received comments about checksums and if this application follows the principles in RFC5405. Since then, there are massive discussions on mpls mailing list on the same concern in mpls-in-udp. Based on the discussion consent/conclusion, authors could like propose following changes in the gre-in-udp draft. 

Replace:

To simplify packet processing at the tunnel egress, packets destined
   to this assigned UDP destination port [TBD] SHOULD have their UDP
   checksum and Sequence flags set to zero because the egress tunnel
   only needs to identify this protocol.  Although IPv6 [RFC2460]
   restricts the processing a packet with the UDP checksum of zero,
   [RFC6935] and [RFC6936] relax this constraint to allow the zero UDP
   checksum.

With
To simplify packet processing at the tunnel egress, packets destined to this assigned UDP destination port [TBD] MAY have their UDP checksum set to zero. In the environment where the UDP packets may be mis-delivered [RFC5405], UDP checksum SHOULD be used. For IPv6, the considerations described in detail in [RFC6935][RFC6936] MUST be examined if UDP checksum need to be disabled for performance or implementation concerns. The Sequence flags MUST set to zero.

Replace:
   Note that the IPv6 header [RFC2460] contains a flow label field that
   may be used for load balancing in an IPv6 network [RFC6438].  Thus in
   an IPv6 network, either GRE-in-UDP or flow labels may be used in
   order to improve load balancing performance.  Use of GRE-in-UDP
   encapsulation provides a unified hardware implementation for load
   balancing in an IP network independent of the IP version(s) in use.

With:
   Note that the IPv6 header [RFC2460] contains a flow label field that
   may be used for load balancing in an IPv6 network [RFC6438].  Thus in
   an IPv6 network, either GRE-in-UDP or flow labels may be used in
   order to improve load balancing performance.  Use of GRE-in-UDP
   encapsulation provides a unified hardware implementation for load
   balancing in an IP network independent of the IP version(s) in use. However,
  if UDP checksum has to be used in an environment, a flow label based load
  balancing has advantage in term of performance and implementation.

comments are welcome.

Lucy on behalf of authors.

---

From: "Black, David" <[email-masked]>
Date: Fri, 7 Feb 2014 13:21:54 -0500

Lucy,

<WG chair hat ON>

I think this text is a good start, however, I'm concerned that it leaves
application of RFC 6935 and RFC 6936 as "an exercise to the reader":

> To simplify packet processing at the tunnel egress, packets destined to this
> assigned UDP destination port [TBD] MAY have their UDP checksum set to zero.
> In the environment where the UDP packets may be mis-delivered [RFC5405], UDP
> checksum SHOULD be used. For IPv6, the considerations described in detail in
> [RFC6935][RFC6936] MUST be examined if UDP checksum need to be disabled for
> performance or implementation concerns. The Sequence flags MUST set to zero.

I don't have a problem with that text, but I also don't think that it sufficiently
addresses the situation.

</WG chair hat ON>

Thanks,
--David

> From: tsvwg [mailto:[email-masked]] On Behalf Of Lucy yong
> Sent: Friday, February 07, 2014 11:26 AM
> Cc: [email-masked]
> Subject: [tsvwg] propose the text change in draft-ietf-tsvwg-gre-in-udp
> 
> During WG adoption of the draft, we received comments about checksums and if
> this application follows the principles in RFC5405. Since then, there are
> massive discussions on mpls mailing list on the same concern in mpls-in-udp.
> Based on the discussion consent/conclusion, authors could like propose
> following changes in the gre-in-udp draft.
> 
> Replace:
> 
> To simplify packet processing at the tunnel egress, packets destined to this
> assigned UDP destination port [TBD] MAY have their UDP checksum set to zero.
> In the environment where the UDP packets may be mis-delivered [RFC5405], UDP
> checksum SHOULD be used. For IPv6, the considerations described in detail in
> [RFC6935][RFC6936] MUST be examined if UDP checksum need to be disabled for
> performance or implementation concerns. The Sequence flags MUST set to zero.
> 
> Replace:
> However,