From arulmohan.jovelponnaien@alcatel-lucent.com Mon Oct 1 02:25:36 2012 Return-Path: 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 37C7021F85BB for ; Mon, 1 Oct 2012 02:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.149 X-Spam-Level: X-Spam-Status: No, score=-7.149 tagged_above=-999 required=5 tests=[AWL=-2.849, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4] 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 Ey3qVipnN3Mh for ; Mon, 1 Oct 2012 02:25:29 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 90A9921F8587 for ; Mon, 1 Oct 2012 02:25:29 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q919PMS8002402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 04:25:25 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q919PLQS007138 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 1 Oct 2012 14:55:21 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Mon, 1 Oct 2012 14:55:21 +0530 From: "JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)" To: Marc Binderberger , Donald Eastlake Date: Mon, 1 Oct 2012 14:55:20 +0530 Subject: RE: Comment on DestinationMac in draft-mmm-bfd-on-lags Thread-Topic: Comment on DestinationMac in draft-mmm-bfd-on-lags Thread-Index: Ac2fViR7g2ei/WcOSdKUa8LkKVurgQAXeofQ Message-ID: <7A2E55DFE338EE418E3B95A0C388997D075E408279@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7A2E55DFE338EE418E3B95A0C388997D075E407F79@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C22A8F0-BBC9-413C-9AD9-95813973BAA9@sniff.de> In-Reply-To: <2C22A8F0-BBC9-413C-9AD9-95813973BAA9@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 09:25:36 -0000 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 w= e > 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 mi= cro-BFD is not supported over L2 bridges. Regards, Arul Mohan. -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de]=20 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 a= nd 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?=20 - 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 implement= ation may use the MAC to know it's a micro session and process it according= ly. 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 l= ike to keep it open. (okay, not a strong point, if we would need another MAC we could get one fr= om IANA I suppose) I would say we need practical experience to see how bad your scenario actua= lly is and if we need to introduce e.g. some "jabber control" on the BFD le= vel, i.e. detecting when multiple sessions end up on one link. Or we just s= tate clearly what is and what is not supported. [ Regards, Marc On 2012-09-30, at 21:52 , Donald Eastlake wrote: > Hi, >=20 > On Fri, Sep 28, 2012 at 6:45 AM, JOVELPONNAIEN, ARULMOHAN (ARULMOHAN) > wrote: >> Hi All, >>=20 >> 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. >>=20 >> 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 >>=20 >> If MAC-address is chosen from range 01:80:c2:xx:xx:xx, then this case wo= uld >> 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. >=20 > 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. >=20 >> 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? >=20 > 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. >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com >=20 >> Regards, >> Arul Mohan. >>=20 >>=20 >=20 From manav.bhatia@alcatel-lucent.com Mon Oct 1 04:12:42 2012 Return-Path: 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 31E7121F8602 for ; Mon, 1 Oct 2012 04:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-8] 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 uBHSMZ57vhdW for ; Mon, 1 Oct 2012 04:12:41 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2290B21F85C7 for ; Mon, 1 Oct 2012 04:12:40 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q91BCa5v002815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 1 Oct 2012 06:12:39 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q91BCYfo017686 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 1 Oct 2012 16:42:35 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Mon, 1 Oct 2012 16:42:34 +0530 From: "Bhatia, Manav (Manav)" To: "JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)" Date: Mon, 1 Oct 2012 16:42:42 +0530 Subject: RE: Comment on DestinationMac in draft-mmm-bfd-on-lags Thread-Topic: Comment on DestinationMac in draft-mmm-bfd-on-lags Thread-Index: Ac2fViR7g2ei/WcOSdKUa8LkKVurgQAXeofQAARSCrA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D07F33618@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7A2E55DFE338EE418E3B95A0C388997D075E407F79@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C22A8F0-BBC9-413C-9AD9-95813973BAA9@sniff.de> <7A2E55DFE338EE418E3B95A0C388997D075E408279@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7A2E55DFE338EE418E3B95A0C388997D075E408279@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 11:12:42 -0000 Hi Arul, While I cant think of a specific scenario where we would want micro BFD ses= sions over L2 bridges/switches, I don't necessarily see why we should precl= ude the possibility of us ever supporting that in the future. Cheers, Manav > -----Original Message----- > From: rtg-bfd-bounces@ietf.org=20 > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of JOVELPONNAIEN,=20 > 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 >=20 > Hi Marc and Donald, >=20 > > I would say we need practical experience to see how bad=20 > your scenario=20 > > actually is and if we need to introduce e.g. some "jabber=20 > control" on=20 > > the BFD level, i.e. detecting when multiple sessions end up=20 > on one link. Or we > just state clearly what is and what is=20 > not supported. >=20 > I understand your reasoning for using IANA MAC address=20 > instead of IEEE. But it would be still good to define a=20 > jabber control mechanism or indicate micro-BFD is not=20 > supported over L2 bridges. >=20 > Regards, > Arul Mohan. >=20 > -----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 >=20 > Hello Donald and Arul, >=20 > > I believe you will find that the range of addresses that=20 > are blocked=20 > > by 802.1 bridges if they do not understand them is MUCH=20 > narrower. It=20 > > is, in fact, only the block of 16 addresses from=20 > 01:80:C2:00:00:00 to=20 > > 01:80:C2:00:00:0F. >=20 >=20 > indeed, see e.g.=20 > http://standards.ieee.org/develop/regauth/tut/macgrp.pdf and=20 > http://standards.ieee.org/develop/regauth/grpmac/public.html . >=20 > So yes, in the setup you describe - and which is not=20 > supported as of now by the draft - it can get confusing. >=20 >=20 > Why do we look at a RFC5342 IANA MAC address?=20 >=20 > - unlikely we get our own address out of the scarce resource=20 > of the 16 link-local addresses >=20 > - sharing a MAC out of this range is mixing IEEE and IETF and=20 > side effects may occur >=20 > - we actually want to have a dedicated MAC "only for us", as=20 > some implementation may use the MAC to know it's a micro=20 > session and process it accordingly. This processing may be=20 > very different from 802.1D, 802.3 and other IEEE-related=20 > processing (hardware vs. software, distributed vs. central,=20 > delay/jitter of processing and so on) >=20 > - using link-local MAC would require a new allocation if we=20 > want to extend the draft across layer-2 bridges. We haven't=20 > cracked this problem yet but like to keep it open. > (okay, not a strong point, if we would need another MAC we=20 > could get one from IANA I suppose) >=20 >=20 > I would say we need practical experience to see how bad your=20 > scenario actually is and if we need to introduce e.g. some=20 > "jabber control" on the BFD level, i.e. detecting when=20 > multiple sessions end up on one link. Or we just state=20 > clearly what is and what is not supported. > [ >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On 2012-09-30, at 21:52 , Donald Eastlake wrote: >=20 > > Hi, > >=20 > > On Fri, Sep 28, 2012 at 6:45 AM, JOVELPONNAIEN, ARULMOHAN=20 > (ARULMOHAN)=20 > > wrote: > >> Hi All, > >>=20 > >> Micro-BFD session would use dedicated destination MAC address=20 > >> allocated for IANA range (RFC 5342). But this MAC address range is=20 > >> not link-level and would allow forwarding of Link-Level=20 > BFD packets by intermediate L2 switches. > >>=20 > >> Assume case below, here it is possible that 3 micro BFD=20 > sessions from > >> Router1 could be forwarded on single-port to Router2. > >> Router1 ------------(3-port) LAG------------L2 Switch-------(1-port > >> LAG)-----------Router2 > >>=20 > >> If MAC-address is chosen from range 01:80:c2:xx:xx:xx,=20 > then this case=20 > >> would not arise. Micro-BFD session would then be terminated by L2=20 > >> switch immediately. By 802.1d standard 01:80:c2:xx:xx:xx would be=20 > >> terminated by L2 switch. > >=20 > > I believe you will find that the range of addresses that=20 > are blocked=20 > > by 802.1 bridges if they do not understand them is MUCH=20 > narrower. It=20 > > is, in fact, only the block of 16 addresses from=20 > 01:80:C2:00:00:00 to=20 > > 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=20 > Level 1 and=20 > > All Level 2 Intermediate Systems, respectively, and which must be=20 > > transparently handled by bridges or you couldn't have a bridge in=20 > > between two Layer 3 IP routers. > >=20 > >> Is it not better if we choose a MAC address in 01:80:c2=20 > range similar=20 > >> to LACP to make sure micro-BFD session remains link-level protocol? > >=20 > > If you want an address of that type, you could apply to the IEEE=20 > > Registration Authority although the WG should probably=20 > coordinate that=20 > > with you AD. Only a tiny fraction of those addresses, which are=20 > > intended for standards use, have been allocated. But, as I say, it=20 > > will not make any difference to the behavior and it seems=20 > easier for=20 > > an IETF WG to get a 48-bit multicast address using the=20 > procedures in=20 > > RFC 5342. > >=20 > > Thanks, > > Donald > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > >=20 > >> Regards, > >> Arul Mohan. > >>=20 > >>=20 > >=20 >=20 > = From arulmohan.jovelponnaien@alcatel-lucent.com Mon Oct 1 05:57:50 2012 Return-Path: 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 5A80811E8185 for ; Mon, 1 Oct 2012 05:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.424 X-Spam-Level: X-Spam-Status: No, score=-5.424 tagged_above=-999 required=5 tests=[AWL=-1.725, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4] 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 bjyja-Sefxjw for ; Mon, 1 Oct 2012 05:57:49 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB9B11E8219 for ; Mon, 1 Oct 2012 05:57:32 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q91CvSvU022123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 1 Oct 2012 07:57:31 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q91CvReE028386 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 1 Oct 2012 18:27:27 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Mon, 1 Oct 2012 18:27:27 +0530 From: "JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)" To: "Bhatia, Manav (Manav)" Date: Mon, 1 Oct 2012 18:27:27 +0530 Subject: RE: Comment on DestinationMac in draft-mmm-bfd-on-lags Thread-Topic: Comment on DestinationMac in draft-mmm-bfd-on-lags Thread-Index: Ac2fViR7g2ei/WcOSdKUa8LkKVurgQAXeofQAARSCrAAA5YyUA== Message-ID: <7A2E55DFE338EE418E3B95A0C388997D075E408387@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7A2E55DFE338EE418E3B95A0C388997D075E407F79@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C22A8F0-BBC9-413C-9AD9-95813973BAA9@sniff.de> <7A2E55DFE338EE418E3B95A0C388997D075E408279@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D07F33618@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D07F33618@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 12:57:50 -0000 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 si= milar to LACP. Regards, Arul Mohan. -----Original Message----- From: Bhatia, Manav (Manav)=20 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 ses= sions over L2 bridges/switches, I don't necessarily see why we should precl= ude the possibility of us ever supporting that in the future. Cheers, Manav > -----Original Message----- > From: rtg-bfd-bounces@ietf.org=20 > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of JOVELPONNAIEN,=20 > 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 >=20 > Hi Marc and Donald, >=20 > > I would say we need practical experience to see how bad=20 > your scenario=20 > > actually is and if we need to introduce e.g. some "jabber=20 > control" on=20 > > the BFD level, i.e. detecting when multiple sessions end up=20 > on one link. Or we > just state clearly what is and what is=20 > not supported. >=20 > I understand your reasoning for using IANA MAC address=20 > instead of IEEE. But it would be still good to define a=20 > jabber control mechanism or indicate micro-BFD is not=20 > supported over L2 bridges. >=20 > Regards, > Arul Mohan. >=20 > -----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 >=20 > Hello Donald and Arul, >=20 > > I believe you will find that the range of addresses that=20 > are blocked=20 > > by 802.1 bridges if they do not understand them is MUCH=20 > narrower. It=20 > > is, in fact, only the block of 16 addresses from=20 > 01:80:C2:00:00:00 to=20 > > 01:80:C2:00:00:0F. >=20 >=20 > indeed, see e.g.=20 > http://standards.ieee.org/develop/regauth/tut/macgrp.pdf and=20 > http://standards.ieee.org/develop/regauth/grpmac/public.html . >=20 > So yes, in the setup you describe - and which is not=20 > supported as of now by the draft - it can get confusing. >=20 >=20 > Why do we look at a RFC5342 IANA MAC address?=20 >=20 > - unlikely we get our own address out of the scarce resource=20 > of the 16 link-local addresses >=20 > - sharing a MAC out of this range is mixing IEEE and IETF and=20 > side effects may occur >=20 > - we actually want to have a dedicated MAC "only for us", as=20 > some implementation may use the MAC to know it's a micro=20 > session and process it accordingly. This processing may be=20 > very different from 802.1D, 802.3 and other IEEE-related=20 > processing (hardware vs. software, distributed vs. central,=20 > delay/jitter of processing and so on) >=20 > - using link-local MAC would require a new allocation if we=20 > want to extend the draft across layer-2 bridges. We haven't=20 > cracked this problem yet but like to keep it open. > (okay, not a strong point, if we would need another MAC we=20 > could get one from IANA I suppose) >=20 >=20 > I would say we need practical experience to see how bad your=20 > scenario actually is and if we need to introduce e.g. some=20 > "jabber control" on the BFD level, i.e. detecting when=20 > multiple sessions end up on one link. Or we just state=20 > clearly what is and what is not supported. > [ >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On 2012-09-30, at 21:52 , Donald Eastlake wrote: >=20 > > Hi, > >=20 > > On Fri, Sep 28, 2012 at 6:45 AM, JOVELPONNAIEN, ARULMOHAN=20 > (ARULMOHAN)=20 > > wrote: > >> Hi All, > >>=20 > >> Micro-BFD session would use dedicated destination MAC address=20 > >> allocated for IANA range (RFC 5342). But this MAC address range is=20 > >> not link-level and would allow forwarding of Link-Level=20 > BFD packets by intermediate L2 switches. > >>=20 > >> Assume case below, here it is possible that 3 micro BFD=20 > sessions from > >> Router1 could be forwarded on single-port to Router2. > >> Router1 ------------(3-port) LAG------------L2 Switch-------(1-port > >> LAG)-----------Router2 > >>=20 > >> If MAC-address is chosen from range 01:80:c2:xx:xx:xx,=20 > then this case=20 > >> would not arise. Micro-BFD session would then be terminated by L2=20 > >> switch immediately. By 802.1d standard 01:80:c2:xx:xx:xx would be=20 > >> terminated by L2 switch. > >=20 > > I believe you will find that the range of addresses that=20 > are blocked=20 > > by 802.1 bridges if they do not understand them is MUCH=20 > narrower. It=20 > > is, in fact, only the block of 16 addresses from=20 > 01:80:C2:00:00:00 to=20 > > 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=20 > Level 1 and=20 > > All Level 2 Intermediate Systems, respectively, and which must be=20 > > transparently handled by bridges or you couldn't have a bridge in=20 > > between two Layer 3 IP routers. > >=20 > >> Is it not better if we choose a MAC address in 01:80:c2=20 > range similar=20 > >> to LACP to make sure micro-BFD session remains link-level protocol? > >=20 > > If you want an address of that type, you could apply to the IEEE=20 > > Registration Authority although the WG should probably=20 > coordinate that=20 > > with you AD. Only a tiny fraction of those addresses, which are=20 > > intended for standards use, have been allocated. But, as I say, it=20 > > will not make any difference to the behavior and it seems=20 > easier for=20 > > an IETF WG to get a 48-bit multicast address using the=20 > procedures in=20 > > RFC 5342. > >=20 > > Thanks, > > Donald > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > >=20 > >> Regards, > >> Arul Mohan. > >>=20 > >>=20 > >=20 >=20 >=20 From d3e3e3@gmail.com Mon Oct 1 07:40:25 2012 Return-Path: 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 ; 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 ; 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 ; Mon, 1 Oct 2012 07:40:24 -0700 (PDT) Received: by oagn5 with SMTP id n5so6198722oag.31 for ; 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> <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 Date: Mon, 1 Oct 2012 10:40:02 -0400 Message-ID: Subject: Re: Comment on DestinationMac in draft-mmm-bfd-on-lags To: "JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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) 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) >> > 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. >> >> >> >> >> > >> >> From arulmohan.jovelponnaien@alcatel-lucent.com Mon Oct 1 23:42:55 2012 Return-Path: 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 7183721F8A18 for ; Mon, 1 Oct 2012 23:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] 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 8cz30hhDNiJp for ; Mon, 1 Oct 2012 23:42:54 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 585B521F8A15 for ; Mon, 1 Oct 2012 23:42:53 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q926glvY003437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 01:42:51 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q926glF0025894 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 2 Oct 2012 12:12:47 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Tue, 2 Oct 2012 12:12:46 +0530 From: "JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)" To: Donald Eastlake Date: Tue, 2 Oct 2012 12:12:47 +0530 Subject: RE: Comment on DestinationMac in draft-mmm-bfd-on-lags Thread-Topic: Comment on DestinationMac in draft-mmm-bfd-on-lags Thread-Index: Ac2f4rVlY/+i31wKRtCYPoRNtF14GwAg37SQ Message-ID: <7A2E55DFE338EE418E3B95A0C388997D075E408440@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7A2E55DFE338EE418E3B95A0C388997D075E407F79@INBANSXCHMBSA1.in.alcatel-lucent.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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 06:42:55 -0000 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(n= on-TPMR). I would re-phrase my statement. "LACP for sure cannot cross over non-TPMR b= ridges. Micro-BFD also should act similar and not cross over non-TPMR bridg= es." But destination-MAC currently defined for micro-BFD allows it to cross non-= TPMR bridges. Regards, Arul Mohan. -----Original Message----- From: Donald Eastlake [mailto:d3e3e3@gmail.com]=20 Sent: Monday, October 01, 2012 8:10 PM To: JOVELPONNAIEN, ARULMOHAN (ARULMOHAN) Cc: Bhatia, Manav (Manav); rtg-bfd@ietf.org Subject: Re: Comment on DestinationMac in draft-mmm-bfd-on-lags Hi, On Mon, Oct 1, 2012 at 8:57 AM, JOVELPONNAIEN, ARULMOHAN (ARULMOHAN) wrote: > Hi Manav, > > LACP for sure cannot cross-over a L2 bridge. So for BFD on top of LAGs(wi= th 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D 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 s= essions over L2 bridges/switches, I don't necessarily see why we should pre= clude 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) >> > 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 >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> > Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> > 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >> > >> >> Regards, >> >> Arul Mohan. >> >> >> >> >> > >> >> From jhaas@slice.pfrc.org Thu Oct 4 11:25:37 2012 Return-Path: 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 5198721F86B0 for ; Thu, 4 Oct 2012 11:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.343 X-Spam-Level: X-Spam-Status: No, score=-102.343 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 8abaj-24kOYC for ; Thu, 4 Oct 2012 11:25:37 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DBDFB21F8648 for ; Thu, 4 Oct 2012 11:25:36 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 792C6C3A9; Thu, 4 Oct 2012 14:25:36 -0400 (EDT) Date: Thu, 4 Oct 2012 14:25:36 -0400 From: Jeffrey Haas To: "JOVELPONNAIEN, ARULMOHAN (ARULMOHAN)" Subject: Re: Comment on DestinationMac in draft-mmm-bfd-on-lags Message-ID: <20121004182536.GY1854@pfrc> References: <7A2E55DFE338EE418E3B95A0C388997D075E407F79@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C22A8F0-BBC9-413C-9AD9-95813973BAA9@sniff.de> <7A2E55DFE338EE418E3B95A0C388997D075E408279@INBANSXCHMBSA1.in.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7A2E55DFE338EE418E3B95A0C388997D075E408279@INBANSXCHMBSA1.in.alcatel-lucent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 18:25:37 -0000 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) From marc@sniff.de Fri Oct 12 04:10:29 2012 Return-Path: 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 1340B21F8596 for ; Fri, 12 Oct 2012 04:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599] 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 1J-4Mbh53gpO for ; Fri, 12 Oct 2012 04:10:28 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2764921F855F for ; Fri, 12 Oct 2012 04:10:28 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 2FF3C2AA0F for ; Fri, 12 Oct 2012 11:10:26 +0000 (GMT) From: Marc Binderberger Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fwd: I-D Action: draft-mmm-bfd-on-lags-06.txt Date: Fri, 12 Oct 2012 13:10:25 +0200 References: <20121012084117.9925.42306.idtracker@ietfa.amsl.com> To: rtg-bfd@ietf.org Message-Id: <3B1AF1C6-157C-47BE-AD92-94E001754201@sniff.de> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 11:10:29 -0000 Hello BFD experts, the authors of draft-mmm-bfd-on-lags have taken your input plus our = internal discussions to create a new version -06 of the draft. Well, see yourself :-) Best regards, Marc Begin forwarded message: > From: internet-drafts@ietf.org > Date: October 12, 2012 10:41:17 GMT+02:00 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-mmm-bfd-on-lags-06.txt > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Bidirectional Forwarding Detection (BFD) on = Link Aggregation Group (LAG) Interfaces > Author(s) : Manav Bhatia > Mach(Guoyi) Chen > Sami Boutros > Marc Binderberger > Jeffrey Haas > Filename : draft-mmm-bfd-on-lags-06.txt > Pages : 11 > Date : 2012-10-12 >=20 > Abstract: > This document proposes a mechanism to run BFD on Link Aggregation > Group (LAG) interfaces. It does so by running an independent > Asynchronous mode BFD session on every LAG member link. >=20 > This mechanism allows the verification of member link continuity, > either in combination with, or in absence of, LACP. It provides a > shorter detection time than what LACP offers. The continuity check > can also cover elements of layer 3 bidirectional forwarding. >=20 > This mechanism utilizes a well-known UDP port distinct from that of > single-hop BFD over IP. This new UDP port removes the ambiguity of > BFD over LAG packets from BFD over single-hop IP. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-mmm-bfd-on-lags >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-mmm-bfd-on-lags-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-mmm-bfd-on-lags-06 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 From jhaas@slice.pfrc.org Fri Oct 12 08:25:05 2012 Return-Path: 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 24C5221F8644 for ; Fri, 12 Oct 2012 08:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.323 X-Spam-Level: X-Spam-Status: No, score=-102.323 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 SHu4q6LlOW3K for ; Fri, 12 Oct 2012 08:25:04 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B7B8621F8643 for ; Fri, 12 Oct 2012 08:25:04 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 20770C383; Fri, 12 Oct 2012 11:25:04 -0400 (EDT) Date: Fri, 12 Oct 2012 11:25:04 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: Fwd: I-D Action: draft-mmm-bfd-on-lags-06.txt Message-ID: <20121012152503.GE6973@pfrc> References: <20121012084117.9925.42306.idtracker@ietfa.amsl.com> <3B1AF1C6-157C-47BE-AD92-94E001754201@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B1AF1C6-157C-47BE-AD92-94E001754201@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 15:25:05 -0000 Working group, On Fri, Oct 12, 2012 at 01:10:25PM +0200, Marc Binderberger wrote: > Hello BFD experts, > > the authors of draft-mmm-bfd-on-lags have taken your input plus our internal discussions to create a new version -06 of the draft. The current document reflects the consensus to date on the feature. Since we have multiple vendors working on code related to this specification, we're expecting minor tweaks to accommodate implementations as we gain experience with the specification. Our hope, however, is that the structure of the feature is generally stable. The authors and editors of the draft would greatly appreciate your feedback on the current text. Things of note: - We are hoping our re-charter for the working group will be complete by the Atlanta IETF and will include this item. - We have proceeded with requesting code points for the well known MAC address and the UDP port. - The major place where the specification seems to still need attention is clarifying behavior in the presence of VLANs when the VLAN terminates in a VRF. As noted before, BFD will *not* be meeting at the upcoming IETF. However, it is my intention to publish status slides for the WG as part of the meeting materials. -- Jeff From jhaas@slice.pfrc.org Wed Oct 17 06:36:35 2012 Return-Path: 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 476D521F8617 for ; Wed, 17 Oct 2012 06:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.319 X-Spam-Level: X-Spam-Status: No, score=-102.319 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 Fyu13AScNfCg for ; Wed, 17 Oct 2012 06:36:34 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8464D21F8606 for ; Wed, 17 Oct 2012 06:36:34 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id F216EC248; Wed, 17 Oct 2012 09:36:33 -0400 (EDT) Date: Wed, 17 Oct 2012 09:36:33 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Fwd: [IANA #608024] EUI-48 request Message-ID: <20121017133633.GB13587@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 13:36:35 -0000 Begin forwarded message: > From: Amanda Baber via RT > Subject: [IANA #608024] EUI-48 request > Date: October 16, 2012 11:23:01 PM EDT > > Hi Jeff, > > We've assigned the following IANA Multicast 48-bit MAC Address (by the > way, the IANA Considerations section needs to mention, as section 2.3 > does, that this is a dedicated multicast address) with your draft as a > reference: > > 90-00-01 > Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) > Interfaces > [draft-mmm-bfd-on-lags] > > Please see > http://www.iana.org/assignments/ethernet-numbers/ > > thanks, > > Amanda Baber > ICANN/IANA > From d3e3e3@gmail.com Wed Oct 17 06:42:42 2012 Return-Path: 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 0005321F853B for ; Wed, 17 Oct 2012 06:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.484 X-Spam-Level: X-Spam-Status: No, score=-103.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, 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 UrcRNwkdmC6d for ; Wed, 17 Oct 2012 06:42:41 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 408AF21F8448 for ; Wed, 17 Oct 2012 06:42:41 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so6292025iad.31 for ; Wed, 17 Oct 2012 06:42:40 -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=CQIDa0wCFUZZLvcVyHmXIc91MFtXxeIjtAiUeVDsAXs=; b=KyGLcPkm6aZgWwgSEzUtw9Sah/0MZC1aAsG7e/2+JkLiSeT96hTFIH5CWog5HbnDcy d0maoByXTIz7R2bAtJRYIzV3kh9dDNtRSK7bL0rztrfMe2xJ6PRQU3rxp41cX6VIt5g4 3MytIl+DMmd5kdChMm5D9dO0psdYwA31dwy8BJJaaF5y/9grFiG6BrSYDx1IKP/IT3+I Yftq3BycHk81r9hTMrfCTYQBtk+zATMd7a9t5sJf96s6VIhylzVkYXET6B+RaBFgDHB2 gs67zb44QEbBI1G/zoW9+k9tSUP9AxYyKFfE6aCdLxo+ca3qG6R5GvmiFHfX4/EiAPWx t12Q== Received: by 10.50.33.147 with SMTP id r19mr1515462igi.73.1350481360822; Wed, 17 Oct 2012 06:42:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.113 with HTTP; Wed, 17 Oct 2012 06:42:20 -0700 (PDT) In-Reply-To: <20121017133633.GB13587@pfrc> References: <20121017133633.GB13587@pfrc> From: Donald Eastlake Date: Wed, 17 Oct 2012 09:42:20 -0400 Message-ID: Subject: Re: [IANA #608024] EUI-48 request To: Jeffrey Haas Content-Type: text/plain; charset=ISO-8859-1 Cc: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 13:42:42 -0000 Note that such values are pre-fixed by the IANA OUI with the multicast bit turned on or off depending on whether the address is multicast. So the MAC address in this case is really 01-00-05-90-00-01. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, Oct 17, 2012 at 9:36 AM, Jeffrey Haas wrote: > Begin forwarded message: > >> From: Amanda Baber via RT >> Subject: [IANA #608024] EUI-48 request >> Date: October 16, 2012 11:23:01 PM EDT >> >> Hi Jeff, >> >> We've assigned the following IANA Multicast 48-bit MAC Address (by the >> way, the IANA Considerations section needs to mention, as section 2.3 >> does, that this is a dedicated multicast address) with your draft as a >> reference: >> >> 90-00-01 >> Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) >> Interfaces >> [draft-mmm-bfd-on-lags] >> >> Please see >> http://www.iana.org/assignments/ethernet-numbers/ >> >> thanks, >> >> Amanda Baber >> ICANN/IANA >> From d3e3e3@gmail.com Wed Oct 17 06:54:32 2012 Return-Path: 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 3C74A21F85F4 for ; Wed, 17 Oct 2012 06:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.487 X-Spam-Level: X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, 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 GTy-sUEJ50v9 for ; Wed, 17 Oct 2012 06:54:31 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1F021F8499 for ; Wed, 17 Oct 2012 06:54:31 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so6303208iad.31 for ; Wed, 17 Oct 2012 06:54:31 -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=DGutIzaA9ITGWTcxLHLhyXW8cF+A8zE0rUS/XUjLgTc=; b=S9cPKxc5FQze7EkwM2YghVTcN5R2NSYsHwmiLfj373NMKBJF4wqbUQhMZ7zRiknjt2 k8UvH8tKsM7DD/gplWclsMEW5qslpIVAVYGO9IBBgLusYn8qMk2bax3FK7l/LboXWt7O 4C1ked1zOWuKMSkv8GyPUnA4arGwkMV2ISAzKfj/cIiVGlBsf+ADorMzZt/owgKvkiU6 BBDnllR7yBc2ppITB0eGc80kqFBpfdMGqKp7Bw/4OO19X3w49E9GaFA1oCvJ5RsF6KPQ szItDldnriV4FFZODqMf31LPQhtrjklrWGlpvIggU/PWwvIB4lHtH75rbrYx81Y8wpv4 oZ4A== Received: by 10.50.140.38 with SMTP id rd6mr1660940igb.0.1350482071074; Wed, 17 Oct 2012 06:54:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.113 with HTTP; Wed, 17 Oct 2012 06:54:09 -0700 (PDT) In-Reply-To: References: <20121017133633.GB13587@pfrc> From: Donald Eastlake Date: Wed, 17 Oct 2012 09:54:09 -0400 Message-ID: Subject: Re: [IANA #608024] EUI-48 request To: Jeffrey Haas Content-Type: text/plain; charset=ISO-8859-1 Cc: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 13:54:32 -0000 Sorry for the typo, that's 01-00-5E-90-00-01. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com ---------- Forwarded message ---------- From: Donald Eastlake Date: Wed, Oct 17, 2012 at 9:42 AM Subject: Re: [IANA #608024] EUI-48 request To: Jeffrey Haas Cc: rtg-bfd@ietf.org Note that such values are pre-fixed by the IANA OUI with the multicast bit turned on or off depending on whether the address is multicast. So the MAC address in this case is really 01-00-05-90-00-01. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, Oct 17, 2012 at 9:36 AM, Jeffrey Haas wrote: > Begin forwarded message: > >> From: Amanda Baber via RT >> Subject: [IANA #608024] EUI-48 request >> Date: October 16, 2012 11:23:01 PM EDT >> >> Hi Jeff, >> >> We've assigned the following IANA Multicast 48-bit MAC Address (by the >> way, the IANA Considerations section needs to mention, as section 2.3 >> does, that this is a dedicated multicast address) with your draft as a >> reference: >> >> 90-00-01 >> Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) >> Interfaces >> [draft-mmm-bfd-on-lags] >> >> Please see >> http://www.iana.org/assignments/ethernet-numbers/ >> >> thanks, >> >> Amanda Baber >> ICANN/IANA >> From internet-drafts@ietf.org Thu Oct 18 22:58:53 2012 Return-Path: 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 B190821F8562; Thu, 18 Oct 2012 22:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, 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 bvMxvMlE5nMo; Thu, 18 Oct 2012 22:58:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD23021F8491; Thu, 18 Oct 2012 22:58:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-generic-crypto-auth-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121019055852.12100.90506.idtracker@ietfa.amsl.com> Date: Thu, 18 Oct 2012 22:58:52 -0700 Cc: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 05:58:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : BFD Generic Cryptographic Authentication Author(s) : Manav Bhatia Vishwas Manral Dacheng Zhang Filename : draft-ietf-bfd-generic-crypto-auth-03.txt Pages : 12 Date : 2012-10-18 Abstract: This document proposes an extension to Bidirectional Forwarding Detection (BFD) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes described in the base specification. This document adds the basic infrastructure that is required for supporting algorithm and key agility for BFD. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-generic-crypto-auth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-generic-crypto-auth-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-generic-crypto-auth-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Oct 18 23:10:58 2012 Return-Path: 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 A2A8A21F8622; Thu, 18 Oct 2012 23:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 b0qlPuRfDlOX; Thu, 18 Oct 2012 23:10:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7C121F85FD; Thu, 18 Oct 2012 23:10:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-hmac-sha-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121019061058.10145.62861.idtracker@ietfa.amsl.com> Date: Thu, 18 Oct 2012 23:10:58 -0700 Cc: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 06:10:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : Authenticating BFD using HMAC-SHA-2 procedures Author(s) : Dacheng Zhang Manav Bhatia Vishwas Manral Filename : draft-ietf-bfd-hmac-sha-02.txt Pages : 10 Date : 2012-10-18 Abstract: This document describes the mechanism to authenticate Bidirectional Forwarding Detection (BFD) protocol packets using Hashed Message Authentication Mode (HMAC) with the SHA-256, SHA-384, and SHA-512 algorithms. The described mechanism uses the Generic Cryptographic Authentication and Generic Meticulous Cryptographic Authentication sections to carry the authentication data. This document updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 5880. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-hmac-sha There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-hmac-sha-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-hmac-sha-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From he@uninett.no Tue Oct 30 02:31:08 2012 Return-Path: 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 3C03221F84C8 for ; Tue, 30 Oct 2012 02:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[AWL=1.454, BAYES_00=-2.599] 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 4Ce-IGjGTyQf for ; Tue, 30 Oct 2012 02:31:07 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id 64E5D21F84C7 for ; Tue, 30 Oct 2012 02:31:05 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id E12303D0B4 for ; Tue, 30 Oct 2012 10:31:01 +0100 (CET) Date: Tue, 30 Oct 2012 10:31:01 +0100 (CET) Message-Id: <20121030.103101.409931545.he@uninett.no> To: rtg-bfd@ietf.org Subject: Monitoring BFD sessions From: Havard Eidnes X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 09:31:08 -0000 Hi, I'm maintaining a small software package we use to monitor certain aspects of our network, and among them I'm monitoring BFD session states, using a couple of vendors' interim versions of the BFD MIB (implanted in their own enterprises tree for the time being). With one of the vendors I'm observing strange behaviour, in that almost every time a BFD session goes through an operational down->up state transition (after first going through an up->down state transition), the implementation chooses a new BFD discriminator for the session. Furthermore, it looks as if the vendor is using the value of the local discriminator when forming the bfdSessIndex value in the MIB. Thus, what my management software sees is that the old BFD session is removed from the bfdSessTable, and a new entry is instead created when the session gets reestablished. I have tried to point out to the vendor that this makes it extremely difficult to track the state of the BFD sessions through the administrative lifetime of the sessions, in particular to automatically measure the downtime duration for the sessions, and have the "red" alarms for the downed BFD sessions automatically go "green" when the session gets re-established. The vendor in question (who shall reman nameless for the time being), hides behind this clause in the BFD specification (RFC 5880, section 6.3) to defend the current behaviour: Note that it is permissible for a system to change its discriminator= during a session without affecting the session state, since only tha= t system uses its discriminator for demultiplexing purposes (by having= the other system reflect it back). The implications on an implementation for changing the discriminator value is outside the scope of this specification. So my questions here are twofold: 1) Is there a problem with the specifications as written that allows an implementor to (in my opinion) totally de-value the usefulness of the bfdSessTable? or 2) Is the implementor in question defending unreasonable behaviour which instead belongs in the "implementation bug" category? Best regards, - H=E5vard From marc@sniff.de Tue Oct 30 07:15:32 2012 Return-Path: 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 A3B1221F8542 for ; Tue, 30 Oct 2012 07:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 poSWZK48j3vX for ; Tue, 30 Oct 2012 07:15:32 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A34C21F853B for ; Tue, 30 Oct 2012 07:15:31 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 198362AA0F; Tue, 30 Oct 2012 14:15:28 +0000 (GMT) Subject: Re: Monitoring BFD sessions Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Marc Binderberger In-Reply-To: <20121030.103101.409931545.he@uninett.no> Date: Tue, 30 Oct 2012 15:15:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121030.103101.409931545.he@uninett.no> To: Havard Eidnes X-Mailer: Apple Mail (2.1084) Cc: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 14:15:32 -0000 Hello Havard, > So my questions here are twofold: >=20 > 1) Is there a problem with the specifications as written that > allows an implementor to (in my opinion) totally de-value the > usefulness of the bfdSessTable? > or >=20 > 2) Is the implementor in question defending unreasonable > behaviour which instead belongs in the "implementation bug" > category? I think neither nor. The discriminator can change, so it's not a "good = number" to be used when tracking the BFD session over a long time. The information that should be the same for the same session is likely = something as [interface, dest-ip-addr]. This uniquely defines your = session. Regards, Marc On 2012-10-30, at 10:31 , Havard Eidnes wrote: > Hi, >=20 > I'm maintaining a small software package we use to monitor > certain aspects of our network, and among them I'm monitoring BFD > session states, using a couple of vendors' interim versions of > the BFD MIB (implanted in their own enterprises tree for the time > being). >=20 > With one of the vendors I'm observing strange behaviour, in that > almost every time a BFD session goes through an operational > down->up state transition (after first going through an up->down > state transition), the implementation chooses a new BFD > discriminator for the session. >=20 > Furthermore, it looks as if the vendor is using the value of the > local discriminator when forming the bfdSessIndex value in the > MIB. >=20 > Thus, what my management software sees is that the old BFD > session is removed from the bfdSessTable, and a new entry is > instead created when the session gets reestablished. >=20 > I have tried to point out to the vendor that this makes it > extremely difficult to track the state of the BFD sessions > through the administrative lifetime of the sessions, in > particular to automatically measure the downtime duration for the > sessions, and have the "red" alarms for the downed BFD sessions > automatically go "green" when the session gets re-established. > The vendor in question (who shall reman nameless for the time > being), hides behind this clause in the BFD specification (RFC > 5880, section 6.3) to defend the current behaviour: >=20 > Note that it is permissible for a system to change its discriminator > during a session without affecting the session state, since only = that > system uses its discriminator for demultiplexing purposes (by having > the other system reflect it back). The implications on an > implementation for changing the discriminator value is outside the > scope of this specification. >=20 > So my questions here are twofold: >=20 > 1) Is there a problem with the specifications as written that > allows an implementor to (in my opinion) totally de-value the > usefulness of the bfdSessTable? > or >=20 > 2) Is the implementor in question defending unreasonable > behaviour which instead belongs in the "implementation bug" > category? >=20 > Best regards, >=20 > - H=E5vard >=20 -- Marc Binderberger From iesg-secretary@ietf.org Tue Oct 30 08:46:26 2012 Return-Path: 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 8618921F85E6; Tue, 30 Oct 2012 08:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, 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 METBMO7zgH-p; Tue, 30 Oct 2012 08:46:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E252221F85F4; Tue, 30 Oct 2012 08:46:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121030154625.13482.31090.idtracker@ietfa.amsl.com> Date: Tue, 30 Oct 2012 08:46:25 -0700 Cc: bfd WG X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 15:46:26 -0000 The Bidirectional Forwarding Detection (bfd) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Bidirectional Forwarding Detection (bfd) ------------------------------------------------ Current Status: Active Working Group Chairs: David Ward Jeffrey Haas Technical advisors: Dave Katz Assigned Area Director: Adrian Farrel Mailing list Address: rtg-bfd@ietf.org To Subscribe: rtg-bfd-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ Charter of Working Group: The BFD Working Group is chartered to standardize and support the bidirectional forwarding detection protocol (BFD) and its extensions. A core goal of the working group is to standardize BFD in the context of IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. The Working Group will also provide advice and guidance on BFD to other working groups or standards bodies as requested. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware. - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course). - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. The working group is chartered to complete the following work items: 1. Develop the MIB module for BFD and submit it to the IESG for publication as a Proposed Standard. 2a. Provide a generic keying-based cryptographic authentication mechanism for the BFD protocol in discussion with the KARP working group. This mechanism will support authentication through a key identifier for the BFD session's Security Association rather than specifying new authentication extensions. 2b. Provide extensions to the BFD MIB in support of the generic keying-based cryptographic authentication mechanism. 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value) using the generic keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks. 4. Assist the MPLS working group in the standardization of the BFD protocol for MPLS-TP. The preferred solution will be interoperable with the current BFD specification. 5. Provide one or more mechanisms to run BFD over Link Aggregation Group Interfaces. The working group will maintain a relationship with the KARP and MPLS working groups, and will communicate with the IEEE with respect to BFD over LAGs. Milestones: Done - Submit the base protocol specification to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for MPLS LSPs to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Sep 2011 - Submit the BFD MIB to the IESG to be considered as a Proposed Standard Dec 2011 - Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard Dec 2011 - Submit a BFD MIB extension in support of the generic keying document to the IESG to be considered as a Proposed Standard Dec 2011 - Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard Mar 2012 - Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard Jun 2012 - Submit the bootstrapping mechanism for BFD using DHCP to the IESG to be considered as a Proposed Standard