[mpls] FW: Large FLow Classificaiton in Flow Aware Transport

[Yong Lucy <[e-mail]>]

I like to post this e-mail again for reminding. We have changed the draft
title to draft-yong-pwe-lfc-fat-pw to focus on large flow classification,
not enhanced ECMP.

 

Look forward to discussing this at Maastricht.

 

Lucy

 

  _____  

From: [e-mail] [mailto:[e-mail]] On Behalf Of Yong
Lucy
Sent: Tuesday, April 27, 2010 5:37 PM
To: 'pwe3'; [e-mail]
Subject: [mpls] Large FLow Classificaiton in Flow Aware Transport

 

Hi,
 
I recap the comments raised during IETF77 meeting. Some are from the PWE3
meeting and some from offline discussions. Hope this gives some
clarification and bring up further mailing discussion.
 
The draft proposal (draft-yong-pwe3-enhanced-ecmp-lfat-01) is to use one of
the TC bits in the flow label to indicate large flow. TC bits in flow label
described in FAT-PW are not used and are not interpreted by LSR. 
 
Comments and Responses:
          
1) No use for the proposal. would need to update all equipment to get this
to work.  A while ago we agreed to not standardize ECMP process. 
 
Lucy: Some carriers see the value of it. There is no need to update all
equipment to get this work. The backward compatibility is supported as
described in section 6. Partially upgrading can improve some segments while
keeping other segments remain the same. The intention of the draft is not
for standardizing ECMP process. It is about standardizing large flow
classification indication in PSN. The draft layout may lead this confusion.
We will modify the draft and move enhanced ECMP process description to
appendix as one implementation example to use large flow classification. We
will change the draft title to "large flow classification in flow aware
transport over PSN" and upload soon.
 
2) would need to go through MPLS WG for issue on standardizing ECMP. Label
stack is always MPLS label stack so MPLS WG would need to OK change of TC
semantics.  Needs a co-review in MPLS WG and they must approve.
 
Lucy: The draft is not for standardizing ECMP. (sorry for the confusion).
The draft does not change the semantics of a label stack entry defined by
RFC3032 because the flow label is never on the top of label stack. As FAT-PW
draft indicates that the interpretation of TC bits in the flow label by LSR
is undefined. This draft proposes one definition.
 
3) If you can get MPLS WG to agree, one of the issues is that you are
marking at a PE where the PE may or may not know what is or isn't a big
flow.  Limitations on PEs ability to determine what a big flow is. Would
need to tell easily and ubiquitously what a big flow is.
 
Lucy: In our proposal, large flows in this context are the top rate ranked
flows. It is relevant to other flows not the link capacity. Enhanced ECMP
process just needs a small set of large flows for load balancing, therefore,
it can pick by statistics, i.e. not necessary all the large flows. The
method works well even some large flows placed by hashing function. The
backward compatibility in the draft would deal with this.
          
4) we haven't standardized anything on ECMP. Many will look at bottom of
stack to look at IP address or anything else to hash on. If I'm a PE router
with lots of L3VPN traffic and some PWs, how do I know if this is a flow
label or VPN label.
 
Lucy: This is not for ECMP standardization. We propose one method to
differentiate the flow label from IP packet, PW label, and LSP label at the
bottom of label stack. This is: check the first nibble to separate IP and
MPLS packets; for MPLS packets, use TTL value (=0) to check the flow label
packets.  
 
5) this is addressing an important issue.  Simulations showed a lot of
traffic and the flows are large enough.  Cases in well engineered network
where situation is much worse than shown.  Drafts have been submitting in
past that gained no traction.  To use a method other than just hashing, but
may be ways to do this without changing label or MPLS.
 
Lucy: The simulation use Internet traffic pattern. For carrier network, it
has a lot of L2VPN traffic carried as single flow, so the situation is
worse. We work on additional simulation to include such type of traffic. It
confirms the statement. As Internet traffic grow with higher and higher bit
rate flows, the problem will become more and more severe. We need to aim on
this real problem.
 
6) there was a proposal to solve this 10 years ago with no protocol changes.
This is not needed.
 
Lucy: Need clarification which proposal refers to. If it is OMP, the draft
proposes the different method from OMP. OMP suggest using routing protocol
to advertise individual ECMP path TE information in the network. The draft
is about large flow classification indication so LSR can use a set of large
flows in performing load balance over ECMP paths effectively.
 
7) Changes too much about MPLS processing
 
Lucy: It is not that additional process. Gaining is obvious too. 
 
8) did the simulations deal with coming and going of flows? How to address
flow fluctuation?
 
Lucy: we are working on additional simulations. That will include flow
coming and going situation and include much higher bit rate flows, and a
"permanent flow" whose rate may change over time to make it as small flow at
a time or a large flow at another time. The latter case likes a VPWS as a
flow. Be glad to show some simulation result to the group.
 
9) Signaling can be used for this, why using marking?
 
Lucy: today, signaling a PW is used per a service basis such as VPWS or
VPLS. But one VPWS or VPLS may contain many flows, the draft address this
situation. It is hard for carrier to signal individual large flow within
VPLS over PSN networks.  
 
10) If there is incentive to enhanced ECMP, why not do large flow
recognition at local LSR for the purpose? PE based large flow recognition
and marking do not apply well at individual LSR.
 
Lucy: High bit rate flow is relevant to other flows. Operator can set large
flow criteria. Having each LSR performs larger flow recognition add complex
to each LSR and may impact the service performance. Large flow
classification is easier, we think. Today, DiffServ enables the network to
perform different service treatments. Large flow classification enables
network to perform different flow treatments over ECMP operation.
 
Comments and suggestion are welcome.
 
 
Regards,
Lucy