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

[Pablo Frank <[e-mail]>]

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) <
[e-mail]> wrote:

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