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

From: [email-masked]
Date: Fri, 23 Jul 2010 00:18:41 +0800

Hi Lucy,
Is it possible to define two FAT label for large flow and small flow 
separately? If it is possible, I think this is a better solution than 
extending TC bits.

BR
Lizhong

> ------------------------------
> 
> Message: 2
> Date: Wed, 21 Jul 2010 10:27:39 -0500
> From: Yong Lucy <[email-masked]>
> Subject: Re: [PWE3] FW: [mpls] Large FLow Classificaiton in Flow Aware
>    Transport
> To: [email-masked]
> Cc: [email-masked], 'pwe3' <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> SNIP
> > 
> > 
> > Lucy,
> > 
> > Any modifications to the use of the TC bits is almost certainly a
> > non-starter.  I thought that was also mentioned in the last meeting.
> > We'll see what comments come out of the meeting this time.
> > 
> > Curtis
> > 
> > 
> [LY] We are glad to discuss the alternate solution. It is clear to me 
that
> flow label serves different function than PW label and LSP label and its 
TC
> bits are not defined yet.
> 
> Lucy
> > >   _____
> > >
> > > From: [email-masked] [mailto:[email-masked]] On Behalf 
Of
> > Yong
> > > Lucy
> > > Sent: Tuesday, April 27, 2010 5:37 PM
> > > To: 'pwe3'; [email-masked]
> > > 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
> 
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Yong Lucy <[email-masked]>
Date: Thu, 22 Jul 2010 11:46:45 -0500

Hi Lizhong,

Theoretical, it is possible. But it needs to inform intermediate routers
which label value represent for large and which for the rest.  Each PE may
choose to use different FAT label spaces. This will be more complex.  FAT PW
solution makes intermediate routers not aware of FAT label even using it. 

Thanks,

Lucy

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 22, 2010 11:19 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [PWE3] FW: [mpls] Large FLow Classificaiton in Flow Aware
Transport

Hi Lucy, 

BR 
Lizhong 

> [LY] We are glad to discuss the alternate solution. It is clear to me that
TC
Of
one
> > of
> > > the TC bits in the flow label to indicate large flow. TC bits in flow
> > label
> > > 1) No use for the proposal. would need to update all equipment to get
> > this
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
> > > We will modify the draft and move enhanced ECMP process description to
classification.
aware
> > > stack is always MPLS label stack so MPLS WG would need to OK change of
> > TC
> > > 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
by
> > > 3) If you can get MPLS WG to agree, one of the issues is that you are
big
Would
> > > it can pick by statistics, i.e. not necessary all the large flows. The
The
> > > 4) we haven't standardized anything on ECMP. Many will look at bottom
of
flow
at
> > the
> > > bottom of label stack. This is: check the first nibble to separate IP
> > and
> > > 5) this is addressing an important issue.  Simulations showed a lot of
> > > where situation is much worse than shown.  Drafts have been submitting
> > in
hashing,
network,
> > it
> > > has a lot of L2VPN traffic carried as single flow, so the situation is
traffic.
higher
aim
> > > is about large flow classification indication so LSR can use a set of
> > large
> > > Lucy: we are working on additional simulations. That will include flow
> > > coming and going situation and include much higher bit rate flows, and
a
as
or
within
> > > Lucy: High bit rate flow is relevant to other flows. Operator can set
> > large
network
enables

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is
solely property of the sender's organization. This mail communication is
confidential. Recipients named above are obligated to maintain secrecy and
are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the originator of the
message. Any views expressed in this message are those of the individual
sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.