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

Reply via email to