Tony Hain wrote:
>
> Alex Conta wrote:
>
> In fact, diffserv can't get the job done across multiple domains in
> the presence of ESP. There simply are no visible bits with well-known
> semantics to base the decisions on. Allowing the DSCP to be mutable was
> explicitly the work of the diffserv WG, and therein lies the reason you
> are looking for another set of immutable bits.
>
I think you are talking about tunnel mode ESP, and Brian talks about
transport
mode ESP.
Brian's reason to use the flow label is for M-F classification, with
transport mode
ESP. Ports and protocol ID, are encrypted, while BA classification, can
still
be done, since the DSCP is in clear.
The tunnel mode ESP is a completely different beast, I have not looked
at
that in detail, since it is beyond the scope of the Carpenter/Conta
proposal.
> > Ad absurdum, if the routers in a domain, do not know, or there is no
> > mechanism to know,
> > but they can have a use of a mutable flow label, then they would work
> > together, and have the egress restore the original value when packets
> > leave the domain.
>
> Talk about ambiguity, what is the point of rewriting the flow label
> only to restore it later? Even if you wanted to, where is the protocol
> that communicates the value from edge to edge?
>
A model is there: MPLS label distribution, which includes RSVP-TE.
> > That working group does not standardize the IPv6 headers.
>
> They wrote RFC 2474 didn't they. As far as I can tell that means they
> are responsible for the content of the TS field.
>
> Tony
Likely, Brian can answer this much better than I can, since I have not
been
involved in the Diffserv architecture work.
To me it is simple: I see the IPv6 main header divided into functions
for forwarding,
and functions for QoS. The 8 bit TS is part of the QoS fields, and is
the Diffserv BA classification field, similar between IPv4, and IPv6 -
great similarity/compatibility achievement, from model, architecture,
specifications, to implementation in devices, and practical use by
providers, and providers' customers.
The 20 bit flow label is also a QoS field, which up to the
Carpenter/Conta proposal
was a field defined normatively for QoS, and non-normatively for
Intserv/RSVP.
There is conceptual similarity between Intserv non-flow label based
classifiers, and Diffserv M-F classifiers. Intserv classifiers can use
the flow label, and so could the Diffserv M-F classifiers, in which case
they would share the 20 bit space.
It is late here, so please bear with me...
You seem to see the problem in terms of bit allocation.
You seem to say that the Diffserv architecture should accommodate all
its functions in 8 bits for IPv6, because the TS is all that DIffserv
would ever get, and that is because the 20 bits of the flow label, used
by Intserv, are too precious to share with Diffserv.
OK, so the alternative that you suggest, means to have the DIffserv WG
rework a completely different Diffserv model, mechanisms, architecture,
specifications which some are already on the standards track, IETF
marketing, etc... for IPv6.
This means dropping, the model, architecture, mechanisms,
implementation similarity/compatibility between IPv6 and IPv4, and
dropping the complete similarity or commonality of the user/provider,
and provider/provider model between IPv4, and IPv6, and all the other
implications.
Is that what you really mean?
Alex
Alex
S/MIME Cryptographic Signature
