RE: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ?

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Thu, 16 August 2012 03:17 UTC

Return-Path: <manav.bhatia@alcatel-lucent.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE35511E80E4 for <rtg-bfd@ietfa.amsl.com>; Wed, 15 Aug 2012 20:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.599
X-Spam-Level:
X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 FDhfGEVAxBOI for <rtg-bfd@ietfa.amsl.com>; Wed, 15 Aug 2012 20:17:27 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4092B11E80DE for <rtg-bfd@ietf.org>; Wed, 15 Aug 2012 20:17:27 -0700 (PDT)
Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q7G3HMCw007833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Aug 2012 22:17:25 -0500 (CDT)
Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7G3HIIJ024267 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Aug 2012 08:47:19 +0530
Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 16 Aug 2012 08:47:18 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: Marc Binderberger <marc@sniff.de>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, Pablo Frank <pabloisnot@gmail.com>
Date: Thu, 16 Aug 2012 08:47:41 +0530
Subject: RE: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ?
Thread-Topic: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ?
Thread-Index: Ac16OftgLYbVmwzPTOSy60qIYcFdsgBInqSg
Message-ID: <7C362EEF9C7896468B36C9B79200D8350D063A0B51@INBANSXCHMBSA1.in.alcatel-lucent.com>
References: <AC626F7A-7A9A-4395-B653-32C0F45BFA85@sniff.de>
In-Reply-To: <AC626F7A-7A9A-4395-B653-32C0F45BFA85@sniff.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: "draft-mmm-bfd-on-lags@tools.ietf.org" <draft-mmm-bfd-on-lags@tools.ietf.org>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2012 03:17:28 -0000

> 
> for draft-mmm-bfd-on-lags-05 I would like to bring a question 
> into the discussion that I have heard now several times 
> (thanks Pablo!) since the latest draft is out: why is the 
> draft so strict in enforcing the micro sessions to be either 
> IPv4 exclusive-or IPv6 ?  Why not allowing both?
> 
> 
> 2.1.  Micro BFD session address family
> 
>    Only one address family MUST be used for all micro BFD sessions
>    running on all LAG member links.  I.e. all member link micro BFD
>    sessions of a particular LAG MUST either use IPv4 or IPv6.

The above statement was written to preclude the possibility of someone using IPv4 for one member link and IPv6 for the other member link within the same LAG. Clearly, what we're saying here is that either use IPv4 or IPv6 for all micro sessions - don't do a mix and match.

The text as it appears seems to suggest that we're discouraging running both IPv4 and IPv6 for all micro sessions. The reason is scale, as already answered by Wim. If an IP interface has both IPv4 and IPv6, folks could use one address family (IPv4 or IPv6) for all micro BFD sessions and the other address family for a more sedate BFD session over that IP interface.

> As we want to cover the layer-3 aspects of the LAG and member 
> links as well, having a liveness test for both IPv4 and IPv6 
> seems reasonable. The draft states
> 
> 
> 5.  Detecting a member link failure
> 
>    When a micro BFD session goes down then this member link MUST be
>    taken out of the LAG L2 load balance table.
> 
> 
> One could rewrite this statement that when _any_ micro BFD 
> session of a member link goes down that the link MUST be 
> taken out of the load balance table. Plus the comment that in 
> case the LAG load balance table is address-family aware that 
> an implementation MAY remove the link from the load-balance 
> table only that matches the failing micro session's address 
> family (not sure if such an implementation of LAG load 
> balance tables exist at all? Otherwise we could skip this 2nd part).

I don't think there are such address family aware load balancers existing today. However, I don't see a harm in adding such a text. 

Cheers, Manav