Subject: [Monami6] Comments on draft-soliman-monami6-flow-binding-02

From: Gábor Fekete <[email-masked]>
Date: Tue, 03 Oct 2006 16:08:23 +0300

Hi Hesham and everybody,

Sorry for this long mail!
Here are some comments and questions on
draft-soliman-monami6-flow-binding-02.txt.
I refer to draft-ietf-monami6-multiplecoa-00.txt as "[3]".

1. Section 2.2.  Binding Cache and Binding Update list extensions:

 "... The BID sub-option includes one or more
  BIDs as defined in [3]."

  According to [3], 1 BID sub-option contains 1 BID. So, I assume that
  this sub-option is just semantically the same as the BID sub-option
  of [3]. Is it so that this BID sub-option has the same fields as the
  option in [3]? Is the only difference that it allows to include multiple
  (BID, Priority/Status, C, R, Reserved, [CoA]) groups unlike [3]?

2. Section 2.2.

 "... When this sub-option is included in the Flow
  identification option it associates the flow described with one or
  more BIDs that where already registered with the recipient of the BU.
  A BID sub-option is not necessarily included in the same BU, but MUST
  be already known to the receiver of the BU."

  From this text, it seems that it talks about two different BID 
sub-options.
  One included in the BU itself (as in [3]) and the other is in the FID 
option.
  Besides, [3] is also ambiguous since it talks about sub-option in Section
  4.3.1, whereas it should say only "option".

  and then Section 3.1:

 "The solution presented in this specification can be used with or
  without the solution in [3]...."

  So, does this mean that e.g. n-casting can be used without [3] since
  this draft already has support for a BID sub-option? And then does this
  mean that the MN can add/register CoAs using a BID sub-option in the FID
  option? I guess no, but in the text it is not really clear.
  How can you assign a BID to a CoA (BC entry) without [3]?

3. Section 3.2

  "... On one
   hand, an entry is now identified by the pair (home address, FID)
   because several Care-of addresses may be bound to a single home
   address."

   and then Section 7.1:

  "o  If the flow option included an action field indicating a request
      for n-cast, the home agent needs to create muliple logical entries
      in its binding cache.  All flows matching the one in the option
      would be n-cast to the care-of addresses pointed to by the BIDs
      sub-options or the set of registered care-of addresses...."

   I understand that we are talking about conceptual data structures but
   even then we should stay consistent.
   For me, it is hard to see how a (HoA, FID) pair can identify uniquely a
   BC entry in the above n-cast case. I understand it as the HA creates
   multiple BC entries with the same FID here but with different CoAs.

   The "or the set of registered care-of addresses" part also confuses 
me. It
   also indicates as if the MN could do some kind of bulk registration here
   with a single BU. If we do not use [3] then I see no explanation of 
bulk-reg
   in this draft. Or then what is the difference between "registered" 
CoAs and
   CoAs "pointed to by the BIDs"?

   And then the rest of the text is

  "...If only
   one BID were included in the BID sub-option and it pointed to a
   different care-of address from the one included in the packet,
   then packets matching the flow would be bicast to those two
   addresses."

   Why is this needed? For me it is like: The BU has a FID option and one or
   more BID sub-options. Then the flow matching the FID option is 
n-casted to
   the CoA of the BU (src addr, or alt-coa) and to all the CoAs (BC entries)
   referred to by the BID sub-options.
   Am I totally lost here?

4. Section 3.3

   [3] says nothing about a "default binding". I cannot even find the word
   "default" in the whole document. Do you refer here to the priority field
   of the BID option of [3]? How can the MN add a "default" entry? Or is
   the default entry a "wild card" entry?

5. Section 5.1.1

  "o  The PRI field is set to indicate the priority of the rule in case
      of an overlap between rules.  An overlap can occur when multiple
      flows match the flow description in the option."

  Should not it be

  "o  The PRI field is set to indicate the priority of the rule in case
      of an overlap between rules.  An overlap can occur when one flow
      matches multiple flow description options."

  instead?

6. Section 5.1.2

  "o  If either the source or destination address fields are present,
      their prefixes MUST be set to 128, to indicate a single address."

  Why is this restriction needed? What if the CN is a router? Why cannot the
  source be a whole network?

7. Section 5.1.4

  "...As such a
   mobile node / mobile router receiving a Binding Acknowledgement in
   response to the transmission of a Binding Request MUST determine..."

  Should not it be Binding Update rather than Binding Request?

8. Section 5.2

  I do not see how n-casting can be done without [3]. Then it means that
  to change the CoA of an n-cast binding the MN MUST use [3].
  Consider an n-cast BC fragment like this:

  HoA - CoA-1 - FID-1 - BID-1
  HoA - CoA-2 - FID-1 - BID-2

  In this case one cannot change CoA-1 to e.g. CoA-3 without [3] (there are
  no BIDs and FID-1 is not unique).
  So again, I'm asking about the relationship between this draft and [3].
  Is it so that
  draft-soliman = FD [+ BID sub-opt] or
  draft-soliman = FD [+ BID sub-opt + draft-ietf-monami6-multicoa] ?

9. Section 5.4

  "This will cause the home agent to remove all
   Flow Bindings that are linked to the home address, including the flow
   bindings."

  May be

  "This will cause the home agent to remove all
   Flow Bindings that are linked to the home address, including the
   Mobility Bindings."

10. Section 6.1

  "o  If the BID sub-option were present in the option, it MUST include
      the BID corresponding to the care-of address in the binding
      update...."

  Why? Why cannot it point to another already registered CoA?
  Furthermore:

  "   ... If the BID sub-option contained BID that were not already
      authorized, ____or____ if the BID did not correspond to to the care-of
      address in the packet, the option MUST be rejected by including an
      error code in the Status field of the option included in the
      binding acknowledgement."

  This "or" should be "and", or not?
  Just because later it is said:

  "o  If the BID sub-option were present, the correspondent node MUST
      ensure that the BID points to the care-of address in the packet,
      or to an already authrozied care-of address.  Otherwise the option
      MUST be rejected with an appropriate error code."

  I feel that these two points should be the same.

Regards,
Gabor Fekete

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 3 Oct 2006 06:51:13 -0700

Thanks for the prompt review, some answers inline.

 >   (BID, Priority/Status, C, R, Reserved, [CoA]) groups unlike [3]?

=> Yes and no. It allows for multiple BIDs but not the Priority/Status, C, R ...etc.
Only the BID is included. Note that this is included as an index and does not modify any of the information sent in [3], therefore there is no need for anything except the BID itself.

 >   4.3.1, whereas it should say only "option".

=> Yes in [3] it should be an option. And yes your intrepretation is correct. This is a *new* sub-option and does not copy the option in [3].

 >   this draft already has support for a BID sub-option? 

=> No, you can't do n-casting or aggregate without [3]. Perhaps this sentence should be clarified to indicate that some loss of functionality will take place if you don't use [3]. But I think that is clear later in the draft.

    And 
 > then does this

=> No. The text says that the BID must already be known to the receiver of the BU, isn't that clear? 

 >   How can you assign a BID to a CoA (BC entry) without [3]?

=> You can't.

 >    multiple BC entries with the same FID here but with 

=> Sure. On the other hand you could implement this as follows:

HoA    FID       Forward dst

HoA -- FID1 ----- CoA1
         | 
          -------CoA2

I'm not advocating a particular way of doing it, but both are feasible. 

 >    CoAs "pointed to by the BIDs"?

=> Of course, bulk registration implies the use of [3]. This is stated in the motivation for using [3]. 

 >    referred to by the BID sub-options.

=> I think you said the same thing in a different way :) Now I'm confused. What you say is exactly what is meant by the text you refer to. If clarification is needed please suggest rewording.

 >    the default entry a "wild card" entry?

=> The Default entry is done using [3]. I think we should clarify that in the next rev. 

 >       matches multiple flow description options."

=> Yes, thanks. Will fix that.

 >   source be a whole network?

=> Well, the BC is intended to be per addressin MIPv6. MIPv6 does not support the BC per prefix and the MN has no way of knowing if the CN is a router. So, while it might be possible, I'm reluctant to add it without much further investigation.

 >   Should not it be Binding Update rather than Binding Request?

=> Yes.

 > 
 > 8. Section 5.2
 > 
 >   I do not see how n-casting can be done without [3]. 

=> It can't. We assume that [3] is used for n-casting to work. I think this is clear in the operations sections
(CN/HA/MAP operations).

 >    Flow Bindings that are linked to the home address, including the

=> What do you mean by "Mobility Bindings"? We consistently refer to it as flow bindings in the doc. 

 >   I feel that these two points should be the same.

=> We might have messed up this part a bit because we changed it multiple times. The intention is that the BID (if present) has to contain the CoA in the BU or another already *bound* CoA. If none of that is true, the FID must be rejected. So I think we need to reword those paragraphs accordingly. I agree they're not very clear. 

Thanks,
Hesham