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

From: Marc Binderberger <[email-masked]>
Date: Tue, 14 Aug 2012 18:29:12 +0200

Hello BFD experts,

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.

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).

Comments?

Regards, Marc
--
Marc Binderberger           <[email-masked]>

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Tue, 14 Aug 2012 19:53:04 +0200

I believe the main reason for allowing one or the other and not both was to avoid scale impact. If you want to run both we should allow it but we should state that this is not intended by default.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Binderberger
Sent: dinsdag 14 augustus 2012 18:29
To: [email-masked]; Pablo Frank
Cc: [email-masked]
Subject: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ?

Hello BFD experts,

Comments?

Regards, Marc

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 14 Aug 2012 14:01:57 -0400

Agree with Wim.

Regards,
Jeff

---

From: Mach Chen <[email-masked]>
Date: Wed, 15 Aug 2012 01:10:23 +0000

Agree.

In addition, in order for deployment and operational simplification, it may be better to specify the default address family (e.g., IPv4).

Best regards,
Mach

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Henderickx, Wim (Wim)
> 发送时间: 2012年8月15日 1:53
> 收件人: Marc Binderberger; [email-masked]; Pablo Frank
> 抄送: [email-masked]
> 主题: RE: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ?
> 
> I believe the main reason for allowing one or the other and not both was to
> avoid scale impact. If you want to run both we should allow it but we should
> state that this is not intended by default.
> 
> 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?
> 
> 
> 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
> 
> 
> 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).
> 
> 
> Comments?
> 
> 
> Regards, Marc
> --

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 16 Aug 2012 08:47:41 +0530

> 
> 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?
> 
> 

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
> 
> 
> 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

---

From: Pablo Frank <[email-masked]>
Date: Thu, 16 Aug 2012 10:32:17 -0400

In my original comments on this topic, I had suggested that one should be
able to run separate IPv4 and IPv6 micro-BFD sessions on the same member
link.  They would be separate sessions for all intents and purposes.
 Because of the scale problem, I also suggested that you should run one of
the address families at a more sedate rate but I was still thinking it
would be a set of (separate) micro-BFD sessions.

It seems inconsistent to me to suggest that one address family should use
micro-BFD and the other address family should use regular BFD.  If that's
acceptable, then why did we use IP encapsulation in the first place for
micro-BFD?

regards,
Pablo

On Wed, Aug 15, 2012 at 11:17 PM, Bhatia, Manav (Manav) <
[email-masked]> wrote:

> 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.
>
> 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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 16 Aug 2012 20:42:14 +0530

I believe there is nothing in the draft that precludes somebody from running separate IPv4 and IPv6 micro BFD sessions on the same member link. I could be missing something but i just cant think of why somebody would want to do that. Do you have some scenarios in mind?

Cheers, Manav

________________________________
From: Pablo Frank [mailto:[email-masked]]
Sent: Thursday, August 16, 2012 8:02 PM
To: Bhatia, Manav (Manav)
Cc: Marc Binderberger; [email-masked]; [email-masked]
Subject: Re: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ?

In my original comments on this topic, I had suggested that one should be able to run separate IPv4 and IPv6 micro-BFD sessions on the same member link.  They would be separate sessions for all intents and purposes.  Because of the scale problem, I also suggested that you should run one of the address families at a more sedate rate but I was still thinking it would be a set of (separate) micro-BFD sessions.

It seems inconsistent to me to suggest that one address family should use micro-BFD and the other address family should use regular BFD.  If that's acceptable, then why did we use IP encapsulation in the first place for micro-BFD?

regards,
Pablo

Cheers, Manav

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Aug 2012 15:16:30 +0000

Pablo, and all,
I suspect that the problems with IPv4/IPv6 (and some other problems) stem from the desire to kill two birds with one stone:

1.       To detect failure of individual physical links comprising LAG in the situations when lower layers do not provide suitable detection techniques.

a.        Ethernet over SONET is a classic example of such a link (unless you want to use ETH-AIS).

2.       To verify that IP connectivity across an individual link is "up and running".

a.       This has been the rationale for using IP encapsulation for micro-BFD sessions

b.      Judging by the level of support on the list, this is not an esoteric situation but a problem from real networking life

c.       Such verification would be admittedly implementation-specific with IMHO high potential for:

                                                              i.      False-positives (e.g., micro-BFD session is UP because local IP addresses used in these sessions are identified correctly, but IP packets to remote destinations are not forwarded because the LPM tables are corrupted). Note that this can happen with "normal" BFD

                                                            ii.      False-negatives (e.g., micro-BFD session does not come up because specific Destination MAC addresses it uses  are not recognized as "local", but IP packets using  MAC address of the LAG as their destination MAC address are treated normally)

d.      Separate verifications (and hence separate micro-BFD sessions) are required for IPv4 and IPv6 if both run over the LAG.

Quoting from my favorite RFC 1925<http://tools.ietf.org/rfc/rfc1925.txt>:

It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Pablo Frank
Sent: Thursday, August 16, 2012 5:32 PM
To: Bhatia, Manav (Manav)
Cc: [email-masked]; [email-masked]
Subject: Re: draft-mmm-bfd-on-lags: IPv4 _and_ IPv6 ?

regards,
Pablo

Cheers, Manav

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: Thu, 16 Aug 2012 17:20:04 +0200

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.

Regards, Marc

On 2012-08-16, at 17:12 , Bhatia, Manav (Manav) wrote:

> On Wed, Aug 15, 2012 at 11:17 PM, Bhatia, Manav (Manav) <[email-masked]> wrote:
> >