From marc@sniff.de Fri Nov 1 01:28:46 2013 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 B1AE511E8127 for ; Fri, 1 Nov 2013 01:28:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01dWk0oEMc6u for ; Fri, 1 Nov 2013 01:28:46 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BA311E80E6 for ; Fri, 1 Nov 2013 01:28:45 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 79A642AA0F; Fri, 1 Nov 2013 08:28:41 +0000 (GMT) Date: Fri, 1 Nov 2013 01:28:40 -0700 From: Marc Binderberger To: Mahesh Jethanandani Message-ID: <20131101012840441464.ae114f50@sniff.de> In-Reply-To: <931B5B03-5578-428D-BA5B-F3311E31305B@gmail.com> References: <20131024191431.GO17538@pfrc> <315041E4211CB84E86EF7C25A2AB583D337EBFB3@xmb-rcd-x15.cisco.com> <425296D4-F96F-49FF-86D2-40737B64E117@gmail.com> <20211F91F544D247976D84C5D778A4C32E4EEE0D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <931B5B03-5578-428D-BA5B-F3311E31305B@gmail.com> Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.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: Fri, 01 Nov 2013 08:28:46 -0000 Hello Mahesh, > What is wrong with being more clear? what you propose isn't more clear. And no, there is no specific meaning for "interface information" outside a specific implementation. I.e. it's implementation specific, which is why we are not trying to say more - we would get it wrong for the N+1 implementation (we hardly can know them all :-) As I said, nothing wrong asking question and the answer is it is a generic "interface information" tat identifies the particular interface. To say more is already wrong for the specification. Even if your system uses ifindex (or whatever name an interface identifier number has in your implementation) then, as you mentioned, it doesn't mean the APIs provide this information. Which means an implementation for this draft knows the "interface" in a different way. And again I cannot specify what "different way" means, as this would be just one example I have in my mind. The wording has been chosen very carefully ... . Regards, Marc On Thu, 31 Oct 2013 23:10:10 -0700, Mahesh Jethanandani wrote: > Marc, > > I do not know about you, but when I read interface there are specific > implications in my mind of what it means. To a certain extent I can > see that is in this response from Manav. It means something very > specific. > > On Oct 27, 2013, at 4:37 AM, Bhatia, Manav (Manav) wrote: > >> Can you explain the scenario where you think its not possible for a >> system to know the ifindex of the IP interface over which an >> incoming packet arrived? > > My point is that if you believe that by "interface information" you > do not necessarily mean the interface (ifIndex) itself or that it is > a fairly generic reference to an identification of a member link of > LAG, then just say so. Or better still, say what it should mean. What > is wrong with being more clear? If I mis-read what was meant, so will > others. > > Cheers. > > Mahesh Jethanandani > mjethanandani@gmail.com > > > From manav.bhatia@alcatel-lucent.com Fri Nov 1 03:58:54 2013 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 47E0911E820D for ; Fri, 1 Nov 2013 03:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWKg1fxZZ9xb for ; Fri, 1 Nov 2013 03:58:33 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0786511E8211 for ; Fri, 1 Nov 2013 03:58:29 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rA1AwOUr013967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Nov 2013 05:58:24 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id rA1AwNbw013591 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Nov 2013 06:58:23 -0400 Received: from SG70YWXCHHUB03.zap.alcatel-lucent.com (135.253.2.37) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 1 Nov 2013 06:58:23 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.83]) by SG70YWXCHHUB03.zap.alcatel-lucent.com ([135.253.2.37]) with mapi id 14.02.0328.009; Fri, 1 Nov 2013 18:58:20 +0800 From: "Bhatia, Manav (Manav)" To: Mahesh Jethanandani , Marc Binderberger Subject: RE: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Topic: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Index: AQHO0Z+DNFj/MU8qmUKBYON0YuBEtZoIbKoAgAb8BACAAI+C8A== Date: Fri, 1 Nov 2013 10:58:19 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E4F4E0A@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20131024191431.GO17538@pfrc> <315041E4211CB84E86EF7C25A2AB583D337EBFB3@xmb-rcd-x15.cisco.com> <425296D4-F96F-49FF-86D2-40737B64E117@gmail.com> <20211F91F544D247976D84C5D778A4C32E4EEE0D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <931B5B03-5578-428D-BA5B-F3311E31305B@gmail.com> In-Reply-To: <931B5B03-5578-428D-BA5B-F3311E31305B@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.17] 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: Fri, 01 Nov 2013 10:58:54 -0000 Hi Mahesh, > I do not know about you, but when I read interface there are specific > implications in my mind of what it means. To a certain extent I can see > that is in this response from Manav. It means something very specific. >=20 > On Oct 27, 2013, at 4:37 AM, Bhatia, Manav (Manav) wrote: >=20 > > Can you explain the scenario where you think its not possible for a > system to know the ifindex of the IP interface over which an incoming > packet arrived? I had given a general comment in response to your email where you had said = that its not possible for systems to be aware of the interface a control pa= cket arrives on. This draft *never* talks about the ifindex. All we're saying is that when y= ou get a uBFD packet you should somehow know which interface and member por= t of the LAG the packet arrived on. How you do that is an implementation sp= ecific issue and will NEVER affect interoperability.=20 I don't understand why we're discussing an implementation specific issue th= at has no bearing on interoperability. >=20 > My point is that if you believe that by "interface information" you do > not necessarily mean the interface (ifIndex) itself or that it is a > fairly generic reference to an identification of a member link of LAG, > then just say so. Or better still, say what it should mean. What is Can you point to the text in the draft that gives you the impression that w= e are talking about an "ifIndex"?=20 Cheers, Manav > wrong with being more clear? If I mis-read what was meant, so will > others. >=20 > Cheers. >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 From mishra.ashesh@outlook.com Fri Nov 1 11:59:00 2013 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 3E6C211E81C6 for ; Fri, 1 Nov 2013 11:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwgE7rphjPAR for ; Fri, 1 Nov 2013 11:58:54 -0700 (PDT) Received: from bay0-omc4-s4.bay0.hotmail.com (bay0-omc4-s4.bay0.hotmail.com [65.54.190.206]) by ietfa.amsl.com (Postfix) with ESMTP id 7951A11E819D for ; Fri, 1 Nov 2013 11:58:54 -0700 (PDT) Received: from BAY176-W32 ([65.54.190.201]) by bay0-omc4-s4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Nov 2013 11:58:54 -0700 X-TMN: [1Bx6tTfspZl8vrq8nMEpmquift6uH0ZC] X-Originating-Email: [mishra.ashesh@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_143a8097-0981-4a66-9de4-4f3bb406b374_" From: Ashesh Mishra To: "rtg-bfd@ietf.org" Subject: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Date: Fri, 1 Nov 2013 11:58:54 -0700 Importance: Normal In-Reply-To: <20131101012840441464.ae114f50@sniff.de> References: <20131024191431.GO17538@pfrc>, <315041E4211CB84E86EF7C25A2AB583D337EBFB3@xmb-rcd-x15.cisco.com>, <425296D4-F96F-49FF-86D2-40737B64E117@gmail.com>, <20211F91F544D247976D84C5D778A4C32E4EEE0D@SG70YWXCHMBA05.zap.alcatel-lucent.com>, <931B5B03-5578-428D-BA5B-F3311E31305B@gmail.com>, <20131101012840441464.ae114f50@sniff.de> MIME-Version: 1.0 X-OriginalArrivalTime: 01 Nov 2013 18:58:54.0487 (UTC) FILETIME=[69473A70:01CED734] 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, 01 Nov 2013 18:59:00 -0000 --_143a8097-0981-4a66-9de4-4f3bb406b374_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all=2C Does the mechanism proposed in this draft suggest that the transmitting end= will multicast the BFD CC frames over the LAG and the receiving end will h= ave a Rx session for every member of the LAG? If so=2C how will the session negotiation work with more than one endpoint = on the peer node? -- Ashesh = --_143a8097-0981-4a66-9de4-4f3bb406b374_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all=2C

Does the mechan= ism proposed in this draft suggest that the transmitting end will multicast= the BFD CC frames over the LAG and the receiving end will have a Rx sessio= n for every member of the LAG?

If so=2C how will the session negotia= tion work with more than one endpoint on the peer node?

--
Ashesh=
= --_143a8097-0981-4a66-9de4-4f3bb406b374_-- From marc@sniff.de Fri Nov 1 13:29:15 2013 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 9F75411E813D for ; Fri, 1 Nov 2013 13:29:15 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCSHD9FYkoNg for ; Fri, 1 Nov 2013 13:29:15 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB2711E8131 for ; Fri, 1 Nov 2013 13:29:15 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id E28CF2AA0F; Fri, 1 Nov 2013 20:29:12 +0000 (GMT) Date: Fri, 1 Nov 2013 13:29:13 -0700 From: Marc Binderberger To: Ashesh Mishra Message-ID: <20131101132913173633.325d6feb@sniff.de> In-Reply-To: References: <20131024191431.GO17538@pfrc> <315041E4211CB84E86EF7C25A2AB583D337EBFB3@xmb-rcd-x15.cisco.com> <425296D4-F96F-49FF-86D2-40737B64E117@gmail.com> <20211F91F544D247976D84C5D778A4C32E4EEE0D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <931B5B03-5578-428D-BA5B-F3311E31305B@gmail.com> <20131101012840441464.ae114f50@sniff.de> Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.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: Fri, 01 Nov 2013 20:29:15 -0000 Hello Ashesh, > the receiving end will have a Rx session for every member of the LAG? Yes. You have a sending and a receiving session per LAG member link. > If so, how will the session negotiation work with more than one > endpoint on the peer node? section 2.2 explains it. Here the part for starting the session: The demultiplexing of a received BFD packet is solely based on the Your Discriminator field, if this field is nonzero. For the initial Down BFD packets of a BFD session this value MAY be zero. In this case demultiplexing MUST be based on some combination of other fields which MUST include the interface information of the member link. In other words your implementation "binds" a particular Rx/Tx session to one member interface (I use quotation marks to indicate the details are up to your implementation). Regards, Marc On Fri, 1 Nov 2013 11:58:54 -0700, Ashesh Mishra wrote: > Hi all, > > Does the mechanism proposed in this draft suggest that the > transmitting end will multicast the BFD CC frames over the LAG and > the receiving end will have a Rx session for every member of the LAG? > > If so, how will the session negotiation work with more than one > endpoint on the peer node? > > -- > Ashesh From mishra.ashesh@outlook.com Fri Nov 1 13:49:25 2013 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 62E7111E816D for ; Fri, 1 Nov 2013 13:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOVVHw+ZuZBp for ; Fri, 1 Nov 2013 13:49:19 -0700 (PDT) Received: from bay0-omc2-s8.bay0.hotmail.com (bay0-omc2-s8.bay0.hotmail.com [65.54.190.83]) by ietfa.amsl.com (Postfix) with ESMTP id 6960211E8179 for ; Fri, 1 Nov 2013 13:49:19 -0700 (PDT) Received: from BAY176-W48 ([65.54.190.124]) by bay0-omc2-s8.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Nov 2013 13:49:18 -0700 X-TMN: [MtWKwslFZuKDzTSopIhUT/vSd23G7tYX] X-Originating-Email: [mishra.ashesh@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_61627170-bac2-4dde-99b1-4dffd450c73e_" From: Ashesh Mishra To: Marc Binderberger Subject: RE: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Date: Fri, 1 Nov 2013 13:49:18 -0700 Importance: Normal In-Reply-To: <20131101132913173633.325d6feb@sniff.de> References: <20131024191431.GO17538@pfrc>, <315041E4211CB84E86EF7C25A2AB583D337EBFB3@xmb-rcd-x15.cisco.com>, <425296D4-F96F-49FF-86D2-40737B64E117@gmail.com>, <20211F91F544D247976D84C5D778A4C32E4EEE0D@SG70YWXCHMBA05.zap.alcatel-lucent.com>, <931B5B03-5578-428D-BA5B-F3311E31305B@gmail.com>, <20131101012840441464.ae114f50@sniff.de>, , <20131101132913173633.325d6feb@sniff.de> MIME-Version: 1.0 X-OriginalArrivalTime: 01 Nov 2013 20:49:18.0839 (UTC) FILETIME=[D5B32070:01CED743] 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, 01 Nov 2013 20:49:25 -0000 --_61627170-bac2-4dde-99b1-4dffd450c73e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Marc. Having individual Tx/Rx pair for each member link does make th= e implementation simpler!=20 Regards=2C Ashesh > Date: Fri=2C 1 Nov 2013 13:29:13 -0700 > From: marc@sniff.de > To: mishra.ashesh@outlook.com > CC: rtg-bfd@ietf.org > Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends Nov= ember 8 >=20 > Hello Ashesh=2C >=20 > > the receiving end will have a Rx session for every member of the LAG? >=20 > Yes. You have a sending and a receiving session per LAG member link. >=20 > > If so=2C how will the session negotiation work with more than one=20 > > endpoint on the peer node? >=20 > section 2.2 explains it. Here the part for starting the session: >=20 > The demultiplexing of a received BFD packet is solely based on the > Your Discriminator field=2C if this field is nonzero. For the initial > Down BFD packets of a BFD session this value MAY be zero. In this > case demultiplexing MUST be based on some combination of other fields > which MUST include the interface information of the member link. >=20 >=20 > In other words your implementation "binds" a particular Rx/Tx session=20 > to one member interface (I use quotation marks to indicate the details=20 > are up to your implementation). >=20 >=20 > Regards=2C Marc >=20 >=20 >=20 > On Fri=2C 1 Nov 2013 11:58:54 -0700=2C Ashesh Mishra wrote: > > Hi all=2C > >=20 > > Does the mechanism proposed in this draft suggest that the=20 > > transmitting end will multicast the BFD CC frames over the LAG and=20 > > the receiving end will have a Rx session for every member of the LAG? > >=20 > > If so=2C how will the session negotiation work with more than one=20 > > endpoint on the peer node? > >=20 > > -- > > Ashesh = --_61627170-bac2-4dde-99b1-4dffd450c73e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks Marc. Having individual T= x/Rx pair for each member link does make the implementation simpler!
Regards=2C
Ashesh

>=3B Date: Fri=2C 1 Nov 2013 13:29:13 = -0700
>=3B From: marc@sniff.de
>=3B To: mishra.ashesh@outlook.com=
>=3B CC: rtg-bfd@ietf.org
>=3B Subject: Re: WGLC for BFD over Li= nk Aggregate Group Interfaces - ends November 8
>=3B
>=3B Hello = Ashesh=2C
>=3B
>=3B >=3B the receiving end will have a Rx sess= ion for every member of the LAG?
>=3B
>=3B Yes. You have a sendi= ng and a receiving session per LAG member link.
>=3B
>=3B >=3B= If so=2C how will the session negotiation work with more than one
>= =3B >=3B endpoint on the peer node?
>=3B
>=3B section 2.2 expl= ains it. Here the part for starting the session:
>=3B
>=3B Th= e demultiplexing of a received BFD packet is solely based on the
>=3B = Your Discriminator field=2C if this field is nonzero. For the initial>=3B Down BFD packets of a BFD session this value MAY be zero. In t= his
>=3B case demultiplexing MUST be based on some combination of o= ther fields
>=3B which MUST include the interface information of th= e member link.
>=3B
>=3B
>=3B In other words your implemen= tation "binds" a particular Rx/Tx session
>=3B to one member interfac= e (I use quotation marks to indicate the details
>=3B are up to your = implementation).
>=3B
>=3B
>=3B Regards=2C Marc
>=3B =
>=3B
>=3B
>=3B On Fri=2C 1 Nov 2013 11:58:54 -0700=2C Ash= esh Mishra wrote:
>=3B >=3B Hi all=2C
>=3B >=3B
>=3B &g= t=3B Does the mechanism proposed in this draft suggest that the
>=3B = >=3B transmitting end will multicast the BFD CC frames over the LAG and <= br>>=3B >=3B the receiving end will have a Rx session for every member = of the LAG?
>=3B >=3B
>=3B >=3B If so=2C how will the sessio= n negotiation work with more than one
>=3B >=3B endpoint on the pee= r node?
>=3B >=3B
>=3B >=3B --
>=3B >=3B Ashesh
= --_61627170-bac2-4dde-99b1-4dffd450c73e_-- From jhaas@slice.pfrc.org Sun Nov 3 13:02:20 2013 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 9050211E818E for ; Sun, 3 Nov 2013 13:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.246 X-Spam-Level: X-Spam-Status: No, score=-102.246 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgiMlQEwAokO for ; Sun, 3 Nov 2013 13:02:15 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4E13411E8170 for ; Sun, 3 Nov 2013 13:02:15 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id D94D1C385; Sun, 3 Nov 2013 16:02:14 -0500 (EST) Date: Sun, 3 Nov 2013 16:02:14 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: IETF 88 minutes taker and jabber scribe wanted Message-ID: <20131103210214.GA18608@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: Sun, 03 Nov 2013 21:02:20 -0000 We need someone to volunteer to be a minutes taker and another to be jabber scribe for tomorrow's session. We're also happy to have the minutes crowd sourced via etherpad: http://tools.ietf.org/wg/bfd/minutes -- Jeff From nobo@cisco.com Thu Nov 7 07:26:06 2013 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 5A4F521E80AD for ; Thu, 7 Nov 2013 07:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wysKVT3N0rnL for ; Thu, 7 Nov 2013 07:25:57 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C623E11E8102 for ; Thu, 7 Nov 2013 07:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3351; q=dns/txt; s=iport; t=1383837957; x=1385047557; h=from:to:cc:subject:date:message-id:mime-version; bh=+jgDDsjmMYJrSoBmYvs8mLlz0a6JWrf8zOcal6uSA/A=; b=VdABgh4iXKed5Ig7VAumzWNS1068udqpYzuNaPYnYfBR5r2focAkgEEV xSnH+niB5ET8TMEGWmXFpeVNUG8PkVm20Ymt8j0j+Mqfqut3iEHACcJIa KsF4h/2IR5qmadhmCBqYoSj5EBETiOVSRG4ZM33iZ0XLRcbE8LMd+yRrT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAOSve1KtJV2a/2dsb2JhbABbgkMjIThTvw6BJRZ0gicBBC1MEgEMHlYmAQQODYd5Ab09jygxgyeBEAOqFoMmgio X-IronPort-AV: E=Sophos;i="4.93,652,1378857600"; d="scan'208,217";a="281954434" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 07 Nov 2013 15:25:57 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA7FPvxZ008835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 15:25:57 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 09:25:56 -0600 From: "Nobo Akiya (nobo)" To: "Gregory Mirsky (gregory.mirsky@ericsson.com)" Subject: S-BFD use-case draft Thread-Topic: S-BFD use-case draft Thread-Index: Ac7ai3ZYj7PvsXCwTrivaS4/TDtA1w== Date: Thu, 7 Nov 2013 15:25:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.64.245] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941DEDE7CFxmbalnx01ciscoc_" MIME-Version: 1.0 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, 07 Nov 2013 15:26:06 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941DEDE7CFxmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, One of your comment at IETF88 was pointing out the need for S-BFD use-case = draft. You are absolutely right, having a use-case draft will definitely help clar= ify where S-BFD fits in. We will work on this. And many thanks for valuable comments. -Nobo (on behalf of S-BFD authors/contributors) --_000_CECE764681BE964CBE1DFF78F3CDD3941DEDE7CFxmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

One of your comment at IETF88 was pointing out the n= eed for S-BFD use-case draft.

You are absolutely right, having a use-case draft wi= ll definitely help clarify where S-BFD fits in.

 

We will work on this.

 

And many thanks for valuable comments.

 

-Nobo

(on behalf of S-BFD authors/contributors)=

 

--_000_CECE764681BE964CBE1DFF78F3CDD3941DEDE7CFxmbalnx01ciscoc_-- From manav.bhatia@alcatel-lucent.com Thu Nov 7 08:49:52 2013 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 5F2B921E812B for ; Thu, 7 Nov 2013 08:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNUMtOPw9IFL for ; Thu, 7 Nov 2013 08:49:39 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 88A2221E8158 for ; Thu, 7 Nov 2013 08:48:54 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rA7GmpMg006016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 7 Nov 2013 10:48:52 -0600 (CST) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id rA7GmpWP030779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 7 Nov 2013 11:48:51 -0500 Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 7 Nov 2013 11:48:51 -0500 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.83]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.02.0247.003; Fri, 8 Nov 2013 00:48:48 +0800 From: "Bhatia, Manav (Manav)" To: "rtg-bfd@ietf.org" Subject: Security aspects with S-BFD Thread-Topic: Security aspects with S-BFD Thread-Index: Ac7b2ToBrFn7tnaZR4yTSVGAJsb+Gw== Date: Thu, 7 Nov 2013 16:48:47 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E4FACB1@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] 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 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, 07 Nov 2013 16:49:52 -0000 Hi, S-BFD describes the reflector sessions which raises interesting security co= nsiderations. Since the reflector sessions are stateless (that's one of the biggest advan= tages) it's impossible for the reflector to keep track of the sequence numb= er that its heard from its peers. This means, that the reflector is suscept= ible to both inter-session and intra-session replay attacks. We had a discu= ssion internally amongst the co-authors and had the following proposal that= we wanted to vet before the WG members. Would like to hear the WGs opinion on this. 1. The Initiator picks up a crypto sequence number depending upon the authe= ntication mode that its using (meticulous or non meticulous). It sends a pa= cket to the Reflector with this seq num. 2. The reflector maintains no session state and hence does not look at the = crypto sequence number before accepting the packet. It looks at the Key ID = (draft-ietf-bfd-generic-crypto-auth-05) in the incoming packet (or it can d= o it based on its own database where it maps the neighbor to the key iD) an= d verifies the authentication data. If everything looks good, it processes = the packet.=20 3. When responding the Reflector needs to compute the Authentication data. = It uses the same sequence number that it received in the S-BFD packet that = it is responding to. It knows the Key ID, and thus the SA. It computes the = authentication data and sends the S-BFD packet out. 4. The Initiator receives the response from the Reflector. It only accepts = the S-BFD packet if it either comes with the same sequence number as it had= sent or its within the window that it finds acceptable (described in detai= l in Sec 3.4 of draft-ietf-bfd-generic-crypto-auth-05) Benefits of this scheme. 1. Reflectors continue to remain stateless despite using security. 2. Reflectors are not susceptible to replay attacks as they always respond = to S-BFD packets irrespective of the sequence number carried. 3. An attacker cannot forge packets from the Reflector since the Initiator = will only accept S-BFD packets that come with the sequence number that it h= ad originally used when sending the S-BFD packet. Drawbacks of this scheme. 1. Reflectors are susceptible to DoS attacks since they respond to all inco= ming S-BFD packets. This gets worse when cryptography is used as the work l= oad drastically increases as security is employed. Cheers, Manav From glen.kent@gmail.com Thu Nov 7 08:54:09 2013 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 C75AC21E8121 for ; Thu, 7 Nov 2013 08:54:09 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCbch3IuAbYF for ; Thu, 7 Nov 2013 08:54:09 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id F3B2321E8149 for ; Thu, 7 Nov 2013 08:52:40 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id wp18so319268obc.27 for ; Thu, 07 Nov 2013 08:52:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EfKLjmeyDaqcX0KUdh3VhmQrYr+lAWpd9QsIgH122Ew=; b=XykXwiGLMcgnEdVlLYr0u1Rg34eKPEc6okh7veVTclsg94JrX14ITSUVNDiuIdgH8O g06lYa2gi4jyUEJa8Qg9V/buE7V4hdpjpWtZoR8OBe931EvKBW5Imz3S2ACW3l1keCNV azZ/z0H7aXhmw9JBPw96zqaKUSj6ugwtsRDvu8UKJs4H6piOk6J7YYUbBaFaiS8WwCWr L7qdTMH6fRBLszZVunHxpThnEaWjfACEvJ+JXeXg0CtC7KMfiIGwNQ40v99FNXUd0nA3 HU4CozTlGdpeO4k4gPaGaK9aUxABB7b/TvevWS/uv6+XOWlt9wR2gWX00JEYvFhA8jYN WT+Q== MIME-Version: 1.0 X-Received: by 10.182.24.69 with SMTP id s5mr737249obf.35.1383843156630; Thu, 07 Nov 2013 08:52:36 -0800 (PST) Received: by 10.182.23.36 with HTTP; Thu, 7 Nov 2013 08:52:36 -0800 (PST) In-Reply-To: <20131024191431.GO17538@pfrc> References: <20131024191431.GO17538@pfrc> Date: Thu, 7 Nov 2013 22:22:36 +0530 Message-ID: Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 From: Glen Kent To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a11c2a20cc6a1ee04ea9917ab 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, 07 Nov 2013 16:54:09 -0000 --001a11c2a20cc6a1ee04ea9917ab Content-Type: text/plain; charset=ISO-8859-1 Support. Glen On Fri, Oct 25, 2013 at 12:44 AM, Jeffrey Haas wrote: > This email is to initiate working group last call on the BFD on Link > Aggregate Group Interfaces document: > > http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 > > The last call will complete on November 8, the end of IETF week. Time will > be available during the Vancouver IETF BFD session to discuss last call > comments. > > Nobo Akiya will be serving as document shepherd (RFC 4858) for this WGLC. > > Due to the small nature of the BFD working group and the fact that both > working group chairs have contributed to this document, we have gotten > Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as an > independent party to gauge working group consensus. > > In order to facilitate the transparency of this WGLC, please remember to > send all comments to the working group mailing list. > > IPR declarations have been filed against this draft and the document > authors > and contributors have been polled for any further IPR. Current IPR > declarations may be seen at the following link: > > > http://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-ietf-bfd-on-lags > > If you are aware of additional IPR against this document please declare > so, per > the IETF Note Well. > > Finally, the IEEE has expressed interest in the disposition of this draft. > They will likely provide additional commentary, if any, via the IETF > liaison > process. This process will likely happen after WGLC concludes. Depending > on their feedback, WGLC may re-open to address their concerns. > > -- Jeff (for the chairs) > --001a11c2a20cc6a1ee04ea9917ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support.

Glen


On Fri, Oct 25, 2013 at 12:44 AM,= Jeffrey Haas <jhaas@pfrc.org> wrote:
This email is to initiate working group last= call on the BFD on Link
Aggregate Group Interfaces document:

http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01

The last call will complete on November 8, the end of IETF week. =A0Time wi= ll
be available during the Vancouver IETF BFD session to discuss last call
comments.

Nobo Akiya will be serving as document shepherd (RFC 4858) for this WGLC.
Due to the small nature of the BFD working group and the fact that both
working group chairs have contributed to this document, we have gotten
Carlos Pignataro (cpignata@cisco.com<= /a>) to volunteer to serve as an
independent party to gauge working group consensus.

In order to facilitate the transparency of this WGLC, please remember to send all comments to the working group mailing list.

IPR declarations have been filed against this draft and the document author= s
and contributors have been polled for any further IPR. =A0Current IPR
declarations may be seen at the following link:

http://datatracker.ietf= .org/ipr/search/?option=3Ddocument_search&id=3Ddraft-ietf-bfd-on-lags

If you are aware of additional IPR against this document please declare so,= per
the IETF Note Well.

Finally, the IEEE has expressed interest in the disposition of this draft.<= br> They will likely provide additional commentary, if any, via the IETF liaiso= n
process. =A0This process will likely happen after WGLC concludes. =A0Depend= ing
on their feedback, WGLC may re-open to address their concerns.

-- Jeff (for the chairs)

--001a11c2a20cc6a1ee04ea9917ab-- From glen.kent@gmail.com Fri Nov 8 09:23:54 2013 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 4ACC221E8138 for ; Fri, 8 Nov 2013 09:23:54 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98ky-ecPJGjs for ; Fri, 8 Nov 2013 09:23:53 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7B42F11E80DC for ; Fri, 8 Nov 2013 09:23:53 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id va2so1782760obc.9 for ; Fri, 08 Nov 2013 09:23:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7vePI1oFtWMYXia1RbwTjImEHfzkIq/es5n79/TB3yU=; b=D04tVB3hRJsx6Tr/uUeLuHCvkYnAW3r80ZsDxot0HKc56ubvqg45/2aNKA5NVVkpo7 kiLymySUiQWMq+xahfYgn0RQzmiuT8/lAWfNA+VkVNrCMtosSSrxhKPqxfCT8/zzpB3V oZDTNihWbwfOFAeGaIFkRsyiX8PmotZlXDwytJZ61b8Hw3bEw2z29NWcyNmDrT9tXhrk 52UG8ZHwukPr/Laj+yaiSBV1lwgpPkPZk2tk7Kddpl0PSEogljm9kfQBpINCxHYPPAww CytB5Ah+ZG6yGjk33d4aLHMDmRV4/PqQWz6wHknwFrmYbyTIgEGDPnBr2jvnJT4X91of yr/A== MIME-Version: 1.0 X-Received: by 10.182.18.102 with SMTP id v6mr889240obd.71.1383931432929; Fri, 08 Nov 2013 09:23:52 -0800 (PST) Received: by 10.182.23.36 with HTTP; Fri, 8 Nov 2013 09:23:52 -0800 (PST) In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4FACB1@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20211F91F544D247976D84C5D778A4C32E4FACB1@SG70YWXCHMBA05.zap.alcatel-lucent.com> Date: Fri, 8 Nov 2013 22:53:52 +0530 Message-ID: Subject: Re: Security aspects with S-BFD From: Glen Kent To: "Bhatia, Manav (Manav)" Content-Type: multipart/alternative; boundary=001a11c339e6740d3c04eaada547 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, 08 Nov 2013 17:23:54 -0000 --001a11c339e6740d3c04eaada547 Content-Type: text/plain; charset=ISO-8859-1 This is akin to saying that sequence numbers will not be used for authenticating S-BFD packets, right? If thats how it is, then cant we simply set this to 0, and ignore it on receipt. Glen On Thu, Nov 7, 2013 at 10:18 PM, Bhatia, Manav (Manav) < manav.bhatia@alcatel-lucent.com> wrote: > Hi, > > S-BFD describes the reflector sessions which raises interesting security > considerations. > > Since the reflector sessions are stateless (that's one of the biggest > advantages) it's impossible for the reflector to keep track of the sequence > number that its heard from its peers. This means, that the reflector is > susceptible to both inter-session and intra-session replay attacks. We had > a discussion internally amongst the co-authors and had the following > proposal that we wanted to vet before the WG members. > > Would like to hear the WGs opinion on this. > > 1. The Initiator picks up a crypto sequence number depending upon the > authentication mode that its using (meticulous or non meticulous). It sends > a packet to the Reflector with this seq num. > > 2. The reflector maintains no session state and hence does not look at the > crypto sequence number before accepting the packet. It looks at the Key ID > (draft-ietf-bfd-generic-crypto-auth-05) in the incoming packet (or it can > do it based on its own database where it maps the neighbor to the key iD) > and verifies the authentication data. If everything looks good, it > processes the packet. > > 3. When responding the Reflector needs to compute the Authentication data. > It uses the same sequence number that it received in the S-BFD packet that > it is responding to. It knows the Key ID, and thus the SA. It computes the > authentication data and sends the S-BFD packet out. > > 4. The Initiator receives the response from the Reflector. It only accepts > the S-BFD packet if it either comes with the same sequence number as it had > sent or its within the window that it finds acceptable (described in detail > in Sec 3.4 of draft-ietf-bfd-generic-crypto-auth-05) > > Benefits of this scheme. > > 1. Reflectors continue to remain stateless despite using security. > > 2. Reflectors are not susceptible to replay attacks as they always respond > to S-BFD packets irrespective of the sequence number carried. > > 3. An attacker cannot forge packets from the Reflector since the Initiator > will only accept S-BFD packets that come with the sequence number that it > had originally used when sending the S-BFD packet. > > Drawbacks of this scheme. > > 1. Reflectors are susceptible to DoS attacks since they respond to all > incoming S-BFD packets. This gets worse when cryptography is used as the > work load drastically increases as security is employed. > > Cheers, Manav > > > --001a11c339e6740d3c04eaada547 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is akin to sayin= g that sequence numbers will not be used for authenticating S-BFD packets, = right? If thats how it is, then cant we simply set this to 0, and ignore it= on receipt.

Glen
<= div class=3D"gmail_extra">
On Thu, Nov 7, 201= 3 at 10:18 PM, Bhatia, Manav (Manav) <manav.bhatia@alcatel-l= ucent.com> wrote:
Hi,

S-BFD describes the reflector sessions which raises interesting security co= nsiderations.

Since the reflector sessions are stateless (that's one of the biggest a= dvantages) it's impossible for the reflector to keep track of the seque= nce number that its heard from its peers. This means, that the reflector is= susceptible to both inter-session and intra-session replay attacks. We had= a discussion internally amongst the co-authors and had the following propo= sal that we wanted to vet before the WG members.

Would like to hear the WGs opinion on this.

1. The Initiator picks up a crypto sequence number depending upon the authe= ntication mode that its using (meticulous or non meticulous). It sends a pa= cket to the Reflector with this seq num.

2. The reflector maintains no session state and hence does not look at the = crypto sequence number before accepting the packet. It looks at the Key ID = (draft-ietf-bfd-generic-crypto-auth-05) in the incoming packet (or it can d= o it based on its own database where it maps the neighbor to the key iD) an= d verifies the authentication data. If everything looks good, it processes = the packet.

3. When responding the Reflector needs to compute the Authentication data. = It uses the same sequence number that it received in the S-BFD packet that = it is responding to. It knows the Key ID, and thus the SA. It computes the = authentication data and sends the S-BFD packet out.

4. The Initiator receives the response from the Reflector. It only accepts = the S-BFD packet if it either comes with the same sequence number as it had= sent or its within the window that it finds acceptable (described in detai= l in Sec 3.4 of draft-ietf-bfd-generic-crypto-auth-05)

Benefits of this scheme.

1. Reflectors continue to remain stateless despite using security.

2. Reflectors are not susceptible to replay attacks as they always respond = to S-BFD packets irrespective of the sequence number carried.

3. An attacker cannot forge packets from the Reflector since the Initiator = will only accept S-BFD packets that come with the sequence number that it h= ad originally used when sending the S-BFD packet.

Drawbacks of this scheme.

1. Reflectors are susceptible to DoS attacks since they respond to all inco= ming S-BFD packets. This gets worse when cryptography is used as the work l= oad drastically increases as security is employed.

Cheers, Manav



--001a11c339e6740d3c04eaada547-- From santoshpk@juniper.net Fri Nov 8 09:40:42 2013 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 84A9221F9FB9 for ; Fri, 8 Nov 2013 09:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9Ue0+umig0C for ; Fri, 8 Nov 2013 09:40:27 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id F1C6B11E81AD for ; Fri, 8 Nov 2013 09:39:37 -0800 (PST) Received: from mail110-co1-R.bigfish.com (10.243.78.252) by CO1EHSOBE026.bigfish.com (10.243.66.89) with Microsoft SMTP Server id 14.1.225.22; Fri, 8 Nov 2013 17:38:38 +0000 Received: from mail110-co1 (localhost [127.0.0.1]) by mail110-co1-R.bigfish.com (Postfix) with ESMTP id 2D0DC64053D; Fri, 8 Nov 2013 17:38:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zzdb82h98dI9371Ic85fhzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h9a9j1155h) Received-SPF: pass (mail110-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=santoshpk@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(377454003)(24454002)(54316002)(87266001)(47446002)(31966008)(56776001)(69226001)(74502001)(79102001)(74662001)(63696002)(46102001)(77982001)(74876001)(59766001)(80022001)(66066001)(65816001)(51856001)(74366001)(81342001)(19300405004)(4396001)(76796001)(76786001)(76576001)(87936001)(81816001)(54356001)(53806001)(81542001)(2656002)(76482001)(74706001)(81686001)(77096001)(50986001)(56816003)(49866001)(47976001)(47736001)(15202345003)(561944002)(33646001)(18717965001)(83072001)(80976001)(85306002)(16236675002)(19609705001)(19580395003)(74316001)(19580405001)(83322001)(15975445006)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB124; H:BN1PR05MB121.namprd05.prod.outlook.com; CLIP:116.197.184.18; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail110-co1 (localhost.localdomain [127.0.0.1]) by mail110-co1 (MessageSwitch) id 1383932316121743_20732; Fri, 8 Nov 2013 17:38:36 +0000 (UTC) Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.247]) by mail110-co1.bigfish.com (Postfix) with ESMTP id 19B1AA8004D; Fri, 8 Nov 2013 17:38:36 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 8 Nov 2013 17:38:35 +0000 Received: from BN1PR05MB124.namprd05.prod.outlook.com (10.255.199.28) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 8 Nov 2013 17:38:27 +0000 Received: from BN1PR05MB121.namprd05.prod.outlook.com (10.255.199.16) by BN1PR05MB124.namprd05.prod.outlook.com (10.255.199.28) with Microsoft SMTP Server (TLS) id 15.0.810.5; Fri, 8 Nov 2013 17:38:20 +0000 Received: from BN1PR05MB121.namprd05.prod.outlook.com ([169.254.13.238]) by BN1PR05MB121.namprd05.prod.outlook.com ([169.254.13.111]) with mapi id 15.00.0810.005; Fri, 8 Nov 2013 17:38:19 +0000 From: Santosh P K To: Glen Kent , "Bhatia, Manav (Manav)" Subject: RE: Security aspects with S-BFD Thread-Topic: Security aspects with S-BFD Thread-Index: Ac7b2ToBrFn7tnaZR4yTSVGAJsb+GwAzhE4AAABrHHA= Date: Fri, 8 Nov 2013 17:38:19 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C32E4FACB1@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.18] x-forefront-prvs: 00246AB517 Content-Type: multipart/alternative; boundary="_000_ed5747584fdb464bb7d1d9a1d04d0835BN1PR05MB121namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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, 08 Nov 2013 17:40:47 -0000 --_000_ed5747584fdb464bb7d1d9a1d04d0835BN1PR05MB121namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Glen, Sequence number has a meaning at initiator. Initiator on receiving the p= acket from the reflector can look in to sequence number and reject/accept b= ased on that. Thanks Santosh P K From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Glen Kent Sent: Friday, November 08, 2013 10:54 PM To: Bhatia, Manav (Manav) Cc: rtg-bfd@ietf.org Subject: Re: Security aspects with S-BFD This is akin to saying that sequence numbers will not be used for authentic= ating S-BFD packets, right? If thats how it is, then cant we simply set thi= s to 0, and ignore it on receipt. Glen On Thu, Nov 7, 2013 at 10:18 PM, Bhatia, Manav (Manav) > wrote: Hi, S-BFD describes the reflector sessions which raises interesting security co= nsiderations. Since the reflector sessions are stateless (that's one of the biggest advan= tages) it's impossible for the reflector to keep track of the sequence numb= er that its heard from its peers. This means, that the reflector is suscept= ible to both inter-session and intra-session replay attacks. We had a discu= ssion internally amongst the co-authors and had the following proposal that= we wanted to vet before the WG members. Would like to hear the WGs opinion on this. 1. The Initiator picks up a crypto sequence number depending upon the authe= ntication mode that its using (meticulous or non meticulous). It sends a pa= cket to the Reflector with this seq num. 2. The reflector maintains no session state and hence does not look at the = crypto sequence number before accepting the packet. It looks at the Key ID = (draft-ietf-bfd-generic-crypto-auth-05) in the incoming packet (or it can d= o it based on its own database where it maps the neighbor to the key iD) an= d verifies the authentication data. If everything looks good, it processes = the packet. 3. When responding the Reflector needs to compute the Authentication data. = It uses the same sequence number that it received in the S-BFD packet that = it is responding to. It knows the Key ID, and thus the SA. It computes the = authentication data and sends the S-BFD packet out. 4. The Initiator receives the response from the Reflector. It only accepts = the S-BFD packet if it either comes with the same sequence number as it had= sent or its within the window that it finds acceptable (described in detai= l in Sec 3.4 of draft-ietf-bfd-generic-crypto-auth-05) Benefits of this scheme. 1. Reflectors continue to remain stateless despite using security. 2. Reflectors are not susceptible to replay attacks as they always respond = to S-BFD packets irrespective of the sequence number carried. 3. An attacker cannot forge packets from the Reflector since the Initiator = will only accept S-BFD packets that come with the sequence number that it h= ad originally used when sending the S-BFD packet. Drawbacks of this scheme. 1. Reflectors are susceptible to DoS attacks since they respond to all inco= ming S-BFD packets. This gets worse when cryptography is used as the work l= oad drastically increases as security is employed. Cheers, Manav --_000_ed5747584fdb464bb7d1d9a1d04d0835BN1PR05MB121namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Glen,

   Sequence num= ber has a meaning at initiator. Initiator on receiving the packet from the = reflector can look in to sequence number and reject/accept based on that.

 <= /p>

Thanks<= /p>

Santosh P K  

 <= /p>

From: rtg-bfd-= bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Glen Kent
Sent: Friday, November 08, 2013 10:54 PM
To: Bhatia, Manav (Manav)
Cc: rtg-bfd@ietf.org
Subject: Re: Security aspects with S-BFD

 

This is akin to saying that sequence numbers will no= t be used for authenticating S-BFD packets, right? If thats how it is, then= cant we simply set this to 0, and ignore it on receipt.

 

Glen

 

On Thu, Nov 7, 2013 at 10:18 PM, Bhatia, Manav (Mana= v) <manav.bhatia@alcatel-lucent.com> wrote:

Hi,

S-BFD describes the reflector sessions which raises interesting security co= nsiderations.

Since the reflector sessions are stateless (that's one of the biggest advan= tages) it's impossible for the reflector to keep track of the sequence numb= er that its heard from its peers. This means, that the reflector is suscept= ible to both inter-session and intra-session replay attacks. We had a discussion internally amongst the co-authors and = had the following proposal that we wanted to vet before the WG members.

Would like to hear the WGs opinion on this.

1. The Initiator picks up a crypto sequence number depending upon the authe= ntication mode that its using (meticulous or non meticulous). It sends a pa= cket to the Reflector with this seq num.

2. The reflector maintains no session state and hence does not look at the = crypto sequence number before accepting the packet. It looks at the Key ID = (draft-ietf-bfd-generic-crypto-auth-05) in the incoming packet (or it can d= o it based on its own database where it maps the neighbor to the key iD) and verifies the authentication data. = If everything looks good, it processes the packet.

3. When responding the Reflector needs to compute the Authentication data. = It uses the same sequence number that it received in the S-BFD packet that = it is responding to. It knows the Key ID, and thus the SA. It computes the = authentication data and sends the S-BFD packet out.

4. The Initiator receives the response from the Reflector. It only accepts = the S-BFD packet if it either comes with the same sequence number as it had= sent or its within the window that it finds acceptable (described in detai= l in Sec 3.4 of draft-ietf-bfd-generic-crypto-auth-05)

Benefits of this scheme.

1. Reflectors continue to remain stateless despite using security.

2. Reflectors are not susceptible to replay attacks as they always respond = to S-BFD packets irrespective of the sequence number carried.

3. An attacker cannot forge packets from the Reflector since the Initiator = will only accept S-BFD packets that come with the sequence number that it h= ad originally used when sending the S-BFD packet.

Drawbacks of this scheme.

1. Reflectors are susceptible to DoS attacks since they respond to all inco= ming S-BFD packets. This gets worse when cryptography is used as the work l= oad drastically increases as security is employed.

Cheers, Manav

 

--_000_ed5747584fdb464bb7d1d9a1d04d0835BN1PR05MB121namprd05pro_-- From cpignata@cisco.com Sun Nov 10 14:28:58 2013 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 5388611E8175 for ; Sun, 10 Nov 2013 14:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.431 X-Spam-Level: X-Spam-Status: No, score=-110.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhvDLrL6-RMN for ; Sun, 10 Nov 2013 14:28:53 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 64B2D21E80DB for ; Sun, 10 Nov 2013 14:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3357; q=dns/txt; s=iport; t=1384122533; x=1385332133; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2wEC8lNtGaAI3OkaohE2zamIokDb1/mYPWXafO8NdJQ=; b=RfD4EdZuG6tqg4r2Sa3BBpea2hSw42+Az0mmSgWJN7GGFDSmplWQtq/K bXx7IN6gOwf/Ifl33ShWevDAcryr6okf9KNTKhT+QCbYWLIFfihiGrtvV 2x9RwShQcfVl69NFoW2l2kVTRS1G3aHlALqoBLR3JgkDXRK4UKXQti5u6 U=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAAkIgFKtJV2c/2dsb2JhbABZgwc4U78PgSkWdIIlAQEBAwEdUQsFCwIBCA4fGTIlAgQOBQkFC4diBg29JoxqgTSBSQIFCoMWgRADkDCBMIJOg2GBL5BbgyaBcTk X-IronPort-AV: E=Sophos;i="4.93,674,1378857600"; d="asc'?scan'208";a="283084845" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 10 Nov 2013 22:28:52 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAAMSpwx019988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Nov 2013 22:28:51 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.229]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Sun, 10 Nov 2013 16:28:51 -0600 From: "Carlos Pignataro (cpignata)" To: Jeffrey Haas Subject: Re: WGLC for BFD base MIB and TC - ends November 8 Thread-Topic: WGLC for BFD base MIB and TC - ends November 8 Thread-Index: AQHO3mQ7d29rmKPEbUGsnzhYr0Jy/A== Date: Sun, 10 Nov 2013 22:28:50 +0000 Message-ID: References: <20131024190612.GN17538@pfrc> In-Reply-To: <20131024190612.GN17538@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.56] Content-Type: multipart/signed; boundary="Apple-Mail=_61C2787F-09FB-420D-A558-394648E7E1BA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 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: Sun, 10 Nov 2013 22:28:58 -0000 --Apple-Mail=_61C2787F-09FB-420D-A558-394648E7E1BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 BFDers, The BFD co-chairs asked me to gauge consensus on this WG Last Call for = draft-ietf-bfd-mib-14 and draft-ietf-bfd-tc-mib-02. The WGLC ended this = past Friday. In my view, there is good support for these two documents, including = from implementors, and consensus to move forward and be sent to the = IESG. Before that, the following needs to be taken into account: 1. Fix the Nits identified by idnits [1] [2] 2. Ask the OPS ADs for a MIB Doctor review [3] (=93after the Working = Group Last Call and before the IETF Last Call=94) Thanks, =97 Carlos. [1] = http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-bfd= -mib-14.txt [2] = http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-bfd= -tc-mib-02.txt [3] http://www.ietf.org/iesg/directorate/mib-doctors.html On Oct 24, 2013, at 3:06 PM, Jeffrey Haas wrote: > This email is to initiate working group last call on the BFD MIB and > Textual-Convention documents: >=20 > http://tools.ietf.org/html/draft-ietf-bfd-mib-14 > http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-02 >=20 > The last call will complete on November 8, the end of IETF week. Time = will > be available during the Vancouver IETF BFD session to discuss last = call > comments. >=20 > I will be serving as document shepherd (RFC 4858) for this WGLC.=20 >=20 > Due to the small nature of the BFD working group and the fact that = both > working group chairs have contributed to the documents, we have gotten > Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as an > independent party to gauge working group consensus. >=20 > In order to facilitate the transparency of this WGLC, please remember = to > send all comments to the working group mailing list. >=20 > As is often the case with MIB documents, implementations typically do = not > exist for the final form of the document. Typically enterprise MIBs = are > implemented at some point in the document life cycle and then later = the > implementor will revise to match the published RFC, including OID > code-points assigned by IANA. Reviewers examining the MIB against = deployed > implementations are requested to bear in mind implementability of the = final > document vs. existence proof of the running code. >=20 > Finally, note that no IPR polling has been done for these documents. = MIBs, > being IETF data models of things that themselves may have IPR, tend = not to > have IPR against them. However, if someone is aware of IPR against = these > documents, please state it for the WG. >=20 > -- Jeff (for the chairs) --Apple-Mail=_61C2787F-09FB-420D-A558-394648E7E1BA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKACKIACgkQtfDPGTp3USy6MQCgy2tfVWLowoCL/mSHt9TCkAm9 3LcAn3RL+X3rwEvr/xicrDlzG5wGozwe =dhVC -----END PGP SIGNATURE----- --Apple-Mail=_61C2787F-09FB-420D-A558-394648E7E1BA-- From cpignata@cisco.com Sun Nov 10 14:29:50 2013 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 50A6611E80D9 for ; Sun, 10 Nov 2013 14:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.441 X-Spam-Level: X-Spam-Status: No, score=-110.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVrOuWhn5BDn for ; Sun, 10 Nov 2013 14:29:45 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 586E011E8175 for ; Sun, 10 Nov 2013 14:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2895; q=dns/txt; s=iport; t=1384122585; x=1385332185; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ut2bmVYlxmkSP0tqDGLmacNulF2saxU3dYTY2ad661U=; b=KdphVTpGT09qavwbnOYj0uJuX8ozcg+U6flWo45qcpsN6X6Ljt33HwYE LkqnsXnHFbdgjCSovPJVxgKicDv0ipl0DlonV09BvpjKUuiaP8coUQnlo K/xtBvqGGnyFFX8MisO6FprrHATKefhJ0i5TuI7cRRDLwWAD1x0MVLJLo 0=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAD0IgFKtJV2c/2dsb2JhbABZgwc4U78PgSkWdIIlAQEBAwFuCwULAgEIDjgyJQIEDgUOh20GDb0mjh6BSQeDIIEQA5AwgTCCToNhgS+QW4MmgXE5 X-IronPort-AV: E=Sophos;i="4.93,674,1378857600"; d="asc'?scan'208";a="283143106" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 10 Nov 2013 22:29:45 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAAMTiwh020805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Nov 2013 22:29:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.229]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Sun, 10 Nov 2013 16:29:44 -0600 From: "Carlos Pignataro (cpignata)" To: Jeffrey Haas Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Topic: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Index: AQHO3mRas6v9ADVrWkWBxo6hb1kgOw== Date: Sun, 10 Nov 2013 22:29:43 +0000 Message-ID: <6C38E01D-2C15-4F18-9A19-06486DC48C50@cisco.com> References: <20131024191431.GO17538@pfrc> In-Reply-To: <20131024191431.GO17538@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.56] Content-Type: multipart/signed; boundary="Apple-Mail=_0C22679D-D6A5-457B-AF2E-3F12A39C37C5"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 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: Sun, 10 Nov 2013 22:29:50 -0000 --Apple-Mail=_0C22679D-D6A5-457B-AF2E-3F12A39C37C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 WG: Hi, The BFD co-chairs asked me to gauge consensus on the WGLC for = draft-ietf-bfd-on-lags-01, which ended November 8th. There is clearly good support for this document, and I see strong = consensus to move forward including the mention of interoperable = implementations. There was also a good discussion (and conclusion) on = the list about interface identification. I captured the following notes: 1. Please fix idnits warnings Thanks, =97 Carlos. On Oct 24, 2013, at 3:14 PM, Jeffrey Haas wrote: > This email is to initiate working group last call on the BFD on Link > Aggregate Group Interfaces document: >=20 > http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 >=20 > The last call will complete on November 8, the end of IETF week. Time = will > be available during the Vancouver IETF BFD session to discuss last = call > comments. >=20 > Nobo Akiya will be serving as document shepherd (RFC 4858) for this = WGLC. >=20 > Due to the small nature of the BFD working group and the fact that = both > working group chairs have contributed to this document, we have gotten > Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as an=20 > independent party to gauge working group consensus. >=20 > In order to facilitate the transparency of this WGLC, please remember = to=20 > send all comments to the working group mailing list. >=20 > IPR declarations have been filed against this draft and the document = authors > and contributors have been polled for any further IPR. Current IPR > declarations may be seen at the following link: >=20 > = http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t-ietf-bfd-on-lags >=20 > If you are aware of additional IPR against this document please = declare so, per > the IETF Note Well. >=20 > Finally, the IEEE has expressed interest in the disposition of this = draft. > They will likely provide additional commentary, if any, via the IETF = liaison > process. This process will likely happen after WGLC concludes. = Depending > on their feedback, WGLC may re-open to address their concerns. >=20 > -- Jeff (for the chairs) --Apple-Mail=_0C22679D-D6A5-457B-AF2E-3F12A39C37C5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKACNcACgkQtfDPGTp3USzjGwCgoQTHRzvjd7g9csMWaFRCGgBH HkoAoJSmn5oWcDWfMVNUcSoSA5F3TvAS =OIjm -----END PGP SIGNATURE----- --Apple-Mail=_0C22679D-D6A5-457B-AF2E-3F12A39C37C5-- From nobo@cisco.com Mon Nov 11 07:21:10 2013 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 68CF421F9EDA for ; Mon, 11 Nov 2013 07:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikuBhywt6zZU for ; Mon, 11 Nov 2013 07:21:05 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBFB11E817E for ; Mon, 11 Nov 2013 07:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2793; q=dns/txt; s=iport; t=1384183265; x=1385392865; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=u8y2ftkp1AMcBJdsixuP3aBE6/Gii4LcLrTSUFvrWXo=; b=awjwh6qMkRVL1a0KgTso5ozx6yVpIJ/DmsoCFRjNZXk0hUCCYK9O2X2L uDWY31r25YNkb1CX6aJ5lYn2ZTXodVits5lnUE6kNntfjQSvxRxLgwNHW sLS/3Rq06y000OSd4hnrriYTqeJdDZS021fMidKJAC5QpLuO6sFjFJGVC c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFALX0gFKtJV2c/2dsb2JhbABZgmYhOFO/F4E6FnSCJQEBAQQ6NAsMBAIBCBEEAQEBChQJBzIUCQgCBAENBQiHeQEMvXuOHoEYMQcGgxqBEAOULoUQkFuDJoFxOQ X-IronPort-AV: E=Sophos;i="4.93,678,1378857600"; d="scan'208";a="280294744" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 11 Nov 2013 15:21:04 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rABFL4Us027355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Nov 2013 15:21:04 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 09:21:04 -0600 From: "Nobo Akiya (nobo)" To: "Carlos Pignataro (cpignata)" , Jeffrey Haas Subject: RE: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Topic: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8 Thread-Index: AQHO3mRiUajq3tTg6U2yq9mkMQcIrZogJDog Date: Mon, 11 Nov 2013 15:21:03 +0000 Message-ID: References: <20131024191431.GO17538@pfrc> <6C38E01D-2C15-4F18-9A19-06486DC48C50@cisco.com> In-Reply-To: <6C38E01D-2C15-4F18-9A19-06486DC48C50@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 11 Nov 2013 15:21:10 -0000 Carlos, thank you for gauging the WGLC consensus on draft-ietf-bfd-on-lags = document. Authors, please address only the idnits and post a new ID. -Nobo (as draft-ietf-bfd-on-lags shepherd) > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Carlos Pignataro (cpignata) > Sent: Sunday, November 10, 2013 5:30 PM > To: Jeffrey Haas > Cc: rtg-bfd@ietf.org > Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends > November 8 >=20 > WG: >=20 > Hi, >=20 > The BFD co-chairs asked me to gauge consensus on the WGLC for draft-ietf- > bfd-on-lags-01, which ended November 8th. >=20 > There is clearly good support for this document, and I see strong consens= us > to move forward including the mention of interoperable implementations. > There was also a good discussion (and conclusion) on the list about inter= face > identification. >=20 > I captured the following notes: > 1. Please fix idnits warnings >=20 > Thanks, >=20 > - Carlos. >=20 > On Oct 24, 2013, at 3:14 PM, Jeffrey Haas wrote: >=20 > > This email is to initiate working group last call on the BFD on Link > > Aggregate Group Interfaces document: > > > > http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 > > > > The last call will complete on November 8, the end of IETF week. Time > > will be available during the Vancouver IETF BFD session to discuss > > last call comments. > > > > Nobo Akiya will be serving as document shepherd (RFC 4858) for this > WGLC. > > > > Due to the small nature of the BFD working group and the fact that > > both working group chairs have contributed to this document, we have > > gotten Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as > > an independent party to gauge working group consensus. > > > > In order to facilitate the transparency of this WGLC, please remember > > to send all comments to the working group mailing list. > > > > IPR declarations have been filed against this draft and the document > > authors and contributors have been polled for any further IPR. > > Current IPR declarations may be seen at the following link: > > > > http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Dd= raf > > t-ietf-bfd-on-lags > > > > If you are aware of additional IPR against this document please > > declare so, per the IETF Note Well. > > > > Finally, the IEEE has expressed interest in the disposition of this dra= ft. > > They will likely provide additional commentary, if any, via the IETF > > liaison process. This process will likely happen after WGLC > > concludes. Depending on their feedback, WGLC may re-open to address > their concerns. > > > > -- Jeff (for the chairs) From internet-drafts@ietf.org Mon Nov 11 14:53:55 2013 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 173CB21E80B6; Mon, 11 Nov 2013 14:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfAhWaX00GI4; Mon, 11 Nov 2013 14:53:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E5C11E8103; Mon, 11 Nov 2013 14:53:54 -0800 (PST) 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-tc-mib-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131111225354.20259.98156.idtracker@ietfa.amsl.com> Date: Mon, 11 Nov 2013 14:53:54 -0800 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 22:53:55 -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 : Definitions of Textual Conventions (TCs) for Bidirection= al Forwarding Detection (BFD) Management Author(s) : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-tc-mib-03.txt Pages : 10 Date : 2013-11-11 Abstract: This draft defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Bidirectional Forwarding Detection (BFD) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD related MIB modules that would otherwise define their own representations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-tc-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-tc-mib-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Nov 11 14:54:57 2013 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 052C221E80B7; Mon, 11 Nov 2013 14:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLsiEmD784Xl; Mon, 11 Nov 2013 14:54:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D38711E8114; Mon, 11 Nov 2013 14:54:56 -0800 (PST) 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-mib-15.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131111225456.20279.29822.idtracker@ietfa.amsl.com> Date: Mon, 11 Nov 2013 14:54:56 -0800 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 22:54:57 -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 Management Information Base Author(s) : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-mib-15.txt Pages : 38 Date : 2013-11-11 Abstract: This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-mib-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-mib-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Nov 11 15:12:44 2013 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 4687321E80DB; Mon, 11 Nov 2013 15:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVDFRMLw72Vz; Mon, 11 Nov 2013 15:12:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C977421E80B5; Mon, 11 Nov 2013 15:12:43 -0800 (PST) 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-on-lags-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131111231243.20259.22545.idtracker@ietfa.amsl.com> Date: Mon, 11 Nov 2013 15:12:43 -0800 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 23:12:44 -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 : Bidirectional Forwarding Detection (BFD) on Link Aggrega= tion Group (LAG) Interfaces Author(s) : Manav Bhatia Mach(Guoyi) Chen Sami Boutros Marc Binderberger Jeffrey Haas Filename : draft-ietf-bfd-on-lags-02.txt Pages : 11 Date : 2013-11-11 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. 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. 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-on-lags-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-on-lags-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobo@cisco.com Mon Nov 11 15:15:39 2013 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 1626C21E809C for ; Mon, 11 Nov 2013 15:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aN8+6zU7obcn for ; Mon, 11 Nov 2013 15:15:34 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E3C4311E80D9 for ; Mon, 11 Nov 2013 15:15:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3376; q=dns/txt; s=iport; t=1384211734; x=1385421334; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=d7ecQN1f1D+r8CBSaYY8WsMUi/nR0Xu9xd5Yejpc2SU=; b=X5mAo2XCDJVYAaZ0G4vO9knZ1aJ1xR5Yd4W4cEGvsQgOy+2adpCBu2FD Vljd5ABSGrev7Gs0cRYBnXB9+VR56MtQb/HyLsc7rfEI07w4Etet3f2yo uiDEE0ImwZI1IO1fv5CvE23Y9LwEENmVCecHTfjmzAQn/YTZKo7sHPDmu Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAIxkgVKtJXHB/2dsb2JhbABZgmYhOFO/FoE9FnSCJQEBAQQdHTQLDAQCAQgRBAEBAQoLCQkHMhQJCAIEAQ0FCAEQh2gBDL5NjGaBNIEYMQIFBgSDFoEQA5QuhRCQW4MmgXE5 X-IronPort-AV: E=Sophos;i="4.93,680,1378857600"; d="scan'208";a="283452969" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 11 Nov 2013 23:15:33 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rABNFXtI027417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Nov 2013 23:15:33 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 17:15:32 -0600 From: "Nobo Akiya (nobo)" To: "Carlos Pignataro (cpignata)" , Jeffrey Haas Subject: RE: WGLC for BFD base MIB and TC - ends November 8 Thread-Topic: WGLC for BFD base MIB and TC - ends November 8 Thread-Index: AQHO0Owjc7oH/6Jq4EuHfR8yKojndJofizEAgAE2acA= Date: Mon, 11 Nov 2013 23:15:32 +0000 Message-ID: References: <20131024190612.GN17538@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 11 Nov 2013 23:15:39 -0000 Hi, Nits have been addressed, and new IDs have been posted (1 taken care of). http://tools.ietf.org/html/draft-ietf-bfd-mib-15 http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-03 Jeff, if would like me to engage MIB doctors (2), then please let me know. = Otherwise I'll assume that you will. -Nobo (for BFD base/TC MIB authors) > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Carlos Pignataro (cpignata) > Sent: Sunday, November 10, 2013 5:29 PM > To: Jeffrey Haas > Cc: rtg-bfd@ietf.org > Subject: Re: WGLC for BFD base MIB and TC - ends November 8 >=20 > BFDers, >=20 > The BFD co-chairs asked me to gauge consensus on this WG Last Call for > draft-ietf-bfd-mib-14 and draft-ietf-bfd-tc-mib-02. The WGLC ended this > past Friday. >=20 > In my view, there is good support for these two documents, including from > implementors, and consensus to move forward and be sent to the IESG. >=20 > Before that, the following needs to be taken into account: > 1. Fix the Nits identified by idnits [1] [2] 2. Ask the OPS ADs for a MIB= Doctor > review [3] ("after the Working Group Last Call and before the IETF Last C= all") >=20 > Thanks, >=20 > - Carlos. >=20 > [1] http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-iet= f-bfd- > mib-14.txt > [2] http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-iet= f-bfd-tc- > mib-02.txt > [3] http://www.ietf.org/iesg/directorate/mib-doctors.html >=20 >=20 > On Oct 24, 2013, at 3:06 PM, Jeffrey Haas wrote: >=20 > > This email is to initiate working group last call on the BFD MIB and > > Textual-Convention documents: > > > > http://tools.ietf.org/html/draft-ietf-bfd-mib-14 > > http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-02 > > > > The last call will complete on November 8, the end of IETF week. Time > > will be available during the Vancouver IETF BFD session to discuss > > last call comments. > > > > I will be serving as document shepherd (RFC 4858) for this WGLC. > > > > Due to the small nature of the BFD working group and the fact that > > both working group chairs have contributed to the documents, we have > > gotten Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as > > an independent party to gauge working group consensus. > > > > In order to facilitate the transparency of this WGLC, please remember > > to send all comments to the working group mailing list. > > > > As is often the case with MIB documents, implementations typically do > > not exist for the final form of the document. Typically enterprise > > MIBs are implemented at some point in the document life cycle and then > > later the implementor will revise to match the published RFC, > > including OID code-points assigned by IANA. Reviewers examining the > > MIB against deployed implementations are requested to bear in mind > > implementability of the final document vs. existence proof of the runni= ng > code. > > > > Finally, note that no IPR polling has been done for these documents. > > MIBs, being IETF data models of things that themselves may have IPR, > > tend not to have IPR against them. However, if someone is aware of > > IPR against these documents, please state it for the WG. > > > > -- Jeff (for the chairs) From mach.chen@huawei.com Mon Nov 11 17:51:39 2013 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 1298E21E8138 for ; Mon, 11 Nov 2013 17:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8Sb2C821XOe for ; Mon, 11 Nov 2013 17:51:34 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 234F321E80D9 for ; Mon, 11 Nov 2013 17:51:33 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXT94286; Tue, 12 Nov 2013 01:51:31 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 01:51:07 +0000 Received: from szxeml459-hub.china.huawei.com (10.82.67.202) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 01:51:18 +0000 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.159]) by szxeml459-hub.china.huawei.com ([10.82.67.202]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 09:18:17 +0800 From: Mach Chen To: "Carlos Pignataro (cpignata)" , Jeffrey Haas Subject: RE: WGLC for BFD base MIB and TC - ends November 8 Thread-Topic: WGLC for BFD base MIB and TC - ends November 8 Thread-Index: AQHO3mQ7d29rmKPEbUGsnzhYr0Jy/JogyEJg Date: Tue, 12 Nov 2013 01:18:16 +0000 Message-ID: References: <20131024190612.GN17538@pfrc> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected 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, 12 Nov 2013 01:51:39 -0000 Hi Carlos and all, Thanks for doing this, I have one question to the WG. Since the BFD over LA= G draft is also in publication process, and there are some implementations = and deployment requirements, but the MIB drafts seem lack of supporting the= BFD over LAG scenario ( e.g., a variable to describe the dedicated multica= st MAC) . Does the WG plan to fix this in these two drafts ? Or there will = be a separate document that will cover this in the future? Best regards, Mach > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of > Carlos Pignataro (cpignata) > Sent: Monday, November 11, 2013 6:29 AM > To: Jeffrey Haas > Cc: rtg-bfd@ietf.org > Subject: Re: WGLC for BFD base MIB and TC - ends November 8 >=20 > BFDers, >=20 > The BFD co-chairs asked me to gauge consensus on this WG Last Call for > draft-ietf-bfd-mib-14 and draft-ietf-bfd-tc-mib-02. The WGLC ended this p= ast > Friday. >=20 > In my view, there is good support for these two documents, including from > implementors, and consensus to move forward and be sent to the IESG. >=20 > Before that, the following needs to be taken into account: > 1. Fix the Nits identified by idnits [1] [2] 2. Ask the OPS ADs for a MIB= Doctor > review [3] ("after the Working Group Last Call and before the IETF Last C= all") >=20 > Thanks, >=20 > - Carlos. >=20 > [1] > http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-bf= d-mib-14.txt > [2] > http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-bf= d-tc-mib-02.t > xt > [3] http://www.ietf.org/iesg/directorate/mib-doctors.html >=20 >=20 > On Oct 24, 2013, at 3:06 PM, Jeffrey Haas wrote: >=20 > > This email is to initiate working group last call on the BFD MIB and > > Textual-Convention documents: > > > > http://tools.ietf.org/html/draft-ietf-bfd-mib-14 > > http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-02 > > > > The last call will complete on November 8, the end of IETF week. Time > > will be available during the Vancouver IETF BFD session to discuss > > last call comments. > > > > I will be serving as document shepherd (RFC 4858) for this WGLC. > > > > Due to the small nature of the BFD working group and the fact that > > both working group chairs have contributed to the documents, we have > > gotten Carlos Pignataro (cpignata@cisco.com) to volunteer to serve as > > an independent party to gauge working group consensus. > > > > In order to facilitate the transparency of this WGLC, please remember > > to send all comments to the working group mailing list. > > > > As is often the case with MIB documents, implementations typically do > > not exist for the final form of the document. Typically enterprise > > MIBs are implemented at some point in the document life cycle and then > > later the implementor will revise to match the published RFC, > > including OID code-points assigned by IANA. Reviewers examining the > > MIB against deployed implementations are requested to bear in mind > > implementability of the final document vs. existence proof of the runni= ng code. > > > > Finally, note that no IPR polling has been done for these documents. > > MIBs, being IETF data models of things that themselves may have IPR, > > tend not to have IPR against them. However, if someone is aware of > > IPR against these documents, please state it for the WG. > > > > -- Jeff (for the chairs) From nobo@cisco.com Mon Nov 11 18:21:35 2013 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 8B03221E8113 for ; Mon, 11 Nov 2013 18:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9i1x9ou2tCx for ; Mon, 11 Nov 2013 18:21:30 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8750821E8106 for ; Mon, 11 Nov 2013 18:21:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4742; q=dns/txt; s=iport; t=1384222890; x=1385432490; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rEW1wY3JjCDGvvDaR+SreMkrqXkgiBsEePGZUppt6fk=; b=Zkw6MxS2MkiqYRNHmxjWBNe4Aov7MkSBdw+mr1UuWeMIk8aNmiiBtAns E6RcbK/MEa309a9ERWivivlENEw//Mv6WgAzhsqls+iZYGsfChplIJPCq ET2fO/8krd5LyB+7eFlKsDzD9DK2OsO52Oyyx4LD/4b9ouB26B5aBqhQk 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FACKQgVKtJXG8/2dsb2JhbABZgmYhOFO/G4FCFnSCJQEBAQQdHTQLDAQCAQgRBAEBAQoLCQkHMhQJCAIEAQ0FCAEQh2gBDL48jF2BNIEYMQIFBgSDFoEQA5QuhRCQW4MmgXE5 X-IronPort-AV: E=Sophos;i="4.93,681,1378857600"; d="scan'208";a="283478426" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 12 Nov 2013 02:21:30 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAC2LThT031553 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 02:21:29 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 20:21:29 -0600 From: "Nobo Akiya (nobo)" To: Mach Chen , "Carlos Pignataro (cpignata)" , Jeffrey Haas Subject: RE: WGLC for BFD base MIB and TC - ends November 8 Thread-Topic: WGLC for BFD base MIB and TC - ends November 8 Thread-Index: AQHO0Owjc7oH/6Jq4EuHfR8yKojndJofizEAgAHBrAD//6jSYA== Date: Tue, 12 Nov 2013 02:21:28 +0000 Message-ID: References: <20131024190612.GN17538@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 12 Nov 2013 02:21:35 -0000 [speaking as contributor to both LAG and MIB documents] Hi Mach, My thought on this is that BFD on LAG is a variant of single-hop BFD, thus = [LAG member, IP address] is sufficient to uniquely describe an uBFD session= . I know of an implementation that is using this approach, and it seems to = satisfy user needs. Certainly there's no OID to describe multicast MAC nor interface MAC, of uB= FD session. Benefit of being able to read such OID seems very marginal. Whe= ther anyone ever want to write to such OID (to switch to/from multicast fro= m/to interface MAC?) is also questionable. New UDP port is automatically covered by TC MIB as well. Thus my preference would be use existing BFD base/TC MIB as is for BFD on L= AG. -Nobo > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Mach Chen > Sent: Monday, November 11, 2013 8:18 PM > To: Carlos Pignataro (cpignata); Jeffrey Haas > Cc: rtg-bfd@ietf.org > Subject: RE: WGLC for BFD base MIB and TC - ends November 8 >=20 > Hi Carlos and all, >=20 > Thanks for doing this, I have one question to the WG. Since the BFD over > LAG draft is also in publication process, and there are some > implementations and deployment requirements, but the MIB drafts seem > lack of supporting the BFD over LAG scenario ( e.g., a variable to descri= be > the dedicated multicast MAC) . Does the WG plan to fix this in these two > drafts ? Or there will be a separate document that will cover this in the > future? >=20 > Best regards, > Mach >=20 > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > > Behalf Of Carlos Pignataro (cpignata) > > Sent: Monday, November 11, 2013 6:29 AM > > To: Jeffrey Haas > > Cc: rtg-bfd@ietf.org > > Subject: Re: WGLC for BFD base MIB and TC - ends November 8 > > > > BFDers, > > > > The BFD co-chairs asked me to gauge consensus on this WG Last Call for > > draft-ietf-bfd-mib-14 and draft-ietf-bfd-tc-mib-02. The WGLC ended > > this past Friday. > > > > In my view, there is good support for these two documents, including > > from implementors, and consensus to move forward and be sent to the > IESG. > > > > Before that, the following needs to be taken into account: > > 1. Fix the Nits identified by idnits [1] [2] 2. Ask the OPS ADs for a > > MIB Doctor review [3] ("after the Working Group Last Call and before > > the IETF Last Call") > > > > Thanks, > > > > - Carlos. > > > > [1] > > http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-= b > > fd-mib-14.txt > > [2] > > http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-= b > > fd-tc-mib-02.t > > xt > > [3] http://www.ietf.org/iesg/directorate/mib-doctors.html > > > > > > On Oct 24, 2013, at 3:06 PM, Jeffrey Haas wrote: > > > > > This email is to initiate working group last call on the BFD MIB and > > > Textual-Convention documents: > > > > > > http://tools.ietf.org/html/draft-ietf-bfd-mib-14 > > > http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-02 > > > > > > The last call will complete on November 8, the end of IETF week. > > > Time will be available during the Vancouver IETF BFD session to > > > discuss last call comments. > > > > > > I will be serving as document shepherd (RFC 4858) for this WGLC. > > > > > > Due to the small nature of the BFD working group and the fact that > > > both working group chairs have contributed to the documents, we have > > > gotten Carlos Pignataro (cpignata@cisco.com) to volunteer to serve > > > as an independent party to gauge working group consensus. > > > > > > In order to facilitate the transparency of this WGLC, please > > > remember to send all comments to the working group mailing list. > > > > > > As is often the case with MIB documents, implementations typically > > > do not exist for the final form of the document. Typically > > > enterprise MIBs are implemented at some point in the document life > > > cycle and then later the implementor will revise to match the > > > published RFC, including OID code-points assigned by IANA. > > > Reviewers examining the MIB against deployed implementations are > > > requested to bear in mind implementability of the final document vs. > existence proof of the running code. > > > > > > Finally, note that no IPR polling has been done for these documents. > > > MIBs, being IETF data models of things that themselves may have IPR, > > > tend not to have IPR against them. However, if someone is aware of > > > IPR against these documents, please state it for the WG. > > > > > > -- Jeff (for the chairs) From mach.chen@huawei.com Mon Nov 11 19:19:58 2013 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 2ECDE21E8085 for ; Mon, 11 Nov 2013 19:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.208 X-Spam-Level: X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+P5-fetwNcg for ; Mon, 11 Nov 2013 19:19:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6754E21E80FC for ; Mon, 11 Nov 2013 19:19:50 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAD88362; Tue, 12 Nov 2013 03:19:49 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 03:19:36 +0000 Received: from SZXEML450-HUB.china.huawei.com (10.82.67.193) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 03:19:48 +0000 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.159]) by szxeml450-hub.china.huawei.com ([10.82.67.193]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 10:51:40 +0800 From: Mach Chen To: "Nobo Akiya (nobo)" , "Carlos Pignataro (cpignata)" , Jeffrey Haas Subject: RE: WGLC for BFD base MIB and TC - ends November 8 Thread-Topic: WGLC for BFD base MIB and TC - ends November 8 Thread-Index: AQHO3mQ7d29rmKPEbUGsnzhYr0Jy/JogyEJg//+QogCAAIrvcA== Date: Tue, 12 Nov 2013 02:51:39 +0000 Message-ID: References: <20131024190612.GN17538@pfrc> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected 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, 12 Nov 2013 03:19:58 -0000 Hi Nobo, Thanks for your prompt response! Pls see my reply inline.. >=20 > [speaking as contributor to both LAG and MIB documents] >=20 > Hi Mach, >=20 > My thought on this is that BFD on LAG is a variant of single-hop BFD, thu= s [LAG > member, IP address] is sufficient to uniquely describe an uBFD session. I= know of > an implementation that is using this approach, and it seems to satisfy us= er needs. >=20 > Certainly there's no OID to describe multicast MAC nor interface MAC, of = uBFD > session. Benefit of being able to read such OID seems very marginal. Whet= her > anyone ever want to write to such OID (to switch to/from multicast from/t= o > interface MAC?) is also questionable. Yes, I agree that it is very marginal.=20 I am not sure whether there will be writing, but there should be reading of= such OID. The "multicast MAC or interface MAC" is just the one that came into my mind= , I am not sure whether there are some uncovered places.=20 If the "multicast MAC or interface MAC" is the only one need to be consider= ed, IMHO, it's maybe easy to modify the BFD base MIB to fix it. Best regards, Mach >=20 > New UDP port is automatically covered by TC MIB as well. >=20 > Thus my preference would be use existing BFD base/TC MIB as is for BFD on= LAG. >=20 > -Nobo >=20 > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > > Behalf Of Mach Chen > > Sent: Monday, November 11, 2013 8:18 PM > > To: Carlos Pignataro (cpignata); Jeffrey Haas > > Cc: rtg-bfd@ietf.org > > Subject: RE: WGLC for BFD base MIB and TC - ends November 8 > > > > Hi Carlos and all, > > > > Thanks for doing this, I have one question to the WG. Since the BFD > > over LAG draft is also in publication process, and there are some > > implementations and deployment requirements, but the MIB drafts seem > > lack of supporting the BFD over LAG scenario ( e.g., a variable to > > describe the dedicated multicast MAC) . Does the WG plan to fix this > > in these two drafts ? Or there will be a separate document that will > > cover this in the future? > > > > Best regards, > > Mach > > > > > -----Original Message----- > > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > > > Behalf Of Carlos Pignataro (cpignata) > > > Sent: Monday, November 11, 2013 6:29 AM > > > To: Jeffrey Haas > > > Cc: rtg-bfd@ietf.org > > > Subject: Re: WGLC for BFD base MIB and TC - ends November 8 > > > > > > BFDers, > > > > > > The BFD co-chairs asked me to gauge consensus on this WG Last Call > > > for > > > draft-ietf-bfd-mib-14 and draft-ietf-bfd-tc-mib-02. The WGLC ended > > > this past Friday. > > > > > > In my view, there is good support for these two documents, including > > > from implementors, and consensus to move forward and be sent to the > > IESG. > > > > > > Before that, the following needs to be taken into account: > > > 1. Fix the Nits identified by idnits [1] [2] 2. Ask the OPS ADs for > > > a MIB Doctor review [3] ("after the Working Group Last Call and > > > before the IETF Last Call") > > > > > > Thanks, > > > > > > - Carlos. > > > > > > [1] > > > http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-iet= f > > > -b > > > fd-mib-14.txt > > > [2] > > > http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-iet= f > > > -b > > > fd-tc-mib-02.t > > > xt > > > [3] http://www.ietf.org/iesg/directorate/mib-doctors.html > > > > > > > > > On Oct 24, 2013, at 3:06 PM, Jeffrey Haas wrote: > > > > > > > This email is to initiate working group last call on the BFD MIB > > > > and Textual-Convention documents: > > > > > > > > http://tools.ietf.org/html/draft-ietf-bfd-mib-14 > > > > http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-02 > > > > > > > > The last call will complete on November 8, the end of IETF week. > > > > Time will be available during the Vancouver IETF BFD session to > > > > discuss last call comments. > > > > > > > > I will be serving as document shepherd (RFC 4858) for this WGLC. > > > > > > > > Due to the small nature of the BFD working group and the fact that > > > > both working group chairs have contributed to the documents, we > > > > have gotten Carlos Pignataro (cpignata@cisco.com) to volunteer to > > > > serve as an independent party to gauge working group consensus. > > > > > > > > In order to facilitate the transparency of this WGLC, please > > > > remember to send all comments to the working group mailing list. > > > > > > > > As is often the case with MIB documents, implementations typically > > > > do not exist for the final form of the document. Typically > > > > enterprise MIBs are implemented at some point in the document life > > > > cycle and then later the implementor will revise to match the > > > > published RFC, including OID code-points assigned by IANA. > > > > Reviewers examining the MIB against deployed implementations are > > > > requested to bear in mind implementability of the final document vs= . > > existence proof of the running code. > > > > > > > > Finally, note that no IPR polling has been done for these documents= . > > > > MIBs, being IETF data models of things that themselves may have > > > > IPR, tend not to have IPR against them. However, if someone is > > > > aware of IPR against these documents, please state it for the WG. > > > > > > > > -- Jeff (for the chairs) From jhaas@slice.pfrc.org Tue Nov 12 10:33:43 2013 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 54A0D11E8138 for ; Tue, 12 Nov 2013 10:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.215 X-Spam-Level: X-Spam-Status: No, score=-102.215 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itulUaAUAsdm for ; Tue, 12 Nov 2013 10:33:33 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 10EDD21F9FFF for ; Tue, 12 Nov 2013 10:33:32 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0E9CCC2F0; Tue, 12 Nov 2013 13:33:25 -0500 (EST) Date: Tue, 12 Nov 2013 13:33:25 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Draft minutes for BFD session for IETF-88, Vancouver Message-ID: <20131112183324.GD15347@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: Tue, 12 Nov 2013 18:33:43 -0000 The following are the draft minutes for the working group session at IETF-88 in Vancouver. Please send corretions to the WG list. I will be posting these notes immediately to the proceedings and will post updates no later than this Friday. --------------------------8<--- cut --->8--------------------------- BFD Working Group, IETF-88 Vancouver Monday, November 4, 2013 Chairs: Nobo Akiya (nobo@cisco.com), Jeffrey Haas (jhaas@pfrc.org) ------ Presentation: Working Group Status (see meeting materials) 3 documents in Working Group last call, ending this week. (November 8.) The Working Group chairs will be handling the shepherding of the documents. Carlos Pignatoro has volunteered to gauge Working Group consensus. There have been a few clarification questions on BFD on LAGs (draft-ietf-bfd-on-lags). The questions on the list appear to be resolved. BFD MIB documents (draft-ietf-bfd-mib, draft-ietf-tc-mib), as expected, not getting a lot of feedback requesting changes. MPLS MIB document (draft-ietf-bfd-mpls-mib), needs additional input on the mailing list. Particulary, are there any implementations available? BFD Crypto documents (draft-ietf-bfd-generic-crypto-auth, draft-ietf-bfd-hmac-sha) demonstrate good practice and the KARP Working Group gave us good input. However, the motivation for BFD authentication crypto at line rate is not there at the moment. This is holding back implementations and thus progression of the documents in the Working Group. S-BFD may potentially require some stronger crypto? BFD multipoint (draft-ietf-bfd-multipoint). Silent tail not being implemented. Should silent tail get snipped to move draft along? Dave Ward doesnt think we should move it out. Perhaps we can move active tail to appendix? Interval draft (draft-akiya-bfd-intervals). Nobo: There's an interesting problem of P/F bit workability when the session is not yet up, when HW based BFD supports deviating interval set. I spoke to co-author, Marc Binderberger, and he is actively working on this document to roll it out as informational draft. If you have any inputs around interval topic, please send to WG list. Greg Mirsky, Ericsson: We should target BCP for this document. Several people at the meeting had read the draft and would support its adoption as a Working Group document. Redundancy draft (draft-mbind-bfd-redundancy), there were some discussion on the list. Impression is the draft will not move forward. BFD over eVPN (draft-vgovindan-l2vpn-evpn-bfd) will be presented in L2VPN, perhaps presented as BFD at next London. ------ Presentation: S-BFD (Nobo Akiya) (see meeting materials) Greg Mirsky (on the alert discriminator draft): In the BFD multi-hop, there is no mechanism, nothing to require congruent forwarding. The tools are thus no less predictable. Doesn't really matter which tool you're using. Nobo Akiya: In IP multi-hop, how do we protect it in the first place? Greg Mirsky: The ambiguity is just there to begin with. Nobo Akiya: If you have BFD multi-hop in the first place, operators still want to find the issues. Greg Mirsky: BFD will just get ICMP. Nobo Akiya: In some cases, yes. Greg Mirsky: This argument to switch to use IP traceroute is only an _okay_ mechanism. Nobo Akiya: There are scenarios for a BFD trace... Greg Mirsky: Traceroute S-BFD may not follow the same path as ECMP traffic. If we're talking about IP, it is one thing. MPLS may be something different. Nobo Akiya: The longer you wait, the harder it is to determine where the fault was. Greg Mirsky: Fault isolation is usually driven by the operator. Nobo Akiya: The hints this would provide are still helpful for operators. Greg Mirsky: [Wants to hear from the operators.] LSPTrace is sufficient. LSP Ping can be extended better than BFD, usually. --- Greg Mirsky: On selecting the discriminator, there's some confusion. For example, suggesting that an IPv4 address is directly interpreted but also refers to a mapping table. What happens if it is already allocate by dynamic BFD? Since S-BFD is on a different port, use a different discriminator pool. Overlapping spaces creates a lot of issues. Nobo Akiya: Agreed. Part of the change was for this reason. Greg Mirksy: It's more robust. Separate space of reserved values in an IANA registry? Mapping other than direct registration. Nobo Akiya: Please clarify. Greg Mirsky: The ambiguity is the IP address is the same as the discriminator. If mapped, you can map numbers to discriminators easily. Nobo Akiya: Direct mapping is simpler. No signaling is required. Greg Mirsky: The mapping mechanism can be outside of the BFD protocol. Manual provisioning is often more flexible. --- Greg Mirsky: It's good to have separate requirements documents. I don't see enough reason to justify this feature [S-BFD] compared to IP and LSP Ping. These are better to troubleshoot an IP/MPLS network. Perhaps talk to the LMAP Working Group about large scale access groups. It's possibly in their charter to help. Jeff Haas: The S-BFD mechanism is not just about the alert feature. The primary novel thing about the feature is that it can provide _stateless_ BFD. The presentation shows several mechanisms that were originally part of a single document that had been split into the base feature and several application documents. Most of the comments provided have targeted the alert feature, but it's not even the biggest feature. Suggest the WG consider evaluating it in that light. What happens when you have need for reachability verification at extremely large scale and use existing BFD? This may be one use case. To handle cryptographic sequence number, some amount of minimumal state needs to be kept. Greg Mirsky: Use case document may be appropriate? --- A poll of the room showed that about half of the room had read the S-BFD drafts. A second poll showed that most of those who had read it would support the documents be adopted as Working Group Drafts. --------------------------8<--- cut --->8--------------------------- -- Jeff From jhaas@slice.pfrc.org Tue Nov 12 12:25:20 2013 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 E5BA621E80F0 for ; Tue, 12 Nov 2013 12:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.218 X-Spam-Level: X-Spam-Status: No, score=-102.218 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2w4VLyOZXHm for ; Tue, 12 Nov 2013 12:25:15 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 36E2721E8093 for ; Tue, 12 Nov 2013 12:25:11 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id D388CC2F0; Tue, 12 Nov 2013 15:25:10 -0500 (EST) Date: Tue, 12 Nov 2013 15:25:10 -0500 From: Jeffrey Haas To: Mach Chen Subject: Re: WGLC for BFD base MIB and TC - ends November 8 Message-ID: <20131112202510.GG15347@pfrc> References: <20131024190612.GN17538@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Carlos Pignataro \(cpignata\)" , "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, 12 Nov 2013 20:25:21 -0000 Mach, On Tue, Nov 12, 2013 at 02:51:39AM +0000, Mach Chen wrote: > > [speaking as contributor to both LAG and MIB documents] > > > > Hi Mach, > > > > My thought on this is that BFD on LAG is a variant of single-hop BFD, thus [LAG > > member, IP address] is sufficient to uniquely describe an uBFD session. I know of > > an implementation that is using this approach, and it seems to satisfy user needs. > > > > Certainly there's no OID to describe multicast MAC nor interface MAC, of uBFD > > session. Benefit of being able to read such OID seems very marginal. Whether > > anyone ever want to write to such OID (to switch to/from multicast from/to > > interface MAC?) is also questionable. > > Yes, I agree that it is very marginal. > > I am not sure whether there will be writing, but there should be reading of such OID. I spent some time reviewing the BFD MIBs specially with the LAG cases in mind. The conclusion I arrived at included the following: - the *base* MIBs are capable of handling the subsets of behavior that are not feature specific to the BFD MPLS MIB or LAG scenarios. - the superset of feature elements were largley covered by the port number change. - the one minor element was the mac address. - As BFD continues to evolve, a single MIB can never address 100% of the use cases. The latter is the main point here, I think. As you suggest, there's really only a single object (maybe two) that distinguishes the additional details of BFD on LAG: Whether we're using the multicast MAC as part of the procedures and what the MAC is for the session. > The "multicast MAC or interface MAC" is just the one that came into my mind, I am not sure whether there are some uncovered places. > > If the "multicast MAC or interface MAC" is the only one need to be considered, IMHO, it's maybe easy to modify the BFD base MIB to fix it. My suggestion would be that if you find that specific detail interesting, it is in-charter for the Working Group to add an extension MIB for the base MIB for the necessary feature-specific objects. Did you have any interest in authoring that? -- Jeff From jhaas@slice.pfrc.org Tue Nov 12 12:37:19 2013 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 4199821E80CB for ; Tue, 12 Nov 2013 12:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.22 X-Spam-Level: X-Spam-Status: No, score=-102.22 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5XDOlYmqTui for ; Tue, 12 Nov 2013 12:37:03 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1880111E810A for ; Tue, 12 Nov 2013 12:37:03 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 62461C2F0; Tue, 12 Nov 2013 15:37:01 -0500 (EST) Date: Tue, 12 Nov 2013 15:37:01 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Poll - working group adoption of draft-akiya-bfd-intervals Message-ID: <20131112203701.GI15347@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: Tue, 12 Nov 2013 20:37:20 -0000 Working Group, Part of our discussion at IETF 88 in Vancouver was with regard to the draft "Standardized interval support in BFD", draft-akiya-bfd-intervals. Prior discussion of this draft suggested that making the intervals mandatory was probably over-reaching the work we'd like to do. However, there's interest in pursuing this work in an Informational context. A longer term goal of the document would be to achieve Best Current Practice (BCP) status. A poll of the room in Vancouver indicated good support to take on this work. Since this is somewhat out of our current charter, we'd be seeking a re-charter to cover this specific task. Please indicate to the Working Group mailing list if you'd support or don't support adoption of this draft as a Working Group document. If there is sufficient support, we'll initiate the re-chartering, probably along with the S-BFD work. -- Jeff From jhaas@slice.pfrc.org Tue Nov 12 12:47:31 2013 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 E263021E80AD for ; Tue, 12 Nov 2013 12:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.221 X-Spam-Level: X-Spam-Status: No, score=-102.221 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OB5yMzsyFeeD for ; Tue, 12 Nov 2013 12:47:25 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BCB8221E80A7 for ; Tue, 12 Nov 2013 12:47:25 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2DFA2C2F0; Tue, 12 Nov 2013 15:47:16 -0500 (EST) Date: Tue, 12 Nov 2013 15:47:16 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: S-BFD status (followup from IETF-88, Vancouver) Message-ID: <20131112204716.GJ15347@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: Tue, 12 Nov 2013 20:47:31 -0000 Working Group, After discussing the comments to date about the S-BFD proposals - off-list, on-list and at the Working Group session - the chairs believe that these proposals need a bit more work before requesting Working Group re-chartering and adoption. One of the new documents that will be produced from this effort would be a use case document to better clarify the feature and how it would be utilized. The remaining documents will receive further attention and refinement according to the use cases. While these drafts are not yet official work for this WG, I'd like to encourage the authors to consider making use of the WG mailing list for refining their ideas. -- Jeff (for the chairs) From jhaas@slice.pfrc.org Tue Nov 12 13:00:58 2013 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 D343421F9C69 for ; Tue, 12 Nov 2013 13:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.223 X-Spam-Level: X-Spam-Status: No, score=-102.223 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oF1K+Fy9l1sf for ; Tue, 12 Nov 2013 13:00:53 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CA1BD11E810A for ; Tue, 12 Nov 2013 13:00:53 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 82D10C2F0; Tue, 12 Nov 2013 16:00:53 -0500 (EST) Date: Tue, 12 Nov 2013 16:00:53 -0500 From: Jeffrey Haas To: "Bhatia, Manav (Manav)" Subject: Re: Security aspects with S-BFD Message-ID: <20131112210053.GK15347@pfrc> References: <20211F91F544D247976D84C5D778A4C32E4FACB1@SG70YWXCHMBA05.zap.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4FACB1@SG70YWXCHMBA05.zap.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: Tue, 12 Nov 2013 21:00:58 -0000 Manav, On Thu, Nov 07, 2013 at 04:48:47PM +0000, Bhatia, Manav (Manav) wrote: > 1. The Initiator picks up a crypto sequence number depending upon the authentication mode that its using (meticulous or non meticulous). It sends a packet to the Reflector with this seq num. > > 2. The reflector maintains no session state and hence does not look at the crypto sequence number before accepting the packet. It looks at the Key ID (draft-ietf-bfd-generic-crypto-auth-05) in the incoming packet (or it can do it based on its own database where it maps the neighbor to the key iD) and verifies the authentication data. If everything looks good, it processes the packet. > > 3. When responding the Reflector needs to compute the Authentication data. It uses the same sequence number that it received in the S-BFD packet that it is responding to. It knows the Key ID, and thus the SA. It computes the authentication data and sends the S-BFD packet out. > > 4. The Initiator receives the response from the Reflector. It only accepts the S-BFD packet if it either comes with the same sequence number as it had sent or its within the window that it finds acceptable (described in detail in Sec 3.4 of draft-ietf-bfd-generic-crypto-auth-05) > > Benefits of this scheme. > > 1. Reflectors continue to remain stateless despite using security. It would be good to see some discussion from the S-BFD authors regarding light-weight state for authentication. In other words, just enough to verify crypto sequence numbers. One challenge that immediately comes to mind is that since the sessions are completely stateless, this means the reflector really can't know if the initiator rebooted or not, especially if the initiator is foolish enough to have the same discriminator. > 2. Reflectors are not susceptible to replay attacks as they always respond to S-BFD packets irrespective of the sequence number carried. > > 3. An attacker cannot forge packets from the Reflector since the Initiator will only accept S-BFD packets that come with the sequence number that it had originally used when sending the S-BFD packet. Protecting the Initiator is good. But ... > Drawbacks of this scheme. > > 1. Reflectors are susceptible to DoS attacks since they respond to all incoming S-BFD packets. This gets worse when cryptography is used as the work load drastically increases as security is employed. This continues to be my primary concern about the security for this feature. In the absence of *any* state, it's very difficult to have a low-work filter that protects the Reflector against cryptographic work attacks. Also, as best I understand several of the potential use cases for this feature, every S-BFD node may end up being a Reflector in some of those cases. To take a post-WG session comment to heart, this feature does have several resemblances to simply using IP Ping. This means that several of the security considerations associated with ICMP attacks (rate limiting, etc.) are likely applicable. > Cheers, Manav -- Jeff From marc@sniff.de Tue Nov 12 13:12:13 2013 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 52D7221E80CF for ; Tue, 12 Nov 2013 13:12:13 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Tp-51sGSMDi for ; Tue, 12 Nov 2013 13:12:12 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6207421E80A1 for ; Tue, 12 Nov 2013 13:12:12 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 66A4E2AA0F; Tue, 12 Nov 2013 21:12:10 +0000 (GMT) Date: Tue, 12 Nov 2013 13:12:08 -0800 From: Marc Binderberger To: Jeffrey Haas Message-ID: <20131112131208841567.3060ef78@sniff.de> In-Reply-To: <20131112203701.GI15347@pfrc> References: <20131112203701.GI15347@pfrc> Subject: Re: Poll - working group adoption of draft-akiya-bfd-intervals MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.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: Tue, 12 Nov 2013 21:12:13 -0000 Support. Marc On Tue, 12 Nov 2013 15:37:01 -0500, Jeffrey Haas wrote: > Working Group, > > Part of our discussion at IETF 88 in Vancouver was with regard to the draft > "Standardized interval support in BFD", draft-akiya-bfd-intervals. > > Prior discussion of this draft suggested that making the intervals mandatory > was probably over-reaching the work we'd like to do. However, there's > interest in pursuing this work in an Informational context. A longer term > goal of the document would be to achieve Best Current Practice (BCP) status. > > A poll of the room in Vancouver indicated good support to take on this work. > Since this is somewhat out of our current charter, we'd be seeking a > re-charter to cover this specific task. > > Please indicate to the Working Group mailing list if you'd support or don't > support adoption of this draft as a Working Group document. > > If there is sufficient support, we'll initiate the re-chartering, probably > along with the S-BFD work. > > -- Jeff > From nobo@cisco.com Tue Nov 12 13:21:06 2013 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 1E86211E8128 for ; Tue, 12 Nov 2013 13:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2j8n7wxw0wKd for ; Tue, 12 Nov 2013 13:21:00 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 31AAA11E810C for ; Tue, 12 Nov 2013 13:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1442; q=dns/txt; s=iport; t=1384291260; x=1385500860; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Y2ruxmawSvXufxxPtcjEGBD7qMvYLQb6OggbKhh+htI=; b=bwkeCCzztdmfQk3wZrtat41vu3UEG7FARhhi6teDbrA3KxTwyr88BAg5 vkoC+FCbLF8VqdqYYGXWj2lrAv5B7QJ02OL3uFO8UZO1Rxz7NAiL+Dsf/ ybBZpmESZqlvdUNzPF4DprYMM47T0QpO4qdTfHpk4mVh18ZG8YF0UwYGC Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFABybglKtJV2a/2dsb2JhbABagmYhgQu/FoEqFnSCJQEBAQQ6NBcEAgEIDgMEAQELFAkHMhQJCAIEARIIh3kBv0uPLjgGgxqBEQOqGYMmgio X-IronPort-AV: E=Sophos;i="4.93,687,1378857600"; d="scan'208";a="280921614" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 12 Nov 2013 21:20:59 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rACLKxZr027562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 21:20:59 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 15:20:59 -0600 From: "Nobo Akiya (nobo)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Poll - working group adoption of draft-akiya-bfd-intervals Thread-Topic: Poll - working group adoption of draft-akiya-bfd-intervals Thread-Index: AQHO3+cBmJlVxINYJE6TrpXnwRW3iJoiGPQg Date: Tue, 12 Nov 2013 21:20:59 +0000 Message-ID: References: <20131112203701.GI15347@pfrc> In-Reply-To: <20131112203701.GI15347@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 12 Nov 2013 21:21:06 -0000 Speaking as a co-author of the draft, I believe such BCP document will sign= ificantly reduce potential interoperability issues with HW based BFD, thus = support. -Nobo > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Jeffrey Haas > Sent: Tuesday, November 12, 2013 3:37 PM > To: rtg-bfd@ietf.org > Subject: Poll - working group adoption of draft-akiya-bfd-intervals >=20 > Working Group, >=20 > Part of our discussion at IETF 88 in Vancouver was with regard to the dra= ft > "Standardized interval support in BFD", draft-akiya-bfd-intervals. >=20 > Prior discussion of this draft suggested that making the intervals mandat= ory > was probably over-reaching the work we'd like to do. However, there's > interest in pursuing this work in an Informational context. A longer ter= m > goal of the document would be to achieve Best Current Practice (BCP) stat= us. >=20 > A poll of the room in Vancouver indicated good support to take on this wo= rk. > Since this is somewhat out of our current charter, we'd be seeking a re- > charter to cover this specific task. >=20 > Please indicate to the Working Group mailing list if you'd support or don= 't > support adoption of this draft as a Working Group document. >=20 > If there is sufficient support, we'll initiate the re-chartering, probabl= y along > with the S-BFD work. >=20 > -- Jeff From davari@broadcom.com Tue Nov 12 13:32:25 2013 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 9444511E80E6 for ; Tue, 12 Nov 2013 13:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pmt9oV4cqEWH for ; Tue, 12 Nov 2013 13:32:20 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 55E4911E810C for ; Tue, 12 Nov 2013 13:32:20 -0800 (PST) Received: from [10.9.208.55] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 12 Nov 2013 13:31:55 -0800 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS07.corp.ad.broadcom.com (10.16.203.16) by IRVEXCHCAS07.corp.ad.broadcom.com (10.9.208.55) with Microsoft SMTP Server (TLS) id 14.1.438.0; Tue, 12 Nov 2013 13:32:08 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Tue, 12 Nov 2013 13:32:08 -0800 From: "Shahram Davari" To: "Jeffrey Haas" , "rtg-bfd@ietf.org" Subject: RE: Poll - working group adoption of draft-akiya-bfd-intervals Thread-Topic: Poll - working group adoption of draft-akiya-bfd-intervals Thread-Index: AQHO3+cG8rFQhVsi4UKi+WIgxXxj1ZoiHIxQ Date: Tue, 12 Nov 2013 21:32:07 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F281BF3B915@SJEXCHMB12.corp.ad.broadcom.com> References: <20131112203701.GI15347@pfrc> In-Reply-To: <20131112203701.GI15347@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7E9C41C01507497832-01-01 Content-Type: multipart/alternative; boundary=_000_4A6CE49E6084B141B15C0713B8993F281BF3B915SJEXCHMB12corpa_ 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, 12 Nov 2013 21:32:25 -0000 --_000_4A6CE49E6084B141B15C0713B8993F281BF3B915SJEXCHMB12corpa_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Jeff, I support defining a list of intervals that must be supported. However I wo= uld like to propose matching the rates to the ETH-OAM, since most of HW OAM engines must support both BFD and ETH-OAM. Y.1731 rates are: 3.3ms, 10ms, 100ms, 1s, 10s, 1min, 10min. Thx Shahram -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Jeffrey Haas Sent: Tuesday, November 12, 2013 12:37 PM To: rtg-bfd@ietf.org Subject: Poll - working group adoption of draft-akiya-bfd-intervals Working Group, Part of our discussion at IETF 88 in Vancouver was with regard to the draft "Standardized interval support in BFD", draft-akiya-bfd-intervals. Prior discussion of this draft suggested that making the intervals mandator= y was probably over-reaching the work we'd like to do. However, there's interest in pursuing this work in an Informational context. A longer term goal of the document would be to achieve Best Current Practice (BCP) status= . A poll of the room in Vancouver indicated good support to take on this work= . Since this is somewhat out of our current charter, we'd be seeking a re-charter to cover this specific task. Please indicate to the Working Group mailing list if you'd support or don't support adoption of this draft as a Working Group document. If there is sufficient support, we'll initiate the re-chartering, probably along with the S-BFD work. -- Jeff --_000_4A6CE49E6084B141B15C0713B8993F281BF3B915SJEXCHMB12corpa_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi Jeff,

 

I support defining a list of intervals that must = be supported. However I would like to propose matching the rates to the

ETH-OAM, since most of HW OAM engines must suppor= t both BFD and ETH-OAM.

 

Y.1731 rates are:

 

3.3ms, 10ms, 100ms, 1s, 10s, 1min, 10min.

 

Thx

Shahram

 

 

 

-----Original Message-----
From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Jeffrey Haas
Sent: Tuesday, November 12, 2013 12:37 PM
To: rtg-bfd@ietf.org
Subject: Poll - working group adoption of draft-akiya-bfd-intervals

 

Working Group,

 

Part of our discussion at IETF 88 in Vancouver wa= s with regard to the draft

"Standardized interval support in BFD",= draft-akiya-bfd-intervals.

 

Prior discussion of this draft suggested that mak= ing the intervals mandatory

was probably over-reaching the work we'd like to = do.  However, there's

interest in pursuing this work in an Informationa= l context.  A longer term

goal of the document would be to achieve Best Cur= rent Practice (BCP) status.

 

A poll of the room in Vancouver indicated good su= pport to take on this work.

Since this is somewhat out of our current charter= , we'd be seeking a

re-charter to cover this specific task.

 

Please indicate to the Working Group mailing list= if you'd support or don't

support adoption of this draft as a Working Group= document.

 

If there is sufficient support, we'll initiate th= e re-chartering, probably

along with the S-BFD work.

 

-- Jeff

 

--_000_4A6CE49E6084B141B15C0713B8993F281BF3B915SJEXCHMB12corpa_-- From nobo@cisco.com Tue Nov 12 13:41:46 2013 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 92E7521F9F7F for ; Tue, 12 Nov 2013 13:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysQkb64J7y+z for ; Tue, 12 Nov 2013 13:41:40 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9122221E808A for ; Tue, 12 Nov 2013 13:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4563; q=dns/txt; s=iport; t=1384292500; x=1385502100; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jey/2TMkiRkTvULjPr1T7pEb51tYqamoG58lM594TzA=; b=aIFtNKRuHpkcsAY9s33lDSZ4OIYNlaiJMwvKFRZfvWp6Vo7Vq4HjZfH9 eXWW7Xbdd8UNZ3a7POQ79SZP9VX6G9xSFdmWVEkJx09Lm5Qwbrzdnk0XO X4g8SOgUKzHQ8pUxmln4ixM8vzSmjSUqnfQAZrpwRvZI7rKY2smgt5wmW 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAIifglKtJV2Z/2dsb2JhbABagmYhgQu/HYEqFnSCJQEBAQQ6LRIMBAIBCA4DBAEBAQoUCQcyFAkIAQEEDgUIE4dmAb9CjhWBGTEHBoMagREDqhmDJoIq X-IronPort-AV: E=Sophos;i="4.93,687,1378857600"; d="scan'208";a="283732338" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 12 Nov 2013 21:41:40 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rACLfdEv010390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 21:41:39 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 15:41:39 -0600 From: "Nobo Akiya (nobo)" To: Jeffrey Haas , "Bhatia, Manav (Manav)" Subject: RE: Security aspects with S-BFD Thread-Topic: Security aspects with S-BFD Thread-Index: Ac7b2ToBrFn7tnaZR4yTSVGAJsb+GwEQ1aaAAAvVdqA= Date: Tue, 12 Nov 2013 21:41:39 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C32E4FACB1@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20131112210053.GK15347@pfrc> In-Reply-To: <20131112210053.GK15347@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 12 Nov 2013 21:41:46 -0000 Hi Jeff, Manav, Santosh, Glen, et al, An interesting aspect was brought up during internal discussions. Leaving a= side DoS aspect, S-BFD itself provides slight increase in security, as sing= le hi-jacked packet (w/ down state) can no longer taken down a session. i.e= . at initiator, it's getting the response packets that keeps session up. Al= though flip-flop of received states can raise alarm in initiator implementa= tions, it doesn't translate to automatic down. Regarding the DoS [to reflector session] aspect, IMO, what you described ap= pear to provide reasonable security to progress the solution, i.e. authenti= cation itself and in combination with ACL filters. For further security [w/= real sequencing], yes I agree that small table maintenance by reflector se= ssion will be required, but opens up list of issues to consider in implemen= tations (not necessary in protocols). Perhaps this portion can be described= in base appendix. -Nobo > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Jeffrey Haas > Sent: Tuesday, November 12, 2013 4:01 PM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: Re: Security aspects with S-BFD >=20 > Manav, >=20 > On Thu, Nov 07, 2013 at 04:48:47PM +0000, Bhatia, Manav (Manav) wrote: > > 1. The Initiator picks up a crypto sequence number depending upon the > authentication mode that its using (meticulous or non meticulous). It sen= ds > a packet to the Reflector with this seq num. > > > > 2. The reflector maintains no session state and hence does not look at = the > crypto sequence number before accepting the packet. It looks at the Key I= D > (draft-ietf-bfd-generic-crypto-auth-05) in the incoming packet (or it can= do > it based on its own database where it maps the neighbor to the key iD) an= d > verifies the authentication data. If everything looks good, it processes = the > packet. > > > > 3. When responding the Reflector needs to compute the Authentication > data. It uses the same sequence number that it received in the S-BFD pack= et > that it is responding to. It knows the Key ID, and thus the SA. It comput= es > the authentication data and sends the S-BFD packet out. > > > > 4. The Initiator receives the response from the Reflector. It only > > accepts the S-BFD packet if it either comes with the same sequence > > number as it had sent or its within the window that it finds > > acceptable (described in detail in Sec 3.4 of > > draft-ietf-bfd-generic-crypto-auth-05) > > > > Benefits of this scheme. > > > > 1. Reflectors continue to remain stateless despite using security. >=20 > It would be good to see some discussion from the S-BFD authors regarding > light-weight state for authentication. In other words, just enough to ve= rify > crypto sequence numbers. >=20 > One challenge that immediately comes to mind is that since the sessions > are completely stateless, this means the reflector really can't know if t= he > initiator rebooted or not, especially if the initiator is foolish enough = to have > the same discriminator. >=20 > > 2. Reflectors are not susceptible to replay attacks as they always resp= ond > to S-BFD packets irrespective of the sequence number carried. > > > > 3. An attacker cannot forge packets from the Reflector since the Initia= tor > will only accept S-BFD packets that come with the sequence number that it > had originally used when sending the S-BFD packet. >=20 > Protecting the Initiator is good. But ... >=20 > > Drawbacks of this scheme. > > > > 1. Reflectors are susceptible to DoS attacks since they respond to all > incoming S-BFD packets. This gets worse when cryptography is used as the > work load drastically increases as security is employed. >=20 > This continues to be my primary concern about the security for this featu= re. > In the absence of *any* state, it's very difficult to have a low-work fil= ter that > protects the Reflector against cryptographic work attacks. >=20 > Also, as best I understand several of the potential use cases for this fe= ature, > every S-BFD node may end up being a Reflector in some of those cases. >=20 > To take a post-WG session comment to heart, this feature does have severa= l > resemblances to simply using IP Ping. This means that several of the > security considerations associated with ICMP attacks (rate limiting, etc.= ) are > likely applicable. >=20 > > Cheers, Manav >=20 > -- Jeff From jhaas@slice.pfrc.org Tue Nov 12 13:55:00 2013 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 8EE5721F9FC7 for ; Tue, 12 Nov 2013 13:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.225 X-Spam-Level: X-Spam-Status: No, score=-102.225 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4D70BNu0IXGg for ; Tue, 12 Nov 2013 13:54:56 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 81D3721F9D28 for ; Tue, 12 Nov 2013 13:54:56 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3A152C2F0; Tue, 12 Nov 2013 16:54:56 -0500 (EST) Date: Tue, 12 Nov 2013 16:54:56 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: Poll - working group adoption of draft-akiya-bfd-intervals Message-ID: <20131112215456.GO15347@pfrc> References: <20131112203701.GI15347@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131112203701.GI15347@pfrc> 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: Tue, 12 Nov 2013 21:55:00 -0000 On Tue, Nov 12, 2013 at 03:37:01PM -0500, Jeffrey Haas wrote: > Part of our discussion at IETF 88 in Vancouver was with regard to the draft > "Standardized interval support in BFD", draft-akiya-bfd-intervals. The authors have been requested to refresh the document. At the moment, here's a link to the last published version. http://tools.ietf.org/html/draft-akiya-bfd-intervals-03 -- Jeff From nobo@cisco.com Tue Nov 12 13:55:17 2013 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 A65E321F9D28 for ; Tue, 12 Nov 2013 13:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.568 X-Spam-Level: X-Spam-Status: No, score=-10.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOU0+SdeeDeV for ; Tue, 12 Nov 2013 13:55:11 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2D71021F9FC7 for ; Tue, 12 Nov 2013 13:55:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10082; q=dns/txt; s=iport; t=1384293311; x=1385502911; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=M4G7iyIbPQ6sM24HisvJRXMwlFQezqPe0YyhTIw1LEc=; b=nAF1RhwSegZuLomiFoLgHTsrHOFyt2cw2hpyzrxDa7Q2Arz3E2KYouL0 Rsdv2tRGWQSZjqgPH9Lt+MNxUOPe40emDWNHxASBSk8V3/cPzxBwczxGS V2oHZil1gvjgiR46F9wT46L5mYZBO0mXjZCeFKQKitpY0Da91WgvdDG9H I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFABOjglKtJXG//2dsb2JhbABagkMjIThTvyOBKhZ0giUBAQEELUEXBAIBCBEEAQELHQcyFAkIAgQBEgiHeQG/O48uNwEGgxqBEQOqGYMmgio X-IronPort-AV: E=Sophos;i="4.93,688,1378857600"; d="scan'208,217";a="283738651" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 12 Nov 2013 21:55:10 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rACLtAdG016944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 21:55:10 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 15:55:09 -0600 From: "Nobo Akiya (nobo)" To: Shahram Davari , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Poll - working group adoption of draft-akiya-bfd-intervals Thread-Topic: Poll - working group adoption of draft-akiya-bfd-intervals Thread-Index: AQHO3+cBmJlVxINYJE6TrpXnwRW3iJoigg2A//+eQiA= Date: Tue, 12 Nov 2013 21:55:09 +0000 Message-ID: References: <20131112203701.GI15347@pfrc> <4A6CE49E6084B141B15C0713B8993F281BF3B915@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BF3B915@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941DEE29CExmbalnx01ciscoc_" MIME-Version: 1.0 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, 12 Nov 2013 21:55:17 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941DEE29CExmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Shahram, Agree, there are specific base timer values that would be beneficial to sup= port. For next revision (for BCP) is really to aim for much wider interval = spectrum by describing techniques using few timer sets: i.e. few timers & m= ultiple of those timers + jitter considerations. -Nobo From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Shahram Davari Sent: Tuesday, November 12, 2013 4:32 PM To: Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: Poll - working group adoption of draft-akiya-bfd-intervals Hi Jeff, I support defining a list of intervals that must be supported. However I wo= uld like to propose matching the rates to the ETH-OAM, since most of HW OAM engines must support both BFD and ETH-OAM. Y.1731 rates are: 3.3ms, 10ms, 100ms, 1s, 10s, 1min, 10min. Thx Shahram -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg= -bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Tuesday, November 12, 2013 12:37 PM To: rtg-bfd@ietf.org Subject: Poll - working group adoption of draft-akiya-bfd-intervals Working Group, Part of our discussion at IETF 88 in Vancouver was with regard to the draft "Standardized interval support in BFD", draft-akiya-bfd-intervals. Prior discussion of this draft suggested that making the intervals mandator= y was probably over-reaching the work we'd like to do. However, there's interest in pursuing this work in an Informational context. A longer term goal of the document would be to achieve Best Current Practice (BCP) status= . A poll of the room in Vancouver indicated good support to take on this work= . Since this is somewhat out of our current charter, we'd be seeking a re-charter to cover this specific task. Please indicate to the Working Group mailing list if you'd support or don't support adoption of this draft as a Working Group document. If there is sufficient support, we'll initiate the re-chartering, probably along with the S-BFD work. -- Jeff --_000_CECE764681BE964CBE1DFF78F3CDD3941DEE29CExmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Shahram,=

 

Agree, there are speci= fic base timer values that would be beneficial to support. For next revisio= n (for BCP) is really to aim for much wider interval spectrum by describing= techniques using few timer sets: i.e. few timers & multiple of those timers + jitter considerations.

 

-Nobo

 

From: rtg-bfd-= bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Shahram Davari
Sent: Tuesday, November 12, 2013 4:32 PM
To: Jeffrey Haas; rtg-bfd@ietf.org
Subject: RE: Poll - working group adoption of draft-akiya-bfd-interv= als

 

Hi Jeff,

 

I support defining a list of intervals that must = be supported. However I would like to propose matching the rates to the

ETH-OAM, since most of HW OAM engines must suppor= t both BFD and ETH-OAM.

 

Y.1731 rates are:

 

3.3ms, 10ms, 100ms, 1s, 10s, 1min, 10min.

 

Thx

Shahram

 

 

 

-----Original Message-----
From: rtg-bfd-bounces@ietf.org<= /a> [mailto:rtg-bfd-bounces@iet= f.org] On Behalf Of Jeffrey Haas
Sent: Tuesday, November 12, 2013 12:37 PM
To: rtg-bfd@ietf.org
Subject: Poll - working group adoption of draft-akiya-bfd-intervals

 

Working Group,

 

Part of our discussion at IETF 88 in Vancouver wa= s with regard to the draft

"Standardized interval support in BFD",= draft-akiya-bfd-intervals.

 

Prior discussion of this draft suggested that mak= ing the intervals mandatory

was probably over-reaching the work we'd like to = do.  However, there's

interest in pursuing this work in an Informationa= l context.  A longer term

goal of the document would be to achieve Best Cur= rent Practice (BCP) status.

 

A poll of the room in Vancouver indicated good su= pport to take on this work.

Since this is somewhat out of our current charter= , we'd be seeking a

re-charter to cover this specific task.

 

Please indicate to the Working Group mailing list= if you'd support or don't

support adoption of this draft as a Working Group= document.

 

If there is sufficient support, we'll initiate th= e re-chartering, probably

along with the S-BFD work.

 

-- Jeff

 

--_000_CECE764681BE964CBE1DFF78F3CDD3941DEE29CExmbalnx01ciscoc_-- From gregory.mirsky@ericsson.com Tue Nov 12 13:57:28 2013 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 BE29521E80E4 for ; Tue, 12 Nov 2013 13:57:26 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnVdKg2T+M83 for ; Tue, 12 Nov 2013 13:57:21 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 4263C21F9FC7 for ; Tue, 12 Nov 2013 13:57:21 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-17-5282a43f13ef Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E7.A5.04556.F34A2825; Tue, 12 Nov 2013 22:57:19 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Tue, 12 Nov 2013 16:57:16 -0500 From: Gregory Mirsky To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Poll - working group adoption of draft-akiya-bfd-intervals Thread-Topic: Poll - working group adoption of draft-akiya-bfd-intervals Thread-Index: AQHO3+cAUOUzwERwyECVDkx/FQRsR5oid6kA//+sYvA= Date: Tue, 12 Nov 2013 21:57:16 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7109F9@eusaamb103.ericsson.se> References: <20131112203701.GI15347@pfrc> <20131112215456.GO15347@pfrc> In-Reply-To: <20131112215456.GO15347@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyuXRPgq79kqYgg18nVSz2H3zLavH5zzZG ByaPJUt+Mnlc7t3KGsAUxWWTkpqTWZZapG+XwJXx5OtzloLzbBUXZ/1iaWDcx9rFyMkhIWAi sbrlLguELSZx4d56ti5GLg4hgSOMEkuX3GKEcJYzSqyfdQSsg03ASOLFxh52EFtEwEOi+9hz RhBbWMBdYtfGPaww8bWPTjNC2FYS71pmg9WzCKhKzP74hg3E5hXwlVj38x3YZiGg3uenZoDZ nAJaEkc7VoH1MgJd9P3UGiYQm1lAXOLWk/lMEJcKSCzZc54ZwhaVePn4H9Q3yhLf5zxigajX kViw+xMbhK0tsWzha2aIvYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkaO0uLUstx0I8NN jMB4OCbB5riDccEny0OM0hwsSuK8X946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgnKD5 wZf9Sp2ik2f+/aqX4fZ9x+fVb2u6b/c5/0jvz4UXpqmsPbzk5sN099gFyfwa4jM9yg/Ztzf8 q/y0hK/64L9n4uuWPFx060euo/e0PVleP9laBR496gp6NaNNxyAxqnMD5z+fYENBhopfRf+0 PL1v7eX/EZHTkj2nS1rkq7HKSj+1X3/PKrEUZyQaajEXFScCAIUPKp1VAgAA 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, 12 Nov 2013 21:57:28 -0000 Hello, I'd note that current version is targeting document for Standard track. Hop= e authors would consider changing to Informational track instead. Regards, Greg -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Jeffrey Haas Sent: Tuesday, November 12, 2013 1:55 PM To: rtg-bfd@ietf.org Subject: Re: Poll - working group adoption of draft-akiya-bfd-intervals On Tue, Nov 12, 2013 at 03:37:01PM -0500, Jeffrey Haas wrote: > Part of our discussion at IETF 88 in Vancouver was with regard to the=20 > draft "Standardized interval support in BFD", draft-akiya-bfd-intervals. The authors have been requested to refresh the document. At the moment, he= re's a link to the last published version. http://tools.ietf.org/html/draft-akiya-bfd-intervals-03 -- Jeff From marc@sniff.de Tue Nov 12 14:02:07 2013 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 E182511E810C for ; Tue, 12 Nov 2013 14:02:07 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zso-+NT7bcEl for ; Tue, 12 Nov 2013 14:02:07 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4190F11E810B for ; Tue, 12 Nov 2013 14:02:07 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 5A4142AA0F; Tue, 12 Nov 2013 22:02:05 +0000 (GMT) Date: Tue, 12 Nov 2013 14:02:03 -0800 From: Marc Binderberger To: Shahram Davari Message-ID: <20131112140203843331.d33e9a12@sniff.de> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BF3B915@SJEXCHMB12.corp.ad.broadcom.com> References: <20131112203701.GI15347@pfrc> <4A6CE49E6084B141B15C0713B8993F281BF3B915@SJEXCHMB12.corp.ad.broadcom.com> Subject: RE: Poll - working group adoption of draft-akiya-bfd-intervals MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.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: Tue, 12 Nov 2013 22:02:08 -0000 Hello Shahram, this is on the list of things to be updated and further discussed. Point is: where it doesn't hurt existing BFD implementations: ok. But BFD is not a greenfield protocol anymore and in reality you find quite a number of (software-based) implementations that run as fast as 50msec while 10msec is a bit of a stretch. The Y.1731 intervals would not necessarily fit the demand in the mid-milisecond range. Regards, Marc On Tue, 12 Nov 2013 21:32:07 +0000, Shahram Davari wrote: > Hi Jeff, > > I support defining a list of intervals that must be supported. > However I would like to propose matching the rates to the > ETH-OAM, since most of HW OAM engines must support both BFD and ETH-OAM. > > Y.1731 rates are: > > 3.3ms, 10ms, 100ms, 1s, 10s, 1min, 10min. > > Thx > Shahram > > > > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Jeffrey Haas > Sent: Tuesday, November 12, 2013 12:37 PM > To: rtg-bfd@ietf.org > Subject: Poll - working group adoption of draft-akiya-bfd-intervals > > Working Group, > > Part of our discussion at IETF 88 in Vancouver was with regard to the draft > "Standardized interval support in BFD", draft-akiya-bfd-intervals. > > Prior discussion of this draft suggested that making the intervals mandatory > was probably over-reaching the work we'd like to do. However, there's > interest in pursuing this work in an Informational context. A longer term > goal of the document would be to achieve Best Current Practice (BCP) status. > > A poll of the room in Vancouver indicated good support to take on this work. > Since this is somewhat out of our current charter, we'd be seeking a > re-charter to cover this specific task. > > Please indicate to the Working Group mailing list if you'd support or don't > support adoption of this draft as a Working Group document. > > If there is sufficient support, we'll initiate the re-chartering, probably > along with the S-BFD work. > > -- Jeff > From marc@sniff.de Tue Nov 12 14:10:46 2013 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 2B62D21E80E4 for ; Tue, 12 Nov 2013 14:10:46 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbv4B1ob36AZ for ; Tue, 12 Nov 2013 14:10:45 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 619FB21F9EF2 for ; Tue, 12 Nov 2013 14:10:45 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id A6D5E2AA0F; Tue, 12 Nov 2013 22:10:43 +0000 (GMT) Date: Tue, 12 Nov 2013 14:10:41 -0800 From: Marc Binderberger To: Gregory Mirsky Message-ID: <20131112141041928300.d003510e@sniff.de> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7109F9@eusaamb103.ericsson.se> References: <20131112203701.GI15347@pfrc> <20131112215456.GO15347@pfrc> <7347100B5761DC41A166AC17F22DF1121B7109F9@eusaamb103.ericsson.se> Subject: RE: Poll - working group adoption of draft-akiya-bfd-intervals MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.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: Tue, 12 Nov 2013 22:10:46 -0000 Hello Gregory, yes, that's the agreement: make it informational. We are jut updating the document, mainly these few formal aspects, to have a cleaner re-start situation. Regards, Marc On Tue, 12 Nov 2013 21:57:16 +0000, Gregory Mirsky wrote: > Hello, > I'd note that current version is targeting document for Standard > track. Hope authors would consider changing to Informational track > instead. > > Regards, > Greg > > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Jeffrey Haas > Sent: Tuesday, November 12, 2013 1:55 PM > To: rtg-bfd@ietf.org > Subject: Re: Poll - working group adoption of draft-akiya-bfd-intervals > > On Tue, Nov 12, 2013 at 03:37:01PM -0500, Jeffrey Haas wrote: >> Part of our discussion at IETF 88 in Vancouver was with regard to the >> draft "Standardized interval support in BFD", draft-akiya-bfd-intervals. > > The authors have been requested to refresh the document. At the > moment, here's a link to the last published version. > > http://tools.ietf.org/html/draft-akiya-bfd-intervals-03 > > -- Jeff > From gregory.mirsky@ericsson.com Tue Nov 12 14:12:13 2013 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 6B18F21E813C for ; Tue, 12 Nov 2013 14:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftqzDFyCm9Td for ; Tue, 12 Nov 2013 14:12:06 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id B037E21F9EF2 for ; Tue, 12 Nov 2013 14:12:06 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-5b-5282a7af6c4d Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 95.66.04556.0B7A2825; Tue, 12 Nov 2013 23:12:00 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Tue, 12 Nov 2013 17:11:59 -0500 From: Gregory Mirsky To: Shahram Davari , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Poll - working group adoption of draft-akiya-bfd-intervals Thread-Topic: Poll - working group adoption of draft-akiya-bfd-intervals Thread-Index: AQHO3+cAUOUzwERwyECVDkx/FQRsR5oicUmA//+zQmA= Date: Tue, 12 Nov 2013 22:11:59 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B710A2C@eusaamb103.ericsson.se> References: <20131112203701.GI15347@pfrc> <4A6CE49E6084B141B15C0713B8993F281BF3B915@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BF3B915@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B710A2Ceusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyuXRPuO6G5U1BBgt6pCzW93pa7D/4ltXi 859tjA7MHrPun2XzWLLkJ5PH5d6trAHMUVw2Kak5mWWpRfp2CVwZlx/PYinYFFqx69tclgbG N55djBwcEgImErcOJ3QxcgKZYhIX7q1nA7GFBI4wStx7a93FyAVkL2eUmPZuOliCTcBI4sXG HnaQXhGBAomnz4pBwsIC7hK7Nu5hBbFFBDwk1j46zQhRYiXR8bUGJMwioCoxedEHsBJeAV+J 07NOMUOsKpP4/X46E4jNKRAucfTyfTCbEeic76fWgNnMAuISt57MZ4I4U0BiyZ7zzBC2qMTL x/9YIWxlie9zHrFA1OdLzLr6ghlil6DEyZlPWCYwisxCMmoWkrJZSMog4joSC3Z/YoOwtSWW LXzNDGOfOfCYCVl8ASP7KkaO0uLUstx0I8NNjMBIOibB5riDccEny0OM0hwsSuK8X946BwkJ pCeWpGanphakFsUXleakFh9iZOLglGpg1P28yZVZ0fZwwb2crRKGycL3XFpV/rK1MG5cvMdk QshR3dzg8OdXlLdzRHTd/bdbSV25frnNvzn3c6XsD11p7znEYqhwnKd3lewVaaMGjomFp0rW n9z24KSq3qIsZUvX17yXJLxnCNsIfedR/Gj04fzX32WluQpruTmcNGfL6VzedCNrzkMDJZbi jERDLeai4kQArLPYMXICAAA= 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, 12 Nov 2013 22:12:13 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B710A2Ceusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Shahram, et. al, I agree that better alignment with Ethernet OAM is beneficial. Adding 100 m= s, 10 sec, and 1 min would be step in that direction. 10 min might be not r= eally practical. But I want to remind that BFD and Ethernet CFM differently interpret time i= nterval and, as result, when connectivity failure gets detected. For BFD ba= sed CC/CV, if Detect Multiplier =3D=3D 3 and Interval =3D=3D 100msec, detec= tion would be between 225msec and 300msec. For Ethernet OAM CCM with interv= al 100msec detection would be between 300msec and 325msec. So, as we see ha= ving intervals same in BFD and Ethernet OAM makes interworking only somewha= t easier. Regards, Greg From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Shahram Davari Sent: Tuesday, November 12, 2013 1:32 PM To: Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: Poll - working group adoption of draft-akiya-bfd-intervals Hi Jeff, I support defining a list of intervals that must be supported. However I wo= uld like to propose matching the rates to the ETH-OAM, since most of HW OAM engines must support both BFD and ETH-OAM. Y.1731 rates are: 3.3ms, 10ms, 100ms, 1s, 10s, 1min, 10min. Thx Shahram -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg= -bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Tuesday, November 12, 2013 12:37 PM To: rtg-bfd@ietf.org Subject: Poll - working group adoption of draft-akiya-bfd-intervals Working Group, Part of our discussion at IETF 88 in Vancouver was with regard to the draft "Standardized interval support in BFD", draft-akiya-bfd-intervals. Prior discussion of this draft suggested that making the intervals mandator= y was probably over-reaching the work we'd like to do. However, there's interest in pursuing this work in an Informational context. A longer term goal of the document would be to achieve Best Current Practice (BCP) status= . A poll of the room in Vancouver indicated good support to take on this work= . Since this is somewhat out of our current charter, we'd be seeking a re-charter to cover this specific task. Please indicate to the Working Group mailing list if you'd support or don't support adoption of this draft as a Working Group document. If there is sufficient support, we'll initiate the re-chartering, probably along with the S-BFD work. -- Jeff --_000_7347100B5761DC41A166AC17F22DF1121B710A2Ceusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Shahram, et. al,

I agree that better al= ignment with Ethernet OAM is beneficial. Adding 100 ms, 10 sec, and 1 min w= ould be step in that direction. 10 min might be not really practical.<= /o:p>

But I want to remind t= hat BFD and Ethernet CFM differently interpret time interval and, as result= , when connectivity failure gets detected. For BFD based CC/CV, if Detect M= ultiplier =3D=3D 3 and Interval =3D=3D 100msec, detection would be between 225msec and 300msec. For Ethernet OAM CCM with = interval 100msec detection would be between 300msec and 325msec. So, as we = see having intervals same in BFD and Ethernet OAM makes interworking only s= omewhat easier.

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: rtg-bfd-= bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Shahram Davari
Sent: Tuesday, November 12, 2013 1:32 PM
To: Jeffrey Haas; rtg-bfd@ietf.org
Subject: RE: Poll - working group adoption of draft-akiya-bfd-interv= als

 

Hi Jeff,

 

I support defining a list of intervals that must = be supported. However I would like to propose matching the rates to the

ETH-OAM, since most of HW OAM engines must suppor= t both BFD and ETH-OAM.

 

Y.1731 rates are:

 

3.3ms, 10ms, 100ms, 1s, 10s, 1min, 10min.

 

Thx

Shahram

 

 

 

-----Original Message-----
From: rtg-bfd-bounces@ietf.org<= /a> [mailto:rtg-bfd-bounces@iet= f.org] On Behalf Of Jeffrey Haas
Sent: Tuesday, November 12, 2013 12:37 PM
To: rtg-bfd@ietf.org
Subject: Poll - working group adoption of draft-akiya-bfd-intervals

 

Working Group,

 

Part of our discussion at IETF 88 in Vancouver wa= s with regard to the draft

"Standardized interval support in BFD",= draft-akiya-bfd-intervals.

 

Prior discussion of this draft suggested that mak= ing the intervals mandatory

was probably over-reaching the work we'd like to = do.  However, there's

interest in pursuing this work in an Informationa= l context.  A longer term

goal of the document would be to achieve Best Cur= rent Practice (BCP) status.

 

A poll of the room in Vancouver indicated good su= pport to take on this work.

Since this is somewhat out of our current charter= , we'd be seeking a

re-charter to cover this specific task.

 

Please indicate to the Working Group mailing list= if you'd support or don't

support adoption of this draft as a Working Group= document.

 

If there is sufficient support, we'll initiate th= e re-chartering, probably

along with the S-BFD work.

 

-- Jeff

 

--_000_7347100B5761DC41A166AC17F22DF1121B710A2Ceusaamb103erics_-- From gregory.mirsky@ericsson.com Tue Nov 12 14:24:23 2013 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 B336111E80E9 for ; Tue, 12 Nov 2013 14:24:23 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfgpWhzHE3jT for ; Tue, 12 Nov 2013 14:24:17 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6B911E810B for ; Tue, 12 Nov 2013 14:24:17 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-1a-5282aa90149f Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9A.F6.04556.09AA2825; Tue, 12 Nov 2013 23:24:16 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Tue, 12 Nov 2013 17:24:16 -0500 From: Gregory Mirsky To: Marc Binderberger , Shahram Davari Subject: RE: Poll - working group adoption of draft-akiya-bfd-intervals Thread-Topic: Poll - working group adoption of draft-akiya-bfd-intervals Thread-Index: AQHO3+cAUOUzwERwyECVDkx/FQRsR5oicUmAgAAIXYD//7CwUA== Date: Tue, 12 Nov 2013 22:24:15 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B710A74@eusaamb103.ericsson.se> References: <20131112203701.GI15347@pfrc> <4A6CE49E6084B141B15C0713B8993F281BF3B915@SJEXCHMB12.corp.ad.broadcom.com> <20131112140203843331.d33e9a12@sniff.de> In-Reply-To: <20131112140203843331.d33e9a12@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyuXSPn+6EVU1BBnO71CzW93pazL7yn9ni 859tjA7MHrPun2XzWLLkJ5NH6+pulgDmKC6blNSczLLUIn27BK6Ms0d3MBZMF62YfecGcwPj C4EuRk4OCQETiecXPjJD2GISF+6tZ+ti5OIQEjjCKNHwYy8LSEJIYDmjxNmlziA2m4CRxIuN PewgtoiAt8Skrr1MIDazgKZE04nPYHFhAXeJXRv3sELUeEisfXSaEcJ2kji58xlYnEVAVWLr 1F6wOK+Ar8SmJduYIRYvZJT4fWkKWBGngKlE68NLYEMZga77fmoN1DJxiVtP5jNBXC0gsWTP eagPRCVePv7HCmErS3yf84gFol5HYsHuT2wQtrbEsoWvmSEWC0qcnPmEZQKj2CwkY2chaZmF pGUWkpYFjCyrGDlKi1PLctONDDcxAiPnmASb4w7GBZ8sDzFKc7AoifN+eescJCSQnliSmp2a WpBaFF9UmpNafIiRiYNTqoHRVubyD20LFXshfkcPHTVV3tUzLlqWPWF68/TudqdQLvdEUwOn AgOlq3u8Yi6JSa1nCjh9fNXEzfkM2ziLl6/jP7xv82NpFlGTNeGmW9Y++tAjqrgkvjm3rkBT 6+cvh5kODTMKMu3Yex5NfvuiL3gFw4F9v4wnpkS8q46KrAwo8xY6/sv40zslluKMREMt5qLi RAC1aluIagIAAA== 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, 12 Nov 2013 22:24:23 -0000 Hi Marc, I think that MPLS-TP CC/CV presents a good case where support of 3.3msec an= d 10msec is somewhat of a SHOULD if not a MUST. It can be explained in the = Informational document, I think. I can write a paragraph or two. Regards, Greg -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Marc Binderberger Sent: Tuesday, November 12, 2013 2:02 PM To: Shahram Davari Cc: rtg-bfd@ietf.org Subject: RE: Poll - working group adoption of draft-akiya-bfd-intervals Hello Shahram, this is on the list of things to be updated and further discussed.=20 Point is: where it doesn't hurt existing BFD implementations: ok. But BFD i= s not a greenfield protocol anymore and in reality you find quite a number = of (software-based) implementations that run as fast as 50msec while 10msec= is a bit of a stretch.=20 The Y.1731 intervals would not necessarily fit the demand in the mid-milise= cond range. Regards, Marc On Tue, 12 Nov 2013 21:32:07 +0000, Shahram Davari wrote: > Hi Jeff, > =20 > I support defining a list of intervals that must be supported.=20 > However I would like to propose matching the rates to the > ETH-OAM, since most of HW OAM engines must support both BFD and ETH-OAM. > =20 > Y.1731 rates are: > =20 > 3.3ms, 10ms, 100ms, 1s, 10s, 1min, 10min. > =20 > Thx > Shahram > =20 > =20 > =20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 > Behalf Of Jeffrey Haas > Sent: Tuesday, November 12, 2013 12:37 PM > To: rtg-bfd@ietf.org > Subject: Poll - working group adoption of draft-akiya-bfd-intervals > =20 > Working Group, > =20 > Part of our discussion at IETF 88 in Vancouver was with regard to the dra= ft > "Standardized interval support in BFD", draft-akiya-bfd-intervals. > =20 > Prior discussion of this draft suggested that making the intervals mandat= ory > was probably over-reaching the work we'd like to do. However, there's > interest in pursuing this work in an Informational context. A longer ter= m > goal of the document would be to achieve Best Current Practice (BCP) stat= us. > =20 > A poll of the room in Vancouver indicated good support to take on this wo= rk. > Since this is somewhat out of our current charter, we'd be seeking a > re-charter to cover this specific task. > =20 > Please indicate to the Working Group mailing list if you'd support or don= 't > support adoption of this draft as a Working Group document. > =20 > If there is sufficient support, we'll initiate the re-chartering, probabl= y > along with the S-BFD work. > =20 > -- Jeff > =20 From mjethanandani@gmail.com Tue Nov 12 15:11:16 2013 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 C74A011E814D for ; Tue, 12 Nov 2013 15:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cg3gzT5Ho7yg for ; Tue, 12 Nov 2013 15:11:01 -0800 (PST) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id C7D6B21E8095 for ; Tue, 12 Nov 2013 15:11:01 -0800 (PST) Received: by mail-pb0-f53.google.com with SMTP id up7so7639788pbc.12 for ; Tue, 12 Nov 2013 15:11:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=RS/MkG3l46vvi0itdXKmPpDMSOdSqYQd9NDITMHYjTw=; b=hMIpaEfFDzPtj7TN7EURdmqKltnxd2KK7AGL35ziNaczuZahK/A5WSwKQoejhUXzW8 0aPqStLVjK3xhTnxr0wUb+pw+WRLt1moQBhTHNXfGcYdLRW/4qdB0g/ICEZpV6qX/rWo iJc0FO7LLHoSZ3NMwlaoM1o+6cov1lncPZ7GoCuc8k+d1SW5+tSK7pK/f/Rp0naUfErB noJhReV2ZRiPBJaO1XhjYfjPkrVpZ1BQ/w4vpgefhHSvgw4HAAStX+4JIh3qhZ3G/jqx acYJ/V0dL23A63mzIz4WA2mOSf9O+FB2kmufePZdsOT3vC0ogRIzE4HhTacXRzaNa/pg ubpQ== X-Received: by 10.68.218.165 with SMTP id ph5mr37898428pbc.11.1384297861406; Tue, 12 Nov 2013 15:11:01 -0800 (PST) Received: from [10.10.206.4] (mobile-166-137-215-029.mycingular.net. [166.137.215.29]) by mx.google.com with ESMTPSA id gx11sm30881059pbd.37.2013.11.12.15.10.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Nov 2013 15:10:56 -0800 (PST) References: <20131112203701.GI15347@pfrc> Mime-Version: 1.0 (1.0) In-Reply-To: <20131112203701.GI15347@pfrc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0375F834-23B8-44A7-9650-ADC23F40090A@gmail.com> X-Mailer: iPhone Mail (10B329) From: Mahesh Jethanandani Subject: Re: Poll - working group adoption of draft-akiya-bfd-intervals Date: Tue, 12 Nov 2013 15:10:53 -0800 To: Jeffrey Haas 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, 12 Nov 2013 23:11:16 -0000 Support.=20 Mahesh Jethanandani=20 mjethanandani@gmail.com On Nov 12, 2013, at 12:37 PM, Jeffrey Haas wrote: > Working Group, >=20 > Part of our discussion at IETF 88 in Vancouver was with regard to the draf= t > "Standardized interval support in BFD", draft-akiya-bfd-intervals. >=20 > Prior discussion of this draft suggested that making the intervals mandato= ry > was probably over-reaching the work we'd like to do. However, there's > interest in pursuing this work in an Informational context. A longer term= > goal of the document would be to achieve Best Current Practice (BCP) statu= s. >=20 > A poll of the room in Vancouver indicated good support to take on this wor= k. > Since this is somewhat out of our current charter, we'd be seeking a > re-charter to cover this specific task. >=20 > Please indicate to the Working Group mailing list if you'd support or don'= t > support adoption of this draft as a Working Group document. >=20 > If there is sufficient support, we'll initiate the re-chartering, probably= > along with the S-BFD work. >=20 > -- Jeff From aldrin.ietf@gmail.com Tue Nov 12 16:22:34 2013 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 4EF5921E80BF for ; Tue, 12 Nov 2013 16:22:34 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIXeCa57RE2B for ; Tue, 12 Nov 2013 16:22:33 -0800 (PST) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A6D4E21E8098 for ; Tue, 12 Nov 2013 16:22:33 -0800 (PST) Received: by mail-qe0-f46.google.com with SMTP id s14so6279290qeb.33 for ; Tue, 12 Nov 2013 16:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Hj1Ta2Jjs7PrKA74Xv/lbZirjbcvMivf5UaEflOCt6g=; b=Ieyc9OWJr5ROHdXsjyH/woJx7h6KJfhkkRuc221X8gEJSGXTVYf/ieznKLTC0g4/wz sCz9u69PCiafxZg5UmgaPuJfjnTq9cNq+WXe6D8CV0KhHkZx1AK/O6dQJSpBHfusqX0p 6v+eDVEGzPEttoxCZqykNcrwhDUvLU55V1diFROUxbvTrGsaKsWwUoWGGJSGkvhtLNcQ xmBb4e2IaxShICr7S07a/o6P6XZJHIuU1yIeHOla4T411XUipJ7UY0AAOhTp1vvgFYaq vonza3xgTh4Bin+t+Kgw2IMdwrEvuelRc9hcXMxsN5i1EXwzZpR8oHtG5SFkuNz+3iAI Nt8A== MIME-Version: 1.0 X-Received: by 10.49.41.3 with SMTP id b3mr61207237qel.51.1384302152902; Tue, 12 Nov 2013 16:22:32 -0800 (PST) Received: by 10.96.177.232 with HTTP; Tue, 12 Nov 2013 16:22:32 -0800 (PST) In-Reply-To: <20131112203701.GI15347@pfrc> References: <20131112203701.GI15347@pfrc> Date: Tue, 12 Nov 2013 16:22:32 -0800 Message-ID: Subject: Re: Poll - working group adoption of draft-akiya-bfd-intervals From: Sam Aldrin To: Jeffrey Haas Content-Type: multipart/alternative; boundary=047d7bea33d615ecf904eb03f63d 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, 13 Nov 2013 00:22:34 -0000 --047d7bea33d615ecf904eb03f63d Content-Type: text/plain; charset=ISO-8859-1 I support this document to become WG document, informational as opposed to standards track. Would prefer it to become BCP with different scenarios captured and recommended intervals used in various deployments of the same. cheers -sam On Tue, Nov 12, 2013 at 12:37 PM, Jeffrey Haas wrote: > Working Group, > > Part of our discussion at IETF 88 in Vancouver was with regard to the draft > "Standardized interval support in BFD", draft-akiya-bfd-intervals. > > Prior discussion of this draft suggested that making the intervals > mandatory > was probably over-reaching the work we'd like to do. However, there's > interest in pursuing this work in an Informational context. A longer term > goal of the document would be to achieve Best Current Practice (BCP) > status. > > A poll of the room in Vancouver indicated good support to take on this > work. > Since this is somewhat out of our current charter, we'd be seeking a > re-charter to cover this specific task. > > Please indicate to the Working Group mailing list if you'd support or don't > support adoption of this draft as a Working Group document. > > If there is sufficient support, we'll initiate the re-chartering, probably > along with the S-BFD work. > > -- Jeff > --047d7bea33d615ecf904eb03f63d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I support this document to become WG document, i= nformational as opposed to standards track.
Would prefer it to bec= ome BCP with different scenarios captured and recommended intervals used in= various deployments of the same.

cheers
-sam


On Tue, Nov 12, 2013 at 12:37 PM, Jeffrey Haas <jhaas@pf= rc.org> wrote:
Working Group,

Part of our discussion at IETF 88 in Vancouver was with regard to the draft=
"Standardized interval support in BFD", draft-akiya-bfd-intervals= .

Prior discussion of this draft suggested that making the intervals mandator= y
was probably over-reaching the work we'd like to do. =A0However, there&= #39;s
interest in pursuing this work in an Informational context. =A0A longer ter= m
goal of the document would be to achieve Best Current Practice (BCP) status= .

A poll of the room in Vancouver indicated good support to take on this work= .
Since this is somewhat out of our current charter, we'd be seeking a re-charter to cover this specific task.

Please indicate to the Working Group mailing list if you'd support or d= on't
support adoption of this draft as a Working Group document.

If there is sufficient support, we'll initiate the re-chartering, proba= bly
along with the S-BFD work.

-- Jeff

--047d7bea33d615ecf904eb03f63d-- From mach.chen@huawei.com Tue Nov 12 16:57:56 2013 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 1A57721E80C1 for ; Tue, 12 Nov 2013 16:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.263 X-Spam-Level: X-Spam-Status: No, score=-6.263 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmtfYq5h5ueX for ; Tue, 12 Nov 2013 16:57:51 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EA64D11E8155 for ; Tue, 12 Nov 2013 16:57:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAE85467; Wed, 13 Nov 2013 00:57:46 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Nov 2013 00:57:28 +0000 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Nov 2013 00:57:42 +0000 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.159]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Wed, 13 Nov 2013 08:57:35 +0800 From: Mach Chen To: Sam Aldrin , Jeffrey Haas Subject: RE: Poll - working group adoption of draft-akiya-bfd-intervals Thread-Topic: Poll - working group adoption of draft-akiya-bfd-intervals Thread-Index: AQHO3+cAu4DHyk9K00+cxFpnXcNURJohxvgAgACPaUA= Date: Wed, 13 Nov 2013 00:57:35 +0000 Message-ID: References: <20131112203701.GI15347@pfrc> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25CF1F7A0szxeml558mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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, 13 Nov 2013 00:57:56 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25CF1F7A0szxeml558mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree. And support the adoption. Best regards, Mach From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Sam Aldrin Sent: Wednesday, November 13, 2013 8:23 AM To: Jeffrey Haas Cc: rtg-bfd@ietf.org Subject: Re: Poll - working group adoption of draft-akiya-bfd-intervals I support this document to become WG document, informational as opposed to = standards track. Would prefer it to become BCP with different scenarios captured and recomme= nded intervals used in various deployments of the same. cheers -sam On Tue, Nov 12, 2013 at 12:37 PM, Jeffrey Haas > wrote: Working Group, Part of our discussion at IETF 88 in Vancouver was with regard to the draft "Standardized interval support in BFD", draft-akiya-bfd-intervals. Prior discussion of this draft suggested that making the intervals mandator= y was probably over-reaching the work we'd like to do. However, there's interest in pursuing this work in an Informational context. A longer term goal of the document would be to achieve Best Current Practice (BCP) status= . A poll of the room in Vancouver indicated good support to take on this work= . Since this is somewhat out of our current charter, we'd be seeking a re-charter to cover this specific task. Please indicate to the Working Group mailing list if you'd support or don't support adoption of this draft as a Working Group document. If there is sufficient support, we'll initiate the re-chartering, probably along with the S-BFD work. -- Jeff --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25CF1F7A0szxeml558mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Agree.

=  

= And support the adoption.

=  

= Best regards,

= Mach

=  

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Sam Aldrin
Sent: Wednesday, November 13= , 2013 8:23 AM
To: Jeffrey Haas
Cc: rtg-bfd@ietf.org
Subject: Re: Poll - working = group adoption of draft-akiya-bfd-intervals

 

I support this document to become WG = document, informational as opposed to standards track.

Would prefer it to become BCP with di= fferent scenarios captured and recommended intervals used in various deploy= ments of the same.

cheers

-sam

&= nbsp;

On Tue, Nov 12, 2013 at 12:37 PM, Jef= frey Haas <jhaas@pfr= c.org> wrote:

Working Group,

Part of our discussion at IETF 88 in Vancouver was with regard to the draft=
"Standardized interval support in BFD", draft-akiya-bfd-intervals= .

Prior discussion of this draft suggested that making the intervals mandator= y
was probably over-reaching the work we'd like to do.  However, there's=
interest in pursuing this work in an Informational context.  A longer = term
goal of the document would be to achieve Best Current Practice (BCP) status= .

A poll of the room in Vancouver indicated good support to take on this work= .
Since this is somewhat out of our current charter, we'd be seeking a
re-charter to cover this specific task.

Please indicate to the Working Group mailing list if you'd support or don't=
support adoption of this draft as a Working Group document.

If there is sufficient support, we'll initiate the re-chartering, probably<= br> along with the S-BFD work.

-- Jeff

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25CF1F7A0szxeml558mbschi_-- From mach.chen@huawei.com Tue Nov 12 17:07:46 2013 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 D442D11E8163 for ; Tue, 12 Nov 2013 17:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.286 X-Spam-Level: X-Spam-Status: No, score=-6.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNKDEQkNKrVs for ; Tue, 12 Nov 2013 17:07:41 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC9421E813C for ; Tue, 12 Nov 2013 17:07:31 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAE85907; Wed, 13 Nov 2013 01:07:19 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Nov 2013 01:07:04 +0000 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Nov 2013 01:07:18 +0000 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.159]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.03.0158.001; Wed, 13 Nov 2013 09:07:14 +0800 From: Mach Chen To: Jeffrey Haas Subject: RE: WGLC for BFD base MIB and TC - ends November 8 Thread-Topic: WGLC for BFD base MIB and TC - ends November 8 Thread-Index: AQHO3mQ7d29rmKPEbUGsnzhYr0Jy/JogyEJg//+QogCAAIrvcIAAo9kAgADSQuA= Date: Wed, 13 Nov 2013 01:07:13 +0000 Message-ID: References: <20131024190612.GN17538@pfrc> <20131112202510.GG15347@pfrc> In-Reply-To: <20131112202510.GG15347@pfrc> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Carlos Pignataro \(cpignata\)" , "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, 13 Nov 2013 01:07:46 -0000 Hi Jeff, I am OK to progress the two drafts as it be.=20 As for the extension draft, yes, I am interesting. But based on the fact th= at there is only one element left, so maybe we could just wait and put it i= nto other extension draft in the future.=20 Best regards, Mach > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of > Jeffrey Haas > Sent: Wednesday, November 13, 2013 4:25 AM > To: Mach Chen > Cc: Carlos Pignataro (cpignata); rtg-bfd@ietf.org > Subject: Re: WGLC for BFD base MIB and TC - ends November 8 >=20 > Mach, >=20 > On Tue, Nov 12, 2013 at 02:51:39AM +0000, Mach Chen wrote: > > > [speaking as contributor to both LAG and MIB documents] > > > > > > Hi Mach, > > > > > > My thought on this is that BFD on LAG is a variant of single-hop > > > BFD, thus [LAG member, IP address] is sufficient to uniquely > > > describe an uBFD session. I know of an implementation that is using t= his > approach, and it seems to satisfy user needs. > > > > > > Certainly there's no OID to describe multicast MAC nor interface > > > MAC, of uBFD session. Benefit of being able to read such OID seems > > > very marginal. Whether anyone ever want to write to such OID (to > > > switch to/from multicast from/to interface MAC?) is also questionable= . > > > > Yes, I agree that it is very marginal. > > > > I am not sure whether there will be writing, but there should be readin= g of such > OID. >=20 > I spent some time reviewing the BFD MIBs specially with the LAG cases in = mind. > The conclusion I arrived at included the following: > - the *base* MIBs are capable of handling the subsets of behavior that ar= e > not feature specific to the BFD MPLS MIB or LAG scenarios. > - the superset of feature elements were largley covered by the port numbe= r > change. > - the one minor element was the mac address. > - As BFD continues to evolve, a single MIB can never address 100% of the = use > cases. >=20 > The latter is the main point here, I think. As you suggest, there's real= ly only a > single object (maybe two) that distinguishes the additional details of BF= D on LAG: > Whether we're using the multicast MAC as part of the procedures and what = the > MAC is for the session. >=20 > > The "multicast MAC or interface MAC" is just the one that came into my = mind, I > am not sure whether there are some uncovered places. > > > > If the "multicast MAC or interface MAC" is the only one need to be cons= idered, > IMHO, it's maybe easy to modify the BFD base MIB to fix it. >=20 > My suggestion would be that if you find that specific detail interesting,= it is > in-charter for the Working Group to add an extension MIB for the base MIB= for > the necessary feature-specific objects. >=20 > Did you have any interest in authoring that? >=20 > -- Jeff From jhaas@slice.pfrc.org Tue Nov 12 19:47:52 2013 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 BC0C421F9DC7 for ; Tue, 12 Nov 2013 19:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.226 X-Spam-Level: X-Spam-Status: No, score=-102.226 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMXVI+ApcPEr for ; Tue, 12 Nov 2013 19:47:47 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CD07521F9D7B for ; Tue, 12 Nov 2013 19:47:41 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1077FC2F0; Tue, 12 Nov 2013 22:47:41 -0500 (EST) Date: Tue, 12 Nov 2013 22:47:40 -0500 From: Jeffrey Haas To: Mach Chen Subject: Re: WGLC for BFD base MIB and TC - ends November 8 Message-ID: <20131113034740.GQ15347@pfrc> References: <20131024190612.GN17538@pfrc> <20131112202510.GG15347@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Carlos Pignataro \(cpignata\)" , "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, 13 Nov 2013 03:47:52 -0000 Mach, On Wed, Nov 13, 2013 at 01:07:13AM +0000, Mach Chen wrote: > I am OK to progress the two drafts as it be. Excellent. That clears the last comment on those drafts. > As for the extension draft, yes, I am interesting. But based on the fact that there is only one element left, so maybe we could just wait and put it into other extension draft in the future. The objects in question would be particular to the LAGs extension. It would thus be appropriate for them to go into a standalone draft. This would allow implementations that do not support the LAG feature to not have their SNMP implementations entangled with other features in such a MIB. -- Jeff From mach.chen@huawei.com Tue Nov 12 23:41:51 2013 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 9C92621E8099 for ; Tue, 12 Nov 2013 23:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoNvrdlgxkhJ for ; Tue, 12 Nov 2013 23:41:46 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E688721E808D for ; Tue, 12 Nov 2013 23:41:45 -0800 (PST) Received: from 172.18.7.233 (EHLO lhrrgout.huawei.com) ([172.18.7.233]) by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AOL80948; Wed, 13 Nov 2013 01:35:09 -0600 (CST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXV12126; Wed, 13 Nov 2013 05:49:47 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Nov 2013 05:48:32 +0000 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Nov 2013 05:48:48 +0000 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.159]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.03.0158.001; Wed, 13 Nov 2013 13:48:44 +0800 From: Mach Chen To: Jeffrey Haas Subject: RE: WGLC for BFD base MIB and TC - ends November 8 Thread-Topic: WGLC for BFD base MIB and TC - ends November 8 Thread-Index: AQHO3mQ7d29rmKPEbUGsnzhYr0Jy/JogyEJg//+QogCAAIrvcIAAo9kAgADSQuD//6lgAIAAp7WA Date: Wed, 13 Nov 2013 05:48:43 +0000 Message-ID: References: <20131024190612.GN17538@pfrc> <20131112202510.GG15347@pfrc> <20131113034740.GQ15347@pfrc> In-Reply-To: <20131113034740.GQ15347@pfrc> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Carlos Pignataro \(cpignata\)" , "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, 13 Nov 2013 07:41:51 -0000 Jeff, > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Wednesday, November 13, 2013 11:48 AM > To: Mach Chen > Cc: Jeffrey Haas; Carlos Pignataro (cpignata); rtg-bfd@ietf.org > Subject: Re: WGLC for BFD base MIB and TC - ends November 8 >=20 > Mach, >=20 > On Wed, Nov 13, 2013 at 01:07:13AM +0000, Mach Chen wrote: > > I am OK to progress the two drafts as it be. >=20 > Excellent. That clears the last comment on those drafts. >=20 > > As for the extension draft, yes, I am interesting. But based on the fac= t that > there is only one element left, so maybe we could just wait and put it in= to other > extension draft in the future. >=20 > The objects in question would be particular to the LAGs extension. It wo= uld > thus be appropriate for them to go into a standalone draft. This would a= llow > implementations that do not support the LAG feature to not have their SNM= P > implementations entangled with other features in such a MIB. Yes, I just realize it. Best regards, Mach >=20 > -- Jeff From mjethanandani@gmail.com Thu Nov 14 17:52:10 2013 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 D37B521E80F7 for ; Thu, 14 Nov 2013 17:52:10 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbhWpgzsw34h for ; Thu, 14 Nov 2013 17:52:10 -0800 (PST) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9F121E80F5 for ; Thu, 14 Nov 2013 17:52:09 -0800 (PST) Received: by mail-ve0-f179.google.com with SMTP id oz11so2518990veb.24 for ; Thu, 14 Nov 2013 17:52:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fRaW0J6xTTnV4Pp5SwiROcf8WMK55m4nRlK1AjUZSPQ=; b=XNVQEuGxrzRpB4RKxQGEizk71MTg8zU8eq1icEHWDx6oZm/Mva15FKouwKs1EWroFR uUuPYhfLQoTbVi8DLmifR6tuJhVXmLsk6NuWMNGUzOvAxMPDR3O65awrrLg8aX9qKUE3 JNMmPkv9l6CodlDJ3Ay5U0Y6vQuyp6WSg5G0oJsc8AEeZdOaiGAYfypMs35rbexJHpty LPQCXuA4/y518s6TQzw5fHRV7WkmjUcEjgNBDX1DsT/g6kn72ttXIjflNpC80rND19ha HA7GgvpHBhwiKKgA0ayOGlexkdEaI31V6J+lH/eWX1ZWi+59Wgm4OKFqKEB83c84LiJc 8mkg== MIME-Version: 1.0 X-Received: by 10.221.44.136 with SMTP id ug8mr2358797vcb.13.1384480329446; Thu, 14 Nov 2013 17:52:09 -0800 (PST) Received: by 10.52.30.110 with HTTP; Thu, 14 Nov 2013 17:52:09 -0800 (PST) In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BF3B915@SJEXCHMB12.corp.ad.broadcom.com> References: <20131112203701.GI15347@pfrc> <4A6CE49E6084B141B15C0713B8993F281BF3B915@SJEXCHMB12.corp.ad.broadcom.com> Date: Thu, 14 Nov 2013 17:52:09 -0800 Message-ID: Subject: Re: Poll - working group adoption of draft-akiya-bfd-intervals From: Mahesh Jethanandani To: Shahram Davari Content-Type: multipart/alternative; boundary=001a113378d83c3afd04eb2d722f 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, 15 Nov 2013 01:52:10 -0000 --001a113378d83c3afd04eb2d722f Content-Type: text/plain; charset=ISO-8859-1 I am curious why we would want to support anything at or above 10s for timeout interval in BFD. If I look at some of the OSPF implementations out there, they support a "fast hello timeout" of 10s for ethernet and 30s for a non-broadcast network. On Tue, Nov 12, 2013 at 1:32 PM, Shahram Davari wrote: > Hi Jeff, > > > > I support defining a list of intervals that must be supported. However I > would like to propose matching the rates to the > > ETH-OAM, since most of HW OAM engines must support both BFD and ETH-OAM. > > > > Y.1731 rates are: > > > > 3.3ms, 10ms, 100ms, 1s, 10s, 1min, 10min. > > > > Thx > > Shahram > > > > > > > > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Jeffrey Haas > Sent: Tuesday, November 12, 2013 12:37 PM > To: rtg-bfd@ietf.org > Subject: Poll - working group adoption of draft-akiya-bfd-intervals > > > > Working Group, > > > > Part of our discussion at IETF 88 in Vancouver was with regard to the draft > > "Standardized interval support in BFD", draft-akiya-bfd-intervals. > > > > Prior discussion of this draft suggested that making the intervals > mandatory > > was probably over-reaching the work we'd like to do. However, there's > > interest in pursuing this work in an Informational context. A longer term > > goal of the document would be to achieve Best Current Practice (BCP) > status. > > > > A poll of the room in Vancouver indicated good support to take on this > work. > > Since this is somewhat out of our current charter, we'd be seeking a > > re-charter to cover this specific task. > > > > Please indicate to the Working Group mailing list if you'd support or don't > > support adoption of this draft as a Working Group document. > > > > If there is sufficient support, we'll initiate the re-chartering, probably > > along with the S-BFD work. > > > > -- Jeff > > > -- Mahesh Jethanandani mjethanandani@gmail.com --001a113378d83c3afd04eb2d722f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am curious why we would want to support anything at or a= bove 10s for timeout interval in BFD.

If I look at some = of the OSPF implementations out there, they support a "fast hello time= out" of 10s for ethernet and 30s for a non-broadcast network.


On Tue, Nov 1= 2, 2013 at 1:32 PM, Shahram Davari <davari@broadcom.com> w= rote:

Hi Jeff,

=A0

I support defining a list of intervals that must be supported. However I= would like to propose matching the rates to the

ETH-OAM, since most of HW OAM engines must support both BFD and ETH-OAM.=

=A0

Y.1731 rates are:

=A0

3.3ms, 10ms, 100ms, 1s, 10s, 1min, 10min.

=A0

Thx

Shahram

=A0

=A0

=A0

-----Original Message-----
From: rtg-bfd= -bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas
Sent: Tuesday, November 12, 2013 12:37 PM
To: rtg-bfd@ietf.org<= /a>
Subject: Poll - working group adoption of draft-akiya-bfd-intervals

=A0

Working Group,

=A0

Part of our discussion at IETF 88 in Vancouver was with regard to the dr= aft

"Standardized interval support in BFD", draft-akiya-bfd-interv= als.

=A0

Prior discussion of this draft suggested that making the intervals manda= tory

was probably over-reaching the work we'd like to do.=A0 However, the= re's

interest in pursuing this work in an Informational context.=A0 A longer = term

goal of the document would be to achieve Best Current Practice (BCP) sta= tus.

=A0

A poll of the room in Vancouver indicated good support to take on this w= ork.

Since this is somewhat out of our current charter, we'd be seeking a=

re-charter to cover this specific task.

=A0

Please indicate to the Working Group mailing list if you'd support o= r don't

support adoption of this draft as a Working Group document.

=A0

If there is sufficient support, we'll initiate the re-chartering, pr= obably

along with the S-BFD work.

=A0

-- Jeff

=A0




--
--001a113378d83c3afd04eb2d722f-- From lokeshnb1@gmail.com Fri Nov 15 03:10:23 2013 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 11B6911E8128 for ; Fri, 15 Nov 2013 03:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXGF4EpKEYuv for ; Fri, 15 Nov 2013 03:10:22 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8916D11E8119 for ; Fri, 15 Nov 2013 03:10:22 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id w4so802663qcr.38 for ; Fri, 15 Nov 2013 03:10:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=0NRM4VrdOHyWSW3CwscGevIQdXWE7RpUkDs+SbQj7JI=; b=cu7KLR9a8tXm+18AXQyT9A1K8bpmbGHaM/Oeth8qP+/LaBoLw3QD6gDJbpuuhtYmv7 yeBy+cLdcglE8FoBdCsR5dpMqFCGzp/rtKohPSXCIN0Iuegut5Veb0l0uoJaJmdHvBXW MjLVo83+wGQ4V1i9sq0uyHd+c6lq9BxqmN4qKRXYf+GGO7ONlQjIVX+ni4v0HC3S+3wf 9ETyENiBPfvA8JUWEumVDtbQYSp2f4rEqW8JfkUedmiGaKSr15b24YOeOrBSeCJXmLY4 UO7T8xj8Y5oq+Qr9+H2NnMgTg8lfX+KQPvr9p36LSeYjo4FOC83i7u+UG5W+kCZ6arne KwTw== MIME-Version: 1.0 X-Received: by 10.49.84.65 with SMTP id w1mr9905434qey.0.1384513822070; Fri, 15 Nov 2013 03:10:22 -0800 (PST) Received: by 10.96.22.38 with HTTP; Fri, 15 Nov 2013 03:10:22 -0800 (PST) Date: Fri, 15 Nov 2013 16:40:22 +0530 Message-ID: Subject: Open source BFD From: Lokesh B To: "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary=047d7bd6b0d88d1d3904eb353ecb 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, 15 Nov 2013 11:10:23 -0000 --047d7bd6b0d88d1d3904eb353ecb Content-Type: text/plain; charset=ISO-8859-1 Hi Does any one knows open source implementation of BFD? I don't seem to find any. Regards -Lokesh --047d7bd6b0d88d1d3904eb353ecb Content-Type: text/html; charset=ISO-8859-1
Hi
Does any one knows open source implementation of BFD? I don't seem to find any.
Regards
-Lokesh
--047d7bd6b0d88d1d3904eb353ecb-- From aland@deployingradius.com Fri Nov 15 06:46:16 2013 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 E193411E8145 for ; Fri, 15 Nov 2013 06:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvWIjAOeJreQ for ; Fri, 15 Nov 2013 06:46:12 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id D561411E8117 for ; Fri, 15 Nov 2013 06:46:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id E4E6D2240159; Fri, 15 Nov 2013 15:46:08 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d2gKI+9TgfL; Fri, 15 Nov 2013 15:46:06 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1176121806.dsl.bell.ca [70.26.49.206]) by power.freeradius.org (Postfix) with ESMTPSA id 6A8632240143; Fri, 15 Nov 2013 15:46:06 +0100 (CET) Message-ID: <528633AD.8010900@deployingradius.com> Date: Fri, 15 Nov 2013 09:46:05 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Lokesh B Subject: Re: Open source BFD References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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, 15 Nov 2013 14:46:17 -0000 Lokesh B wrote: > Hi > Does any one knows open source implementation of BFD? I don't seem to > find any. Github has two: https://github.com/dyninc/OpenBFDD https://github.com/FreeRADIUS/freeradius-server/ The second one is my pet project. :) Yes, it's a RADIUS server, but it also does DHCPv4 and BFD. I've been using it in customer environments to do application layer liveliness detection. i.e. BFD runs between apps, instead of checking link status. It also runs SNMP triggers when a link goes up / down. Alan DeKok. From iesg-secretary@ietf.org Mon Nov 18 07:36:22 2013 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 D3FDD11E8117; Mon, 18 Nov 2013 07:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d69B-ebexpwF; Mon, 18 Nov 2013 07:36:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BF811E80F5; Mon, 18 Nov 2013 07:35:06 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131118153506.18433.79049.idtracker@ietfa.amsl.com> Date: Mon, 18 Nov 2013 07:35:06 -0800 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 15:36:22 -0000 The IESG has received a request from the Bidirectional Forwarding Detection WG (bfd) to consider the following document: - 'Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-12-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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. 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. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2084/ From jhaas@slice.pfrc.org Mon Nov 18 09:52:31 2013 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 E946E11E8256 for ; Mon, 18 Nov 2013 09:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyEk8QkTzyU9 for ; Mon, 18 Nov 2013 09:52:23 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9840011E8231 for ; Mon, 18 Nov 2013 09:47:22 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id BFE27C1B6; Mon, 18 Nov 2013 12:46:59 -0500 (EST) Date: Mon, 18 Nov 2013 12:46:59 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: [nomcom-chair-2013@ietf.org: NOMCOM - final call for feedback, nominee list] Message-ID: <20131118174659.GA13511@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: Mon, 18 Nov 2013 17:52:31 -0000 Nomcom could use your help. ----- Forwarded message from NomCom Chair 2013 ----- Date: Sat, 16 Nov 2013 11:21:09 -0800 From: NomCom Chair 2013 To: IETF Announcement List Cc: wgchairs@ietf.org Subject: NOMCOM - final call for feedback, nominee list Help the Nomcom: this is the last call for general feedback on nominees. This email includes the willing nominee list for your convenience, as per RFC 5680. WG chairs, please forward this email to your WGs. WARNING - DO NOT reply to this email with feedback - the announcement tool provides an unpredictable Reply-To field. You may send mail to nomcom13, but please do continue reading for additional info. The deadline is midnight (any timezone) Wed Nov 20. Enter your feedback into the encrypted nomcom tool at: https://datatracker.ietf.org/nomcom/2013/feedback/ All feedback is confidential. Select individual nominees, or select an area (e.g. INT Multiple) if you want to give feedback on multiple nominees for that area in one entry. The Nomcom will greatly appreciate your concrete and detailed thoughts on nominees. You need to have a datatracker account in order to enter feedback. This is the site to access either to create a datatracker account or to reset the password on an existing account: https://datatracker.ietf.org/accounts/ As we announced last week, we are sharing the names of the willing nominees in this email, as part of our use of RFC 5680 Open List in this nomcom cycle. These names (appearing at the end of the email) have been available within the datatracker since our first call for feedback; we hope some people will be extra encouraged to provide feedback by seeing the names prior to datatracker login. All your feedback must be entered in the encrypted nomcom site (or mailed to nomcom-chair-2013@ietf.org or nomcom13@ietf.org). You may ask the chair or any another nomcom member to submit your feedback without your name attached, if you would prefer. Again, your feedback is absolutely confidential, however delivered. Thanks very much from all of us for your time and for helping the Nomcom to do the best possible job. Also enormous thanks to the willing nominees. Names below. Allison for the Nomcom APP Joe Hildebrand Barry Leiba (incumbent) Yoshiro Yoneya INT Donald Eastlake Wesley George Brian Haberman (incumbent) Ole Troan OPS Benoit Claise (incumbent) Linda Dunbar Victor Kuarsingh Bill Manning RAI Ben Campbell Alissa Cooper Keith Drage Dan Romascanu RTG Loa Andersson Alia Atlas Deborah Brungard Stewart Bryant (incumbent) Donald Eastlake Susan Hares Keyur Patel SEC Derek Atkins Donald Eastlake Jeff Hodges Leif Johansson Alexey Melnikov Kathleen Moriarty Eric Rescorla TSV Martin Stiemerling (incumbent) Dave Taht IAB Bernard Aboba (incumbent) Loa Andersson Alias Atlas Mary Barnes Marc Blanchet (incumbent) Ross Callon (incumbent) Hago Dafalla Linda Dunbar Roni Even Jim Gettys Ted Hardie Susan Hares Joe Hildebrand Sheng Jiang Eliot Lear (incumbent) Larry Masinter S. Moonesamy Kathleen Moriarty Kaveh Ranjbar Robert Sparks Tina Tsou Brian Trammell IAOC/IETF Trust Glenn Deen Tobias Gondrom Chris Griffiths (incumbent) John Levine Tina Tsou ----- End forwarded message ----- From nobo@cisco.com Wed Nov 20 15:18:02 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953951AE17F for ; Wed, 20 Nov 2013 15:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.025 X-Spam-Level: X-Spam-Status: No, score=-15.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwrIpJCpf1RH for ; Wed, 20 Nov 2013 15:18:00 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3D35C1AE071 for ; Wed, 20 Nov 2013 15:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11589; q=dns/txt; s=iport; t=1384989474; x=1386199074; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gbYf6GHN5kjsmv5TsTdrSweQ+WysFMUYbYFr1YKwVdU=; b=fD9VbApeoV/gDDDNOPZ+y89o4ugmpvJnjOs0zQ1tcGT8ZKE8J6Jb+amV 453q4+M+oBMEYDwaIO5UAov1vqCvABEeAsOtUWiURLRxV6YLu92BARmP+ SeXTsGH3MZPyVyplX72UNTIk1V4aweYVRSZPeiSNdWNljODmnAiTWx9re g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAOxCjVKtJV2b/2dsb2JhbABZgkMjIThTvWmBGxZ0giUBAQEELUELDAQCAQgOAwQBAQsdByERFAkIAgQBDQUIh2cDDwG4NA2ILheMcoJIMQYBBoMagRIDlieOQIU4gyiCKg X-IronPort-AV: E=Sophos;i="4.93,739,1378857600"; d="scan'208,217";a="286462912" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 20 Nov 2013 23:17:53 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAKNHrUY018536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Nov 2013 23:17:53 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 17:17:52 -0600 From: "Nobo Akiya (nobo)" To: Mahesh Jethanandani , Shahram Davari Subject: RE: Poll - working group adoption of draft-akiya-bfd-intervals Thread-Topic: Poll - working group adoption of draft-akiya-bfd-intervals Thread-Index: AQHO3+cBmJlVxINYJE6TrpXnwRW3iJoigg2AgANtUICACNqZAA== Date: Wed, 20 Nov 2013 23:17:52 +0000 Message-ID: References: <20131112203701.GI15347@pfrc> <4A6CE49E6084B141B15C0713B8993F281BF3B915@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941DEE9F47xmbalnx01ciscoc_" MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 Nov 2013 23:18:02 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941DEE9F47xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It'll be a good idea to have terminology section in the document (ex: timeo= ut interval and timer interval are two different things). Steady state under small scale, 10 seconds "timeout interval" is probably r= arely used. With that said, given that software based BFD had use-cases for= large intervals, I agree that it'll be beneficial to also discuss about ho= w "high" HW based BFD may go up to. -Nobo From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Mahesh Jethanandani Sent: Thursday, November 14, 2013 8:52 PM To: Shahram Davari Cc: rtg-bfd@ietf.org Subject: Re: Poll - working group adoption of draft-akiya-bfd-intervals I am curious why we would want to support anything at or above 10s for time= out interval in BFD. If I look at some of the OSPF implementations out there, they support a "fa= st hello timeout" of 10s for ethernet and 30s for a non-broadcast network. On Tue, Nov 12, 2013 at 1:32 PM, Shahram Davari > wrote: Hi Jeff, I support defining a list of intervals that must be supported. However I wo= uld like to propose matching the rates to the ETH-OAM, since most of HW OAM engines must support both BFD and ETH-OAM. Y.1731 rates are: 3.3ms, 10ms, 100ms, 1s, 10s, 1min, 10min. Thx Shahram -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg= -bfd-bounces@ietf.org] On Behalf Of Jeffre= y Haas Sent: Tuesday, November 12, 2013 12:37 PM To: rtg-bfd@ietf.org Subject: Poll - working group adoption of draft-akiya-bfd-intervals Working Group, Part of our discussion at IETF 88 in Vancouver was with regard to the draft "Standardized interval support in BFD", draft-akiya-bfd-intervals. Prior discussion of this draft suggested that making the intervals mandator= y was probably over-reaching the work we'd like to do. However, there's interest in pursuing this work in an Informational context. A longer term goal of the document would be to achieve Best Current Practice (BCP) status= . A poll of the room in Vancouver indicated good support to take on this work= . Since this is somewhat out of our current charter, we'd be seeking a re-charter to cover this specific task. Please indicate to the Working Group mailing list if you'd support or don't support adoption of this draft as a Working Group document. If there is sufficient support, we'll initiate the re-chartering, probably along with the S-BFD work. -- Jeff -- Mahesh Jethanandani mjethanandani@gmail.com --_000_CECE764681BE964CBE1DFF78F3CDD3941DEE9F47xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It’ll be a good ide= a to have terminology section in the document (ex: timeout interval and tim= er interval are two different things).

 <= /p>

Steady state under small = scale, 10 seconds “timeout interval” is probably rarely used. W= ith that said, given that software based BFD had use-cases for large intervals, I agree that it’ll be beneficial to also discuss about ho= w “high” HW based BFD may go up to.

 <= /p>

-Nobo

 <= /p>

From: rtg-bfd-= bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mahesh Jethanandani
Sent: Thursday, November 14, 2013 8:52 PM
To: Shahram Davari
Cc: rtg-bfd@ietf.org
Subject: Re: Poll - working group adoption of draft-akiya-bfd-interv= als

 

I am curious why we would want to support anything a= t or above 10s for timeout interval in BFD.

 

If I look at some of the OSPF implementations out th= ere, they support a "fast hello timeout" of 10s for ethernet and = 30s for a non-broadcast network.

 

On Tue, Nov 12, 2013 at 1:32 PM, Shahram Davari <= davari@broadcom.co= m> wrote:

Hi Jeff,

 

I support defining a list of intervals that must be supported. However I= would like to propose matching the rates to the

ETH-OAM, since most of HW OAM engines must support both BFD and ETH-OAM.=

 

Y.1731 rates are:

 

3.3ms, 10ms, 100ms, 1s, 10s, 1min, 10min.

 

Thx

Shahram

 

 

 

-----Original Message-----
From: rtg-bfd= -bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas

 

Working Group,

 

Part of our discussion at IETF 88 in Vancouver was with regard to the dr= aft

"Standardized interval support in BFD", draft-akiya-bfd-interv= als.

 

Prior discussion of this draft suggested that making the intervals manda= tory

was probably over-reaching the work we'd like to do.  However, ther= e's

interest in pursuing this work in an Informational context.  A long= er term

goal of the document would be to achieve Best Current Practice (BCP) sta= tus.

 

A poll of the room in Vancouver indicated good support to take on this w= ork.

Since this is somewhat out of our current charter, we'd be seeking a

re-charter to cover this specific task.

 

Please indicate to the Working Group mailing list if you'd support or do= n't

support adoption of this draft as a Working Group document.

 

If there is sufficient support, we'll initiate the re-chartering, probab= ly

along with the S-BFD work.

 

-- Jeff

 



 

--

--_000_CECE764681BE964CBE1DFF78F3CDD3941DEE9F47xmbalnx01ciscoc_-- From marc@sniff.de Wed Nov 20 17:01:11 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30E41A8026 for ; Wed, 20 Nov 2013 17:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uht2KPqSAWcQ for ; Wed, 20 Nov 2013 17:01:09 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D05E11A1F48 for ; Wed, 20 Nov 2013 17:01:08 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id ED0932AA0F; Thu, 21 Nov 2013 01:00:59 +0000 (GMT) Date: Wed, 20 Nov 2013 17:01:00 -0800 From: Marc Binderberger To: Nobo Akiya (nobo) , Mahesh Jethanandani Message-ID: <20131120170100297387.081a7c21@sniff.de> In-Reply-To: References: <20131112203701.GI15347@pfrc> <4A6CE49E6084B141B15C0713B8993F281BF3B915@SJEXCHMB12.corp.ad.broadcom.com> Subject: RE: Poll - working group adoption of draft-akiya-bfd-intervals MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 21 Nov 2013 01:01:11 -0000 Hello, the larger intervals are one way to do graceful restart in BFD. Originally we did not have them on our "radar". Personally I assumed implementations would use software for the larger intervals. But meanwhile I learned the hardware colleagues want it all ;-) 10 sec with a multiplier of 255 is about 42 minutes. 1sec x 255 is "only" 4.2 minutes, which is much closer to restart times (not the process but the whole OS) I've seen. The 10sec would offer some peace of mind. For 1 and 10 minute I'm curious myself if someone has a use-case? Regards, Marc On Wed, 20 Nov 2013 23:17:52 +0000, Nobo Akiya (nobo) wrote: > It’ll be a good idea to have terminology section in the document (ex: > timeout interval and timer interval are two different things). > > Steady state under small scale, 10 seconds “timeout interval” is > probably rarely used. With that said, given that software based BFD > had use-cases for large intervals, I agree that it’ll be beneficial > to also discuss about how “high” HW based BFD may go up to. > > -Nobo > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Mahesh Jethanandani > Sent: Thursday, November 14, 2013 8:52 PM > To: Shahram Davari > Cc: rtg-bfd@ietf.org > Subject: Re: Poll - working group adoption of draft-akiya-bfd-intervals > > I am curious why we would want to support anything at or above 10s > for timeout interval in BFD. > > If I look at some of the OSPF implementations out there, they support > a "fast hello timeout" of 10s for ethernet and 30s for a > non-broadcast network. > > On Tue, Nov 12, 2013 at 1:32 PM, Shahram Davari wrote: > Hi Jeff, > > I support defining a list of intervals that must be supported. > However I would like to propose matching the rates to the > ETH-OAM, since most of HW OAM engines must support both BFD and ETH-OAM. > > Y.1731 rates are: > > 3.3ms, 10ms, 100ms, 1s, 10s, 1min, 10min. > > Thx > Shahram > > > > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Jeffrey Haas > Sent: Tuesday, November 12, 2013 12:37 PM > To: rtg-bfd@ietf.org > Subject: Poll - working group adoption of draft-akiya-bfd-intervals > > Working Group, > > Part of our discussion at IETF 88 in Vancouver was with regard to the draft > "Standardized interval support in BFD", draft-akiya-bfd-intervals. > > Prior discussion of this draft suggested that making the intervals mandatory > was probably over-reaching the work we'd like to do. However, there's > interest in pursuing this work in an Informational context. A longer term > goal of the document would be to achieve Best Current Practice (BCP) status. > > A poll of the room in Vancouver indicated good support to take on this work. > Since this is somewhat out of our current charter, we'd be seeking a > re-charter to cover this specific task. > > Please indicate to the Working Group mailing list if you'd support or don't > support adoption of this draft as a Working Group document. > > If there is sufficient support, we'll initiate the re-chartering, probably > along with the S-BFD work. > > -- Jeff > > > > > -- > Mahesh Jethanandani > mjethanandani@gmail.com From internet-drafts@ietf.org Thu Nov 21 07:28:28 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4661AE170; Thu, 21 Nov 2013 07:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bl2luqT5_U3; Thu, 21 Nov 2013 07:28:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1161ADFE2; Thu, 21 Nov 2013 07:28:26 -0800 (PST) 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-tc-mib-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131121152826.12144.77276.idtracker@ietfa.amsl.com> Date: Thu, 21 Nov 2013 07:28:26 -0800 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 15:28:28 -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 : Definitions of Textual Conventions (TCs) for Bidirection= al Forwarding Detection (BFD) Management Author(s) : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-tc-mib-04.txt Pages : 9 Date : 2013-11-21 Abstract: This draft defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Bidirectional Forwarding Detection (BFD) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD related MIB modules that would otherwise define their own representations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-tc-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-tc-mib-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Nov 21 07:28:36 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9E71ADF81; Thu, 21 Nov 2013 07:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnoWdOx8ReLc; Thu, 21 Nov 2013 07:28:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE12A1AE19C; Thu, 21 Nov 2013 07:28:34 -0800 (PST) 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-mib-16.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131121152834.12126.4611.idtracker@ietfa.amsl.com> Date: Thu, 21 Nov 2013 07:28:34 -0800 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 15:28:36 -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 Management Information Base Author(s) : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-mib-16.txt Pages : 38 Date : 2013-11-21 Abstract: This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-mib-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-mib-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jhaas@slice.pfrc.org Thu Nov 21 07:44:46 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C240E1AE210 for ; Thu, 21 Nov 2013 07:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gr3KwbkBhV2R for ; Thu, 21 Nov 2013 07:44:45 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BE8101AE1FF for ; Thu, 21 Nov 2013 07:44:38 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 26BEBC25C; Thu, 21 Nov 2013 10:44:32 -0500 (EST) Date: Thu, 21 Nov 2013 10:44:32 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: WGLC issues on BFD MIBs - IANA maintenance Message-ID: <20131121154432.GB26223@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.15 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, 21 Nov 2013 15:44:47 -0000 Working Group, As part of doing due diligence for the WGLC shepherding work for the BFD MIBs, I found comments in my notes relating to part of our motivation to split the TCs from the BFD MIB: Making the TCs IANA maintained. The primary reason to make the Textual-Conventions IANA maintained is that IANA can update the MIB without having to require the document to go through BFD I-D and review before hitting RFC again. Since the things maintained in this MIB are primarily related to code points that may be assigned as part of other work, this makes for significantly easier management of the TC MIB. It was necessary for the authors to update the naming conventions as well as some copyright information in the MIB. The only other issue found during shepherding work was a minor typo in the TC MIB that resulted in the MIB not compiling. While these changes are relatively minor (please see the diffs), I'd like to give the WG a few more days to review them prior to sending the drafts off to the IESG. While I expect no issues to be found, such last minute renames often result in very small issues that are not caught by eyes who have reviewed the draft many times. Please do us the favor of reviewing these last minute changes. I will send this to IESG with the shepherd writeups this coming Wednesday. http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-04 http://tools.ietf.org/html/draft-ietf-bfd-mib-16 -- Jeff (acting as document shepherd) From jhaas@slice.pfrc.org Fri Nov 22 06:56:21 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132F71AE0DB for ; Fri, 22 Nov 2013 06:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhwblnmlLQO0 for ; Fri, 22 Nov 2013 06:56:19 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CF4EE1AE134 for ; Fri, 22 Nov 2013 06:56:06 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id C1279C346; Fri, 22 Nov 2013 09:55:59 -0500 (EST) Date: Fri, 22 Nov 2013 09:55:59 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: Poll - working group adoption of draft-akiya-bfd-intervals Message-ID: <20131122145559.GC26223@pfrc> References: <20131112203701.GI15347@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131112203701.GI15347@pfrc> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 22 Nov 2013 14:56:21 -0000 The mailing list shows good interest for adopting this draft as a WG item. Those who showed interest in the room at IETF-88 in Vancouver were sufficiently disjoint from those who showed interest on the list for this to be a pretty good showing in BFD-WG-land. :-) A re-chartering request will be sent out to our AD next week to take on this item. -- Jeff On Tue, Nov 12, 2013 at 03:37:01PM -0500, Jeffrey Haas wrote: > Part of our discussion at IETF 88 in Vancouver was with regard to the draft > "Standardized interval support in BFD", draft-akiya-bfd-intervals. > > Prior discussion of this draft suggested that making the intervals mandatory > was probably over-reaching the work we'd like to do. However, there's > interest in pursuing this work in an Informational context. A longer term > goal of the document would be to achieve Best Current Practice (BCP) status. > > A poll of the room in Vancouver indicated good support to take on this work. > Since this is somewhat out of our current charter, we'd be seeking a > re-charter to cover this specific task. > > Please indicate to the Working Group mailing list if you'd support or don't > support adoption of this draft as a Working Group document. > > If there is sufficient support, we'll initiate the re-chartering, probably > along with the S-BFD work. > > -- Jeff From adrian@olddog.co.uk Sat Nov 30 04:44:14 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19991AE017 for ; Sat, 30 Nov 2013 04:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnjUvvqgRer1 for ; Sat, 30 Nov 2013 04:44:13 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id B34781ADF8E for ; Sat, 30 Nov 2013 04:44:12 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id rAUCiAkY028926 for ; Sat, 30 Nov 2013 12:44:10 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id rAUCi8K0028907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 30 Nov 2013 12:44:09 GMT From: "Adrian Farrel" To: Subject: Minor charter modification Date: Sat, 30 Nov 2013 12:44:07 -0000 Message-ID: <0a6201ceedc9$dcc80af0$965820d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7tyTlVMYLEqDkaRgW/btL/a7Dqcg== Content-Language: en-gb X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 12:44:14 -0000 Hi, Talking with the chairs, we have decided it would be nice to explicitly cover the work on intervals/timers with a charter item. Hence we are proposing adding... 6. Provide an informational document to recommend standardized timers and timer operations for BFD when used in different applications. You can see this at... https://datatracker.ietf.org/doc/charter-ietf-bfd/ I will take this to the IESG. Cheers, Adrian From internet-drafts@ietf.org Sat Nov 30 18:56:30 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4D61AE4D3; Sat, 30 Nov 2013 18:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuINiY7B3LPR; Sat, 30 Nov 2013 18:56:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D010D1AE0B1; Sat, 30 Nov 2013 18:56:28 -0800 (PST) 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-on-lags-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131201025628.3115.54343.idtracker@ietfa.amsl.com> Date: Sat, 30 Nov 2013 18:56:28 -0800 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 02:56:30 -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 : Bidirectional Forwarding Detection (BFD) on Link Aggrega= tion Group (LAG) Interfaces Author(s) : Manav Bhatia Mach(Guoyi) Chen Sami Boutros Marc Binderberger Jeffrey Haas Filename : draft-ietf-bfd-on-lags-03.txt Pages : 11 Date : 2013-11-30 Abstract: This document defines 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. This mechanism allows the verification of member link continuity, either in combination with, or in absence of, Link Aggregation Control Protocol (LACP). It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of layer 3 bidirectional forwarding. 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-on-lags-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-on-lags-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/