Brian,
Diff-serv itself is a sort of signaling and the field it operates on is mutable is it not? I hope you at least agree that is is either configured or signaled. I believe you can signal to routers and have routers that are not configured or capable of handling the signaling ignore the signaling. IPv6's option definitions were designed specifically for this filtering function.
So I guess what I'm saying is, the example you gave to indicate that the fields should be immutable is not immutable itself and so I don't think the reasoning holds up. Making the field mutable or not is disjoint from the signaling or configuration argument in order to act on a field. With diff-serv you either configure or signal to set up the behavior of its operational field. The merits of configuration vs signaling might be argued but IMO configuration (especially remote configuration) is a form of signaling as well. I do see value in out of the box schemas for on-net solutions; however, I don't think mutability will thwart this ability or desire as long as the signaling or subsequent configuration can change the default schema.
I also don't understand why people are so terrified of mutability of certain fields. The original point was that if there is a business reason to make a field mutable or not, it will be mutable irrespective of what an RFC says. It seems to me that making things immutable reduces the use of the fields in question from a functional perspective. Mutability with signaling and at least configuration seems to increase flexibility and extensibility. It seems to me that for the long term we should not try to restrict the use of fields but rather detail the use and expectations for particular applications as their need arises. I don't see a problem with an RFC saying, "for this particular network layer service, the field is expected to be immutable as it traverses certain parts of the network or the whole network". But this would be for just one type of network-layer service and would leave the door open for other uses in the future.
regards,
Glenn
> -----Original Message-----
> From: Brian E Carpenter [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, December 23, 2001 9:17 AM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: Margaret Wasserman; [EMAIL PROTECTED]
> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt
>
>
> 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
>
>
>
