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

Re: Flow label versus Extension header - protocol itself



Hi Francis,

Sorry to keep returning to this point.

I really think that Extension headers (and even Destination
Options) are a undesirable.

[chop]

I think they make it pretty clear that using the flow label for demux can be done without impact to other flow label use, at the cost of some extra complexity when selecting the flow label for a new session.


=> but the flow label selection is already an essential part of
RFC 3697. IMHO this proposal is acceptable only because there is
currently no standard flow label use at all... I.e., it is possible
to get rid of RFC 3697 and to reserve the flow label for shim6, but
you have to go this way clearly if you'd like to take it.

I'm not sure that this is necessary (changing 3697) or even desirable, even for proponents of flow-label-as-shim6.

When I was talking off-list to others about this issue, the role of
3697 flow labels came up and I was encouraged to look into the RFC.

I agree that the labels need to be preserved in their existing sense,
if new flow-label usage schemes are to be supported.

The role of a receiver oriented scheme doesn't interfere with this
though, because for every (src,dest) pair upon which a receiver based
allocation is performed, there's no difference to the routing
infrastructure as to which allocation scheme is used:

The first packet on the path always contains the context tag as label,
since label allocation on subsequent paths (not the original source &
destination), prerequires context tag allocation.

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).

It doesn't interfere explicitly with simple source selection of
labels, though, except to (slightly) reduce the amount of potential
tags able to be selected by the sender.

Regards

Francis.Dupont@enst-bretagne.fr

PS: I still believe the best is a destination option.


:)

At this stage we're in polite disagreement.

Greg