Re: [v6ops] draft-templin-v6ops-pdhost a working group draft?

Brian,

Sure, but we have learnt that the matter of route injection is a thorny problem. 
If you do not topologically restrict the problem, how do you solve it? Among separate administrative domains. 

Ole

> On 15 Dec 2017, at bu20:07, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 16/12/2017 02:21, Ole Troan wrote:
>>>> Please review and send any new comments to the list, and please confirm whether
>>>> earlier comments have been addressed.
>>> 
>>> It continue to describe the entity delegating the prefix as a "Delegating Router 'D'". The IPAM (IP address Management, and by extension IP Prefix Management) software can be implemented in a computer sold as a router, but there is no requirement that it be, and it usually is not. As a matter of fact, if a router is a system that forwards messages directed to addresses other than its own, in the context of an application such as a DHCPv6 address/prefix management process, it is acting as a host, not a router.
>> 
>> Prefix delegation, more so than address assignment is coupled with the routing system.
>> Which is why RFC3633 only described a model where the delegating router and requesting router was directly connected.
> 
> They're coupled, but it isn't logically required that the entity that gives
> prefix P to a device is also the upstream router that will include P in an
> aggregate. I agree that's a natural implementation, but it isn't the only one.
> IPAMs and their generalisation in CASM, and draft-ietf-anima-prefix-management,
> are alternatives.
> 
> So I agree - it is a false assumption that the prefix delegator is
> a router, and that the delegation mechanism is RFC3633.
> 
> As far as the draft goes, I'd like to see this qualified:
> 
> "An example IPv6 PD service is the Dynamic Host
> Configuration Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633].  An
> alternative service based solely on IPv6 ND messaging has also
> been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]."
> 
> Maybe by adding that other, non-router, mechanisms may exist,
> such as proprietary IPAMs, draft-ietf-anima-prefix-management
> and draft-sun-casm-address-pool-management-yang (expired).
> 
>   Brian
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops