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

Jeffrey Haas <jhaas@pfrc.org> Wed, 12 September 2012 13:34 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 E063F21F8564 for <rtg-bfd@ietfa.amsl.com>; Wed, 12 Sep 2012 06:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.19
X-Spam-Level:
X-Spam-Status: No, score=-102.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 EjGdhebCG+3H for <rtg-bfd@ietfa.amsl.com>; Wed, 12 Sep 2012 06:34:11 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7426521F855F for <rtg-bfd@ietf.org>; Wed, 12 Sep 2012 06:34:11 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 939C0C386; Wed, 12 Sep 2012 09:34:10 -0400 (EDT)
Date: Wed, 12 Sep 2012 09:34:10 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Marc Binderberger <marc@sniff.de>
Subject: Re: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ?
Message-ID: <20120912133410.GB25037@pfrc>
References: <AC626F7A-7A9A-4395-B653-32C0F45BFA85@sniff.de> <7C362EEF9C7896468B36C9B79200D8350D063A0B51@INBANSXCHMBSA1.in.alcatel-lucent.com> <CAGEmCZxJtms7puJW6W4J13vr7Y1dajpuGt0cZQXivGFFWEafOw@mail.gmail.com> <7C362EEF9C7896468B36C9B79200D8350D063A0D7A@INBANSXCHMBSA1.in.alcatel-lucent.com> <0D1B9ACE-889A-4090-88CC-BA7E3652117F@sniff.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <0D1B9ACE-889A-4090-88CC-BA7E3652117F@sniff.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: draft-mmm-bfd-on-lags@tools.ietf.org, rtg-bfd@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: Wed, 12 Sep 2012 13:34:12 -0000

Just to prod this particular topic a bit:

On Thu, Aug 16, 2012 at 05:20:04PM +0200, Marc Binderberger wrote:
> Hello Manav, Pablo et al.,
> 
> I think we will work on an update with a better wording. What we have now can be misunderstood. I agree with Manav's comment that what we really want to enforce is:
> 
> when you run a micro session for a particular address family on one member link then you must run micro sessions for this address family on all member links (of the LAG).
> 
> 
> > Do you have some scenarios in mind?
> 
> I have a (big) customer in mind who was just asking for this :-)
> The reason is that BFD micro sessions do cover layer-3 aspects as well and the customer thinks we should cover both, IPv4 and IPv6 code path. Sounds reasonable.

Let us presume that we arrive at wording that effectively says "if you run
micro sessions in a given address family, do it on all links".

Presume also you run both IPv4 and IPv6.

The implication is that if IPv4 drops, but IPv6 stays up, that the LMM
should remove *only* the impacted address family from use.

However, we're also suggesting that a scenario where one runs only one
address family across the LAG is sufficient to impact all layer 3 traffic
for the LMM.  Harkening back to the IS-IS observations, I'm fine with this.

What this means is we need language that says all of this.

-- Jeff (speaking as an individual contributor)