[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Diffserv] Diffserv and Tunnels issues for discussion
At the end of the DC meeting I promised to post the questions
on the last slide of the Diffserv and Tunnels presentation
for further discussion. The current draft is
draft-black-diffserv-tunnels-00.txt, and the intent
is to use the comments from this discussion to revise
that to a working group draft and submit that within
the next few weeks. So, here are the questions
that were on the final slide plus some explanations:
Is keeping DSCP only in IP headers ok?
This is about whether to specify things like a
tunnel ingress traffic conditioner that spits
out two DSCPs (inner and outer headers) or a tunnel
egress traffic conditioner that takes two DSCPs as
part of its input. Such conditioners would complicate
the diffserv conceptual model, and are difficult to
impossible to implement for some tunnels (e.g., L2TP).
Set to zero or class selector as simple TC?
This concerns situations in which full traffic conditioning
support is undesirable for some reason (e.g., need to muck
with the inner IP header's DSCP after encapsulation). What
should we recommend to tunnel implementers as something simple
to deploy if they can't or don't want to put in full diffserv
traffic conditioning? The draft suggests the ability to
zero the DSCP or set it to one of the class selector DSCP
values. Another alternative would be to set to any DSCP
value (fixed by configuration).
Egress selection approach ok?
This refers to the rationale in the draft that tries to make
the case that although there are always two DSCPs at a tunnel
egress, it is usually the case that only one of them contains
interesting information. Hence the draft describes configurable
support for selecting one or the other DSCP. Is this rationale
and approach reasonable?
Egress selection operators - right ones?
The draft describes four selection operators. Of particular
interest here is whether the convention of using the DSCP value
000000 as a possible "escape" (meaning "see the other DSCP")
is a reasonable and useful approach.
What to recommend?
The draft is currently more of a survey than anything else.
It needs a short section of crisp recommendations for the future
tunnel RFC author whose AD tells him/her that diffserv has
to be considered in the design. What SHOULD that author do?
Any other comments? IPsec? Translators?
I've received a few interesting offline comments. Tunnels
span a surprisingly broad spectrum, and I've had two different
people tell me that for the sort of tunnels they think about,
only one of the two conceptual tunnel models (uniform and pipe)
makes sense -- but it was a different model in each case :-).
Hence, I think both models stay, but if there are better terms
for them that are already used in other contexts (e.g., I
think I've heard the "pipe" model referred to as a "virtual
wire"), I'm open to suggestions.
In addition, some people have pointed out that MPLS and layer
2 headers have some resemblance to outer headers in tunnels,
and hence also should be discussed. One important difference
here is that in contrast to the general IP in IP tunnel case,
it's much more reasonable to build traffic classifiers that
look at both the outer (MPLS or layer 2) and inner (IP) headers.
Finally, Geoff Huston promised me a strong opinion on the
subject of why and how the rationale in the draft is horribly
confused, even though the low level mechanisms discussed
are a more or less reasonable approach.
Ok, comments, please ... otherwise you run the risk of
me substituting my opinion for that of the WG ;-).
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA 01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
diffserv mailing list