Subject: [MEXT] Review of draft-ietf-mext-flow-binding-00

From: "Giaretta, Gerardo" <[email-masked]>
Date: Tue, 18 Nov 2008 11:28:18 -0800

Hi Hesham, All,

I went through draft-ietf-mext-flow-binding-00. I think the draft is very well written and quite stable to be a 00 version. However there are some issues that need to be resolved in particular based on the latest version of the MCoA draft. 

First issue is that the draft has expired :-)

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
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext