[Monami6] Questions on draft-nomadv6-mobileip-filters-03.txt.

Hello everyone,

And now, some questions on draft-nomadv6-mobileip-filters-03.txt.

1. Section 4.1.1 says:
  "Filters for Mobile IPv6 is applicable only in the context of a mobile 
   node maintaining multiple points of attachment to one or more 
   Internet administrative domains. ..."
  Why would not it be applicable with single point of attachment. E.g. the
  MN may have multiple CoAs on its single interface but the end-to-end
  characteristics of these CoAs may be different. Cannot it be?
  E.g. packets to different CoAs may be routed on different paths.

2. Section 4.1.1:
  "N    When set, the binding agent MUST act based on the functions 
        described in section 4.1.3 and add a new entry to the binding 
        cache without deleting any existing entries for the mobile ..."
  I guess this does not mean that "if the N bit is set then the agent
  MUST add a new entry". So I think this text should be deleted or
  clarified.

3. What if the N-bit is set and the BU is a CoA de-registration BU?
  E.g. Can a de-registration BU carry a Filter Deletion Extension?

4. What is the mechanism of matching flows? First match the destination
  address with a HoA and then find the proper CoA using the filters?

5. Section 4.1.3:
  "then a new one will automatically be configured by each involved 
   Filtering Agent to the lowest possible Index of 0.  "
  What does "configured" mean? Created? So the Agent would then create
  a Default filter for the HoA that has index 0, weight 1 and applies
  to any packet? Just because it is not clear from the text.

6. How does the MN specify the Default Filter? With a BU, N-bit set,
  no Filter Modules but only an FCL with index 0? Or can the Default Filter
  be more specific than "match any packet", that is, specifying with a BU,
  N-bit set, Filter Modules and an FCL with index 0?

7. At an agent, does every registered HoA have a Default Filter
  (or rather a Default Binding or Default CoA)?

8. Section 4.1.4:
  "binding. If the lifetime of a binding expires or it is cancelled by 
   the registration of another mobility binding ..."
  Cancellation means "deletion" here? If yes, is it so that it can happen
  only if the MN sends a BU with the N-bit not set while having multiple
  bindings for the corresponding HoA?
  What about an RFC3775 de-registration BU? Is that "cancellation"?
  And if "all associated Filters are deleted from the binding cache" then
  what about shared Filters? Do you delete a shared Filter even if its
  still valid for another Binding Cache entry (a Binding)?
  Oh, yes, and what is the lifetime of a shared Filter?

9. The first paragraph of Section 4.1.6 is overcomplicated. Does not it say
  that a CoA can be bound to multiple HoAs of the MN?
  And in the second paragraph, cannot the MN send the BU for HoA-A from B
  without AltCoA? I think it can.

10. In section 4.1.7 it says:
  "points of attachment, the mobile node MUST de-register all the other 
   bindings that belong to the same home IP address. ..."
  Does the MN need to de-register even at the CNs? Is it for keeping things
  clean and simple? I mean, is the idea that if we are at the network of a
  HoA with an interface then forget this draft for that HoA?

11. Section 4.2:
  "When MN requires transferring flow `d to the interface connected to 
   FN-B, MN sends a binding update with HoA-2 and CoA-C, together with 
   CoA-B in the Alternate care-of-address mobility option and with the 
   required filtering extensions (see section 4.1.6). ..."
  I guess it is just an example but just in case, I'd like to note that
  the BU could be sent from B without AltCoA.
  And also, in the previous paragraph the N-bit was set, and here no text
  about the N-bit. It is obviously set here too, but still.

12. Section 5:
  "... in the destination option. Binding updates without the N 
   bit set are considered as idle mobility bindings. ..."
  Just for clarification, I guess Binding != BU. Rather a Binding is an
  association represented by a Binding Cache Entry.
  Is a NOMADv6 BU without N-bit set the same as an RFC3775 BU?
  So I guess it's more like "Binding updates without the N 
  bit set create idle mobility bindings.". No?

13. So what does this N-bit indicate? Does it indicate that
  a) enable multiple bindings for the HoA in this BU ___AND___
  b) this BU contains filter description(s)/actions?

14. Section 6.1:
  "...Filters will be associated with the registered care-of address at all 
   Filtering Agents (HA,CN,MAP). A mobile node that maintains multiple 
   points of attachment may request for simultaneous mobility bindings 
   by setting the N bit in its binding Updates. ... "
  I guess the "...Filters will be associated with the registered care-of
  address at the Filtering Agent (HA, CN or MAP)".
  Also, what about a MN with a single point of attachment having multiple
  CoAs? It "may request for simultaneous mobility bindings" too.

15. A Filter can be shared between different Bindings and a Binding can be
  associated with multiple Filters.
  For me this tells that Bindings and Filters should be allowed to be
  handled independently and stored in separate "Databases". E.g. according
  to this draft if you want to change only the CoA of an existing Binding
  at the Filtering Agent then you have to send two BUs. One for creating a
  Binding with the new CoA and associated with the same Filter and another
  BU to remove the other Binding.
  BID of draft-wakikawa-mobileip-multiplecoa-05.txt might come handy ;)

16. In Section 6.1.2, does the replacing of a shared filter affect all the
  involved Bindings at the Filtering Agent and not only the one indicated
  by this BU?

17. In Section 6.1.5, how can a single BU re-new the lifetime of all the
  Bindings of a HoA?
  The lifetime belongs not only to the HoA but to a Binding and
  a Binding is identified by (HoA, CoA). Or not?

18. So Section 6.1.6 and 6.1.7 deletes only filters and does not touch Bindings?
  First sign of handling filters independently from bindings :)

19. The 1st paragraph of Section 6.1.8 is quite incomprehensible. Transferring a
  filter? FROM where TO where? Like dis-associating a filter from Binding-A and 
  associating it with Binding-B?

20. The 2nd paragraph of Section 6.1.8 is lost and is desperately looking for its
  place in the draft :). And also:
  "... by the corresponding mobility binding. In the case of 
   shared Filters, packets of matching flows will get distributed 
   between multiple points of attachment with respect to the Weight 
   value of each Filter."
  I thought a shared Filter was "shared" between multiple Bindings. Does "shared
  Filter" mean a Binding with multiple Filters. Just because I cannot see how
  the weight of a Filter can control distribution on multiple PoAs.
  Should not the weight be associated with Bindings rather than Filters in this
  case?
  Or is the semantic of "weight" implementation specific?

21. Section 6.2:
  "Should the Filtering Agent succeed in applying the Filters, then the 
   Filtering Acknowledgement indicating the index of the success MUST be 
   sent, only if `A bit is set on the Binding Update. "
  What about registration with the HA? No Filtering Ack? There is BA...
  "When a mobility binding expires or is deregistered by a mobile node  
   then all associated Filters are deleted with it. ..."
  What about shared filters?

22. Section 7:
  "once. A Filter Module may include one or more predicates. ..."
  What are predicates? Give me an example of a Filter Module with multiple
  predicates please because I don't get it from the text!

That's all for now :)

Thanks,
Gabor

_______________________________________________
Monami6 mailing list
Monami6@ietf.org
https://www1.ietf.org/mailman/listinfo/monami6