Re: Comment on DestinationMac in draft-mmm-bfd-on-lags
Donald Eastlake <d3e3e3@gmail.com> Mon, 01 October 2012 14:40 UTC
Return-Path: <d3e3e3@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC56521F8879 for <rtg-bfd@ietfa.amsl.com>; Mon, 1 Oct 2012 07:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.074
X-Spam-Level:
X-Spam-Status: No, score=-103.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKSWV-BR+zcK for <rtg-bfd@ietfa.amsl.com>; Mon, 1 Oct 2012 07:40:24 -0700 (PDT)
Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9690221F8881 for <rtg-bfd@ietf.org>; Mon, 1 Oct 2012 07:40:24 -0700 (PDT)
Received: by oagn5 with SMTP id n5so6198722oag.31 for <rtg-bfd@ietf.org>; Mon, 01 Oct 2012 07:40:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7SRPv0QA0yuNOdK6naHIo9Qk7DvJYntlsPWmXZVRICI=; b=tjscUhnUt71+XO36W+x69qUZblnGA8wEbPU6pLMqSWWaXPP8FOrKasPOY6C0icZauW wjtfFyMkt0rxK0QVKK0MoFOEpTxeCDIfI6Wqvvg7yQw5OHer5OHidpjp9msh0X/5Vcdp 85HG5fkSe1Wl5z6cXdISql4+r4HVUURLxUn/NQj2lZ6D9lEi4z6R+NyF0Klfc4eYwx53 fqodaDkOE7SlD/cMIhVO0H1c2FZsPzUvFODwkC/z6+GsRp0lkpHm9QORy2/U/04kJezC 5bgOW4U2HaN8mTiBjghBvMfK8bHaXityVWQHyOmhGqfPIj+FoQshdVyxGdNH4ST0t4f5 JWig==
Received: by 10.60.172.199 with SMTP id be7mr11676287oec.93.1349102424038; Mon, 01 Oct 2012 07:40:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.135.1 with HTTP; Mon, 1 Oct 2012 07:40:02 -0700 (PDT)
In-Reply-To: <7A2E55DFE338EE418E3B95A0C388997D075E408387@INBANSXCHMBSA1.in.alcatel-lucent.com>
References: <7A2E55DFE338EE418E3B95A0C388997D075E407F79@INBANSXCHMBSA1.in.alcatel-lucent.com> <CAF4+nEE6kK5WfSonT14z-rz4iFHS7JFvVry+xS1a9c+Waxvebw@mail.gmail.com> <2C22A8F0-BBC9-413C-9AD9-95813973BAA9@sniff.de> <7A2E55DFE338EE418E3B95A0C388997D075E408279@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D07F33618@INBANSXCHMBSA1.in.alcatel-lucent.com> <7A2E55DFE338EE418E3B95A0C388997D075E408387@INBANSXCHMBSA1.in.alcatel-lucent.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Mon, 01 Oct 2012 10:40:02 -0400
Message-ID: <CAF4+nEFVLHDTOORAxM58J1634-mEd6EEPNQJJrgzuEOKir_4=g@mail.gmail.com>
Subject: Re: Comment on DestinationMac in draft-mmm-bfd-on-lags
To: "JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)" <arulmohan.jovelponnaien@alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Oct 2012 14:40:25 -0000
Hi, On Mon, Oct 1, 2012 at 8:57 AM, JOVELPONNAIEN, ARULMOHAN (ARULMOHAN) <arulmohan.jovelponnaien@alcatel-lucent.com> 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 +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Regards, > Arul Mohan. > > -----Original Message----- > From: Bhatia, Manav (Manav) > Sent: Monday, October 01, 2012 4:43 PM > To: JOVELPONNAIEN, ARULMOHAN (ARULMOHAN) > Cc: rtg-bfd@ietf.org > 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: rtg-bfd-bounces@ietf.org >> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of JOVELPONNAIEN, >> ARULMOHAN (ARULMOHAN) >> Sent: Monday, October 01, 2012 2:55 PM >> To: Marc Binderberger; Donald Eastlake >> Cc: rtg-bfd@ietf.org >> 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:marc@sniff.de] >> Sent: Monday, October 01, 2012 3:24 AM >> To: JOVELPONNAIEN, ARULMOHAN (ARULMOHAN); Donald Eastlake >> Cc: rtg-bfd@ietf.org >> 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) >> > <arulmohan.jovelponnaien@alcatel-lucent.com> 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 d3e3e3@gmail.com >> > >> >> Regards, >> >> Arul Mohan. >> >> >> >> >> > >> >>
- Comment on DestinationMac in draft-mmm-bfd-on-lags JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)
- Re: Comment on DestinationMac in draft-mmm-bfd-on… Donald Eastlake
- Re: Comment on DestinationMac in draft-mmm-bfd-on… Marc Binderberger
- RE: Comment on DestinationMac in draft-mmm-bfd-on… JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)
- RE: Comment on DestinationMac in draft-mmm-bfd-on… Bhatia, Manav (Manav)
- RE: Comment on DestinationMac in draft-mmm-bfd-on… JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)
- Re: Comment on DestinationMac in draft-mmm-bfd-on… Donald Eastlake
- RE: Comment on DestinationMac in draft-mmm-bfd-on… JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)
- Re: Comment on DestinationMac in draft-mmm-bfd-on… Jeffrey Haas