Subject: DRAFT proposed charter for IPFX WG

From: Dave Plonka <[email-masked]>
Date: Fri, 18 May 2001 17:07:24 -0500

IPFX folks,

Below is the proposed draft charter that Mike MacFaden, Kevin Zhang,
and Nevil Brownlee assisted in preparing and that has been submitted
for consideration by the Operations and Management Area Directors.

Randy's recent Cc's to the list were in response to this draft.

Please send comments and suggestions on the charter to the ipfx mailing
list.

Thanks,
Dave

>>>>>>>>>>>>> DRAFT proposed charter for IPFX WG <<<<<<<<<<<<<<<<<
                    (ipfx_charter_00.txt)

IP Flow Export (IPFX)

   IETF Area:
        Operations and Management Area

   Chair(s):
        Nevil Brownlee <[email-masked]> 
        Dave Plonka <[email-masked]> 

   Operations and Management Area Director(s): 
        Randy Bush <[email-masked]>
        Bert Wijnen <[email-masked]>

   Responsible Area Director:
        TBD

   Mailing Lists:
        General Discussion: [email-masked]
        To Subscribe: [email-masked] with "subscribe ipfx"
		      in message body
        Archive: http://ipfx.doit.wisc.edu/

Description of Working Group: 

   There is a need in industry and the Internet research community for
   IP devices such as routers to export flow information in a standard
   way to external systems such as mediation systems,
   accounting/billing systems, and network management systems to
   facilitate services such as measurement, accounting, and billing.

   This group will define a protocol by which IP flow information can
   be transferred in a timely fashion from an "exporter" to a
   collection station or stations.  The "exporter", which is typically
   an IP router or IP traffic measurement device, will employ the IP
   flow export protocol to report "IP flows", these being series of
   related IP packets that have been either forwarded or dropped.  The
   reported flow details will include both (1) those attributes derived
   from the IP packet headers such as source and destination address,
   protocol, and port number and (2) those attributes often known only
   to an IP router such as timestamps, ingress and egress ports, IP
   (sub)net mask, and autonomous system numbers.

   In doing so, the group has the following specific goals:

    o  Devise a protocol that provides a flexible but specialized, high
       performance, online IP Flow export capability which meets the
       work-load, reliability and timeliness requirements of existing
       applications that rely on IP flow export.

    o  Define the notion of a "standard IP flow" within the protocol
       specification.  The flow definition will be a practical one,
       similar to those currently in use by existing non-standard flow
       export protocols which have attempted to acheive similar goals
       but have not documented their flow defintion.

    o  Devise data encodings that support analysis of MPLS, IPv4 and
       IPv6 unicast and multicast flows traversing a network element at
       packet header level and other levels of aggregation as requested
       by the network operator according to the capabilities of the
       given router implementation.

    o  Ensure that the protocol is reasonable to implement by router
       and instrumentation developers and is easy to deploy by network
       operators.

    o  Design the protocol to be reliable in that it will minimize the
       likelihood of flow data being lost and to accurately report such
       loss if it occurs.  This may involve supporting the use of
       firewall/proxy between network element and collectors as well as
       load balance amongst multiple collectors.

    o  Consider the notion of IP flow export based upon packet sampling.

Goals and Milestones:

   Jun 2001
            Request BOF at IETF 51 in London.
	    BOF would discuss the charter, continue the requirements
	    discussion, and begin discussion on Transport Layer
	    protocol and Data encoding model.

   Late Jun 2001  
            Submit Internet-Draft on IP Flow Export Requirements
               IPFX-REQUIREMENTS

   Late Sep 2001
            Submit Revised Internet-Draft on IP Flow Export Requirements
               IPFX-REQUIREMENTS

   Early Feb 2002
            Submit IPFX-REQUIREMENTS to IESG for publication,
               Informational RFC
            Submit Internet-Draft on IP Flow Export Protocol
               IPFX-PROTOCOL
            Submit Internet-Draft on IP Flow Export Data Model
               IPFX-DATAMODEL

   Early May 2002
            Submit IPFX-DATAMODEL to IESG for publication,
               Informational RFC 
            Submit IPFX-PROTOCOL to IESG for publication, Proposed
               Standard RFC (also need an Applicability Statement RFC)

-- 
[email-masked]  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

---

From: Simon Leinen <[email-masked]>
Date: 30 May 2001 14:49:17 +0200

Dave & all,

thanks for your work on the draft charter.  Looks very good to me.

>    given router implementation.

I'd prefer to *not* have MPLS explicitly mentioned in the charter.
MPLS has its own concepts of flows (FECs, LSPs, TE trunks...), and the
MPLS and Traffic Engineering working groups are developing their own
mechanisms for looking at traffic within those.

We should concentrate on IP flows and treat MPLS as one of many
possible link (or "linkwork") layers.  If we find it useful/necessary
to add support for lower-layer-specific information in flow data (such
as LSPs for MPLS, or MAC addresses for 802 links, or VC ids for
ATM/Frame Relay etc.), then that's fine with me.
-- 
Simon.

---

From: Kamlesh Shah <[email-masked]>
Date: Wed, 30 May 2001 09:19:23 -0400

Simon,

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. If we do not account for MPLS, then we run the risk of ignoring a large portion of networks that will benefit.

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).

Regards.

>ATM/Frame Relay etc.), then that's fine with me.

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

---

From: Kamlesh Shah <[email-masked]>
Date: Wed, 30 May 2001 10:10:47 -0400

And your point is ??

Please, if you are going to waste my in box, I will have to add you to the spam list..lets be reasonable here..and give me a break.

Regards.

At 07:04 AM 5/30/2001 -0700, Randy Bush wrote:
>> 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.
>
>and pigs fly
>
>randy

---

From: Kamlesh Shah <[email-masked]>
Date: Wed, 30 May 2001 16:38:45 -0400

Randy,

I certainly do not take your comments personally, and no MPLS is not my religion. Its just something I do, and am trying to learn a few things about in this little brain of mine.

I think it is a good idea to consider it in our discussions in case it does stay around for a couple of days and in a couple of ISPs networks.

Regards.

At 10:56 AM 5/30/2001 -0700, Randy Bush wrote:
>apologies for being terse.  and for stepping on your religion.
>
>despite some vendor madly pushing atm-2, it's being used by very few isps.
>and they are having a heck of a time with implementation issues.  and the
>wonderful benefits may be as elusive as atm-1.
>
>so it would be best if the bof and wg focus on normal internet solutions
>as well as trying to sort out how to cover atm-2 approaches as well.
>
>randy

---

From: Simon Leinen <[email-masked]>
Date: 30 May 2001 23:28:23 +0200

>>>>> "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.

> 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.

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.

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.

> 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.
-- 
Simon Leinen				       [email-masked]
SWITCH				   http://www.switch.ch/misc/leinen/

	       Computers hate being anthropomorphized.

---

From: Mike MacFaden <[email-masked]>
Date: Thu, 31 May 2001 01:52:01 -0700

>picture just makes it a whole lot fuzzier to me.

I agree having MPLS risks the overall delivery of IPFX.

>section.  But personally I'd prefer to delegate responsibility for

I like the idea of moving it to an "extra points" section to reduce
the risk to the schedule and to keep the group (if chartered)
more focused on one clear goal.

I do not believe we should punt the responsiblity just yet. Having
reviewed the MPLS-TE-MIB and TE-MIB modules as well as the LSR
and LDP and ... I happen to think there is a good match for the kinds of 
information that will be shipped to mgmt apps from LSRs.

>schemes that are the topic of this group.

Perhaps, but current reading of the TE-MIB and MPLS-TE MIB modules
at least to me shows IPFX could be a vehicle for delivering vast quantities
of information as found in these MIB modules in a way that scales.
For example, given the indexing schemes of teTunnelList and mplsTunnelTable, 
the number of rows in these tables can grow very large.
Both drafts define a tunnel name (32 or 255 chars depending on the author) 
and provide byte and packet  counters. Still, I'm not sure how well this
class of data behaves compared to ipv4/6 which as I stated before might
only serve to complicate an IPFX protocol needlessly.

And even if MPLS is ruled out of the charter, somehow relating flows to
mpls tunnels or dlci's or pvcs would be a good thing.

Regards,
Mike MacFaden

---

From: "Carter Bullard" <[email-masked]>
Date: Wed, 30 May 2001 22:59:24 -0400

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:
>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.

>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.

>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.
>
>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 
>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.

--
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/

---

From: Kamlesh Shah <[email-masked]>
Date: Wed, 30 May 2001 22:22:28 -0400

Simon, 

You have raised some very valid/good points to consider. Please see in line.

>in several otherwise IP networks today, including the one I help

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.

>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.

>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.

>section.  But personally I'd prefer to delegate responsibility for

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.

>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.