IETF-77, Anaheim, CA, USA TSVWG 1300-1500 MONDAY, March 22, 2010 WG Chairs: James Polk Gorry Fairhurst Notetaker: Dave Borman Chairs Agenda Bashing NOTE WELL Document Status and Accomplishments 0 RFCs published since IETF 76 2 IDs in RFC Editor Queue now - An EF DSCP for Capacity-Admitted Traffic - RSVP Extensions for Emergency Services Norm. ref to router alert draft (in the INT-area WG) IDs in IESG processing draft-ietf-tsvwg-rsvp-l3vpn draft-ietf-tsvwg-rsvp-proxy-approaches draft-ietf-tsvwg-port-randomization Magnus provided an update on the current status of the IESG documents. L3VPN will require another revision. Port randomisation also requires another revision. Francois: The Proxy draft has been revised and hoped satisfy the issues raised in Cullen's AD discuss. The milestones were reviewed (see status slides) Lars noted there was an RSVP-related TSVAREA discussion on RSVP later in the week. The intent of this discussion was to see if there was consensus and energy to work on future RSVP extensions. The topic of RSVP has been brewsing for a while, there have been a number of RSVP documents that have been difficult to get reviewed. Some documents seem to be too severe to call them minor extensions. We need to have a sizable community to get consensus. The TSVAREA meeting will discuss what can be done. The current meeting agenda was bashed. 2. WGLC Feedback * Michael Tuexen - DTLS for SCTP (draft-ietf-tsvwg-dtls-for-sctp) WGLC revealed some editorial comments and issues that had been addressed. There had also been some harmonisation with the DTLS?DCCP draft. There was also some updates to a normative reference. A new revision was uploaded, and would now be given SECDIR review, and after any changes needed, is expected to be sent to IESG. * Bob Briscoe - Layered Encapsulation of Congestion Notification (draft-ietf-tsvwg-ecn-tunnel) The document was currently in WGLC. There had been 4 revisions since the last IETF. A security directorate review has been requested during the WGLC. David: The point about the change in marking in this draft was that a CE marking is the equivalent of a drop in TCP. The most likely use of ECT(1) is with PCN. This is a lower level mechanism that does not justify the same response as for CE. Gorry: The WG last call is still on-going - please do respond to the list. 3. WG Drafts * Magnus Westerlund - IANA Procedures for Management of Transport Protocol Port (draft-ietf-tsvwg-iana-ports) There has been feedback and the document is being revised. There were interactions with draft-gudmundsson-dnsext-srv-clarify, both update RFC 2871. The authors do not want to hold up this document for that draft. Dan Wing: We have lots of fantastic transports that need to run over UDP, such as SCTP - is this the right place to declare these? Joe Touch: Many protocols have multiple layers. At the moment these define everything above the transport. This is not in the document. Today service is everything above the transport. Is that useful in the future? Yes. Is that part of this? No. Dan Wing: In my world, the future is here. Stuart Cheshire: It may seem attractive to internal identifiers, although this is not attractive. We should describe a bundle of technologies, e.g., HTTP over TLS over TCP. Magnus: There are also services that sometimes run over UDP. Joe: There is not a huge difference between TCP over of encapsulated, the port means a single thing, since a port is a single number, and that is all you can do. If you do not see the identifier, it does not mean anything. I do not see this encapsulation is much different to the use of http to support many services. Magnus said the document editors would meet this week and agree things to prepare a new revision of the ID. * Michael Tuexen - SCTP API (draft-ietf-tsvwg-sctpsocket) This is now revision 22. The work has been going on over 10 years. The authors include the linux, solaris, and freebsd maintainers of SCTP and the last review by authors raised several issues. Current status: o Incorporated many editorial changes o Review by authors o Some outstanding issue brought up by the review o Another revision is needed - there are open issues. James (from floor): Given things have evolved. What would happen if we did not make this an RFC? Would the API be different in 5 years? In other words, how many changes would it be nice to make in future? Lars: We probably should have issued a revision every 2 years and obsoleted the previous one. Randall: We learned where the API was not extensible. This is useful and now more ready to add things. Lars: When can we publish this? Randall: We need agreement between implementors. Michael: Once we have agreed on the next revision, we will ask for WGLC. Lars: Sometimes we have to just let it go. It is OK to say that not all implementations follow the document. At some point we just need to publish. * Randall - Stream Reset (draft-ietf-tsvwg-sctp-strrst) Status: o Incorporated comments form the Linux SCTP maintainer o Incorporated editorial changes o Updataed all example message flows o Added a socket API section The authors think this is ready for WGLC. Brian: I looked at the document from an IPFIX viewpoint. Gorry: The chairs would like to know that there are reviewers before we move this to WGLC. If people are interested in seeing this progress, please tell the authors or chairs. Could the document authors help by providing some people who would review this in a WGLC. If we find suitable reviewers, we could consider taking this to WGLC. * Bob - Byte and Packet Congestion Notification (no talk) draft-ietf-tsvwg-byte-pkt-congest * Francois - RSVP Group keying 5 min draft-ietf-tsvwg-rsvp-security-groupkeying Francois: This had a SECDIR review comments and this will now need a new revision. Gorry: Although there is consensus to proceed by the group, we may need a short WGLC to confirm the final text prior to submission to IESG. Non-WG Drafts (NAT-Related Drafts) * NAT for SCTP 10 min (draft-ietf-behave-sctpnat) (draft-stewart-natsupp-tsvwg) Chairs: Who has read the draft? - 2 people. Dan: If the client supports this, and the server does not, what is meant to happen at the client? What does this mean to be multihomed behind a NAT? Michael: If the server does not support it, you can set up single homed setup. Randal: You lose functionality when you use this option if the server does not support it. Dan: You do need to always do this. This kind of breaks the ability to multihoming. This may not be designed right. It is important that you can not know if you are behind a NAT. Randall: This is a per destination question. You can not multihome behind a NAT. Matt: We need a "before and after table" to clarify what happens if this deployed. Joe: Multihoming already did not work from behind a NAT today, so there is no change. Chairs: We need the draft to contain text to reflect this TSVWG discussion, a revised document that people can sign-up to would help in assessing WG adoption. * UDP encaps for SCTP 10 (draft-tuexen-sctp-udp-encap) o Document is incomplete o Describes the BSD implementation. There are a lot of SCTP specific changes for SCTP over UDP, mainly because SCTP is multihomed and UDP is not. Lars: There are other proposals, so I want to push back on the question about interest in this ID. There can be either generic encapsulation, or transport-specific. But not both. Please let us not do all possible options just because we can! Michael: To get a working solution, there are protocol specific things, that need to be addressed in a generic way. Lars: We need to do either generic, or specific, but not both. Lars: We need to see if there are opportunities to define one encapsulation or several. There may be merits in one common approach. * UDP encaps for DCCP 10 min (draft-ietf-dccp-udpencap) Pasi presented on behalf of Tom Phelan. Please read the draft and send comments to DCCP mailing list. Gorry: If you use the UDP length field, you are hypbridizing UDP and UDP-Lite… We should think seriously about that, before pushing it forward. Magnus: Not having UDP length consistent with actual length is a sure way to have it shut down. In reality, partial checksum is hard to use, and not support this when using UDP encapsulation. Lars: We have already had this discussion about UDP-Lite using the UDP port. Gorry: What would be pain in coming to a common solution, i.e. straight UDP encapsulation or generic, such as GUT? Randal: In BSD, we just spliced a header on inbound/outbound. Generic mechanism add some additional glue that we do not think is necessary. Jukka: The GUT approach works for other protocols and provides support for IPv4 options using the encaps. The basic idea of the GUTS spec is to tunnel any IP payload and to try to handle IPv4 options in a proper way. How special is this for SCTP? Michael: How do you handle multi-homing and with encaps? Magnus: You need to define ports - you ca not expect specific ports to be available with NAPT. You need to have agility to work on any port. Pasi: Doing a generic approach could take a long time. Michael: Can a DCCP app work with a UDP header? Pasi: Probably, but not the current proposed method and I am not the author. Gorry: It seems the DCCP WG has decided to work on UDP encapsulation, but TSVWG has not yet made any decision about whether to support SCTP. Is it important to do this work to allow SCTP to work over UDP? Matt: I think this is important. Chairs: Does the WG support work on UDP encaps for SCTP (without considering any specific approach)? There was a hum to support this work. There was no hum opposing this as a topic for work. Lars: If we have two specific versions, then we can decide how much coordination we need. But do we want a single generic solution, or multiple protocol specific solutions? Gorry: We need more people to discuss this. We can move both docs forward, but we need discussion and the authors to talk and decide if the wire method for encapsulation using UDP could be common for both SCTP and DCCP (and other transports). Non-WG Drafts (if time allows) * Gorry - IPv6 UDP Checksum Considerations (draft-fairhurst-tsvwg-6man-udpzero) The document now contained a set of issues and requirements for things that would need to be considered by any method modifying the IPv6 checksum. This was being taken to the 6man WG to see if it could progress there. * Michael - SCTP Chunk Flags (draft-tuexen-tsvwg-sctp-chunk-flags-00) This document updates IANA procedure for Chunk flags and creates new registries. Chairs: Who supports adopting this ID as a TSVWG work item? Support for adopting as a WG Item. No-one was against adopting this as a work item. The document authors will consult IANA on best way to format the registry text. It seems the document has support, but we will take the question of adoption to the list and confirm if there is any negative feedback. * Xiangsong - SCTP extensions for SigTran (draft-cui-tsvwg-snm-ps-00.txt) (draft-cui-tsvwg-assoc-changeover-00.txt) Lars: Sigtran is working in the RAI area. What does this ask us to do? Michael: It is more dealing with SCTP issues, Lars: What is needed - what impact does this have? Randall: We need to explain the connectivity case. Michael: Do you want to avoid message loss? Can you accept duplication? Lars: You can also avoid loss by duplication, without the need to change SCTP. Xiangsong: We want to avoid duplication for charging, etc. Lars: I want to gauge if this is important enough to justify work in this working group. * Francois - RSVP Extensions for Flexible Resource Sharing (draft-narayanan-tsvwg-rsvp-resource-sharing) Want to have different associations share resources. e.g., call waiting when switching between calls, only one will use resources at a time. James: What is needed to be done? Fracois: We would like to see this progressed in CCAMP End of meeting.