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

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 16 Jun 2010 11:15:21 +0900

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,

---

From: Tim Chown <[email-masked]>
Date: Wed, 16 Jun 2010 15:11:18 +0100

>  the remaining questions are,

For info this one is draft-ietf-6man-addr-select-considerations-00, expired in April.

Tim

---

From: Tim Chown <[email-masked]>
Date: Wed, 16 Jun 2010 15:21:38 +0100

The huitema drafts I was thinking of are:

draft-huitema-multi6-addr-selection-00
draft-huitema-multi6-experiment-00

Maybe worth a read with respect to the multihoming text (which I support working on)

Tim

---

From: Tim Chown <[email-masked]>
Date: Thu, 17 Jun 2010 15:41:36 +0100

> 2) discussions/outputs from IETF77

Hi.

First, many thanks for rallying us and organising the call and Tony for the Webex hosting.

Here's my rough notes on what we discussed.  Please do correct/add anything I misunderstood, left out or noted down incorrectly.

1.   multihome-without-nat66 activity

We discussed draft-troan-multihoming-without-nat66-00 and agreed that the draft was relevant to our work and worth reading more closely and contributing to.  There did not seem to be any conflicts.   It may help focus some of our own discussions.

Tim circulated a pointer to 
	draft-huitema-multi6-addr-selection-00
	draft-huitema-multi6-experiment-00
which appear to be older takes on a similar theme.

Tony mentioned his desire to revive his work on ICMPv6 messaging to indicate selection problems/hints.   I haven't reread Christian's drafts yet but I recall a similar idea is mentioned in one of those.

2.  Discussion/outputs from IETF77

I think we agreed it's too early to discuss the specifics of configuration syntax.

3.  Remaining issues

The latest draft from the DT discussion is draft-ietf-6man-addr-select-considerations-00, which just expired and should be refreshed.

How dynamic?  I think we agreed that cases where policy changes might be very dynamic would be where either hosts are moving within a site frequently, or where the site is using very dynamic traffic engineering that may affect external path selections.    For the typical enterprise this would be unusual, as it would be for a typical SOHO network.

We felt that in the general case when a device fetches/receives new address configuration information it should also fetch/receive the policy information.

We didn't discuss policy distribution in non-DHCPv6 networks, though we did say such networks are probably not 'managed' and thus there's less likely to be configured policy to distribute.

On policy conflicts we agreed this was of course a hard problem.   It's also one that's generic to other DHCP-served configuration information not just address selection policy (if we work on that as a solution), and also to conflicts between configuration information received in other ways (perhaps by RFC5006-bis or even manual configuration).   There are also per-interface conflicts, e.g. from a laptop in a 'coffee shop' wireless running a VPN connection to a home site; policy may then apply per prefix in use.   

We did say that the delivery of the configuration information is a 'network' problem while the conflict resolution is a 'host' one, so if that claim is reasonable we could begin to work on these independently (and policy conflict is something 'bigger picture' to include mif WG etc).

The question of legacy hosts was raised.   There was some agreement that this is not an overly important issue.

We seemed to agree that pushing out RFC3484-bis asap was good given many implementors have already applied many of the recommendations that have been made.   See draft-arifumi-6man-rfc3484-revise-02.

4.  Next steps

We talked about the need to get something out (policy distribution method for an enterprise for example) against the likely IETF requirement to consider enough corner cases to make the work valid.   We felt that by abstracting the distribution method to the network and stating the conflict resolution is a per-host issue, we can make progress on at least a DHCPv6-based distribution solution (given our consensus on 'how dynamic' above).

We agreed to try to hold another telecon in 2 weeks or so after discussion on the list.    The list discussion could usefully work on an applicability statement.

We would try to find out the Apple position on address selection implementation for Mac OSX.    It does appear from NANOG that Apple are to implement DHCPv6 'soon'.

Tim