Subject: [armd] ARMD BOF agenda and details

From: Linda Dunbar <[email-masked]>
Date: Sun, 07 Nov 2010 21:47:51 +0800

ARMD BOF will be Friday Nov 12, 9am~11:30am at Garden Ballroom. 

Detailed agenda has been posted on the wiki website. 

http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/ARMD%20-%20BOF
%20agenda%20at%2079th%20IETF.ppt

Looking forward to seeing most of you in Beijing. 

Linda Dunbar

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 8 Nov 2010 23:28:04 -0800

Agenda and some of the meeting material is posted at the usual place:

https://datatracker.ietf.org/meeting/79/materials.html

--julien

From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Sunday, November 07, 2010 6:48 AM
To: [email-masked]
Cc: 'Jari Arkko'
Subject: [armd] ARMD BOF agenda and details

http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/ARMD%20-%20BOF%20agenda%20at%2079th%20IETF.ppt

Linda Dunbar

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 11 Nov 2010 16:38:04 -0800

Final Agenda and all meeting material is uploaded:

--julien

From: [email-masked] [mailto:[email-masked]] On Behalf Of Laganier, Julien
Sent: Tuesday, November 09, 2010 12:28 AM
To: Linda Dunbar; [email-masked]
Cc: 'Jari Arkko'
Subject: Re: [armd] ARMD BOF agenda and details

--julien

Linda Dunbar

---

From: xuxiaohu 41208 <[email-masked]>
Date: Fri, 12 Nov 2010 10:31:06 +0800

1. Does moose deal with the ARP scalability issue, or MAC table scalability issue?

2. Can MOOSE support multi-homing function? for example, if MAC-NAT-1 forwarding initial packets fails, MAC-NAT-2 takes over the forwarding and translation servive, which node will be responsible for updating the previous ARP cache which contains the MAC translated by MAC-NAT-1?

Xiaohu Xu
Huawei Technologies Co.,Ltd

---

From: Malcolm Scott <[email-masked]>
Date: Fri, 12 Nov 2010 02:36:39 +0000 (GMT)

> 1. Does moose deal with the ARP scalability issue, or MAC table 

MAC table scalability, primarily.  I'm thinking about ways to bring in ARP 
scalability; I think moose is a good starting point for this.

We could at least use draft-shah-armd-arp-reduction in combination with 
moose.

> 2. Can MOOSE support multi-homing function? for example, if MAC-NAT-1 
> forwarding initial packets fails, MAC-NAT-2 takes over the forwarding and 
> translation servive, which node will be responsible for updating the 
> previous ARP cache which contains the MAC translated by MAC-NAT-1?

Current implementation does not support this, but I am planning on working 
on this.  I envisage an election protocol to determine which moose switch is 
the primary home switch for each host, but don't yet have details.

Malcolm

-- 
Malcolm Scott
University of Cambridge Computer Laboratory

---

From: xuxiaohu 41208 <[email-masked]>
Date: Fri, 12 Nov 2010 10:57:44 +0800

----- 原邮件 -----
发件人: Malcolm Scott <[email-masked]>
日期: 星期五, 十一月 12日, 2010 上午10:36
主题: Re: [armd] Two comments on MOOSE// 回复 :Re:  ARMD BOF agenda and details
收件人: xuxiaohu 41208 <[email-masked]>
抄送: "Laganier, Julien" <[email-masked]>, Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>

> the primary home switch for each host, but don't yet have details.

Maybe multiple MAC-NAT devices of a given redundancy group could share a single Virtual Switch ID. 

By the way, I suggest to remove the port ID part in the translated MAC address which makes the mechanism much more complex, especially when considering multi-homing scenario. IMHO, it is acceptable that the MAC forwarding table on core switches is sized to the number of edge switches(i.e., MAC-NAT devices).

Xiaohu

---

From: Malcolm Scott <[email-masked]>
Date: Fri, 12 Nov 2010 03:08:01 +0000 (GMT)

At 10:57 today, xuxiaohu 41208 wrote:

> By the way, I suggest to remove the port ID part in the translated MAC 
> address which makes the mechanism much more complex, especially when 
> considering multi-homing scenario. IMHO, it is acceptable that the MAC 
> forwarding table on core switches is sized to the number of edge 
> switches(i.e., MAC-NAT devices).

There was a slide on this which I had to omit due to time.  The part of the 
NAT MAC address beyond the switch ID can be implementation-dependent; maybe 
some switches will want to put a port ID in there, or maybe it should just 
be a sequential ID, or even something like a hash of the host's real MAC 
address.

Remote switches MUST NOT assume any structure to the switch-local portion.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Nov 2010 19:51:06 -0500

First, an apology.  For personal reasons I had to miss the BoF, so there 
may be context which makes the following comment irrelevant.

Assuming I have followed the discussion properly, allow me to level up.
There appear to be at least two problems. (I have seen renditions that 
make it three, but two suffices.)

One problem is how to create, manage, and use the mapping information 
between IP address and MAC address.  This ARP resolution problem can be 
addressed from many angles, and there are a number of proposals.  (In 
addition to the several drafts, there are also the ideas of using Trill, 
802.1aq, or SCSP to carry the information around.)
This is a problem that the IETF can reasoanbly address.  It seems to me 
that we probably should address it.

The second problem is how to handle the forwarding of packets based on 
their MAC address.  That is what the MAC NAT proposal addresses. 
Potentially, such a proposal could reduce the need for the first item, 
but it is in a very separate space.
In particular, defining how Ethernet Switches work, and how Ethernet MAC 
addresses are used, seems to me to be an IEEE matter.  We, the IETF, 
justifiably get upset if other standards bodies start telling us how IP 
addresses should behave.  It seems appropriate for us to stay out of 
degining matters which fall squarely and exclusively in the purview of 
other standards bodies.

Yours,
Joel M. Halpern

On 11/11/2010 10:08 PM, Malcolm Scott wrote:
> There was a slide on this which I had to omit due to time. The part of
> the NAT MAC address beyond the switch ID can be
> implementation-dependent; maybe some switches will want to put a port ID
> in there, or maybe it should just be a sequential ID, or even something
> like a hash of the host's real MAC address.
>

---

From: Kathy McEwen <[email-masked]>
Date: Fri, 12 Nov 2010 20:22:46 -0600

Hmmm it would be very nice to believe networks are autonomous and independent islands too...  Fortunately they are not.... Being mobile and having wings to fly makes our generation unique in time thus far ... Addressing is complex for that reason. 

Sent from my iPhone

On Nov 12, 2010, at 6:51 PM, "Joel M. Halpern" <[email-masked]> wrote:

> First, an apology.  For personal reasons I had to miss the BoF, so there may be context which makes the following comment irrelevant.
> 
> There appear to be at least two problems. (I have seen renditions that make it three, but two suffices.)
> 
> One problem is how to create, manage, and use the mapping information between IP address and MAC address.  This ARP resolution problem can be addressed from many angles, and there are a number of proposals.  (In addition to the several drafts, there are also the ideas of using Trill, 802.1aq, or SCSP to carry the information around.)
> This is a problem that the IETF can reasoanbly address.  It seems to me that we probably should address it.
> 
> The second problem is how to handle the forwarding of packets based on their MAC address.  That is what the MAC NAT proposal addresses. Potentially, such a proposal could reduce the need for the first item, but it is in a very separate space.
> In particular, defining how Ethernet Switches work, and how Ethernet MAC addresses are used, seems to me to be an IEEE matter.  We, the IETF, justifiably get upset if other standards bodies start telling us how IP addresses should behave.  It seems appropriate for us to stay out of degining matters which fall squarely and exclusively in the purview of other standards bodies.
> 
> Yours,
> Joel M. Halpern
> 
> _______________________________________________
> armd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/armd