Re: [armd] ARMD Status and Work Plan

["Ashish Dalela (adalela)" <[e-mail]>]

In the interest of kick-starting a discussion, below are some random
thoughts.

First, address resolution is comprised of two problems - 
- at the level of ARP/ND and 
- at the level of Location/Address binding

These two problems can be combined/coupled or kept separate. It might be
good to say that there are two types "resolving" and do we want to
combine or keep them separate. Combining has backward compatibility
issues, but it might be worth determining if the benefits warrant that
disruption.

Second, there are questions about architecture of address resolution - 
- distributed at access
- distributed all over (e.g. with a hash)
- centralized at some points (load-balanced)

There can be a discussion of various models, their pros-and-cons, with a
recommendation.

Third, how does the address resolver get populated?
- snoop ARP/ND 
- rely on conversation learning
- use protocols to update addresses

This gets into the design of the mechanism, and has implications for
convergence/reliability.

Fourth, there are issues of security and manageability
- can anyone resolve anyone (security)?
- how do I know who is resolving whom (which are active flows)?
- is address resolution a self-sustaining system, or operator controls
it (policy)?

Rather than start with a problem statement, it might be good to start
with questions, then determine if some of them are problems, then decide
if we really want to solve these problems (some problems are best left
untouched ;-)).

Thanks, Ashish


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Benson Schliesser (bschlies)
Sent: Friday, November 11, 2011 12:32 AM
To: [e-mail]
Subject: Re: [armd] ARMD Status and Work Plan

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

_______________________________________________
armd mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/armd