Subject: Comment on DestinationMac in draft-mmm-bfd-on-lags

From: "JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)" <[email-masked]>
Date: Fri, 28 Sep 2012 16:15:28 +0530

Hi All,

Micro-BFD session would use dedicated destination MAC address allocated for IANA range(RFC 5342). But this MAC address range is not link-level and would allow forwarding of Link-Level BFD packets by intermediate L2 switches.

Assume case below, here it is possible that 3 micro BFD sessions from Router1 could be forwarded on single-port to Router2.
Router1 ------------(3-port) LAG------------L2 Switch-------(1-port LAG)-----------Router2

If MAC-address is chosen from range 01:80:c2:xx:xx:xx, then this case would not arise. Micro-BFD session would then be terminated by L2 switch immediately. By 802.1d standard 01:80:c2:xx:xx:xx would be terminated by L2 switch.

Is it not better if we choose a MAC address in 01:80:c2 range similar to LACP to make sure micro-BFD session remains link-level protocol?

Regards,
Arul Mohan.

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 30 Sep 2012 15:52:06 -0400

Hi,

On Fri, Sep 28, 2012 at 6:45 AM, JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)
<[email-masked]> wrote:
> Hi All,
>
> Micro-BFD session would use dedicated destination MAC address allocated for
> IANA range (RFC 5342). But this MAC address range is not link-level and would
> allow forwarding of Link-Level BFD packets by intermediate L2 switches.
>
> Assume case below, here it is possible that 3 micro BFD sessions from
> Router1 could be forwarded on single-port to Router2.
> If MAC-address is chosen from range 01:80:c2:xx:xx:xx, then this case would
> not arise. Micro-BFD session would then be terminated by L2 switch
> immediately. By 802.1d standard 01:80:c2:xx:xx:xx would be terminated by L2
> switch.

I believe you will find that the range of addresses that are blocked
by 802.1 bridges if they do not understand them is MUCH narrower. It
is, in fact, only the block of 16 addresses from 01:80:C2:00:00:00 to
01:80:C2:00:00:0F. For example, 01-80-C2-00-00-14 and
01-80-C2-00-00-15 are the addresses used by IS-IS for All Level 1 and
All Level 2 Intermediate Systems, respectively, and which must be
transparently handled by bridges or you couldn't have a bridge in
between two Layer 3 IP routers.

> Is it not better if we choose a MAC address in 01:80:c2 range similar to
> LACP to make sure micro-BFD session remains link-level protocol?

If you want an address of that type, you could apply to the IEEE
Registration Authority although the WG should probably coordinate that
with you AD. Only a tiny fraction of those addresses, which are
intended for standards use, have been allocated. But, as I say, it
will not make any difference to the behavior and it seems easier for
an IETF WG to get a 48-bit multicast address using the procedures in
RFC 5342.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 30 Sep 2012 23:54:06 +0200

Hello Donald and Arul,

> 01:80:C2:00:00:0F.

indeed, see e.g. http://standards.ieee.org/develop/regauth/tut/macgrp.pdf and http://standards.ieee.org/develop/regauth/grpmac/public.html .

So yes, in the setup you describe - and which is not supported as of now by the draft - it can get confusing.

Why do we look at a RFC5342 IANA MAC address? 

- unlikely we get our own address out of the scarce resource of the 16 link-local addresses

- sharing a MAC out of this range is mixing IEEE and IETF and side effects may occur

- we actually want to have a dedicated MAC "only for us", as some implementation may use the MAC to know it's a micro session and process it accordingly. This processing may be very different from 802.1D, 802.3 and other IEEE-related processing (hardware vs. software, distributed vs. central, delay/jitter of processing and so on)

- using link-local MAC would require a new allocation if we want to extend the draft across layer-2 bridges. We haven't cracked this problem yet but like to keep it open.
(okay, not a strong point, if we would need another MAC we could get one from IANA I suppose)

I would say we need practical experience to see how bad your scenario actually is and if we need to introduce e.g. some "jabber control" on the BFD level, i.e. detecting when multiple sessions end up on one link. Or we just state clearly what is and what is not supported.

Regards, Marc