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

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

To: Hesham Soliman <hesham at elevatemobile.com>
Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03
From: George Tsirtsis <tsirtsis at googlemail.com>
Date: Mon, 26 Oct 2009 15:02:13 +0000
Cc: "Laganier, Julien" <julienl at qualcomm.com>, mext at ietf.org
Delivered-to: mext at core3.amsl.com
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gN+gVfYO0sIVQtDR0fM98XEXYPFcVCEqp6ync+c/xck=; b=HLK9bQdkHwrlDMYtIlzgjRcxm9HWzDwqeMi6J6surcGezuFLCEOZ4WR3BKqBaTRhF/ 5k1rmzCYqdrFMp0BDSOSX5hcH5zM6Bwq1Nx74T233PWpnWMaPmZpA9txZTPzVK2HAuUi W3SjLD9AWGzUveK5EZzaCHdhOHrBbn8xL8Ofw=
Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tG8Pq9GOrnzFbmBhqi3h/FEgnM5O/K5aYTeJ0uBJMjUyZecHqX/B+shNryjXXRvFT9 MGQ1XtAOZgYJHvqoZxQLw8PMp3H7/VMsJlqKgg7AH/FU78BjfMWhelIb+nraT3J2Fe4P G2q2ZzUpItbwngvuzbIGwbOj4g43u8eNEgY5M=
In-reply-to: <C70BDED1.FEC7%hesham at elevatemobile.com>
List-archive: <http://www.ietf.org/mail-archive/web/mext>
List-help: <mailto:mext-request@ietf.org?subject=help>
List-id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-post: <mailto:mext@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
References: <C24C03AE7348E44FB76B34B5D4ED44F503F63332 at esealmw106.eemea.ericsson.se> <C70BDED1.FEC7%hesham at elevatemobile.com>

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

Follow-Ups:
- Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03
  - From: Yuri Ismailov
- Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03
  - From: Frank Xia

References:
- Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03
  - From: Yuri Ismailov
- Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03
  - From: Hesham Soliman

Prev by Date: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03
Next by Date: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03
Previous by thread: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03
Next by thread: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03
Index(es):
- Date
- Thread