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

[Frank Xia <xiayangsong at huawei.com>]

Hi George

It will help mobile application to make use
of underline flow binding mechnism.
You can put in a seperate appendix.

BR
Frank

----- Original Message ----- 
From: "George Tsirtsis" <tsirtsis at googlemail.com>
To: "Hesham Soliman" <hesham at elevatemobile.com>
Cc: "Laganier, Julien" <julienl at qualcomm.com>; <mext at ietf.org>
Sent: Monday, October 26, 2009 10:02 AM
Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03


> Folks,
>
> I do not agree with adding examples like that. there is a virtually
> infinite number of traffic flows resulting in an equivalent number of
> traffic selector combinations. It is also a really large number of
> different ways of putting together TSs that do exactly the same thing.
> All this is at the discretion of the implementor and we should not get
> in the middle of it.
>
> Regards
> George
>
> On Mon, Oct 26, 2009 at 12:18 PM, Hesham Soliman
> <hesham at elevatemobile.com> wrote:
> > On 26/10/09 11:12 PM, "Yuri Ismailov" <yuri.ismailov at ericsson.com> wrote:
> >
> > > Hesham,
> > > Yes, what you're saying will do the job, not in all possible situations 
> > > though
> > > (FID-PRI number less than existing one should be available)
> >
> > => Sure, but since the MN knows what is available and what's not, it can
> > renumber FIDs ...etc.
> >
> > > In such case the proposal for the text, which I gave earlier would work 
> > > as
> > > well, and I would recommend to include the example which we went through 
> > > as
> > > well.
> >
> > => I think the second part of your text is clear, we will have to
> > incorporate this example in a different part of the draft, but point 
> > taken.
> >
> > Thanks,
> > Hesham
> >
> > > Regads
> > > Yuri
> > >
> > >
> > > -----Original Message-----
> > > From: Hesham Soliman [mailto:hesham at elevatemobile.com]
> > > Sent: Monday, October 26, 2009 12:55 PM
> > > To: Yuri Ismailov; George Tsirtsis
> > > Cc: Laganier, Julien; mext at ietf.org
> > > Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03
> > >
> > >
> > >
> > >
> > > On 26/10/09 10:11 PM, "Yuri Ismailov" <yuri.ismailov at ericsson.com> 
> > > wrote:
> > >
> > > > Hi Hesham,
> > > >
> > > > If, for example, there is a FID which covers range of port numbers and
> > > > IP addresses. In such case flow bindings may look like as following
> > > >
> > > > FID-PRI FID Flow Description BIDs Action A/I
> > > > ------- --- ---------------- ---- ------- ------
> > > > 10 4 TCP dstPortMin=P1 1 Forward Active
> > > > dstPortMax=PN
> > > >
> > > > If an MN whishes to discard some particular port number P1 < i < PN
> > > > then the only possibility with the current FID table is to set The
> > > > whole range to the state "Discard"
> > >
> > > => No, that's not a good way to go at all. If you want to do that the 
> > > way to
> > > say discard port 100 where P1 < 100 < N then you send a new FID with 
> > > Discard
> > > action, PRI set to say 9 (higher priority). You don't need to touch the
> > > existing one.
> > >
> > > Hesham
> > >
> > >
> > > > If other port numbers in the range should be still in Active state
> > > > then the new FID definitions will be required and flow bindings will
> > > > have to be transformed looking like the following, for example:
> > > >
> > > > FID-PRI FID Flow Description BIDs Action A/I
> > > > ------- --- ---------------- ---- ------- ------
> > > > 10 4 TCP dstPortMin=P1 1 Forward Active
> > > > dstPortMax=P(i-1)
> > > >
> > > > 10 5 TCP dstPortMin=P(i+1) 1 Forward Active
> > > > dstPortMax=PN
> > > >
> > > > 10 6 TCP dstPortMin=i 1 Discard Active
> > > >
> > > > Similar should be done if there are ranges of IP addresses and/or
> > > > both IP addresses and port numbers covered by a single FID
> > > >
> > > > Does this clarify what I mean?
> > > >
> > > > Regards
> > > > Yuri
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Hesham Soliman [mailto:hesham at elevatemobile.com]
> > > > Sent: Monday, October 26, 2009 9:59 AM
> > > > To: Yuri Ismailov; George Tsirtsis
> > > > Cc: Laganier, Julien; mext at ietf.org
> > > > Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03
> > > >
> > > > Yuri,
> > > >
> > > >
> > > > > After the text:
> > > > >
> > > > > "1 Discard. This value indicates a request to discard all packets
> > > > > in the flow described by the option. No BIDs are associated with
> > > > > this Action."
> > > > >
> > > > > Add the following text:
> > > > >
> > > > > "In the case there is no correspondent FID to a particular flow or
> > > > > range of flows, which should be discarded, a mobile node MUST install
> > > > > a correspondent FID, otherwise error code 136 "FID not found" will be
> > > > > returned by HA.
> > > >
> > > > => I don't understand what this means. Can you clarify?
> > > >
> > > >
> > > > Care
> > > > > should be taken when issuing request for discarding packets as this
> > > > > will lead to disrupting applications communication after the "Discard"
> > > > > action was applied to selected flows. Implementations may consider
> > > > > notifying impacted applications in mobile nodes"
> > > >
> > > > => This part is clear to me.
> > > >
> > > > Hesham
> > > >
> > > > > Regards
> > > > > Yuri
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: George Tsirtsis [mailto:tsirtsis at googlemail.com]
> > > > > Sent: Friday, October 23, 2009 5:54 PM
> > > > > To: Yuri Ismailov
> > > > > Cc: Laganier, Julien; mext at ietf.org
> > > > > Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03
> > > > >
> > > > > Hi Yuri, comments inline.
> > > > >
> > > > > On Fri, Oct 23, 2009 at 1:20 PM, Yuri Ismailov
> > > > > <yuri.ismailov at ericsson.com>
> > > > > wrote:
> > > > > > Hi Goerge,
> > > > > > Thanks for the answers,
> > > > > > What I did not understand if there will be some clarification text
> > > > > > in the draft around "discard" action or all that is obvious and does
> > > > > > not require any changes? My comment was that some additional text is
> > > > > > needed.
> > > > >
> > > > > GT> I am not yet sure what non-trivial clarification we can provide.
> > > > > IMO we do not need to provide any further clarifications on this 
> > > > > subject.
> > > > >
> > > > > > I do not think your clarification about using FID-PRI is quite clear.
> > > > > > The reason is that there is no FID for a particular flow within the
> > > > > > range There is only a FID for the whole range of port numbers and/or
> > > > > > IP addresses.
> > > > >
> > > > > GT> What prevents you from creating another FID that is specific for
> > > > > GT> that
> > > > > flow?
> > > > >
> > > > > > Surprized that disclaimer for n-cast about carefull use is in the
> > > > > > text and about disclaimer for "discard" you just say "I do not think
> > > > > > there is anything to say here." Still the question is will there be
> > > > > > related text?
> > > > >
> > > > > GT> I think the implication of dropping packets is much clearer than
> > > > > the implication of n-casting. Dropping packets means the application
> > > > > to which the packet is sent will not receive the packet...do we
> > > > > really need to say that? On the other hand, receiving N copies of the
> > > > > same packet has some implications to TCP....this is also rather
> > > > > obvious for people that know TCP...but maybe not everyone does.
> > > > >
> > > > > > Regards
> > > > > > Yuri
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: George Tsirtsis [mailto:tsirtsis at googlemail.com]
> > > > > > Sent: Friday, October 23, 2009 11:08 AM
> > > > > > To: Yuri Ismailov
> > > > > > Cc: Laganier, Julien; mext at ietf.org
> > > > > > Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03
> > > > > >
> > > > > > Hi Yuri,
> > > > > >
> > > > > > Comments inline...
> > > > > >
> > > > > > On Tue, Oct 20, 2009 at 8:55 AM, Yuri Ismailov
> > > > > > <yuri.ismailov at ericsson.com>
> > > > > > wrote:
> > > > > > > Hi,
> > > > > > > after re-reading the draft come up with the comment on "Discard"
> > > > > > > action in "Flow Identification Mobility Option"
> > > > > > > I suggest either to extend the paragraph in the section 4.2 or add
> > > > > > > a separate subsection clarifying behavior of MN and HA before and
> > > > > > > after the "Discard" action was issued by MN.
> > > > > > >
> > > > > > > Below are the issues which are proposed to be addressed in the text.
> > > > > > >
> > > > > > > 1.The case when installed FID represent ranges of port numbers and
> > > > > > > IP addresses. If MN decides to discard a particular flow within the
> > > > > > > range then before that a correspondent FID should be installed in 
> > > > > > > the HA.
> > > > > > > Otherwise
> > > > > > > "136 FID not found" will be returned from HA.
> > > > > >
> > > > > > GT> If the MN wants to discard a particular flow within a range of
> > > > > > previously registered flows, it needs to either split the range it
> > > > > > two parts, or even better, use a higher FID-PRI for the discard
> > > > > > flow so that packets get matched against it before they get matched
> > > > > > against the range.
> > > > > >
> > > > > > > 2. Specify the time interval for how long time the "Discard" state
> > > > > > > will be active in HA. This is necessary because there is no
> > > > > > > "un-discard" message sent from MN.
> > > > > >
> > > > > > GT> Flow bindings share the same lifetime with the BU. There is no
> > > > > > flow binding-specific lifetime. If an MN wants to remove a flow
> > > > > > binding it sends a BU which does not include the corresponding FID.
> > > > > >
> > > > > > > 3. Add a disclaimer that for some protocols, like TCP, "Discard"
> > > > > > > action may lead to hanging up the connection at CN and should be
> > > > > > > used responsibly.
> > > > > >
> > > > > > GT> Discarding packets will drop connections....yes...I do not think
> > > > > > there is anything to say here.
> > > > > >
> > > > > > > Regards
> > > > > > > Yuri
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > MEXT mailing list
> > > > > > > MEXT at ietf.org
> > > > > > > https://www.ietf.org/mailman/listinfo/mext
> > > > > _______________________________________________
> > > > > MEXT mailing list
> > > > > MEXT at ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/mext
> _______________________________________________
> MEXT mailing list
> MEXT at ietf.org
> https://www.ietf.org/mailman/listinfo/mext