Subject: BFD on LAG - one AF session per member link

From: Jeffrey Haas <[email-masked]>
Date: Sun, 11 Mar 2012 18:01:24 -0400

[Speaking as an individual contributor.]
I'm proxying a message from a Juniper developer.

In draft-mmm-bfd-on-lags-03, we have:

: 2.1. Micro BFD async session address family
: 
: 
:    Only one address family MUST be used for all micro BFD async sessions
:    running on all LAG member links. i.e. all member link async BFD
:    sessions MUST either use IPv4 or IPv6.

The MUST in question here seems a little too aggressive.  However, that view
may have been an artifact of some of the original work where we're trying to
test closer to layer 2 rather than validating layer 3 forwarding over member
links.

To that end, I'd suggest this be made a SHOULD.  However, I'm also aware
that text to accommodate this SHOULD will also need to be worked into
updated draft text talking about inputs on the IP traffic balancer rather
than impacts on LACP.  To that end, I request you keep this thought in mind
when we get around to bumping the next rev of the draft.

-- Jeff

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 11 Mar 2012 23:44:51 +0100

Hello Jeff,

maybe the wording is not the most elegant piece of English text ;-) but what it tries to say is: for one given LAG you run either all micro sessions as IPv4 exclusive-or all micro sessions are IPv6 based.

In other words: having member links L1, L2, L3 using IPv4 packets while member links L4, L5 and L6 use IPv6 packets is what we don't want.

Probably no one would do this but we should write it down for clarification.

Another questions is if you could run both, IPv4 and IPv6 sessions on every member link. The paragraph in the draft does not allow this either. The problem with this setup is that the draft in it's current form is totally focused on LAG and the "LMM" being the consumer of the BFD information. The LAG is layer-2, so if an IPv4 session fails but the IPv6 session for the same member link stays up, what is the LMM gonna do?

(a) any member-link session fails -> take the link out of forwarding
(b) only when both IPv4 and IPv6 session fail we take the member link out

Regards, Marc

--
Marc Binderberger           <[email-masked]>

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 12 Mar 2012 05:39:25 +0000

Marc, Jeff and all,
IMHO and FWIW this thread is yet one more proof of the artificial nature of the decision to run micro-BFD sessions in IP encapsulation.
Overloading the BFD state machine with the need to discover peer IP addresses, the need for on-the fly modifications of encapsulation of the BFD packets in these encapsulations etc. have all been already noted and discussed on the list...

I wonder if the argument that "IP-based encapsulation would help to detect failures of the IP layer" is valid.
If it were, IS-IS (that does not run on IP) should be much less popular than OSPF (which does) - but AFAIK, this is not the case.

Regards,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] on behalf of Marc Binderberger [[email-masked]]
Sent: Sunday, March 11, 2012 11:44 PM
To: Jeffrey Haas
Cc: [email-masked]
Subject: Re: BFD on LAG - one AF session per member link

Hello Jeff,

Regards, Marc

--
Marc Binderberger           <[email-masked]>
This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 12 Mar 2012 09:21:54 +0100

Hello Alexander,

> IMHO and FWIW this thread is yet one more proof of the artificial nature of the decision to run micro-BFD sessions in IP encapsulation.

It is actually the apposite. The "IP" is a requirement from every customer I talked to - and I assume the same holds true for the other vendors that have an implementation based on IP encapsulation for per-member BFD. Artificial would be to ignore the customer requirements.

> Overloading the BFD state machine with the need to discover peer IP addresses, the need for on-the fly modifications of encapsulation of the BFD packets in these encapsulations etc. have all been a…

Agree this is mudding the water. But the per-member-link draft itself is talking about configuring the destination IP, full-stop.

> If it were, IS-IS (that does not run on IP) should be much less popular than OSPF (which does) - but AFAIK, this is not the case.

Because in the older days nobody knew better - until vendors and customers learned it the hard way. Had been some nasty outages with CLNS running but the IP table not being populated :-)

And because of such experience customers today demand IP-based per-member-link BFD :-)

Regards, Marc

---

From: Manav Bhatia <[email-masked]>
Date: Mon, 12 Mar 2012 14:21:45 +0530

Hi Marc,

> In other words: having member links L1, L2, L3 using IPv4 packets while member links L4, L5 and L6 use IPv6 packets is what we don't want.

Yes, that was the intention.

>
> Another questions is if you could run both, IPv4 and IPv6 sessions on every member link. The paragraph in the draft does not allow this either.

Well if we really want true fate separation for IPv4 and IPv6 then yes 
we might want to do this. Fate separation in case of LAGs would mean 
having a different IP load balancer (hash) for IPv4 and IPv6.

 > The problem with this setup is that the draft in it's current form is 
totally focused on LAG and the "LMM" being the consumer of the BFD 
information. The LAG is layer-2, so if an IPv4 session fails but the 
IPv6 session for the same member link stays up, what is the LMM gonna do?

I'll hazard a reply here.

The behavior would depend upon the HW capabilities.

Assuming that the HW has different IP balancers (LAG hashes) for IPv4 
and IPv6 then if a micro BFD session for v4 times out then you could 
remove that link from the IP balancer for the IPv4 traffic. You could 
still continue using that link for v6.

For most HWs that dont have a separate IP balancer for IPv4 and IPv6, a 
micro session timing out for one AF would automatically mean losing 
connectivity over the offending link for both v4 and v6.

Thus the operators need to run v4 and v6 BFD sessions only if their 
vendor's hardware has separate IP traffic balancers for v4 and v6.

> (b) only when both IPv4 and IPv6 session fail we take the member link out

Hope the above answers this.

Cheers, Manav

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 12 Mar 2012 09:48:04 -0400

Manav,

On Mon, Mar 12, 2012 at 02:21:45PM +0530, Manav Bhatia wrote:
> Well if we really want true fate separation for IPv4 and IPv6 then
> yes we might want to do this. Fate separation in case of LAGs would
> mean having a different IP load balancer (hash) for IPv4 and IPv6.

This was part of the point I was proxying.

> Assuming that the HW has different IP balancers (LAG hashes) for
> IPv4 and IPv6 then if a micro BFD session for v4 times out then you
> could remove that link from the IP balancer for the IPv4 traffic.
> You could still continue using that link for v6.
> 
> For most HWs that dont have a separate IP balancer for IPv4 and
> IPv6, a micro session timing out for one AF would automatically mean
> losing connectivity over the offending link for both v4 and v6.
> 

Exactly.

Whether it makes sense to do this or not will depend on the fate-sharing
properties of your various forwarding planes.  I believe this could be
accommodated by making multiple AF sessions on the links optional (i.e. the
SHOULD).  But what this means is that we need to be clear about what
implementations should do with this information.  In the current document,
we talk a bit about LACP.  In a future document, we'll talk more about the
forwarder.

One such behavior could be that if multiple sessions are up (which requires
*both* sides to agree by permitting sessions on multiple AFs) that the loss
of one AF may simply remove the bundle from that AF's load balancing.

In an environment with shared fate, running a single session would make
sense.

-- Jeff