|
Hi Hesham, All, I went through draft-ietf-mext-flow-binding-01. There are
some issues that need to be resolved in particular based on the latest version
of the MCoA draft. General comments: - I think the interactions with rfc3775 compliant BUs
should be captured in the document. For example what happens if the BC of the
HA has two FID entries for HoA1 and then the MN sends a BU without any FID/BID
but just with the CoA? I think the correct behavior is that the new BU will
overwrite the BCE and the MN will go back in a rfc3775 operation mode. This
should be allowed and captured in the MN and HA operations - We should have a brief section about DSMIPv6
applicability in the same way we have it in the MCoA draft (section 8). My
understanding is that the same considerations of MCoA draft apply (no bulk
registration for an initial binding when IPv4 CoA is used in order to perform
NAT detection) - Section 6.4 needs more details based on the home link
operation described in the latest version of the MCoA draft - the draft assumes that FID option can be used without
BID option. However based on the MCoA draft, a BU without a BID will replace
all the BCEs which contain a BID. I think some alignment is required on this.
Can we assume BID is always used when FID is used? Detailed comments: - Section 2: I would update the terminology as follows: Flow A flow is identified as a
set of data packets that are exchanged between two distant hosts
and can be univocally identified and grouped based on the Flow Description. Flow Description A set of instructions that
describes and univocally identifies a flow. - Section 3.2: the format of the Binding Reference
Sub-option is not clear. I guess the assumption is that the field BID should
point to a BID mobility option in the BU or to an existing entry in the BCE. It
is not also clear based on the text in this section why a MN would include more
than one BID for a specific FID: I think the motivation is to enable n-cast -
in this case I would add that in this subsection to make it clearer. - Section 4.1: the MCoA draft does not define any
preferred or default CoA. The Priority field in the BID option was removed a
few revisions ago. Therefore it is up to this draft to define a default CoA or
a default binding. I think we have two possibilities: 1) we mandate that the MN always has a default binding
with match-all filters 2) we allow the MN to not have a default binding. In this
case there may be packets that do not match any FID in the BCE. The treatment
of these packets at the HA may be left implementation dependant or we may
mandate that packets that do not match any existing filters are discarded. The
latter would allow the MN to avoid signaling blacklist flows. The issue of the default binding requires changes also in
other section of the draft (e.g. 4.3, 6.1). We should also understand what
happens if a default FID is removed by the MN. - Section 4.4: An Add operation implies that the FID is new
and is not already used by the mobile node for any other flow
binding. If the Flow identification option is sent without any
flow description and with the PRO field indicating an Add operation,
this MUST be seen as a wild card request by the sender. A
wild card request implies that all flows should be directed to the particular
care-of address in the packet. The last statement is true only if there is not any other
entry which matches an incoming packet and has higher priority. We should
clarify that. - Section 6.1.1: o If the Action field is set to
indicate N-cast, the Binding Reference sub-option must
be present and it must contain one or more BIDs. If the
Binding Update sub-option includes only one BID, it must be pointing
to a care-of address other than the one included in the binding
update. Based on this, the n-cast would be done between the CoA
in the BID and the CoA in the source address of the packet. I think it would be
much cleaner to always include all BIDs for which n-casting is requested. The
source address of the packet is not processed as CoA when a BID is present
based on the MCoA draft (similarly to what happens in case the Alt-CoA option
is used). This comment applies also to the fourth bullet of section 8.1 - I think section 7 should be renamed to Correspondent
Node operations I have also some editorial comments but I will give them
offline to authors. Cheers Gerardo |