On 30/03/2017 11:14, Mark Townsley (townsley) wrote:
>
>> On Mar 29, 2017, at 10:04 AM, Michael Richardson <mcr+i...@sandelman.ca>
>> wrote:
>>
>>
>> This discussion started in a private thread, so I'll try to bring people
>> up-to-date by repeating and moving around text.
>>
>> The ANIMA GRASP reference problem Autonomic Service Agent (ASA), is
>> to do distributed prefix allocation. This is very much in the space of
>> *coordinated* address management.
>>
>> (My take, BTW, is that CASM should be considered the first spin-off WG
>> From ANIMA...)
>>
>> Mark and Brian discussed how HNCP does prefix distribution within Homenet.
>
> I was really pointing out that RFC 7695 could be used independent of HNCP.
>
> HNCP is just one protocol that uses the RFC 7695 distributed prefix
> assignment algorithm (which actually began as extensions to OSPF before HNCP
> even existed).
True. And I don't see any reason why a CASM system including autonomic service
agents shouldn't be used to supply prefixes for use by an RFC7695
implementation.
So the various tools can fit together.
Brian
>
> - Mark
>
>>
>> Brian then suggests:
>>
>> brian> But if the CE includes a little autonomic service agent (ASA) which
>> brian> is in the ISP's security domain (not the SOHO domain), it can act for
>> brian> HNCP to solicit address space from the ISP. That's the southern side
>> brian> of the CASM model and the northern side of HNCP.
>>
>> I asked a simple question: don't we have DHCPv6 for this?
>>
>> I also then asked:
>>
>>> a) the CPE device is now part of the ISP's ACP.
>>> That's okay if the CPE device is owned by the ISP and/or the CPE device
>>> includes some kind of trusted computation environment.
>>> {But a CPE owned by the ISP, might not be trusted by the home owner,
>>> so another router in between would be needed,
>>
>> Brian answered:
>>> Really? Why not?
>>
>> I don't think that the ISP can trust to have code controlled by end users
>> running in their ACP domain.
>>
>> I also think that many end-users will be quite reasonably upset that their
>> ISPs can snoop on their internal traffic. This may in fact violate many
>> work-at-home agreements; which is often the case of why you see multiple
>> routers/firewalls in documents like
>> https://datatracker.ietf.org/doc/html/draft-baker-fun-multi-router.
>>
>> (Fred had more interesting diagrams in presentations, which I could dig up)
>>
>>>> b) DHCPv6 PD is already the protocol that solves prefix allocation across
>>>> trust boundaries.
>>
>>> Indeed. That's why we have "PD supported" as a Boolean property of the
>>> PrefixManager objective. There's no intention to undermine PD.
>>
>> Why do I need to run a protocol in order to find if I can run a protocol,
>> when DHCP has the same mechanism already. And use of DHCPv6 itself is well
>> defined in cable and DSL connections already.
>>
>>>> I would think that the ISP's DSLAM/BMS/CMTS would have an ASA that deals
>>>> with
>>>> prefixes. It would speak DHCPv6-PD to the south, and GRASP/ASA to the
>>>> north.
>>
>>> Yes, the DSLAM is definitely a good place to put one.
>>
>>
>>>> North of the ISP's device would be the ISP's (distributed) IPAM.
>>>> GRASP/ASA-Prefix would be the protocol between.
>>
>>> Anyway, my point is that these approaches (ANIMA, HNCP and PD) are
>>> complementary not competitors.
>>
>> I don't see you saying that.
>>
>> I see ou trying to extend two internal mechanisms (ANIMA in the ISP, and HNCP
>> in the home) such that they interact directly, rather than using PD. You
>> say this right here:
>>
>> brian> But if the CE includes a little autonomic service agent (ASA) which
>>
>>
>> --
>> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
>>
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>
> _______________________________________________
> Anima mailing list
> an...@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
