Alex,
I am responding because you sent the email to me directly.
At 08:52 PM 8/23/2001 -0400, Alex Conta wrote:
>Brian, Bob,
>
>I respect very much the IPv6 WG, the WG's chairs, and the participants
>to the thread that Brian
>started, in an effort to move in the right direction.
Thanks you.
>But in my opinion -- perhaps as usual, less politically correct than
>Brian -- I do not think that the IPv6 WG has a choice, that we have a
>choice.
The IPv6, or any other working group for that matter, always have any
choices. The process is driven by "rough consensus". The scope of a
working group work is defined by it's charter.
The only mention of the flow label in the new IPv6 w.g. charter recently
approved by the IESG is:
The working group would welcome contributions on the following topics
(this is not an exhaustive list):
- Flow label standardization
.....
This is far from saying the working group must do something. Many working
groups do less than their charter :-)
>IPv6 is not X's, or Y's IP. It is IETF's IPv6, in fact, everybody's
>IPv6.
>
>This puts a tremendous responsibility, but also demands a certain code
>of conduct, or direction of thinking for all of us. If that is not
>captured in the charter, I think it should.
>
>The IPv6 WG is not a preferential club, or an exclusivist group. The
The chairs try to keep the working group process open and fair.
>IPv6 WG is not to tell the IETF what standard is good and what standard
>is bad. While the IPv6 WG develops IPv6, IT MUST ENSURE that IPv6 works
>with, and it supports the other IETF standards.
I don't think your statements are correct. There is not a formal IETF
requirement that the working groups output support all other IETF standards.
>Intserv, and RSVP completed work (WGs closed). Diffserv started is well
>on its way. They are TWO IETF models for IP QoS, and are both on the
>IETF standards track.
Correct. There may also be new methods for IP QoS defined in the
future. If I remember correctly, Diffserv was created after the scaling
problems with Intserv/RSVP were better understood.
>So, in terms of mechanisms to be standardized for the IPv6 flow label,
>it is no question in my mind that right now WE MUST DO:
You are, of course, entitled to your opinion.
>c) - standardization of the flow label for IP QoS, e.g. Intserv, and
>Diffserv.
>
>The choice is the user's, e.g. end users and network providers, to use
>or not, one (Intserv), the other (Diffserv), or both, when deploying
>IPv6.
"c)" is one of the choices being discussed on the mailing list. From my
read of the list, I don't see a consensus on any of the choices.
>Furthermore, personally, I think that if the IPv6 flow label would have
>been done right, we would not have MPLS, and IPv6 would have given even
>more reasons to be adopted/deployed.
I do not agree with this statement and would note that it ignores the use
of MPLS for IPv4. IPv4 does not have a flow label field.
>At this point is too late, if for no other reason than just that MPLS is
>a IETF standard on its way, and its own right, and that with the current
>IPv6 header format, the flow label cannot match the efficiency of all
>MPLS's features anyway.
MPLS will swim or sink on it's own merits. I don't think this has much to
do with IPv6.
>As I think that no standard should be excluded, I think that IPv6 WG
>should do its best, to make IPv6 work well, friendly with MPLS. Which is
>in a way [a subset of a)]+c).
The IETF creates a lot of standards. They cover all parts of the protocol
stack. Did you really mean to include all of them in your assertion? For
example, I bet we could figure out way of including of encoding a DNS name
in the flow label field to improve the performance of reverse
lookups. Email addresses? Perhaps you only meant to include MPLS, Diff
Serv, and Int Serv standards in your assertion.
In this case, I don't think that the w.g. has to do this (i.e., MUST). I
think we could standardize a specific use of the flow label field (beyond
what is in the current RFC) if there was a compelling technical argument
made and there was a rough consensus around that approach instead of the
other choices. However, it will have to a reason more compelling than
other IETF working groups have standardized something.
Bob
p.s. For what it is worth, my current thinking is that I would prefer not
use the flow label field for any specific QOS approach(s). I am open to
something that makes it easier to identify flows. This could be used for
QOS or other flow related applications.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
