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

["Bhatia, Manav (Manav)" <[e-mail]>]

Hi Arul,

While I cant think of a specific scenario where we would want micro BFD sessions over L2 bridges/switches, I don't necessarily see why we should preclude the possibility of us ever supporting that in the future.

Cheers, Manav

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of JOVELPONNAIEN, 
> ARULMOHAN (ARULMOHAN)
> Sent: Monday, October 01, 2012 2:55 PM
> To: Marc Binderberger; Donald Eastlake
> Cc: [e-mail]
> Subject: RE: Comment on DestinationMac in draft-mmm-bfd-on-lags
> 
> 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.
> >> 
> >> 
> > 
> 
>