Subject: RE: MPLS flows out of scope? [Re: DRAFT proposed charter for IPFX WG]

From: Kamlesh Shah <[email-masked]>
Date: Fri, 01 Jun 2001 09:33:39 -0400

Carter,

Good point. It is this "little bit of attention to the flow key and data" in the context of MPLS is what we were talking about. 

But you present a good way to look at it, and deal with it along with the list of other flow types.

Regards.

At 10:59 PM 5/30/2001 -0400, Carter Bullard wrote:
>Gentle People,
>   If you have a flexible flow key descriptor that is separate
>from the flow attributes that are reported in a flow data record
>(FDR), reporting on MPLS flows, or DSbyte flows, IPv6 flow_id
>flows, Layer 2 flows, ifIndex flows, VP flows, AS-AS
>flows, RTP based streaming media flows, ESP tunnel flows or
>traditional 5-tuple flows, whether they are uni-directional
>or bi-directional is really a very simple matter.
>
>   The trick is to work within the limits of relational algebra.
>With a little bit of attention paid to flow key and flow
>attribute concepts, the FDR can be well structured such that it can
>handle all the semantics that the TE WG has discussed, as well
>as the semantics that are supported by all the current flow based
>technology.
>
>Just a thought,
>
>Carter
>
>Carter Bullard
>QoSient, LLC
>300 E. 56th Street, Suite 18K
>New York, New York  10022
>
>[email-masked]
>Phone +1 212 588-9133
>Fax   +1 212 588-9134
>http://qosient.com 
>
>
>-----Original Message-----
>From: majordomo listserver [mailto:[email-masked]] On
>Behalf Of Kamlesh Shah
>Sent: Wednesday, May 30, 2001 10:22 PM
>To: Simon Leinen
>Cc: Dave Plonka; [email-masked]; [email-masked]
>Subject: Re: MPLS flows out of scope? [Re: DRAFT proposed charter for
>IPFX WG]
>
>
>Simon, 
>
>You have raised some very valid/good points to consider. Please see in
>line.
>
>At 11:28 PM 5/30/2001 +0200, Simon Leinen wrote:
>>>>>>> "ks" == Kamlesh Shah <[email-masked]> writes:
>>> One of the things that differentiates MPLS from other examples you 
>>> have below (such as vlan ids) is that it is an end-to-end thing in 
>>> many ISP networks today.
>>
>>Actually this may not be such a good example, because ATM is also 
>>something that is an end-to-end thing (customer-to-customer service) in
>
>>several otherwise IP networks today, including the one I help operate.
>
>I need to better explain my thought. I was thinking that since we are
>trying to do "IP Flow Export", the focus needs to be able to capture IP
>flows information end-to-end. This is somewhat different than IP packets
>that traverse an ATM cloud, which is similar in category to flows which
>traverse a FR cloud, where IP is mapped into layer 2 technology to
>traverse the cloud and really the only Layer 3 relationship exist
>between the edge devices. 
>
>In case of MPLS, even though it is layer 2 and a half technology, the
>layer 3 relationship is carried thought out the cloud and is often
>transformed (read copied) from out of the cloud to in the cloud, gfor
>instance TTL and TOS bits. Hence the comment about considering MPLS as
>an aspect.
>
>
>>> If we do not account for MPLS, then we run the risk of ignoring a 
>>> large portion of networks that will benefit.
>>
>>Sure, but since we won't make everybody happy anyway, we should try to 
>>make our task as clearly defined as possible.  And adding MPLS to the 
>>picture just makes it a whole lot fuzzier to me.
>
>That is  a matter of consensus, and I have no problem with this line of
>reasoning if generally speaking we want to keep it that way as a group.
>
>>There's a lot of experience with flow export mechanisms for IPv4 (such 
>>as LFAP and NetFlow), so I think we have a good basis for building a 
>>standard on that - which doesn't mean we're guaranteed to succeed. 
>>Extension to IPv6 is natural and shouldn't provide much contention, so 
>>it makes sense to include that from the beginning.
>
>Agree, IPV6 is much easier extension to consider as well as the fact
>that we all have a lot more experience with Flow export in the context
>of plane old IPv4 networks.
>
>
>>But extending the flow concept to "MPLS traffic flows" looks hairier to
>
>>me (different domain), and we certainly cannot build on a comparable 
>>amount of operational experience with it.
>>
>>So as a practical matter (to keep our task tractable), I'd suggest to 
>>remove it from the list of initial goals in the charter.  Or at least 
>>move it to a "for extra points^H^H^H^H^H^H^H^H^H^H^H^Hfurther study" 
>>section.  But personally I'd prefer to delegate responsibility for this
>
>>to the MPLS group.
>
>Please note, I am tuned into a lot of MPLS work in Cisco, and have some
>exposure to MPLS work out side of Cisco as well. I do NOT think there is
>*ANY* work going on to capture the flows or to define MPLS flows from
>the point of view of doing something similar to what we do with NetFlow
>export for instance.
>
>I would suggest to consider this for discussion here with some valid
>reasoning behind our actions besides the fact that we do not feel fully
>comfortable to handle this aspect or to keep it simple. At best, I can
>suggest to keep it as an item of discussion some what later in the
>process rather than dropping it altogether.
>
>>> The problem in covering MPLS as just another link layer technology is
>
>>> that we will loose capturing the information that is needed to 
>>> complete end-to-end flow definition/capture as part of the charter.
>>
>>> Where as IETF has several RFCs and work in progress documents 
>>> covering various aspects of MPLS networks, I do not know of any 
>>> single one of them covering something similar to NetFlow (of Cisco).
>>
>>Maybe a NetFlow-like mechanism isn't really necessary for MPLS 
>>networks, because MPLS has its own "natural" ways of grouping traffic 
>>into aggregates, and defines mechanisms to count traffic in those 
>>aggregates that are more convenient to use than the flow-export schemes
>
>>that are the topic of this group.
>
>I would go with this line of reasoning if MPLS was somewhat of a
>proprietary thing. Where as MPLS does have a concept of FECs (Forwarding
>Equivalence Class), to group traffic into "classes", this is still a
>layer 3 thing, and as such if we ignore this completely, we ignore a
>very crucial part of (at least some) SP networks. When you report a flow
>export from such a network, how do we treat the IP traffic flows
>behavior ?? How does an SP who is trying to charge for an IP flow
>account this part of his network ? So, I think we need to think thru
>this. 
>
>At the very least, we should make a statement about things like this and
>Layer 2 VPNs to untangle this later in the process if that is what most
>folks here think, and I would be willing to table this for now.
>
>>-- 
>>Simon Leinen                                   [email-masked]
>>SWITCH                             http://www.switch.ch/misc/leinen/
>>
>>               Computers hate being anthropomorphized.
>
>((((((((((((())))))))))))
>Kamlesh Shah  CCIE # 2803
>Technical Marketing Engineer - MPLS, ISBU
>
>
>--
>Help        mailto:[email-masked] and say "help" in message
>body
>Unsubscribe mailto:[email-masked] and say "unsubscribe
>ipfx" in message body
>Archive     http://ipfx.doit.wisc.edu/list/ipfx/archive/ 

((((((((((((())))))))))))
Kamlesh Shah  CCIE # 2803
Technical Marketing Engineer - MPLS, ISBU

---

From: "Carter Bullard" <[email-masked]>
Date: Fri, 1 Jun 2001 10:49:44 -0400

Hey Kamlesh,
   I'm not sure that I see any particularly complex issue with
regard to MPLS flow/tag reporting.  There don't seem to be 
any unique issues that MPLS presents that don't have to be addressed
to support, say, extending the 5-tuple flow model to include the
ifIndex as a key to the flow, or to report the ifIndex as an
attribute of the traditional 5-tuple flow.

Carter

Carter Bullard
QoSient, LLC

[email-masked]
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com 

-----Original Message-----
From: Kamlesh Shah [mailto:[email-masked]] 
Sent: Friday, June 01, 2001 9:34 AM
To: Carter Bullard; 'Simon Leinen'
Cc: 'Dave Plonka'; [email-masked]; [email-masked]
Subject: RE: MPLS flows out of scope? [Re: DRAFT proposed charter for
IPFX WG]

Carter,

Good point. It is this "little bit of attention to the flow key and
data" in the context of MPLS is what we were talking about. 

But you present a good way to look at it, and deal with it along with
the list of other flow types.

Regards.

At 10:59 PM 5/30/2001 -0400, Carter Bullard wrote:
>Gentle People,
>   If you have a flexible flow key descriptor that is separate from the

>flow attributes that are reported in a flow data record (FDR), 
>reporting on MPLS flows, or DSbyte flows, IPv6 flow_id flows, Layer 2 
>flows, ifIndex flows, VP flows, AS-AS flows, RTP based streaming media 
>flows, ESP tunnel flows or traditional 5-tuple flows, whether they are 
>uni-directional or bi-directional is really a very simple matter.
>
>   The trick is to work within the limits of relational algebra. With a

>little bit of attention paid to flow key and flow attribute concepts, 
>the FDR can be well structured such that it can handle all the 
>semantics that the TE WG has discussed, as well as the semantics that 
>are supported by all the current flow based technology.
>
>Just a thought,
>
>Carter
>
>Carter Bullard
>QoSient, LLC