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

["JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)" <[e-mail]>]

Hi Marc and Donald,

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

I understand your reasoning for using IANA MAC address instead of IEEE. But it would be still good to define a jabber control mechanism or indicate micro-BFD is not supported over L2 bridges.

Regards,
Arul Mohan.

-----Original Message-----
From: Marc Binderberger [mailto:[e-mail]] 
Sent: Monday, October 01, 2012 3:24 AM
To: JOVELPONNAIEN, ARULMOHAN (ARULMOHAN); Donald Eastlake
Cc: [e-mail]
Subject: Re: Comment on DestinationMac in draft-mmm-bfd-on-lags

Hello Donald and Arul,

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


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



On 2012-09-30, at 21:52 , Donald Eastlake wrote:

> Hi,
> 
> On Fri, Sep 28, 2012 at 6:45 AM, JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)
> <[e-mail]> 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.
>> 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.
> 
> 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   [phone] (cell)
> 155 Beaver Street, Milford, MA 01757 USA
> [e-mail]
> 
>> Regards,
>> Arul Mohan.
>> 
>> 
>