[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03
OK,
Hope to see you in Hiroshima
Regards
Yuri
-----Original Message-----
From: Hesham Soliman [mailto:hesham at elevatemobile.com]
Sent: Monday, October 26, 2009 1:19 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 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
>>> GT> for 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
>>>> GT> 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
>>
>>
>
>