Subject: FW: New Version Notification for draft-wang-6man-flow-label-reflection-00.txt

From: Sheng Jiang <[email-masked]>
Date: Fri, 24 Oct 2014 05:45:18 +0000

Hi, 6man,

We have submitted a new draft to 6man WG. It proposes a flow label reflection mechanism that network devices copy the flow label value from received packets to the corresponding flow label field in return packets. With this mechanism, network operators would easily correlate an upstream session and the corresponding downstream session together. This mechanism could simplify the network traffic recognition process in network operations and make the policy for both directions of traffic of one session consistent.

http://tools.ietf.org/html/draft-wang-6man-flow-label-reflection

Please review this draft. Any comments are appreciated.

Best regards,

Sheng + Aijun

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Tuesday, October 21, 2014 4:10 PM
>To: Aijun Wang; Aijun Wang; Sheng Jiang; Sheng Jiang
>Subject: New Version Notification for
>draft-wang-6man-flow-label-reflection-00.txt
>
>
>A new version of I-D, draft-wang-6man-flow-label-reflection-00.txt
>has been successfully submitted by Sheng Jiang and posted to the
>IETF repository.
>
>Name:		draft-wang-6man-flow-label-reflection
>Revision:	00
>Title:		IPv6 Flow Label Reflection
>Document date:	2014-10-21
>Group:		Individual Submission
>Pages:		9
>URL:
>http://www.ietf.org/internet-drafts/draft-wang-6man-flow-label-reflection-0
>0.txt
>Status:
>https://datatracker.ietf.org/doc/draft-wang-6man-flow-label-reflection/
>Htmlized:
>http://tools.ietf.org/html/draft-wang-6man-flow-label-reflection-00
>
>
>Abstract:
>   The current definition of the IPv6 Flow Label focuses mainly on how
>   the packet source forms the value of this field and how the forwarder
>   in-path treats it.  In network operations, there are needs to
>   correlate an upstream session and the corresponding downstream
>   session together.  This document propose a flow label reflection
>   mechanism that network devices copy the flow label value from
>   received packets to the corresponding flow label field in return
>   packets.  This mechanism could simplify the network traffic
>   recognition process in network operations and make the policy for
>   both directions of traffic of one session consistent.
>
>The IETF Secretariat

---

From: Ray Hunter <[email-masked]>
Date: Sat, 25 Oct 2014 16:55:49 +0200

>> Please review this draft. Any comments are appreciated.
This is an interesting draft, especially for monitoring and debugging.

Another possible applicable scenario could be efficiently switching 
return packets of flows where policy based routing has been applied, 
thus ensuring symmetric return paths (one of the great challenges of 
PBR), although obviously the security considerations would need updating.

-- 
Regards,
RayH

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 27 Oct 2014 09:46:02 +0000

>>> We have submitted a new draft to 6man WG. It proposes a flow label
>reflection mechanism that network devices copy the flow label value from
>received packets to the corresponding flow label field in return packets. With
>this mechanism, network operators would easily correlate an upstream
>session and the corresponding downstream session together. This mechanism
>could simplify the network traffic recognition process in network operations
>and make the policy for both directions of traffic of one session consistent.
>>>

Hi, Ray,

Thanks for your email. We did consider the symmetric return paths, but find that technically very difficult to realize, even the flow label has been reflected. The load-balancing points for original packets and return packets are actually different devices and different location in the network. So even the return packets have the same 3-tuple (of course, dest addr and source addr are reversed). There is no obvious mechanism to make them be routed into the same paths.

Best regards,

Sheng

---

From: Ray Hunter <[email-masked]>
Date: Mon, 27 Oct 2014 23:49:09 +0100

> Sheng Jiang <mailto:[email-masked]>
> 27 October 2014 10:46
Indeed.

You'd have to perform "previous hop discovery", possibly based on 
caching a combination of inbound physical interface and L2 source 
address of the inbound packet (mapped to flow label).

Whether you think it's a good idea or not is a different discussion.

-- 
Regards,
RayH

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 28 Oct 2014 10:43:23 +0800

Hi, Ray:

Previously, we have discussed the solution of symmetric path for upstream
and downstream packets of one session, just based on the 5-tuple information
of this session. If there is additional information can be used, such
requirement can be met more perfectly.
Anyway, there are scenarios that require the upstream and downstream of one
session pass the same device, or even same link, the flow label mechanism
can assist/accelerate such aim to be accomplished.

Aijun 

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ray Hunter
Sent: Tuesday, October 28, 2014 6:49 AM
To: Sheng Jiang
Cc: 6man WG; Aijun Wang
Subject: Re: FW: New Version Notification for

>> reflection mechanism that network devices copy the flow label value 
>> from received packets to the corresponding flow label field in return 
>> packets. With this mechanism, network operators would easily 
>> session together. This mechanism could simplify the network traffic 
>> recognition process in network operations and make the policy for both
directions of traffic of one session consistent.
> Thanks for your email. We did consider the symmetric return paths, but
find that technically very difficult to realize, even the flow label has
been reflected. The load-balancing points for original packets and return
packets are actually different devices and different location in the
network. So even the return packets have the same 3-tuple (of course, dest
addr and source addr are reversed). There is no obvious mechanism to make
them be routed into the same paths.
Indeed.

You'd have to perform "previous hop discovery", possibly based on caching a
combination of inbound physical interface and L2 source address of the
inbound packet (mapped to flow label).

--
Regards,
RayH

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 28 Oct 2014 10:10:37 +0800

Hi, Ray:

Aijun 

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ray Hunter
Sent: Tuesday, October 28, 2014 6:49 AM
To: Sheng Jiang
Cc: 6man WG; Aijun Wang
Subject: Re: FW: New Version Notification for

Indeed.

--
Regards,
RayH

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 28 Oct 2014 10:24:42 +0800

Hi, Ray:

Aijun 

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ray Hunter
Sent: Tuesday, October 28, 2014 6:49 AM
To: Sheng Jiang
Cc: 6man WG; Aijun Wang
Subject: Re: FW: New Version Notification for

Indeed.

--
Regards,
RayH