Re: [armd] ARMD Status and Work Plan

[Benson Schliesser <[e-mail]>]

For those of you that might ignore my message as "too long; didn't read", here is a shorter version just listing the questions:

- Does the WG feel that our Problem Statement is complete?

- Does the WG feel that draft-karir-armd-statistics and/or draft-armd-datacenter-reference-arch should be made WG documents, incorporated in the Problem Statement, and/or need more work?

- Does the WG have interest in pursuing further work on the "survey of existing implementations" and "survey of security" milestones?

- Does the WG have interest in developing an "ARP/ND implementation" recommendation, a "how to scale" recommendation, and/or some other recommendation(s)?

- Does the WG feel that there are gaps between existing solutions and the issues described by our Problem Statement? If so, what are the requirements for a solution to the Problem Statement?

- Does the WG feel that our current Problem Statement scope should include additional topics, such as those described [in section 3 below] and/or others?

Cheers,
-Benson


On Nov 9, 2011, at 10:00 PM, Benson Schliesser wrote:

> ARMD Participants -
> 
> Linda and I have been discussing ARMD's progress against our charter and planning next steps for the WG, and we would like your feedback.  This topic will be discussed at the upcoming IETF-82 meeting in Taipei.  But even if you plan to attend in person, please provide feedback on the mailing list so that everybody can join the discussion. We apologize for the length of this message, but hope that you will take the time to respond to each of the questions below.
> 
> 1. CURRENT STATUS OF MILESTONES
> 
> According to our charter we have several milestones that are due. Specifically, we are overdue to publish a Problem Statement and we are currently due to publish documents on "statistics collection and behavior analysis", a "survey of existing implementations", and a "survey of security".
> 
> ARMD has a draft for the problem statement (draft-ietf-armd-problem-statement-00). Also, there is an individual draft discussing statistics (draft-karir-armd-statistics-01) and there is an independent draft on datacenter architecture (draft-armd-datacenter-reference-arch-00). Collectively, these drafts would seem to satisfy some of our milestones. As a WG we need to decide on next steps for these documents.
> 
> As for the other milestones that are not addressed by the existing drafts, we must decide how to proceed. There is a comment, about variations of ARP / ND implementations, in draft-karir-armd-statistics-01 which might apply to the "survey of existing implementations" milestone. But we do not have an actual survey per se, with details of the various ARP and ND implementations.  Also, to my knowledge we have no contributions that might apply to the "survey of security" milestone. The WG needs to decide how to proceed with these milestones.
> 
> - Does the WG feel that our Problem Statement is complete?
> - Does the WG feel that draft-karir-armd-statistics and/or draft-armd-datacenter-reference-arch should be made WG documents, incorporated in the Problem Statement, and/or need more work?
> - Does the WG have interest in pursuing further work on the "survey of existing implementations" and "survey of security" milestones?
> 
> 2. NEXT STEPS
> 
> In addition to the milestones mentioned above, our charter includes two milestones due in March 2012. These are to document ARMD's "recommendations" and perform a "gap analysis".
> 
> Thus far, the chairs have identified two types of recommendation that ARMD might consider making. The first is an ARP and/or ND "implementation" BCP, with recommendations for configuring or tuning ARP and/or ND. This would be much easier if we have a completed ARP/ND implementation survey. The second is an operational "how to scale" recommendation. As an illustrative example, this might suggest such options as A) replace ARP/ND with static entries, B) use L2/L3 segmentation to fit within specified constraints (smaller L2 domains, L3 to the access layer, etc), and/or C) deploy ARP/ND proxy functions in the network. This example isn't meant as a proposal, merely as an illustration for further discussion. The WG needs to decide what recommendations to make.
> 
> As an aside, I would like to point out that ARP Proxy isn't very well defined. There are multiple variations of ARP Proxy with different levels of documentation. As examples of different ARP Proxy behaviors, please see RFC1027 and draft-shah-armd-arp-reduction-02. I also recommend becoming familiar with draft-hu-trill-rbridge-esadi and draft-dunbar-trill-directory-assisted-edge, as well as OpenFlow, the NVO3 effort, etc. If the WG recommends ARP Proxy as described above, then we may need to survey existing ARP and/or ND Proxy behaviors.
> 
> Once we have documented our recommendations, the WG will perform a gap analysis, comparing our recommendations (and the existing solutions) versus the issues identified by our Problem Statement. If there are gaps, then the WG should develop a Requirements document, as input to future work. The development of a solution, based on those requirements, might happen in a different WG or by a re-chartered ARMD.
> 
> - Does the WG have interest in developing an "ARP/ND implementation" recommendation, a "how to scale" recommendation, and/or some other recommendation(s)?
> - Does the WG feel that there are gaps between existing solutions and the issues described by our Problem Statement? If so, what are the requirements for a solution to the Problem Statement?
> 
> 3. OTHER TOPICS TO CONSIDER
> 
> Considering the ARMD charter as a whole, we are not limited to discussion of ARP and ND, and we may consider other Address Resolution mechanisms that are applicable to massive datacenters.
> 
> For example, the work taking place under the name "NVO3" (possibly including NVGRE, VXLAN, etc) is an example of an overlay approach that ARMD might consider. Specifically, ARMD might consider issues related to "inter-layer" address resolution (mapping "inside" addresses to "outside" addresses). And/or ARMD might consider issues related to traditional ARP/ND address resolution within an overlay, etc. (Note that ARMD cannot develop overlay solutions, per our current charter, but it may be appropriate to investigate the operational issues associated with them.)
> 
> As an additional example, ARMD might consider operational issues and/or requirements related to address resolution in TRILL campuses, OpenFlow networks, etc. The chairs have not specifically identified these as topics for ARMD, but rather we hope the WG will decide whether they are relevant or whether our current scope is adequate.
> 
> - Does the WG feel that our current Problem Statement scope should include additional topics, such as those described above and/or others?
> 
> Thanks for taking the time to read this message. We look forward to receiving feedback from all ARMD participants. And we look forward to seeing some of you in Taipei.
> 
> Cheers,
> -Benson & Linda
> 
> _______________________________________________
> armd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/armd