Subject: Re: I-D Action:draft-krishnan-6man-header-reserved-bits-00.txt

From: Tina Tsou <[email-masked]>
Date: Fri, 29 Oct 2010 11:39:50 -0700

Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html

-----Original Message-----

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Suresh Krishnan

Sent: Thursday, October 28, 2010 9:01 AM

To: Rémi Després

Cc: 6man 6man; George, Wes E IV [NTK]; Guolinag Yang; Yiu Lee; Christian
Huitema; Brian Carpenter

Subject: Re: I-D Action:draft-krishnan-6man-header-reserved-bits-00.txt

Hi Remi,

On 10-10-28 02:50 AM, Rémi Després wrote:

> Le 28 oct. 2010 à 07:18, Suresh Krishnan a écrit :

>>>>> ...

>>>> I doubt that any new use of the flow label will be backward compatible.

Do you have any text about this proposal that I can read up on?

>>> In my understanding:

>>> - draft-carpenter-flow-ecmp-03 details a promising particular use of

20-bit FLs that wasn't detailed before (Flow Label for tunnel ECMP/LAG)

>>> - it can work with the current rules about flow-label settings, but 

>>> too

few hosts, if any, set FLs to non-zero values today

>>> - this is, at least in part, due to the fact that these rules are 

>>> more

complex that needed: stateful processing is required, or "seems" to be
required (there is a debate), while algorithmic hashes would be easier to
implement in hosts and sufficient for load balancing purposes. -

draft-zhou-softwire-ds-lite-p2p-02 describes a new use of 20-bit FLs
(Deployment DS-lite in Point-to-Point Access Network)

>>> - it remains backward compatible with current rules because it is 

>>> only

between point-to-point tunnel endpoints, i.e. without relationship with host
FL settings.

>>> If one of these proposals would fail with hosts that support current

rules for FL settings, it couldn't be claimed that they are backward
compatible, but I have personally identified no such incompatibility.

>> The proposals need consenting hosts on both ends to be useful, don't

they?

> They don't!

> (Load balancing is a one-way function. If a host sets FLs, its flows 

> to

all destinations can be load balanced with ecmp, independently of what other
ends do.)

For one-way functions, it should not matter if one side thinks of these 20
bits as two different fields (4+16) and the other as a single 20 bit field,
right? I agree with the goals you have stated in this thread, but I am
trying to figure out *what exactly breaks* because of shortening/splitting
out the field.

And this one-way quality is certainly not true of the other work

(draft-zhou) that you mentioned that requires that the Flow Label be be
mated to the NAT binding on one side and to the point-to-point link id on
the other side.

>>> ....

>> My point was, if we need to change the nodes at both ends to 

>> implement a

new use of the flow label, the backward compatibility argument is moot.

> Right "if we need to change the nodes at both ends", but we don't.

As I said before, for draft-zhou, we need to.

[Suresh, thank you for taking time reading draft-zhou. As the author, I
don’t see why we need to modify the Flow label at both ends in draft-zhou.
Why do you say that? What’s the technical reason? Thanks.]

Thanks

Suresh

--------------------------------------------------------------------

IETF IPv6 working group mailing list

[email-masked]

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

--------------------------------------------------------------------