Subject: [armd] ARMD Status and Work Plan

From: Benson Schliesser <[email-masked]>
Date: Wed, 9 Nov 2011 22:00:14 -0600

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

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 10 Nov 2011 13:02:01 -0600

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 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 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/armd

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Fri, 11 Nov 2011 06:35:15 +0530

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Benson Schliesser (bschlies)
Sent: Friday, November 11, 2011 12:32 AM
To: [email-masked]
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 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.
> 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 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?
> 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.

---

From: Linda Dunbar <[email-masked]>
Date: Sat, 12 Nov 2011 08:19:45 +0000

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 

> Ashish Dalela (adalela)
> Sent: Thursday, November 10, 2011 7:05 PM
> To: Benson Schliesser (bschlies); [email-masked]

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Mon, 14 Nov 2011 10:17:28 +0530

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:[email-masked]] 
Sent: Saturday, November 12, 2011 1:50 PM
To: Ashish Dalela (adalela); Benson Schliesser (bschlies); [email-masked]
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