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

[Brian E Carpenter <[e-mail]>]

On 16/11/2017 21:47, Templin, Fred L wrote:
> Brian, thank you for your constructive input. Bob Hinden and others have also
> been consistently reminding me about the host/router distinction and I have
> not been ignoring them - I just didn't know how to speak to the distinction.
> But, your input gives some useful clues.
> 
> Some comments and questions below:
> 
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:[e-mail]]
>> Sent: Thursday, November 16, 2017 12:21 AM
>> To: Templin, Fred L <[e-mail]>; Van De Velde, Gunter (Nokia - BE/Antwerp)
>> <[e-mail]>; Fred Baker <[e-mail]>; [e-mail]
>> Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft?
>>
>> On 16/11/2017 18:35, Templin, Fred L wrote:
>>> Hi Gunter,
>>>
>>>> -----Original Message-----
>>>> From: v6ops [mailto:[e-mail]] On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp)
>>>> Sent: Wednesday, November 15, 2017 6:31 PM
>>>> To: Fred Baker <[e-mail]>; [e-mail]
>>>> Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft?
>>>>
>>>> Does this mean that the document desires to include all the dynamics of address assignment subscriber management when PD is
>>>> used? (i.e. subscriber vs address correlation state, identification of the subscriber/host, etc...)?
>>>
>>> This draft is about what a host can do internally when it gets a prefix delegation
>>
>> What is a bit confusing is whether, having acquired a prefix, it's going
>> to turn itself into a forwarding device. If so, surely there is nothing
>> to say except that IPv6 router requirements apply. (Which does not
>> mean it's going to run a routing protocol, since it can default route
>> everything to its upstream. But things like redirects are covered by
>> 6434(bis), which also mandates that routers must send RAs etc.)
> 
> My understanding is that routers only send RAs over advertising
> interfaces, and nodes that receive prefix delegations over an
> upstream interface would not configure that interface as an
> advertising interface. So, I agree that the delegating router
> would send RAs, but the requesting router would not send RAs
> over the upstream interface. But, perhaps you did not mean to
> imply otherwise?

No, that sounds right.

>> So I guess my point is: what is specific to a host about the discussion
>> in this document? Just to take an example, in section 4:
>>
>>    When the node receives the prefix, it can distribute the prefix to
>>    downstream networks and configure one or more addresses for itself on
>>    downstream interfaces.  The node then acts as a router on behalf of
>>    its downstream networks and configures a default route via a neighbor
>>    on an upstream interface.
>>
>> So that is describing what a *router* does, not what a host does.
> 
> Yes. Even though it may be a "host-like" device like my laptop or cellphone
> if it forwards packets that are not explicitly addressed to itself it is a router.

Exactly.
 
>> If it's *not* going to be a forwarding device, I wonder what it's
>> going to use the prefix for? Also in section 4:
>>
>>    The node could instead (or in addition) use portions of the delegated
>>    prefix for its own multi-addressing purposes.  In a first
>>    alternative, the node can assign as many addresses as it wants from
>>    the prefix to virtual interfaces.  In that case, applications running
>>    on the node can use the addresses according to the weak end system
>>    model.
>>
>> Fair enough. But it's very confusing to mix the end host behaviours
>> in with the router behaviours. And since a lot of the document is
>> about router behaviours, the document title itself is confusing.
>> (I don't agree with Lorenzo that the host/router distinction is
>> confusing in itself.)
>>
>> I suggest
>> (a) changing the title. Something like "IPv6 Prefix Delegation Models".
> 
> OK.
> 
>> (b) refactoring the contents to clearly separate the router-like
>>     and host-like behaviours.
> 
> I think I can do that.
> 
>> Also, perhaps, identify any points that would be better moved
>> into 6434bis (or 6434ter).
> 
> Can you give some examples of what could be moved there?

Not really, that would require some close study. But if you
have identified some behaviour that is in practice required,
but is not already implicitly or explicitly covered in 6343bis,
surely it belongs there?

   Brian

>> With those changes I'd be happy to see this as a WG draft.
> 
> Thanks for raising these points.
> 
> Fred
> [e-mail]
> 
>>    Brian
>