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

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

Hi Donald,

> 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

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:[e-mail]] 
Sent: Monday, October 01, 2012 8:10 PM
To: JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)
Cc: Bhatia, Manav (Manav); [e-mail]
Subject: Re: Comment on DestinationMac in draft-mmm-bfd-on-lags

Hi,

On Mon, Oct 1, 2012 at 8:57 AM, JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)
<[e-mail]> wrote:
> 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.

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
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Regards,
> Arul Mohan.
>
> -----Original Message-----
> From: Bhatia, Manav (Manav)
> Sent: Monday, October 01, 2012 4:43 PM
> To: JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)
> Cc: [e-mail]
> Subject: RE: Comment on DestinationMac in draft-mmm-bfd-on-lags
>
> 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.
>> >>
>> >>
>> >
>>
>>