[addr-select-dt] Things to consider for wednesday meeting.

[Arifumi Matsumoto <[e-mail]>]

All,

for tomorrow's meeting, I have these things to share/discuss in mind.

1) multihome-without-nat66 activity
2) discussions/outputs from IETF77
3) remaining issues
4) next step


1) multihome-without-nat66 activity
  Mainly in order to enforce this activity of address selection
  standardization, we started some work in BBF (Broad-Band Forum)
  with some vendors and carriers. At the last BBF meeting in May,
  they agreed on the need for multi-prefix environment solution,
  and submitted a liaison document to IETF.

  The problem scope, scenarios and requirements are documented
  in this draft.
  http://tools.ietf.org/html/draft-troan-multihoming-without-nat66-00

  The liaison enforces this draft and also three proposed mechanisms,
  that is, address selection mechanism, DNS server selection, route
  selection. The latter two are discussed at mif wg.

  I hope you all to take a look at this document, and see if there
  is no conflict with your opinion regarding this activity.


2) discussions/outputs from IETF77
  In my understanding, there was no big technical discussion in Anaheim,
  but rather process/management of this design team.

  One remaining technical issue is about configuration method,
  that is what Hui proposed, XML based configuration.
  I believe it's just a matter of delivering way, and should be
  discussed rather later.


3) remaining issues
  When we look at our output document,
  http://tools.ietf.org/html/draft-chown-addr-select-considerations-03
  the remaining questions are,

  How Dynamic ?
    We did examine the target scenarios, but could not narrow down
    the answer to this question yet.

  Policy Conflicts ?
    We did some discussion on this, and I drafted a document that examines
    merging algorithm for this.
    http://tools.ietf.org/html/draft-arifumi-6man-addr-select-conflict
    But, this is rather complicated, and not perfect.
    The biggest problem, here is IMO that nobody knows the answer for
    policy merging.

  When to obtain policy ?
    Again, this issue is not concluded, I guess.

  Solution space ?
    push, pull, routing hints ?
    This is more like a matter of DHCPv6 or RA ?
    So, should be addressed after the above issues.

  Changes to RFC3484 Default Policyes
    I think, this issue is relatively fixed and documented in
    http://tools.ietf.org/html/draft-arifumi-6man-rfc3484-revise-02


4) Next step
  Everybody has his own opinion about the next step.
  At least, we know we have to answer some of the outstanding
  issues mentioned in 3).

  IMO, there is no perfect solution for the above mentioned issues.
  So, what needs to be done is to narrow down the applicability
  of the solution. The problem scope described in the 
  draft-troan-multihoming-without-nat66-00 is good starting scope
  I think.


See you on webex tomorrow. :)
  
Kindest regards,