[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03



Julien,

I propose the following which I think addresses the terminology issues
but is also consistent with the rest of the document.

                    <t>Flow: A flow is as a set of data packets that are
                        exchanged between two nodes. In the context of this
                        specification the term "flow" is some times used to
                        refer to a plurality of flows as well as a
single flow.</t>
                    <t>Traffic Selector: Information that identifies one or more
                        flows. </t>
                    <t>Flow binding: It consists of a traffic selector, and an
                        action. IP packets from one or more flows that match the
                        traffic selector associated with the flow binding, are
                        processed according to the action associated with the
                        same flow binding.</t>
                    <t>Flow Identifier: A flow identifier uniquely identifies a
                        flow binding associated with a mobile node. It is
                        generated by a mobile node and is cached in the table of
                        flow binding entries maintained by the MN, HA, CN or
                        MAP.</t>

WRT to the use of the term "n-cast" vs "forward" I am fine with
changing it to "Forward" which I agree makes more sense. In an effort
to avoid an endless/pointless discussion about it, however, I would
like the chairs to reassure me that I will not have to change it back
again :-).

George

On Thu, Oct 22, 2009 at 6:20 PM, Laganier, Julien <julienl at qualcomm.com> wrote:
> Folks,
>
> Please find below my _individual_ WGLC comments:
>
> As we've discussed in the past I think the terminology is misleading and we had agreed to fix it. The draft hasn't been updated since then, however, so I'm repeating my comments in the WGLC.
>
> The current flow description can catches traffic to many destination, e.g., HTTP traffic to any destination, yet the current definition of flow talks about packet exchanged between two nodes:
>
>      Flow: A flow is identified as a set of data packets that are
>      exchanged between two nodes and match a given flow description
>
> I think it is fair to say that the basic object that this specification manipulates is a "bunch of flows" rather than a flow. So I think we should make the following easy change and renaming in our definitions and terminology, it will make the specification more consistent and easier to read without entailing changes to the protocol mechanism:
>
>   Flow:
>
>         (something ala RFC 2460, e.g.) a sequence of packets
>         sent from a particular source to a particular (unicast
>         or multicast) destination for which a MN desires
>         special handling by intervening MIPv6 peers, being it
>         the HA or the CN.
>
>   Flow Description -> Traffic Description/Selector (I don't care which one we pick, traffic selector is used by IPsec already with exactly the same meaning that here):
>
>         a piece of information that identifies one or more flows.
>         The identification is based on various fields of the
>         network and transport layer headers, such as the source
>         address, the destination port, the protocol number, the
>         DSCP value, etc.
>
>   Flow Identification -> Traffic Identification
>
>   Flow Identifier -> Traffic Identifier:
>
>         an unsigned integer used as a reference to a particular
>         Traffic Description/Selector.
>
>   Flow Binding -> Traffic Binding:
>
>        an association between a traffic description/selector and
>        an action (Forward or Discard).  An IP packet that matches
>        the traffic description/selector will be processed according
>        to the action.
>
> Note above, the Flow identifier doesn't need to be included in the definition of a binding. Also I prefer to use "Forward" rather than "n-cast", since Forward is clear and does not necessarily imply that the packet is only forwarded in one direction.
>
> --julien
> _______________________________________________
> MEXT mailing list
> MEXT at ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>