TSVWG Agenda for IETF 66 (Montreal) Monday July 10th, 2006 0900-1130 Chair's 9:00-9:15 Agenda Bashing (15 min) - we switched two presos in order - Bob's re-ecn-apps wasn't submitted on time, but the topic is still in the re-ecn-tcp ID NOTE WELL Document Status and Accomplishments New Charter New Milestones Kwok - Aggregation of Diffserv Service Classes 9:15-9:25 draft-ietf-tsvwg-diffserv-class-aggr-00 (10 min) - reviewed changes to this version - all info should be in this doc, and not plan another follow-on doc - wants reviews (David Black had already agreed) - ADs stated Randy and Michael - SCTPbis and SCTP Padding Chunks 9:25-9:40 draft-ietf-tsvwg-2960bis-02 (15 min) - Randy discussed summary of changes - discussed summaries/reviews made - needs a final read - may be some additional XML changes no one has caught yet - asked for WGLC - to spur real reviews draft-ietf-tsvwg-sctp-padding-00 - summarized changes since last version - asked for WGLC Marushin - SCTP ASCONF Chunk Transmission Ext. 9:40-9:45 draft-marushin-sctp-asconfext-01 (5 min) - reviewed what this ID is about - this is an extension to SCTP ADD-IP - reviewed a scenario in which this idea applies (regarding a IPv4 and IPv6 addressing mismatch on each end of a e2e flow, ext keeps both v4 and v6 addresses on one side cached to make sure communications can remain up) - reviewed how chunks can be bundled between peers - Michael T. asked about scenario 1 in which node B need to keep its previous address, so the text here needs to be tighten - also, each chunk goes in one packet, and shouldn't be stored until there is X many - agreement was reached between Marushin and Randy/Michael about a max of one packet is the barrier for transmission, that multiple chunks can be in the same packet. - Peter discussed v4 or v6 address families - and that ADD-IP mobility could be addressed with this doc - look to incorporate into ADD-IP (which dropped two authors, making room for these new authors of ADD-IP) - Randy said this needs a review to see if incorporation is done right - then ADD-IP ready for WGLC Randy and Michael - SCTP Threats and Socket 9:45-9:55 draft-ietf-tsvwg-sctpthreat-00 (10 min) - summarized changes since last version - ready for WGLC after SCTP AUTH and ADD-IP draft-ietf-tsvwg-sctpsocket-13 - addressed changes in new version - doc ought to float around for a little bit of time before WGLC - security section needs to be tweaked a bit to account for one more thing - ought to be LC after SCTP AUTH, ADD-IP, Threats Francois - RSVP Extensions for Emergency Services 9:55-10:05 draft-lefaucheur-emergency-rsvp-02 (10 min) - reviewed changes since last version - covered how merging rules apply to multicast - moved informative text and examples to appendix - doc focuses on network layer capabilities - and not which flavor (for example, preemption or not) should or should not be used - these are the examples that are in the appendix, that are each spelled out - Janet Gunn supports this - Kimberly King supports this HUM for becoming a WG item 100% HUM against becoming a WG item 0% [NOTE: This hum has since been reviewed by the WG on the TSVWG list, with no voices against this acceptance as a WG item] Phil - Controlled Load 10:05-10:25 draft-briscoe-tsvwg-cl-phb-02 (20 min) draft-briscoe-tsvwg-cl-architecture-03 - review of what these docs are - showed doc map point to where each of the PCN docs fit into the overall architecture - John Loughley comment - mentioned that he and David Black came up with a better way of presenting this arch - the marking behavior - how bits are marked - how things are signaled - "other" things - Phil continued - Understanding Behavior - Investigating Algorithm - Fred commented: what he's observed is that two routers experiencing the congestion are on two ends of the same link, and that this shouldn't count as double the congestion when measuring. - Dave McDyson comment: suggested that the docs read like the routing of the flows are static, and not dynamic (i.e. changing LSPs). Make it explicit, not implicit. - Bob clarified that the QOS is decoupled from the routing, to the point of this being for the situation in which routing changes the path to where there is congestion (or near capacity) already Bob - Policing and Accountability for Causing Congestion on Borders draft-briscoe-tsvwg-re-ecn-tcp-02 10:25-10:45 - hopes to go to PS - reviewed updates since last version - didn't break out the application draft - mentioned that many off the list continue to break the models - Dave comment: is there an assumption of forward and reverse paths are taking the same path, and Bob said no, the feedback is e2e - Sally comment: asked if this plans on changing or redefining 3168 bits - Bob answered not anymore - room liked that answer - Discussed how bottleneck policers don't work - But that Re-ECN only policies at the ingress, with the egress providing feedback to the ingress - that encryption is a non-issue because RE-ECN is at the network layer - A version of DOS attack exists, and will be addressed in the next version - David Black comment: copying 3168 header to outer header is fine draft-briscoe-tsvwg-re-ecn-border-cheat-01 (20 min) - reviewed update since last version - policing at your domain's border, and not trust neighbor's network to policy what you have set to be denied - this is maybe once every 30 seconds vs. TCP which is every other packet - this is not saying this is how you must to contracts - goal is not to have SBCs by using this mechanism - Randy comment: SCTP and multi-homing might produce interesting results, Bob agreed - Lars comment: where does this work go? He thinks this is wider than the TSVWG can do (involving the Internet, Routing and Security Areas), so a larger discussion needs to start as to where this ought to go - and this list needs to be involved in that discussion. - Matt comment: that some of the authors and contributors are not part of the IETF, and remove any IETF list from the cc list on each message. - Aaron comment: asked that Bob come up with a 10 page summary ID covering what's in the 90 doc - to get folks interest (who will read a 10 page doc, when they likely won't read anything 90 pages). draft-briscoe-tsvwg-re-ecn-apps-00 **this ID didn't get submitted on time** Francois - RSVP Ext for Admission Control over DS using PCN 10:45-10:55 draft-lefaucheur-rsvp-ecn-01 (10 min) - discussed doc - the egress gateway signals back to the ingress gateway, inside the RSVP Resv message, the ratio of packets marked as experiencing PCN-congestion when transiting through intermediate routers. - defines a new object - the ingress gateway maintains a threshold on PCN-ratio for admission decision. - new errors codes are required to do this - this is a companion document to the two main PCN I-Ds (i.e. PCN Deployment Model, PCN Marking). Not asking WG status for RSVP extensions I-D as the two main PCN I-Ds are not WG docs yet Georgios - Resource Unavailability PDB 10:55-11:05 draft-karagiannis-ru-pdb-02 (10 min) - reviewed idea - this is without signaling - idea: using Diffserv to use throughout measurements and DSCP remarks to notify resource unavailability - can be used in combination with e2e ECN Bruce - A Proposal to Incorporate ECN and PCN in MPLS 11:05-11:15 draft-davie-ecn-mpls-00 (10 min) - reviewed idea - this is about marking bits of a particular type (EXP in MPLS) - ECT assumed throughout core, if assumption is right, packet is forwarded, if assumption is wrong, packet is dropped - use RFC 3270 for all packets marked with another codepoint - works everywhere except where there is all 8 PHBs (i.e. EXP bits) defined already - wants to be a Standards Track - on agenda in the MPLS WG, so there remains an open question which WG this ID should be in - Sally believe this should be a WG item, and prefers TSVWG, but Lars prefers MPLS because it is regarding MPLS. - Magnus comment: if PCN is removed, this ID will progress much faster, Bruce agreed and can do this VOTING RESULTS: draft-lefaucheur-emergency-rsvp-02 VOTE for becoming a WG item 100% VOTE against becoming a WG item 0% [NOTE: This hum has since been reviewed by the WG on the TSVWG list, with no voices against this acceptance as a WG item]