[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] about draft-ietf-mext-flow-binding-02.txt
Hesham Soliman escribió:
Thanks for the detailed review. Some answers inline
On 16/05/09 9:46 AM, "marcelo bagnulo braun" <marcelo at it.uc3m.es> wrote:
Hi,
Please find my comments about draft-ietf-mext-flow-binding-02.txt.
Flow binding: An entry in the list of flow binding associated with
a given mobile node.
circular definition, please rephrase.
=> ok.
BID-PRI
This is a 7-bit field placing each BID to a relative priority
with other registered BIDs. Value "0" is reserved for
implementation of [I-D.ietf-monami6-multiplecoa] that do not
support this specification. A higher number in this field
indicates lower priority,
Why is that? Is there a reason for having the higher value of a field
called BID PRI to mean _lower_ priority or are we just trying hard to be
counter intuitive?
=> I think George added this in a way to be consistent with the PRI field,
which you comment on below. Why is the PRI field that way? I don't know :) I
guess I did that one day when I was feeling counter intuitive. We can
reverse this
i would prefer that
same comment applies to:
FID-PRI
This is an 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.
Later the drafts reads:
The following values are reserved for the PRO field in this option:
0 Add a flow binding
1 Modify a flow binding
I haven't read the whole draft yet, but wouldn't make sense to avoid
this option. I mean, if the FID is new, then we create a new binding and
if the FID already exists, then it is a modification. I mean, the
problem with doing the approach described is that it has the potential
of creating contradictory situations... for instance what happens if we
receive an option with a value of 0 in the PRO field but there is no
existing binding with the BID?
=> I think you mean 1 not 0. It would be an error, which illustrates the
advantage of this, i.e. It catches any mismatch between the MN and HA.
:-)
but one would expect people implementing this are smarter than me
Anyway, i see below that you are fine with this, so
(I mean, i understand that the flow
binding messages are atomic i.e. that each time w new one is received it
not an incremental change from the previous one, but it contains the
complete information about the binding, correct? If that is the case, we
better simply create a new one, even if the sender thinks this is a
modifciation, since the msg actually provides all the information for
the creation of the flow binding, correct?)
=> It can be done this way if we don't care about catching mismatches. This
orginally contained explicit deletes as well, which we removed. I know that
it now seems redundant with only those two operations.
later on the draft reads:
1 Forward. This value indicates a request to forward a flow to
the address indicated in the Binding Reference sub-option. A
single BID MUST be associated with this Action.
...
3 n-cast. This value indicates a request to replicate the flow to
several addresses indicated in the Binding Reference sub-option.
One or more BIDs MUST be associated with this Action.
What is the difference between a n-cast value with a single BID and a
Forward option? couldn't we just live with the n-cast option? (if it has
only one BID, it has the same behaviour as the forward option?
=> Yes we could.
Again, if there is not special value in having the forward and n-cast
separated, i would simplify it and have a single option for these, since
it seems simpler
LAter on it reads:
It should be noted that per-packet load balancing may have negative
impacts on TCP congestion avoidance mechanisms as it is desirable to
maintain order between packets belonging to the same TCP connection.
This behaviour is specified in RFC2702 [RFC2702]. Other negative
impacts are also foreseen for other types of real time connections
due to the potential variations in RTT between packets. Hence per-
packet load balancing is not currently supported in this extension.
I fully agree with this, but i fail to see why this is the correct place
to mention this. It probably belongs to somewhere else. Probably, we
should make even a stronger statement, i.e. the flow bindings separating
the packets of a TCP connection SHOULD NOT be used.
=> Ok about placement. SHOULD NOT? I think this is a MUST NOT.
don't have a strong opinion about this.
Also, it
affects any secure traffic with replay attack prevention.
right
so we need a statement not only about TCP. how would we scope the
statement then?
So it's not just
TCP. That's why the entire option is not allowed in the draft.
that makes sense to me, just that in the case of TCP, the performance is
worse, so i am dubious if we need to use a MUST NOT or simply a SHOULD NOT
The binding identifier option, defined in
[I-D.ietf-monami6-multiplecoa], registering a given BID which is then
indicated in the Binding Reference sub-option, MUST be either defined
in the same or earlier BU from the one including the binding
reference sub-option.
I think what this sentence means, but I fail to parse it properly. I
would suggest rephrasing
=> ok.
4.3. Flow Identification Summary Mobility Option
TBD
I guess more text is needed here...
later on...
The BIDs included in a given entry point to a corresponding entry in
the binding cache for the purpose of identifying a care-of address.
is there a verb missing in this sentence?
=> Yup needs rewording.
later on
Depending on the Action parameter in a given entry a valid BID is
required to make the entry "active".
How is that dependent of the action paramter?
The text tha follows, seem to imply that an entry is active or inactvie
depending on the BID not on the actions...
=> Agreed, this is left over and erroneous.
later on...
BID-PRI BID CoA
--------- --- ---
20 1 IP1
30 3 IP2
30 2 IP3
Ordered BID Entries
I would suggest moving this table right after the table describing the
Ordered Flow Binding Entries
=> ok.
5.2. Mobile Node Considerations
This specification allows the mobile node to maintain several
bindings in its home agent and to direct packets to different care-of
addresses according to flow bindings.
I understnad that not only the HA maintains the bidnings but also the CN
and the MAPs, so i think this should be included here.
=> Agreed.
The home agent list of flow bindings is manipulated by the mobile
node, via flow identification and flow summary options included in
binding update messages.
similar comment here. It is not only the HA list of bindings, but also
the CN and MAP list of bindings, right?
=> Yes.
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.
So, i really fail to see why we need the PRO bits. I mean, if every tome
we sent a BU it will contain all the info about all the bindings, it is
irrelevant if the binding is being created or modified in the options,
since we are including all the information anyway.
=> Yeah, I think you have a point about this. Like I said earlier, it used
to work different and contain more actions but I think you're right.
ok
Note that any inactive flow bindings, i.e., flow bindings without
associated BIDs that are marked as Inactive in the list of flow
binding entries (see Section 4.4, MUST also be refreshed, or
modified, to be maintained. If they are not included in a BU they
will be removed.
closing bracket missing
5.2.4. Removing flow bindings
Removal of flow binging entries is performed implicitly by omission
of a given FID from a binding update.
To remove a flow binding the MN simply sends a binding update that
includes flow identification and flow summary options for all the
FIDs that need to be refreshed, modified, or added, and simply omits
any FIDs that need to be removed.
what if the MN sneds a BUt wihtout the Flow binding option? are all the
flow bidings removed?
=> Without any FIDs? Yes they're all removed.
ok, it may be useful to state this (if nto already there and i missed it)
- if the Action indicates 'n-cast',
If the Binding reference sub-option is not included, 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 129 (Flow identification option poorly formed).
If the Binding Reference sub-option is present and includes BIDs
that are not present in the binding cache of the 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 TBD (BID not known).
If the Binding Reference sub-option is present and includes one or
more BIDs, and the BIDs exist in the mobile node's binding cache,
all the bods must exist? what if some exists and some don't?
=> What do you mean? You mean on a per FID or on aggregate?
I mean i the last paragraph quoted above, it reads:
If the Binding Reference sub-option is present and includes one or
more BIDs, and the BIDs exist in the mobile node's binding cache,
What if some BID exist and some other BIDs don't, how is the option
processed?
Regards, marcelo
later on...
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 modify
request
is this option only carried in a modify request? I understood that also
could be carried in an add request, correct?
=> Yes.
Hesham