From jhaas@slice.pfrc.org Sun Mar 11 15:01:25 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF7A21F8753 for ; Sun, 11 Mar 2012 15:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.431 X-Spam-Level: X-Spam-Status: No, score=-101.431 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_05=-1.11, 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 otiw1D2EVS0N for ; Sun, 11 Mar 2012 15:01:24 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C991D21F8723 for ; Sun, 11 Mar 2012 15:01:24 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 964881703E1; Sun, 11 Mar 2012 18:01:24 -0400 (EDT) Date: Sun, 11 Mar 2012 18:01:24 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: BFD on LAG - one AF session per member link Message-ID: <20120311220124.GA22615@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) 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, 11 Mar 2012 22:01:25 -0000 [Speaking as an individual contributor.] I'm proxying a message from a Juniper developer. In draft-mmm-bfd-on-lags-03, we have: : 2.1. Micro BFD async session address family : : : Only one address family MUST be used for all micro BFD async sessions : running on all LAG member links. i.e. all member link async BFD : sessions MUST either use IPv4 or IPv6. The MUST in question here seems a little too aggressive. However, that view may have been an artifact of some of the original work where we're trying to test closer to layer 2 rather than validating layer 3 forwarding over member links. To that end, I'd suggest this be made a SHOULD. However, I'm also aware that text to accommodate this SHOULD will also need to be worked into updated draft text talking about inputs on the IP traffic balancer rather than impacts on LACP. To that end, I request you keep this thought in mind when we get around to bumping the next rev of the draft. -- Jeff From marc@sniff.de Sun Mar 11 15:45:00 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B9321F8768 for ; Sun, 11 Mar 2012 15:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 3oSq44Kvmbng for ; Sun, 11 Mar 2012 15:44:59 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CB421F8764 for ; Sun, 11 Mar 2012 15:44:59 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id E26982AA0F; Sun, 11 Mar 2012 22:44:56 +0000 (GMT) Subject: Re: BFD on LAG - one AF session per member link Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <20120311220124.GA22615@slice> Date: Sun, 11 Mar 2012 23:44:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120311220124.GA22615@slice> To: Jeffrey Haas X-Mailer: Apple Mail (2.1084) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 22:45:00 -0000 Hello Jeff, maybe the wording is not the most elegant piece of English text ;-) but = what it tries to say is: for one given LAG you run either all micro = sessions as IPv4 exclusive-or all micro sessions are IPv6 based. In other words: having member links L1, L2, L3 using IPv4 packets while = member links L4, L5 and L6 use IPv6 packets is what we don't want. Probably no one would do this but we should write it down for = clarification. Another questions is if you could run both, IPv4 and IPv6 sessions on = every member link. The paragraph in the draft does not allow this = either. The problem with this setup is that the draft in it's current = form is totally focused on LAG and the "LMM" being the consumer of the = BFD information. The LAG is layer-2, so if an IPv4 session fails but the = IPv6 session for the same member link stays up, what is the LMM gonna = do? (a) any member-link session fails -> take the link out of forwarding (b) only when both IPv4 and IPv6 session fail we take the member link = out Regards, Marc On 2012-03-11, at 23:01 , Jeffrey Haas wrote: > [Speaking as an individual contributor.] > I'm proxying a message from a Juniper developer. >=20 > In draft-mmm-bfd-on-lags-03, we have: >=20 > : 2.1. Micro BFD async session address family > :=20 > :=20 > : Only one address family MUST be used for all micro BFD async = sessions > : running on all LAG member links. i.e. all member link async BFD > : sessions MUST either use IPv4 or IPv6. >=20 > The MUST in question here seems a little too aggressive. However, = that view > may have been an artifact of some of the original work where we're = trying to > test closer to layer 2 rather than validating layer 3 forwarding over = member > links. >=20 > To that end, I'd suggest this be made a SHOULD. However, I'm also = aware > that text to accommodate this SHOULD will also need to be worked into > updated draft text talking about inputs on the IP traffic balancer = rather > than impacts on LACP. To that end, I request you keep this thought in = mind > when we get around to bumping the next rev of the draft. >=20 > -- Jeff >=20 -- Marc Binderberger From jhaas@slice.pfrc.org Sun Mar 11 15:57:32 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBAD21F8772 for ; Sun, 11 Mar 2012 15:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.16 X-Spam-Level: X-Spam-Status: No, score=-102.16 tagged_above=-999 required=5 tests=[AWL=0.105, 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 QJDoNWgZte0b for ; Sun, 11 Mar 2012 15:57:31 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 85F5B21F876D for ; Sun, 11 Mar 2012 15:57:31 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 543601703DC; Sun, 11 Mar 2012 18:57:31 -0400 (EDT) Date: Sun, 11 Mar 2012 18:57:31 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: IETF 83 - tentative agenda posted Message-ID: <20120311225731.GD22615@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) 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, 11 Mar 2012 22:57:32 -0000 I have uploaded the tentative agenda based on the prior call for presentations. As noted earlier, we're on a tight time slot and the bulk of our time will be taken discussing the BFD over LAG proposal along with related working group rechartering. As also discussed earlier, we are taking WG "presentations" that will not be given during the IETF face-to-face session. Manav has requested one of these for an update on the BFD crypto mechanisms. The goal would be to upload the presentations for discussion prior to the IETF week for on-list discussion. Presenters are strongly encouraged to supply their completed presentations ahead of time for upload and on-list discussion prior to the session. Let's reserve our valuable face-to-face time for discussion! -- Jeff ------------------------------8<--- cut here --->8-------------------------- http://www.ietf.org/proceedings/83/agenda/agenda-83-bfd.txt BFD Agenda, IETF 83 ------------------------------ Presentations to the list: BFD Cryptographic Mechanisms Update (Manav Bhatia) http://tools.ietf.org/html/draft-ietf-bfd-generic-crypto-auth http://tools.ietf.org/html/draft-ietf-bfd-hmac-sha Wednesday, Afternoon Session II 1510-1610 (1 hour) Administravia - 10 minutes (chairs) BFD MIB extensions for MPLS-TP - 10 minutes (Sam Aldrin) http://tools.ietf.org/html/draft-vkst-bfd-mpls-mib BFD explicit sessions - 10 minutes (Tina Tsou) http://tools.ietf.org/html/draft-tsou-bfd-ds-lite BFD over LAG - 30 minutes (Manav Bhatia + open discussion) http://tools.ietf.org/html/draft-mmm-bfd-on-lags From Alexander.Vainshtein@ecitele.com Sun Mar 11 22:39:31 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0432221F8548 for ; Sun, 11 Mar 2012 22:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.081 X-Spam-Level: X-Spam-Status: No, score=-3.081 tagged_above=-999 required=5 tests=[AWL=-0.879, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 Ci3BeRH2A2zz for ; Sun, 11 Mar 2012 22:39:30 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id B98BA21F850C for ; Sun, 11 Mar 2012 22:39:28 -0700 (PDT) Received: from [85.158.143.35:33729] by server-2.bemta-4.messagelabs.com id C1/71-17550-F0C8D5F4; Mon, 12 Mar 2012 05:39:27 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1331530767!9800102!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 20205 invoked from network); 12 Mar 2012 05:39:27 -0000 Received: from unknown (HELO fridlpvsb005.ecitele.com) (168.87.1.157) by server-11.tower-21.messagelabs.com with SMTP; 12 Mar 2012 05:39:27 -0000 X-AuditID: a8571406-b7f606d000006c05-f9-4f5d8c11706c Received: from FRIDWPPCH002.ecitele.com (fridwppch002.ecitele.com [10.1.16.53]) by fridlpvsb005.ecitele.com (Symantec Messaging Gateway) with SMTP id 8E.F6.27653.11C8D5F4; Mon, 12 Mar 2012 06:39:29 +0100 (CET) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.46]) by FRIDWPPCH002.ecitele.com ([10.1.16.53]) with mapi id 14.01.0339.001; Mon, 12 Mar 2012 06:39:26 +0100 From: Alexander Vainshtein To: Marc Binderberger , Jeffrey Haas Subject: RE: BFD on LAG - one AF session per member link Thread-Topic: BFD on LAG - one AF session per member link Thread-Index: AQHM/9KEXFknOYa4O0a+X2uNEiYwSJZloLqAgACAv/E= Date: Mon, 12 Mar 2012 05:39:25 +0000 Message-ID: References: <20120311220124.GA22615@slice>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTfUgTYRz23d3mOXd1Tm2vq2gdGX1pEwtWOPGPKCVqlUFUSJ3b63a03cZu iiaFmSL5ka5U2qI0mWEaGUZfKkWKUJaZFSGRZWhFmZQZiJHVnVdmdH8cz/s+z+95fu97vyMw 9WeFlmA5D3JzjJ1WKHElCNLGqEvTTPqCk8GG23dG5YbTT39ihvHv10ASlhwITMqSn5RdlScX NpXg27A9eSCB4Tinh/EgnQXxZiO9zc1mMeYcWsdajHQcrXPZGTNyIM5jpBmXC3EWOlGp++9J EGQsp0Oc2WlhOauRTkk1xRgMa9fFxNGJO20sr0MxDoa16xyI5xkr0gk7Yt+cZf8lzPagqw93 FUVlHz3bLcsDneHFIISA1BpYOPE0WMLz4KOXzYpioCTU1BMA70+2y6VFAMDLb29iokpBGWFL 04BCxBHUBtjx9YpMxBi1HObfHZ92CqcM8FjlpFzSrIOBca9MwuthWavkg1PRsLS5F4iYpDbD geqaaU81tQeOel9P60OoBJhf0DXtCYTuJrov/s7SwOfDNTKpawoG2nsxCUfC90M/5BJeBK9c HZJL+lWwtu2LQsIr4flzI5iUGwbv+YZxSR8F7zT04xVA458V4Z9V7p9V7p9VXgvwRgAz3KzF 7sri0/X6tbHIzHqQHcWanY4WIExMw64IxQ2QVxHbASgC0Cry1PY0k1rOZPE5jg4QRcjoSHJv ibA1J91pybExvG2fO9OO+A4ACYyOIF/HCRxpYXIOIrfzD2UQLtGLaUPNTvEbe/bF6/X/LGgN 2bwj0aSmrMLgHUDIhdx/ShcQBA3JFWJimBtZUXYGa/f8pWVEiJisEpJ/FIvJvItx8KxV4rvB SqK+s/ExIHr6hLca55wc0mrI3aIdJUptmdyM2wegEU4cTiaJrEoYxxmfD0KETIgYV+4VI4Tf Y4bS5oGq1YpT39/tnK/a2voqtfP6wrOhhwZelA9OHSlfVJ+r9FZlRofWnejpaYw8k15T6Iv0 j1Uu+2Sq7bm0JbjRpD/c8I7LKLiwMYxvAmlFSz9623wpmssj7wNJ1bkO1ZuHS46/ueWDc4uD Ljxrn7oZkhpfXXdUmd816Bsrv1a9aXFF/zeexnkbE7cCc/PML4fi2HoDBAAA 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, 12 Mar 2012 05:39:31 -0000 Marc, Jeff and all, IMHO and FWIW this thread is yet one more proof of the artificial nature of= the decision to run micro-BFD sessions in IP encapsulation. Overloading the BFD state machine with the need to discover peer IP addresse= s, the need for on-the fly modifications of encapsulation of the BFD packets= in these encapsulations etc. have all been already noted and discussed on t= he list... I wonder if the argument that "IP-based encapsulation would help to detect f= ailures of the IP layer" is valid. If it were, IS-IS (that does not run on IP) should be much less popular than= OSPF (which does) - but AFAIK, this is not the case. Regards, Sasha ________________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] on behalf of Marc= Binderberger [marc@sniff.de] Sent: Sunday, March 11, 2012 11:44 PM To: Jeffrey Haas Cc: rtg-bfd@ietf.org Subject: Re: BFD on LAG - one AF session per member link Hello Jeff, maybe the wording is not the most elegant piece of English text ;-) but what= it tries to say is: for one given LAG you run either all micro sessions as= IPv4 exclusive-or all micro sessions are IPv6 based. In other words: having member links L1, L2, L3 using IPv4 packets while memb= er links L4, L5 and L6 use IPv6 packets is what we don't want. Probably no one would do this but we should write it down for clarification. Another questions is if you could run both, IPv4 and IPv6 sessions on every= member link. The paragraph in the draft does not allow this either. The pro= blem with this setup is that the draft in it's current form is totally focus= ed on LAG and the "LMM" being the consumer of the BFD information. The LAG i= s layer-2, so if an IPv4 session fails but the IPv6 session for the same mem= ber link stays up, what is the LMM gonna do? (a) any member-link session fails -> take the link out of forwarding (b) only when both IPv4 and IPv6 session fail we take the member link out Regards, Marc On 2012-03-11, at 23:01 , Jeffrey Haas wrote: > [Speaking as an individual contributor.] > I'm proxying a message from a Juniper developer. > > In draft-mmm-bfd-on-lags-03, we have: > > : 2.1. Micro BFD async session address family > : > : > : Only one address family MUST be used for all micro BFD async sessions > : running on all LAG member links. i.e. all member link async BFD > : sessions MUST either use IPv4 or IPv6. > > The MUST in question here seems a little too aggressive. However, that vi= ew > may have been an artifact of some of the original work where we're trying= to > test closer to layer 2 rather than validating layer 3 forwarding over memb= er > links. > > To that end, I'd suggest this be made a SHOULD. However, I'm also aware > that text to accommodate this SHOULD will also need to be worked into > updated draft text talking about inputs on the IP traffic balancer rather > than impacts on LACP. To that end, I request you keep this thought in min= d > when we get around to bumping the next rev of the draft. > > -- Jeff > -- Marc Binderberger This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From marc@sniff.de Mon Mar 12 01:22:04 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261DD21F8656 for ; Mon, 12 Mar 2012 01:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 9smfINyX10dB for ; Mon, 12 Mar 2012 01:22:03 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8288621F864D for ; Mon, 12 Mar 2012 01:22:02 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 6B32C2AA0F; Mon, 12 Mar 2012 08:22:00 +0000 (GMT) Subject: Re: BFD on LAG - one AF session per member link Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Mon, 12 Mar 2012 09:21:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120311220124.GA22615@slice>, To: Alexander Vainshtein X-Mailer: Apple Mail (2.1084) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 08:22:04 -0000 Hello Alexander, > IMHO and FWIW this thread is yet one more proof of the artificial = nature of the decision to run micro-BFD sessions in IP encapsulation. It is actually the apposite. The "IP" is a requirement from every = customer I talked to - and I assume the same holds true for the other = vendors that have an implementation based on IP encapsulation for = per-member BFD. Artificial would be to ignore the customer requirements. > Overloading the BFD state machine with the need to discover peer IP = addresses, the need for on-the fly modifications of encapsulation of the = BFD packets in these encapsulations etc. have all been already noted and = discussed on the list... Agree this is mudding the water. But the per-member-link draft itself is = talking about configuring the destination IP, full-stop. > I wonder if the argument that "IP-based encapsulation would help to = detect failures of the IP layer" is valid. > If it were, IS-IS (that does not run on IP) should be much less = popular than OSPF (which does) - but AFAIK, this is not the case. Because in the older days nobody knew better - until vendors and = customers learned it the hard way. Had been some nasty outages with CLNS = running but the IP table not being populated :-) And because of such experience customers today demand IP-based = per-member-link BFD :-) Regards, Marc >=20 > Regards, > Sasha >=20 >=20 >=20 >=20 > ________________________________________ > From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] on behalf of = Marc Binderberger [marc@sniff.de] > Sent: Sunday, March 11, 2012 11:44 PM > To: Jeffrey Haas > Cc: rtg-bfd@ietf.org > Subject: Re: BFD on LAG - one AF session per member link >=20 > Hello Jeff, >=20 > maybe the wording is not the most elegant piece of English text ;-) = but what it tries to say is: for one given LAG you run either all micro = sessions as IPv4 exclusive-or all micro sessions are IPv6 based. >=20 > In other words: having member links L1, L2, L3 using IPv4 packets = while member links L4, L5 and L6 use IPv6 packets is what we don't want. >=20 > Probably no one would do this but we should write it down for = clarification. >=20 > Another questions is if you could run both, IPv4 and IPv6 sessions on = every member link. The paragraph in the draft does not allow this = either. The problem with this setup is that the draft in it's current = form is totally focused on LAG and the "LMM" being the consumer of the = BFD information. The LAG is layer-2, so if an IPv4 session fails but the = IPv6 session for the same member link stays up, what is the LMM gonna = do? >=20 > (a) any member-link session fails -> take the link out of forwarding > (b) only when both IPv4 and IPv6 session fail we take the member link = out >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 > On 2012-03-11, at 23:01 , Jeffrey Haas wrote: >=20 >> [Speaking as an individual contributor.] >> I'm proxying a message from a Juniper developer. >>=20 >> In draft-mmm-bfd-on-lags-03, we have: >>=20 >> : 2.1. Micro BFD async session address family >> : >> : >> : Only one address family MUST be used for all micro BFD async = sessions >> : running on all LAG member links. i.e. all member link async BFD >> : sessions MUST either use IPv4 or IPv6. >>=20 >> The MUST in question here seems a little too aggressive. However, = that view >> may have been an artifact of some of the original work where we're = trying to >> test closer to layer 2 rather than validating layer 3 forwarding over = member >> links. >>=20 >> To that end, I'd suggest this be made a SHOULD. However, I'm also = aware >> that text to accommodate this SHOULD will also need to be worked into >> updated draft text talking about inputs on the IP traffic balancer = rather >> than impacts on LACP. To that end, I request you keep this thought = in mind >> when we get around to bumping the next rev of the draft. >>=20 >> -- Jeff >>=20 >=20 > -- > Marc Binderberger > This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof. >=20 -- Marc Binderberger From manav.bhatia@alcatel-lucent.com Mon Mar 12 01:53:08 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3470421F871A for ; Mon, 12 Mar 2012 01:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.847 X-Spam-Level: X-Spam-Status: No, score=-8.847 tagged_above=-999 required=5 tests=[AWL=1.752, 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 cNFtJMxP+DTL for ; Mon, 12 Mar 2012 01:53:07 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 06B7D21F8716 for ; Mon, 12 Mar 2012 01:53:06 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q2C8r3cD022303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 12 Mar 2012 03:53:05 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2C8r2Ob003837 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 12 Mar 2012 14:23:02 +0530 Received: from [135.250.26.223] (135.250.19.8) by INBANSXCHHUB01.in.alcatel-lucent.com (135.250.12.32) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 12 Mar 2012 14:23:01 +0530 Message-ID: <4F5DB921.80305@alcatel-lucent.com> Date: Mon, 12 Mar 2012 14:21:45 +0530 From: Manav Bhatia User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Subject: Re: BFD on LAG - one AF session per member link References: <20120311220124.GA22615@slice>, In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 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, 12 Mar 2012 08:53:08 -0000 Hi Marc, > maybe the wording is not the most elegant piece of English text ;-) but what it tries to say is: for one given LAG you run either all micro sessions as IPv4 exclusive-or all micro sessions are IPv6 based. > > In other words: having member links L1, L2, L3 using IPv4 packets while member links L4, L5 and L6 use IPv6 packets is what we don't want. Yes, that was the intention. > > Another questions is if you could run both, IPv4 and IPv6 sessions on every member link. The paragraph in the draft does not allow this either. Well if we really want true fate separation for IPv4 and IPv6 then yes we might want to do this. Fate separation in case of LAGs would mean having a different IP load balancer (hash) for IPv4 and IPv6. > The problem with this setup is that the draft in it's current form is totally focused on LAG and the "LMM" being the consumer of the BFD information. The LAG is layer-2, so if an IPv4 session fails but the IPv6 session for the same member link stays up, what is the LMM gonna do? I'll hazard a reply here. The behavior would depend upon the HW capabilities. Assuming that the HW has different IP balancers (LAG hashes) for IPv4 and IPv6 then if a micro BFD session for v4 times out then you could remove that link from the IP balancer for the IPv4 traffic. You could still continue using that link for v6. For most HWs that dont have a separate IP balancer for IPv4 and IPv6, a micro session timing out for one AF would automatically mean losing connectivity over the offending link for both v4 and v6. Thus the operators need to run v4 and v6 BFD sessions only if their vendor's hardware has separate IP traffic balancers for v4 and v6. > > (a) any member-link session fails -> take the link out of forwarding > (b) only when both IPv4 and IPv6 session fail we take the member link out Hope the above answers this. Cheers, Manav From jhaas@slice.pfrc.org Mon Mar 12 06:48:04 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46FA21F8764 for ; Mon, 12 Mar 2012 06:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=0.100, 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 fSs5xgfjCdIT for ; Mon, 12 Mar 2012 06:48:04 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 818C221F875B for ; Mon, 12 Mar 2012 06:48:04 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 5205C170311; Mon, 12 Mar 2012 09:48:04 -0400 (EDT) Date: Mon, 12 Mar 2012 09:48:04 -0400 From: Jeffrey Haas To: Manav Bhatia Subject: Re: BFD on LAG - one AF session per member link Message-ID: <20120312134804.GD25264@slice> References: <20120311220124.GA22615@slice> <4F5DB921.80305@alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F5DB921.80305@alcatel-lucent.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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, 12 Mar 2012 13:48:05 -0000 Manav, On Mon, Mar 12, 2012 at 02:21:45PM +0530, Manav Bhatia wrote: > Hi Marc, > >Another questions is if you could run both, IPv4 and IPv6 sessions on every member link. The paragraph in the draft does not allow this either. > > Well if we really want true fate separation for IPv4 and IPv6 then > yes we might want to do this. Fate separation in case of LAGs would > mean having a different IP load balancer (hash) for IPv4 and IPv6. This was part of the point I was proxying. > I'll hazard a reply here. > > The behavior would depend upon the HW capabilities. > > Assuming that the HW has different IP balancers (LAG hashes) for > IPv4 and IPv6 then if a micro BFD session for v4 times out then you > could remove that link from the IP balancer for the IPv4 traffic. > You could still continue using that link for v6. > > For most HWs that dont have a separate IP balancer for IPv4 and > IPv6, a micro session timing out for one AF would automatically mean > losing connectivity over the offending link for both v4 and v6. > > Thus the operators need to run v4 and v6 BFD sessions only if their > vendor's hardware has separate IP traffic balancers for v4 and v6. Exactly. Whether it makes sense to do this or not will depend on the fate-sharing properties of your various forwarding planes. I believe this could be accommodated by making multiple AF sessions on the links optional (i.e. the SHOULD). But what this means is that we need to be clear about what implementations should do with this information. In the current document, we talk a bit about LACP. In a future document, we'll talk more about the forwarder. One such behavior could be that if multiple sessions are up (which requires *both* sides to agree by permitting sessions on multiple AFs) that the loss of one AF may simply remove the bundle from that AF's load balancing. In an environment with shared fate, running a single session would make sense. -- Jeff From Tina.Tsou.Zouting@huawei.com Mon Mar 12 19:34:21 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E6221F88AC for ; Mon, 12 Mar 2012 19:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.415 X-Spam-Level: X-Spam-Status: No, score=-6.415 tagged_above=-999 required=5 tests=[AWL=0.184, 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 lppRnZ5v+liv for ; Mon, 12 Mar 2012 19:34:20 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id AAE8421F88AA for ; Mon, 12 Mar 2012 19:34:20 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0S00HNGXSZHL@szxga05-in.huawei.com> for rtg-bfd@ietf.org; Tue, 13 Mar 2012 10:34:11 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0S0043ZXSMAU@szxga05-in.huawei.com> for rtg-bfd@ietf.org; Tue, 13 Mar 2012 10:34:11 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHU14610; Tue, 13 Mar 2012 10:34:07 +0800 Received: from SZXEML434-HUB.china.huawei.com (10.72.61.62) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Mar 2012 10:34:05 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.102]) by szxeml434-hub.china.huawei.com ([10.72.61.62]) with mapi id 14.01.0323.003; Tue, 13 Mar 2012 10:33:59 +0800 Date: Tue, 13 Mar 2012 02:33:59 +0000 From: Tina TSOU Subject: FW: New Version Notification for draft-tsou-bfd-ds-lite-01.txt X-Originating-IP: [10.212.245.243] To: "rtg-bfd@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: New Version Notification for draft-tsou-bfd-ds-lite-01.txt Thread-index: AQHNAJenjz2lBKKXKkeI3U5yXTFEtpZnWixQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected 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, 13 Mar 2012 02:34:21 -0000 For your comments. http://datatracker.ietf.org/doc/draft-tsou-bfd-ds-lite/ For BFD, what Jeff recommend is a very terse description of the problem being solved and then focus on the BFD bootstrapping portion of the document. I did not manage to update in this way before today's submission deadline. Sorry about that. However, the main part is almost there in the draft. Tina > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, March 12, 2012 2:33 PM > To: Tina TSOU > Subject: New Version Notification for draft-tsou-bfd-ds-lite-01.txt > > A new version of I-D, draft-tsou-bfd-ds-lite-01.txt has been > successfully submitted by Tina Tsou and posted to the IETF repository. > > Filename: draft-tsou-bfd-ds-lite > Revision: 01 > Title: BFD Support DS-Lite > Creation date: 2012-03-12 > WG ID: Individual Submission > Number of pages: 8 > > Abstract: > In DS-Lite, the tunnel is not associated with any state information, > which makes it difficult to manage and diagnose. Some tools may be > used to resolve this problem. > > > > > The IETF Secretariat From jhaas@slice.pfrc.org Sun Mar 25 01:23:07 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB1F21F85CE for ; Sun, 25 Mar 2012 01:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.169 X-Spam-Level: X-Spam-Status: No, score=-102.169 tagged_above=-999 required=5 tests=[AWL=0.096, 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 aI73CKKNv2jK for ; Sun, 25 Mar 2012 01:23:07 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 736EA21F85C3 for ; Sun, 25 Mar 2012 01:23:07 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9BCF9170311; Sun, 25 Mar 2012 04:23:06 -0400 (EDT) Date: Sun, 25 Mar 2012 04:23:06 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: [lsmt@ietf.org: New Liaison Statement, "Liaison response to IETF regarding Proposed IETF BFD WG work on Ethernet LAG"] Message-ID: <20120325082306.GC24448@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) 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, 25 Mar 2012 08:23:08 -0000 Working group, We have received a response from IEEE regarding the proposed charter work for BFD over LAGs. Please take this opportunity to review their response and consider its implications on the discussion about how we'd go about implementing BFD over LAG. -- Jeff ----- Forwarded message from Liaison Statement Management Tool ----- Date: Mon, 19 Mar 2012 14:09:43 -0700 From: Liaison Statement Management Tool To: Stewart Bryant , Adrian Farrel Cc: The IETF Chair , Eric Gray , David Ward , Jeffrey Haas , Dan Romascanu , Stephen Haddock , Tony Jeffree Subject: New Liaison Statement, "Liaison response to IETF regarding Proposed IETF BFD WG work on Ethernet LAG" Title: Liaison response to IETF regarding Proposed IETF BFD WG work on Ethernet LAG Submission Date: 2012-03-15 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1152/ From: IEEE 802.1 (Tony Jeffree ) To: Routing Area (Stewart Bryant , Adrian Farrel ) Cc: The IETF Chair ,Eric Gray ,David Ward ,Jeffrey Haas ,Dan Romascanu Reponse Contact: Stephen Haddock , Tony Jeffree Technical Contact: Purpose: For information Referenced liaison: Proposed IETF BFD WG Work on Ethernet LAG (http://datatracker.ietf.org/liaison/1145/) Body: Attachments: Liaison response to IETF regarding Proposed IETF BFD WG work on Ethernet LAG https://datatracker.ietf.org/documents/LIAISON/liaison-2012-03-15-ieee-8021-rtg-liaison-response-to-ietf-regarding-proposed-ietf-bfd-wg-work-on-ethernet-lag-attachment-1.pdf ----- End forwarded message ----- From jhaas@slice.pfrc.org Sun Mar 25 01:31:56 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A9521F8593 for ; Sun, 25 Mar 2012 01:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.964 X-Spam-Level: X-Spam-Status: No, score=-100.964 tagged_above=-999 required=5 tests=[AWL=-1.113, BAYES_40=-0.185, 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 07Y-kuAlMTGP for ; Sun, 25 Mar 2012 01:31:56 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9793D21F8573 for ; Sun, 25 Mar 2012 01:31:56 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 67AA7170409; Sun, 25 Mar 2012 04:31:56 -0400 (EDT) Date: Sun, 25 Mar 2012 04:31:56 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Updated IETF 83 slides Message-ID: <20120325083156.GD24448@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) 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, 25 Mar 2012 08:31:57 -0000 Working Group, Two of the three slide sets for the upcoming presentations have been uploaded to the data tracker. Links to the slides have been placed in the agenda. The final presentation is expected to be uploaded soon. Please take this opportunity to review the presentations prior to our session so that we can focus on discussion of the material. :-) -- Jeff From jhaas@slice.pfrc.org Mon Mar 26 05:01:15 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CB621F86AF for ; Mon, 26 Mar 2012 05:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.148 X-Spam-Level: X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[AWL=0.117, 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 bjKIK0HgL9th for ; Mon, 26 Mar 2012 05:01:14 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5D821F86A7 for ; Mon, 26 Mar 2012 05:01:13 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 51312170417; Mon, 26 Mar 2012 08:01:13 -0400 (EDT) Date: Mon, 26 Mar 2012 08:01:13 -0400 From: Jeffrey Haas To: Jeffrey Haas Subject: Re: Updated IETF 83 slides Message-ID: <20120326120113.GA19795@slice> References: <20120325083156.GD24448@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120325083156.GD24448@slice> User-Agent: Mutt/1.5.20 (2009-06-14) 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, 26 Mar 2012 12:01:15 -0000 On Sun, Mar 25, 2012 at 04:31:56AM -0400, Jeffrey Haas wrote: > Working Group, > > Two of the three slide sets for the upcoming presentations have been > uploaded to the data tracker. Links to the slides have been placed in the > agenda. The final presentation is expected to be uploaded soon. > > Please take this opportunity to review the presentations prior to our > session so that we can focus on discussion of the material. :-) All slides for presentation are currently uploaded. > -- Jeff