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

From: Jeffrey Haas <[email-masked]>
Date: Wed, 12 Sep 2012 09:34:10 -0400

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)

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 12 Sep 2012 15:57:14 +0200

Hello Jeff,

> should remove *only* the impacted address family from use.

... if the implementation can differentiate between IPv4 and IPv6 in the load balance. I have no intention to make such an AF-aware load-balance table a requirement. The fact that either an IPv4 or an IPv6 BFD failure can remove the link for all traffic is understood by (my) customers and acceptable.

But with such an "if an implementation's distribution algorithm can differentiate between IPv4 and IPv6 then ..." condition I can add something to the draft.

Has anyone implemented such an AF-ware load-balancer?  Just for my curiosity.

Regards, Marc

--
Marc Binderberger           <[email-masked]>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 12 Sep 2012 10:04:48 -0400

> ... if the implementation can differentiate between IPv4 and IPv6 in the load balance. I have no intention to make such an AF-aware load-balance table a requirement. The fact that either an IPv4 or…

Agreed - we don't want to force implementations to have unnecessary
abstractions.  (We're not OSI.)  But...

> But with such an "if an implementation's distribution algorithm can differentiate between IPv4 and IPv6 then ..." condition I can add something to the draft.

Exactly.  Let's be thorough.

> Has anyone implemented such an AF-ware load-balancer?  Just for my curiosity.

FWIW, this is one of those "I'm not concerned about this year's
implementations.  It's next year's that I'm worried about" issues.

Prophylactic standardization, if you will.

-- Jeff

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 12 Sep 2012 18:29:45 +0200

Hello Jeff et al.,

is the following text achieving what we want?

----snip----snap----snip----snap----
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(s).

   In case an implementation has separate load balance tables for IPv4
   and IPv6 then if both an IPv4 and IPv6 micro session exist for a
   member link an implementation MAY remove the member link from the
   load balance table only that matches the address family of the
   failing BFD session.  If for example the IPv4 micro session fails but
   the IPv6 micro session stays up then the member link MAY be removed
   from the IPv4 load balance table only but remains forwarding in the
   IPv6 load balance table.
----snip----snap----snip----snap----

And similar for the part where we describe adding a member link to the table.

Regards, Marc

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 12 Sep 2012 12:38:02 -0400

> And similar for the part where we describe adding a member link to the table.

Perfect.

-- Jeff