Date: Thu, 20 Dec 2001 17:16:58 +0100
From: "Hesham Soliman (ERA)" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
| I was arguing
| against letting the default routers set the
| flow label and I was saying that 'it' (setting
| the flow label by default routers) should not
| be allowed, or at least not unless somehow
| it's restored before the packet is delivered to
| the receiver, as per draft-rajahame....
Well, the draft, as it exists now at least, allows for just the opposite
(in 2 specific cases). Certainly allowing any more than the two it
allows would not be agreeable with me, but I'm not certain that I can
see a reason to expressly prohibit those two.
Which isn't to say that I can think of a good reason to support them
either - other than that I don't like to prohibit something for no better
reason than that I don't understand it.
| => Well the assumption here of course is that
| applications know nothing about the flow label,
| which is fair, considering that it has not been
| defined yet. However, once it is defined, I can't
| see why we can't add it to the API and allow it
| to be set by the applications.
Of course. I haven't gone to check, but I'd be surprised if the
API isn't already there - just unused as no-one knows how to use it
yet.
But once applications exist, and work (for some definition of work)
getting them all upgraded to use new functionality is a very difficult
thing to achieve.
| Alternatively another part of the stack may also choose to set it.
Yes. But don't you see how similar this is to having a router set it?
In either case, it won't (shouldn't) be altered if it has been explicitly
set by the application, but assuming the existence of a "not set to anything"
or if you like "I don't care" value (which is the 0 value currently),
if there some particular reason it makes a big difference whether something
down the stack change it, or whether a router does? In either case, when
the packet arrives at the destination application, it has been changed.
Of course, once altered by anyone, it is no longer at the "unset" value,
and can never be altered again (the other "explicit permission" exception
assumed not to apply)
| => So I guess you're arguing for allowing the
| case where routers can modify the flow label
| from zero to X. But should we then force them
| to set it back to Zero again ?
Yes, that's it - though "arguing for" is perhaps too strong,
"arguing against prohibiting" would be better.
And I can't imagine why.
| I'm just wondering if there will be any confusion
| if the receiver gets a flow label set to X when
| the sending node didn't intend to set/use the
| flow label at all.
I can't think of any reason why it should - I can imagine a receiving
node requiring a flow label to have been set, if it wants to believe
that some specific service quality is somehow being delivered to it,
which an unset label would pretty much guarantee isn't happening, but
I can't imagine why it would care that it explicitly wasn't getting
anything special.
That is, I wouldn't often expect SMTP senders to set flow IDs for most
mail - but nor would I expect a SMTP receiver to object if some sender
decided its mail should get some special treatment.
In general, Tony Hain's arguments are pretty persuasive to me ... but I
am not sure that I would go as far as to prohibit all changes to the
label - though the only ones I would allow are where the source has
explicitly said that changes are OK (which an initial label of 0, or
we could reserve FFFFF for the purpose, could be defined to do, and some
flow state setup mechanism could also do).
Also, everyone please note, just in case it isn't already clear. When
anyone says the field needs to be immutable (in this case anyway), it
isn't (really) because anyone cares what value is delivered to the
recipient node - it is that we want to know what value will be observed as
the packet passes through each routing domain along the path. That's
important. It just happens that this is equivalent to saying that the
field must not be modified (perhaps with some specific exceptions).
Lastly, wrt Margaret's question/suggestion - I think that the IPv6 group
needs to define the basic parameters of the field. If that isn't done
there are no guidelines for others to use to know what they can and cannot
assume. In particular, there's nothing to prevent incompatible specs
for the use of the field being developed - ones so incompatible that there's
no way to accommodate both in the internet (and yet perhaps no global way
to prefer one over the other). So, I certainly feel it is appropriate for
this WG to say whether, and if so when, this field can be modified by routers
along the path.
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
