This message flow about ECN belongs in TSVWG - please do NOT cross post to the AQM list.
If you are interested in the end-to-end usage of ECN or rules for tunnels, etc then please do join the TSVWG list. Gorry --- > Joe, > > The approach of a BCP just about ECN doesn't preclude any of the > following options for stds track docs: > a) one RFC updating all tunnel specs about ECN > b) one RFC updating all tunnel specs about ECN and Diffserv (the two > fields that propagate up as well as down). > c) one RFC updating all tunnel specs about everything > d) one RFC per each tunnel spec to wrap up all updates around at the time > > These choices are for the relevant ADs and WGs to make. > Writing a BCP in TSV gives the raw info that any of these approaches can > use. > > > > Bob > > At 20:50 05/11/2013, Joe Touch wrote: > > >>On 11/5/2013 10:59 AM, Bob Briscoe wrote: >>>Joe, >>> >>>I envisage that a very brief standards track doc that explicitly UPDATES >>>the relevant IETF tunnel specs will be written, and it will refer to >>>this doc for rationale. >> >>Tunnels need to handle ingress/egress translation of all signals in >>the header. This is no different. >> >>My concern is that putting these recommendations in separate places >>gives an opportunity for different groups to have different >>interpretations of that sort of translation, and that's a bad thing IMO. >> >>Joe >> >> >>> >>>See Appendix A (outstanding items), which I have also highlighted when >>>presenting each time: >>> >>> 2. Consider whether an IETF Standard Track doc will be needed to >>> Update the IP-in-IP protocols listed in Section 4.1--at least >>> those that the IETF controls--and which Area it should sit >>> under. >>> >>>Does that address your concern? >>> >>> >>>Bob >>> >>>At 18:40 05/11/2013, Joe Touch wrote: >>>>IMO, these guidelines ought to come out in a single recommendation for >>>>tunnels; we had a draft of that in INTAREA but insufficient momentum. >>>> >>>>Piecemeal recommendations are likely to be ignored/lost. >>>> >>>>Joe >>>> >>>>On 11/4/2013 11:36 PM, Michael Menth wrote: >>>>>+1 >>>>> >>>>>We need such guidelines for consistent congestion management. >>>>> >>>>>Best wishes, >>>>> >>>>>Michael >>>>> >>>>>Am 05.11.2013 00:16, schrieb Matt Mathis: >>>>>>I think this is valuable work. Having a single document that >>>>>>describes the requirements and general principles will save future >>>>>>tunnel inventor/implementers from rediscovering the same bugs >>>>>> >>>>>>Thanks, >>>>>>--MM-- >>>>>>The best way to predict the future is to create it. - Alan Kay >>>>>> >>>>>>Privacy matters! We know from recent events that people are using >>>>>> our >>>>>>services to speak in defiance of unjust governments. We treat >>>>>>privacy and security as matters of life and death, because for some >>>>>>users, they are. >>>>>> >>>>>> >>>>>>On Mon, Nov 4, 2013 at 2:03 PM, Bob Briscoe <[email protected] >>>>>><mailto:[email protected]>> wrote: >>>>>> >>>>>> Folks, >>>>>> >>>>>> Pls respond if you support this being adopted as a work-group >>>>>> item >>>>>> in the IETF transport services w-g (tsvwg). The WG chairs need >>>>>> visibility of interest. >>>>>> Even better, if you're willing to read / comment / review / >>>>>>implement >>>>>> >>>>>> Guidelines for Adding Congestion Notification to Protocols that >>>>>> Encapsulate IP >>>>>> >>>>>><http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines> >>>>>> >>>>>> Abstract >>>>>> >>>>>> The purpose of this document is to guide the design of >>>>>>congestion >>>>>> notification in any lower layer or tunnelling protocol that >>>>>> encapsulates IP. The aim is for explicit congestion signals >>>>>> to >>>>>> propagate consistently from lower layer protocols into IP. >>>>>> Then the >>>>>> IP internetwork layer can act as a portability layer to carry >>>>>> congestion notification from non-IP-aware congested nodes up >>>>>>to the >>>>>> transport layer (L4). Following these guidelines should >>>>>> assure >>>>>> interworking between new lower layer congestion notification >>>>>> mechanisms, whether specified by the IETF or other standards >>>>>> bodies. >>>>>> >>>>>> >>>>>> [Cross-posting tsvwg & aqm, just in case] >>>>>> >>>>>> >>>>>> Bob Briscoe, >>>>>> also for co-authors Pat Thaler and John Kaippallimalil >>>>>> >>>>>> >>>>>> ________________________________________________________________ >>>>>> Bob Briscoe, BT >>>>>> _______________________________________________ >>>>>> aqm mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://www.ietf.org/mailman/listinfo/aqm >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>aqm mailing list >>>>>>[email protected] >>>>>>https://www.ietf.org/mailman/listinfo/aqm >>>>> >>>>>-- >>>>>Prof. Dr. habil. Michael Menth >>>>>University of Tuebingen >>>>>Faculty of Science >>>>>Department of Computer Science >>>>>Chair of Communication Networks >>>>>Sand 13, 72076 Tuebingen, Germany >>>>>phone: (+49)-7071/29-70505 >>>>>fax: (+49)-7071/29-5220 >>>>>mailto:[email protected] >>>>>http://kn.inf.uni-tuebingen.de >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>aqm mailing list >>>>>[email protected] >>>>>https://www.ietf.org/mailman/listinfo/aqm >>>>_______________________________________________ >>>>aqm mailing list >>>>[email protected] >>>>https://www.ietf.org/mailman/listinfo/aqm >>> >>>________________________________________________________________ >>>Bob Briscoe, BT >>_______________________________________________ >>aqm mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/aqm > > ________________________________________________________________ > Bob Briscoe, BT > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm > _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
