Re: [armd] ARMD Status and Work Plan

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

Linda,

Location resolution isn't necessarily an overlay. Portland/MOOSE do it
without overlay by changing L2 headers. In these approaches, address
resolution and location resolution are identical. That's an advantage,
IMO.

Thanks,
Ashish

-----Original Message-----
From: Linda Dunbar [mailto:[e-mail]] 
Sent: Saturday, November 12, 2011 1:50 PM
To: Ashish Dalela (adalela); Benson Schliesser (bschlies); [e-mail]
Subject: RE: [armd] ARMD Status and Work Plan

Ashish, 

You are absolutely right that the "Address Resolution" in data center
not only involves IP <-> MAC type of Address resolution (ARP/ND) but
also has Host <-> Overlay Edge type of resolution due to the trend of
Overlay network in data centers. 
The question is 
- should the "host (MAC or IP) <-> Overlay Edge" address resolution be a
Section in the " draft-ietf-armd-problem-statement", or a separate
draft? Any volunteer to write the draft? 

At this stage of ARMD, we don't really need to address if solution could
be "combined/coupled" or kept separate (because ARMD is still in
OpArea).   

As for "snoop ARP/ND", "conversation learning", etc, I've seen them
being used today to reduce the ARP/ND processing required on boundary
routers. Therefore, they should be included in the ARMD Best Common
Practice Recommendation draft. 

Linda 


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
Of
> Ashish Dalela (adalela)
> Sent: Thursday, November 10, 2011 7:05 PM
> To: Benson Schliesser (bschlies); [e-mail]
> Subject: Re: [armd] ARMD Status and Work Plan
> 
> 
> 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
> _______________________________________________
> armd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/armd