Ray, thank you for your comments.
On 2012/02/22, at 2:56, Ray Hunter wrote: > I have read draft-ietf-6man-addr-select-opt-03. I support this work. Thanks. > > Some comments. > > 1) I find Section 4.3 unsatisfactory. In highly-mobile devices, the status > "single-homed" and "only one upstream line" is time dependent. A > highly-mobile device may have a semi-permanent 4G uplink, and a temporary > wifi uplink dependent on the user's current location. Whether a new Address > Selection Policy table is installed or not should not depend primarily on the > order that the interfaces are brought up. If we think about the routing table, the entries related to a certain network interface will also be added and deleted, when the interface goes up and down. So, it seems to me that this issue is not too new, or strange for implementors. > 2) Suggest splitting transport of policy/configuration information from > actual use of the policy/configuration information by the end node. I'm > thinking of how routers may have multiple sources of routing information > (derived from various sources: static, RIPng, OSPFv3) but they may only > install subsets of the total known information into the single active > forwarding table using local policy configuration concepts such as > Administrative Distance and locally defined route filters. Do you suggest splitting them into different documents, or just defining the transport information format and leaving others to implementation dependent ? I do not see much value in just dividing this into two documents. It just makes it troublesome to understand this mechanism. Regarding the latter case, IMO, this mechanism is so new, and no operational experiences are gained by administrators, implementors, and so on. So, we first have to propose the expected /recommended way to use this mechanism. If you find the current specification goes beyond recommendation in some points, please tell it to me. > 3) MIF RFC 6419 identifies that address selection and interface selection > mechanisms are not consistently applied across various implementations. > > Humbly suggest adding an Informative Reference, whilst leaving solving such > selection and consistency problems to the MIF WG. agree. > 4) MIF RFC 6418 defines the concepts of "Provisioning Domain" & > "Administrative Domain" > > Humbly suggest adding an Informative Reference and adopting this terminology > in your draft. agree. > > 5) DHCPv6 RFC 3315 Section 16 states "a client .. SHOULD send the message > through the interface for which configuration information is being requested." > > Since a highly-mobile node may communicate with multiple (inconsistent) > sources of DHCPv6 information via different interfaces, depending on the > selected DHCPv6 server(s)/ relays, and which interfaces are active at any > particular time, is it worth discussing a mechanism to track the provenance > of the received "node-global information"? > > I think it may be useful to be able to tag DHCPv6 derived > policy/configuration information (such as the Address Selection Policy table) > with a provenance, so that an end node may associate the configuration/ > policy information learned from an interface/DHCPv6 server combination with a > "Provisioning Domain" and/or "Administrative Domain." > > Otherwise how do you know which Address Selection Policy table is appropriate > to install/ de-install as the active table as each interface goes up/down? > > And if the MIF WG defines a way of selecting a Provisioning Domain, the > Address Selection Policy info learned via DHCPv6 will already be > appropriately tagged (before being processed/installed into any active > node-global table). I think it is a matter of implementation, and common for several other DHCPv6 options. It may be helpful for implementors, but this document should not be the right place for this generic issue. Thanks ! > > regards, > RayH > >> Message: 5 >> Date: Wed, 15 Feb 2012 03:40:10 -0800 >> From:internet-dra...@ietf.org >> To:i-d-annou...@ietf.org >> Cc:ipv6@ietf.org >> Subject: I-D Action: draft-ietf-6man-addr-select-opt-02.txt >> Message-ID:<20120215114010.14255.26519.idtrac...@ietfa.amsl.com> >> Content-Type: text/plain; charset="utf-8" >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the IPv6 Maintenance Working Group >> of the IETF. >> >> Title : Distributing Address Selection Policy using DHCPv6 >> Author(s) : Arifumi Matsumoto >> Tomohiro Fujisaki >> Jun-ya Kato >> Tim Chown >> Filename : draft-ietf-6man-addr-select-opt-02.txt >> Pages : 10 >> Date : 2012-02-15 >> >> RFC 3484 defines default address selection mechanisms for IPv6 that >> allow nodes to select appropriate address when faced with multiple >> source and/or destination addresses to choose between. The RFC 3484 >> allowed for the future definition of methods to administratively >> configure the address selection policy information. This document >> defines a new DHCPv6 option for such configuration, allowing a site >> administrator to distribute address selection policy overriding the >> default address selection policy table, and thus control the address >> selection behavior of nodes in their site. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-6man-addr-select-opt-02.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-addr-select-opt-02.txt >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arif...@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
