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

From: "Glenn Morrow" <[email-masked]>
Date: Fri, 21 Dec 2001 09:02:31 -0600

IMO, you are absolutely right. To pin it down to one specific use would in
effect limit its use (i.e. reduce extensibility of IPv6). 

We should also learn from past on the mutability question in that if there
is an economic incentive for functionality that requires that a field be
mutable under certain circumstances, it will be. Putting something in an
standard that says a field is immutable has proven to acheive nothing.

I am not apposed to someone saying the field can be used for "function A"
and the field is IMUTABLE when used for "function A", but to limit the
fields use only to "function A" would be quite unrealistic given the past,
in my opinion  - especially without detailing the necessary signaling
semantics of using it for "function A". 

If "function A" wants the field immutable so be it. The signaling for
"function A" needs to convey the mutability rules to affected parties either
implicitly or by optionality. 

Thanks,

Glenn

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Thursday, December 20, 2001 10:50 AM
> To: [email-masked]
> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt
> 
> 
> 
> 
> Hi All,
> 
> I am wondering why we should specify the use of the flow label as
> part of the base IPv6 specifications at all.  Why do we need
> these rules as part of IPv6?  
> 
> The flow label does not, by itself, provide any useful information
> that a router can use to classify a flow and/or optimize packet
> handling.  In fact, without knowledge of a specific signalling
> mechanism or flow-establishment mechanism, the router can't
> use the flow label for anything at all.  For example, a router 
> cannot use a flow label for QoS queuing or to optimize hop-by-hop 
> header processing, unless the router is aware of the signalling/
> flow-establishment mechanism in use, since it will not 
> know the flow lifetime.
> 
> Any rules governing how the flow label is chosen, modified,
> authenticated and/or interpreted will be specific to the 
> signalling/flow-establishment mechanism in use.  And, all of 
> the nodes/routers that are utilizing one of these mechanisms
> will be aware of the mechanism.
> 
> So why not specify the semantics/use/etc. of the flow label as
> part of the signalling/flow establishment protocols?
> 
> The IPv6 specifications could merely include the current rule:
> 
> "Hosts or routers that do not support the functions of the Flow Label 
> field are required to set the field to zero when originating 
> a packet, 
> pass the field on unchanged when forwarding a packet, and ignore the 
> field when receiving a packet." [from RFC 2460].
> 
> This rule should properly protect the flow label, so that
> signalling/flow-establishment mechanisms can use the flow
> label, as needed by the specific mechanism.
> 
> 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: Sun, 23 Dec 2001 16:16:48 +0100

Glenn Morrow wrote:

> If "function A" wants the field immutable so be it. The signaling for "function A" needs to convey the mutability rules to affected parties
> either implicitly or by optionality. 

This is broken. You can't signal to routers that aren't aware of
the "function A", because they won't be aware of the relevant
signalling either. Also, we need to be able to construct signalling-free 
solutions (such as diffserv) for scalability.

Immutability is the only viable answer.

  Brian

---

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

Of course the deployment of a certain type of flow setup and flow
processing mechanism can be done only with devices that are supporting
it. The fact that a device supports a certain mechanism or not does not
make that mechanism "broken" (If for any reason, you cannot use OSPF on
a router, does not make OSPF broken). 

If mutability has a lesser application in some cases, prohibiting its
use in all cases, for instance at a local scale, or intra-domain scale,
is an unnecessary overkill. 

Accepting mutability, when specifically indicated by the flow setup and
flow processing mechanism, does not exclude signalling-free solutions -
the default "behavior" can be "immutable".

Alex