Jarno,
As diffserv WG co-chair I have been making the argument why diffserv
will work better with an appropriate format of flow label throughout
this discussion, and I think it has been shown that diffserv *does*
need such support in the case of ESP headers.
Brian
[EMAIL PROTECTED] wrote:
>
> Alex,
>
> I don't think it has been shown yet, that the diffserv architecture actually
> needs any specific support from the IPv6 flow label. While the
> MF-classification is mentioned in the diffserv architecture, the value of
> that on the administrative boundaries is less than clear.
>
> An SLA between two domains could well be specified to only consider DSCP
> values, and the associated PHB, volume, charging, etc.
>
> Could someone please explain why this could not work, and what specifically
> is the value of signaling the PHB in the flow label field?
>
> Jarno
>
> > -----Original Message-----
> > From: ext Alex Conta [mailto:[EMAIL PROTECTED]]
> > Sent: 24. elokuuta 2001 3:52
> > To: Hinden Bob (IPRG)
> > Cc: Brian E Carpenter; ipng
> > Subject: a), b), c), d), or e)
> >
> >
> > 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.
> >
> > 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.
> >
> > 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
> > 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.
> >
> > 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.
> >
> > 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:
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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).
> >
> > Regards,
> > Alex
> >
> > P.S. Please note that MPLS labels are forwarding handles,
> > that can also
> > include a QoS hint
> > (Intserv, or Diffserv).
> >
> >
> >
> >
> > Bob Hinden wrote:
> > >
> > > Brian,
> > >
> > > At 08:45 AM 8/16/2001 -0500, Brian E Carpenter wrote:
> > > >I think the WG needs to decide once and for all whether
> > the flow label is
> > > > a) a CATNIP or MPLS-like routing handle
> > > >or b) a QOS hint for intserv only
> > > >or c) a QOS hint for intserv and diffserv
> > > >or d) a waste of bits
> > >
> > > I would like to suggest another choice:
> > >
> > > e) a set of bits we hold in reserve for the future
> > >
> > > I don't think that we have enough experience to pick
> > between a), b), or c)
> > > now, and think that something might come up in the future
> > where 28 bits in
> > > the IPv6 header might be very useful. This might not have
> > anything to do
> > > with QOS.
> > >
> > > Bob
> > >
> > > --------------------------------------------------------------------
> > > 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]
> > >
> > --------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
