On 2010-10-01 20:29, Rémi Després wrote:
> Le 1 oct. 2010 à 02:00, Brian E Carpenter a écrit :
>> On 2010-09-30 20:01, Rémi Després wrote:
>>>> ...
>>>> Our question is: "Is this usage compatible to RFC 3697?" We posted this
>>>> question to Softwires and we were told to also ask 6man for input.
>>> With RFC 3697 as is, it doesn't seem to be compatible.
>>> This is because the RFC specifies a very specific way to assign FLs to
>>> flows.
>> I don't see the problem. The RFC leaves the packet source entirely free
>> to define a flow in any way it likes, and doesn't specify much
>> about the value of the flow label.
>
> Oops, thank you, my comment applies to RFC 2460 (not to RFC3697).
> (That is RFC 2460 that says "New flow labels must be chosen (pseudo-)randomly
> and uniformly from the range 1 to FFFFF hex.")
>
Yes, in the non-normative appendix! The only normative statement
in 2460 is in section 6:
"Hosts or routers
that do not support the functions of the Flow Label field are
required to set the field to zero when originating a packet, pass the
field on unchanged when forwarding a packet, and ignore the field
when receiving a packet."
Brian
> Regards,
> RD
>
>
>
>
>
>> Brian
>>
>>> Now, in the revision under study, what you propose should IMHO be
>>> unambiguously permitted.
>>> (For a load-balancing application between BRAS and AFTRs, your proposal is
>>> clearly a good choice.)
>>>
>>> Regards,
>>> RD
>>>
>>>> Thanks,
>>>> Yiu
>>>>
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> [email protected]
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>
>>>
>
>
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------