Brian, Remi,
On Apr 22, 2010, at 06:50 MDT, Rémi Després wrote:
> Le 22 avr. 2010 à 04:56, Brian E Carpenter a écrit :
>
>> I think we need to simplify the change proposed in
>> draft-carpenter-6man-flow-update-02 even more after the recent
>> discussions, while maintaining the proposed duality
>> (RFC 3697-like
>> use still possible, but locally-defined use also possible for those who
>> want it).
>
> In my understanding, restoring domain-entrance FL-values at domain exit
> should be a "MUST" for any domain-specific use:
I'm concerned with Remi's above proposal about restoring FL-values at domain
exit.
IMHO, instead of restoring FL-values at domain exit, it is /much/ more simple
to declare that Flow-Label values are _mutable_ when a packet crosses over from
one administratively defined domain to the next. I doubt any existing, already
deployed high-speed network equipment (routers) would support any scheme to
"restore" domain-specific FL-values from entrance to exit of a domain --
although, I haven't conducted a thorough investigation with them; rather, I'm
basing this on knowledge of the forwarding architecture of various, **already
deployed** (and, will keep getting deployed) platforms whose ASIC's are
extremely limited, to say the least.
Of course, declaring the FL as "mutable" would still allow two (or more),
"consenting" administrative domains to decide that they want to preserve a
special "administrative-domain" flow-label treatment between them and that is
fine. In fact, this would be similar to how the IP DSCP/TC field is dealt with
today, particularly in the context of VPN's that span two, or more,
administrative domains.
> - Efficiency of FL-based load balancing requires that FLs are in general
> different for different 5-tuples.
Agreed.
> - For fragmented datagrams, only source hosts are in a position to base FL
> values on 5-tuples (intra-domain nodes aren't).
I would instead rephrase this as "sources are in the _best_ position" and we
should certainly encourage them to encode a FL value on all packets, (incl.
fragmented packets). However, intermediate nodes/routers can detect a
fragmented datagram (by looking for a fragment Ext. header) and once they do
so, revert to just using the 2-tuple of IPv6 src + dst address, which is not
great, but better than nothing.
Related to the above, I was thinking that a 3967bis may want to recommend the
following:
- For "plain" IPv6 packets, (i.e.: non-tunneled, non-encrypted packets), just
encode, say, the 3-tuple of {protocol, src port, dst port}, since the source
and destination addresses are already available to intermediate nodes.
- OTOH, if it is a tunneled and/or encrypted packet (i.e.: IP/IPv6 or
IPSec/IPv6), then the host should encode the entire 5-tuple of the inner IP
packet's header in the flow-label, in order that we have the most granularity
in the flow-label to distribute those packets as widely as possible over LAG
and ECMP paths.
> Provided this obligation is complied with, any domain-specific use of FLs is
> clearly permitted (it remains a purely local matter).
>
>
>> Independently, I expect to continue with draft-hu-flow-label-cases
>> as background material and with draft-carpenter-flow-ecmp as a
>> specific RFC 3697 use case, with my co-authors on those two drafts.
>
>> The guidance we need from the 6MAN WG is: should we start to draft
>> rfc3697bis, fixing the issues that have been raised and incorporating
>> the (simplified) proposal from draft-carpenter-6man-flow-update?
>
> IMHO, yes.
Yes, I support that.
>> That would also need a new milestone added to the 6man charter.
>
> Support for this.
Yes, I support that.
-shane
> Regards,
> RD
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
