Re: [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols?

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 <bob.briscoe@bt.com
>>>>><mailto:bob.briscoe@bt.com>> 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
>>>>>     aqm@ietf.org <mailto:aqm@ietf.org>
>>>>>     https://www.ietf.org/mailman/listinfo/aqm
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>aqm mailing list
>>>>>aqm@ietf.org
>>>>>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:menth@uni-tuebingen.de
>>>>http://kn.inf.uni-tuebingen.de
>>>>
>>>>
>>>>
>>>>_______________________________________________
>>>>aqm mailing list
>>>>aqm@ietf.org
>>>>https://www.ietf.org/mailman/listinfo/aqm
>>>_______________________________________________
>>>aqm mailing list
>>>aqm@ietf.org
>>>https://www.ietf.org/mailman/listinfo/aqm
>>
>>________________________________________________________________
>>Bob Briscoe,                                                  BT
>_______________________________________________
>aqm mailing list
>aqm@ietf.org
>https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,                                                  BT 