Hi, Bob,
IMO, the desciption of how IP header info (which is what I presume
you're suggesting) to impact L2s (which include tunnels) belongs in a
tunnel doc, which AFAICT belongs in INTAREA. The tunnel landscape is
already quite complex.
I have no idea why TSV would be involved in this except if you're
talking about TCP ECH markings, but IMO the relationship of the TCP mark
to the IP mark might belong in TSV.
However, I do not think TSV should be promoting having signals "jump"
layers, i.e., from TCP ECN to its impact on tunnels or L2.
Joe
On 11/6/2013 2:50 PM, Bob Briscoe wrote:
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
