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

From: "JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)" <[email-masked]>
Date: Mon, 1 Oct 2012 14:55:20 +0530

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:[email-masked]] 
Sent: Monday, October 01, 2012 3:24 AM
To: JOVELPONNAIEN, ARULMOHAN (ARULMOHAN); Donald Eastlake
Cc: [email-masked]
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)
> <[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.
>> 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   +1-508-333-2270 (cell)
> 155 Beaver Street, Milford, MA 01757 USA
> [email-masked]
> 
>> Regards,
>> Arul Mohan.
>> 
>> 
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 1 Oct 2012 16:42:42 +0530

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of JOVELPONNAIEN, 
> ARULMOHAN (ARULMOHAN)
> Sent: Monday, October 01, 2012 2:55 PM
> To: Marc Binderberger; Donald Eastlake
> Cc: [email-masked]
> Subject: RE: Comment on DestinationMac in draft-mmm-bfd-on-lags
> 
> Hi Marc and Donald,
> 
> > 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.
> 
> 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.
> 
> 
> - 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.
> 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
> 
> 
> 
> >> 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.
> >> 
> >> 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?
> > 
> > 155 Beaver Street, Milford, MA 01757 USA [email-masked]
> > 
> >> Regards,
> >> Arul Mohan.
> >> 
> >> 
> > 
> 
>

---

From: "JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)" <[email-masked]>
Date: Mon, 1 Oct 2012 18:27:27 +0530

Hi Manav,

LACP for sure cannot cross-over a L2 bridge. So for BFD on top of LAGs(with LACP) we should have same behavior. BFD termination end-point should be similar to LACP.

Regards,
Arul Mohan.

-----Original Message-----
From: Bhatia, Manav (Manav) 
Sent: Monday, October 01, 2012 4:43 PM
To: JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)
Cc: [email-masked]
Subject: RE: Comment on DestinationMac in draft-mmm-bfd-on-lags

Hi Arul,

Cheers, Manav

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 1 Oct 2012 10:40:02 -0400

Hi,

> LACP for sure cannot cross-over a L2 bridge. So for BFD on top of LAGs(with LACP) we should have same behavior. BFD termination end-point should be similar to LACP.

Sort of.

If you look at IEEE Std 802.1AXbk-2012 (25 May 2012), you will find
that LACP has been generalized so that the LACP frame destination MAC
address is no longer limited to always being 01-80-C2-00-00-02, the
IEEE 802.3 Slow_Protocols_Multicast, which must be handled or blocked
by all 802.1 bridges.

LACP is now permitted to run using destination MAC address
01-80-C2-00-00-03, Nearest non-TPMR Bridge, and 01-80-C2-00-00-00,
Nearest Customer Bridge. If you use the Nearest Customer Bridge
destination MAC, then Provider bridges and Two Port MAC Relays (TMPRs,
which are a type of 802.1 bridge) will be transparent to those LACP
frames. And if you use the Nearest non-TPMR Bridge destination MAC,
then TMPRs will be transparent to those LACP frames, although both
Customer and Provider bridges will either handle or block the frames.

Thanks,
Donald

---

From: "JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)" <[email-masked]>
Date: Tue, 2 Oct 2012 12:12:47 +0530

Hi Donald,

> frames

I am not referring to TPMR bridges here. I am referring to normal bridges(non-TPMR).
I would re-phrase my statement. "LACP for sure cannot cross over non-TPMR bridges. Micro-BFD also should act similar and not cross over non-TPMR bridges."

But destination-MAC currently defined for micro-BFD allows it to cross non-TPMR bridges.

Regards,
Arul Mohan.

-----Original Message-----
From: Donald Eastlake [mailto:[email-masked]] 
Sent: Monday, October 01, 2012 8:10 PM
To: JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)
Cc: Bhatia, Manav (Manav); [email-masked]
Subject: Re: Comment on DestinationMac in draft-mmm-bfd-on-lags

Hi,

Sort of.

Thanks,
Donald

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 4 Oct 2012 14:25:36 -0400

Arul,

On Mon, Oct 01, 2012 at 02:55:20PM +0530, JOVELPONNAIEN, ARULMOHAN (ARULMOHAN) wrote:
> 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.

Until a BFD session transitions to the Up state, it will use the sedate
timers.  In this case, 1 message per second.

As mentioned elsewhere, we intend to explore work to do BFD over LAG over
switches in the future.  Some of the initial speculation of such a feature
is that the multicast MAC would be used as part of service discovery.  Once
the session is ready to transition to the Up state, it is very likely that a
unicast MAC would be used for the destination.

But again, this is speculation and work that is deferred for the future.

-- Jeff (speaking as an individual contributor)