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

Re: Flow label versus Extension header - protocol itself

Hi Greg,

El 04/05/2005, a las 3:00, Greg Daley escribió:

Hi Francis,

Francis Dupont wrote:
In your previous mail you wrote:
Sorry to keep returning to this point.
=> so I return to my main concern too..
I'm not sure that this is necessary (changing 3697) or even desirable,
even for proponents of flow-label-as-shim6.
=> if we keep full 3697 compliance, the only thing we can do is to
improve the flow label allocation in the shim6-capable sending node,
mainly making them looking as unique (easy with less than 10^10
concurrent comminucations which should be the common case).
But what happens between two different sending nodes communicating
with the same receiver? They can use the same flow label value and
the same destination address: the receiver can distinguish between them
only with the source address. This works with multi-homing because
the lists of possible addresses per sender are known and do not share
a value, but this does not work with mobility where the next source
address is not predictable.
So IMHO RFC 3697 is not compatible with mobility when destination
options have no problem at all... 

Yes, this is the case.  If the existing 3697 (sender side) allocation
for flow labels is used, then explicit signaling to add each
<source,dest,label> to a multihoming context has to precede packet
delivery.


Maybe i am missing something here, but this is the case, independently of the mechanisms you choose to carry the context tag, because of security issues....

I mean when a node is adding a new locator into an established shim context, it must send an explicity message, informing of that new locator and including security information in order to validate this new locator. In this exchange used to add and verify the new locator, the receiver could inform the transmitter about the new flow label value (if needed)

So i would say that explicit signaling when adding a new locator is always needed.

a possible question would be if it would be possible to include the signalling in the same packet that carry the new locator as source address... i guess this depends on how you define the packet processing, but i guess it may be possible in any case.

regards, marcelo


So it is possible, but has undesirable properties.

The receiver based allocation scheme doesn't have this problem,
and preserves RFC3697 compliance on the originally homed path.

   Within the sender and receiver host, receiver side allocation
   causes some complexity, which may interfere with future uses
   (I guess it would be predictable though).
   => IMHO the main issue with a receiver allocation of flow labels
is this won't work at all with not-shim6-capable nodes, i.e.,
there shall be a major interoperability issue with legacy nodes...


Yes, but only with not-shim6-capable hosts.  There is no problem
with routers, if the new labels are used in the same way as
RFC3697 labels on the new paths (and old paths are unmodified).

The not-shim6-capable hosts won't be doing multihoming anyway, and
won't understand a new destination option, let alone a new
extension header.

Thanks for your patience.

Greg