RE: draft-wang-6man-flow-label-reflection

["Aijun Wang" <[e-mail]>]

Hi, Jeroen

Please see the reply inline below.

> -----Original Message-----
> From: Jeroen Massar [mailto:[e-mail]]
> Sent: Saturday, November 15, 2014 10:51 AM
> To: Aijun Wang; 'Sheng Jiang'; '6man WG'
> Subject: Re: draft-wang-6man-flow-label-reflection
> 
> On 2014-11-15 02:05, Aijun Wang wrote:
> > Hi, Jeroen:
> >
> > Service Provider wants to apply the same policy to the upstream and 
> > downstream of one session, or more accurately, apply the policy to 
> > downstream of one session based on the recognition of it upstream
packet.
> >
> > The flow label can be used to identify the unique session between 
> > one pair of IPv6 hosts, and alleviate the burden for the network 
> > device to recognize the downstream packet, for example, http 
> > response packet. We think this is one appropriate use case for the flow
label.
> 
> The Flow Label as defined tells you nothing about the contents of the
flow.
> Hence nothing to prioritise on there. You will still have to look at 
> the typical five tuple and likely deeper when everything is just going to
look like HTTP.
> 
【Aijun】: with the reflection mechanism, we only need the deeper
information of upstream packet, not necessary for the corresponding
downstream packet. For downstream packets of the same session, the 3-tuple
info(src, dst, flow label) is enough for upper layer traffic recognition. 
We also consider other usage scenarios for flow label reflection, for detail
information, you can review
http://datatracker.ietf.org/doc/draft-wang-6man-flow-label-reflection/ in
more detail. The presentation document(the link on the current IETF website)
seems to connect the wrong file) 

> Oh, and IPv6 Errors (ICMPv6) are part of that flow, but the Flow Label 
> will not include those.
> 
【Aijun】：ICMP Errors packets are often regenerated by the router, not the
original data packet destination(3-tuple information has been changed). So
the process for flow label reflection would be different and we will
consider it more carefully later.
For PTB error message in ECMP environment, especially for the load balancer
before server farm, we recommend the load balancer to deal with specially
such PTB error message, that is to say, send this error message to all
servers that have the same address. Such method is more simple and less
influences to redefine the meaning of this field. Servers that receive the
PTB error message should all reduce their following packet size according to
the recommending MTU value.



> And as you say "Service Provider" though, sounds like you are opening 
> that can of worms called Net Neutrality.
【Aijun】: SFC, NFVRG etc group in IETF are all considering how to deal with
various traffic flow in more flexible manner, this is the development trend.
It is not enough for service provider to consider only the ip src and ip
dest information. 
> 

> Greets,
>  Jeroen