Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK)
I also think ISP networks and enterprise networks are different from home networks. Although many requirements may looks similar, particularly considering the auto operation target, there are many preconditions are different. It could result on different solution though some components may be reusable among these networks. For ANIMA, we should surely study what homenet is working on and identify the differentia. Only after then, we can produce necessary solution with confusing the world. Best regards, Sheng From: homenet [homenet-boun...@ietf.org] on behalf of Toerless Eckert [eck...@cisco.com] Sent: 02 October 2014 22:41 To: Leddy, John Cc: Michael Behringer (mbehring); The IESG; homenet@ietf.org; Stephen Farrell; an...@ietf.org; Ted Lemon Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) Fully agreed. But does this imply that we will make most progress by blocking out a working group that is actively chartered to look at the problems in the market segments Homenet is not addressing ? If the BLOCK is meant to suggest a charter improvements for anima to better define our mutual desire to share whatever is applicable and not reinvent unnecessarily, then where is the proposed charter text change ? Cheers Toerless P.S.: Also, if i may throw in some random tidbit of technology thoughts: I love home networks (and the WG for it), because it is the best place for IPv6 to eliminate IPv4 and start creating fresh, better IP network. I have a lot of doubt that we are anywhere close to going that route especially in larger enterprises, so the address management for IPv4 in those networks is going to be a crucial requirement where i don't think homenet could (or should) be any big help. And i am not sure if i would want to hold my breath for a lot of IPv4 adress complexity reduction in IoT either. But certainly autonomic processes cold rather help than hurt in that matter. On Thu, Oct 02, 2014 at 01:50:13PM +, Leddy, John wrote: > My worry on this topic is that we are referring to ³the Home² and ³the > Enterprise². > It isn¹t that clear of a distinction. This isn¹t just a simple L2 flat > home vs. a Fortune 1000 enterprise. > > The home is getting more complex and includes work from home; IOT, home > security, hot spots, cloud services, policies, discovery etc. > Large numbers of SMB¹s look like more high end residential than they do > large enterprises. > > It would be ideal to have a solution that spans the range of size and > complexity for both residential and enterprise. > Perhaps enabling features/capabilities where required. > > Also, as far as IPV6 connectivity residential is probably ahead of > enterprises in adopting V6 centric architectures and services. > Residential doesn¹t have much of a choice, it just happens. > > 2cents, John > > On 10/2/14, 9:15 AM, "Stephen Farrell" wrote: > > > > > > >On 02/10/14 13:49, Michael Behringer (mbehring) wrote: > >> My personal goal is that what we do in ANIMA is fully compatible with > >> and ideally used in homenet. It would feel wrong to me to have an > >> infrastructure that doesn't work in a homenet. > >> > >> The security bootstrap is a good example of what we can achieve, with > >> reasonable effort. > > > >FWIW, it is not clear to me that the reasonable requirements > >for provisioning device security information (or bootstrapping > >if we wanted to call it that) are the same. > > > >In enterprise environments we see fewer larger vendors of devices. > >In the home where we additionally have a large range of vendors > >many of whom are tiny and leverage a lot of OSS and who could > >perhaps not take part in the kind of provisioning infrastructure > >that is quite reasonable for enterprises and their vendors. > > > >I do think both want to end up in the same state, where devices > >are authorised for connection to the network and where there is > >some keying material usable for security, but I'd be surprised > >if one approach to getting there worked the same way for both > >homes and enterprises. > > > >S. > > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK)
I am fully agree with Brian and Kathleen. It is well understood that the new WG would study on existing solutions and ongoing proposals to make sure it is necessary to create new mechanisms. Coordination and awareness is essential for the ANIMA group. Best regards, Sheng From: homenet [homenet-boun...@ietf.org] on behalf of Brian E Carpenter [brian.e.carpen...@gmail.com] Sent: 03 October 2014 5:47 To: Kathleen Moriarty Cc: Michael Behringer (mbehring); The IESG; homenet@ietf.org; Stephen Farrell; an...@ietf.org; Ted Lemon Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) On 03/10/2014 04:12, Kathleen Moriarty wrote: > On Thu, Oct 2, 2014 at 9:15 AM, Stephen Farrell > wrote: > >> >> On 02/10/14 13:49, Michael Behringer (mbehring) wrote: >>> My personal goal is that what we do in ANIMA is fully compatible with >>> and ideally used in homenet. It would feel wrong to me to have an >>> infrastructure that doesn't work in a homenet. >>> >>> The security bootstrap is a good example of what we can achieve, with >>> reasonable effort. >> FWIW, it is not clear to me that the reasonable requirements >> for provisioning device security information (or bootstrapping >> if we wanted to call it that) are the same. >> > > This is where we would have overlap with SACM and I2NSF. I've spoken in > Ops and Dan R has helped to try to recruit some folks to help in SACM. It > would be good to not solve this in multiple places. SACM and I2NSF are > de-conflicting what they cover. Provisioning and assessing security > information is part of those efforts already, hence my questions on the > charter as well. > >> In enterprise environments we see fewer larger vendors of devices. >> In the home where we additionally have a large range of vendors >> many of whom are tiny and leverage a lot of OSS and who could >> perhaps not take part in the kind of provisioning infrastructure >> that is quite reasonable for enterprises and their vendors. >> > > There is a push in the vendor space for this type of automation and I'm all > for it, let's just coordinate on it so we don't wind up with too many ways > to do it. Absolutely. It isn't surprising that Anima proponents are proposing specific approaches to security (or anything else), but there is an overriding sentence in the charter: "Where suitable protocols, models or methods exist, they will be preferred over creating new ones. " Clerarly that calls for coordination and awareness. Brian > > >> I do think both want to end up in the same state, where devices >> are authorised for connection to the network and where there is >> some keying material usable for security, but I'd be surprised >> if one approach to getting there worked the same way for both >> homes and enterprises. >> > > I'd like to see this discusses more, but maybe it's not in this group? > > Thanks, > Kathleen > >> S. >> >> > > > > > > ___ > 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK)
On Thu, Oct 2, 2014 at 6:50 AM, Leddy, John wrote: > My worry on this topic is that we are referring to ³the Home² and ³the > Enterprise². I have always approached homenet as a place to get standards that also work for small business. Small business is the place (IMHO) where much of an ipv6 revolution could start to happen. > It isn¹t that clear of a distinction. This isn¹t just a simple L2 flat > home vs. a Fortune 1000 enterprise. +1 > The home is getting more complex and includes work from home; IOT, home > security, hot spots, cloud services, policies, discovery etc. > Large numbers of SMB¹s look like more high end residential than they do > large enterprises. +1 > > It would be ideal to have a solution that spans the range of size and > complexity for both residential and enterprise. > Perhaps enabling features/capabilities where required. > > Also, as far as IPV6 connectivity residential is probably ahead of > enterprises in adopting V6 centric architectures and services. > Residential doesn¹t have much of a choice, it just happens. Comcast's rollout has been quite impressive. Gfiber's also. Others, not so much. > > 2cents, John > > On 10/2/14, 9:15 AM, "Stephen Farrell" wrote: > >> >> >>On 02/10/14 13:49, Michael Behringer (mbehring) wrote: >>> My personal goal is that what we do in ANIMA is fully compatible with >>> and ideally used in homenet. It would feel wrong to me to have an >>> infrastructure that doesn't work in a homenet. >>> >>> The security bootstrap is a good example of what we can achieve, with >>> reasonable effort. >> >>FWIW, it is not clear to me that the reasonable requirements >>for provisioning device security information (or bootstrapping >>if we wanted to call it that) are the same. >> >>In enterprise environments we see fewer larger vendors of devices. >>In the home where we additionally have a large range of vendors >>many of whom are tiny and leverage a lot of OSS and who could >>perhaps not take part in the kind of provisioning infrastructure >>that is quite reasonable for enterprises and their vendors. >> >>I do think both want to end up in the same state, where devices >>are authorised for connection to the network and where there is >>some keying material usable for security, but I'd be surprised >>if one approach to getting there worked the same way for both >>homes and enterprises. >> >>S. >> >>___ >>homenet mailing list >>homenet@ietf.org >>https://www.ietf.org/mailman/listinfo/homenet >> > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht https://www.bufferbloat.net/projects/make-wifi-fast ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK)
On 03/10/2014 04:12, Kathleen Moriarty wrote: > On Thu, Oct 2, 2014 at 9:15 AM, Stephen Farrell > wrote: > >> >> On 02/10/14 13:49, Michael Behringer (mbehring) wrote: >>> My personal goal is that what we do in ANIMA is fully compatible with >>> and ideally used in homenet. It would feel wrong to me to have an >>> infrastructure that doesn't work in a homenet. >>> >>> The security bootstrap is a good example of what we can achieve, with >>> reasonable effort. >> FWIW, it is not clear to me that the reasonable requirements >> for provisioning device security information (or bootstrapping >> if we wanted to call it that) are the same. >> > > This is where we would have overlap with SACM and I2NSF. I've spoken in > Ops and Dan R has helped to try to recruit some folks to help in SACM. It > would be good to not solve this in multiple places. SACM and I2NSF are > de-conflicting what they cover. Provisioning and assessing security > information is part of those efforts already, hence my questions on the > charter as well. > >> In enterprise environments we see fewer larger vendors of devices. >> In the home where we additionally have a large range of vendors >> many of whom are tiny and leverage a lot of OSS and who could >> perhaps not take part in the kind of provisioning infrastructure >> that is quite reasonable for enterprises and their vendors. >> > > There is a push in the vendor space for this type of automation and I'm all > for it, let's just coordinate on it so we don't wind up with too many ways > to do it. Absolutely. It isn't surprising that Anima proponents are proposing specific approaches to security (or anything else), but there is an overriding sentence in the charter: "Where suitable protocols, models or methods exist, they will be preferred over creating new ones. " Clerarly that calls for coordination and awareness. Brian > > >> I do think both want to end up in the same state, where devices >> are authorised for connection to the network and where there is >> some keying material usable for security, but I'd be surprised >> if one approach to getting there worked the same way for both >> homes and enterprises. >> > > I'd like to see this discusses more, but maybe it's not in this group? > > Thanks, > Kathleen > >> S. >> >> > > > > > > ___ > 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
Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK)
On 03/10/2014 01:49, Michael Behringer (mbehring) wrote:
> My personal goal is that what we do in ANIMA is fully compatible with and
> ideally used in homenet. It would feel wrong to me to have an infrastructure
> that doesn't work in a homenet.
>
> The security bootstrap is a good example of what we can achieve, with
> reasonable effort. To me, address management is a *use case* for the ANIMA
> work. Actually, we ought to be able to map *any* distributed address
> management method on top of the autonomic infrastructure that we're trying to
> create in ANIMA.
>
> We should also look to use HNCP in ANIMA, for sure (and the charter allows
> that!). But according to my intro statement, what ANIMA does would have to
> work across all architectures. We need to look more closely at this, and see
> whether 1) HNCP works as is , or 2) we can create an HNCP++ that can scale to
> SP/Ent, or 3) we need a different approach in ANIMA. As long as we do proper
> due diligence we should be able to settle on the best of those 3 options.
Exactly. We have a model for the discovery/negotiation protocol which is
certainly different from HNCP right now, but it is *not* written in stone.
However, today HNCP has a defined scope and has some limitations, so
if we converge, it would have to lose the H ("home") and gain some other
properties. I don't believe we can commit to that in the charter but of
course we can commit to investigate it.
Brian
> So, personally I think we can work out a charter that resolves those
> conflicts, step by step.
>
> Michael
>
>> -Original Message-
>> From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Ted Lemon
>> Sent: 02 October 2014 13:38
>> To: The IESG
>> Cc: an...@ietf.org
>> Subject: [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with
>> BLOCK)
>>
>> Ted Lemon has entered the following ballot position for
>> charter-ietf-anima-00-09: Block
>>
>> When responding, please keep the subject line intact and reply to all email
>> addresses included in the To and CC lines. (Feel free to cut this
>> introductory
>> paragraph, however.)
>>
>>
>>
>> The document, along with other ballot positions, can be found here:
>> http://datatracker.ietf.org/doc/charter-ietf-anima/
>>
>>
>>
>> --
>> BLOCK:
>> --
>>
>> The following exchange between Mark and Brian illustrates what I want out
>> of a BoF or External Review discussion:
>>
>> Mark:
>>
>> [...]
>>
>> In any case, It's not hard to extrapolate from here that in a year's time or
>> so,
>> if we continue on the current trajectory, homenet will have come up with
>> its own non-anima secure bootstrapping, and anima will have come up with
>> its own non-homenet distributed IPv6 prefix configuration.
>>
>> Brian:
>>
>> Which we should try to coordinate, since I see no reason in theory why
>> there can't be common underlying mechanisms between enterprise, carrier
>> and SOHO. But I don't want to hear in 2 years time that homenet is stuck
>> because anima hasn't met its milestones.
>>
>> Ted:
>>
>> Right now Homenet has a solution for the distributed configuration problem
>> with a spec and at least one WIP implementation, and is working
>> seriously on the mutual authentication problem. There may be some
>> synergy between what Homenet is trying to do and what ANIMA is trying to
>> do. If there is, it would be a big win to coordinate the two groups'
>> activities. It may also be that there is no synergy, and the efforts
>> are really effectively independent.
>>
>> Before the working group is chartered, I would like to see some clarity
>> reached about this. If there is synergy, I'd like there to be some
>> clear agreement about how to move forward so that ANIMA can achieve its
>> goals and Homenet can achieve its goals without either creating an interop
>> problem or stalling.
>>
>>
>>
>>
>> ___
>> Anima mailing list
>> an...@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
>
> ___
> 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
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
On 02/10/2014 21:20, Markus Stenberg wrote: > On 1.10.2014, at 22.44, Brian E Carpenter wrote: >> Personal comments on this: >> >> 1) One reason for not stating homenet as part of the scope is >> that we do not want to interfere with the current progress in >> homenet. Personally I think there is a lot to learn from >> homenet, but as I just said to Pierre, we are too late to affect >> homenet's choices. I will be delighted if the results can be >> applied to homenets in future, of course. > > Well, it sounds as if you plan to WGLC your negotiation protocol probably > around the time we WGLC HNCP (or sooner? who knows). I have no idea. The homenet milestones haven't been updated for 2 years, but I would expect HNCP to be much sooner than Anima. >> 2) I am also a little nervous about the IoT reference in the >> charter. We haven't yet seen a use case description that would >> apply to IoT (which has IMHO a much broader scope than home >> networks, e.g. building services.) >> >> I think the initial focus is indeed on enterprise and carrier >> networks where the OPEX pain is greatest, but we should not >> artificially limit the applicability either. > > I would just say that you aim at enterprise networks and leave it at that, > then. Considering home networks, and even more so constrained devices in the > IoT land have different management model and resources than your typical > enterprise devices. Yes, but we are (to be frank) trying to disrupt the current enterprise model and I don't want to constrain the thinking by constraining the scope. > >> There are the existing NMRG documents and there will be an >> overview document, but we are following quite specific direction >> from the ADs about this. > > Well, at least providing links to them in the charter would be probably good > idea then. As it is, it looks like ‘we have solution, here is the WG’ to me. The NMRG drafts are cited in the charter. We are trying to avoid claiming that existing solution proposals *are* the draft solutions, because that's the WG's choice to make. > >>> It is not also clear to me how well the suitability of the >>> solution has been evaluated. For implementation of some >>> autonomic, distributed algorithms, point-to-point negotiation >>> protocol such as the suggested solution is far from optimal. >>> In case of homenet, we moved from hierarchical DHCPv6 PD >>> (point-to-point hierarchy) to a distributed algorithm >>> (draft-ietf-homenet-prefix-assignment*) which was result of >>> over two years of draft updates, academic proving of >>> correctness etc. >> There is a subtle point here. The idea is to produce generic >> components that do *not* imply specific autonomic algorithms. If >> we do it correctly, those components will support either a top >> down or a distributed mechanism or even a blend of the two >> approaches. So actually the solution choices come later: we >> don’t have to decide in advance between top-down and peer-to-peer. > > A protocol (draft-jiang-config-negotiation-protocol) that is essentially > point-to-point state push/pull mechanism does not seem like natural fit for > that (+- some discovery). Well, I disagree, but that again is a job for the WG. > The scalable solutions with such protocol require hierarchies of delegation. > For example, given prefix delegation problem, the reasonable (=low number of > total message exchanges) solutions wind up subdividing the prefix > hierarchically, or alternatively with some ‘god node’(s) that perform the > allocations. It becomes harder if you have multiple sources of same resource > (=prefix) or want to be robust in case of failure. If a resource needs a hierarchy you would contstruct that on top of the negotiation protocol, not as an intrinsic feature of the protocol. >>> although it is covered >>> only by one mention in the whole charter (and the rest does >>> not seem very IoT oriented). >> So should we say in the charter that the scope is everything but >> the initial focus is enterprise and carrier? > > Or that you are developing enterprise solution and it can work for anything > with luck. No, not with luck, if we do it right. That would be like saying that DHCP(v4) was designed for campus networks but would work for home networks with luck. > >>> Looking at the solutions, from homenet developer / draft >>> writer point of view, I would welcome a general trust >>> bootstrapping framework. I am not convinced by the current >>> solution draft for that (it assumes too many components for a >>> home network case at least). A lot of the other things seem >>> somewhat enterprise-y (control plane with IPsec, own routing >>> protocol and ULAs? Not in IoT device at least, nor probably >>> in constrained homenet router), or just unsuitable, such as >>> the negotiation protocol that does not seem like a good fit >>> for distributed decision making which is usually the key >>> thing in autonomic networking. >> That means we have explai
Re: [homenet] Homenet feedback on the ANIMA charter
Markus Stenberg wrote: >> Note also that a BoF has been requested, just in case. >> Since HOMENET was mentioned during the UCAN BoF, I thought of >>double-checking with you guys. > TL;DR: Please either add homenet (and solutions already in the WG) to > the WG goals, or drop IoT too and just focus on enterprise. I see your point; if you think that much IoT will be in the home. However, there are significant areas of IoT deployment into industrial settings which have very different availability of human resources. While in the home, there is perhaps an IoT : HUMAN ration of 1000:1, which is to say that in an average home of 100 devices, there is barely 10% of a human available set them up, in industrial settings the ratio could be even worse (1:1?), but still that might leave a team of ten trained humans available to create Intents. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- pgp1lSXvkXMx6.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet feedback on the ANIMA charter
Benoit Claise wrote: > Based on the previous UCAN BoF, we are considering having an ANIMA WG: > Autonomic Networking Integrated Model and Approach > This is now a proposed charter, under consideration by the IESG. > This is your chance to provide feedback on > http://datatracker.ietf.org/wg/anima/charter/ Thanks. I have read the charter. Thank you for trying to restrict it to something focused. I think you have enough focus, but there still significant space for scope creap. Why not build this issue into the charter? Mar 2015 - recharter to refocus scope [In reading it, I was reminded of the SNMP v2 security wars of 1995. Can we have enough security present in order to configure the system to have security, was part of the underlying debate. I think we can do it now.] -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- pgpNHavVTSfM3.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
On 02/10/2014 19:26, Lorenzo Colitti wrote: > On Thu, Oct 2, 2014 at 12:16 PM, Brian E Carpenter < > brian.e.carpen...@gmail.com> wrote: > >>> This use case is precisely what draft-ietf-homenet-prefix-assignment >> does (which has roots all the way back to >> draft-arkko-homenet-prefix-assignment-00 in October 2011). So to homenet, >> this is a solved problem - with an algorithm that has been applied not just >> to HNCP, but to OSPF and ISIS. >> >> Well, we have a bug in our short description, because the intention is to >> support prefix assignment in a carrier scenario, which is different >> in many ways. > > > Really? Which ways? That was the point of draft-jiang-auto-addr-management which was briefly presented at the UCAN BOF. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK)
Fully agreed. But does this imply that we will make most progress by blocking out a working group that is actively chartered to look at the problems in the market segments Homenet is not addressing ? If the BLOCK is meant to suggest a charter improvements for anima to better define our mutual desire to share whatever is applicable and not reinvent unnecessarily, then where is the proposed charter text change ? Cheers Toerless P.S.: Also, if i may throw in some random tidbit of technology thoughts: I love home networks (and the WG for it), because it is the best place for IPv6 to eliminate IPv4 and start creating fresh, better IP network. I have a lot of doubt that we are anywhere close to going that route especially in larger enterprises, so the address management for IPv4 in those networks is going to be a crucial requirement where i don't think homenet could (or should) be any big help. And i am not sure if i would want to hold my breath for a lot of IPv4 adress complexity reduction in IoT either. But certainly autonomic processes cold rather help than hurt in that matter. On Thu, Oct 02, 2014 at 01:50:13PM +, Leddy, John wrote: > My worry on this topic is that we are referring to ³the Home² and ³the > Enterprise². > It isn¹t that clear of a distinction. This isn¹t just a simple L2 flat > home vs. a Fortune 1000 enterprise. > > The home is getting more complex and includes work from home; IOT, home > security, hot spots, cloud services, policies, discovery etc. > Large numbers of SMB¹s look like more high end residential than they do > large enterprises. > > It would be ideal to have a solution that spans the range of size and > complexity for both residential and enterprise. > Perhaps enabling features/capabilities where required. > > Also, as far as IPV6 connectivity residential is probably ahead of > enterprises in adopting V6 centric architectures and services. > Residential doesn¹t have much of a choice, it just happens. > > 2cents, John > > On 10/2/14, 9:15 AM, "Stephen Farrell" wrote: > > > > > > >On 02/10/14 13:49, Michael Behringer (mbehring) wrote: > >> My personal goal is that what we do in ANIMA is fully compatible with > >> and ideally used in homenet. It would feel wrong to me to have an > >> infrastructure that doesn't work in a homenet. > >> > >> The security bootstrap is a good example of what we can achieve, with > >> reasonable effort. > > > >FWIW, it is not clear to me that the reasonable requirements > >for provisioning device security information (or bootstrapping > >if we wanted to call it that) are the same. > > > >In enterprise environments we see fewer larger vendors of devices. > >In the home where we additionally have a large range of vendors > >many of whom are tiny and leverage a lot of OSS and who could > >perhaps not take part in the kind of provisioning infrastructure > >that is quite reasonable for enterprises and their vendors. > > > >I do think both want to end up in the same state, where devices > >are authorised for connection to the network and where there is > >some keying material usable for security, but I'd be surprised > >if one approach to getting there worked the same way for both > >homes and enterprises. > > > >S. > > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK)
My worry on this topic is that we are referring to ³the Home² and ³the Enterprise². It isn¹t that clear of a distinction. This isn¹t just a simple L2 flat home vs. a Fortune 1000 enterprise. The home is getting more complex and includes work from home; IOT, home security, hot spots, cloud services, policies, discovery etc. Large numbers of SMB¹s look like more high end residential than they do large enterprises. It would be ideal to have a solution that spans the range of size and complexity for both residential and enterprise. Perhaps enabling features/capabilities where required. Also, as far as IPV6 connectivity residential is probably ahead of enterprises in adopting V6 centric architectures and services. Residential doesn¹t have much of a choice, it just happens. 2cents, John On 10/2/14, 9:15 AM, "Stephen Farrell" wrote: > > >On 02/10/14 13:49, Michael Behringer (mbehring) wrote: >> My personal goal is that what we do in ANIMA is fully compatible with >> and ideally used in homenet. It would feel wrong to me to have an >> infrastructure that doesn't work in a homenet. >> >> The security bootstrap is a good example of what we can achieve, with >> reasonable effort. > >FWIW, it is not clear to me that the reasonable requirements >for provisioning device security information (or bootstrapping >if we wanted to call it that) are the same. > >In enterprise environments we see fewer larger vendors of devices. >In the home where we additionally have a large range of vendors >many of whom are tiny and leverage a lot of OSS and who could >perhaps not take part in the kind of provisioning infrastructure >that is quite reasonable for enterprises and their vendors. > >I do think both want to end up in the same state, where devices >are authorised for connection to the network and where there is >some keying material usable for security, but I'd be surprised >if one approach to getting there worked the same way for both >homes and enterprises. > >S. > >___ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK)
On 02/10/14 13:49, Michael Behringer (mbehring) wrote: > My personal goal is that what we do in ANIMA is fully compatible with > and ideally used in homenet. It would feel wrong to me to have an > infrastructure that doesn't work in a homenet. > > The security bootstrap is a good example of what we can achieve, with > reasonable effort. FWIW, it is not clear to me that the reasonable requirements for provisioning device security information (or bootstrapping if we wanted to call it that) are the same. In enterprise environments we see fewer larger vendors of devices. In the home where we additionally have a large range of vendors many of whom are tiny and leverage a lot of OSS and who could perhaps not take part in the kind of provisioning infrastructure that is quite reasonable for enterprises and their vendors. I do think both want to end up in the same state, where devices are authorised for connection to the network and where there is some keying material usable for security, but I'd be surprised if one approach to getting there worked the same way for both homes and enterprises. S. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
Dear Benoit, Markus, all, On 02/10/2014 14:16, Benoit Claise wrote: On 01/10/2014 18:27, Markus Stenberg wrote: Notably, adoption of a solution (discovery+negotiation protocol) before adoption of use cases seems like putting cart before the horse. Valid point. Regards, Benoit Indeed a valid point, however before concluding here, some insights might help: -OPS ADs gave guidance to focus on (applicability on) 2 use cases only. -The solution adoption milestone shall read as _applicability_ of the protocols onto the two proposed/elected use cases (the milestone should be rewritten in that sense for more clarity). -The WG aims at developing protocols reusable _among __multiple_ use cases. -An initial step of the WG should be to extract, from these multiple use cases, the boundaries / problems these protocols have to solve. HTH, best regards, Laurent. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK)
My personal goal is that what we do in ANIMA is fully compatible with and ideally used in homenet. It would feel wrong to me to have an infrastructure that doesn't work in a homenet. The security bootstrap is a good example of what we can achieve, with reasonable effort. To me, address management is a *use case* for the ANIMA work. Actually, we ought to be able to map *any* distributed address management method on top of the autonomic infrastructure that we're trying to create in ANIMA. We should also look to use HNCP in ANIMA, for sure (and the charter allows that!). But according to my intro statement, what ANIMA does would have to work across all architectures. We need to look more closely at this, and see whether 1) HNCP works as is , or 2) we can create an HNCP++ that can scale to SP/Ent, or 3) we need a different approach in ANIMA. As long as we do proper due diligence we should be able to settle on the best of those 3 options. So, personally I think we can work out a charter that resolves those conflicts, step by step. Michael > -Original Message- > From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Ted Lemon > Sent: 02 October 2014 13:38 > To: The IESG > Cc: an...@ietf.org > Subject: [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with > BLOCK) > > Ted Lemon has entered the following ballot position for > charter-ietf-anima-00-09: Block > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/charter-ietf-anima/ > > > > -- > BLOCK: > -- > > The following exchange between Mark and Brian illustrates what I want out > of a BoF or External Review discussion: > > Mark: > > [...] > > In any case, It's not hard to extrapolate from here that in a year's time or > so, > if we continue on the current trajectory, homenet will have come up with > its own non-anima secure bootstrapping, and anima will have come up with > its own non-homenet distributed IPv6 prefix configuration. > > Brian: > > Which we should try to coordinate, since I see no reason in theory why > there can't be common underlying mechanisms between enterprise, carrier > and SOHO. But I don't want to hear in 2 years time that homenet is stuck > because anima hasn't met its milestones. > > Ted: > > Right now Homenet has a solution for the distributed configuration problem > with a spec and at least one WIP implementation, and is working > seriously on the mutual authentication problem. There may be some > synergy between what Homenet is trying to do and what ANIMA is trying to > do. If there is, it would be a big win to coordinate the two groups' > activities. It may also be that there is no synergy, and the efforts > are really effectively independent. > > Before the working group is chartered, I would like to see some clarity > reached about this. If there is synergy, I'd like there to be some > clear agreement about how to move forward so that ANIMA can achieve its > goals and Homenet can achieve its goals without either creating an interop > problem or stalling. > > > > > ___ > 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
Re: [homenet] Homenet feedback on the ANIMA charter
On 01/10/2014 18:27, Markus Stenberg wrote: On 1.10.2014, at 16.20, Benoit Claise wrote: Based on the previous UCAN BoF, we are considering having an ANIMA WG: Autonomic Networking Integrated Model and Approach This is now a proposed charter, under consideration by the IESG. This is your chance to provide feedback on http://datatracker.ietf.org/wg/anima/charter/ Note also that a BoF has been requested, just in case. Since HOMENET was mentioned during the UCAN BoF, I thought of double-checking with you guys. TL;DR: Please either add homenet (and solutions already in the WG) to the WG goals, or drop IoT too and just focus on enterprise. Looking at the milestones, I am very curious about lack of requirements or architecture work before promoting solutions and even WGLCing them. As mentioned in http://www.ietf.org/mail-archive/web/anima/current/msg00246.html A few observations, to start with: 1. Autonomic Networking could be a huge explanatory field. 2. From the BoF, we heard (among other points): There is interest but focus ... focus ... focus on things that could be done quickly 3. The IESG has also been realizing that the process of problem statement/use cases/requirements/architecture/protocol takes way too long for the industry. 4. If a great architecture document to rule all autonomic functions would have been easy, it would been done already. In NMRG for example, which had plenty of time to think about it! So an architecture as a starting point is not the right approach. 5. A WG can always be re-chartered in future phases These are the reasons why Joel and I asked the BoF chairs to lead a charter discussion, focusing on only 2 use cases Notably, adoption of a solution (discovery+negotiation protocol) before adoption of use cases seems like putting cart before the horse. Valid point. Regards, Benoit It is not also clear to me how well the suitability of the solution has been evaluated. For implementation of some autonomic, distributed algorithms, point-to-point negotiation protocol such as the suggested solution is far from optimal. In case of homenet, we moved from hierarchical DHCPv6 PD (point-to-point hierarchy) to a distributed algorithm (draft-ietf-homenet-prefix-assignment*) which was result of over two years of draft updates, academic proving of correctness etc. Also, while dropping homenet from list of target things is _a_ way to solve the conflict that we already have autonomic solution for that particular problem which works (it was mentioned there before in e.g. IETF 90 not-quite-WG-forming BoF), even better would be to have a general solution that _also_ works in a homenet. Especially as IoT is just specialized type of homenet, I assume, although it is covered only by one mention in the whole charter (and the rest does not seem very IoT oriented). Looking at the solutions, from homenet developer / draft writer point of view, I would welcome a general trust bootstrapping framework. I am not convinced by the current solution draft for that (it assumes too many components for a home network case at least). A lot of the other things seem somewhat enterprise-y (control plane with IPsec, own routing protocol and ULAs? Not in IoT device at least, nor probably in constrained homenet router), or just unsuitable, such as the negotiation protocol that does not seem like a good fit for distributed decision making which is usually the key thing in autonomic networking. Cheers, -Markus . ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
On 1.10.2014, at 22.44, Brian E Carpenter wrote:
> Personal comments on this:
>
> 1) One reason for not stating homenet as part of the scope is
> that we do not want to interfere with the current progress in
> homenet. Personally I think there is a lot to learn from
> homenet, but as I just said to Pierre, we are too late to affect
> homenet's choices. I will be delighted if the results can be
> applied to homenets in future, of course.
Well, it sounds as if you plan to WGLC your negotiation protocol probably
around the time we WGLC HNCP (or sooner? who knows).
> 2) I am also a little nervous about the IoT reference in the
> charter. We haven't yet seen a use case description that would
> apply to IoT (which has IMHO a much broader scope than home
> networks, e.g. building services.)
>
> I think the initial focus is indeed on enterprise and carrier
> networks where the OPEX pain is greatest, but we should not
> artificially limit the applicability either.
I would just say that you aim at enterprise networks and leave it at that,
then. Considering home networks, and even more so constrained devices in the
IoT land have different management model and resources than your typical
enterprise devices.
> There are the existing NMRG documents and there will be an
> overview document, but we are following quite specific direction
> from the ADs about this.
Well, at least providing links to them in the charter would be probably good
idea then. As it is, it looks like ‘we have solution, here is the WG’ to me.
>> It is not also clear to me how well the suitability of the
>> solution has been evaluated. For implementation of some
>> autonomic, distributed algorithms, point-to-point negotiation
>> protocol such as the suggested solution is far from optimal.
>> In case of homenet, we moved from hierarchical DHCPv6 PD
>> (point-to-point hierarchy) to a distributed algorithm
>> (draft-ietf-homenet-prefix-assignment*) which was result of
>> over two years of draft updates, academic proving of
>> correctness etc.
> There is a subtle point here. The idea is to produce generic
> components that do *not* imply specific autonomic algorithms. If
> we do it correctly, those components will support either a top
> down or a distributed mechanism or even a blend of the two
> approaches. So actually the solution choices come later: we
> don’t have to decide in advance between top-down and peer-to-peer.
A protocol (draft-jiang-config-negotiation-protocol) that is essentially
point-to-point state push/pull mechanism does not seem like natural fit for
that (+- some discovery).
The scalable solutions with such protocol require hierarchies of delegation.
For example, given prefix delegation problem, the reasonable (=low number of
total message exchanges) solutions wind up subdividing the prefix
hierarchically, or alternatively with some ‘god node’(s) that perform the
allocations. It becomes harder if you have multiple sources of same resource
(=prefix) or want to be robust in case of failure.
>> although it is covered
>> only by one mention in the whole charter (and the rest does
>> not seem very IoT oriented).
> So should we say in the charter that the scope is everything but
> the initial focus is enterprise and carrier?
Or that you are developing enterprise solution and it can work for anything
with luck.
>> Looking at the solutions, from homenet developer / draft
>> writer point of view, I would welcome a general trust
>> bootstrapping framework. I am not convinced by the current
>> solution draft for that (it assumes too many components for a
>> home network case at least). A lot of the other things seem
>> somewhat enterprise-y (control plane with IPsec, own routing
>> protocol and ULAs? Not in IoT device at least, nor probably
>> in constrained homenet router), or just unsuitable, such as
>> the negotiation protocol that does not seem like a good fit
>> for distributed decision making which is usually the key
>> thing in autonomic networking.
> That means we have explained the negotiation idea badly. It is
> not top-down negotiation like
> draft-boucadair-network-automation-requirements. It is peer to
> peer with top-down as a special case.
Sure, it is simple ‘who is there’, ’{can I haz X, (yes|no|no but you can have
Y)}+’ protocol as far as I can read the draft anyway
(draft-jiang-config-negotiation-protocol-02)
It is not obvious to me how it would be even used to tell other all other nodes
about e.g. change in some network parameter (say, NTP server). Is it a
‘request’? Who is it sent to? How to prevent duplication of sending it to nodes
that already did receive it?
>From my point of view, a general network infra protocol needs
- discovery
- state push/pull _network wide_
HNCP does this; I am not sure how CDNP can be used for this, but I welcome
examples.
Cheers,
-Markus
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listi
