Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt

From: Margaret Wasserman <[email-masked]>
Date: Fri, 21 Dec 2001 17:38:41 -0500

Hi Hesham,

>=> Perhaps another way to look at this, is to
>come back to basics and say that the flow label
>is part of the IPv6 header, therefore it seems
>rational to let IPv6 WG define its use. 
>I don't see anything wrong with this, no other
>fields in the IPv6 header are defined by other
>groups.

This is acceptable to me, if it represents a consensus view
of the WG.  But, in this case, we should go all the way
and actually specify a useful flow label -- one that
could be used to look-up cached information on intermediate
routers without a signalling protocol, for example.

But, the current effort does not seem focused on
defining an actual use for the flow label.  We seem to
be focused on defining restrictions on the flow label,
without a specific use that justifies those restrictions.

Margaret

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Dec 2001 14:21:50 +0100

Margaret Wasserman wrote:
...
> without a specific use that justifies those restrictions.

No. The immutability property is necessary for both of the
existing QOS standards, and is necessary for any QOS mechanism
that doesn't require an explicit chain of SLAs along the entire
path (an unlikely scenario in a dynamically routed internet).

    Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 26 Dec 2001 12:01:59 -0500

>path (an unlikely scenario in a dynamically routed internet).

If immutability would make the flow label field useful for
diffserv and intserv, then I have no objection to it being
immutable.  I think that making intserv/diffserv more useful
and/or efficient would be a fine use for the flow lable.

Could we get a draft that explains how the flow label would be 
used for diffserv/intserv?  One that justifies the need for 
immutability?

Assuming that immutability would actually make the flow
label more useful for diffserv/intserv, I would accept the 
minor changes to the base IPv6 spec (adding immutability) that 
Tony sent.  But, I have not seen any draft that would make this 
single change.

The current draft (in the subject) says a lot more
than this.  First, it recaps parts of the IPv6 Appendix, 
without really making it clear what parts of that Appendix
it is (and is not) intending to standardize. 

The draft also states that a given source/desination/FL 
combination will uniquely identify a flow.  This is not
true -- some knowledge of lifetimes, or some restrictions
against flow label re-use would be needed to make this
true.  

Anyway, how a flow is identified shouldn't be defined as 
part of the base IPv6 specification.  Each signalling
(or other flow management) mechanism should define how
flows are identified for its use -- and this may differ
for different mechanisms.

So -- what I'd like to see:

         - A draft that explains how the flow label 
                 would be used for intserv and/or
                 diffserv that explains what properties
                 are necessary for that use (i.e.
                 length, immutability, values, etc.)
         - A draft that proposes the simple change
                 to the IPv6 spec that Tony sent.

Do you think that is reasonable?

Margaret

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 11:49:18 +0100

Margaret,

First, I agree - the normative text needed is very short (Tony's 
paragraph) and the current draft can be confusing (I can say that
since I was a co-author of the previous version:).

Second- both intserv and diffserv already document their use of
the flow label. For intserv it's in RFC 2205 (only slightly out
of date). For diffserv it's in the MIB (queued up at the RFC
Editor). For intserv, the flow label is an optional part of
a Filter_Spec, i.e. it needs to have the same value all along
the path since the Filter_Spec is signalled along the path
by RSVP. For diffserv, the flow label is the only field available
as an ISP-independent QOS flag, so (unlike the traffic class)
it needs to survive ISP boundaries.

  Brian

---

From: Alex Conta <[email-masked]>
Date: Sun, 30 Dec 2001 11:36:16 -0500

Some additional information on the use of the IPv6 flow label with
"Diffserv" is in:

 draft-conta-diffserv-ipv6-fl-classifier-01.txt

submitted to the "diffserv" WG.

Alex

Brian E Carpenter wrote:
> 
> Margaret,
>
> For diffserv it's in the MIB (queued up at the RFC
> Editor). [...] For diffserv, the flow label is the only field available