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

On 16/12/2017 10:20, Templin, Fred L wrote:
> Hi,
> 
>> -----Original Message-----
>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter
>> Sent: Friday, December 15, 2017 1:09 PM
>> To: Ole Troan <otroan@employees.org>
>> Cc: v6ops@ietf.org
>> Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft?
>>
>> On 16/12/2017 09:20, Ole Troan wrote:
>>> Brian,
>>>
>>> Sure, but we have learnt that the matter of route injection is a thorny problem.
> 
> Without question, the first-hop router has to do route injection. It also has
> to honor route lifetimes, route revocations and link-layer address changes
> of the requesting router.
> 
> I think this latter point is one that may need some further consideration.
> If the requesting router's link-layer address changes, and the requesting
> router signals the first-hop router by sending unsolicited NAs, wouldn't
> it be much easier if the first-hop router were also an active participant
> in the prefix delegation process? Because, an off-link entity would
> never see the NAs.
>  
>>> If you do not topologically restrict the problem, how do you solve it? Among separate administrative domains.
>>
>> Agreed. It can get very tricky. I just prefer the language in the draft
>> not to be restrictive.
> 
> I think the language can be relaxed, but I go back to the point about
> the first-hop router also being an active participant in the PD exchange.
> AFAICT, the first-hop router is the only node that can both inject the
> prefix and observe the on-link behavior of the requesting router.

Yes, but if it observes one of its downstream routers advertising a new prefix
in the IGP, it is not acting as a first hop router; it's simply a peer router.
At that point the downstream device is no longer acting only as a host, the
upstream device perhaps did not hand out the prefix in question, and the
network may not even be hierarchical any more.

I realise that's not the scenario you're mainly interested in, but it
seems entirely possible.

    Brian

> 
> Thanks - Fred
> 
>>    Brian
>>
>>>
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 