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

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 6 Oct 2009 16:30:24 -0700

Folks,

Hereby we're starting a two weeks WGLC on our "Flow Bindings in Mobile IPv6 and NEMO Basic Support" document, available at the following URL:

<http://tools.ietf.org/html/draft-ietf-mext-flow-binding-03>

Please review the specification, post your comments to the mailing list, and state whether or not you think the document is ready to be forwarded to IESG before 2009-10-20 6:00PM PST.
 
Thank you for your support.
 
--julien & marcelo, MEXT chairs

---

From: Benjamin Lim <[email-masked]>
Date: Fri, 09 Oct 2009 13:38:49 +0800

Hi,

I have reviewed the draft and it seems to be in good shape. Some
comments below.

Comment 1
--------------
Reference updates for
I-D.ietf-mext-nemo-v4traversal --> RFC 5555
I-D.ietf-monami6-multiplecoa --> RFC 5648

Comment 2
--------------
In section 4.4, it states
"A valid BID is required to make the entry "active".  If all of the BIDs
pointed to by a given entry are not valid BIDs in the binding cache, the
flow binding entry becomes "inactive", in other words it does not affect
data traffic."

FID-PRI     FID    Flow Description    BIDs    Action       A/I
    -------     ---    ----------------         ----      -------     ------
       10        4           TCP                 2      Forward     Active
       20        3       srcAddr=IPx       N/A     Discard     Active
       30        2       srcAddr=IPy        4      Forward     Inactive
       40        5           UDP               1,3     N-Cast      Active

                       Ordered Flow Binding Entries

However, for the above figure, in the second entry, N/A mean no BID
specified. If so, how can this be an active entry as there is no "valid
BID"? I find this confusing. There are two ways to approach this,

a) associate a BID with the discard action. This means that the
definition of discard action in 4.2 needs to be updated.
b) add more text in 4.4 to say that for discard action even if there is
no BID associated to it, that entry is treated as valid.

Comment 3
--------------
In section 5.3.2.1, the forward action is not defined in 4.2. From my
reading of 4.2, my understanding is that using n-cast and specifying a
single BID can be implied as the forward action.

<snip for 4.2>
> 2 n-cast.  This value indicates a request to send the flow to one or
> more addresses indicated in the Binding Reference sub-option. One or
> more BIDs MUST be associated with this Action.  If only one BID is
> associated with this action then it is essentially a request to
> forward packets to that CoA.  Care should be taken when the n-cast
> action is used as some transport layers may not be able to handle
> packet duplication and this can affect their performance.
</snip>

There are two ways to approach this,
a) define action forward
b) drop the text for action forward in 5.3.2.1.

I prefer b) as I feel n-cast covers the forward action.

Comment 4
--------------
In section 5.3.3, propose to reword the second paragraph to

<old  text>
> If the value of any of the FID fields included in the flow summary 
> option is not present in the list of flow binding entries for this 
> mobile node, the home agent MUST reject this flow binding refresh by 
> including a flow identification option in the BA, and setting the FID
>  field in the value of the FID that is not found and the Status field
>  to 135 (FID not found).
</old text>

<new text>
If the value of any of the FID fields included in the flow summary
option is not present in the list of flow binding entries for this
mobile node, the home agent MUST reject this flow binding refresh by
including a flow identification option in the BA for each FID that is
not found, and setting the FID field with the value of the FID and the
Status field to 135 (FID not found).
</new text>

Comment 5
--------------
In section 5.3.3, in the third paragraph

> If the value of the FID field is present in the mobile nodes list of 
> slow binding entries the, home agent SHOULD refresh the binding entry
> 
s/ slow/ flow

> identified by the FID without changing any of the other parameters 
> associated with it.

Regards,
Benjamin Lim

---

From: <[email-masked]>
Date: Sat, 10 Oct 2009 00:36:51 +0200

Hello,

The document needs at least another revision before it would be ready
to be sent to the IESG.

Below is a review of the Flow bindings I-D
<draft-ietf-mext-flow-binding-03>:

- Update reference DSMIPv6 [I-D.ietf-mext-nemo-v4traversal] to RFC5555

- Update reference [I-D.ietf-monami6-multiplecoa] to RFC5648

>   In this document, a flow is defined as a set of IP packets matching a
>   flow descriptor.

The definition in the terminology section is better suited to describe
a flow. A flow can be identified by a flow descriptor but that is not
the definition of what a flow is.

>   This specification, however, does not define flow
>   descriptors and it is assumed that one or more ways of defining flow
>   descriptors are going to be defined in other specifications.

The specification now exists and hence should be referenced, i.e I-D:
draft-ietf-mext-binary-ts

>     Flow Identifier: An unsigned integer.

This definition really does not explain what a Flow ID is. Suggested
text: "A flow identifier uniquely identifies a flow associated with an
MN. It is generated by the MN and is cached in the flow binding list
maintained by the MN, HA, CN or MAP."

>     BID-PRI
>
>         This is a 7-bit unsigned integer placing each BID to a relative
>         priority with other registered BIDs.  Value "0" is reserved.  A
>         lower number in this field indicates higher priority, while
>         BIDs with the same BID-PRI value have equal priority.  This is
>         consistent with current practice in packet classifiers.

I dont see the value in having a priority associated with the
BID. This I-D proposes the creation of an ordered BID list. The reason
for having an ordered list is to process the packet with the BID which
has the highest priority in case there is no match for any Flow
ID. This is not required. The HA can decide to forward it to any CoA
based on some default binding cache entry or policy that it has.
I would suggest not modifying the Binding Identifier mobility option
as specified in RFC5648.

>      FID-PRI
>
>         This is an unsigned 8-bit priority field to indicate the
>         priority of a particular option.  This field is needed in cases
>         where two different flow descriptions in two different options
>         overlap.  The priority field decides which policy should be in
>         those cases.  A lower number in this field indicates a higher
>         priority.

I guess multiple FIDs can have the same priority, right? Is there a
default value in case no priority is assigned by the MN? Or because
you are creating an ordered list of FIDs, the priority for each FID is
unique? Also it would be good to reserve priority 0 for future use.
Some additional text to clarify this might be useful.

>      Action
>
>         This field specifies the action that needs to be taken by the
>         receiver of the binding update containing the flow
>         identification option.  The details of these requests are
>         discussed below.

- s/This field specifies/This 8 bit unsigned integer field specifies
- Can you include the values defined for the actions further below in
  the section immediately below the Action field definition? Makes
  reading easier.
- a/Action value 0 is reserved.
- In the example of Flow binding entries shown in Sec 4.4, the action
  field also includes Forward (in addition to discard and
  n-cast). Does this imply that not indicating anything in the Action
  field equates to Forwarding? Or should there be a separate value
  reserved for forwarding as well? Why not be explicit and just assign
  a value for forwarding as well.

> Rsvd
> Status

Specify these are 8 bit unsigned integer fields just to be explicit.

>   A number of sub-options can follow the option defined in this
>   section.

Rephrase as : A number of sub-options can follow the Flow
Identification mobility option defined in this section.

>4.2.1.  Binding Reference Sub-option
>  This section introduces the Binding Reference sub-option, which may
>   be included in the Flow identification option.

Is it really a MAY? If the MN is adding a new flow ID, the binding
reference sub-option is mandatory especially if the action is set to
Forward. From the processing rules defined in Sec 5.3.2.1 it seems
that the binding reference sub-option MUST be included and SHOULD have
a valid BID.

Adding a flow ID that does not have a valid matching BID in the BC
does not make much sense.

s/which may be included in the Flow identification option./which MUST
be included in the Flow identification mobility option.

>4.2.2.  Flow Description Sub-option
>      Sub-opt Type
>
>         Indicates the Sub-option type.  For the flow description sub-
>         option, this field SHOULD be set to one of the FD types defined
>         below.

- Move the text defining the suboptions to follow the definition of the
  suboption.
- s/Indicates the/8 bit unsigned integer which indicates the
- What is really implied by: "17-32 reserved for Flow Description
  formats"?
  Do these values have any predefined flow descriptions? Or does it
  imply that these values cannot be used by the MN?

>      Flow Description
>
>         The flow description corresponding to the type indicated by the
>         Sub-opt Type field.  Flow description is out of scope of this
>         document.

In I-D: draft-ietf-mext-binary-ts-00 Sec 3 says "
   [I-D.ietf-mext-flow-binding] defines the format for the traffic
   selector sub-option."

There is no traffic selector sub-option defined in the flow-binding
ID. The closest match I guess is the flow description field in the
flow-description sub-option. Revise the flow description text and also
check to see if the format of the traffic selector options fit into
the flow description field.

>4.3.  Flow Identification Summary Mobility Option

Is this option really required? The only reason I can gather from the
I-D is that every BU MUST include a list of all the FIDs that have
been added otheriwse they will be deleted. And hence the summary
option is an optimized way of sending a list of all the FIDs.

>   The Flow Identification Summary Mobility option includes one or more
>   flow identifiers (FIDs) for the purpose of refresing their state

Why do you need to refresh the state of the FIDs? They do not have a
lifetime. If a BU sent to the HA for example were to deprecate a BID
(interface/CoA no longer being available), the BU could also include
the FID options to modify the FIDs which use that BID. If an MN is
simply sending a BU to refresh its lifetime associated with one or
more CoAs, there is no reason to include the FID summary mobility
option.

>   The binding cache was then
>   extended by [I-D.ietf-monami6-multiplecoa] to include more than one
>   care-of addresses and to associate each of them with a Binding
>   Identifier (BID).

s/The binding cache was then/The binding cache has been
Also reference the MCoA RFC instead.

>      *  Active/Inactive flag: This flag indicates whether the entry is
>         active or inactive.

What does it mean when the entry is set as Inactive? Does it imply
that the BID is invalid? In the example shown in this section what
does the 3rd entry which is inactive imply? The MN does not specify in
the FID option sent in the BU whether a flow binding is active or
inactive. So how is this flag set and under what conditions?

>   If all of the
>   BIDs pointed to by a given entry are not valid BIDs in the binding
>   cache, the flow binding entry becomes "inactive", in other words it
>   does not affect data traffic.

If a BID is not valid, then the entry in the flow binding list should
be deprecated. Why would you have an entry in the flow binding list
when there is no valid BID in the BC?
Invalid BIDs should be treated as an error case. In the protocol
operations section the ID says that the HA will reject the addition of
a FID if the BID specified in it is invalid.

>  The third entry is marked as Inactive since the BID 4 does not exist
>   in the ordered list of BID entries below.  Inactive entries do not
>   affect traffic, i.e., packets are not matched against them.

See above reasoning. No reason to have such an entry. Should be viewed
as an error case.

> Ordered BID Entries

As stated earlier as well, there is really no need to order the
BIDs. Assigning a priority to the BIDs by modifying the BID Mbility
option is not required. Flow mobility works without assigning
priorities to BIDs.

>   Finally any remaining packets that do not match any of the entries
>   above will be simply forwarded to the care-of address indicated by
>   the highest order BID in the table below.

For the case where there is no matching FID, the HA/CN/MAP can handle
it based on policy or forward to a default CoA.

>   As indicated earlier the
>   flow description itself is defined in another document.

Reference draft-ietf-mext-binary-ts

>5.1.1.  Preferred Care-of address
>
>   Any node that supports this specification MUST maintain an ordered
>   list of care-of addresses for each mobile node it maintains a list of
>   flow bindings for.  The ordered list of care-of addresses is built
>   based on the BID-PRI field of the Binding Identifier option (see
>   Section 4.1).
>
>   The ordered list of BIDs is used to determine how to forward a packet
>   to a given mobile node when the packet does not match any of the flow
>   binding entries defined in Section 4.4.  A packet that does not match
>   any of the flow binding entries SHOULD be forwarded to the care-of
>   address identified by the BID with the highest priority i.e., lowest
>   BID-PRI value.

See reasons above why BID-PRI is not needed and how packets which do
not match any FIDs can be handled in a more simpler/implementation
specific manner.

>   In other words, two flow
>   identification options in the same message can not be about the same
>   flow binding.

s/can not be/MUST not be

>   All flow binding state MUST be refreshed in every binding update the
>   mobile node sends.  Any previously registered flow binding that is
>   not included in a given binding update will be deleted.  So, any flow
>   bindings that are not added or modified by a flow identification
>   option, but have previously registered and need to be maintained MUST
>   be included in a flow summary option.  Only one flow summary option
>   can be included in a given binding update.

This is suboptimal. Why do you need to include the FID options in
every BU. The MN may be sending a BU to refresh the lifetime of a CoA
or adding a new CoA etc. Requiring that FID options be carried in
every BU even when the FID option does not have any implication is
simply an overhead. Additionally there is no reason to keep refreshing
FIDs.

>   When the mobile node sends a binding update it MUST refresh all flow
>   bindings it wants to maintain even if it does not want to change any
>   of their parameters.

Why?

>5.2.4.  Removing flow bindings
>
>   Removal of flow binging entries is performed implicitly by omission
>   of a given FID from a binding update.

It would be better to have an explicit flag in the Flow ID mobility
option whether the operation is an add/modify/delete rather than this
implicit mechanism. Also you would avoid having to send the flow
summary option as a means to deprecate FIDs.

>   When all the BIDs associated with a flow binding are removed, the
>   flow binding MUST be marked as inactive in the list of flow binding
>   entries as shown in Section 4.4.

If all BIDs are removed and the rule is other than discard, the flow
binding itself should be deprecated. Why keep such a flow binding?

>   If the FID field of the flow identification option is already present
>   in the list of flow binding entries for this mobile node, the home
>   agent MUST reject this flow binding add request by copying the flow
>   identification option in the BA, and setting the Status field to 135
>   (FID already in use).

Why? It could be a modify operation for an existing FID? How do you
specify whether an operation is add or modify?
An HA which receives a BU with a FID which already exists for that MN
is simply viewed as a modify operation, right?

>   A de-registration binding
>   update (with a zero lifetime) would result in deleting all bindings
>   regardless of the presence of the Flow summary option.

It would be useful to include a section which explains what happens
when the MN returns to its home link and deregisters.

>   identified by the FID without changing any of the other parameters

slow binding entries? ;)

>   If, however, the action
>   indicated in an entry of the list of flow bindings is "n-cast", the
>   entry must indicated a BID.

s/the entry must indicated a BID/the entry must indicate more than one
valid BID.

>   If none of the
>   BIDs pointed to in a flow binding entry is valid then the entry is
>   considered to be inactive (as defined in Section 4.4) and is skipped.
>   In other words packets should not be matched against that entry.

Should that Flow binding be deprecated?

-Raj

On 10/6/09 6:30 PM, "ext Laganier, Julien" <[email-masked]> wrote:

> Folks,
>
> Hereby we're starting a two weeks WGLC on our "Flow Bindings in Mobile IPv6
> and NEMO Basic Support" document, available at the following URL:
>
> Please review the specification, post your comments to the mailing list, and
> state whether or not you think the document is ready to be forwarded to IESG
> before 2009-10-20 6:00PM PST.
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 19 Oct 2009 09:45:04 +0100

Hi folks,

Just to apologize for the delay in dealing with the comments so far.
We are in the process of reviewing all of them and we will be back
with you soon with responses.

Regards
George

---

From: Conny Larsson <[email-masked]>
Date: Mon, 19 Oct 2009 22:25:01 +0200

Hi,

Comments (a detailed review will be done when the draft has been updated)

There has been a lengthy discussion on the mailing list regarding 
support for bidirectional transfer of flow descriptors. A number of 
arguments have been stated both in favor of bidirectional transfer and 
against it. I'm in favor of adding support for bidirectional transfer 
and believe it should be added according to what has previously been 
agreed in the WG charter.

There has also been a discussion about support for binary and ASCII flow 
descriptors. The draft is currently written only to fit the binary 
format. I see no reason for this approach. The draft could easily be 
changed to fit both formats.

I see no reason for draft-ietf-mext-flow-binding-03 to be forwarded to 
IESG before the above issues have been fixed.

Regards
Conny

-- 

line

*CONNY LARSSON M.Sc.* *
Senior Research Engineer*

Ericsson AB
Ericsson Research, Packet Technologies
Isafjordsgatan 14E
SE-164 80 Stockholm, Sweden
Phone +46 10 714 8458
SMS/MMS +46 70 267 3556
[email-masked]
www.ericsson.com

Ericsson

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 20 Oct 2009 10:49:46 +1100

Hi Conny, 

We need the comments now, not after the document is updated :). This is WGLC
and we're updating the document as a result of reviews.

The bidirectionality issue was discussed and it was decided that there is no
case for it. This was sent to the list by the chairs. So we won't be adding
this to the draft. 

Hesham

---

From: "Yuri Ismailov" <[email-masked]>
Date: Tue, 20 Oct 2009 09:55:01 +0200

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

Regards
Yuri

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 20 Oct 2009 08:11:13 -0700 (PDT)

Hi Conny, Hesham,

----- Original Message ----
> From: Hesham Soliman <[email-masked]>
> To: Conny Larsson <[email-masked]>; "Laganier, Julien" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Mon, October 19, 2009 6:49:46 PM
> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03
> 
> Hi Conny, 
> 
> case for it. 

I don't think this reflects the situation.

The right answer is that flow revocation and possibly other flow binding operations initiated by HA will be taken up as part of MEXT rechartering.

BTW we revised our draft, here is the link to the revised draft:

http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-01.txt

Regards,

Behcet

---

From: "Yuri Ismailov" <[email-masked]>
Date: Wed, 21 Oct 2009 10:06:42 +0200

Hi,
Sorry for jumping in, but did not understand the point with re-chartering.
As I can see it is in the charter.

/yuri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Tuesday, October 20, 2009 5:11 PM
To: Hesham Soliman; Conny Larsson; Laganier, Julien
Cc: [email-masked]
Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03

Hi Conny, Hesham,

----- Original Message ----
> We need the comments now, not after the document is updated :). This 
> is WGLC and we're updating the document as a result of reviews.
> 
> The bidirectionality issue was discussed and it was decided that there 
> is no case for it.

Regards,

Behcet

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 21 Oct 2009 19:21:32 +1100

Hi Raj, 

Thanks for the comments. Until the draft is updated (we discussed the
comments so far and George is going to propose text and do the new rev),
I'll give a quick overview comment in response.

You have two main comments that manifest themselves in various forms below:
1. Questioning the need for PRI
2. Questioning the need to include existing bindings in the BU to refresh
them. 

Answers:
1. We have to have a PRI for the HA to work out the priosirities of
bindings. IFF two PRI values are the same then the HA will select one of
them based on means out of our scope. Removing the PRI is essentially asking
the MN to "hope" that the HA arranges them properly.

2. MIPv6 basically allows one BU to completely overwrite the previous BU.
This makes the implementation simple. Hence, if you don't include something
in a BU it is removed. You could argue for a different approach but I think
you'll find that it's more complex and likely more BW consuming. This way
it's fairly easy to keep things in sync between the MN and HA.

Regarding how the HA knows if it's an "add" or "modify" operation, it
doesn't need to, when it receives an FID it checks if it already exists, if
yes then it overwrites it with the new one, if no then it creates a new one.
Simple! 

George will respond to your comments about inactive bindings.

Hesham

---

From: "Yuri Ismailov" <[email-masked]>
Date: Wed, 21 Oct 2009 10:25:28 +0200

Hi Marcelo,
Got the point
Regards
Yuri

-----Original Message-----
From: marcelo bagnulo braun [mailto:[email-masked]] 
Sent: Wednesday, October 21, 2009 10:24 AM
To: Yuri Ismailov
Cc: Behcet Sarikaya; Hesham Soliman; Conny Larsson; Laganier, Julien; [email-masked]
Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03

Hi Yuri,

about the rechartering:

the main challenge that MEXT has is how manage the energy.

In order to work on something, we not only need to decide that this is not broken, but also that we want to invest the limited amount of energy of the WG in this topic _instead_ than investing in another topic.

and this is why we need a rechartering, so we can pick this topic and not pick another one or viveversa.

Makes sense?

Regards, marcelo

Yuri Ismailov escribió:
>> The bidirectionality issue was discussed and it was decided that 
>> there is no case for it.
>>     
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 21 Oct 2009 10:24:01 +0200

Hi Yuri,

about the rechartering:

In order to work on something, we not only need to decide that this is 
not broken, but also that we want to invest the limited amount of energy 
of the WG in this topic _instead_ than investing in another topic.

and this is why we need a rechartering, so we can pick this topic and 
not pick another one or viveversa.

Makes sense?

Regards, marcelo

---

From: Conny Larsson <[email-masked]>
Date: Wed, 21 Oct 2009 16:44:24 +0200

Hi Hesham,

See inline.

Regards
Conny

> and we're updating the document as a result of reviews.
Your draft is only considering the binary flow descriptors and I see no 
reason for this limitation. It has previously been suggested that your 
draft only should handle the transfer and operation of flow descriptors. 
Specific flow descriptor handling should be put in a separate draft.

To be more specific. In case of ASCII format there is no need for the 
FID and FID-PRI fields in Figure 2. They are only used for the binary 
flow descriptors. Besides this all option length fields indicates the 
length of the option in 1-octet unit, not 8-octet units.

The Binding Reference sub-option (section 4.2.1), the Flow Description 
sub-option (section 4.2.2) and the Flow Identification Summary option 
(section 4.3) are binary specific things and should be taken care of by 
that draft, they are not needed for the ASCII format.

Making these changes, and perhaps some minor modifications related to 
these changes, would make the draft look much better. I believe it's doable.
> case for it. This was sent to the list by the chairs. So we won't be adding
There is a draft making the case for HA to MN initiated flow bindings, 
but this is a separate discussion from the one above.

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 21 Oct 2009 19:27:42 +0100

Thanks a lot Ben...all comments below resolved....but also see inline.

Geroge

> I have reviewed the draft and it seems to be in good shape. Some

GT> Done.

> Comment 2

GT> Yes, Dave caught that one too. I will do (b).

> Comment 3

GT> Yes true. Fixed.

> I prefer b) as I feel n-cast covers the forward action.

GT> I agree. done.

> Comment 4

GT> done.

> Comment 5

GT> done

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 21 Oct 2009 13:21:58 -0700

Hi Conny,

Please see my individual comments below:

> Specific flow descriptor handling should be put in a separate draft.

I do not understand your statement that the WG draft considers only binary flow descriptors. The WG draft does not imply any type of flow descriptor in particular, and reserves sub-option types 17-32 for various types of flow descriptors.

> length of the option in 1-octet unit, not 8-octet units.

I do not understand why you're tying the need for Flow IDentifier and FID Priority to a binary format.

The Flow IDentifier and FID Priority are in intrinsic part of the flow binding protocol extension considered so far by the WG which implies ordering the flow binding rules. 

The need for them do not depend on the format used to describe how to match a specific flow aggregate, it is a design choice that has been made. That a flow binding rule matches a traffic aggregate based on an ASCII or binary description doesn't change the fact that rules have to be ordered.

> that draft, they are not needed for the ASCII format.

Same comment as above:

- The flow description doesn't imply a specific format: 

   Flow Description

   The following values are reserved for the sub-option Type values are
   defined for Flow Description:

      17-32 reserved for Flow Description formats.

- The flow identification summary doesn't imply a specific format:

   The Flow Identification Summary Mobility option includes one or more
   flow identifiers (FIDs) for the purpose of refreshing their state.

> these changes, would make the draft look much better. I believe it's

At this point in the lifecycle of a WG document (i.e., the WG Last Call) I don't think we want to change the basics of the flow binding mechanisms, that is, that packets are matched against an ordered ruleset.

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 22 Oct 2009 10:20:53 -0700

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

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 23 Oct 2009 10:00:17 +0100

Hi Raj,

Thanks for the very detailed review, it is appreciated.
I have taken on board most of your comments.

See also inline.

GT> done

> draft-ietf-mext-binary-ts

GT> will do

> maintained by the MN, HA, CN or MAP."

GT> nice, thanks.

> I would suggest not modifying the Binding Identifier mobility option

GT> I think Hesham responded to this but the bottom line is that it is
not reasonable for the MN to be able to route any specific flow as it
wants, but not being able to indicate what the default CoA should be.

> Some additional text to clarify this might be useful.

GT> I have already dealt with this in another e-mail, but each flow
binding has a unique FID-PRI. I will reserve value 0 as you suggest.

> - s/This field specifies/This 8 bit unsigned integer field specifies

GT> ok

>  the section immediately below the Action field definition? Makes

GT> Yes, done.

GT> done

>  a value for forwarding as well.

GT> Yes, caught by others too...as I said before it s remnant from an
older version. which I have now fixed.

> Specify these are 8 bit unsigned integer fields just to be explicit.

GT> A bit extreme for the reserved bits but will do for Status

GT> done

> does not make much sense.

GT> It does when Action=Discard.

> - Move the text defining the suboptions to follow the definition of the

GT> OK

> - s/Indicates the/8 bit unsigned integer which indicates the

GT> OK

>  imply that these values cannot be used by the MN?

GT> This is the by product of splitting Traffic Selector (ex. Flow
Description) definitions out of the Flow Bindings draft. It simply
reserves some Sub-Type values for use by Traffic Selectors.
draft-ietf-mext-binary-ts will for example use some of these values.
Another way would be to define the TS sub-types for binary TSs only
for now...which would probably make things clearer. In this case only
the body of these TSs would be defined in a separate draft.

> the flow description field.

GT> Yes, we renamed Flow Description to Traffic Selector after the
publication of v03 of the draft. Next version will use the term
Traffic Selector, instead of Flow Description.

> more CoAs, there is no reason to include the FID summary mobility

GT> Hesham dealt with this point.

> Also reference the MCoA RFC instead.

GT> OK

> inactive. So how is this flag set and under what conditions?

GT> A BID is becoming invalid when it is deregistered. in other words,
if an MN creates a Flow Binding and points it to BID1, but then some
time later it deregisters BID1, then we say that the flow binding
pointing to BID1 (assuming it only points to BID1) becomes
inactive....which means that the HA keeps the flow binding state but
does not use it to match packets with This is done in anticipation of
the fact that CoAs might come and go, and we would like to avoid
having the M N to have to keep reregistering flow bindings (with
length TSs)  just because a BID had to be removed and be replaced by a
new one a few seconds later.

> a FID if the BID specified in it is invalid.

GT> See above

> See above reasoning. No reason to have such an entry. Should be viewed

GT> Its not an error case, see above.

> it based on policy or forward to a default CoA.

GT> I think we have answered this.

> Reference draft-ietf-mext-binary-ts

GT> OK

> not match any FIDs can be handled in a more simpler/implementation

GT> See above

>>   identification options in the same message can not be about the same

GT> There is already a "MUST" about this in the previous sentence.
"More than one flow identification options MAY be
                    included in the same binding update but each of them MUST
                    include a different FID.".
The sentence you quoted is just further explanation.

> simply an overhead. Additionally there is no reason to keep refreshing

GT> Hesham dealt with this point too.

>>   bindings it wants to maintain even if it does not want to change any

GT> See Hesham's e-mail

> summary option as a means to deprecate FIDs.

GT> This is how it was earlier and the authors and WG decided to
change it. The current mechanism is actually more natural to the
normal MIPv6 operations. Beleive me we went through the exercise with
add/modify/delete and it got rather complex without any benefit. See
also below when I summarize the current technique which I think is
very simple.

> binding itself should be deprecated. Why keep such a flow binding?

GT> As I said so that the MN does not have to keep sending a Traffic
Selector for flows (especially think long term ones) just because a
BID was temporarily removed.

> is simply viewed as a modify operation, right?

GT> This is a bug so I am correcting the text. The mechanism is very
simple and straightforward. When a BU is received the HA looks at the
list of FIDs.
- If for a given FID the HA already has state, the flow binding in the
BU replaces the flow binding in the HA (i.e., this is a Modify).
- If for a given FID the HA does not have state, then the flow binding
is added to the HA (i.e., this is an addition),
- If the HA has flow bindings with FIDs that are not included in a BU,
the flow bindings are removed from the HA (i.e., this is a delete)

> when the MN returns to its home link and deregisters.

GT> Good idea. I will add text explaining that returning home is
performed as per RFC3775 and RFC5648...something like the following:.

                <section title="Returning Home">
                    <t>This specification is compatible to the home registration
                        procedures defined in <xref target="RFC3775"/> and <xref
                            target="RFC5648"/>. More specifically, if the mobile
                        node performes an <xref target="RFC3775"/> style
                        deregistration, all of its bindings, including flow
                        bindings are deleted. If the mobile node, however,
                        performs an <xref target="RFC5648"/> style home
                        registration, then the home link is associated with a
                        specific BID and so, as far as this specification is
                        concerned, it is treated as any other link associated
                        with a given BID.</t>
                </section>

>>   identified by the FID without changing any of the other parameters

GT> yes...very slow ;-)

> s/the entry must indicated a BID/the entry must indicate more than one

GT> ok

> Should that Flow binding be deprecated?

GT> it just become inactive as explained above.

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 23 Oct 2009 10:07:49 +0100

Hi Yuri,

Comments inline...

On Tue, Oct 20, 2009 at 8:55 AM, Yuri Ismailov
<[email-masked]> wrote:
> Hi,
> after re-reading the draft come up with the comment on "Discard" action in
> "Flow Identification Mobility Option"
> separate subsection clarifying behavior of MN and HA before and after the
> "Discard" action was issued by MN.
>
> 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.

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 23 Oct 2009 10:24:29 +0100

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

---

From: "Yuri Ismailov" <[email-masked]>
Date: Fri, 23 Oct 2009 14:20:01 +0200

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.

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.

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?

Regards
Yuri

-----Original Message-----
From: George Tsirtsis [mailto:[email-masked]] 
Sent: Friday, October 23, 2009 11:08 AM
To: Yuri Ismailov
Cc: Laganier, Julien; [email-masked]
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 <[email-masked]> wrote:
> Hi,
> after re-reading the draft come up with the comment on "Discard" 
> action in "Flow Identification Mobility Option"
> Otherwise

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

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 23 Oct 2009 08:17:28 -0700

Thanks George, this looks good.

--julien

> Sent: Friday, October 23, 2009 2:24 AM
> To: Laganier, Julien
> Cc: [email-masked]; [email-masked]
> > 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:
> >
> > 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:
> >
> >   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):
> >
> > 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

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 23 Oct 2009 16:53:41 +0100

Hi Yuri, comments inline.

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

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

GT> What prevents you from  creating another FID that is specific for that flow?

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

---

From: "Yuri Ismailov" <[email-masked]>
Date: Mon, 26 Oct 2009 09:27:32 +0100

Hi George, all

George, what I understood from
*******
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.
********
is that you do not see any point of further discussion.
Well, I will anyway provide the text which I think is suitable for clarification.
On the other hand I disagree about the fact that TCP connection suffering performance is more clearer than TCP connection stop working. Strange that this is not obvious.

Below is the proposal for the text to add in the paragraph describing "Discard" action in chapter 4.2

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

Regards
Yuri

-----Original Message-----
From: George Tsirtsis [mailto:[email-masked]] 
Sent: Friday, October 23, 2009 5:54 PM
To: Yuri Ismailov
Cc: Laganier, Julien; [email-masked]
Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03

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.

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

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

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 26 Oct 2009 19:58:39 +1100

Yuri,

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

>> 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.
>> 
> 
>> 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.
>> 
> 
>> 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?
>> 
> 
> 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
>> 
>> 
>> 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.
>> 
>> flow binding-specific lifetime. If an MN wants to remove a flow binding it
>> sends a BU which does not include the corresponding FID.
>>

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 26 Oct 2009 09:47:29 +0000

> => I don't understand what this means. Can you clarify?

GT> Yes this seems strange since there is no way to indicate Discard
Action without providing an FID.

> => This part is clear to me.

GT> Yuri, I will add this to the document, no problem.

---

From: "Yuri Ismailov" <[email-masked]>
Date: Mon, 26 Oct 2009 12:11:40 +0100

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"

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:[email-masked]] 
Sent: Monday, October 26, 2009 9:59 AM
To: Yuri Ismailov; George Tsirtsis
Cc: Laganier, Julien; [email-masked]
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.

  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"

Hesham

>> 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.
>> 
> 
>> 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 
>>> separate subsection clarifying behavior of MN and HA before and 
>>> after the "Discard" action was issued by MN.
>>> 
>>> 1.The case when installed FID represent ranges of port numbers and 
>>> IP addresses. If MN decides to discard a particular flow within the 
>> 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.
>>

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 26 Oct 2009 22:54:32 +1100

On 26/10/09 10:11 PM, "Yuri Ismailov" <[email-masked]> 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
> 
> 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

=> 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:
> 
> Similar  should be done if there are ranges of IP addresses and/or both IP
> addresses and port numbers covered by a single FID
>

---

From: "Yuri Ismailov" <[email-masked]>
Date: Mon, 26 Oct 2009 13:12:21 +0100

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

Regads
Yuri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Monday, October 26, 2009 12:55 PM
To: Yuri Ismailov; George Tsirtsis
Cc: Laganier, Julien; [email-masked]
Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03

On 26/10/09 10:11 PM, "Yuri Ismailov" <[email-masked]> 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
> 
> 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:
> 
> Similar  should be done if there are ranges of IP addresses and/or 
> both IP addresses and port numbers covered by a single FID
> 
>>> 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.
>>> 
>> 
>> 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
>>> 
>>> 
>>>> 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 
>>> 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.
>>>

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 26 Oct 2009 23:18:41 +1100

On 26/10/09 11:12 PM, "Yuri Ismailov" <[email-masked]> 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

---

From: "Yuri Ismailov" <[email-masked]>
Date: Mon, 26 Oct 2009 13:35:31 +0100

OK,
Hope to see you in Hiroshima
Regards
Yuri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Monday, October 26, 2009 1:19 PM
To: Yuri Ismailov; George Tsirtsis
Cc: Laganier, Julien; [email-masked]
Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03

On 26/10/09 11:12 PM, "Yuri Ismailov" <[email-masked]> 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

>> 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
>> 
> => 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
> 
> 
>> 
>>> 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.
>> 
>>>> 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> What prevents you from  creating another FID that is specific 
>>> GT> for that
>>> flow?
>>> 
>>>> 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?
>>>> 
>>> 
>>> 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 
>>>>> 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
>>>> GT> Discarding packets will drop connections....yes...I do not 
>>>> GT> think

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 26 Oct 2009 15:02:13 +0000

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

---

From: Frank Xia <[email-masked]>
Date: Mon, 26 Oct 2009 10:13:39 -0500

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" <[email-masked]>
To: "Hesham Soliman" <[email-masked]>
Cc: "Laganier, Julien" <[email-masked]>; <[email-masked]>
Sent: Monday, October 26, 2009 10:02 AM
Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03

>>> way to

---

From: "Yuri Ismailov" <[email-masked]>
Date: Mon, 26 Oct 2009 16:43:13 +0100

George,
There is no need to give infinite number of examples, just one for clarifying purposes
I think it makes things clearer
/yuri

-----Original Message-----
From: George Tsirtsis [mailto:[email-masked]] 
Sent: Monday, October 26, 2009 4:02 PM
To: Hesham Soliman
Cc: Yuri Ismailov; Laganier, Julien; [email-masked]
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 <[email-masked]> wrote:
>> 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
>>
>>
>>>
>>>>> 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> I think the implication of dropping packets is much clearer 
>>>> GT> 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
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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
>>>>> 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