[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Flow label versus Extension header - protocol itself

On Fri, 6 May 2005, Erik Nordmark wrote:
Francis Dupont wrote: 
The point I'd like to make (and about which we should agree) is that
it is hard or impossible to keep full/real RFC 3697 compliance and
shim6 goal support, so if we decide to follow the flow label way the
best is to obsolete the RFC 3697 and to reserve the 20 bit field
currently named flow label to shim6 usage.


FWIW I disagree with this conclusion.

As I've stated in other emails, we can have a RFC 3697 compliant flow label usage for the communication using the ULIDs as locators, and when there is a need to use a different locator pair after a failure, we can have a different (RFC 3697 compliant AFAIK) usage of the flow label.

In all cases the <src locator, dst locator, flow label> would identify the flow. The fact that each locator pair implies a different flow is inherent in the desire to switch locator(s) when there is failure for the initial locator pair.

Agree with Erik. I see nothing "holy" with flow label. If we define it so that it matches RFC 3697 we should be OK. We'll just have to see how it looks like when a new proposal for the use of RFC 3697 comes along. They might be able to co-exist peacefully. There might be issues before or after a failure event. But if those are serious enough, the sites (and implementors) would just need to make the tradeoff which ones to support and how. But that's OK -- there are going to be multiple (and to some degree conflicting) uses of flow label in any case.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings