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)
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 scope + homenet interaction + charter v15
Hi, Benoit and all, Reply in lines. On 29/10/2014 09:13, Benoit Claise wrote: >Dear all, > >[sorry for double-posting, but we need the specific feedback from the >HOMENET community] > >1. scope >I finished reading the ANIMA mailing list and, based on the feedback, >Joel, Ted, and I would like to clarify the ANIMA scope for "the set of >specific reusable infrastructure components that support autonomic >interactions between devices" (quoting the charter) > >The charter currently mentions: > The ANIMA working group will initially focus on enterprise, ISP >networks and IoT. > >Multiple tracks were discussed on the mailing list. > * keep enterprise, ISP networks and IoT > * focus on enterprise and ISP networks > * everything, but the initial focus is enterprise and carrier? > * professionally-managed networks > >It seems to us that "professionally-managed networks" is what ANIMA is >after. And it's potentially a distraction to try to segment the scope >based on enterprise, ISP, homenet, or IoT. What is IoT after all? > >OLD: The ANIMA working group will initially focus on enterprise, ISP >networks and IoT. >NEW:The ANIMA working group focuses on professionally-managed >networks. > >Does it sound about right? Yes, it is right. After we develop a generic protocol/mechanism, it is possible that other people may reuse them in other scenarios. It is out of our current focus, for sure. >2. Overlap with HOMENET >This distinction in point 1 might help regarding the potential overlap >of the solution for distributed IPv6 prefix management. >Btw, the new charter has been adapted: >OLD: A solution for distributed IPv6 prefix management within a network. >NEW: the solution for distributed IPv6 prefix management within a >large-scale network That's exactly stated in the individual draft that submitted to anima. >Also, The HOMENET collaboration has been stressed in the charter. It would be helpful. >3. Others >I believe I took care of the others changes proposed on the mailing. If >this is not the case, let me know. >At this point in time, please provide concrete change to the charter >text if some issues persist. >Charter v15 has just been posted, and you can review the detailed >changes at >https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fd >oc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=--html&sub >mit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-a >nima%2Fwithmilestones-00-15.txt > > >4. Security Advisor. >I have requested one for ANIMA to the security ADs. It would be great. Many thanks. Best regards, Sheng >Regards, Benoit > >___ >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] ANIMA scope + homenet interaction + charter v15
>I would personally rather drop prefix management. At least, the current >proposed solution is DHCPv6 PD plus lot of marketing plus one extra thing >(role) minus tons of existing functionality. I would rather stick the role >into PD, >than reinvent the protocol. DHCPv6 PD has only solve the prefix request and assign process based on the preconditions: a) the requesting router knows the prefix length it should request; b) the requesting router knows what device to send the request; c) The requested device have enough resource for the request. However, human configuration or human intervention are needed to meet these preconditions. The current proposed solution focuses on to autonomic processes to solve these preconditions. Best regards, Sheng >If there is not something more novel there (that is, not hierarchical PD in >disguise), I do not see the point. > >> Also, The HOMENET collaboration has been stressed in the charter. >> >> 3. Others >> I believe I took care of the others changes proposed on the mailing. If this >> is >not the case, let me know. >> At this point in time, please provide concrete change to the charter text if >some issues persist. >> Charter v15 has just been posted, and you can review the detailed changes >at >https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fd >oc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=--html&sub >mit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-a >nima%2Fwithmilestones-00-15.txt > >I think it is mostly fine, although the use of term ‘autonomous’ for >essentially (on high level) managed devices that perform some low-level >autonomic functions sounds still strange to me. I guess I could live with it >though. > >Cheers, > >-Markus > > >___ >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] ANIMA scope + homenet interaction + charter v15
>-Original Message- >From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Ted Lemon >Sent: Friday, October 31, 2014 6:32 PM >To: Sheng Jiang >Cc: Benoit Claise; homenet@ietf.org; Markus Stenberg; an...@ietf.org >Subject: Re: [Anima] [homenet] ANIMA scope + homenet interaction + >charter v15 > >On Oct 31, 2014, at 1:53 AM, Sheng Jiang wrote: >> a) the requesting router knows the prefix length it should request; > >It should always request a single /64. Are you talking about assigning prefix for homenet? I thought we were talking about auto prefix management in a large network, which is ANIMA use case. Sheng >___ >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] ANIMA scope + homenet interaction + charter v15
Hi, Ted, I now understand your point. Your arguments do make sense. The current general mechanism are too general to work for the use case of hierarchical prefix delegation. But if we add hierarchical topology and no bypass requests as constraint conditions, we may be able to make hierarchical prefix delegation work. Best regards, Sheng From: Ted Lemon [mel...@fugue.com] Sent: 31 October 2014 22:34 To: Sheng Jiang Cc: Benoit Claise; homenet@ietf.org; Markus Stenberg; an...@ietf.org Subject: Re: [Anima] [homenet] ANIMA scope + homenet interaction + charter v15 On Oct 31, 2014, at 8:54 AM, Sheng Jiang wrote: > Are you talking about assigning prefix for homenet? I thought we were talking > about auto prefix management in a large network, which is ANIMA use case. In either case, it's important to make the distinction between prefix assignment and prefix delegation. In an autonomous network, I don't think it's practical to do hierarchical prefix delegation. That has the unfortunate consequence that there can't be any routing aggregation. The delegating router can of course _try_ to keep the topology clean, but routing has to work even if it fails. That being the case, every delegation _request_ should be for a /64, because every delegation request should be a request for a /64 to configure on an interface of a router. Whether or not aggregation occurs is up to whichever device is the delegating router. Having a distributed delegation framework is probably a good idea, but a hierarchical distribution won't work, so the idea that a router could request prefixes to be delegated and then re-delegate some of those prefixes is, IMHO, not going to work. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
Hi, Ted, I agree with you that an autonomic network must be able to support incremental grow. So the network topology would not always remain hierarchical. Therefore, hierarchical delegation does not work in an autonomous network. Also, it is difficult to remain routing aggregation based on hierarchical topology in an autonomous network. But getting back to where we start the discussion, I still think in a large network, the requesting prefix may not always be /64. It is reasonable to have multiple distributed sources for prefix assignment, in a large network. Autonomic network use case also includes to manage the prefix resource among these prefix pools. Some resource may be transferred from one pool to another with negotiation supporting. In such scenario, the requesting device may not know the requesting prefix length, unless it has already negotiated with a certain requested device. My guess is we should separate the abovementioned scenario from normal /64 prefix assignment. Also Brian's scenario that a devices may require multiple /64 is also common. Best regards, Sheng From: Ted Lemon [mel...@fugue.com] Sent: 31 October 2014 23:47 To: Sheng Jiang Cc: Benoit Claise; homenet@ietf.org; Markus Stenberg; an...@ietf.org Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15 On Oct 31, 2014, at 10:55 AM, Sheng Jiang wrote: > The current general mechanism are too general to work for the use case of > hierarchical prefix delegation. But if we add hierarchical topology and no > bypass requests as constraint conditions, we may be able to make hierarchical > prefix delegation work. No, that is not the point I am making. The point I am making is that hierarchical delegation simply won't work, no matter what mechanism you put in place to do it, because the network has to be able to grow incrementally. With that as a base assumption, you cannot predict where the network will grow, so you don't know how to construct the hierarchy. Once the hierarchy is constructed, you would have to renumber on a regular basis to make hierarchical delegation work. I think it is preferable to simply allow for a complete routing table, and then try as best as possible to make routing hierarchical, without demanding perfection. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
A very large carrier is normally organizing its network into multiple ASes. It is naturely aggregated when an AS announced its prefix(es). Complete routing table with in an AS should not be a scaling problem. Because it is not possible for all routers have complete routing table, so the path within an AS may not always be perfect. But reachability would not be in any doubts. Sheng From: homenet [homenet-boun...@ietf.org] on behalf of Brian E Carpenter [brian.e.carpen...@gmail.com] Sent: 01 November 2014 8:19 To: Ralph Droms Cc: Markus Stenberg; Ted Lemon; Benoit Claise; homenet@ietf.org; an...@ietf.org; Sheng Jiang Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15 On 01/11/2014 12:28, Ralph Droms wrote: > > > >> On Oct 31, 2014, at 4:04 PM, Ted Lemon wrote: >> >>> On Oct 31, 2014, at 3:25 PM, Brian E Carpenter >>> wrote: >>> Well yes. That's exactly why in autonomic management of prefixes, >>> we need peer to peer negotiation, as in "I need 3 /64s that I >>> don't have, do you have any spare ones for me?" Maybe it's >>> badly explained but that is the whole point of our use case. >> Sure, you can approach it as a sort of flood fill algorithm that tries to >> optimize for route aggregation, but copes if that optimization doesn't pan >> out. >> > Do we have use cases in which the number of links is so large that > unaggregated routing tables will be a problem? Not that I'm aware of. In the case of a carrier, the prefix will be aggregated anyway when it is announced to peer carriers, and possibly aggregated regionally anyway if it's a very large carrier. Of course, there will be a scaling limit and that should be a consideration in the design. Brian ___ 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] ANIMA scope + homenet interaction + charter v15
Hi, Ted, Yes, we mixed different concepts. Actually, this was a very good discussion. It gives a very good hints to improve the autonomic prefix management draft. Now, we know prefix management should be at least categoried into prefix assignment and prefix distribution. :) Thanks for your participation in this discussion. Best regards, Sheng From: homenet [homenet-boun...@ietf.org] on behalf of Ted Lemon [mel...@fugue.com] Sent: 01 November 2014 20:31 To: Sheng Jiang Cc: Benoit Claise; homenet@ietf.org; Markus Stenberg; an...@ietf.org Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15 On Nov 1, 2014, at 7:41 AM, Sheng Jiang wrote: > But getting back to where we start the discussion, I still think in a large > network, the requesting prefix may not always be /64. It is reasonable to > have multiple distributed sources for prefix assignment, in a large network. > Autonomic network use case also includes to manage the prefix resource among > these prefix pools. It's certainly true that if you have multiple repositories for prefixes to assign, those repositories will need to transfer more than one /64 at a time, and it will be desirable to maintain pools of prefixes on these repositories that are aggregated into larger prefixes. But prefix _assignment_ will always be a single /64. I suspect that this is the core of our miscommunication--if you talk about prefix assignment and prefix distribution as if they are the same thing, which is what we started out doing, then it's easy to imagine that we are talking about the same thing when really one of is talking about assignment (me) and the other about distribution (you). Sorry about that. ___ 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
