Re: [armd] RtgDir review: draft-ietf-armd-problem-statement-03

Thomas Narten <narten@us.ibm.com> Mon, 22 October 2012 15:47 UTC

Return-Path: <narten@us.ibm.com>
X-Original-To: armd@ietfa.amsl.com
Delivered-To: armd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A303F21F8BA5 for <armd@ietfa.amsl.com>; Mon, 22 Oct 2012 08:47:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.258
X-Spam-Level:
X-Spam-Status: No, score=-110.258 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUw4+vamekVW for <armd@ietfa.amsl.com>; Mon, 22 Oct 2012 08:47:29 -0700 (PDT)
Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id C9C6421F8931 for <armd@ietf.org>; Mon, 22 Oct 2012 08:47:28 -0700 (PDT)
Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <armd@ietf.org> from <narten@us.ibm.com>; Mon, 22 Oct 2012 11:37:16 -0400
Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 22 Oct 2012 11:36:37 -0400
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id F076C38C80A2; Mon, 22 Oct 2012 11:36:24 -0400 (EDT)
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q9MFaO6T297144; Mon, 22 Oct 2012 11:36:24 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q9MFZZcJ031491; Mon, 22 Oct 2012 11:35:38 -0400
Received: from cichlid.raleigh.ibm.com (sig-9-65-211-49.mts.ibm.com [9.65.211.49]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q9MFZWBL031140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 11:35:33 -0400
Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q9MFZOAQ007651; Mon, 22 Oct 2012 11:35:25 -0400
Message-Id: <201210221535.q9MFZOAQ007651@cichlid.raleigh.ibm.com>
To: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
In-reply-to: <7C362EEF9C7896468B36C9B79200D8350D064CAF3A@INBANSXCHMBSA1.in.alcatel-lucent.com>
References: <7C362EEF9C7896468B36C9B79200D8350D063A0AF5@INBANSXCHMBSA1.in.alcatel-lucent.com> <201208272124.q7RLOnx7015943@cichlid.raleigh.ibm.com> <7C362EEF9C7896468B36C9B79200D8350D06450BB6@INBANSXCHMBSA1.in.alcatel-lucent.com> <201208291458.q7TEwgxI011886@cichlid.raleigh.ibm.com> <7C362EEF9C7896468B36C9B79200D8350D064CAF3A@INBANSXCHMBSA1.in.alcatel-lucent.com>
Comments: In-reply-to "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> message dated "Thu, 30 Aug 2012 21:06:25 +0530."
Date: Mon, 22 Oct 2012 11:35:24 -0400
From: Thomas Narten <narten@us.ibm.com>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12102215-9360-0000-0000-00000BF1991C
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "armd@ietf.org" <armd@ietf.org>, "draft-ietf-armd-problem-statement.all@tools.ietf.org" <draft-ietf-armd-problem-statement.all@tools.ietf.org>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Subject: Re: [armd] RtgDir review: draft-ietf-armd-problem-statement-03
X-BeenThere: armd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." <armd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/armd>, <mailto:armd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/armd>
List-Post: <mailto:armd@ietf.org>
List-Help: <mailto:armd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/armd>, <mailto:armd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Oct 2012 15:47:30 -0000

Hi Manav.

Getting back to this thread...

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>; writes:

> Hi Thomas,

> > 
> > > However, the draft still says "multicast frames do not necessarily  
> > > need to be sent to all parts of the network". I could be missing  
> > > something but there still seems to be some disconnect 
> > because in  the 
> > > context of L2, multicast frames will be sent to all parts of  the 
> > > network.
> > 
> > L2 IGMP snooping may be taking place, which can then result 
> > in multicast traffic not being forwarded everywhere in the L2 
> > broadcst domain...

> Yes, that's correct. So youre suggesting that IGMP snooping will
> help reduce "ARP" traffic in case of IPv6. Do hosts send out MLD
> reports for the link local addresses that they expect to receive the
> Neighbor Discovery messages on? If they don't, then snooping will be
> of no help in reducing IPv6 ND traffic that the draft is discussing
> in that section.

Yes, IPv6 hosts do send out MLD reports for LL multicast. This was
done precisely as a concession to snooping bridges.

> > 
> > > Yes it does as long as you remove the original line that I had
> >   quoted.
> > 
> > Removing that line IMO removes something essential. It is the 
> > case that on some routers (i.e., devices at the edge of an L2 
> > boundary) do not have sufficient resources to process "a lot 
> > of ARP traffic". "a lot" is in quotes because we don't have 
> > an exact figure for what that is. This is one of the key 
> > points to come out of the ARMD effort.
> > 
> > What exactly do you object to in that sentence?

> My concern with the opening sentence of Sec 7.1 is that it
> generalizes large L2 domains and makes a sweeping statement that
> seems to suggest that all routers in large L2 domains need to
> process "a lot of " ARP traffic. This is patently incorrect. As I
> have said earlier, this issue is specific to L2 domains that see a
> lot of ARP/ND traffic and is not true in general for all large L2
> domains.

OK. I changed the sentence at issue to:

	  One pain point with large L2 broadcast domains is that the
	  routers connected to the L2 domain may need to process "a
	  lot of" ARP traffic in some cases. In particular,
	  environments where the aggregate level of ARP traffic is
	  very large may lead to a heavy ARP load on routers.

Does that work?

Thomas