From manav.bhatia@alcatel-lucent.com Wed Feb 1 01:58:43 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 E9EEC21F862D for ; Wed, 1 Feb 2012 01:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.63 X-Spam-Level: X-Spam-Status: No, score=-6.63 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 xltSh7nOAtLu for ; Wed, 1 Feb 2012 01:58:43 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 6488221F8628 for ; Wed, 1 Feb 2012 01:58:43 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q119wagJ024086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Feb 2012 03:58:38 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q119wZem008412 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 1 Feb 2012 15:28:35 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 1 Feb 2012 15:28:35 +0530 From: "Bhatia, Manav (Manav)" To: Tom Sanders , "rtg-bfd@ietf.org" Date: Wed, 1 Feb 2012 15:29:25 +0530 Subject: Updated BFD over LAGs draft Thread-Topic: Updated BFD over LAGs draft Thread-Index: AczX2MjqkUAlIbSsQ8GELlakYZk2aQI7J8sA Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 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, 01 Feb 2012 09:58:44 -0000 Folks, After several rounds of tele conferences and multiple internal iterations o= f this draft we (British Telecom, Alcatel-Lucent, Cisco, Juniper, Huawei an= d Ericsson) have converged at a solution that we all believe is the best wa= y forward. Would request the WG to look at the latest version of the BFD over LAGs dra= ft: http://tools.ietf.org/html/draft-mmm-bfd-on-lags-03 Toms, Let me answer your questions: > So where are we with the discussion of BFD over LAGs? We've been having offline discussions since quite some time and the -03 ver= sion of the draft is a result of those extensive discussions. >=20 > Did we reach any conclusion on the layer that the "micro BFD sessions" > should operate in? Is there any update on whether the "micro=20 > BFD sessions" need to use unicast or multicast addressing?=20 Yes, to both. We believe its best to run it as Layer 3 Unicast. > Are the authors of draft-mmm-* coming up with a new version=20 > that captures some progress? Yup, we have new co-authors and several contributors on the new version! >=20 > We have also not heard what the WG chairs feel about the=20 > whole discussion. It would be instructive to hear their take=20 > on this as well. We have one of the chairs as a co-author now. So, we know at least what one= of them feels about this!=20 Cheers, Manav= From Alexander.Vainshtein@ecitele.com Wed Feb 1 07:38:46 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 3EDC111E80B2 for ; Wed, 1 Feb 2012 07:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.053 X-Spam-Level: X-Spam-Status: No, score=-3.053 tagged_above=-999 required=5 tests=[AWL=-0.851, 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 Ua2tmnD+VoJL for ; Wed, 1 Feb 2012 07:38:45 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5052111E8071 for ; Wed, 1 Feb 2012 07:38:44 -0800 (PST) Received: from [85.158.138.51:39495] by server-9.bemta-3.messagelabs.com id 10/A2-31168-38C592F4; Wed, 01 Feb 2012 15:38:43 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1328110722!11588700!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 9695 invoked from network); 1 Feb 2012 15:38:42 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-4.tower-174.messagelabs.com with SMTP; 1 Feb 2012 15:38:42 -0000 X-AuditID: 93eaf2e7-b7f2a6d000000e7d-5e-4f2968a5421f Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 7D.3E.03709.5A8692F4; Wed, 1 Feb 2012 18:30:29 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 1 Feb 2012 17:38:41 +0200 From: Alexander Vainshtein To: "Bhatia, Manav (Manav)" Date: Wed, 1 Feb 2012 17:38:40 +0200 Subject: RE: Updated BFD over LAGs draft Thread-Topic: Updated BFD over LAGs draft Thread-Index: AczX2MjqkUAlIbSsQ8GELlakYZk2aQI7J8sAAAopa7A= Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA1VTa2wMURjt3ZndTqsj09Xaq2mYjFeLbbopsR6LSENFZSkRIdFOZ67did3Z zcyQ1h8bUoI/BFGLFrsepdqkpfXebBNC06QNJQgVuirqXY1XUTMdqv6de8853/nuvd8lMPM7 UxohiAqSRNbDmBLxvd09vdYT7kxndu192n64o8No//SjAdjv9VQZ5mF5ZV3XjHmXgk/i88Lh b4al2OoAmM2Kok9hFUTzSOYczFJJ2MhypQwt8A7GxtB+D8shLxIVB8P6/UjkmTmJs9VNQaSR yPl4QXQ5mEXLnVa7fdoMq42ZM2GsLWdW4gq3INPI6mUFD+1Fssy6EK3uaL2KPOLpdT6JVtyI lor2Yu6GGxVGfzSn5OaXggBoyNgJEghITYVVz7owHY+EbR21pp0gkTBTEQB/vv38Z7EfwJbQ eYOmMlEOWHf2iUnDKSp+WX8Z1zBGLYPXew8YNYxT42BVdWxAP4LKhFuijZiunwQDW9/jOp4J m4NnBjSk6r1QXwY0bKbCALY2WjScQK2FgYqyeA0DtbsvzdUGPcsCH8UqDXrXFAxfbf1zglT4 qvOXUdenwsfba4GunwKPXukx6XgyPHnsNabnJsPbB2O47h0Fo6cf4LuBJTgkIjjEHhxiDw6x HwX4GZAqePxKsdeVbctCnKAgD8rifN46oE/Ly4vge+W4JkARgEkiS7IynGYju1Eu9TaBUYSB SSWPrM50mocX+/hSNyu7C6UNHiQ3AUhgTAq5Z43KkTxbuglJvr+UXb3lPVjaMM6nvbVSmJOd /d+CsZAvuDdLzJRLHbr1CPmR9NeaThAMJNu0qskScqGSdYJH+UcbiAQtOUlNbh9Ilv2sVxZc Ot8MrMSpviutwIyLPhGlWchyTURpIvcGcbCO9k029/f3dwOLeuYRZIWmSlIHc7BStxpiUEPi 7AMh6ucYpNICoJX6PrF818cHq/ojZbZGrpjfcUgZc+u9OLr988OPD1uujg8Zh39ynnj8teXD ysWPEmacfXs3xZleeSHueWVfqCZ/Yf3TguP7a13bFsyPHc99Hb+4KJAbSR92JFQz/Zyp4hdZ PTfpjrwvbO0tD3Xm53fuiE3bFo0cXnHtYsb0MZc2Rb5GGVx2s7ZJmCSzvwFbAD4pAQQAAA== 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, 01 Feb 2012 15:38:46 -0000 Manav, and all, I've read the latest version of the draft and I have several issues with the= new text. 1. In Section 1 you say that " Currently Link aggregation control protocol (= LACP) is used to detect failures on a per physical member link." This statement looks inaccurate to me because any (if not all) LAG imple= mentations react to physical link failures (where available) regardless of usage or non-usage of LACP. IMHO added value of running BF= D over LAG members only exists when, for some reason, the member links do not report physical failures (at all or fast enough)= . 2. In the same Section you say that one of the benefits of running BFD over= LAG members is ability "to verify L3 connectivity per member link". The correctness of this statement is IMHO implementation-specific, same= as in the case of, say, 1-hop IPv4/IPv6 BFD as per RFC 5881: A faulty implementation may be able to correctly identify BFD packets i= n IP/UDP encapsulation and pass them to the appropriate entity (SW or HW) that handles these packets while not being able to fo= rward received IP packets with " remote" destination addresses. 3. In Section 2.2. I've found a couple of statements that imply availabilit= y of the information about the physical ingress port of an IP packet to the appropriate "handling" entity. This looks to me like a strong requ= irement because (and this has been discussed on the list) some existing implementations do not provide this information (as it d= oes not belong to IP layer which treats the entire LAG as a single virtual p= ort). IMHO you should explicitly present this requirement. 4. In the same section, there are certain issues regarding MAC addresses in= the Ethernet encapsulation of the micro-BFD packets: - The Source MAC address is required to match the MAC address of the phy= sical port on which the micro-BFD session runs. This implies bypass of the "regular" IP stack (because it would use the sa= me Source MAC address for all the packets sent via LAG) and, incidentally, compromises the claim that UDP/IP-encapsulation of the= micro-BFD packets helps to verify IP connectivity over the link. - The Destination MAC address of the micro-BFD packets is supposed to ch= ange in the life cycle of the session: it starts with using a dedicated MAC address to be allocated by IANA but goes on using "lear= ned" MAC address (which presumably is the source MAC address in the received micro-BFD packet. IMHO such behavior is neither trivi= al to implement nor adds any benefits: if the peer is supposed to receive packets with the dedicated Destination JAC address, why should this a= ddress be ever changed? The claim that this trick "reduced requirements for Ethernet HW" does not seem to be justified t= o me - Last but not least, the draft states that the dedicated MAC address is= allocated by IANA as per RFC 5342, but it does not explain whether a unicast or a multicast address should be allocated. 5. There seem to be a contradiction regarding activation of a micro-BFD sess= ion as described in Section 3 and Section 3.1: - Section 3 states that this session must be initiated when a link is att= ached to the Aggregator and deleted when it is detached from it (The member link state machine is shown in Figure 5-14 of 802.1ax) - Section 3.1 states that in the presence of LACP this session must be in= itiated when the link advances to its Distributing state. - To me the text in Section 3.1 makes plenty of sense because in the pres= ence of LACP the link only advances to the Distributing state only after it sees that its peer is Collecting. But this definit= ion differs from that in Section 3 6. The text in the same section states that " BFD, as a layer 3 protocol, is= viewed as running across the LAG, with load balancing constraints ensuring particular micro BFD sessions are effectively bound to particu= lar member links". Does this mean that micro-BFD sessions send and receive packets using the Agg: MA-UNITDATA service primitives? If yes, how can t= ransmission of customer traffic via Distributing member links be prevented while micro-BFD packets go thru? 7. 802.1ax does not specify any "load balancing constraints" in the LAG Dis= tributor beyond flow preservation. And there is no indication In the draft regarding how these constraints would look like. 8. IMHO and FWIW the draft would become much more readable if it would expl= icitly indicate the relationship of micro-BFD with the LAG architectural blocks as shown 0n Figure 5-3 of 802.1ax. Hopefully, these notes will be useful. Regards, Sasha > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Bhatia, Manav (Manav) > Sent: Wednesday, February 01, 2012 11:59 AM > To: Tom Sanders; rtg-bfd@ietf.org > Subject: Updated BFD over LAGs draft > > Folks, > + > After several rounds of tele conferences and multiple internal iterations= of > this draft we (British Telecom, Alcatel-Lucent, Cisco, Juniper, Huawei and > Ericsson) have converged at a solution that we ll believe is the best way > forward. > > Would request the WG to look at the latest version of the BFD over LAGs > draft: > http://tools.ietf.org/html/draft-mmm-bfd-on-lags-03 > > Toms, > > Let me answer your questions: > > > So where are we with the discussion of BFD over LAGs? > > We've been having offline discussions since quite some time and the -03 > version of the draft is a result of those extensive discussions. > > > > > Did we reach any conclusion on the layer that the "micro BFD sessions" > > should operate in? Is there any update on whether the "micro > > BFD sessions" need to use unicast or multicast addressing? > > Yes, to both. > > We believe its best to run it as Layer 3 Unicast. > > > Are the authors of draft-mmm-* coming up with a new version > > that captures some progress? > > Yup, we have new co-authors and several contributors on the new version! > > > > > We have also not heard what the WG chairs feel about the > > whole discussion. It would be instructive to hear their take > > on this as well. > > We have one of the chairs as a co-author now. So, we know at least what > one of them feels about this! > > Cheers, Manav 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 toms.sanders@gmail.com Wed Feb 1 12:00:44 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 C4D5D11E8114 for ; Wed, 1 Feb 2012 12:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 AXuo58JfTKEt for ; Wed, 1 Feb 2012 12:00:41 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7999721F877C for ; Wed, 1 Feb 2012 12:00:38 -0800 (PST) Received: by wibhm9 with SMTP id hm9so1538110wib.31 for ; Wed, 01 Feb 2012 12:00:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FUy8YmhjJq2I4ayoX6nfxI79GPJKkbxMTYO5TkRi8sE=; b=XfBRqcmytTYMu1MxltQbK0RHMISvT3yfd+EwpY6dxl4dHTsyyTKHTpvZeUKso8VRAO CjspfQ63fjLy7SNxALdhLSQIqBRuTFTU6Xl0OoePA2A/StZIVxlMogL2aI8qFv5xlOFK 9iL1UgGahRLNmd63z7wIb5EWmaFI2SWvqg/gY= MIME-Version: 1.0 Received: by 10.180.101.35 with SMTP id fd3mr43661183wib.22.1328126437674; Wed, 01 Feb 2012 12:00:37 -0800 (PST) Received: by 10.223.115.81 with HTTP; Wed, 1 Feb 2012 12:00:37 -0800 (PST) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Thu, 2 Feb 2012 01:30:37 +0530 Message-ID: Subject: Re: Updated BFD over LAGs draft From: Tom Sanders To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=UTF-8 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, 01 Feb 2012 20:00:45 -0000 Hi Manav, Thanks very much for the update. Wow .. a lot has changed between -02 and -03! > >> >> Did we reach any conclusion on the layer that the "micro BFD sessions" >> should operate in? Is there any update on whether the "micro >> BFD sessions" need to use unicast or multicast addressing? > > Yes, to both. > > We believe its best to run it as Layer 3 Unicast. I was, and still continue to be, a big fan of multicast as that saves you a lot of configuration overhead. Any particular reason why you didnt go with that approach? BTW, if i am not mistaken, that was your preferred approach too, wasnt it? > >> Are the authors of draft-mmm-* coming up with a new version >> that captures some progress? > > Yup, we have new co-authors and several contributors on the new version! Whoa .. and thats some list you have! :-) > >> >> We have also not heard what the WG chairs feel about the >> whole discussion. It would be instructive to hear their take >> on this as well. > > We have one of the chairs as a co-author now. So, we know at least what one of them feels about this! Aha. -- Toms. From toms.sanders@gmail.com Wed Feb 1 12:11: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 D283D21F878A for ; Wed, 1 Feb 2012 12:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 2yJUCIUmKG7x for ; Wed, 1 Feb 2012 12:11:00 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B597521F878B for ; Wed, 1 Feb 2012 12:10:59 -0800 (PST) Received: by werm10 with SMTP id m10so1551096wer.31 for ; Wed, 01 Feb 2012 12:10:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0NsgCIrd2pPg0w9wzACHW+EnBkn6Kneb4a9+AYxI5QU=; b=f2N13Q7FDXOOsfCygCNgVAi6IQDECZZLct93Anpv4dOx04n7YWrMD1V6z46wdUry3l e8htCJ+fPfEsgJdPexGsuxJsryei9q01n6XAhDRk9eF3jwiUbRLpGLbeQAZ2D+h4lPU4 5McU5bBwPsUO8ugl+s7tdyFgbKRqjDvKUSpuU= MIME-Version: 1.0 Received: by 10.216.131.131 with SMTP id m3mr3449538wei.47.1328127050912; Wed, 01 Feb 2012 12:10:50 -0800 (PST) Received: by 10.223.115.81 with HTTP; Wed, 1 Feb 2012 12:10:50 -0800 (PST) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Thu, 2 Feb 2012 01:40:50 +0530 Message-ID: Subject: Re: Updated BFD over LAGs draft From: Tom Sanders To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=UTF-8 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, 01 Feb 2012 20:11:00 -0000 I also think -02 did a good job with describing how BFD runs over a LAG considering it as one virtual entity (BBP?). I find that entire section missing in -03. I think its important to have that too, as one could run micro BFD sessions to ensure link liveliness, and BFD over the virtual LAG for LAG liveliness. You can argue that the aggregated state of the micro sessions will give you the state of the LAG, but there is a subtle difference. The micro BFD sessions only interact with the LAG manager while the other BFD session will directly interact with the L3 applications like OSPF, etc. I think its useful to describe how BFD runs over a LAG considering it as one virtual port. Toms. On 1 February 2012 15:29, Bhatia, Manav (Manav) wrote: > Folks, > > After several rounds of tele conferences and multiple internal iterations of this draft we (British Telecom, Alcatel-Lucent, Cisco, Juniper, Huawei and Ericsson) have converged at a solution that we all believe is the best way forward. > > Would request the WG to look at the latest version of the BFD over LAGs draft: > http://tools.ietf.org/html/draft-mmm-bfd-on-lags-03 > > Toms, > > Let me answer your questions: > >> So where are we with the discussion of BFD over LAGs? > > We've been having offline discussions since quite some time and the -03 version of the draft is a result of those extensive discussions. > >> >> Did we reach any conclusion on the layer that the "micro BFD sessions" >> should operate in? Is there any update on whether the "micro >> BFD sessions" need to use unicast or multicast addressing? > > Yes, to both. > > We believe its best to run it as Layer 3 Unicast. > >> Are the authors of draft-mmm-* coming up with a new version >> that captures some progress? > > Yup, we have new co-authors and several contributors on the new version! > >> >> We have also not heard what the WG chairs feel about the >> whole discussion. It would be instructive to hear their take >> on this as well. > > We have one of the chairs as a co-author now. So, we know at least what one of them feels about this! > > Cheers, Manav -- Toms. From marc@sniff.de Wed Feb 1 13:21:09 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 25E5311E80D2 for ; Wed, 1 Feb 2012 13:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 UvkdMClyeQqj for ; Wed, 1 Feb 2012 13:21:08 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B10FF11E8072 for ; Wed, 1 Feb 2012 13:21:07 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 67B6A2AA0F; Wed, 1 Feb 2012 21:21:05 +0000 (GMT) Subject: Re: Updated BFD over LAGs draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Wed, 1 Feb 2012 22:21:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <21B05798-0D94-447B-8E5A-09D45A01DEB0@sniff.de> References: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com> To: Tom Sanders 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: Wed, 01 Feb 2012 21:21:09 -0000 Hello Tom, we split off the "BBP" into a separate draft, to focus on the = per-member-link mode that was mainly described (and now solely) in the = draft-mmm-bfd-on-lags. Interestingly we have some fifty-fifty opinion if this split-off draft, = describing BBP, has enough content to publish it. Maybe we should = publish and leave the decision to the IETF list :-) Regards, Marc On 2012-02-01, at 21:10 , Tom Sanders wrote: > I also think -02 did a good job with describing how BFD runs over a > LAG considering it as one virtual entity (BBP?). I find that entire > section missing in -03. I think its important to have that too, as one > could run micro BFD sessions to ensure link liveliness, and BFD over > the virtual LAG for LAG liveliness. You can argue that the aggregated > state of the micro sessions will give you the state of the LAG, but > there is a subtle difference. The micro BFD sessions only interact > with the LAG manager while the other BFD session will directly > interact with the L3 applications like OSPF, etc. >=20 > I think its useful to describe how BFD runs over a LAG considering it > as one virtual port. >=20 > Toms. >=20 > On 1 February 2012 15:29, Bhatia, Manav (Manav) > wrote: >> Folks, >>=20 >> After several rounds of tele conferences and multiple internal = iterations of this draft we (British Telecom, Alcatel-Lucent, Cisco, = Juniper, Huawei and Ericsson) have converged at a solution that we all = believe is the best way forward. >>=20 >> Would request the WG to look at the latest version of the BFD over = LAGs draft: >> http://tools.ietf.org/html/draft-mmm-bfd-on-lags-03 >>=20 >> Toms, >>=20 >> Let me answer your questions: >>=20 >>> So where are we with the discussion of BFD over LAGs? >>=20 >> We've been having offline discussions since quite some time and the = -03 version of the draft is a result of those extensive discussions. >>=20 >>>=20 >>> Did we reach any conclusion on the layer that the "micro BFD = sessions" >>> should operate in? Is there any update on whether the "micro >>> BFD sessions" need to use unicast or multicast addressing? >>=20 >> Yes, to both. >>=20 >> We believe its best to run it as Layer 3 Unicast. >>=20 >>> Are the authors of draft-mmm-* coming up with a new version >>> that captures some progress? >>=20 >> Yup, we have new co-authors and several contributors on the new = version! >>=20 >>>=20 >>> We have also not heard what the WG chairs feel about the >>> whole discussion. It would be instructive to hear their take >>> on this as well. >>=20 >> We have one of the chairs as a co-author now. So, we know at least = what one of them feels about this! >>=20 >> Cheers, Manav >=20 >=20 >=20 > --=20 > Toms. >=20 -- Marc Binderberger From marc@sniff.de Wed Feb 1 15:28:44 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 4407211E8122 for ; Wed, 1 Feb 2012 15:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 yy8whmICDUrz for ; Wed, 1 Feb 2012 15:28:43 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 583BF11E8086 for ; Wed, 1 Feb 2012 15:28:42 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 47FBB2AA0F; Wed, 1 Feb 2012 23:28:40 +0000 (GMT) Subject: Re: Updated BFD over LAGs draft Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Thu, 2 Feb 2012 00:28:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6BA87B92-7DD2-4F69-A574-B14D7FB50089@sniff.de> References: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com> 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: Wed, 01 Feb 2012 23:28:44 -0000 Hello Alexander, lots of feedback - thanks! > 1. In Section 1 you say that " Currently Link aggregation control = protocol (LACP) is used to detect failures on a per physical member = link." > This statement looks inaccurate [...] fair enough. Correct, we talk about failures that are not indicates by = loss-of-signal or other layer-1 "down" signals. Unfortunately that seems = to happen often enough, otherwise no one would be interested in BFD (and = other active protocols) ;-) I think we can mention this in the text. > 2. In the same Section you say that one of the benefits of running BFD = over LAG members is ability "to verify L3 connectivity per member link". > The correctness of this statement is IMHO implementation-specific = [...] indeed. If it helps we could talk about "allows to verify aspects of L3 = connectivity". If and how much of the L3 connectivity and code path is = tested with the BFD implementation is indeed and deliberately left to = the implementor. > 3. In Section 2.2. I've found a couple of statements that imply = availability of the information about the physical ingress port of an IP = packet to > the appropriate "handling" entity. This looks to me like a strong = requirement because (and this has been discussed on the list) > some existing implementations do not provide this information=20 First of all it's up to the implementor how s/he is matching the = incoming packet to a port and more important to the BFD session running = on that port. Remember when you proposed that LACP requests the BFD = session and provides the remote port MAC address with the request? = Providing the packet including the source MAC would then qualify as = "interface information", enough to match the incoming packet to the = session which in turn is for the particular port. Alternatively: we once discussed the drop-off/inject mechanism, using = the MAC service interface between the port MAC and the Link aggregation = sublayer. One could drop/add IP/UDP packets at this point. That may not = have much in common with the normal L3 path but that is actually not the = problem of the draft. What it "guarantees" is that such an API is = possible, based on a well defined MAC service Interface. We had a lot of this API discussion and I think what it was missing was: = the API is possible - the drop/add example is enough for this statement = - and anything else is up to the implementor. > 4. In the same section, there are certain issues regarding MAC = addresses in the Ethernet encapsulation of the micro-BFD packets: > - The Source MAC address is required to match the MAC address of = the physical port on which the micro-BFD session runs. This > implies bypass of the "regular" IP stack (because it would use = the same Source MAC address for all the packets sent via LAG) and, > incidentally, compromises the claim that UDP/IP-encapsulation of = the micro-BFD packets helps to verify IP connectivity over the link. It is a balance between staying close to the layer-3 path and doing what = is written in the draft. And it is again a matter of the implementors = ideas. You could well run the full "normal" path and as a last step = overwrite all the MAC, port, etc values. That would catch all the errors = that may happen in the normal path. Regarding the change in the MAC address I leave this to George. I don't = know how many devices are affected and need this "support". My understanding is that Ethernet hardware exists where anything but the = embedded MAC is kind of an exception and the handling is "expensive". = The mechanism itself seems relatively simple to me: [..] This will be used for the initial BFD down packets of a session, while sending BFD Init and Up packets with the MAC address learned from the received BFD packets. > - Last but not least, the draft states that the dedicated MAC = address is allocated by IANA as per RFC 5342, but it does not explain = whether > a unicast or a multicast address should be allocated. Good point. We should discuss this :-) Both should work and I haven't = seen any advantage for unicast or for multicast. > 5. There seem to be a contradiction regarding activation of a = micro-BFD session as described in Section 3 and Section 3.1: [...] 1:0 for you. Slipped through when we merged text :-/ Authors will = discuss this but I _think_ the ... The micro BFD session for a particular port MUST be requested when the port is attached to an aggregator. The session MUST be deleted when the port is detached from the aggregator. ... should be part of section 3.2. > 6. The text in the same section states that " BFD, as a layer 3 = protocol, is viewed as running across the LAG, with load balancing = constraints > ensuring particular micro BFD sessions are effectively bound to = particular member links". Does this mean that micro-BFD sessions send = and receive > packets using the Agg: MA-UNITDATA service primitives? No, we are not trying to make any such statement about the service = interface to use. What is wants to say is that "ensuring particular = micro BFD sessions are effectively bound to particular member links" is required. I.e. that the = ssion packets go out from the right port. If you think this text part is confusing then we may have to reword this = a bit. > 7. 802.1ax does not specify any "load balancing constraints" in the = LAG Distributor beyond flow preservation. And there is no indication > In the draft regarding how these constraints would look like. We probably have to reword it if this "constraints" misleads = implementors what to do or what they could do. > Hopefully, these notes will be useful. Yes, thanks a lot! Regards, Marc On 2012-02-01, at 16:38 , Alexander Vainshtein wrote: > Manav, and all, > I've read the latest version of the draft and I have several issues = with the new text. >=20 > 1. In Section 1 you say that " Currently Link aggregation control = protocol (LACP) is used to detect failures on a per physical member = link." > This statement looks inaccurate to me because any (if not all) LAG = implementations react to physical link failures (where available) > regardless of usage or non-usage of LACP. IMHO added value of = running BFD over LAG members only exists when, for some reason, > the member links do not report physical failures (at all or fast = enough). >=20 > 2. In the same Section you say that one of the benefits of running BFD = over LAG members is ability "to verify L3 connectivity per member link". > The correctness of this statement is IMHO implementation-specific, = same as in the case of, say, 1-hop IPv4/IPv6 BFD as per RFC 5881: > A faulty implementation may be able to correctly identify BFD = packets in IP/UDP encapsulation and pass them to the appropriate > entity (SW or HW) that handles these packets while not being able = to forward received IP packets with " remote" destination addresses. >=20 > 3. In Section 2.2. I've found a couple of statements that imply = availability of the information about the physical ingress port of an IP = packet to > the appropriate "handling" entity. This looks to me like a strong = requirement because (and this has been discussed on the list) > some existing implementations do not provide this information (as = it does not belong to IP layer which treats the entire LAG as a single = virtual port). > IMHO you should explicitly present this requirement. >=20 > 4. In the same section, there are certain issues regarding MAC = addresses in the Ethernet encapsulation of the micro-BFD packets: > - The Source MAC address is required to match the MAC address of = the physical port on which the micro-BFD session runs. This > implies bypass of the "regular" IP stack (because it would use = the same Source MAC address for all the packets sent via LAG) and, > incidentally, compromises the claim that UDP/IP-encapsulation of = the micro-BFD packets helps to verify IP connectivity over the link. > - The Destination MAC address of the micro-BFD packets is supposed = to change in the life cycle of the session: it starts with using a > dedicated MAC address to be allocated by IANA but goes on using = "learned" MAC address (which presumably is the source MAC address > in the received micro-BFD packet. IMHO such behavior is neither = trivial to implement nor adds any benefits: if the peer is supposed to = receive > packets with the dedicated Destination JAC address, why should = this address be ever changed? The claim that this trick > "reduced requirements for Ethernet HW" does not seem to be = justified to me > - Last but not least, the draft states that the dedicated MAC = address is allocated by IANA as per RFC 5342, but it does not explain = whether > a unicast or a multicast address should be allocated. >=20 > 5. There seem to be a contradiction regarding activation of a = micro-BFD session as described in Section 3 and Section 3.1: > - Section 3 states that this session must be initiated when a link = is attached to the Aggregator and deleted when it is detached from it > (The member link state machine is shown in Figure 5-14 of 802.1ax) > - Section 3.1 states that in the presence of LACP this session must = be initiated when the link advances to its Distributing state. > - To me the text in Section 3.1 makes plenty of sense because in the = presence of LACP the link only advances to the Distributing > state only after it sees that its peer is Collecting. But this = definition differs from that in Section 3 >=20 > 6. The text in the same section states that " BFD, as a layer 3 = protocol, is viewed as running across the LAG, with load balancing = constraints > ensuring particular micro BFD sessions are effectively bound to = particular member links". Does this mean that micro-BFD sessions send = and receive > packets using the Agg: MA-UNITDATA service primitives? If yes, how = can transmission of customer traffic via Distributing member links be = prevented > while micro-BFD packets go thru? >=20 > 7. 802.1ax does not specify any "load balancing constraints" in the = LAG Distributor beyond flow preservation. And there is no indication > In the draft regarding how these constraints would look like. >=20 > 8. IMHO and FWIW the draft would become much more readable if it = would explicitly indicate the relationship of micro-BFD with the LAG > architectural blocks as shown 0n Figure 5-3 of 802.1ax. >=20 > Hopefully, these notes will be useful. >=20 > Regards, > Sasha >=20 >=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On >> Behalf Of Bhatia, Manav (Manav) >> Sent: Wednesday, February 01, 2012 11:59 AM >> To: Tom Sanders; rtg-bfd@ietf.org >> Subject: Updated BFD over LAGs draft >>=20 >> Folks, >> + >> After several rounds of tele conferences and multiple internal = iterations of >> this draft we (British Telecom, Alcatel-Lucent, Cisco, Juniper, = Huawei and >> Ericsson) have converged at a solution that we ll believe is the best = way >> forward. >>=20 >> Would request the WG to look at the latest version of the BFD over = LAGs >> draft: >> http://tools.ietf.org/html/draft-mmm-bfd-on-lags-03 >>=20 >> Toms, >>=20 >> Let me answer your questions: >>=20 >>> So where are we with the discussion of BFD over LAGs? >>=20 >> We've been having offline discussions since quite some time and the = -03 >> version of the draft is a result of those extensive discussions. >>=20 >>>=20 >>> Did we reach any conclusion on the layer that the "micro BFD = sessions" >>> should operate in? Is there any update on whether the "micro >>> BFD sessions" need to use unicast or multicast addressing? >>=20 >> Yes, to both. >>=20 >> We believe its best to run it as Layer 3 Unicast. >>=20 >>> Are the authors of draft-mmm-* coming up with a new version >>> that captures some progress? >>=20 >> Yup, we have new co-authors and several contributors on the new = version! >>=20 >>>=20 >>> We have also not heard what the WG chairs feel about the >>> whole discussion. It would be instructive to hear their take >>> on this as well. >>=20 >> We have one of the chairs as a co-author now. So, we know at least = what >> one of them feels about this! >>=20 >> Cheers, Manav >=20 >=20 > 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 d3e3e3@gmail.com Wed Feb 1 16:19:03 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 A9DCA11E8132 for ; Wed, 1 Feb 2012 16:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.206 X-Spam-Level: X-Spam-Status: No, score=-104.206 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 MVUnLYdIEPuR for ; Wed, 1 Feb 2012 16:19:03 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C499B11E811B for ; Wed, 1 Feb 2012 16:19:02 -0800 (PST) Received: by lahl5 with SMTP id l5so1111974lah.31 for ; Wed, 01 Feb 2012 16:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Xm6QEk3sdIv5d6nohxBMRhjDsON6SWSelJbildn69Ms=; b=tYEwHRKd/4SKS4yJYV1riEjnz6/1bOCpqpLwO+5MbFQ/VNpJAa/b9KqT8QcAIr+4dY rmUyuQgxsERUIDnco6ZJmhVxhESBQBaIQHSeitt9ywfLiiMu4KgoLmAF5mYX/fv/UidE HespPk49O5Wn17MUR4P0kEw/ooYj80stQglPk= Received: by 10.112.85.137 with SMTP id h9mr174803lbz.51.1328141941258; Wed, 01 Feb 2012 16:19:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.40.231 with HTTP; Wed, 1 Feb 2012 16:18:41 -0800 (PST) In-Reply-To: <4F299636.7060604@acm.org> References: <4F299636.7060604@acm.org> From: Donald Eastlake Date: Wed, 1 Feb 2012 19:18:41 -0500 Message-ID: Subject: Fwd: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 To: rtg-bfd WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: trill-chairs@tools.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, 02 Feb 2012 00:19:03 -0000 Hi, A Working Group Last Call on the BFD for TRILL draft http://tools.ietf.org/html/draft-ietf-trill-rbridge-bfd-02 has been issued. If you are not subscribed to the TRILL WG list, I'll be happy to forward messages from this list there. Thanks, Donald (Co-Chair, TRILL) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com ---------- Forwarded message ---------- From: Erik Nordmark Date: Wed, Feb 1, 2012 at 2:44 PM Subject: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02 To: "rbridge@postel.org" The WG last call ends on Feb 15th. Please send comments (including ones that say you've read the document and it is fine) to the rbridge list. =A0 Erik _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From jhaas@slice.pfrc.org Wed Feb 1 17:47: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 85C2211E808A for ; Wed, 1 Feb 2012 17:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.117 X-Spam-Level: X-Spam-Status: No, score=-102.117 tagged_above=-999 required=5 tests=[AWL=0.148, 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 8VFuxZTcMDce for ; Wed, 1 Feb 2012 17:47:21 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 20AD511E8087 for ; Wed, 1 Feb 2012 17:47:21 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id B35FC170336; Wed, 1 Feb 2012 20:47:20 -0500 (EST) Date: Wed, 1 Feb 2012 20:47:20 -0500 From: Jeffrey Haas To: Alexander Vainshtein Subject: Re: Status now? (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Message-ID: <20120202014720.GD30217@slice> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "rtg-bfd@ietf.org" , David Ward 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, 02 Feb 2012 01:47:21 -0000 [Speaking as a co-chair] On Sat, Jan 21, 2012 at 01:20:44PM +0200, Alexander Vainshtein wrote: > It has been my understanding that the discussion around this draft have resulted in the WG chairs requesting a slot for a F2F session at the Paris IETF - for the first time in several years. > > I would take it as an indication (of a kind) of how they feel about the whole discussion. Meeting time is best used for presentation of new ideas or working on consensus. The discussion in the WG list has been energetic and a lot of good ideas have been thrown around. The recently published -03 is the result of many contributors trying to work out the differences in the proposal. My hope is that by the time we've hit our time slot in Paris that we'll have great consensus and will rapidly close any remaining issues. It feels like we're making very good progress. Let's keep it going. -- Jeff From jhaas@slice.pfrc.org Wed Feb 1 18:08:46 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 2D45711E809A for ; Wed, 1 Feb 2012 18:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.123 X-Spam-Level: X-Spam-Status: No, score=-102.123 tagged_above=-999 required=5 tests=[AWL=0.142, 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 ZZplfWcsCnKs for ; Wed, 1 Feb 2012 18:08:45 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C101B11E8087 for ; Wed, 1 Feb 2012 18:08:45 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8630B170336; Wed, 1 Feb 2012 21:08:45 -0500 (EST) Date: Wed, 1 Feb 2012 21:08:45 -0500 From: Jeffrey Haas To: Tom Sanders Subject: Re: Updated BFD over LAGs draft Message-ID: <20120202020845.GE30217@slice> References: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Thu, 02 Feb 2012 02:08:46 -0000 [Speaking as an individual contributor] On Thu, Feb 02, 2012 at 01:30:37AM +0530, Tom Sanders wrote: > I was, and still continue to be, a big fan of multicast as that saves > you a lot of configuration overhead. Any particular reason why you > didnt go with that approach? > > BTW, if i am not mistaken, that was your preferred approach too, wasnt it? My sense is that it's the rough consensus of the group. The general argument is that we're closer to exercising the forwarding path of the involved traffic - at least for IP unicast, which is our first target. Arguments have been made, with some validity, that some of the things necessary to bootstrap the session require a level of control beyond what you'd get out of simple socket APIs. I would offer a counter to this argument that while that's true on the sending side under some of those circumstances, the receiving side may not have similar considerations. IMO, if we're going to have to bang the bits on the wire ourselves, let's do so in such a way that implementations that need few changes need as few changes from stock IP BFD as possible. This lets us leverage existing code and chipsets where possible. > >> We have also not heard what the WG chairs feel about the > >> whole discussion. It would be instructive to hear their take > >> on this as well. > > > > We have one of the chairs as a co-author now. So, we know at least what one of them feels about this! > > Aha. This editor (note role) believes in driving consensus. The discussion has been healthy and I think the resulting -03 is a great step. While I know the RFC editor isn't a giant fan of very large author/editor lists, at this stage in the game it's a good way to show strong, early support from multiple vendors for the direction of the proposal. -- Jeff From jhaas@slice.pfrc.org Wed Feb 1 18:16:29 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA29E11E809A for ; Wed, 1 Feb 2012 18:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.129 X-Spam-Level: X-Spam-Status: No, score=-102.129 tagged_above=-999 required=5 tests=[AWL=0.136, 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 DAhtI801RLdM for ; Wed, 1 Feb 2012 18:16:29 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 25E6711E8087 for ; Wed, 1 Feb 2012 18:16:29 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id CABF3170336; Wed, 1 Feb 2012 21:16:28 -0500 (EST) Date: Wed, 1 Feb 2012 21:16:28 -0500 From: Jeffrey Haas To: Marc Binderberger Subject: Re: Updated BFD over LAGs draft Message-ID: <20120202021628.GF30217@slice> References: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com> <6BA87B92-7DD2-4F69-A574-B14D7FB50089@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6BA87B92-7DD2-4F69-A574-B14D7FB50089@sniff.de> 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: Thu, 02 Feb 2012 02:16:30 -0000 [Speaking as an individual contributor] Marc, On Thu, Feb 02, 2012 at 12:28:37AM +0100, Marc Binderberger wrote: > Regarding the change in the MAC address I leave this to George. I don't know how many devices are affected and need this "support". > My understanding is that Ethernet hardware exists where anything but the embedded MAC is kind of an exception and the handling is "expensive". The mechanism itself seems relatively simple to me: > > [..] This will be used for the initial BFD down > packets of a session, while sending BFD Init and Up packets with the > MAC address learned from the received BFD packets. I won't speak for George's exact scenario, but I have at least one supporting one. Some Ethernet chips have a very small MAC cache that can be used for local addresses. Presume such a chip that supports 8 entries. If you have the standard unicast MAC address, you now have 7 MACs that can be used for other purposes such as multicast or other unicast purposes such as VRRP. Once you've exceeded the maximum number of entries, you may need to always punt traffic up to your primary CPU (pick your vendor specific lingo) for processing. In such circumstances, that traffic may at least be rate limited. In such circumstances, using the well known MAC address for bootstrapping purposes at the sedate BFD setup rate may be acceptable. My memory may be failing, but discussion around a similar issue may possibly be found in the VRRP mailing list archives. Multicast coders may also have similar experiences to share. -- Jeff From jhaas@slice.pfrc.org Wed Feb 1 18:44:03 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 0A71F21F88A5 for ; Wed, 1 Feb 2012 18:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.134 X-Spam-Level: X-Spam-Status: No, score=-102.134 tagged_above=-999 required=5 tests=[AWL=0.131, 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 vw5Z1C4PSpIF for ; Wed, 1 Feb 2012 18:44:02 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 903A821F88A3 for ; Wed, 1 Feb 2012 18:44:02 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 5B598170331; Wed, 1 Feb 2012 21:44:02 -0500 (EST) Date: Wed, 1 Feb 2012 21:44:02 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Charter work for BFD over LAGs Message-ID: <20120202024402.GH30217@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: rtg-bfd-chairs@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, 02 Feb 2012 02:44:03 -0000 Working Group, In the great tradition of many IETF working groups, while we've had great discussion over the topic of BFD over LAGs, it's not formally on our charter. To correct this, we need to request our charter be amended to cover this work. I propose the following text: http://datatracker.ietf.org/wg/bfd/charter/ 7. Provide one or more mechanisms to run BFD over Link Aggregation Group Interfaces. I would also propose a milestone to complete this work and send it to the IESG by December 2012. (And they'll respond that we need to update the dates on our other milestones, but that's a different discussion.) Please send feedback to the mailing list suggesting changes or additions to the charter item or the milestone date. -- Jeff From glen.kent@gmail.com Wed Feb 1 18:53:35 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68A111E80E2 for ; Wed, 1 Feb 2012 18:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 E4u8cYm6JmFZ for ; Wed, 1 Feb 2012 18:53:34 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 46BCE11E80A6 for ; Wed, 1 Feb 2012 18:53:34 -0800 (PST) Received: by iagf6 with SMTP id f6so2934834iag.31 for ; Wed, 01 Feb 2012 18:53:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IJlbSsPNZOwZEB7bmpjgbKEyA0VuMvWf4SALOkw0RMw=; b=SfM9shHgL8h9VA26RM9rRkD9fLY7AsSmSWyAjs9x8XEqFHp5i3JoEbUKt7ryQuzsbE Nj9Siwip5f0xfm9B7sVQwML2cU+GUw/mCqr7rLNkyrEIVNy1nDskoU7DtwPGaR4t9Qca RE+fMhXR01zzIZL52M1Ax7D/Ib8tAqtD6J5L0= MIME-Version: 1.0 Received: by 10.50.217.129 with SMTP id oy1mr1650143igc.4.1328151212558; Wed, 01 Feb 2012 18:53:32 -0800 (PST) Received: by 10.43.44.66 with HTTP; Wed, 1 Feb 2012 18:53:32 -0800 (PST) In-Reply-To: <20120202024402.GH30217@slice> References: <20120202024402.GH30217@slice> Date: Thu, 2 Feb 2012 08:23:32 +0530 Message-ID: Subject: Re: Charter work for BFD over LAGs From: Glen Kent To: Jeffrey Haas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd-chairs@ietf.org, rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 02:53:35 -0000 Looks good to me. Do you think we will be able to send it to IESG by the end of this year? We dont even have a WG document yet? Glen On Thu, Feb 2, 2012 at 8:14 AM, Jeffrey Haas wrote: > Working Group, > > In the great tradition of many IETF working groups, while we've had great > discussion over the topic of BFD over LAGs, it's not formally on our > charter. =A0To correct this, we need to request our charter be amended to > cover this work. =A0I propose the following text: > > http://datatracker.ietf.org/wg/bfd/charter/ > > 7. Provide one or more mechanisms to run BFD over Link Aggregation Group > Interfaces. > > I would also propose a milestone to complete this work and send it to the > IESG by December 2012. > (And they'll respond that we need to update the dates on our other > milestones, but that's a different discussion.) > > Please send feedback to the mailing list suggesting changes or additions = to > the charter item or the milestone date. > > -- Jeff From jhaas@slice.pfrc.org Wed Feb 1 19:09:13 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 93FE511E8098 for ; Wed, 1 Feb 2012 19:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.139 X-Spam-Level: X-Spam-Status: No, score=-102.139 tagged_above=-999 required=5 tests=[AWL=0.126, 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 fSBm4bFMzFqh for ; Wed, 1 Feb 2012 19:09:13 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2603311E8087 for ; Wed, 1 Feb 2012 19:09:13 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id E41FB170336; Wed, 1 Feb 2012 22:09:12 -0500 (EST) Date: Wed, 1 Feb 2012 22:09:12 -0500 From: Jeffrey Haas To: Glen Kent Subject: Re: Charter work for BFD over LAGs Message-ID: <20120202030912.GJ30217@slice> References: <20120202024402.GH30217@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Thu, 02 Feb 2012 03:09:13 -0000 On Thu, Feb 02, 2012 at 08:23:32AM +0530, Glen Kent wrote: > Looks good to me. Do you think we will be able to send it to IESG by > the end of this year? We dont even have a WG document yet? My suspicion is that draft-mmm-bfd-on-lags could be one of those mechanisms. :-) This of course depends on WG consensus on adopting that draft. We can talk about adoption of specific drafts once we have an updated charter. It may also be reasonable to push the milestone date out to accommodate other proposals. Other opinions on the milestone date vs. open work? -- Jeff From Alexander.Vainshtein@ecitele.com Wed Feb 1 22:00:47 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 005C921F8990 for ; Wed, 1 Feb 2012 22:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.031 X-Spam-Level: X-Spam-Status: No, score=-3.031 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 X+iU0yRqSGUb for ; Wed, 1 Feb 2012 22:00:45 -0800 (PST) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id C779A21F898F for ; Wed, 1 Feb 2012 22:00:44 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1328162423!13361959!3 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 30186 invoked from network); 2 Feb 2012 06:00:42 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-10.tower-182.messagelabs.com with SMTP; 2 Feb 2012 06:00:42 -0000 X-AuditID: 93eaf2e7-b7f2a6d000000e7d-8b-4f2a32a704a6 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 74.75.03709.7A23A2F4; Thu, 2 Feb 2012 08:52:23 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 2 Feb 2012 08:00:39 +0200 From: Alexander Vainshtein To: Marc Binderberger Date: Thu, 2 Feb 2012 07:59:23 +0200 Subject: RE: Updated BFD over LAGs draft Thread-Topic: Updated BFD over LAGs draft Thread-Index: AczhORMqBZ3WwFzvQCKQQGxCZTkSpgAMd6Y4 Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com> , <6BA87B92-7DD2-4F69-A574-B14D7FB50089@sniff.de> In-Reply-To: <6BA87B92-7DD2-4F69-A574-B14D7FB50089@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA1VTXUwUVxT27gzbYbtDhgXcCzHNZBASVlBWNFkiS4gPDTStYOTJGnWYuexO 3J3ZzAyE9aUbleJfG4ia1nUbaCXKn1Ug1TZqEPRBeIGk1SAppGkFZfEnEYVgqusdRil9++45 33e+c+49lyIcr6xZlCTrSJX5AGe1kafiL14WXNzsqiy82FTsiU1NJXnO/ZEgPPP/XgVlRHnj zM2k8vb2JUt5Y/cJsorYHQElvCwrOq8jVkSa4OWqVKmeF8IcK4lezs2xoQAvoCCSdS/Hh0JI FrlSWwkOSjKLZEERJdnn5Sp2VRZ4PFuLC9xcaW62u2ibrdovaSwqCPJSgA0iTeN9iMURo1dZ RCJbq6is7kesuv8U4V/ofg5CwxHQ8KZxnIiAAXQcJFOQ2QKbBuJWE6+FY1OXMbZRDmYAwGPP EqR5OAPgt73XLQbLynhhX/fksiKdyYGTc0PAwARTC+/eMTkksx52NE8QBk5j8uChwWuEyXfB yOHnuCiF8Wb4e6fNCNPMThgZO/2RgR1MzAInpvMNnMyUwJkzrcvlAW5ucaTHYlo54cTDVovZ NAPbb4wSJs6As/+8TTL5GfDPpsvvW8uHbddfWE28AV74cY4wfVPh8NmHpKnNhIMd42QzcEZX WURXyaOr5NFV8jZAdoEMKRDSa4K+QvdGJEg6CqCNghLsA+a6PPoVvG5dPwQYCnB2+sqJvEpH El+vhYNDIJOycBn0YLar0pFSo4hhP6/596l1AaQNAUgRXDrd8iWm0yIfPohU5UPKgy+5hcj6 WFCMx9b3FRUW/u/AOelp4ckXDsaHt+4AQiGkfpCuoygO0jM52DFVRT7UUCsF9P/SFirZcLZj 5yWDQ2shPqhJPjM/Aoqo6fH5UUANLy6MAgcpKzLKctJrcjGVMaj+OnmlmvFbvkokEnHgxJOn 0SkGy473c6VeHFtZsNUajzGkhv/ISiorAkr3wLbJn8brslO3u5rPz/3ct2P67x88xZkLe9I+ F3471nG/nT8rdgqKTb9V1G//bKf9yOyOk13f3fwrFK/Pi106Hfnme9B6jtob81Uo8afwKABl Kd77X0/0VpV92pN+tPmX6tufCNFO2+wIVUO8LK/Y5IjlEuH9dbkPHr8qudcvcqTm590uQtX4 d3RJSiMIBAAA 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, 02 Feb 2012 06:00:47 -0000 Marc hi, Lots of thanks for a prompt response. Please see some additional comments inline below. As always, I hope they wil= l be useful. Regards, Sasha ________________________________________ From: Marc Binderberger [marc@sniff.de] Sent: Thursday, February 02, 2012 1:28 AM To: Alexander Vainshtein Cc: Bhatia, Manav (Manav); rtg-bfd@ietf.org Subject: Re: Updated BFD over LAGs draft Hello Alexander, lots of feedback - thanks! > 1. In Section 1 you say that " Currently Link aggregation control protocol= (LACP) is used to detect failures on a per physical member link." > This statement looks inaccurate [...] fair enough. Correct, we talk about failures that are not indicates by loss-= of-signal or other layer-1 "down" signals. Unfortunately that seems to happe= n often enough, otherwise no one would be interested in BFD (and other activ= e protocols) ;-) I think we can mention this in the text. [[Sasha]] This would be nice. > 2. In the same Section you say that one of the benefits of running BFD ove= r LAG members is ability "to verify L3 connectivity per member link". > The correctness of this statement is IMHO implementation-specific [...] indeed. If it helps we could talk about "allows to verify aspects of L3 conn= ectivity". If and how much of the L3 connectivity and code path is tested wi= th the BFD implementation is indeed and deliberately left to the implementor= . [[Sasha]] "some implementation-specific asppects of L3 connectivity" sounds= like an accurate description of what you guys try to achieve. So why not to= say that? Please note also that there are two sides to ths "partial L3 conn= ectivity verification": - you may declare a link OK while actually received IP packets are not forwa= rded properly - the link may be OK but mico-BFD session fails. This could be the case when= , say, your IP stack only accepts unicast IP packets with port (or LAG) dest= ination MAC address (AFAIK, quite a few implementations do that). If you use= your "dedicated MAC address" to bring up the session while this is not reso= lved, the session simly will not come up no matter what really happens... Maybe you should discuss these two situations (say, in a "Guidelines for the= Implementor" Annex to the draft)? > 3. In Section 2.2. I've found a couple of statements that imply availabil= ity of the information about the physical ingress port of an IP packet to > the appropriate "handling" entity. This looks to me like a strong req= uirement because (and this has been discussed on the list) > some existing implementations do not provide this information First of all it's up to the implementor how s/he is matching the incoming pa= cket to a port and more important to the BFD session running on that port. R= emember when you proposed that LACP requests the BFD session and provides th= e remote port MAC address with the request? Providing the packet including t= he source MAC would then qualify as "interface information", enough to match= the incoming packet to the session which in turn is for the particular port= . [[Sasha]] Yes, source MAC address could be used as the link identifier. Alternatively: we once discussed the drop-off/inject mechanism, using the MA= C service interface between the port MAC and the Link aggregation sublayer.= One could drop/add IP/UDP packets at this point. That may not have much in= common with the normal L3 path but that is actually not the problem of the= draft. What it "guarantees" is that such an API is possible, based on a wel= l defined MAC service Interface. [[Sasha]] IMHO and FWIW there are two alternative models for the micro-BFD o= ption: - What you call the "inject/drop-off" option (i.e., micro-BFD sits somewher= e near LACP in the LAG sublayers architecture) - quite straightforward with= minimal similarity to the "normal" L3 path - Aggregator MAC client that relies on some Distributor properties to send m= icro-BFD packets via the specific links - impoved similarity to the regular= L3 path but requires these special Distributor properties. There may be some mixed models as well. IMHO these things should be spelled= out explicitly. We had a lot of this API discussion and I think what it was missing was: the= API is possible - the drop/add example is enough for this statement - and a= nything else is up to the implementor. [[Sasha]] Yes of course - and this is why I would suggest a "Guidelines to t= eh Implementor" Annex. You do not really want a standard with too many optio= ns for non-interoperable implementations IMHO. > 4. In the same section, there are certain issues regarding MAC addresses i= n the Ethernet encapsulation of the micro-BFD packets: > - The Source MAC address is required to match the MAC address of the ph= ysical port on which the micro-BFD session runs. This > implies bypass of the "regular" IP stack (because it would use the s= ame Source MAC address for all the packets sent via LAG) and, > incidentally, compromises the claim that UDP/IP-encapsulation of the= micro-BFD packets helps to verify IP connectivity over the link. It is a balance between staying close to the layer-3 path and doing what is= written in the draft. And it is again a matter of the implementors ideas. Y= ou could well run the full "normal" path and as a last step overwrite all th= e MAC, port, etc values. That would catch all the errors that may happen in= the normal path. [[Sasha]] Why not to send all these packets with the LAG MAC address as the= destination? Anyway your L3 stack would need this address for sending unicast IP traffic= (be it via ARP, PPPoE, DHCP snooping, configuration or anything else). IMHO and FWIW you need a dedicated MC MAC in the "inject/drop-off" architect= ure. In the "Aggregator MAC client" architecture you should send packets to the peer LAG MAC address but provide= specific Source MAC addresses to distribute them to the appropriate member= links. Regarding the change in the MAC address I leave this to George. I don't know= how many devices are affected and need this "support". My understanding is that Ethernet hardware exists where anything but the emb= edded MAC is kind of an exception and the handling is "expensive". The mecha= nism itself seems relatively simple to me: [..] This will be used for the initial BFD down packets of a session, while sending BFD Init and Up packets with the MAC address learned from the received BFD packets. [[Sasha]] How does your Ethernet port oeperate as part of a LAG without micr= o-BFD? The peer sends its unicast P packets with the LAG MAC address as dest= ination - same for all the member links, so it is apt to differ from the phy= sical ("embedded") port MAC address at least for some of the member ports (a= ssuming that there is more than one link in your LAG). I.e., if your HW does= not accept unicast Ethernet packets with Destination MAC different from its= "embedded" address, it cannot be used in LAG regardless of micro-BFD. Did I= miss something here? > - Last but not least, the draft states that the dedicated MAC address i= s allocated by IANA as per RFC 5342, but it does not explain whether > a unicast or a multicast address should be allocated. Good point. We should discuss this :-) Both should work and I haven't seen a= ny advantage for unicast or for multicast. [[Sasha]] I understand the need for a multicast MAC address in the "drop-off= /inject" architecture. I do not see a need for a dedicated unicast MAC addes= s. > 5. There seem to be a contradiction regarding activation of a micro-BFD se= ssion as described in Section 3 and Section 3.1: [...] 1:0 for you. Slipped through when we merged text :-/ Authors will discuss th= is but I _think_ the ... The micro BFD session for a particular port MUST be requested when the port is attached to an aggregator. The session MUST be deleted when the port is detached from the aggregator. ... should be part of section 3.2. [[Sasha]] OK > 6. The text in the same section states that " BFD, as a layer 3 protocol,= is viewed as running across the LAG, with load balancing constraints > ensuring particular micro BFD sessions are effectively bound to partic= ular member links". Does this mean that micro-BFD sessions send and receive > packets using the Agg: MA-UNITDATA service primitives? No, we are not trying to make any such statement about the service interface= to use. What is wants to say is that "ensuring particular micro BFD session= s are effectively bound to particular member links" is required. I.e. that the ssi= on packets go out from the right port. If you think this text part is confusing then we may have to reword this a b= it. > 7. 802.1ax does not specify any "load balancing constraints" in the LAG D= istributor beyond flow preservation. And there is no indication > In the draft regarding how these constraints would look like. We probably have to reword it if this "constraints" misleads implementors wh= at to do or what they could do. > Hopefully, these notes will be useful. Yes, thanks a lot! Regards, Marc On 2012-02-01, at 16:38 , Alexander Vainshtein wrote: > Manav, and all, > I've read the latest version of the draft and I have several issues with t= he new text. > > 1. In Section 1 you say that " Currently Link aggregation control protocol= (LACP) is used to detect failures on a per physical member link." > This statement looks inaccurate to me because any (if not all) LAG impl= ementations react to physical link failures (where available) > regardless of usage or non-usage of LACP. IMHO added value of running B= FD over LAG members only exists when, for some reason, > the member links do not report physical failures (at all or fast enough= ). > > 2. In the same Section you say that one of the benefits of running BFD ove= r LAG members is ability "to verify L3 connectivity per member link". > The correctness of this statement is IMHO implementation-specific, same= as in the case of, say, 1-hop IPv4/IPv6 BFD as per RFC 5881: > A faulty implementation may be able to correctly identify BFD packets= in IP/UDP encapsulation and pass them to the appropriate > entity (SW or HW) that handles these packets while not being able to f= orward received IP packets with " remote" destination addresses. > > 3. In Section 2.2. I've found a couple of statements that imply availabil= ity of the information about the physical ingress port of an IP packet to > the appropriate "handling" entity. This looks to me like a strong req= uirement because (and this has been discussed on the list) > some existing implementations do not provide this information (as it= does not belong to IP layer which treats the entire LAG as a single virtual= port). > IMHO you should explicitly present this requirement. > > 4. In the same section, there are certain issues regarding MAC addresses i= n the Ethernet encapsulation of the micro-BFD packets: > - The Source MAC address is required to match the MAC address of the ph= ysical port on which the micro-BFD session runs. This > implies bypass of the "regular" IP stack (because it would use the s= ame Source MAC address for all the packets sent via LAG) and, > incidentally, compromises the claim that UDP/IP-encapsulation of the= micro-BFD packets helps to verify IP connectivity over the link. > - The Destination MAC address of the micro-BFD packets is supposed to c= hange in the life cycle of the session: it starts with using a > dedicated MAC address to be allocated by IANA but goes on using "lea= rned" MAC address (which presumably is the source MAC address > in the received micro-BFD packet. IMHO such behavior is neither triv= ial to implement nor adds any benefits: if the peer is supposed to receive > packets with the dedicated Destination JAC address, why should this= address be ever changed? The claim that this trick > "reduced requirements for Ethernet HW" does not seem to be justified= to me > - Last but not least, the draft states that the dedicated MAC address i= s allocated by IANA as per RFC 5342, but it does not explain whether > a unicast or a multicast address should be allocated. > > 5. There seem to be a contradiction regarding activation of a micro-BFD se= ssion as described in Section 3 and Section 3.1: > - Section 3 states that this session must be initiated when a link is at= tached to the Aggregator and deleted when it is detached from it > (The member link state machine is shown in Figure 5-14 of 802.1ax) > - Section 3.1 states that in the presence of LACP this session must be i= nitiated when the link advances to its Distributing state. > - To me the text in Section 3.1 makes plenty of sense because in the pre= sence of LACP the link only advances to the Distributing > state only after it sees that its peer is Collecting. But this defini= tion differs from that in Section 3 > > 6. The text in the same section states that " BFD, as a layer 3 protocol,= is viewed as running across the LAG, with load balancing constraints > ensuring particular micro BFD sessions are effectively bound to partic= ular member links". Does this mean that micro-BFD sessions send and receive > packets using the Agg: MA-UNITDATA service primitives? If yes, how can= transmission of customer traffic via Distributing member links be prevented > while micro-BFD packets go thru? > > 7. 802.1ax does not specify any "load balancing constraints" in the LAG D= istributor beyond flow preservation. And there is no indication > In the draft regarding how these constraints would look like. > > 8. IMHO and FWIW the draft would become much more readable if it would ex= plicitly indicate the relationship of micro-BFD with the LAG > architectural blocks as shown 0n Figure 5-3 of 802.1ax. > > Hopefully, these notes will be useful. > > Regards, > Sasha > > >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On >> Behalf Of Bhatia, Manav (Manav) >> Sent: Wednesday, February 01, 2012 11:59 AM >> To: Tom Sanders; rtg-bfd@ietf.org >> Subject: Updated BFD over LAGs draft >> >> Folks, >> + >> After several rounds of tele conferences and multiple internal iterations= of >> this draft we (British Telecom, Alcatel-Lucent, Cisco, Juniper, Huawei an= d >> Ericsson) have converged at a solution that we ll believe is the best way >> forward. >> >> Would request the WG to look at the latest version of the BFD over LAGs >> draft: >> http://tools.ietf.org/html/draft-mmm-bfd-on-lags-03 >> >> Toms, >> >> Let me answer your questions: >> >>> So where are we with the discussion of BFD over LAGs? >> >> We've been having offline discussions since quite some time and the -03 >> version of the draft is a result of those extensive discussions. >> >>> >>> Did we reach any conclusion on the layer that the "micro BFD sessions" >>> should operate in? Is there any update on whether the "micro >>> BFD sessions" need to use unicast or multicast addressing? >> >> Yes, to both. >> >> We believe its best to run it as Layer 3 Unicast. >> >>> Are the authors of draft-mmm-* coming up with a new version >>> that captures some progress? >> >> Yup, we have new co-authors and several contributors on the new version! >> >>> >>> We have also not heard what the WG chairs feel about the >>> whole discussion. It would be instructive to hear their take >>> on this as well. >> >> We have one of the chairs as a co-author now. So, we know at least what >> one of them feels about this! >> >> Cheers, Manav > > > This e-mail message is intended for the recipient only and contains inform= ation 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, p= hone or fax, and then delete the original and all copies thereof. > -- 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 Alexander.Vainshtein@ecitele.com Wed Feb 1 22:12:47 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 820F721F87E1 for ; Wed, 1 Feb 2012 22:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.509 X-Spam-Level: X-Spam-Status: No, score=-4.509 tagged_above=-999 required=5 tests=[AWL=0.694, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 nXOn+GOTawUp for ; Wed, 1 Feb 2012 22:12:46 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 014D721F87BA for ; Wed, 1 Feb 2012 22:12:32 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1328163088!52551240!20 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 16403 invoked from network); 2 Feb 2012 06:11:43 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-6.tower-27.messagelabs.com with SMTP; 2 Feb 2012 06:11:43 -0000 X-AuditID: 93eaf2e7-b7f2a6d000000e7d-b0-4f2a356e4057 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 0F.C5.03709.E653A2F4; Thu, 2 Feb 2012 09:04:14 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 2 Feb 2012 08:12:30 +0200 From: Alexander Vainshtein To: Jeffrey Haas , "rtg-bfd@ietf.org" Date: Thu, 2 Feb 2012 08:10:36 +0200 Subject: RE: Charter work for BFD over LAGs Thread-Topic: Charter work for BFD over LAGs Thread-Index: AczhVFu/kxqVsVdkSQGAbaP9+7SCggAHTJ9x Message-ID: References: <20120202024402.GH30217@slice> In-Reply-To: <20120202024402.GH30217@slice> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA1VTXUzTUBjlttsoSE0dzF0IxlqJ6BTDQONQZtQnfMD5gy+aiHW9bI1bt7QF xWhEEjWKqASIcQ+CSsQoEdD4EyHhL1HxQYnKNFPxP8QpPkwRJSi2KyK+nfudc77z3fa7BG4c MKQQvCAjUWA9jCFeVx2OfMsQllocmcevZdk6uob0tobnA7G2r2M3wCo8r6HhJ5b3uPK6fj22 pQzksoLgk1kZ0RySnHZmvciXsM5ShuY5O2NlaL+HdSIvEmQ7w/r9SOCYlfG5SpEXaCQ4fRwv uOzM2k2ODJttaU6GlVk5b641e0V8gZuXaJThZXkP7UWSxLoQrVTUMQUOcXSRT6RlN6LF7dW4 +9CjRtx/l9gdqqkzlIFRw1EQR0BqCTzX2Bur4Zmwb6BZqccTRqoDwNZL/XrtUAvgsZYmvaoy UHZ49fLLqDuJyoMVdwaBinFqGTw43BjtpKPSYNtwMKpJpBbCsVNtE/pF8Ef3g1gNZ8FgfT+u YpLaAC8+6Yn2N1IW+LqnMtozTvG2V4ajGqBMN3K/CdOyzDD0vg7TpqZgQ/tDXMMm+PHdb72m N8EXh5snZlsE69siBg0vhBfOfprInQF7T7/Xad5k2HXxme4kMAemRASm2ANT7IEp9nqguwRM vMcv7/C6Mq2LkZOXkQctdvq8V4G2KYO3wGhdWjegCMAkkC0VCxxGPVsilXq7QTKBMSbyV7rF YZy+w8eVulnJXSgWe5DUDSCBM0lk1VZFTnJs6R4k+v5SNuUrV+Ep05w+9WfLhdmZmf8dGDP5 wfk530i5lK3biZAfiX+tqQTBQLJ8vpI4Q0QutLuI98j/aIyIU5MTlOQTqoaU/KxX4l0afx/M STGTqSpBqYS7WJj0qs9i//j4eBiYlXsmkm5VlaBs46Q7rDTGlMYxNvVKkvIiJqmUMgDKIr1D 02reYcOdcfdGB9eFXlkK2wNkev/NN6vNH/vgoeSDwR5PV4+j48g29EufM2tX9Zrct8bZke93 +7KX50c68NZQbcmW0L4DvmudtUNZzWMm3ZUzqctvcyWRUHDTivMFWYGnwTv2VRXhvU+bNs78 klh+YuRVfkUVEYPF1m/ezugkN2u14KLE/gFA4f8c8QMAAA== Cc: "rtg-bfd-chairs@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, 02 Feb 2012 06:12:47 -0000 Yes/support. Regards, Sasha ________________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of Jeffr= ey Haas [jhaas@pfrc.org] Sent: Thursday, February 02, 2012 4:44 AM To: rtg-bfd@ietf.org Cc: rtg-bfd-chairs@ietf.org Subject: Charter work for BFD over LAGs Working Group, In the great tradition of many IETF working groups, while we've had great discussion over the topic of BFD over LAGs, it's not formally on our charter. To correct this, we need to request our charter be amended to cover this work. I propose the following text: http://datatracker.ietf.org/wg/bfd/charter/ 7. Provide one or more mechanisms to run BFD over Link Aggregation Group Interfaces. I would also propose a milestone to complete this work and send it to the IESG by December 2012. (And they'll respond that we need to update the dates on our other milestones, but that's a different discussion.) Please send feedback to the mailing list suggesting changes or additions to the charter item or the milestone date. -- Jeff 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 wim.henderickx@alcatel-lucent.com Wed Feb 1 22:13:34 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 65A0321F8A82 for ; Wed, 1 Feb 2012 22:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.02 X-Spam-Level: X-Spam-Status: No, score=-7.02 tagged_above=-999 required=5 tests=[AWL=-0.771, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 a7EklZqRR0jm for ; Wed, 1 Feb 2012 22:13:33 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 27A0821F8A76 for ; Wed, 1 Feb 2012 22:13:32 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q126DUoS004159 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 2 Feb 2012 07:13:30 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 2 Feb 2012 07:13:30 +0100 From: "Henderickx, Wim (Wim)" To: Alexander Vainshtein , Jeffrey Haas , "rtg-bfd@ietf.org" Date: Thu, 2 Feb 2012 07:13:29 +0100 Subject: RE: Charter work for BFD over LAGs Thread-Topic: Charter work for BFD over LAGs Thread-Index: AczhVFu/kxqVsVdkSQGAbaP9+7SCggAHTJ9xAAANNDA= Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D671D859CB4@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <20120202024402.GH30217@slice> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "rtg-bfd-chairs@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, 02 Feb 2012 06:13:34 -0000 Yes/support=20 -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Alexander Vainshtein Sent: donderdag 2 februari 2012 7:11 To: Jeffrey Haas; rtg-bfd@ietf.org Cc: rtg-bfd-chairs@ietf.org Subject: RE: Charter work for BFD over LAGs Yes/support. Regards, Sasha ________________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of Jeff= rey Haas [jhaas@pfrc.org] Sent: Thursday, February 02, 2012 4:44 AM To: rtg-bfd@ietf.org Cc: rtg-bfd-chairs@ietf.org Subject: Charter work for BFD over LAGs Working Group, In the great tradition of many IETF working groups, while we've had great discussion over the topic of BFD over LAGs, it's not formally on our charter. To correct this, we need to request our charter be amended to cover this work. I propose the following text: http://datatracker.ietf.org/wg/bfd/charter/ 7. Provide one or more mechanisms to run BFD over Link Aggregation Group Interfaces. I would also propose a milestone to complete this work and send it to the IESG by December 2012. (And they'll respond that we need to update the dates on our other milestones, but that's a different discussion.) Please send feedback to the mailing list suggesting changes or additions to the charter item or the milestone date. -- Jeff This e-mail message is intended for the recipient only and contains informa= tion 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, p= hone or fax, and then delete the original and all copies thereof. From Alexander.Vainshtein@ecitele.com Wed Feb 1 23:27:29 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7E421F8633 for ; Wed, 1 Feb 2012 23:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.428 X-Spam-Level: X-Spam-Status: No, score=-4.428 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 biAZAWiCpJ-q for ; Wed, 1 Feb 2012 23:27:28 -0800 (PST) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 19ACE21F8469 for ; Wed, 1 Feb 2012 23:27:27 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1328167646!9595650!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 1112 invoked from network); 2 Feb 2012 07:27:26 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-7.tower-21.messagelabs.com with SMTP; 2 Feb 2012 07:27:26 -0000 X-AuditID: 93eaf2e7-b7f2a6d000000e7d-10-4f2a46fc5473 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 87.97.03709.DF64A2F4; Thu, 2 Feb 2012 10:19:09 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 2 Feb 2012 09:27:25 +0200 From: Alexander Vainshtein To: Jeffrey Haas Date: Thu, 2 Feb 2012 09:26:09 +0200 Subject: RE: Updated BFD over LAGs draft Thread-Topic: Updated BFD over LAGs draft Thread-Index: AczhUIBvtX/erre+Q6mqvRb/EiDiPgAKh5oC Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com> <6BA87B92-7DD2-4F69-A574-B14D7FB50089@sniff.de>, <20120202021628.GF30217@slice> In-Reply-To: <20120202021628.GF30217@slice> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA1VTa0zTUBj1rtssuJIyhF0WTWpBI48hE03mY2rEIMbHNPpHYoK1vWyNW7e0 1TBNlMT4YhpFfPESUCTqTCREDRHRQPSHiJHER4iPxbcBJRrUGFGYLVXEf+d+55zvfO39Lo6Z I0YrzgsyEgXGSxtj9eV9A19tQ3npruyu7njHzfZ+g6PqYRRzfPl1FSzC8hsafujyHxy8Ysjf HQ7pV2MFJWA+Iwh+mZERxSGJddKrRX4rwwZpiuectJ2mAl6GRT4kyE6aCQSQwNELYucrRV6g kMD6OV5wO+lla102h2P2HJudXjAtxZ4zL3adh5coZPMxvJfyIUli3IhSKuqsAoc4qsgvUrIH UeLGcsxz8uqSwDtLcUdVlbEEDJtLQQwOyVnw1N0QpuEk2B25ZFSxmWwD8F315FIQq+ByACO/ qoFKGEknbA4/HxFNJKfA2uh+BeM4Rq6Azz+uKgXjcT2ZCiv8ajGBnA7rD7o0bRrcfaIXaHgm HGq/PRJKkGtg7WCPXgtq08HQ2SGdSsSQGfB004WRIKBM9r3z4kgdIy3wyZtanTYxCRuu3/8z fSLsfT1s0PSJ8NneS0DTZ8K61gGjhjNgY/2HP8Hx8E7FG73mTYbt53r0h4GlckxE5Rh75Rh7 5Rh7HdBfAIm8NyBv8rmz7VmI5WXkRVms39cMtE153wIGa1M7AIkD2kQ0hdJcZgOzVQr6OkAy rqMTiYK56S5z3CY/F/QwkqdQ3OJFUgeAOEZPJHbMUDiCY4LbkOj/SzmUf1yGWSewfvWe5cKc 7Oz/DrSFeMt+XGkm3crCbUYogMS/1kk4TkOCUxPjReRGxUW8V/5H6/AYNdmkJHtVDSEFGJ/E uzW+E0yxWojlKkGqhGeLMOpVn8XOaDTaByzKdyYQuarKpCziqLtPaaxTGo9zpKmNlccwSllL QF4v+yhpD2ZaPv2IozVMfLpxhdplrkl9GlrUfG+9YYPrRfHUV8dPNR7ICMx5/yi/Jk3uOtOz xPW44nLm48J6If5lUXjZs/MV4wabIuGH0aOdth8Fs5/2tkRSMk23Cq4ZfM6pZUcjs15nbV+c MtQo1H37mbudaP+8cGm/9VjcvmB/0iFaL3kYezomSsxvOAXC7PEDAAA= 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, 02 Feb 2012 07:27:29 -0000 Jeff, Lots of thanks for a prompt and clarifying response. I fully agree with your explanation regarding limited size of the MAC filter= ing cache in various Ethernet chips. This problem is, indeed, well recognized and must be addressed. IMHO and FWIW such a limitation would be best served if micro-BFD packets wo= uld use the peer LAG MAC address as the destination address. This is definitely possible if LACP is present and initiates micro-BFD sessi= ons as described in Section 3.1 of the draft. LAG without BFD presents lots of problems. E.g., one could imagine the case= (micro-BFD notwithstanding) when: - Layer 1 faults of the member links cannot be detected/used so that failed= links remain Distributing - ARP request/response packets are distributed to failed links (because this= is how the Distributor works) and hence blackholed - As a consequence, unicast IP would not be able use the seemingly alive LAG= at all. Do we really want to remedy this with micro-BFD sessions? If yes, then (a) IMHO it is worth explicitly noting such a scenario (b) A well-known MAC address for micro-BFD sessions would really help. My 2c, Sasha ________________________________________ From: Jeffrey Haas [jhaas@pfrc.org] Sent: Thursday, February 02, 2012 4:16 AM To: Marc Binderberger Cc: Alexander Vainshtein; rtg-bfd@ietf.org Subject: Re: Updated BFD over LAGs draft [Speaking as an individual contributor] Marc, On Thu, Feb 02, 2012 at 12:28:37AM +0100, Marc Binderberger wrote: > Regarding the change in the MAC address I leave this to George. I don't kn= ow how many devices are affected and need this "support". > My understanding is that Ethernet hardware exists where anything but the e= mbedded MAC is kind of an exception and the handling is "expensive". The mec= hanism itself seems relatively simple to me: > > [..] This will be used for the initial BFD down > packets of a session, while sending BFD Init and Up packets with the > MAC address learned from the received BFD packets. I won't speak for George's exact scenario, but I have at least one supporting one. Some Ethernet chips have a very small MAC cache that can be used for local addresses. Presume such a chip that supports 8 entries. If you have the standard unicast MAC address, you now have 7 MACs that can be used for other purposes such as multicast or other unicast purposes such as VRRP. Once you've exceeded the maximum number of entries, you may need to always punt traffic up to your primary CPU (pick your vendor specific lingo) for processing. In such circumstances, that traffic may at least be rate limited. In such circumstances, using the well known MAC address for bootstrapping purposes at the sedate BFD setup rate may be acceptable. My memory may be failing, but discussion around a similar issue may possibly be found in the VRRP mailing list archives. Multicast coders may also have similar experiences to share. -- Jeff 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 manav.bhatia@alcatel-lucent.com Thu Feb 2 00:22:09 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 7851021F8AC1 for ; Thu, 2 Feb 2012 00:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.629 X-Spam-Level: X-Spam-Status: No, score=-6.629 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 u6FtFMYbFiAm for ; Thu, 2 Feb 2012 00:22:09 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id E6F8621F8AAA for ; Thu, 2 Feb 2012 00:22:08 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q128M4VU004772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Feb 2012 02:22:07 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q128M1hq018738 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 2 Feb 2012 13:52:03 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 2 Feb 2012 13:52:01 +0530 From: "Bhatia, Manav (Manav)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Date: Thu, 2 Feb 2012 13:49:42 +0530 Subject: RE: Charter work for BFD over LAGs Thread-Topic: Charter work for BFD over LAGs Thread-Index: AczhVFu/kxqVsVdkSQGAbaP9+7SCggAHTJ9xAAI6FfA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02AB3A17@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.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, 02 Feb 2012 08:22:09 -0000 Hi Jeff, >=20 > http://datatracker.ietf.org/wg/bfd/charter/ >=20 > 7. Provide one or more mechanisms to run BFD over Link=20 > Aggregation Group Interfaces. Yes. >=20 > I would also propose a milestone to complete this work and=20 > send it to the IESG by December 2012. > (And they'll respond that we need to update the dates on our=20 > other milestones, but that's a different discussion.) >=20 > Please send feedback to the mailing list suggesting changes=20 > or additions to the charter item or the milestone date. In addition to this do we also want an item in our charter which asks the W= G to provide an auto discovery mechanism to detect the remote IP destinatio= ns for the micro BFD sessions?=20 Few of us are midway writing a draft that defines such a mechanism. Cheers, Manav From marc@sniff.de Thu Feb 2 01:57:36 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318D621F872B for ; Thu, 2 Feb 2012 01:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 pW8wE9P79aEF for ; Thu, 2 Feb 2012 01:57:35 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBDD21F8729 for ; Thu, 2 Feb 2012 01:57:27 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 7DACB2AA0F; Thu, 2 Feb 2012 09:57:25 +0000 (GMT) Subject: Re: Charter work for BFD over LAGs Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <20120202024402.GH30217@slice> Date: Thu, 2 Feb 2012 10:57:21 +0100 Content-Transfer-Encoding: 7bit Message-Id: <38313726-55EA-4BA0-B2E6-22D15F4F7AB4@sniff.de> References: <20120202024402.GH30217@slice> To: Jeffrey Haas X-Mailer: Apple Mail (2.1084) Cc: rtg-bfd-chairs@ietf.org, rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 09:57:36 -0000 Yes/support Regards, Marc On 2012-02-02, at 3:44 , Jeffrey Haas wrote: > Working Group, > > In the great tradition of many IETF working groups, while we've had great > discussion over the topic of BFD over LAGs, it's not formally on our > charter. To correct this, we need to request our charter be amended to > cover this work. I propose the following text: > > http://datatracker.ietf.org/wg/bfd/charter/ > > 7. Provide one or more mechanisms to run BFD over Link Aggregation Group > Interfaces. > > I would also propose a milestone to complete this work and send it to the > IESG by December 2012. > (And they'll respond that we need to update the dates on our other > milestones, but that's a different discussion.) > > Please send feedback to the mailing list suggesting changes or additions to > the charter item or the milestone date. > > -- Jeff > -- Marc Binderberger From jeff.tantsura@ericsson.com Thu Feb 2 02:18:52 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 6AFD321F8A5C for ; Thu, 2 Feb 2012 02:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 KwyuH54wsnQ4 for ; Thu, 2 Feb 2012 02:18:51 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id D726A21F8A59 for ; Thu, 2 Feb 2012 02:18:51 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q12AIitS032280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Feb 2012 04:18:51 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.33]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 2 Feb 2012 05:18:48 -0500 From: Jeff Tantsura To: Jeffrey Haas , "rtg-bfd@ietf.org" Date: Thu, 2 Feb 2012 05:18:47 -0500 Subject: RE: Charter work for BFD over LAGs Thread-Topic: Charter work for BFD over LAGs Thread-Index: AczhVJE2XVfauEgFTgmkdqP9eJBkIwAP3IRw Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6190F7EA7D7@EUSAACMS0701.eamcs.ericsson.se> References: <20120202024402.GH30217@slice> In-Reply-To: <20120202024402.GH30217@slice> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-bfd-chairs@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, 02 Feb 2012 10:18:52 -0000 Yes/support Regards, Jeff -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Jeffrey Haas Sent: Wednesday, February 01, 2012 6:44 PM To: rtg-bfd@ietf.org Cc: rtg-bfd-chairs@ietf.org Subject: Charter work for BFD over LAGs Working Group, In the great tradition of many IETF working groups, while we've had great d= iscussion over the topic of BFD over LAGs, it's not formally on our charter= . To correct this, we need to request our charter be amended to cover this= work. I propose the following text: http://datatracker.ietf.org/wg/bfd/charter/ 7. Provide one or more mechanisms to run BFD over Link Aggregation Group In= terfaces. I would also propose a milestone to complete this work and send it to the I= ESG by December 2012. (And they'll respond that we need to update the dates on our other mileston= es, but that's a different discussion.) Please send feedback to the mailing list suggesting changes or additions to= the charter item or the milestone date. -- Jeff From shane@castlepoint.net Thu Feb 2 06:49:05 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F85F21F858E for ; Thu, 2 Feb 2012 06:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 BNQ64BaBUhxW for ; Thu, 2 Feb 2012 06:49:05 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 3675A21F858D for ; Thu, 2 Feb 2012 06:49:05 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 976F826806D; Thu, 2 Feb 2012 07:49:04 -0700 (MST) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 02 Feb 2012 07:49:04 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=59451; data-bytes=0 Subject: Re: Charter work for BFD over LAGs Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <20120202030912.GJ30217@slice> Date: Thu, 2 Feb 2012 07:49:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120202024402.GH30217@slice> <20120202030912.GJ30217@slice> To: Jeffrey Haas X-Mailer: Apple Mail (2.1251.1) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 14:49:05 -0000 Yes/support. -shane On Feb 1, 2012, at 8:09 PM, Jeffrey Haas wrote: > On Thu, Feb 02, 2012 at 08:23:32AM +0530, Glen Kent wrote: >> Looks good to me. Do you think we will be able to send it to IESG by >> the end of this year? We dont even have a WG document yet? >=20 > My suspicion is that draft-mmm-bfd-on-lags could be one of those = mechanisms. > :-) >=20 > This of course depends on WG consensus on adopting that draft. We can = talk > about adoption of specific drafts once we have an updated charter. It = may > also be reasonable to push the milestone date out to accommodate other > proposals. >=20 > Other opinions on the milestone date vs. open work? >=20 > -- Jeff From manav.bhatia@alcatel-lucent.com Thu Feb 2 07:33:16 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 2F62B21F85C7 for ; Thu, 2 Feb 2012 07:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.629 X-Spam-Level: X-Spam-Status: No, score=-8.629 tagged_above=-999 required=5 tests=[AWL=1.970, 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 3y4Js4UqWWRZ for ; Thu, 2 Feb 2012 07:33:15 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2F12921F85B5 for ; Thu, 2 Feb 2012 07:33:12 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q12FX6du001200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Feb 2012 09:33:08 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q12FX4FH016754 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 2 Feb 2012 21:03:05 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Thu, 2 Feb 2012 21:03:04 +0530 From: "Bhatia, Manav (Manav)" To: Alexander Vainshtein , Marc Binderberger Date: Thu, 2 Feb 2012 21:03:03 +0530 Subject: RE: Updated BFD over LAGs draft Thread-Topic: Updated BFD over LAGs draft Thread-Index: AczhORMqBZ3WwFzvQCKQQGxCZTkSpgAMd6Y4ABToIDA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02AB3B53@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com> , <6BA87B92-7DD2-4F69-A574-B14D7FB50089@sniff.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 15:33:16 -0000 Hi Sasha, Thanks for the comments. These are indeed very helpful. [clipped] > indeed. If it helps we could talk about "allows to verify=20 > aspects of L3 connectivity". If and how much of the L3=20 > connectivity and code path is tested with the BFD=20 > implementation is indeed and deliberately left to the implementor. >=20 > [[Sasha]] "some implementation-specific asppects of L3=20 > connectivity" sounds like an accurate description of what you=20 > guys try to achieve. So why not to say that? Please note also=20 > that there are two sides to ths "partial L3 connectivity=20 > verification": > - you may declare a link OK while actually received IP=20 > packets are not forwarded properly > - the link may be OK but mico-BFD session fails. This could=20 > be the case when, say, your IP stack only accepts unicast IP=20 > packets with port (or LAG) destination MAC address (AFAIK,=20 > quite a few implementations do that). If you use your=20 > "dedicated MAC address" to bring up the session while this is=20 > not resolved, the session simly will not come up no matter=20 > what really happens... IS-IS has similar properties as the micro BFD sessions that we're describin= g. Theoretically its possible in some buggy implementations for IS-IS adjac= ency to come up, while the IP traffic learnt over the ISIS session to get d= ropped. This however has not detered people from using IS-IS. > Maybe you should discuss these two situations (say, in a=20 > "Guidelines for the Implementor" Annex to the draft)? >=20 > > 3. In Section 2.2. I've found a couple of statements that=20 > imply availability of the information about the physical=20 > ingress port of an IP packet to > > the appropriate "handling" entity. This looks to me=20 > like a strong requirement because (and this has been=20 > discussed on the list) > > some existing implementations do not provide this information I think this information is trivially available in all implementations. If = not, then how do such implementations handle IS-IS? > > 4. In the same section, there are certain issues regarding=20 > MAC addresses in the Ethernet encapsulation of the micro-BFD packets: > > - The Source MAC address is required to match the MAC=20 > address of the physical port on which the micro-BFD session runs. This > > implies bypass of the "regular" IP stack (because it=20 > would use the same Source MAC address for all the packets=20 > sent via LAG) and, > > incidentally, compromises the claim that=20 > UDP/IP-encapsulation of the micro-BFD packets helps to verify=20 > IP connectivity over the link. >=20 > It is a balance between staying close to the layer-3 path and=20 > doing what is written in the draft. And it is again a matter=20 > of the implementors ideas. You could well run the full=20 > "normal" path and as a last step overwrite all the MAC, port,=20 > etc values. That would catch all the errors that may happen=20 > in the normal path. >=20 > [[Sasha]] Why not to send all these packets with the LAG MAC=20 > address as the destination? > Anyway your L3 stack would need this address for sending=20 > unicast IP traffic (be it via ARP, PPPoE, DHCP snooping,=20 > configuration or anything else). We cannot use LAG MAC address as the dest MAC since this requires resolving= ARP before the micro sessions are set up. This means that ARP resolution m= ust work on links that are currently down. This to me is an egregious viola= tion of the ARP standards. [clipped] =20 > > 6. The text in the same section states that " BFD, as a=20 > layer 3 protocol, is viewed as running across the LAG, with =20 > load balancing constraints > > ensuring particular micro BFD sessions are effectively=20 > bound to particular member links". Does this mean that=20 > micro-BFD sessions send and receive > > packets using the Agg: MA-UNITDATA service primitives? >=20 > No, we are not trying to make any such statement about the=20 > service interface to use. What is wants to say is that=20 > "ensuring particular micro BFD sessions are effectively bound=20 > to particular member links" is required. I.e. that the ssion=20 > packets go out from the right port. > If you think this text part is confusing then we may have to=20 > reword this a bit. >=20 I agree that the text in -03 isnt very clear. We will fix this in -04.=20 Cheers, Manav= From manav.bhatia@alcatel-lucent.com Thu Feb 2 07:55:58 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0FE21F8577 for ; Thu, 2 Feb 2012 07:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.67 X-Spam-Level: X-Spam-Status: No, score=-8.67 tagged_above=-999 required=5 tests=[AWL=1.929, 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 NukMJe8Guk99 for ; Thu, 2 Feb 2012 07:55:57 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id A0EC821F85B1 for ; Thu, 2 Feb 2012 07:55:57 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q12FtrX2011874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Feb 2012 09:55:55 -0600 (CST) 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 q12FtqFZ017524 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 2 Feb 2012 21:25:52 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 2 Feb 2012 21:25:52 +0530 From: "Bhatia, Manav (Manav)" To: Tom Sanders Date: Thu, 2 Feb 2012 21:25:52 +0530 Subject: RE: Updated BFD over LAGs draft Thread-Topic: Updated BFD over LAGs draft Thread-Index: AczhHC2+p0jC/fusQ5OJQd3XyFZGuAAo9phQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02AB3B55@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 15:55:58 -0000 Hi Toms, > > We believe its best to run it as Layer 3 Unicast. >=20 > I was, and still continue to be, a big fan of multicast as=20 > that saves you a lot of configuration overhead. Any=20 > particular reason why you didnt go with that approach? >=20 > BTW, if i am not mistaken, that was your preferred approach=20 > too, wasnt it? Yes, I was initially rooting for multicast encapsulation. My biggest gripe with Unicast was the extensive configuration overload that= it entailed. This can be fixed by trivially defining an auto-discovery mec= hanism that will discover the remote destination IP addresses. My other gripe with Unicast was with resolving ARP before the micro session= s can be boot strapped. This opened a hole for DoS attacks and if nothing e= lse is a gross violation of the basic IP tenets. This has been fixed in -03= by using a well known IANA assigned MAC for the initial BFD packets. The primary advantage of using Unicast is that its closer to how other traf= fic will be dealt with and it makes it possible for us to reuse pretty much= the same code and ASIC capabilities that exist today for supporting regula= r BFD (BBP flavor). Cheers, Manav From Alexander.Vainshtein@ecitele.com Thu Feb 2 07:58:35 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F9021F85C4 for ; Thu, 2 Feb 2012 07:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.446 X-Spam-Level: X-Spam-Status: No, score=-4.446 tagged_above=-999 required=5 tests=[AWL=0.756, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 Huq7zYQPZBov for ; Thu, 2 Feb 2012 07:58:32 -0800 (PST) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id BA11B21F85A4 for ; Thu, 2 Feb 2012 07:58:31 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1328198309!4807583!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 28439 invoked from network); 2 Feb 2012 15:58:29 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-16.tower-21.messagelabs.com with SMTP; 2 Feb 2012 15:58:29 -0000 X-AuditID: 93eaf2e7-b7f2a6d000000e7d-2c-4f2abec16c74 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 15.D5.03709.1CEBA2F4; Thu, 2 Feb 2012 18:50:09 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 2 Feb 2012 17:58:28 +0200 From: Alexander Vainshtein To: "Bhatia, Manav (Manav)" Date: Thu, 2 Feb 2012 17:58:27 +0200 Subject: RE: Updated BFD over LAGs draft Thread-Topic: Updated BFD over LAGs draft Thread-Index: AczhORMqBZ3WwFzvQCKQQGxCZTkSpgAMd6Y4ABToIDAAAGn8sA== Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com> , <6BA87B92-7DD2-4F69-A574-B14D7FB50089@sniff.de> <7C362EEF9C7896468B36C9B79200D8350D02AB3B53@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02AB3B53@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C760116340CE70DILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTfUgTYRzu3W3ztnZ5runepOK6otDSXFYsaiZRYZbNKIiMsmt73Y5ut3F3 ShaVfVEpQbEim1IKElpCZh9q3/pPKkFfRt9CalomCRpJn+vOQ/Of/nve53l+z/vc8XtxzHwo IhZneQkJPMPReqM22DvwNaHxbrwzqblnkb20vV1nL2kLY/bBXzdAKpZ2uPuOLq2i4rsm7fCl Im0mllUAljA875cYCVFuJLocdKbA5jGufJpi3Q7aRlMBjnEhH+IlB80EAoh30ynGJTLJ8hTi XX43y3sc9Kr1zgS7fcGiBBudMnO6LXmxcYOXFSmU4GNYjvIhUWQ8iJIZpSvvRm4qxy9QkhdR wrYg5n1T04IFunJ2/rqXWgCCGwsBjkNyPnzSqisEBhnGwMftl/WFwIibyTsANu/v0qmHIIA3 atswxaUnHbD20ju9gi0y7rl6U6sEYeQa+K5vrUJryRmw5FD1sGUiGQcPNNZhqj0eFhzsH7Zb yGWwozJSgQS5Dj4t36LeVI/B4upwhGI3kFvhtwNHhzGQuw21VmsUjJFW+LrrvEbtTMKK248w FUfDT51/dKo/Gr49chmofj88c+3ncB2CjIItZ7u0qn8SbKx8qT0BYkJjYkNjRkJjRlR+Diy7 NaBX8Wx4ofwzNoIf3u/UjOXLQMRFEM1yAWm7z5NkS0QuVkIcSnT5fbVAXaGeevDj/IwmQOKA NhE1RXFOs47JE/N9TWASrqGjCbwm3mmesN3vzvcyojdbyOWQ2AQgjtEWglkma4Sbyd+FBP+I tEL++Sex2PEuv7IAUnZyUtL/D7SV+ODqyzCTHnktdyAUQMJIzmQcpyHx5Yp8RZSAPGhnDstJ /2QNblBqmOQa5lqlhhhgfCLrUfVWMC3WSvxWhklF8Obyo7PK49kXDod7gVX+6IlEv+Iyyes6 Ot0rB2vk4HH2OCVYfjKjUmwBOHnc0Z0xKBozq17Yzw3uhlzpqevQkp7+Iee9qbJjb7qlCO05 3XBxaWgo4Cx/OiVqatbttYUD/KaOVw+eHX+0xp5my90WE2nb1L+6LGveseK5C2c1LN8y78rK jy3dMydvPmUQGhYYylLbXliznwcTIzubHnZrqr5NMTWH9nGslFmXQmtFL2OLxwSR+QvtIr6X FwQAAA== 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, 02 Feb 2012 15:58:35 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760116340CE70DILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Manav, Lots of thanks for a prompt response. Please see some answers/comments inline below (bold blue to make them readab= le). I have removed the fragments of the original emails that are not relevant to= these comments. Regards, Sasha > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Thursday, February 02, 2012 5:33 PM > To: Alexander Vainshtein; Marc Binderberger > Cc: rtg-bfd@ietf.org > Subject: RE: Updated BFD over LAGs draft > > Hi Sasha, > > Thanks for the comments. These are indeed very helpful. > > [clipped] > ... snipped by Sasha ... > IS-IS has similar properties as the micro BFD sessions that we're describi= ng. > Theoretically its possible in some buggy implementations for IS-IS > adjacency to come up, while the IP traffic learnt over the ISIS session to= get > dropped. This however has not detered people from using IS-IS. > [[[Sasha]]] I fully agree regarding similarity between IS-IS and micro-BFD s= essions and popularity of IS-IS. However, to me it cuts both ways: If IS-IS not using IP encapsulation did not deter people from using it for c= reating intra-AS IP connectivity, I do not see why micro-BFD without IP enca= psulation should be treated differently... but this is actually a side issue= . > ... snipped by Sasha ... > > 3. In Section 2.2. I've found a couple of statements that imply availab= ility of the information about the physical > > ingress port of an IP packet to the appropriate "handling" entity. Th= is looks to me like a strong requirement because (and this has been > > discussed on the list) some existing implementations do not provide thi= s information > > I think this information is trivially available in all implementations. If= not, > then how do such implementations handle IS-IS? > [[[Sasha]]] If you run IS-IS over LAG, you only need to know which LAG its p= ackets have been received from. If you run it over a single physical link, you need the information regardin= g the physical ingress port. But I do not see why IS-IS would be interested in the physical ingress port= in a LAG. > > > > [[Sasha]] Why not to send all these packets with the LAG MAC > > address as the destination? > > Anyway your L3 stack would need this address for sending > > unicast IP traffic (be it via ARP, PPPoE, DHCP snooping, > > configuration or anything else). > > We cannot use LAG MAC address as the dest MAC since this requires > resolving ARP before the micro sessions are set up. This means that ARP > resolution must work on links that are currently down. This to me is an > egregious violation of the ARP standards. > [[[Sasha]]] First of all, ARP in LAG does not run over a specific link - it= runs over LAG and resolves the peer LAG IP address to the peer LAG MAC addr= ess. This means that running IP over LAG without LACP over a bunch of links that= do not report Layer 1 faults (and hence remain permanently UP) is problemat= ic: If your Distributor selects a de-facto faulty link to send your ARP, it will= never be resolved, and unicast IP will never come up. However, with LACP this will not happen, because faulty links will be eventu= ally excluded from distribution. At the same time, if LACP is used with LAG,= the peer LAG MAC address is also known (LACP carries it across). To me this= means that the only possible benefit of using some special MAC address in m= icro-BFD is LAG without LACP and without Layer 1 failure detection in the me= mber links. Do we really want to remedy this? How often would such a scenari= o be deployed taking into account that without micro-BFD there is running ch= ance of never bringing up IP forwarding across LAG with some healthy links? ... snipped by Sasha ... [[[Sasha]]] > Cheers, Manav 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. --_000_A3C5DF08D38B6049839A6F553B331C760116340CE70DILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Manav,

Lots of thanks for a prompt response.

 

P= lease see some answers/comments inline below (bold blue to make them re= adable).

I have removed the fragments= of the original emails that are not relevant to these comments.<= /p>

 

Rega= rds,

     Sasha

 

> -----Original Message-----

> From: B= hatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]

> Sent: Thursday, February 02, 2012 5:33 PM

> To: Alexander Vainshtein; Marc Binderberger

> Cc: rtg-bfd@ietf.org

> Subject= : RE: Updated BFD over LAGs draft

>

> Hi Sasha,

>

> Thanks for the comments. These are indeed very helpful= .

>

> [clipped]=

>

... snipped by Sasha ...

> IS-IS has similar properties as the micro BFD sessions= that we're describing.

> Theoretically its po= ssible in some buggy implementations for IS-IS

&g= t; adjacency to come up, while the IP traffic learnt over the ISIS session t= o get

> dropped. This however has not detered= people from using IS-IS.

>

[[[Sasha]]] I fully agree regardi= ng similarity between IS-IS and micro-BFD sessions and popularity of IS-IS.= However, to me it cuts both ways:

If IS-IS not using IP encapsulation= did not deter people from using it for creating intra-AS IP connectivity, I= do not see why micro-BFD without IP encapsulation should be treated differe= ntly... but this is actually a side issue.

>

... snipped by Sasha ...

> > 3.  In Section 2.2. I've found a couple of statements tha= t imply availability of the information about the physical

> > ingress port of an IP packet to   the appropri= ate "handling" entity.  This looks to me like a strong requir= ement because (and this has been

> > discus= sed on the list) some existing  implementations do not provide this inf= ormation

>

> I= think this information is trivially available in all implementations. If no= t,

> then how do such implementations handle I= S-IS?

>

[[[Sasha]]] If you run IS-IS over LAG, you only need= to know which LAG its packets have been received from.

If you run it= over a single physical link, you need the information regarding the physica= l ingress port.

But I do not see why IS-IS would be interested in the= physical ingress port in a LAG.

 

> >

> > [[Sasha]]= Why not to send all these packets with the LAG MAC

> > address as the destination?

> >= ; Anyway your L3 stack would need this address for sending

> > unicast IP traffic (be it via ARP, PPPoE, DHCP snooping,=

> > configuration or anything else).

>

> We cannot use LA= G MAC address as the dest MAC since this requires

> resolving ARP before the micro sessions are set up. This means that AR= P

> resolution must work on links that are cur= rently down. This to me is an

> egregious viol= ation of the ARP standards.

> =

[[[Sasha]]] Fir= st of all, ARP in LAG does not run over a specific link – it runs over= LAG and resolves the peer LAG IP address to the peer LAG MAC address.<= /o:p>

This means that running IP over LAG without LACP over a bunch of links that= do not report Layer 1 faults (and hence remain permanently UP) is problemat= ic:

If your Distributor selects a de-facto faulty link to send your AR= P, it will never be resolved, and unicast IP will never come up.<= /span>

Howev= er, with LACP this will not happen, because faulty links will be eventually= excluded from distribution. At the same time, if LACP is used with LAG, the= peer LAG MAC address is also known (LACP carries it across). To me this mea= ns that the only possible benefit of using some special MAC address in micro= -BFD is LAG without LACP and without Layer 1 failure detection in the member= links. Do we really want to remedy this? How often would such a scenario be= deployed taking into account that without micro-BFD there is running chance= of never bringing up IP forwarding across LAG with some healthy links?=

 

... snipped by Sasha ...<= /o:p>

[[= [Sasha]]]

<= p class=3DMsoPlainText>> Cheers, Manav

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.

--_000_A3C5DF08D38B6049839A6F553B331C760116340CE70DILPTMAIL02e_-- From manav.bhatia@alcatel-lucent.com Thu Feb 2 08:13:18 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 2A58E21F84F5 for ; Thu, 2 Feb 2012 08:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.709 X-Spam-Level: X-Spam-Status: No, score=-8.709 tagged_above=-999 required=5 tests=[AWL=1.889, 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 SqoaCI+wU+oz for ; Thu, 2 Feb 2012 08:13:15 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7610B21F84D7 for ; Thu, 2 Feb 2012 08:13:15 -0800 (PST) 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 q12GD575023552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Feb 2012 10:13:07 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q12GD4gl018166 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 2 Feb 2012 21:43:05 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Thu, 2 Feb 2012 21:43:04 +0530 From: "Bhatia, Manav (Manav)" To: Alexander Vainshtein Date: Thu, 2 Feb 2012 21:43:07 +0530 Subject: RE: Updated BFD over LAGs draft Thread-Topic: Updated BFD over LAGs draft Thread-Index: AczhORMqBZ3WwFzvQCKQQGxCZTkSpgAMd6Y4ABToIDAAAGn8sAAA60nw Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02AB3B59@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com> , <6BA87B92-7DD2-4F69-A574-B14D7FB50089@sniff.de> <7C362EEF9C7896468B36C9B79200D8350D02AB3B53@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7C362EEF9C7896468B36C9B79200D8350D02AB3B59INBANSXCHMBSA_" 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: Thu, 02 Feb 2012 16:13:18 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350D02AB3B59INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sasha, > adjacency to come up, while the IP traffic learnt over the ISIS session t= o get > dropped. This however has not detered people from using IS-IS. > [[[Sasha]]] I fully agree regarding similarity between IS-IS and micro-BFD = sessions and popularity of IS-IS. However, to me it cuts both ways: If IS-IS not using IP encapsulation did not deter people from using it for = creating intra-AS IP connectivity, I do not see why micro-BFD without IP en= capsulation should be treated differently... but this is actually a side is= sue. [Manav] This is as you say is a side issue. By using IP encapsulation we l= everage the existing code and the chip capabilities to a large extent. The = extent of leverage one gets is implementation and platform dependent. The reason i had brought up IS-IS was to counter your point about micro BFD= sessions not relaying the true health of the member links for IP traffic. > ... snipped by Sasha ... > > 3. In Section 2.2. I've found a couple of statements that imply availa= bility of the information about the physical > > ingress port of an IP packet to the appropriate "handling" entity. T= his looks to me like a strong requirement because (and this has been > > discussed on the list) some existing implementations do not provide th= is information > > I think this information is trivially available in all implementations. I= f not, > then how do such implementations handle IS-IS? > [[[Sasha]]] If you run IS-IS over LAG, you only need to know which LAG its = packets have been received from. If you run it over a single physical link, you need the information regardi= ng the physical ingress port. But I do not see why IS-IS would be interested in the physical ingress port= in a LAG. [Manav] If an implementation can pass the information about the physical in= gress port in one scenario then why cant it pass the same information in ca= se of a LAG? Isnt this an implementation specific issue that we're dealing = with here. I would like to know which commercial implementation that wants = to run micro BFD sessions will not be capable of passing such information t= hat enables the SW to learn about the ingress port the packet arrived on? > We cannot use LAG MAC address as the dest MAC since this requires > resolving ARP before the micro sessions are set up. This means that ARP > resolution must work on links that are currently down. This to me is an > egregious violation of the ARP standards. > [[[Sasha]]] First of all, ARP in LAG does not run over a specific link - it= runs over LAG and resolves the peer LAG IP address to the peer LAG MAC add= ress. This means that running IP over LAG without LACP over a bunch of links that= do not report Layer 1 faults (and hence remain permanently UP) is problema= tic: If your Distributor selects a de-facto faulty link to send your ARP, it wil= l never be resolved, and unicast IP will never come up. However, with LACP this will not happen, because faulty links will be event= ually excluded from distribution. At the same time, if LACP is used with LA= G, the peer LAG MAC address is also known (LACP carries it across). To me t= his means that the only possible benefit of using some special MAC address = in micro-BFD is LAG without LACP and without Layer 1 failure detection in t= he member links. Do we really want to remedy this? How often would such a s= cenario be deployed taking into account that without micro-BFD there is run= ning chance of never bringing up IP forwarding across LAG with some healthy= links? [Manav] I believe a solution gets automatically rejected if we come across = even one scenario where it doesnt work. Regular ARP as you yourself noted c= an fail in the absence of LACP. I think we want a solution that works both = in the presence and the absence of LACP. Cheers, Manav --_000_7C362EEF9C7896468B36C9B79200D8350D02AB3B59INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Sasha,
 

> adjacency to come up, while the IP traffic l= earnt=20 over the ISIS session to get

> dropped. This however has not detered people= from=20 using IS-IS.

>

[[[Sasha]]] I f= ully=20 agree regarding similarity between IS-IS and micro-BFD sessions and popul= arity=20 of IS-IS. However, to me it cuts both ways:

If IS-IS n= ot using=20 IP encapsulation did not deter people from using it for creating intra-AS= IP=20 connectivity, I do not see why micro-BFD without IP encapsulation should = be=20 treated differently... but this is actually a side issue. 

 

[Manav]  This is as you say is a side issue. By using IP encapsula= tion we=20 leverage the existing code and the chip capabilities to a large extent. T= he=20 extent of leverage one gets is implementation and platform=20 dependent.

 

The reason i had= brought=20 up IS-IS was to counter your point about micro BFD sessions not relaying = the=20 true health of the member links for IP=20 traffic.

 

>

... snippe= d by=20 Sasha ...  

> > 3.  In Section 2.2. I've found a c= ouple=20 of statements that imply availability of the information about the=20 physical

> > ingress port of an IP packet to=20   the appropriate "handling" entity.  This looks to me lik= e a=20 strong requirement because (and this has been

> > discussed on the list) some existing&nb= sp;=20 implementations do not provide this information

>

> I think this information is trivially availa= ble in=20 all implementations. If not,

> then how do such implementations handle IS-I= S?

>

[[[Sasha]]] If = you run=20 IS-IS over LAG, you only need to know which LAG its packets have been rec= eived=20 from.

If you run it o= ver a=20 single physical link, you need the information regarding the physical ing= ress=20 port.

But I do n= ot see=20 why IS-IS would be interested in the physical ingress port in a=20 LAG. 

 

[Manav] If an=20 implementation can pass the information about the physical ingress=20 port in one scenario then why cant it pass the same information in c= ase=20 of a LAG? Isnt this an implementation specific issue that we're dealing w= ith=20 here. I would like to know which commercial implementation that wants to = run=20 micro BFD sessions will not be capable of passing such information t= hat=20 enables the SW to learn about the ingress port the packet arrived=20 on?

 

> We cannot use LAG MAC address as the dest MA= C since=20 this requires

> resolving ARP before the micro sessions are = set up.=20 This means that ARP

> resolution must work on links that are curre= ntly=20 down. This to me is an

> egregious violation of the ARP standards.

> 

[[[Sasha]]] Fir= st of=20 all, ARP in LAG does not run over a specific link – it runs over LA= G and=20 resolves the peer LAG IP address to the peer LAG MAC=20 address.

This means that= running=20 IP over LAG without LACP over a bunch of links that do not report Layer 1= =20 faults (and hence remain permanently UP) is=20 problematic:

If your Distrib= utor=20 selects a de-facto faulty link to send your ARP, it will never be resolve= d,=20 and unicast IP will never come up.

However, w= ith LACP=20 this will not happen, because faulty links will be eventually excluded fr= om=20 distribution. At the same time, if LACP is used with LAG, the peer LAG MA= C=20 address is also known (LACP carries it across). To me this means that the= only=20 possible benefit of using some special MAC address in micro-BFD is LAG wi= thout=20 LACP and without Layer 1 failure detection in the member links. Do we rea= lly=20 want to remedy this? How often would such a scenario be deployed taking i= nto=20 account that without micro-BFD there is running chance of never bringing = up IP=20 forwarding across LAG with some healthy links? 

 

[Manav] I believe a solutio= n gets=20 automatically rejected if we come across even one scenario where it doesn= t=20 work. Regular ARP as you yourself noted can fail in the absence of LACP. = I=20 think we want a solution that works both in the presence and the absence = of=20 LACP.

 

Cheers,=20 Manav

--_000_7C362EEF9C7896468B36C9B79200D8350D02AB3B59INBANSXCHMBSA_-- From Alexander.Vainshtein@ecitele.com Thu Feb 2 09:23: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 250C921F85D3 for ; Thu, 2 Feb 2012 09:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.464 X-Spam-Level: X-Spam-Status: No, score=-4.464 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 GIt+kvzdsnkL for ; Thu, 2 Feb 2012 09:23:52 -0800 (PST) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id B987621F85BB for ; Thu, 2 Feb 2012 09:23:51 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1328203428!8969285!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 3153 invoked from network); 2 Feb 2012 17:23:49 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-6.tower-21.messagelabs.com with SMTP; 2 Feb 2012 17:23:49 -0000 X-AuditID: 93eaf2e7-b7f2a6d000000e7d-e2-4f2ad2c0576a Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id D8.37.03709.0C2DA2F4; Thu, 2 Feb 2012 20:15:28 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 2 Feb 2012 19:23:47 +0200 From: Alexander Vainshtein To: "Bhatia, Manav (Manav)" Date: Thu, 2 Feb 2012 19:23:46 +0200 Subject: RE: Updated BFD over LAGs draft Thread-Topic: Updated BFD over LAGs draft Thread-Index: AczhORMqBZ3WwFzvQCKQQGxCZTkSpgAMd6Y4ABToIDAAAGn8sAAA60nwAAJfAFA= Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com> , <6BA87B92-7DD2-4F69-A574-B14D7FB50089@sniff.de> <7C362EEF9C7896468B36C9B79200D8350D02AB3B53@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D02AB3B59@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02AB3B59@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C760116340CE734ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTW0zTUBj2tF0pg2qZjB0XH0olJgwwLEoyozOKmmC8oNEXTBTKetyqW7e0 1TAflChoxEu8RA2IggoGLxGvaFBU5h1NNMb7BTWixmk0AgkRjdiugrz49p3v+/7v/8/Jfyjc 0kfaKVFSkSzxfo40Ezuind1ZrQ8c+dl3ClzV7e0mV9evJjAZyyv/0GLKq6v7gc3FFpaCibwk BVVeRayAFI+bmyuLK3hPmGNFwc05OTbk5z0ogCTVzfGhEJIEbpJ5okaKEoskT1AQJa+bmzE/ P8vlyhmf5eQmjR7lHDvBvMAnKizKCvCinw0gReG9iNUYfUBJQAK7JCizqg+xctEO3Fde3gBC FbWgpLPsJCgFvzaAChBPQWYc3NX0AzNwCrzf3khWADNlYS4D2La3GhiHnQC+udUYp7tIxg1P HX1F6jhZwx9PNxM6xpl0uOZWV8xDMGnwWd2mGD9c51vP4YbfAUvXfiMMPAdeuPlC4ymKZubB 900lRq+HBOzoOhDzxzOLYf2j+lgvoE3X03YMM3rZ4POOmr9TM7Du4j3cwFb46d1vk+G3wpfr G4HhD8K3zcdiOTSTBG9XdhCGfwRsbXhKbAUpVYNiqwaVVA0qMfhMWHuhkzRwBjy0/zPej+9e eYcN5mtB3BFgFf0htTjgzXaOQR5RRX40xhMMnALG9nw8D3pr0iKAoQCXSJ/YmJ5vMfErlHAg AkZQGGelHRFHvmVocVAI+3jFVygv9yMlAiCFc8k0n6tptMCHVyI52C9N115/G25P8AT1NVAL x2Zn///A2ej3ni+zLYxXW85lCIWQ3J8zkqI4SP+8rrVIkpEXlSwR/eo/GaPi9TEStTGe6B5a CfEBRfQaehtItdto8oYmMLrgWy4N1Or/ZnVfX18U2LRLD6e/6+WJ2tIOVEe1YEwLHuJK14O1 jzMg2UtB5egtlfNn3c+JRqIp1T27Zgr88bKM2Rmfhy1qGbq5oaz4U9Ge7b1LW8Sv6xIy6kOE nFmwOrwteV7O1EDhibOpjn3uM9vDFQt3229u9JN59w7nuuOurbJe33vJXPCwO9ec9romaUpP NLPj8EHf1acNtk7T4+7vJDFtbW8qMqdzmecSOELx8U4HLiv8H31MHwESBAAA 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, 02 Feb 2012 17:23:56 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760116340CE734ILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hi Manav, Lots of thanks for a prompt response. Some responses inline (bold purple). Regards, Sasha From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Thursday, February 02, 2012 6:13 PM To: Alexander Vainshtein Cc: rtg-bfd@ietf.org Subject: RE: Updated BFD over LAGs draft Hi Sasha, > adjacency to come up, while the IP traffic learnt over the ISIS session to= get > dropped. This however has not detered people from using IS-IS. > [[[Sasha]]] I fully agree regarding similarity between IS-IS and micro-BFD s= essions and popularity of IS-IS. However, to me it cuts both ways: If IS-IS not using IP encapsulation did not deter people from using it for c= reating intra-AS IP connectivity, I do not see why micro-BFD without IP enca= psulation should be treated differently... but this is actually a side issue= . [Manav] This is as you say is a side issue. By using IP encapsulation we le= verage the existing code and the chip capabilities to a large extent. The ex= tent of leverage one gets is implementation and platform dependent. The reason i had brought up IS-IS was to counter your point about micro BFD= sessions not relaying the true health of the member links for IP traffic. [[[Sasha]]] We all seem to agree that this is a side issue, so let's stop he= re. > ... snipped by Sasha ... > > 3. In Section 2.2. I've found a couple of statements that imply availab= ility of the information about the physical > > ingress port of an IP packet to the appropriate "handling" entity. Th= is looks to me like a strong requirement because (and this has been > > discussed on the list) some existing implementations do not provide thi= s information > > I think this information is trivially available in all implementations. If= not, > then how do such implementations handle IS-IS? > [[[Sasha]]] If you run IS-IS over LAG, you only need to know which LAG its p= ackets have been received from. If you run it over a single physical link, you need the information regardin= g the physical ingress port. But I do not see why IS-IS would be interested in the physical ingress port= in a LAG. [Manav] If an implementation can pass the information about the physical ing= ress port in one scenario then why cant it pass the same information in case= of a LAG? Isnt this an implementation specific issue that we're dealing wit= h here. I would like to know which commercial implementation that wants to r= un micro BFD sessions will not be capable of passing such information that e= nables the SW to learn about the ingress port the packet arrived on? [[[Sasha]]] One suspicious use case could be the regular Linux IP stack with= its socket interface. And, by your logic below, if there is one case when i= t does not work, this is enough to bring the entire construction down, right= ? To make it absolutely clear, I only wanted to explicitly state the requireme= nt on the LAG behavior if it is not part of an appropriate standard. > We cannot use LAG MAC address as the dest MAC since this requires > resolving ARP before the micro sessions are set up. This means that ARP > resolution must work on links that are currently down. This to me is an > egregious violation of the ARP standards. > [[[Sasha]]] First of all, ARP in LAG does not run over a specific link - it= runs over LAG and resolves the peer LAG IP address to the peer LAG MAC addr= ess. This means that running IP over LAG without LACP over a bunch of links that= do not report Layer 1 faults (and hence remain permanently UP) is problemat= ic: If your Distributor selects a de-facto faulty link to send your ARP, it will= never be resolved, and unicast IP will never come up. However, with LACP this will not happen, because faulty links will be eventu= ally excluded from distribution. At the same time, if LACP is used with LAG,= the peer LAG MAC address is also known (LACP carries it across). To me this= means that the only possible benefit of using some special MAC address in m= icro-BFD is LAG without LACP and without Layer 1 failure detection in the me= mber links. Do we really want to remedy this? How often would such a scenari= o be deployed taking into account that without micro-BFD there is running ch= ance of never bringing up IP forwarding across LAG with some healthy links? [Manav] I believe a solution gets automatically rejected if we come across e= ven one scenario where it doesnt work. [[[Sasha]]] But we've already agreed that behavior of micro-BFD sessions in= the presence of LACP and without LACP differs. Or didn't we? Regular ARP as you yourself noted can fail in the absence of LACP. I think w= e want a solution that works both in the presence and the absence of LACP. [[[Sasha]]] Please see above. The solution that works with LACP is already d= ifferent from one that works without LACP. So one more point of difference d= oes not weight so much (in my eyes). And IMHO and FWIW, changing the destina= tion MAC address depending on the micro-BFD session state hardly helps with= the objective to reuse existing code and HW. BTW, what really prevents you from using broadcast Destination MAC in the en= capsulation? Do you think that LAG members can pass thru a L2 switch on the= way? Would not that screw the entire LAG operation (e.g., that a broadcast= service frame is always sent via one link and received from one link)? Cheers, Manav 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. --_000_A3C5DF08D38B6049839A6F553B331C760116340CE734ILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hi Manav,

Lots of thanks for a prompt response.

 

Some responses inlin= e (bold purple).

 

Regards,

     Sasha

 =

From: Bhatia, Manav (Ma= nav) [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Thursday, Feb= ruary 02, 2012 6:13 PM
To: Alexander Vainshtein
Cc: rtg-= bfd@ietf.org
Subject: RE: Updated BFD over LAGs draft <= /span>

 

Hi Sasha,

 

> adjacency to com= e up, while the IP traffic learnt over the ISIS session to get

> dropped. This however has not detered people f= rom using IS-IS.

>

<= p class=3DMsoPlainText>[[[Sasha]]] I fully= agree regarding similarity between IS-IS and micro-BFD sessions and popular= ity of IS-IS. However, to me it cuts both ways:

If IS-IS not using IP encapsulation did not deter people= from using it for creating intra-AS IP connectivity, I do not see why micro= -BFD without IP encapsulation should be treated differently... but this is a= ctually a side issue. 

 

[Manav]  This is as you say is a side issu= e. By using IP encapsulation we leverage the existing code and the chip capa= bilities to a large extent. The extent of leverage one gets is implementatio= n and platform dependent.

 

The reason i had brought up IS-IS= was to counter your point about micro BFD sessions not relaying the true he= alth of the member links for IP traffic.

 =

 =

[[[Sasha]]] We all seem to agree that this is a side issue, so let’= s stop here.

 

>

<= strong>...= snipped by Sasha ...  

> > 3. = In Section 2.2. I've found a couple of statements that imply availability o= f the information about the physical

&= gt; > ingress port of an IP packet to   the appropriate "h= andling" entity.  This looks to me like a strong requirement becau= se (and this has been

> > discus= sed on the list) some existing  implementations do not provide this inf= ormation

>

> I think this information is trivially available in all= implementations. If not,

> then ho= w do such implementations handle IS-IS?

>

[[[Sasha]]] If you run IS-IS over LAG, you only need to know which LAG it= s packets have been received from.

If you run it over a single physica= l link, you need the information regarding the physical ingress port. <= /o:p>

But I do not see why IS-IS would be= interested in the physical ingress port in a LAG. 

 

[Manav] If an implementation can pass the information about the physica= l ingress port in one scenario then why cant it pass the same informati= on in case of a LAG? Isnt this an implementation specific issue that we're d= ealing with here. I would like to know which commercial implementation that= wants to run micro BFD sessions will not be capable of passing such in= formation that enables the SW to learn about the ingress port the packet arr= ived on?

 

= [[[Sasha]]] One suspicious use case could b= e the regular Linux IP stack with its socket interface. And, by your logic b= elow, if there is one case when it does not work, this is enough to bring th= e entire construction down, right?

To make it absolutely clear, I onl= y wanted to explicitly state the requirement on the LAG behavior if it is no= t part of an appropriate standard.

 

 

> We cannot use LAG MAC address as the= dest MAC since this requires

> res= olving ARP before the micro sessions are set up. This means that ARP

> resolution must work on links that are c= urrently down. This to me is an

> e= gregious violation of the ARP standards.

> 

[[[Sasha]]] First of all, ARP in LAG does not run over a specific l= ink – it runs over LAG and resolves the peer LAG IP address to the pee= r LAG MAC address.

This means that running IP over LAG without LACP ov= er a bunch of links that do not report Layer 1 faults (and hence remain perm= anently UP) is problematic:

If your Distributor selects a de-facto fau= lty link to send your ARP, it will never be resolved, and unicast IP will ne= ver come up.

However, with LA= CP this will not happen, because faulty links will be eventually excluded fr= om distribution. At the same time, if LACP is used with LAG, the peer LAG MA= C address is also known (LACP carries it across). To me this means that the= only possible benefit of using some special MAC address in micro-BFD is LAG= without LACP and without Layer 1 failure detection in the member links. Do= we really want to remedy this? How often would such a scenario be deployed= taking into account that without micro-BFD there is running chance of never= bringing up IP forwarding across LAG with some healthy links? 

 

=

[Manav] I believe a solution= gets automatically rejected if we come across even one scenario where it do= esnt work.

[[[Sasha]]] But we’ve already agreed that behavior of micro-BFD= sessions in the presence of LACP and without LACP differs.  Or didn= 217;t we?

 

Regular ARP as you yourself noted can= fail in the absence of LACP. I think we want a solution that works both in= the presence and the absence of LACP.

[[[Sasha]]] Please see abov= e. The solution that works with LACP is already different from one that work= s without LACP. So one more point of difference does not weight so much (in= my eyes). And IMHO and FWIW, changing the destination MAC address depending= on the micro-BFD session state hardly helps with the objective to reuse exi= sting code and HW.

BTW, what really prevents you from using broadcast= Destination MAC in the encapsulation? Do you think that LAG members can pas= s thru a L2 switch on the way? Would not that screw the entire LAG operation= (e.g., that a broadcast service frame is always sent via one link and recei= ved from one link)?

 

 

 =

 

Cheers= , Manav

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.

--_000_A3C5DF08D38B6049839A6F553B331C760116340CE734ILPTMAIL02e_-- From nitinb@juniper.net Thu Feb 2 11:13:14 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 2FA0021F84EF for ; Thu, 2 Feb 2012 11:13:14 -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 KBrHx3AJ8rfR for ; Thu, 2 Feb 2012 11:13:13 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 5565C21F862B for ; Thu, 2 Feb 2012 11:13:13 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTyrgRjMvcgcZSQHeHKzM97tzZvokygBd@postini.com; Thu, 02 Feb 2012 11:13:13 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 2 Feb 2012 11:12:32 -0800 From: Nitin Bahadur To: Glen Kent , Jeffrey Haas Date: Thu, 2 Feb 2012 11:12:29 -0800 Subject: Re: Charter work for BFD over LAGs Thread-Topic: Charter work for BFD over LAGs Thread-Index: AczhVfmtB0F2J4ShS5ulj5NjHoc9ogAiKGJK Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-bfd-chairs@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 19:13:14 -0000 Looks good. On 2/1/12 6:53 PM, "Glen Kent" wrote: Looks good to me. Do you think we will be able to send it to IESG by the end of this year? We dont even have a WG document yet? Glen On Thu, Feb 2, 2012 at 8:14 AM, Jeffrey Haas wrote: > Working Group, > > In the great tradition of many IETF working groups, while we've had great > discussion over the topic of BFD over LAGs, it's not formally on our > charter. To correct this, we need to request our charter be amended to > cover this work. I propose the following text: > > http://datatracker.ietf.org/wg/bfd/charter/ > > 7. Provide one or more mechanisms to run BFD over Link Aggregation Group > Interfaces. > > I would also propose a milestone to complete this work and send it to the > IESG by December 2012. > (And they'll respond that we need to update the dates on our other > milestones, but that's a different discussion.) > > Please send feedback to the mailing list suggesting changes or additions = to > the charter item or the milestone date. > > -- Jeff From aldrin.ietf@gmail.com Thu Feb 2 11:33:47 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 3CF7F21F84DE for ; Thu, 2 Feb 2012 11:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.992 X-Spam-Level: X-Spam-Status: No, score=-2.992 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, 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 V3rLMlHJE+2k for ; Thu, 2 Feb 2012 11:33:46 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B534B21F84D5 for ; Thu, 2 Feb 2012 11:33:46 -0800 (PST) Received: by pbdy7 with SMTP id y7so2709742pbd.31 for ; Thu, 02 Feb 2012 11:33:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=Zyc+xJUCmFPmTjYrwgG3e2WwTRUdLybsaoqxwBcE9dM=; b=G0nWzRApP4wJ5BHsXuL6fnDg1HPqmeY2C4rgYKETiq7xkM4ogFSIuyJ1OgfeXZs1/P BH4WZz05zdKCETtPnDg8ucj5DrlhNChc0Coi6ryklBSwGz9C+OfKt9P7QMTjPUaqZZNK hgHBLmJPWDrkO1jbY5tNxKxgLk/8oJYMKVAi4= Received: by 10.68.73.6 with SMTP id h6mr9967614pbv.116.1328211226511; Thu, 02 Feb 2012 11:33:46 -0800 (PST) Received: from [192.168.255.62] ([12.207.18.42]) by mx.google.com with ESMTPS id a5sm7583336pbh.15.2012.02.02.11.33.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Feb 2012 11:33:45 -0800 (PST) References: <20120202024402.GH30217@slice> In-Reply-To: <20120202024402.GH30217@slice> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <77A93564-CAB0-4CFE-A850-224E04052E71@gmail.com> X-Mailer: iPad Mail (9A405) From: Sam Aldrin Subject: Re: Charter work for BFD over LAGs Date: Thu, 2 Feb 2012 11:33:44 -0800 To: Jeffrey Haas Cc: "rtg-bfd-chairs@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 19:33:47 -0000 Looks good. Support. -sam Sent from my iPad On Feb 1, 2012, at 6:44 PM, Jeffrey Haas wrote: > Working Group, > > In the great tradition of many IETF working groups, while we've had great > discussion over the topic of BFD over LAGs, it's not formally on our > charter. To correct this, we need to request our charter be amended to > cover this work. I propose the following text: > > http://datatracker.ietf.org/wg/bfd/charter/ > > 7. Provide one or more mechanisms to run BFD over Link Aggregation Group > Interfaces. > > I would also propose a milestone to complete this work and send it to the > IESG by December 2012. > (And they'll respond that we need to update the dates on our other > milestones, but that's a different discussion.) > > Please send feedback to the mailing list suggesting changes or additions to > the charter item or the milestone date. > > -- Jeff From swallow@cisco.com Thu Feb 2 15:11:14 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 CE0C621F8627 for ; Thu, 2 Feb 2012 15:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 LghRu4lSKNPP for ; Thu, 2 Feb 2012 15:11:13 -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 98E9E21F8677 for ; Thu, 2 Feb 2012 15:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=1580; q=dns/txt; s=iport; t=1328224272; x=1329433872; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=exg+K+P2i0mLDJ+sSaHdaQo/o32gDfzKiFMMGqE+j/E=; b=Tos8WxYCfa3cUKDxIR8LFZP9x9ujhQudRqKSoaMVHQdIL63Gebb0SuJw F0dx+D5HbC6GH04YZN/ruWmtKlsmbvC49vr0lg/lKJNAOAzMNawBs8y1y 77LybW1qRq+tQDD1bhyz6Y55y5SqCLc8Czn7rC8ObsWSjp1tfQf5CbrgE Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMoWK0+tJXHA/2dsb2JhbABDrxKBBYFyAQEBAwESAScCATELBQ0BCBEEAQF+CAEBBAENBSKHWgmZMAGeW4tACAIBBgEpEwEIBQMDCQcBBwcCB4QmDwyDPQSIQoxhknM X-IronPort-AV: E=Sophos;i="4.73,349,1325462400"; d="scan'208";a="55949314" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 02 Feb 2012 23:11:12 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q12NBCYH001406; Thu, 2 Feb 2012 23:11:12 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Feb 2012 17:11:11 -0600 Received: from 10.98.32.163 ([10.98.32.163]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Feb 2012 23:11:11 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 02 Feb 2012 18:11:11 -0500 Subject: Re: Charter work for BFD over LAGs From: George Swallow To: Alexander Vainshtein , Jeffrey Haas , "rtg-bfd@ietf.org" Message-ID: Thread-Topic: Charter work for BFD over LAGs Thread-Index: AczhVFu/kxqVsVdkSQGAbaP9+7SCggAHTJ9xACOZZGw= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Feb 2012 23:11:11.0825 (UTC) FILETIME=[F4493410:01CCE1FF] Cc: "rtg-bfd-chairs@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, 02 Feb 2012 23:11:14 -0000 +1 ...George On 2/2/12 1:10 AM, "Alexander Vainshtein" wrote: > Yes/support. > > Regards, > Sasha > > ________________________________________ > From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey > Haas [jhaas@pfrc.org] > Sent: Thursday, February 02, 2012 4:44 AM > To: rtg-bfd@ietf.org > Cc: rtg-bfd-chairs@ietf.org > Subject: Charter work for BFD over LAGs > > Working Group, > > In the great tradition of many IETF working groups, while we've had great > discussion over the topic of BFD over LAGs, it's not formally on our > charter. To correct this, we need to request our charter be amended to > cover this work. I propose the following text: > > http://datatracker.ietf.org/wg/bfd/charter/ > > 7. Provide one or more mechanisms to run BFD over Link Aggregation Group > Interfaces. > > I would also propose a milestone to complete this work and send it to the > IESG by December 2012. > (And they'll respond that we need to update the dates on our other > milestones, but that's a different discussion.) > > Please send feedback to the mailing list suggesting changes or additions to > the charter item or the milestone date. > > -- Jeff > > 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. > From shtsuchi@cisco.com Thu Feb 2 16:16:33 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 3740921F85FF for ; Thu, 2 Feb 2012 16:16:33 -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 tAn2g52e+NI5 for ; Thu, 2 Feb 2012 16:16:32 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 13C3621F8609 for ; Thu, 2 Feb 2012 16:16:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=1154; q=dns/txt; s=iport; t=1328228192; x=1329437792; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=YqPn6sUHex6VFfHeQVfNtNtj1J9SnueMf3aHR+aI4P0=; b=eU4InaA+qwjH10FrZq2pV12k55wZI8i/NEjuXHDhjAlzLmwBQV6QdyB1 USuZ3qonQpXiZpIIFT8UiwaFrdg1/o0eUrWE36u+DLtfuZGUAK3vVuwJg fep95FCYz6P9jc3jW7QDs4x2g6IdY5fUGt7w/JKuMuwtcUikup8m6POgt k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoGAMkmK09Io8UY/2dsb2JhbABDgw2BfqsMgXIBAQECAhIBDgFMCgEQCxgBAwUWCgMCCQMCAQIBRRMBBwEBBRmHY5kvAYxgAZIAgSyKJQEEAgECAgkCAgENBAYBCwEIBQMDCR+CchkEAwwDFAVXFg4MIYIDgRkEiECMY4VXjQ0 X-IronPort-AV: E=Sophos;i="4.73,349,1325462400"; d="scan'208";a="4699579" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 03 Feb 2012 00:16:30 +0000 Received: from [10.70.230.69] (tky-vpn-client-230-69.cisco.com [10.70.230.69]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q130GSxP015625; Fri, 3 Feb 2012 00:16:29 GMT Message-ID: <4F2B275C.8060403@cisco.com> Date: Fri, 03 Feb 2012 09:16:28 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: jhaas@pfrc.org Subject: Re: Charter work for BFD over LAGs References: <20120202024402.GH30217@slice> In-Reply-To: <20120202024402.GH30217@slice> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: rtg-bfd-chairs@ietf.org, rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 00:16:33 -0000 Support! LAG operation and trouble shooting issue often are discussing within operators. This is NTT communication cases. http://www.nanog.org/meetings/nanog52/presentations/Monday/tomochika-20110613_NANOG52_OCN.pdf We should provide standard mechanisms for BFD over LAG. Regards, -Shishio (2012/02/02 11:44), Jeffrey Haas wrote: > Working Group, > > In the great tradition of many IETF working groups, while we've had great > discussion over the topic of BFD over LAGs, it's not formally on our > charter. To correct this, we need to request our charter be amended to > cover this work. I propose the following text: > > http://datatracker.ietf.org/wg/bfd/charter/ > > 7. Provide one or more mechanisms to run BFD over Link Aggregation Group > Interfaces. > > I would also propose a milestone to complete this work and send it to the > IESG by December 2012. > (And they'll respond that we need to update the dates on our other > milestones, but that's a different discussion.) > > Please send feedback to the mailing list suggesting changes or additions to > the charter item or the milestone date. > > -- Jeff > From mach.chen@huawei.com Thu Feb 2 16:32: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 A428021F84EA for ; Thu, 2 Feb 2012 16:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 kzgh3QRnaxWJ for ; Thu, 2 Feb 2012 16:32:18 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id CDD7D21F869D for ; Thu, 2 Feb 2012 16:32:07 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYS00L40K596O@szxga03-in.huawei.com>; Fri, 03 Feb 2012 08:31:57 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYS00FK0K59VM@szxga03-in.huawei.com>; Fri, 03 Feb 2012 08:31:57 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGU03321; Fri, 03 Feb 2012 08:31:56 +0800 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 03 Feb 2012 08:31:24 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.206]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Fri, 03 Feb 2012 08:32:39 +0800 Date: Fri, 03 Feb 2012 00:31:47 +0000 From: Mach Chen Subject: RE: Charter work for BFD over LAGs In-reply-to: <20120202024402.GH30217@slice> X-Originating-IP: [10.108.4.51] To: Jeffrey Haas , "rtg-bfd@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Charter work for BFD over LAGs Thread-index: AQHM4VSuYSWgQPtOKEepeDpjqruSzpYqU60Q X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20120202024402.GH30217@slice> Cc: "rtg-bfd-chairs@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, 03 Feb 2012 00:32:25 -0000 Yes/Support. Best regards, Mach > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > Jeffrey Haas > Sent: Thursday, February 02, 2012 10:44 AM > To: rtg-bfd@ietf.org > Cc: rtg-bfd-chairs@ietf.org > Subject: Charter work for BFD over LAGs > > Working Group, > > In the great tradition of many IETF working groups, while we've had great > discussion over the topic of BFD over LAGs, it's not formally on our > charter. To correct this, we need to request our charter be amended to > cover this work. I propose the following text: > > http://datatracker.ietf.org/wg/bfd/charter/ > > 7. Provide one or more mechanisms to run BFD over Link Aggregation Group > Interfaces. > > I would also propose a milestone to complete this work and send it to the > IESG by December 2012. > (And they'll respond that we need to update the dates on our other > milestones, but that's a different discussion.) > > Please send feedback to the mailing list suggesting changes or additions to > the charter item or the milestone date. > > -- Jeff From davari@broadcom.com Thu Feb 2 16:33:34 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 6D55B21F8697 for ; Thu, 2 Feb 2012 16:33:34 -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.336, 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 gTp2fvLEhs3p for ; Thu, 2 Feb 2012 16:33:33 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 386A111E8071 for ; Thu, 2 Feb 2012 16:33:32 -0800 (PST) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 02 Feb 2012 16:42:22 -0800 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.131]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 2 Feb 2012 16:33:25 -0800 From: "Shahram Davari" To: "Jeffrey Haas" , "rtg-bfd@ietf.org" Date: Thu, 2 Feb 2012 16:33:21 -0800 Subject: RE: Charter work for BFD over LAGs Thread-Topic: Charter work for BFD over LAGs Thread-Index: AQHM4VSuYSWgQPtOKEepeDpjqruSzpYqU60QgAAAaNA= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6BBDA6154F8@SJEXCHCCR02.corp.ad.broadcom.com> References: <20120202024402.GH30217@slice> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6335F2E43GG24837386-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd-chairs@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, 03 Feb 2012 00:33:34 -0000 Support., Shahram > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of > Jeffrey Haas > Sent: Thursday, February 02, 2012 10:44 AM > To: rtg-bfd@ietf.org > Cc: rtg-bfd-chairs@ietf.org > Subject: Charter work for BFD over LAGs >=20 > Working Group, >=20 > In the great tradition of many IETF working groups, while we've had great > discussion over the topic of BFD over LAGs, it's not formally on our > charter. To correct this, we need to request our charter be amended to > cover this work. I propose the following text: >=20 > http://datatracker.ietf.org/wg/bfd/charter/ >=20 > 7. Provide one or more mechanisms to run BFD over Link Aggregation Group > Interfaces. >=20 > I would also propose a milestone to complete this work and send it to the > IESG by December 2012. > (And they'll respond that we need to update the dates on our other > milestones, but that's a different discussion.) >=20 > Please send feedback to the mailing list suggesting changes or additions = to > the charter item or the milestone date. >=20 > -- Jeff From Tina.Tsou.Zouting@huawei.com Thu Feb 2 20:13:02 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 A78D021F85D6 for ; Thu, 2 Feb 2012 20:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 ZmA1jQBjlVEM for ; Thu, 2 Feb 2012 20:13:02 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id DA00821F8581 for ; Thu, 2 Feb 2012 20:13:01 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYS00AURUDM39@szxga04-in.huawei.com>; Fri, 03 Feb 2012 12:12:58 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYS00160UDM1J@szxga04-in.huawei.com>; Fri, 03 Feb 2012 12:12:58 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGU25857; Fri, 03 Feb 2012 12:12:46 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 03 Feb 2012 12:11:43 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Fri, 03 Feb 2012 12:11:55 +0800 Date: Fri, 03 Feb 2012 04:11:54 +0000 From: Tina TSOU Subject: Re: Charter work for BFD over LAGs In-reply-to: To: Mach Chen Message-id: <5834E9AC-3DB1-42D7-8BC1-2B27F90BF310@huawei.com> Content-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Charter work for BFD over LAGs Thread-index: AQHM4VSQoYnTu6kN5UmFX3J/EvfnRpYpzaeAgAAu+wA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20120202024402.GH30217@slice> Cc: "rtg-bfd-chairs@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 04:13:02 -0000 Support. Sent from my iPad On Feb 2, 2012, at 5:00 PM, "Mach Chen" wrote: > Yes/Support. > > Best regards, > Mach > >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of >> Jeffrey Haas >> Sent: Thursday, February 02, 2012 10:44 AM >> To: rtg-bfd@ietf.org >> Cc: rtg-bfd-chairs@ietf.org >> Subject: Charter work for BFD over LAGs >> >> Working Group, >> >> In the great tradition of many IETF working groups, while we've had great >> discussion over the topic of BFD over LAGs, it's not formally on our >> charter. To correct this, we need to request our charter be amended to >> cover this work. I propose the following text: >> >> http://datatracker.ietf.org/wg/bfd/charter/ >> >> 7. Provide one or more mechanisms to run BFD over Link Aggregation Group >> Interfaces. >> >> I would also propose a milestone to complete this work and send it to the >> IESG by December 2012. >> (And they'll respond that we need to update the dates on our other >> milestones, but that's a different discussion.) >> >> Please send feedback to the mailing list suggesting changes or additions to >> the charter item or the milestone date. >> >> -- Jeff From cpignata@cisco.com Thu Feb 2 21:16:05 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29B521F865D for ; Thu, 2 Feb 2012 21:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 gTDR7u1zuS1E for ; Thu, 2 Feb 2012 21:16:05 -0800 (PST) Received: from av-tac-sj.cisco.com (firebird.cisco.com [171.68.227.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6744221F859E for ; Thu, 2 Feb 2012 21:16:05 -0800 (PST) X-TACSUNS: Virus Scanned Received: from bonfire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q135G4Gq005117 for ; Thu, 2 Feb 2012 21:16:04 -0800 (PST) Received: from [10.117.115.50] (rtp-cpignata-8911.cisco.com [10.117.115.50]) by bonfire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q135FrxW029434; Thu, 2 Feb 2012 21:16:01 -0800 (PST) Message-ID: <4F2B6D89.5000405@cisco.com> Date: Fri, 03 Feb 2012 00:15:53 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Jeffrey Haas Subject: Re: Charter work for BFD over LAGs References: <20120202024402.GH30217@slice> In-Reply-To: <20120202024402.GH30217@slice> X-Enigmail-Version: 1.3.5 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rtg-bfd-chairs@ietf.org, rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 05:16:06 -0000 Support. On 2/1/2012 9:44 PM, Jeffrey Haas wrote: > Working Group, > > In the great tradition of many IETF working groups, while we've had great > discussion over the topic of BFD over LAGs, it's not formally on our > charter. To correct this, we need to request our charter be amended to > cover this work. I propose the following text: > > http://datatracker.ietf.org/wg/bfd/charter/ > > 7. Provide one or more mechanisms to run BFD over Link Aggregation Group > Interfaces. > > I would also propose a milestone to complete this work and send it to the > IESG by December 2012. > (And they'll respond that we need to update the dates on our other > milestones, but that's a different discussion.) > > Please send feedback to the mailing list suggesting changes or additions to > the charter item or the milestone date. > > -- Jeff > > Thanks, -- Carlos. From binnyjeshan@gmail.com Thu Feb 2 22:55:37 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC90A21F856C for ; Thu, 2 Feb 2012 22:55:37 -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 6vAIMB7C6JaT for ; Thu, 2 Feb 2012 22:55:37 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 427F621F852B for ; Thu, 2 Feb 2012 22:55:37 -0800 (PST) Received: by pbdy7 with SMTP id y7so3166245pbd.31 for ; Thu, 02 Feb 2012 22:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SJC4O0ZFyQmtS/Dlwi4/5gygDyYPo7yXFCv43kd5TDc=; b=lnDeHaZF8/Vh+Bn5ZGjyBEezr8KMXMdEoqFQdv3cjY7nFUX58NSv5KvggC7DxKK/Rj CwhCn4vg4sCjRGQrTqYeD9YXhgJV9nxXZASms6qOY7/EbL7dJL/dNloAYC5vS790KgHf lKtgg8+2uEuBGU/JkJBjoMU9p4wVnu9nwM0/U= MIME-Version: 1.0 Received: by 10.68.190.4 with SMTP id gm4mr14928056pbc.95.1328252136984; Thu, 02 Feb 2012 22:55:36 -0800 (PST) Received: by 10.143.168.20 with HTTP; Thu, 2 Feb 2012 22:55:36 -0800 (PST) In-Reply-To: <4F2B6D89.5000405@cisco.com> References: <20120202024402.GH30217@slice> <4F2B6D89.5000405@cisco.com> Date: Fri, 3 Feb 2012 12:25:36 +0530 Message-ID: Subject: Re: Charter work for BFD over LAGs From: binny jeshan To: Carlos Pignataro Content-Type: multipart/alternative; boundary=e89a8ff1cc16cc11ae04b809cc33 Cc: rtg-bfd-chairs@ietf.org, rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 06:55:38 -0000 --e89a8ff1cc16cc11ae04b809cc33 Content-Type: text/plain; charset=ISO-8859-1 +1 Support ! _Binny J On 3 February 2012 10:45, Carlos Pignataro wrote: > Support. > > On 2/1/2012 9:44 PM, Jeffrey Haas wrote: > > Working Group, > > > > In the great tradition of many IETF working groups, while we've had great > > discussion over the topic of BFD over LAGs, it's not formally on our > > charter. To correct this, we need to request our charter be amended to > > cover this work. I propose the following text: > > > > http://datatracker.ietf.org/wg/bfd/charter/ > > > > 7. Provide one or more mechanisms to run BFD over Link Aggregation Group > > Interfaces. > > > > I would also propose a milestone to complete this work and send it to the > > IESG by December 2012. > > (And they'll respond that we need to update the dates on our other > > milestones, but that's a different discussion.) > > > > Please send feedback to the mailing list suggesting changes or additions > to > > the charter item or the milestone date. > > > > -- Jeff > > > > > > Thanks, > > -- Carlos. > --e89a8ff1cc16cc11ae04b809cc33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 Support !

_Binny J

= On 3 February 2012 10:45, Carlos Pignataro <cpignata@cisco.com> wrote:
Support.

On 2/1/2012 9:44 PM, Jeffrey Haas wrote:
> Working Group,
>
> In the great tradition of many IETF working groups, while we've ha= d great
> discussion over the topic of BFD over LAGs, it's not formally on o= ur
> charter. =A0To correct this, we need to request our charter be amended= to
> cover this work. =A0I propose the following text:
>
> http://datatracker.ietf.org/wg/bfd/charter/
>
> 7. Provide one or more mechanisms to run BFD over Link Aggregation Gro= up
> Interfaces.
>
> I would also propose a milestone to complete this work and send it to = the
> IESG by December 2012.
> (And they'll respond that we need to update the dates on our other=
> milestones, but that's a different discussion.)
>
> Please send feedback to the mailing list suggesting changes or additio= ns to
> the charter item or the milestone date.
>
> -- Jeff
>
>

Thanks,

-- Carlos.

--e89a8ff1cc16cc11ae04b809cc33-- From linda.dunbar@huawei.com Thu Feb 2 09:36:12 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 5C01D21F8631 for ; Thu, 2 Feb 2012 09:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 EH52t6pGv0ln for ; Thu, 2 Feb 2012 09:36:11 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C327921F8628 for ; Thu, 2 Feb 2012 09:36:11 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id ADE54994; Thu, 02 Feb 2012 12:36:11 -0500 (EST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Feb 2012 09:34:36 -0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Thu, 2 Feb 2012 09:34:25 -0800 From: Linda Dunbar To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Charter work for BFD over LAGs Thread-Topic: Charter work for BFD over LAGs Thread-Index: AQHM4VSSSKdtTNNCNk2Jh1zYqVElxpYp3xww Date: Thu, 2 Feb 2012 17:34:24 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F632E1A078@dfweml505-mbx> References: <20120202024402.GH30217@slice> In-Reply-To: <20120202024402.GH30217@slice> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.97] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Fri, 03 Feb 2012 10:26:43 -0800 Cc: "rtg-bfd-chairs@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, 02 Feb 2012 17:36:12 -0000 Support.=20 Linda Dunbar > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Jeffrey Haas > Sent: Wednesday, February 01, 2012 8:44 PM > To: rtg-bfd@ietf.org > Cc: rtg-bfd-chairs@ietf.org > Subject: Charter work for BFD over LAGs >=20 > Working Group, >=20 > In the great tradition of many IETF working groups, while we've had > great > discussion over the topic of BFD over LAGs, it's not formally on our > charter. To correct this, we need to request our charter be amended to > cover this work. I propose the following text: >=20 > http://datatracker.ietf.org/wg/bfd/charter/ >=20 > 7. Provide one or more mechanisms to run BFD over Link Aggregation > Group > Interfaces. >=20 > I would also propose a milestone to complete this work and send it to > the > IESG by December 2012. > (And they'll respond that we need to update the dates on our other > milestones, but that's a different discussion.) >=20 > Please send feedback to the mailing list suggesting changes or > additions to > the charter item or the milestone date. >=20 > -- Jeff From ginsberg@cisco.com Sun Feb 5 22:51: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 3577121F8598 for ; Sun, 5 Feb 2012 22:51:32 -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 4C8Se01P5m7F for ; Sun, 5 Feb 2012 22:51:26 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D9FCD21F852B for ; Sun, 5 Feb 2012 22:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ginsberg@cisco.com; l=1070; q=dns/txt; s=iport; t=1328511086; x=1329720686; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=iCprbNMhQr/e17V7hrTqOvLLrFXXqfYLtcXhX5/VJg0=; b=O8VXBa9FoYXFF+AnP2U1stUA/m0OW5MS1NxNhXliaUmFbmMyM9LdbUrS rQMLce98U3AC1gkCVw/Yf67Q+2eM39dM18jlP0iDpuLjHc8AY6DtkI1OA /WI5FZxL6hGq46f1pO8wD37I23Dp+9Jcmh4gfpKCHCFbt7IW678/C11HW Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPZ3L0+rRDoJ/2dsb2JhbABDrzeBBYFyAQEBAwESAR0KPxACAQgiBhgGAVYBAQQBGhqHWpppAZ4Wi2MrMQIBAQQCAwIDAQuDEwUDEnkNgmhjBIhEn2A X-IronPort-AV: E=Sophos;i="4.73,368,1325462400"; d="scan'208";a="28838002" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 06 Feb 2012 06:51:26 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q166pQim010442; Mon, 6 Feb 2012 06:51:26 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 5 Feb 2012 22:51:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Updated BFD over LAGs draft Date: Sun, 5 Feb 2012 22:51:24 -0800 Message-ID: In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02AB3B53@INBANSXCHMBSA1.in.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated BFD over LAGs draft Thread-Index: AczhORMqBZ3WwFzvQCKQQGxCZTkSpgAMd6Y4ABToIDAAtvP2YA== References: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com>, <6BA87B92-7DD2-4F69-A574-B14D7FB50089@sniff.de> <7C362EEF9C7896468B36C9B79200D8350D02AB3B53@INBANSXCHMBSA1.in.alcatel-lucent.com> From: "Les Ginsberg (ginsberg)" To: "Bhatia, Manav (Manav)" , "Alexander Vainshtein" , "Marc Binderberger" X-OriginalArrivalTime: 06 Feb 2012 06:51:26.0528 (UTC) FILETIME=[BF2BBC00:01CCE49B] 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, 06 Feb 2012 06:51:32 -0000 >=20 > IS-IS has similar properties as the micro BFD sessions that we're > describing. Theoretically its possible in some buggy implementations > for IS-IS adjacency to come up, while the IP traffic learnt over the > ISIS session to get dropped. This however has not detered people from > using IS-IS. >=20 Not to divert the main discussion, but simply to clarify this point - describing the issues associated with a lack of fate sharing between a BFD session and the peer session between the BFD clients as a "buggy [client] implementation" isn't accurate - or fair to the implementation owners. Using IS-IS as an example, the base protocol specifies an adjacency state machine which does not depend on BFD session state. In order to address the fate sharing issue, the protocol adjacency state machinery needs to be revised to incorporate BFD session state appropriately. This has interoperability implications and therefore requires a change in the specification. In the case of IS-IS RFC 6213 defines the necessary protocol extensions. Les From nobo@cisco.com Mon Feb 6 00:36: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 A326D21F85C9 for ; Mon, 6 Feb 2012 00:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 2OoxW+MQhwdN for ; Mon, 6 Feb 2012 00:36:08 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3671821F8545 for ; Mon, 6 Feb 2012 00:36:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nobo@cisco.com; l=1145; q=dns/txt; s=iport; t=1328517368; x=1329726968; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=I443vbfbLhoiMymTao1jtGCF/k0OxWS2HXVCeON8fwQ=; b=C/TaRlMfGzLhpUANR8/LPZdmRKzouEtBSmLHh6ZyErAI/VOBX5k8e/5g LBxVESbTJ2YW7BydjOKmsmxT/kp+Yw1nbnjve360uu3lFJ2s5+MCb4kXx jXt4uVqIcSuBrInaWKwMKL2+vdKPcJQA+1Z1Pj5SKXLVx3bzGhfYKTCPh E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAK+QL0+rRDoH/2dsb2JhbABDrzmBBYFyAQEBBBIBHQo0CwwEAgEIDgMEAQELBhcBBgFFCQgBAQQBEggah2OaUQGeMItjKzMBAQQCBQMMgxMFAxJ5DwyCWmMEiESfYA X-IronPort-AV: E=Sophos;i="4.73,369,1325462400"; d="scan'208";a="28707255" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 06 Feb 2012 08:36:07 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q168a7D0015850; Mon, 6 Feb 2012 08:36:07 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Feb 2012 00:36:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Charter work for BFD over LAGs Date: Mon, 6 Feb 2012 00:36:06 -0800 Message-ID: In-Reply-To: <20120202024402.GH30217@slice> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Charter work for BFD over LAGs Thread-Index: AczhVInuU5FSpqIjRJue11OBlQPCmwDVcytQ References: <20120202024402.GH30217@slice> From: "Nobo Akiya (nobo)" To: "Jeffrey Haas" , X-OriginalArrivalTime: 06 Feb 2012 08:36:07.0560 (UTC) FILETIME=[5EF52880:01CCE4AA] Cc: rtg-bfd-chairs@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, 06 Feb 2012 08:36:08 -0000 Yes/support. Regards, Nobo > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Jeffrey Haas > Sent: Thursday, February 02, 2012 11:44 AM > To: rtg-bfd@ietf.org > Cc: rtg-bfd-chairs@ietf.org > Subject: Charter work for BFD over LAGs >=20 > Working Group, >=20 > In the great tradition of many IETF working groups, while we've had great > discussion over the topic of BFD over LAGs, it's not formally on our > charter. To correct this, we need to request our charter be amended to > cover this work. I propose the following text: >=20 > http://datatracker.ietf.org/wg/bfd/charter/ >=20 > 7. Provide one or more mechanisms to run BFD over Link Aggregation Group > Interfaces. >=20 > I would also propose a milestone to complete this work and send it to > the > IESG by December 2012. > (And they'll respond that we need to update the dates on our other > milestones, but that's a different discussion.) >=20 > Please send feedback to the mailing list suggesting changes or additions > to > the charter item or the milestone date. >=20 > -- Jeff From agmalis@gmail.com Mon Feb 6 03:00:19 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 9077721F8619 for ; Mon, 6 Feb 2012 03:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 VxeE1rg2k6+w for ; Mon, 6 Feb 2012 03:00:18 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92C2621F8611 for ; Mon, 6 Feb 2012 03:00:18 -0800 (PST) Received: by iagf6 with SMTP id f6so10040731iag.31 for ; Mon, 06 Feb 2012 03:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=uUw6RVgeZ/za+4bU+dS3hQ8V8X0HyRg8jN2QTrbzwbc=; b=aEBkokLzHD4PTkTErvHW9PVpzCgKS7xO5uQiLZM8oSkDhZsjYa/kg5UjFsKLSpAvlI cDZBbdNi5T3JYANowXAEDYP7fUI06skdCXENa5ar40mmM78Uy68vCBzeCKT/1SuDVcXc UjzKd9ONqv1YK7fy5UpxSmWDVu+pjPVbrRHBQ= Received: by 10.50.207.72 with SMTP id lu8mr20488684igc.0.1328526018293; Mon, 06 Feb 2012 03:00:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.36.136 with HTTP; Mon, 6 Feb 2012 02:59:58 -0800 (PST) In-Reply-To: <20120202030912.GJ30217@slice> References: <20120202024402.GH30217@slice> <20120202030912.GJ30217@slice> From: "Andrew G. Malis" Date: Mon, 6 Feb 2012 11:59:58 +0100 Message-ID: Subject: Re: Charter work for BFD over LAGs To: Jeffrey Haas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 06 Feb 2012 11:00:19 -0000 I support the work, feel the milestone is admirable but may end up being revised. Cheers, Andy On Thu, Feb 2, 2012 at 4:09 AM, Jeffrey Haas wrote: > On Thu, Feb 02, 2012 at 08:23:32AM +0530, Glen Kent wrote: >> Looks good to me. Do you think we will be able to send it to IESG by >> the end of this year? We dont even have a WG document yet? > > My suspicion is that draft-mmm-bfd-on-lags could be one of those mechanis= ms. > :-) > > This of course depends on WG consensus on adopting that draft. =A0We can = talk > about adoption of specific drafts once we have an updated charter. =A0It = may > also be reasonable to push the milestone date out to accommodate other > proposals. > > Other opinions on the milestone date vs. open work? > > -- Jeff From manav.bhatia@alcatel-lucent.com Mon Feb 6 10:59:27 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 5C48E21F85DB for ; Mon, 6 Feb 2012 10:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.747 X-Spam-Level: X-Spam-Status: No, score=-8.747 tagged_above=-999 required=5 tests=[AWL=1.852, 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 psJug0LDvi2Y for ; Mon, 6 Feb 2012 10:59:26 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id C773C21F85D4 for ; Mon, 6 Feb 2012 10:59:26 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q16IxIK1027946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Feb 2012 12:59:21 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q16IxC1D031841 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Feb 2012 00:29:12 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 7 Feb 2012 00:29:12 +0530 From: "Bhatia, Manav (Manav)" To: "Les Ginsberg (ginsberg)" , Alexander Vainshtein , Marc Binderberger Date: Tue, 7 Feb 2012 00:29:29 +0530 Subject: RE: Updated BFD over LAGs draft Thread-Topic: Updated BFD over LAGs draft Thread-Index: AczhORMqBZ3WwFzvQCKQQGxCZTkSpgAMd6Y4ABToIDAAtvP2YAAZruHw Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02AB4048@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D02AB37C1@INBANSXCHMBSA1.in.alcatel-lucent.com>, <6BA87B92-7DD2-4F69-A574-B14D7FB50089@sniff.de> <7C362EEF9C7896468B36C9B79200D8350D02AB3B53@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 18:59:27 -0000 Hi Les, When I cited ISIS I did not mean ISIS and BFD interaction - I had meant van= illa RFC 1195 ISIS and IP traffic. Cheers, Manav=20 > -----Original Message----- > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]=20 > Sent: Monday, February 06, 2012 12:21 PM > To: Bhatia, Manav (Manav); Alexander Vainshtein; Marc Binderberger > Cc: rtg-bfd@ietf.org > Subject: RE: Updated BFD over LAGs draft=20 >=20 > >=20 > > IS-IS has similar properties as the micro BFD sessions that we're=20 > > describing. Theoretically its possible in some buggy=20 > implementations=20 > > for IS-IS adjacency to come up, while the IP traffic learnt=20 > over the=20 > > ISIS session to get dropped. This however has not detered=20 > people from=20 > > using IS-IS. > >=20 >=20 > Not to divert the main discussion, but simply to clarify this=20 > point - describing the issues associated with a lack of fate=20 > sharing between a BFD session and the peer session between=20 > the BFD clients as a "buggy [client] implementation" isn't=20 > accurate - or fair to the implementation owners. Using IS-IS=20 > as an example, the base protocol specifies an adjacency state=20 > machine which does not depend on BFD session state. In order=20 > to address the fate sharing issue, the protocol adjacency=20 > state machinery needs to be revised to incorporate BFD=20 > session state appropriately. This has interoperability=20 > implications and therefore requires a change in the=20 > specification. In the case of IS-IS RFC 6213 defines the=20 > necessary protocol extensions. >=20 > Les >=20 >=20 >=20 > = From manav.bhatia@alcatel-lucent.com Wed Feb 8 20:05:27 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 6018921F8589 for ; Wed, 8 Feb 2012 20:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.783 X-Spam-Level: X-Spam-Status: No, score=-6.783 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 GOBgV4kmtDkW for ; Wed, 8 Feb 2012 20:05:26 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 909DB21F8585 for ; Wed, 8 Feb 2012 20:05:26 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q1945MYL008738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 8 Feb 2012 22:05:25 -0600 (CST) 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 q1945Lcl024619 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 9 Feb 2012 09:35:22 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 9 Feb 2012 09:35:21 +0530 From: "Bhatia, Manav (Manav)" To: "rtg-bfd@ietf.org" Date: Thu, 9 Feb 2012 09:35:38 +0530 Subject: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: Aczm4BTZKNK9QL1IRoSgcwePoSmyvg== Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02AB456F@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 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, 09 Feb 2012 04:05:27 -0000 Hi, There were some concerns about operational complexity that using unicast ad= dresses for micro BFD sessions would entail. We have written a short draft = that alleviates such concerns by suggesting few mechanisms that nodes can u= se to auto discover remote neighbor IP addresses before establishing micro = BFD sessions. Would be great if the WG can review and provide feedback on this draft. The URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.txt=20 Cheers, Manav -- From: internet-drafts@ietf.org=20 To: i-d-announce@ietf.org=20 Reply-to: internet-drafts@ietf.org=20 Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt=20 X-C5I-RSN: 1/0/935/41368/44754=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies.=20 =20 Title : IP Address Schemes for Bidirectional Forwarding Detection (BFD) on = Link Aggregation Group (LAG) Interfaces=20 Author(s) : Manav Bhatia=20 Marc Binderberger=20 Sami Boutros=20 Nobo Akiya=20 Filename : draft-mmsn-bfd-on-lags-address-00.txt=20 Pages : 5=20 Date : 2012-02-08=20 =20 This document describes techniques which can be used by a router to=20 obtain or discover remote neighbor IP address in order to establish=20 micro Bidirectional Forwarding Detection (BFD) sessions=20 [BFD-ON-LAGS].=20 =20 =20 =20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.txt=20 =20 Internet-Drafts are also available by anonymous FTP at:=20 ftp://ftp.ietf.org/internet-drafts/=20 =20 This Internet-Draft can be retrieved at:=20 ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.txt=20 =20 _______________________________________________=20 I-D-Announce mailing list=20 I-D-Announce@ietf.org=20 https://www.ietf.org/mailman/listinfo/i-d-announce=20 Internet-Draft directories: http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=20 = From nitinb@juniper.net Thu Feb 9 04:46: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 4167D21F8722 for ; Thu, 9 Feb 2012 04:46:00 -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 ASDdJ6SOLH8X for ; Thu, 9 Feb 2012 04:45:55 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 5412721F8715 for ; Thu, 9 Feb 2012 04:45:55 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTzPAAe1JjG9LD+/BppJiDwBYiy00rWM0@postini.com; Thu, 09 Feb 2012 04:45:55 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 9 Feb 2012 04:43:24 -0800 From: Nitin Bahadur To: "Bhatia, Manav (Manav)" , "rtg-bfd@ietf.org" Date: Thu, 9 Feb 2012 04:43:22 -0800 Subject: Re: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: Aczm4BTZKNK9QL1IRoSgcwePoSmyvgASFNfW Message-ID: In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02AB456F@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="iso-8859-1" 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: Thu, 09 Feb 2012 12:46:00 -0000 Hi Manav, The draft specifies multiple mechanisms and section 4.2 lists that all MU= ST be supported. This doesn't make sense from a vendor perspective IMO. If "all vendors" have to implement "all options",= then why not just have 1 option ! Having multiple options also leads to inter-op issue among vendors. We have= seen that story with multiple other protocols. Thanks Nitin On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" wrote: Hi, There were some concerns about operational complexity that using unicast ad= dresses for micro BFD sessions would entail. We have written a short draft = that alleviates such concerns by suggesting few mechanisms that nodes can u= se to auto discover remote neighbor IP addresses before establishing micro = BFD sessions. Would be great if the WG can review and provide feedback on this draft. The URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.txt Cheers, Manav -- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Reply-to: internet-drafts@ietf.org Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt X-C5I-RSN: 1/0/935/41368/44754 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : IP Address Schemes for Bidirectional Forwarding Detection (BFD) on = Link Aggregation Group (LAG) Interfaces Author(s) : Manav Bhatia Marc Binderberger Sami Boutros Nobo Akiya Filename : draft-mmsn-bfd-on-lags-address-00.txt Pages : 5 Date : 2012-02-08 This document describes techniques which can be used by a router to obtain or discover remote neighbor IP address in order to establish micro Bidirectional Forwarding Detection (BFD) sessions [BFD-ON-LAGS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From toms.sanders@gmail.com Thu Feb 9 08:06: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 BBCCC21E8021 for ; Thu, 9 Feb 2012 08:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 NL1jE7C8TeES for ; Thu, 9 Feb 2012 08:06:03 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDE221E801F for ; Thu, 9 Feb 2012 08:06:03 -0800 (PST) Received: by wibhm9 with SMTP id hm9so1768488wib.31 for ; Thu, 09 Feb 2012 08:06:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yYCyKBLMFriQYpTfwDAWD40dl9fwTMgAU7kkcXn/Qw4=; b=KokHEtRy8LY+S1HC0bMvbZRXOq6kamrPLSBslj9j0q7Q9VYPSsSOevszK7iiMKvB/B foV6ndWtI3l3s1oD8xVu7aLcgKfYPnfJ30t8hfs1O4vIxwhi1BuNs1YwrQnyLd9YNvU+ 0+T6EyCD/0si0ULjoqkdmyOs7FyxhioAXc3qc= MIME-Version: 1.0 Received: by 10.180.83.72 with SMTP id o8mr33493491wiy.22.1328803562756; Thu, 09 Feb 2012 08:06:02 -0800 (PST) Received: by 10.223.115.81 with HTTP; Thu, 9 Feb 2012 08:06:02 -0800 (PST) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350D02AB456F@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Thu, 9 Feb 2012 21:36:02 +0530 Message-ID: Subject: Re: IP Address Schemes for BFD on LAG interfaces From: Tom Sanders To: Nitin Bahadur Content-Type: text/plain; charset=UTF-8 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, 09 Feb 2012 16:06:04 -0000 Hi Nitin, I'll let the authors clarify but i think the clue lies is in the second statement of Sec 4 which says that ".. all described options can interoperate with each other, as long as following rules, described in this section, are honored." I believe the idea is to describe three possible ways to provide the unicast IP address that micro BFD sessions can potentially use - explicit configuration, multicast and unicast from 127/8 range. Vendors can pick one mechanism out of the three mentioned in the document. Ordinarily they will only interoperate if the other end also supports the same mechanism. However, If implementations follow the rules laid out in Sec 4, then they will always interoperate irrespective of the mechanism each end supports. I think this is in line with the IETF maxim - "Be conservative in what you give and liberal in what you recieve". So, while an implementation would always send out initial discovery packets using multicast, it will also accept 127/8 for micro BFD sessions. I could be completely off the mark in which case the authors can correct me. But this seemed to me to be the high order bit of the document. Question to the authors: (1) 127/8 seems to be vague. Shouldnt you be specifying an exact /32 address that should be used? (2) Do you think its wise to float two proposals that vendors can chose. Cant we have just one - either multicast or the 127/8 unicast? Why do we need two proposals? That would imo also address Nitin's concern (which i believe is quite valid). Toms On 09/02/2012, Nitin Bahadur wrote: > Hi Manav, > > The draft specifies multiple mechanisms and section 4.2 lists that all > MUST be supported. This doesn't make sense from > a vendor perspective IMO. If "all vendors" have to implement "all options", > then why not just have 1 option ! > > Having multiple options also leads to inter-op issue among vendors. We have > seen that story with multiple other protocols. > > Thanks > Nitin > > > On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" > wrote: > > Hi, > > There were some concerns about operational complexity that using unicast > addresses for micro BFD sessions would entail. We have written a short draft > that alleviates such concerns by suggesting few mechanisms that nodes can > use to auto discover remote neighbor IP addresses before establishing micro > BFD sessions. > > Would be great if the WG can review and provide feedback on this draft. > > The URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.txt > > Cheers, Manav > > -- > > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Reply-to: internet-drafts@ietf.org > Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt > X-C5I-RSN: 1/0/935/41368/44754 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : IP Address Schemes for Bidirectional Forwarding Detection (BFD) on > Link Aggregation Group (LAG) Interfaces > Author(s) : Manav Bhatia > Marc Binderberger > Sami Boutros > Nobo Akiya > Filename : draft-mmsn-bfd-on-lags-address-00.txt > Pages : 5 > Date : 2012-02-08 > > This document describes techniques which can be used by a router to > obtain or discover remote neighbor IP address in order to establish > micro Bidirectional Forwarding Detection (BFD) sessions > [BFD-ON-LAGS]. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > -- Toms. From manav.bhatia@alcatel-lucent.com Thu Feb 9 17:08:34 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 9E8B711E808F for ; Thu, 9 Feb 2012 17:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.78 X-Spam-Level: X-Spam-Status: No, score=-6.78 tagged_above=-999 required=5 tests=[AWL=-0.181, 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 OxVT8ya0k5JT for ; Thu, 9 Feb 2012 17:08:34 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 03F1411E809C for ; Thu, 9 Feb 2012 17:08:33 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q1A18QTw022213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Feb 2012 19:08:29 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q1A18PZ0026722 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 Feb 2012 06:38:25 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 10 Feb 2012 06:38:25 +0530 From: "Bhatia, Manav (Manav)" To: Nitin Bahadur , "rtg-bfd@ietf.org" Date: Fri, 10 Feb 2012 06:38:39 +0530 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: Aczm4BTZKNK9QL1IRoSgcwePoSmyvgASFNfWABnzfjA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02B49853@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D02AB456F@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 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, 10 Feb 2012 01:08:34 -0000 Hi Nitin, Sec 4 states that ideally two routers will use the same discovery mechanism= to interoperate, however, *if* they happen to implement different mechanis= ms then they can still interoperate if the rules laid down in sections 4.1 = and 4.2 are followed. We can dilute the requirements laid down in sections 4.1 and 4.2 and we can= actually use a lower case "should" instead of RFC 2119 "MUST" since this s= ection is only giving a hint to the developers. We had internally debated o= n whether we should use RFC 2119 language or not and had decided that it pr= obably made more sense to do that. If we really want different vendors to i= nteroperate despite using different mechanisms then they MUST follow the ru= les specified in sec 4.1 and 4.2 We have described two discovery mechanisms - one using multicast and the ot= her using 127/8, since we wanted to let the WG reach a consensus on which m= echanism it felt was more appropriate. This was again briefly discussed amo= ngst the authors and we decided to specify the two mechanisms in the first = version and remove the one that is not favored in the subsequent versions. Cheers, Manav > -----Original Message----- > From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 > Sent: Thursday, February 09, 2012 6:13 PM > To: Bhatia, Manav (Manav); rtg-bfd@ietf.org > Subject: Re: IP Address Schemes for BFD on LAG interfaces >=20 > Hi Manav, >=20 > The draft specifies multiple mechanisms and section 4.2=20 > lists that all MUST be supported. This doesn't make sense=20 > from a vendor perspective IMO. If "all vendors" have to=20 > implement "all options", then why not just have 1 option ! >=20 > Having multiple options also leads to inter-op issue among=20 > vendors. We have seen that story with multiple other protocols. >=20 > Thanks > Nitin >=20 >=20 > On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)"=20 > wrote: >=20 > Hi, >=20 > There were some concerns about operational complexity that=20 > using unicast addresses for micro BFD sessions would entail.=20 > We have written a short draft that alleviates such concerns=20 > by suggesting few mechanisms that nodes can use to auto=20 > discover remote neighbor IP addresses before establishing=20 > micro BFD sessions. >=20 > Would be great if the WG can review and provide feedback on=20 > this draft. >=20 > The URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-add ress-00.txt >=20 > Cheers, Manav From manav.bhatia@alcatel-lucent.com Thu Feb 9 17:23:38 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 F2DFD11E8094 for ; Thu, 9 Feb 2012 17:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.776 X-Spam-Level: X-Spam-Status: No, score=-6.776 tagged_above=-999 required=5 tests=[AWL=-0.177, 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 hKINYCOahpK9 for ; Thu, 9 Feb 2012 17:23:37 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAB611E8079 for ; Thu, 9 Feb 2012 17:23:36 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q1A1NUPw027512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Feb 2012 19:23:32 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q1A1NTM4027057 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 Feb 2012 06:53:29 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 10 Feb 2012 06:53:29 +0530 From: "Bhatia, Manav (Manav)" To: Tom Sanders , Nitin Bahadur Date: Fri, 10 Feb 2012 06:53:46 +0530 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: AcznRMGSlFR0t5TRRrCZaqTzK5PIdwAS9PHw Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02B49855@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D02AB456F@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 01:23:38 -0000 Hi Toms, >=20 > I could be completely off the mark in which case the authors=20 > can correct me. But this seemed to me to be the high order=20 > bit of the document. Perfect! What you've said above is absolutely correct.=20 >=20 > Question to the authors: >=20 > (1) 127/8 seems to be vague. Shouldnt you be specifying an=20 > exact /32 address that should be used? The idea is to let implementations choose a destination IP address randomly= from the 127/8 range. This is consistent with what has been described in R= FC 5884 (BFD for MPLS LSPs). =09 >=20 > (2) Do you think its wise to float two proposals that vendors=20 > can chose. Cant we have just one - either multicast or the=20 > 127/8 unicast? > Why do we need two proposals? That would imo also address=20 > Nitin's concern (which i believe is quite valid). Both proposals have their pros and cons and the authors of the draft are no= t biased towards any particular solution (multicast or 127/8). We would lik= e the members of the WG to reach a consensus on which proposal they would l= ike to see going forward (if one has to be chosen from the two). Hope this helps. Cheers, Manav >=20 > Toms >=20 > On 09/02/2012, Nitin Bahadur wrote: > > Hi Manav, > > > > The draft specifies multiple mechanisms and section 4.2=20 > lists that=20 > > all MUST be supported. This doesn't make sense from a vendor=20 > > perspective IMO. If "all vendors" have to implement "all options",=20 > > then why not just have 1 option ! > > > > Having multiple options also leads to inter-op issue among=20 > vendors. We=20 > > have seen that story with multiple other protocols. > > > > Thanks > > Nitin > > > > > > On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)"=20 > > > > wrote: > > > > Hi, > > > > There were some concerns about operational complexity that using=20 > > unicast addresses for micro BFD sessions would entail. We=20 > have written=20 > > a short draft that alleviates such concerns by suggesting few=20 > > mechanisms that nodes can use to auto discover remote neighbor IP=20 > > addresses before establishing micro BFD sessions. > > > > Would be great if the WG can review and provide feedback on=20 > this draft. > > > > The URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > txt > > > > Cheers, Manav > > > > -- > > > > From: internet-drafts@ietf.org > > To: i-d-announce@ietf.org > > Reply-to: internet-drafts@ietf.org > > Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt > > X-C5I-RSN: 1/0/935/41368/44754 > > > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > > > Title : IP Address Schemes for Bidirectional Forwarding Detection=20 > > (BFD) on Link Aggregation Group (LAG) Interfaces > > Author(s) : Manav Bhatia > > Marc Binderberger > > Sami Boutros > > Nobo Akiya > > Filename : draft-mmsn-bfd-on-lags-address-00.txt > > Pages : 5 > > Date : 2012-02-08 > > > > This document describes techniques which can be used by a router to=20 > > obtain or discover remote neighbor IP address in order to establish=20 > > micro Bidirectional Forwarding Detection (BFD) sessions=20 > [BFD-ON-LAGS]. > > > > > > > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > >=20 > ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.t > > xt > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > >=20 >=20 > -- > Toms. > = From mach.chen@huawei.com Thu Feb 9 18:25:17 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 76DE511E80B1 for ; Thu, 9 Feb 2012 18:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 dyk3UqXBN4Yi for ; Thu, 9 Feb 2012 18:25:16 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1A38E11E8087 for ; Thu, 9 Feb 2012 18:25:16 -0800 (PST) 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 <0LZ500I10O235Z@szxga05-in.huawei.com> for rtg-bfd@ietf.org; Fri, 10 Feb 2012 10:25:15 +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 <0LZ5008MUO22HX@szxga05-in.huawei.com> for rtg-bfd@ietf.org; Fri, 10 Feb 2012 10:25:14 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGZ95272; Fri, 10 Feb 2012 10:24:26 +0800 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 10 Feb 2012 10:23:43 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.206]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Fri, 10 Feb 2012 10:24:18 +0800 Date: Fri, 10 Feb 2012 02:24:17 +0000 From: Mach Chen Subject: RE: IP Address Schemes for BFD on LAG interfaces In-reply-to: <7C362EEF9C7896468B36C9B79200D8350D02B49855@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Originating-IP: [10.108.4.51] To: "Bhatia, Manav (Manav)" , Tom Sanders , Nitin Bahadur Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: IP Address Schemes for BFD on LAG interfaces Thread-index: Aczm4BTZKNK9QL1IRoSgcwePoSmyvgASFNfW//+ygwCAAJvUAP//bq/Q X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <7C362EEF9C7896468B36C9B79200D8350D02AB456F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D02B49855@INBANSXCHMBSA1.in.alcatel-lucent.com> 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, 10 Feb 2012 02:25:17 -0000 Hi Manav, Toms and all, Firstly, I share the concern of Nitin, and agree with Toms's point: one dynamic remote address learning solution is enough. From your reply, the authors also intend to keep only one solution, great! > Both proposals have their pros and cons and the authors of the draft are not > biased towards any particular solution (multicast or 127/8). We would like the > members of the WG to reach a consensus on which proposal they would like to > see going forward (if one has to be chosen from the two). Are there any analysis about the pros and cons? I personally prefer Multicast, because: 1. For the micro-BFD, we need a well-known Multicast MAC, if use Multicast for remote address learning, the Multicast MAC can be used for both remote address and MAC address learning; 2. The micro-BFD draft proposes to use unicast IP for L3 connectivity test, but the member link will be also used for L3 mulitcast forwarding, so use Multicast for remote address learning could test the L3 multicast connectivity at least one time; 3. On the other hand, if use 127/8, the receiver needs to combine extra information(e.g., UDP port) to identify the learning message. Best regards, Mach > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > Bhatia, Manav (Manav) > Sent: Friday, February 10, 2012 9:24 AM > To: Tom Sanders; Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces > > Hi Toms, > > > > > > I could be completely off the mark in which case the authors > > can correct me. But this seemed to me to be the high order > > bit of the document. > > Perfect! What you've said above is absolutely correct. > > > > > Question to the authors: > > > > (1) 127/8 seems to be vague. Shouldnt you be specifying an > > exact /32 address that should be used? > > The idea is to let implementations choose a destination IP address randomly > from the 127/8 range. This is consistent with what has been described in RFC > 5884 (BFD for MPLS LSPs). > > > > (2) Do you think its wise to float two proposals that vendors > > can chose. Cant we have just one - either multicast or the > > 127/8 unicast? > > Why do we need two proposals? That would imo also address > > Nitin's concern (which i believe is quite valid). > > Both proposals have their pros and cons and the authors of the draft are not > biased towards any particular solution (multicast or 127/8). We would like the > members of the WG to reach a consensus on which proposal they would like to > see going forward (if one has to be chosen from the two). > > Hope this helps. > > Cheers, Manav > > > > > Toms > > > > On 09/02/2012, Nitin Bahadur wrote: > > > Hi Manav, > > > > > > The draft specifies multiple mechanisms and section 4.2 > > lists that > > > all MUST be supported. This doesn't make sense from a vendor > > > perspective IMO. If "all vendors" have to implement "all options", > > > then why not just have 1 option ! > > > > > > Having multiple options also leads to inter-op issue among > > vendors. We > > > have seen that story with multiple other protocols. > > > > > > Thanks > > > Nitin > > > > > > > > > On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" > > > > > > wrote: > > > > > > Hi, > > > > > > There were some concerns about operational complexity that using > > > unicast addresses for micro BFD sessions would entail. We > > have written > > > a short draft that alleviates such concerns by suggesting few > > > mechanisms that nodes can use to auto discover remote neighbor IP > > > addresses before establishing micro BFD sessions. > > > > > > Would be great if the WG can review and provide feedback on > > this draft. > > > > > > The URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > > txt > > > > > > Cheers, Manav > > > > > > -- > > > > > > From: internet-drafts@ietf.org > > > To: i-d-announce@ietf.org > > > Reply-to: internet-drafts@ietf.org > > > Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt > > > X-C5I-RSN: 1/0/935/41368/44754 > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > Title : IP Address Schemes for Bidirectional Forwarding Detection > > > (BFD) on Link Aggregation Group (LAG) Interfaces > > > Author(s) : Manav Bhatia > > > Marc Binderberger > > > Sami Boutros > > > Nobo Akiya > > > Filename : draft-mmsn-bfd-on-lags-address-00.txt > > > Pages : 5 > > > Date : 2012-02-08 > > > > > > This document describes techniques which can be used by a router to > > > obtain or discover remote neighbor IP address in order to establish > > > micro Bidirectional Forwarding Detection (BFD) sessions > > [BFD-ON-LAGS]. > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > > txt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > This Internet-Draft can be retrieved at: > > > > > ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.t > > > xt > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > -- > > Toms. > > From manav.bhatia@alcatel-lucent.com Thu Feb 9 20:23:06 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 CAECB11E8081 for ; Thu, 9 Feb 2012 20:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.773 X-Spam-Level: X-Spam-Status: No, score=-6.773 tagged_above=-999 required=5 tests=[AWL=-0.174, 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 wpV1lJn6d5vy for ; Thu, 9 Feb 2012 20:23:06 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id DE63911E8075 for ; Thu, 9 Feb 2012 20:23:05 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q1A4McVW027971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Feb 2012 22:22:40 -0600 (CST) 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 q1A4MbX1009729 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 Feb 2012 09:52:37 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 10 Feb 2012 09:52:37 +0530 From: "Bhatia, Manav (Manav)" To: Mach Chen , Tom Sanders , Nitin Bahadur Date: Fri, 10 Feb 2012 09:50:15 +0530 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: Aczm4BTZKNK9QL1IRoSgcwePoSmyvgASFNfW//+ygwCAAJvUAP//bq/Q//637+A= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 04:23:06 -0000 Hi Mach, Yes, the idea is to just retain one mechanism.=20 I know you like multicast! ;-) This is btw exactly the opinion that will be useful in zeroing on a final d= iscovery mechanism. It would be good if others too can chime in with their = thoughts on this. Cheers, Manav > -----Original Message----- > From: Mach Chen [mailto:mach.chen@huawei.com]=20 > Sent: Friday, February 10, 2012 7:54 AM > To: Bhatia, Manav (Manav); Tom Sanders; Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces >=20 > Hi Manav, Toms and all, >=20 > Firstly, I share the concern of Nitin, and agree with Toms's=20 > point: one dynamic remote address learning solution is=20 > enough. From your reply, the authors also intend to keep only=20 > one solution, great! >=20 > > Both proposals have their pros and cons and the authors of=20 > the draft=20 > > are not biased towards any particular solution (multicast=20 > or 127/8).=20 > > We would like the members of the WG to reach a consensus on which=20 > > proposal they would like to see going forward (if one has=20 > to be chosen from the two). >=20 > Are there any analysis about the pros and cons? >=20 > I personally prefer Multicast, because: >=20 > 1. For the micro-BFD, we need a well-known Multicast MAC, if=20 > use Multicast for remote address learning, the Multicast MAC=20 > can be used for both remote address and MAC address learning; >=20 > 2. The micro-BFD draft proposes to use unicast IP for L3=20 > connectivity test, but the member link will be also used for=20 > L3 mulitcast forwarding, so use Multicast for remote address=20 > learning could test the L3 multicast connectivity at least one time; >=20 > 3. On the other hand, if use 127/8, the receiver needs to=20 > combine extra information(e.g., UDP port) to identify the=20 > learning message. >=20 >=20 > Best regards, > Mach >=20 > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 > > Behalf Of Bhatia, Manav (Manav) > > Sent: Friday, February 10, 2012 9:24 AM > > To: Tom Sanders; Nitin Bahadur > > Cc: rtg-bfd@ietf.org > > Subject: RE: IP Address Schemes for BFD on LAG interfaces > >=20 > > Hi Toms, > >=20 > >=20 > > > > > > I could be completely off the mark in which case the authors can=20 > > > correct me. But this seemed to me to be the high order bit of the=20 > > > document. > >=20 > > Perfect! What you've said above is absolutely correct. > >=20 > > > > > > Question to the authors: > > > > > > (1) 127/8 seems to be vague. Shouldnt you be specifying=20 > an exact /32=20 > > > address that should be used? > >=20 > > The idea is to let implementations choose a destination IP address=20 > > randomly from the 127/8 range. This is consistent with what=20 > has been=20 > > described in RFC > > 5884 (BFD for MPLS LSPs). > > > > > > (2) Do you think its wise to float two proposals that vendors can=20 > > > chose. Cant we have just one - either multicast or the > > > 127/8 unicast? > > > Why do we need two proposals? That would imo also address Nitin's=20 > > > concern (which i believe is quite valid). > >=20 > > Both proposals have their pros and cons and the authors of=20 > the draft=20 > > are not biased towards any particular solution (multicast=20 > or 127/8).=20 > > We would like the members of the WG to reach a consensus on which=20 > > proposal they would like to see going forward (if one has=20 > to be chosen from the two). > >=20 > > Hope this helps. > >=20 > > Cheers, Manav > >=20 > > > > > > Toms > > > > > > On 09/02/2012, Nitin Bahadur wrote: > > > > Hi Manav, > > > > > > > > The draft specifies multiple mechanisms and section 4.2 > > > lists that > > > > all MUST be supported. This doesn't make sense from a vendor=20 > > > > perspective IMO. If "all vendors" have to implement=20 > "all options",=20 > > > > then why not just have 1 option ! > > > > > > > > Having multiple options also leads to inter-op issue among > > > vendors. We > > > > have seen that story with multiple other protocols. > > > > > > > > Thanks > > > > Nitin > > > > > > > > > > > > On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" > > > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > There were some concerns about operational complexity=20 > that using=20 > > > > unicast addresses for micro BFD sessions would entail. We > > > have written > > > > a short draft that alleviates such concerns by suggesting few=20 > > > > mechanisms that nodes can use to auto discover remote=20 > neighbor IP=20 > > > > addresses before establishing micro BFD sessions. > > > > > > > > Would be great if the WG can review and provide feedback on > > > this draft. > > > > > > > > The URL for this Internet-Draft is: > > > > > > >=20 > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > > > txt > > > > > > > > Cheers, Manav > > > > > > > > -- > > > > > > > > From: internet-drafts@ietf.org > > > > To: i-d-announce@ietf.org > > > > Reply-to: internet-drafts@ietf.org > > > > Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt > > > > X-C5I-RSN: 1/0/935/41368/44754 > > > > > > > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > > > > directories. > > > > > > > > Title : IP Address Schemes for Bidirectional Forwarding=20 > Detection > > > > (BFD) on Link Aggregation Group (LAG) Interfaces > > > > Author(s) : Manav Bhatia > > > > Marc Binderberger > > > > Sami Boutros > > > > Nobo Akiya > > > > Filename : draft-mmsn-bfd-on-lags-address-00.txt > > > > Pages : 5 > > > > Date : 2012-02-08 > > > > > > > > This document describes techniques which can be used by=20 > a router=20 > > > > to obtain or discover remote neighbor IP address in order to=20 > > > > establish micro Bidirectional Forwarding Detection=20 > (BFD) sessions > > > [BFD-ON-LAGS]. > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > >=20 > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > > > txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > This Internet-Draft can be retrieved at: > > > > > > >=20 > ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00 > > > .t > > > > xt > > > > > > > > _______________________________________________ > > > > I-D-Announce mailing list > > > > I-D-Announce@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > > > > > > > -- > > > Toms. > > > > = From gregory.mirsky@ericsson.com Fri Feb 10 09:13:52 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 9096621F8668 for ; Fri, 10 Feb 2012 09:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 SDsGCVeDsqLE for ; Fri, 10 Feb 2012 09:13:51 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9C24B21F8667 for ; Fri, 10 Feb 2012 09:13:51 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q1AHDSwx011576; Fri, 10 Feb 2012 11:13:47 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.105]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 10 Feb 2012 12:13:26 -0500 From: Gregory Mirsky To: "Bhatia, Manav (Manav)" , Mach Chen , Tom Sanders , Nitin Bahadur Date: Fri, 10 Feb 2012 12:13:26 -0500 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: Aczm4BTZKNK9QL1IRoSgcwePoSmyvgASFNfW//+ygwCAAJvUAP//bq/Q//637+D//JixYA== Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 10 Feb 2012 17:13:52 -0000 Hi Manav, Then you know where my heart is. It randomly picks from 127/8 range. ;) One possible disadvantage of using single well-known mcast IP address as DA= in micro-BFD mode, IMO, is that to receipient initial BFD packets (Your Di= scriminator is still zeroed) hard to differentiate, they all are the same b= ut My Discriminator. Should not be a problem but might cause some issues ne= vertheless. Regards, Greg=20 -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Bhatia, Manav (Manav) Sent: Thursday, February 09, 2012 8:20 PM To: Mach Chen; Tom Sanders; Nitin Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Hi Mach, Yes, the idea is to just retain one mechanism.=20 I know you like multicast! ;-) This is btw exactly the opinion that will be useful in zeroing on a final d= iscovery mechanism. It would be good if others too can chime in with their = thoughts on this. Cheers, Manav > -----Original Message----- > From: Mach Chen [mailto:mach.chen@huawei.com] > Sent: Friday, February 10, 2012 7:54 AM > To: Bhatia, Manav (Manav); Tom Sanders; Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces >=20 > Hi Manav, Toms and all, >=20 > Firstly, I share the concern of Nitin, and agree with Toms's > point: one dynamic remote address learning solution is enough. From=20 > your reply, the authors also intend to keep only one solution, great! >=20 > > Both proposals have their pros and cons and the authors of > the draft > > are not biased towards any particular solution (multicast > or 127/8).=20 > > We would like the members of the WG to reach a consensus on which=20 > > proposal they would like to see going forward (if one has > to be chosen from the two). >=20 > Are there any analysis about the pros and cons? >=20 > I personally prefer Multicast, because: >=20 > 1. For the micro-BFD, we need a well-known Multicast MAC, if use=20 > Multicast for remote address learning, the Multicast MAC can be used=20 > for both remote address and MAC address learning; >=20 > 2. The micro-BFD draft proposes to use unicast IP for L3 connectivity=20 > test, but the member link will be also used for > L3 mulitcast forwarding, so use Multicast for remote address learning=20 > could test the L3 multicast connectivity at least one time; >=20 > 3. On the other hand, if use 127/8, the receiver needs to combine=20 > extra information(e.g., UDP port) to identify the learning message. >=20 >=20 > Best regards, > Mach >=20 > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 > > Behalf Of Bhatia, Manav (Manav) > > Sent: Friday, February 10, 2012 9:24 AM > > To: Tom Sanders; Nitin Bahadur > > Cc: rtg-bfd@ietf.org > > Subject: RE: IP Address Schemes for BFD on LAG interfaces > >=20 > > Hi Toms, > >=20 > >=20 > > > > > > I could be completely off the mark in which case the authors can=20 > > > correct me. But this seemed to me to be the high order bit of the=20 > > > document. > >=20 > > Perfect! What you've said above is absolutely correct. > >=20 > > > > > > Question to the authors: > > > > > > (1) 127/8 seems to be vague. Shouldnt you be specifying=20 > an exact /32=20 > > > address that should be used? > >=20 > > The idea is to let implementations choose a destination IP address=20 > > randomly from the 127/8 range. This is consistent with what=20 > has been=20 > > described in RFC > > 5884 (BFD for MPLS LSPs). > > > > > > (2) Do you think its wise to float two proposals that vendors can=20 > > > chose. Cant we have just one - either multicast or the > > > 127/8 unicast? > > > Why do we need two proposals? That would imo also address Nitin's=20 > > > concern (which i believe is quite valid). > >=20 > > Both proposals have their pros and cons and the authors of=20 > the draft=20 > > are not biased towards any particular solution (multicast=20 > or 127/8).=20 > > We would like the members of the WG to reach a consensus on which=20 > > proposal they would like to see going forward (if one has=20 > to be chosen from the two). > >=20 > > Hope this helps. > >=20 > > Cheers, Manav > >=20 > > > > > > Toms > > > > > > On 09/02/2012, Nitin Bahadur wrote: > > > > Hi Manav, > > > > > > > > The draft specifies multiple mechanisms and section 4.2 > > > lists that > > > > all MUST be supported. This doesn't make sense from a vendor=20 > > > > perspective IMO. If "all vendors" have to implement=20 > "all options",=20 > > > > then why not just have 1 option ! > > > > > > > > Having multiple options also leads to inter-op issue among > > > vendors. We > > > > have seen that story with multiple other protocols. > > > > > > > > Thanks > > > > Nitin > > > > > > > > > > > > On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" > > > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > There were some concerns about operational complexity=20 > that using=20 > > > > unicast addresses for micro BFD sessions would entail. We > > > have written > > > > a short draft that alleviates such concerns by suggesting few=20 > > > > mechanisms that nodes can use to auto discover remote=20 > neighbor IP=20 > > > > addresses before establishing micro BFD sessions. > > > > > > > > Would be great if the WG can review and provide feedback on > > > this draft. > > > > > > > > The URL for this Internet-Draft is: > > > > > > >=20 > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > > > txt > > > > > > > > Cheers, Manav > > > > > > > > -- > > > > > > > > From: internet-drafts@ietf.org > > > > To: i-d-announce@ietf.org > > > > Reply-to: internet-drafts@ietf.org > > > > Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt > > > > X-C5I-RSN: 1/0/935/41368/44754 > > > > > > > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > > > > directories. > > > > > > > > Title : IP Address Schemes for Bidirectional Forwarding=20 > Detection > > > > (BFD) on Link Aggregation Group (LAG) Interfaces > > > > Author(s) : Manav Bhatia > > > > Marc Binderberger > > > > Sami Boutros > > > > Nobo Akiya > > > > Filename : draft-mmsn-bfd-on-lags-address-00.txt > > > > Pages : 5 > > > > Date : 2012-02-08 > > > > > > > > This document describes techniques which can be used by=20 > a router=20 > > > > to obtain or discover remote neighbor IP address in order to=20 > > > > establish micro Bidirectional Forwarding Detection=20 > (BFD) sessions > > > [BFD-ON-LAGS]. > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > >=20 > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > > > txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > This Internet-Draft can be retrieved at: > > > > > > >=20 > ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00 > > > .t > > > > xt > > > > > > > > _______________________________________________ > > > > I-D-Announce mailing list > > > > I-D-Announce@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > > > > > > > -- > > > Toms. > > > > = From Alexander.Vainshtein@ecitele.com Fri Feb 10 10:10:37 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3CD21F87B7 for ; Fri, 10 Feb 2012 10:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.514 X-Spam-Level: X-Spam-Status: No, score=-4.514 tagged_above=-999 required=5 tests=[AWL=0.689, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 YxAkPtCdl+A8 for ; Fri, 10 Feb 2012 10:10:36 -0800 (PST) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 487D321F87C0 for ; Fri, 10 Feb 2012 10:10:35 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1328897431!12361178!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 3046 invoked from network); 10 Feb 2012 18:10:32 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-13.tower-21.messagelabs.com with SMTP; 10 Feb 2012 18:10:32 -0000 X-AuditID: 93eaf2e7-b7f2a6d000000e7d-61-4f356981a108 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id D8.92.03709.189653F4; Fri, 10 Feb 2012 21:01:21 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Fri, 10 Feb 2012 20:10:31 +0200 From: Alexander Vainshtein To: Gregory Mirsky , "Bhatia, Manav (Manav)" , Mach Chen , Tom Sanders , Nitin Bahadur Date: Fri, 10 Feb 2012 20:08:57 +0200 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: Aczm4BTZKNK9QL1IRoSgcwePoSmyvgASFNfW//+ygwCAAJvUAP//bq/Q//637+D//JixYADbdleo Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupll+LIzCtJLcpLzFFi42KZ/OrTF93GTFN/g8MvjS2eP+litLiwVthi zr17rBYNve1sFp//bGO0uPppJZMDm0frs72sHr++XmXz2DnrLrtHy5G3rB5Llvxk8rjedJU9 gC2qgdEmMS8vvySxJFUhJbU42VYpoCizLDG5UkkhM8VWyVBJoSAnMTk1NzWvxFYpsaAgNS9F yY7LBiiYmaeQmpecn5KZl26r5Bnsr2thYWqpa6hkp6ZsaGzNFZKRWayQqpubmJmjkJtaXJyY nqoAFAF5JC8lNUUhLb9IoSQjVaEoYTJzxuOezcwFS10rHv06yNTA+Nq0i5GTQ0LAROLr1Wts ELaYxIV764FsLg4hgf2MEuv2TWSCcKYxSlz+/IUVpIpNwFZi0+q7YFUiArcZJZ4+WckEkmAW 0JRoOvGZHcRmEVCVeDf9NVhcWMBS4nLvdDBbRMBKYteyt1B2lMSnq2+Yuxg5OHgFAiVu/5aF WPaVUeLYkx6wkzgFIiSuz/kKtpgR6Lzvp9ZA7RKXuPVkPhPE2QISS/acZ4awRSVePv4HVS8q cad9PSNEvY7Egt2f2CBsbYllC1+D1fMKCEqcnPmEBaJXUuLgihssExjFZyFZMQtJ+ywk7bOQ tC9gZFnFKJqZU1CSlJtuYKiXmpxZkpqTqpecn7uJEZKYnu9g/DVf5RCjAAejEg+vhYuJvxBr YllxZe4hRkkOJiVR3kvRpv5CfEn5KZUZicUZ8UWlOanFhxglOJiVRHh7xIByvCmJlVWpRfkw KQtgKE9kluJOzgfFdkm8sYEBCkdJnPdp8htfIYF0YLLLTk0tSC2CaZXh4FCS4OWPBZoqWJSa nlqRlplTgpBm4uAE2cwDtPlBDMjm4oLE3OLMdIj8KUZdjqn/1l1gFGLJy89LlRLnZQQZJABS lFGaBzcHlIvq/////4pRHOhnYV42kCoeYNKEm/QKaAkT0BLpcyYgS4DZAy4l1cBox5EwJe7j mmgz/bdGjXrOB2PquNK3+t8PDru3TSrj3MR3vu8fbkrauWQGl/SFJYatT27GcP8s2pYl8qkp tPxWhfNbz6VO0carGRM6QhQ4xS/fMeFc73xi77y0/bqV0jYnb57fsE5luf7EFzOUQ4pCMvO8 tjVcWDzTR/nO3ac5ze3B6W0PnhgqsRRnJBpqMRcVJwIAxbq+qiAEAAA= 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, 10 Feb 2012 18:10:37 -0000 Dear Greg, Manav and all, I have strong doubts regarding using destination IP address in the 127/8 ran= ge in the initial micro-BFD packets for the peer address discovery. In particular, I think that the reference to LSP Ping (RFC 4379) is incorrec= t, because LSP Ping Echo packets MUST set the Router Alert option in the IP= header (see Section 4.3. "Sending an MPLS Echo Request") in conjunction wit= h using Destination IP address from the 127/8 range. Many IP stacks silently discarded received packets with Destination IP addre= ss in the 127/8 range unless it is accompanied by the Router Alert option. R= FC 1122 and RFC 1812 definitely allow (and even request) that. RFC 4379 has taken care to provide for backward compatibility with these req= uirements. Adding the Router Alert option to the initial packets of the micro-BFD sessi= on could in principle resolve this contradiction but would actually result i= n one more step away from reuse (claimed) of existing implementations of RF= C 5881. My 2c, Sasha ________________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of Grego= ry Mirsky [gregory.mirsky@ericsson.com] Sent: Friday, February 10, 2012 7:13 PM To: Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Hi Manav, Then you know where my heart is. It randomly picks from 127/8 range. ;) One possible disadvantage of using single well-known mcast IP address as DA= in micro-BFD mode, IMO, is that to receipient initial BFD packets (Your Dis= criminator is still zeroed) hard to differentiate, they all are the same but= My Discriminator. Should not be a problem but might cause some issues never= theless. Regards, Greg -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf O= f Bhatia, Manav (Manav) Sent: Thursday, February 09, 2012 8:20 PM To: Mach Chen; Tom Sanders; Nitin Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Hi Mach, Yes, the idea is to just retain one mechanism. I know you like multicast! ;-) This is btw exactly the opinion that will be useful in zeroing on a final di= scovery mechanism. It would be good if others too can chime in with their th= oughts on this. Cheers, Manav > -----Original Message----- > From: Mach Chen [mailto:mach.chen@huawei.com] > Sent: Friday, February 10, 2012 7:54 AM > To: Bhatia, Manav (Manav); Tom Sanders; Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces > > Hi Manav, Toms and all, > > Firstly, I share the concern of Nitin, and agree with Toms's > point: one dynamic remote address learning solution is enough. From > your reply, the authors also intend to keep only one solution, great! > > > Both proposals have their pros and cons and the authors of > the draft > > are not biased towards any particular solution (multicast > or 127/8). > > We would like the members of the WG to reach a consensus on which > > proposal they would like to see going forward (if one has > to be chosen from the two). > > Are there any analysis about the pros and cons? > > I personally prefer Multicast, because: > > 1. For the micro-BFD, we need a well-known Multicast MAC, if use > Multicast for remote address learning, the Multicast MAC can be used > for both remote address and MAC address learning; > > 2. The micro-BFD draft proposes to use unicast IP for L3 connectivity > test, but the member link will be also used for > L3 mulitcast forwarding, so use Multicast for remote address learning > could test the L3 multicast connectivity at least one time; > > 3. On the other hand, if use 127/8, the receiver needs to combine > extra information(e.g., UDP port) to identify the learning message. > > > Best regards, > Mach > > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > > Behalf Of Bhatia, Manav (Manav) > > Sent: Friday, February 10, 2012 9:24 AM > > To: Tom Sanders; Nitin Bahadur > > Cc: rtg-bfd@ietf.org > > Subject: RE: IP Address Schemes for BFD on LAG interfaces > > > > Hi Toms, > > > > > > > > > > I could be completely off the mark in which case the authors can > > > correct me. But this seemed to me to be the high order bit of the > > > document. > > > > Perfect! What you've said above is absolutely correct. > > > > > > > > Question to the authors: > > > > > > (1) 127/8 seems to be vague. Shouldnt you be specifying > an exact /32 > > > address that should be used? > > > > The idea is to let implementations choose a destination IP address > > randomly from the 127/8 range. This is consistent with what > has been > > described in RFC > > 5884 (BFD for MPLS LSPs). > > > > > > (2) Do you think its wise to float two proposals that vendors can > > > chose. Cant we have just one - either multicast or the > > > 127/8 unicast? > > > Why do we need two proposals? That would imo also address Nitin's > > > concern (which i believe is quite valid). > > > > Both proposals have their pros and cons and the authors of > the draft > > are not biased towards any particular solution (multicast > or 127/8). > > We would like the members of the WG to reach a consensus on which > > proposal they would like to see going forward (if one has > to be chosen from the two). > > > > Hope this helps. > > > > Cheers, Manav > > > > > > > > Toms > > > > > > On 09/02/2012, Nitin Bahadur wrote: > > > > Hi Manav, > > > > > > > > The draft specifies multiple mechanisms and section 4.2 > > > lists that > > > > all MUST be supported. This doesn't make sense from a vendor > > > > perspective IMO. If "all vendors" have to implement > "all options", > > > > then why not just have 1 option ! > > > > > > > > Having multiple options also leads to inter-op issue among > > > vendors. We > > > > have seen that story with multiple other protocols. > > > > > > > > Thanks > > > > Nitin > > > > > > > > > > > > On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" > > > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > There were some concerns about operational complexity > that using > > > > unicast addresses for micro BFD sessions would entail. We > > > have written > > > > a short draft that alleviates such concerns by suggesting few > > > > mechanisms that nodes can use to auto discover remote > neighbor IP > > > > addresses before establishing micro BFD sessions. > > > > > > > > Would be great if the WG can review and provide feedback on > > > this draft. > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > > > txt > > > > > > > > Cheers, Manav > > > > > > > > -- > > > > > > > > From: internet-drafts@ietf.org > > > > To: i-d-announce@ietf.org > > > > Reply-to: internet-drafts@ietf.org > > > > Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt > > > > X-C5I-RSN: 1/0/935/41368/44754 > > > > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > > > directories. > > > > > > > > Title : IP Address Schemes for Bidirectional Forwarding > Detection > > > > (BFD) on Link Aggregation Group (LAG) Interfaces > > > > Author(s) : Manav Bhatia > > > > Marc Binderberger > > > > Sami Boutros > > > > Nobo Akiya > > > > Filename : draft-mmsn-bfd-on-lags-address-00.txt > > > > Pages : 5 > > > > Date : 2012-02-08 > > > > > > > > This document describes techniques which can be used by > a router > > > > to obtain or discover remote neighbor IP address in order to > > > > establish micro Bidirectional Forwarding Detection > (BFD) sessions > > > [BFD-ON-LAGS]. > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > > > txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > This Internet-Draft can be retrieved at: > > > > > > > > ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00 > > > .t > > > > xt > > > > > > > > _______________________________________________ > > > > I-D-Announce mailing list > > > > I-D-Announce@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > > > > > > > -- > > > Toms. > > > > 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 gregory.mirsky@ericsson.com Fri Feb 10 10:52:02 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 7F36D21F8807 for ; Fri, 10 Feb 2012 10:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 fu9CHTlLs8P3 for ; Fri, 10 Feb 2012 10:51:59 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 60DAC21F87EE for ; Fri, 10 Feb 2012 10:51:59 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q1AIpSxW032451; Fri, 10 Feb 2012 12:51:40 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.105]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 10 Feb 2012 13:51:31 -0500 From: Gregory Mirsky To: Alexander Vainshtein , "Bhatia, Manav (Manav)" , Mach Chen , Tom Sanders , Nitin Bahadur Date: Fri, 10 Feb 2012 13:51:29 -0500 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: Aczm4BTZKNK9QL1IRoSgcwePoSmyvgASFNfW//+ygwCAAJvUAP//bq/Q//637+D//JixYADbdleo///zHjA= Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 10 Feb 2012 18:52:02 -0000 Dear Sasha, Thank you for pointing to RA use in LSP Ping. I agree that reference to RFC= 4379 is not the most appropriate. I think that RFC 5884 is more suitable a= s reference since both address single hop BFD and thus Router Alert is not = required. Regards, Greg -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Friday, February 10, 2012 10:09 AM To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Ba= hadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Dear Greg, Manav and all, I have strong doubts regarding using destination IP address in the 127/8 ra= nge in the initial micro-BFD packets for the peer address discovery. In particular, I think that the reference to LSP Ping (RFC 4379) is incorre= ct, because LSP Ping Echo packets MUST set the Router Alert option in the I= P header (see Section 4.3. "Sending an MPLS Echo Request") in conjunction w= ith using Destination IP address from the 127/8 range. Many IP stacks silently discarded received packets with Destination IP addr= ess in the 127/8 range unless it is accompanied by the Router Alert option.= RFC 1122 and RFC 1812 definitely allow (and even request) that. RFC 4379 has taken care to provide for backward compatibility with these re= quirements. Adding the Router Alert option to the initial packets of the micro-BFD sess= ion could in principle resolve this contradiction but would actually result= in one more step away from reuse (claimed) of existing implementations of= RFC 5881. My 2c, Sasha ________________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of Greg= ory Mirsky [gregory.mirsky@ericsson.com] Sent: Friday, February 10, 2012 7:13 PM To: Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Hi Manav, Then you know where my heart is. It randomly picks from 127/8 range. ;) One= possible disadvantage of using single well-known mcast IP address as DA in= micro-BFD mode, IMO, is that to receipient initial BFD packets (Your Discr= iminator is still zeroed) hard to differentiate, they all are the same but = My Discriminator. Should not be a problem but might cause some issues never= theless. Regards, Greg -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Bhatia, Manav (Manav) Sent: Thursday, February 09, 2012 8:20 PM To: Mach Chen; Tom Sanders; Nitin Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Hi Mach, Yes, the idea is to just retain one mechanism. I know you like multicast! ;-) This is btw exactly the opinion that will be useful in zeroing on a final d= iscovery mechanism. It would be good if others too can chime in with their = thoughts on this. Cheers, Manav > -----Original Message----- > From: Mach Chen [mailto:mach.chen@huawei.com] > Sent: Friday, February 10, 2012 7:54 AM > To: Bhatia, Manav (Manav); Tom Sanders; Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces > > Hi Manav, Toms and all, > > Firstly, I share the concern of Nitin, and agree with Toms's > point: one dynamic remote address learning solution is enough. From=20 > your reply, the authors also intend to keep only one solution, great! > > > Both proposals have their pros and cons and the authors of > the draft > > are not biased towards any particular solution (multicast > or 127/8). > > We would like the members of the WG to reach a consensus on which=20 > > proposal they would like to see going forward (if one has > to be chosen from the two). > > Are there any analysis about the pros and cons? > > I personally prefer Multicast, because: > > 1. For the micro-BFD, we need a well-known Multicast MAC, if use=20 > Multicast for remote address learning, the Multicast MAC can be used=20 > for both remote address and MAC address learning; > > 2. The micro-BFD draft proposes to use unicast IP for L3 connectivity=20 > test, but the member link will be also used for > L3 mulitcast forwarding, so use Multicast for remote address learning=20 > could test the L3 multicast connectivity at least one time; > > 3. On the other hand, if use 127/8, the receiver needs to combine=20 > extra information(e.g., UDP port) to identify the learning message. > > > Best regards, > Mach > > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 > > Behalf Of Bhatia, Manav (Manav) > > Sent: Friday, February 10, 2012 9:24 AM > > To: Tom Sanders; Nitin Bahadur > > Cc: rtg-bfd@ietf.org > > Subject: RE: IP Address Schemes for BFD on LAG interfaces > > > > Hi Toms, > > > > > > > > > > I could be completely off the mark in which case the authors can=20 > > > correct me. But this seemed to me to be the high order bit of the=20 > > > document. > > > > Perfect! What you've said above is absolutely correct. > > > > > > > > Question to the authors: > > > > > > (1) 127/8 seems to be vague. Shouldnt you be specifying > an exact /32 > > > address that should be used? > > > > The idea is to let implementations choose a destination IP address=20 > > randomly from the 127/8 range. This is consistent with what > has been > > described in RFC > > 5884 (BFD for MPLS LSPs). > > > > > > (2) Do you think its wise to float two proposals that vendors can=20 > > > chose. Cant we have just one - either multicast or the > > > 127/8 unicast? > > > Why do we need two proposals? That would imo also address Nitin's=20 > > > concern (which i believe is quite valid). > > > > Both proposals have their pros and cons and the authors of > the draft > > are not biased towards any particular solution (multicast > or 127/8). > > We would like the members of the WG to reach a consensus on which=20 > > proposal they would like to see going forward (if one has > to be chosen from the two). > > > > Hope this helps. > > > > Cheers, Manav > > > > > > > > Toms > > > > > > On 09/02/2012, Nitin Bahadur wrote: > > > > Hi Manav, > > > > > > > > The draft specifies multiple mechanisms and section 4.2 > > > lists that > > > > all MUST be supported. This doesn't make sense from a vendor=20 > > > > perspective IMO. If "all vendors" have to implement > "all options", > > > > then why not just have 1 option ! > > > > > > > > Having multiple options also leads to inter-op issue among > > > vendors. We > > > > have seen that story with multiple other protocols. > > > > > > > > Thanks > > > > Nitin > > > > > > > > > > > > On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" > > > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > There were some concerns about operational complexity > that using > > > > unicast addresses for micro BFD sessions would entail. We > > > have written > > > > a short draft that alleviates such concerns by suggesting few=20 > > > > mechanisms that nodes can use to auto discover remote > neighbor IP > > > > addresses before establishing micro BFD sessions. > > > > > > > > Would be great if the WG can review and provide feedback on > > > this draft. > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > > > txt > > > > > > > > Cheers, Manav > > > > > > > > -- > > > > > > > > From: internet-drafts@ietf.org > > > > To: i-d-announce@ietf.org > > > > Reply-to: internet-drafts@ietf.org > > > > Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt > > > > X-C5I-RSN: 1/0/935/41368/44754 > > > > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > > > directories. > > > > > > > > Title : IP Address Schemes for Bidirectional Forwarding > Detection > > > > (BFD) on Link Aggregation Group (LAG) Interfaces > > > > Author(s) : Manav Bhatia > > > > Marc Binderberger > > > > Sami Boutros > > > > Nobo Akiya > > > > Filename : draft-mmsn-bfd-on-lags-address-00.txt > > > > Pages : 5 > > > > Date : 2012-02-08 > > > > > > > > This document describes techniques which can be used by > a router > > > > to obtain or discover remote neighbor IP address in order to=20 > > > > establish micro Bidirectional Forwarding Detection > (BFD) sessions > > > [BFD-ON-LAGS]. > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > > > txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > This Internet-Draft can be retrieved at: > > > > > > > > ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00 > > > .t > > > > xt > > > > > > > > _______________________________________________ > > > > I-D-Announce mailing list > > > > I-D-Announce@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > > > > > > > -- > > > Toms. > > > > This e-mail message is intended for the recipient only and contains informa= tion 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, p= hone or fax, and then delete the original and all copies thereof. From Alexander.Vainshtein@ecitele.com Fri Feb 10 12:14:27 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 481DA11E80B1 for ; Fri, 10 Feb 2012 12:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.529 X-Spam-Level: X-Spam-Status: No, score=-4.529 tagged_above=-999 required=5 tests=[AWL=0.674, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 1qHtZ809zq1K for ; Fri, 10 Feb 2012 12:14:26 -0800 (PST) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 6580121F8874 for ; Fri, 10 Feb 2012 12:14:25 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1328904863!12371198!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 21496 invoked from network); 10 Feb 2012 20:14:23 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-13.tower-21.messagelabs.com with SMTP; 10 Feb 2012 20:14:23 -0000 X-AuditID: 93eaf2e7-b7f2a6d000000e7d-f1-4f3586887f8c Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id FF.83.03709.886853F4; Fri, 10 Feb 2012 23:05:12 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Fri, 10 Feb 2012 22:14:22 +0200 From: Alexander Vainshtein To: Gregory Mirsky , "Bhatia, Manav (Manav)" , Mach Chen , Tom Sanders , Nitin Bahadur Date: Fri, 10 Feb 2012 22:10:25 +0200 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: Aczm4BTZKNK9QL1IRoSgcwePoSmyvgASFNfW//+ygwCAAJvUAP//bq/Q//637+D//JixYADbdleo///zHjD//8zLYA== Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLsWRmVeSWpSXmKPExsUy+dWnL7odbab+Bif+KFk8f9LFaHFhrbDF nHv3WC0aetvZLD7/2cZocfXTSiYHNo/WZ3tZPX59vcrmsXPWXXaPliNvWT2WLPnJ5HG96Sp7 AFtUA6NNYl5efkliSapCSmpxsq1SQFFmWWJypZJCZoqtkqGSQkFOYnJqbmpeia1SYkFBal6K kh2XDVAwM08hNS85PyUzL91WyTPYX9fCwtRS11DJTk3Z0NiaKyQjs1ghVTc3MTNHITe1uDgx PVUBKALySF5KaopCWn6RQklGqkJRwmTmjN8rtzMVbAusmL95HksD4z77LkZODgkBE4mW+SsY IWwxiQv31rOB2EIC+xklvp/O6mLkArKnMUocuLiGBSTBJmArsWn1XTaQhIjAbUaJp09WMoEk mAU0JZpOfGYHsVkEVCVmn4WwhQUsJS73TgerERGwkti17C2UnSUx//hWMJtXIFDi0NNjjBDb Opklfu66AbaNUyBCov/MfbAiRqDzvp9aA7VMXOLWk/lMEGcLSCzZc54ZwhaVePn4HytEvajE nfb1jBD1OhILdn9ig7C1JZYtfM0MsVhQ4uTMJywQvZISB1fcYJnAKD4LyYpZSNpnIWmfhaR9 ASPLKkbRzJyCkqTcdANDvdTkzJLUnFS95PzcTYyQxPR8B+Ov+SqHGAU4GJV4eBc0mPoLsSaW FVfmHmKU5GBSEuVdWgoU4kvKT6nMSCzOiC8qzUktPsQowcGsJMLbIwaU401JrKxKLcqHSVkA g3kisxR3cj4otkvijQ0MUDhK4rxPk9/4CgmkA5NddmpqQWoRTKsMB4eSBO+hSqCpgkWp6akV aZk5JQhpJg5OkM08QJv3gtTwFhck5hZnpkPkTzEac0z9t+4CI8fB9vUXGIVY8vLzUqXEeXeC lAqAlGaU5sFNA+Wl+v///79iFAf6XBhiKQ8wgcLNewW0iglolfQ5E5BVwEwCl5JqYJyWssjm 1at11kfcTsv0XrR+3mE+m9svqYrz9Sn3C6ZH247//RfSYLEiLVnx8b72ddvEGJbd/x1d1l0+ s0Rl8uEPVRYeE+LuLNn5sM/6vLt/ftQyr8U8U1kfZMcfu/0h2pxpZ8cC5qf97OVVLjyFbw9H 2jxcdZp7MaP4+T8PHuyLOOBzyLoy/YMSS3FGoqEWc1FxIgDNJfH0JgQAAA== 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, 10 Feb 2012 20:14:27 -0000 Dear Greg, RFC 5884 indeed does not explicitly requires any form of Router Alert. However, it uses LSP Ping (RFC 4379) for bootstrapping the BFD sessions - an= d this, in its turn, uses Router Alert. So I am not sure that reference to RFC 5884 is appropriate either. Did I miss something? Regards, Sasha ________________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Friday, February 10, 2012 8:51 PM To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nit= in Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Dear Sasha, Thank you for pointing to RA use in LSP Ping. I agree that reference to RFC= 4379 is not the most appropriate. I think that RFC 5884 is more suitable as= reference since both address single hop BFD and thus Router Alert is not re= quired. Regards, Greg -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Friday, February 10, 2012 10:09 AM To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bah= adur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Dear Greg, Manav and all, I have strong doubts regarding using destination IP address in the 127/8 ran= ge in the initial micro-BFD packets for the peer address discovery. In particular, I think that the reference to LSP Ping (RFC 4379) is incorrec= t, because LSP Ping Echo packets MUST set the Router Alert option in the IP= header (see Section 4.3. "Sending an MPLS Echo Request") in conjunction wit= h using Destination IP address from the 127/8 range. Many IP stacks silently discarded received packets with Destination IP addre= ss in the 127/8 range unless it is accompanied by the Router Alert option. R= FC 1122 and RFC 1812 definitely allow (and even request) that. RFC 4379 has taken care to provide for backward compatibility with these req= uirements. Adding the Router Alert option to the initial packets of the micro-BFD sessi= on could in principle resolve this contradiction but would actually result i= n one more step away from reuse (claimed) of existing implementations of RF= C 5881. My 2c, Sasha ________________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of Grego= ry Mirsky [gregory.mirsky@ericsson.com] Sent: Friday, February 10, 2012 7:13 PM To: Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Hi Manav, Then you know where my heart is. It randomly picks from 127/8 range. ;) One= possible disadvantage of using single well-known mcast IP address as DA in= micro-BFD mode, IMO, is that to receipient initial BFD packets (Your Discri= minator is still zeroed) hard to differentiate, they all are the same but My= Discriminator. Should not be a problem but might cause some issues neverthe= less. Regards, Greg -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf O= f Bhatia, Manav (Manav) Sent: Thursday, February 09, 2012 8:20 PM To: Mach Chen; Tom Sanders; Nitin Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Hi Mach, Yes, the idea is to just retain one mechanism. I know you like multicast! ;-) This is btw exactly the opinion that will be useful in zeroing on a final di= scovery mechanism. It would be good if others too can chime in with their th= oughts on this. Cheers, Manav > -----Original Message----- > From: Mach Chen [mailto:mach.chen@huawei.com] > Sent: Friday, February 10, 2012 7:54 AM > To: Bhatia, Manav (Manav); Tom Sanders; Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces > > Hi Manav, Toms and all, > > Firstly, I share the concern of Nitin, and agree with Toms's > point: one dynamic remote address learning solution is enough. From > your reply, the authors also intend to keep only one solution, great! > > > Both proposals have their pros and cons and the authors of > the draft > > are not biased towards any particular solution (multicast > or 127/8). > > We would like the members of the WG to reach a consensus on which > > proposal they would like to see going forward (if one has > to be chosen from the two). > > Are there any analysis about the pros and cons? > > I personally prefer Multicast, because: > > 1. For the micro-BFD, we need a well-known Multicast MAC, if use > Multicast for remote address learning, the Multicast MAC can be used > for both remote address and MAC address learning; > > 2. The micro-BFD draft proposes to use unicast IP for L3 connectivity > test, but the member link will be also used for > L3 mulitcast forwarding, so use Multicast for remote address learning > could test the L3 multicast connectivity at least one time; > > 3. On the other hand, if use 127/8, the receiver needs to combine > extra information(e.g., UDP port) to identify the learning message. > > > Best regards, > Mach > > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > > Behalf Of Bhatia, Manav (Manav) > > Sent: Friday, February 10, 2012 9:24 AM > > To: Tom Sanders; Nitin Bahadur > > Cc: rtg-bfd@ietf.org > > Subject: RE: IP Address Schemes for BFD on LAG interfaces > > > > Hi Toms, > > > > > > > > > > I could be completely off the mark in which case the authors can > > > correct me. But this seemed to me to be the high order bit of the > > > document. > > > > Perfect! What you've said above is absolutely correct. > > > > > > > > Question to the authors: > > > > > > (1) 127/8 seems to be vague. Shouldnt you be specifying > an exact /32 > > > address that should be used? > > > > The idea is to let implementations choose a destination IP address > > randomly from the 127/8 range. This is consistent with what > has been > > described in RFC > > 5884 (BFD for MPLS LSPs). > > > > > > (2) Do you think its wise to float two proposals that vendors can > > > chose. Cant we have just one - either multicast or the > > > 127/8 unicast? > > > Why do we need two proposals? That would imo also address Nitin's > > > concern (which i believe is quite valid). > > > > Both proposals have their pros and cons and the authors of > the draft > > are not biased towards any particular solution (multicast > or 127/8). > > We would like the members of the WG to reach a consensus on which > > proposal they would like to see going forward (if one has > to be chosen from the two). > > > > Hope this helps. > > > > Cheers, Manav > > > > > > > > Toms > > > > > > On 09/02/2012, Nitin Bahadur wrote: > > > > Hi Manav, > > > > > > > > The draft specifies multiple mechanisms and section 4.2 > > > lists that > > > > all MUST be supported. This doesn't make sense from a vendor > > > > perspective IMO. If "all vendors" have to implement > "all options", > > > > then why not just have 1 option ! > > > > > > > > Having multiple options also leads to inter-op issue among > > > vendors. We > > > > have seen that story with multiple other protocols. > > > > > > > > Thanks > > > > Nitin > > > > > > > > > > > > On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" > > > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > There were some concerns about operational complexity > that using > > > > unicast addresses for micro BFD sessions would entail. We > > > have written > > > > a short draft that alleviates such concerns by suggesting few > > > > mechanisms that nodes can use to auto discover remote > neighbor IP > > > > addresses before establishing micro BFD sessions. > > > > > > > > Would be great if the WG can review and provide feedback on > > > this draft. > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > > > txt > > > > > > > > Cheers, Manav > > > > > > > > -- > > > > > > > > From: internet-drafts@ietf.org > > > > To: i-d-announce@ietf.org > > > > Reply-to: internet-drafts@ietf.org > > > > Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt > > > > X-C5I-RSN: 1/0/935/41368/44754 > > > > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > > > directories. > > > > > > > > Title : IP Address Schemes for Bidirectional Forwarding > Detection > > > > (BFD) on Link Aggregation Group (LAG) Interfaces > > > > Author(s) : Manav Bhatia > > > > Marc Binderberger > > > > Sami Boutros > > > > Nobo Akiya > > > > Filename : draft-mmsn-bfd-on-lags-address-00.txt > > > > Pages : 5 > > > > Date : 2012-02-08 > > > > > > > > This document describes techniques which can be used by > a router > > > > to obtain or discover remote neighbor IP address in order to > > > > establish micro Bidirectional Forwarding Detection > (BFD) sessions > > > [BFD-ON-LAGS]. > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > > > txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > This Internet-Draft can be retrieved at: > > > > > > > > ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00 > > > .t > > > > xt > > > > > > > > _______________________________________________ > > > > I-D-Announce mailing list > > > > I-D-Announce@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > > > > > > > -- > > > Toms. > > > > 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. 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 gregory.mirsky@ericsson.com Fri Feb 10 12:18:33 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 EC19121F88BA for ; Fri, 10 Feb 2012 12:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 F0dMiVQJW-9t for ; Fri, 10 Feb 2012 12:18:31 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8198021F88B7 for ; Fri, 10 Feb 2012 12:18:31 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q1AKIGiW014899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Feb 2012 14:18:19 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.105]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 10 Feb 2012 15:18:15 -0500 From: Gregory Mirsky To: Alexander Vainshtein , "Bhatia, Manav (Manav)" , Mach Chen , Tom Sanders , Nitin Bahadur Date: Fri, 10 Feb 2012 15:18:14 -0500 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: Aczm4BTZKNK9QL1IRoSgcwePoSmyvgASFNfW//+ygwCAAJvUAP//bq/Q//637+D//JixYADbdleo///zHjD//8zLYP//mE4Q Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 10 Feb 2012 20:18:33 -0000 Dear Sasha, AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is optional= . Thus use of Router Alert is not mandated by RFC 5884. What do you think? Regards, Greg -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Friday, February 10, 2012 12:10 PM To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Ba= hadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Dear Greg, RFC 5884 indeed does not explicitly requires any form of Router Alert. However, it uses LSP Ping (RFC 4379) for bootstrapping the BFD sessions - a= nd this, in its turn, uses Router Alert. So I am not sure that reference to RFC 5884 is appropriate either. Did I miss something? Regards, Sasha ________________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Friday, February 10, 2012 8:51 PM To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Ni= tin Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Dear Sasha, Thank you for pointing to RA use in LSP Ping. I agree that reference to RFC= 4379 is not the most appropriate. I think that RFC 5884 is more suitable a= s reference since both address single hop BFD and thus Router Alert is not = required. Regards, Greg -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Friday, February 10, 2012 10:09 AM To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Ba= hadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Dear Greg, Manav and all, I have strong doubts regarding using destination IP address in the 127/8 ra= nge in the initial micro-BFD packets for the peer address discovery. In particular, I think that the reference to LSP Ping (RFC 4379) is incorre= ct, because LSP Ping Echo packets MUST set the Router Alert option in the I= P header (see Section 4.3. "Sending an MPLS Echo Request") in conjunction w= ith using Destination IP address from the 127/8 range. Many IP stacks silently discarded received packets with Destination IP addr= ess in the 127/8 range unless it is accompanied by the Router Alert option.= RFC 1122 and RFC 1812 definitely allow (and even request) that. RFC 4379 has taken care to provide for backward compatibility with these re= quirements. Adding the Router Alert option to the initial packets of the micro-BFD sess= ion could in principle resolve this contradiction but would actually result= in one more step away from reuse (claimed) of existing implementations of= RFC 5881. My 2c, Sasha ________________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of Greg= ory Mirsky [gregory.mirsky@ericsson.com] Sent: Friday, February 10, 2012 7:13 PM To: Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Hi Manav, Then you know where my heart is. It randomly picks from 127/8 range. ;) One= possible disadvantage of using single well-known mcast IP address as DA in= micro-BFD mode, IMO, is that to receipient initial BFD packets (Your Discr= iminator is still zeroed) hard to differentiate, they all are the same but = My Discriminator. Should not be a problem but might cause some issues never= theless. Regards, Greg -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Bhatia, Manav (Manav) Sent: Thursday, February 09, 2012 8:20 PM To: Mach Chen; Tom Sanders; Nitin Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Hi Mach, Yes, the idea is to just retain one mechanism. I know you like multicast! ;-) This is btw exactly the opinion that will be useful in zeroing on a final d= iscovery mechanism. It would be good if others too can chime in with their = thoughts on this. Cheers, Manav > -----Original Message----- > From: Mach Chen [mailto:mach.chen@huawei.com] > Sent: Friday, February 10, 2012 7:54 AM > To: Bhatia, Manav (Manav); Tom Sanders; Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces > > Hi Manav, Toms and all, > > Firstly, I share the concern of Nitin, and agree with Toms's > point: one dynamic remote address learning solution is enough. From=20 > your reply, the authors also intend to keep only one solution, great! > > > Both proposals have their pros and cons and the authors of > the draft > > are not biased towards any particular solution (multicast > or 127/8). > > We would like the members of the WG to reach a consensus on which=20 > > proposal they would like to see going forward (if one has > to be chosen from the two). > > Are there any analysis about the pros and cons? > > I personally prefer Multicast, because: > > 1. For the micro-BFD, we need a well-known Multicast MAC, if use=20 > Multicast for remote address learning, the Multicast MAC can be used=20 > for both remote address and MAC address learning; > > 2. The micro-BFD draft proposes to use unicast IP for L3 connectivity=20 > test, but the member link will be also used for > L3 mulitcast forwarding, so use Multicast for remote address learning=20 > could test the L3 multicast connectivity at least one time; > > 3. On the other hand, if use 127/8, the receiver needs to combine=20 > extra information(e.g., UDP port) to identify the learning message. > > > Best regards, > Mach > > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 > > Behalf Of Bhatia, Manav (Manav) > > Sent: Friday, February 10, 2012 9:24 AM > > To: Tom Sanders; Nitin Bahadur > > Cc: rtg-bfd@ietf.org > > Subject: RE: IP Address Schemes for BFD on LAG interfaces > > > > Hi Toms, > > > > > > > > > > I could be completely off the mark in which case the authors can=20 > > > correct me. But this seemed to me to be the high order bit of the=20 > > > document. > > > > Perfect! What you've said above is absolutely correct. > > > > > > > > Question to the authors: > > > > > > (1) 127/8 seems to be vague. Shouldnt you be specifying > an exact /32 > > > address that should be used? > > > > The idea is to let implementations choose a destination IP address=20 > > randomly from the 127/8 range. This is consistent with what > has been > > described in RFC > > 5884 (BFD for MPLS LSPs). > > > > > > (2) Do you think its wise to float two proposals that vendors can=20 > > > chose. Cant we have just one - either multicast or the > > > 127/8 unicast? > > > Why do we need two proposals? That would imo also address Nitin's=20 > > > concern (which i believe is quite valid). > > > > Both proposals have their pros and cons and the authors of > the draft > > are not biased towards any particular solution (multicast > or 127/8). > > We would like the members of the WG to reach a consensus on which=20 > > proposal they would like to see going forward (if one has > to be chosen from the two). > > > > Hope this helps. > > > > Cheers, Manav > > > > > > > > Toms > > > > > > On 09/02/2012, Nitin Bahadur wrote: > > > > Hi Manav, > > > > > > > > The draft specifies multiple mechanisms and section 4.2 > > > lists that > > > > all MUST be supported. This doesn't make sense from a vendor=20 > > > > perspective IMO. If "all vendors" have to implement > "all options", > > > > then why not just have 1 option ! > > > > > > > > Having multiple options also leads to inter-op issue among > > > vendors. We > > > > have seen that story with multiple other protocols. > > > > > > > > Thanks > > > > Nitin > > > > > > > > > > > > On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" > > > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > There were some concerns about operational complexity > that using > > > > unicast addresses for micro BFD sessions would entail. We > > > have written > > > > a short draft that alleviates such concerns by suggesting few=20 > > > > mechanisms that nodes can use to auto discover remote > neighbor IP > > > > addresses before establishing micro BFD sessions. > > > > > > > > Would be great if the WG can review and provide feedback on > > > this draft. > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > > > txt > > > > > > > > Cheers, Manav > > > > > > > > -- > > > > > > > > From: internet-drafts@ietf.org > > > > To: i-d-announce@ietf.org > > > > Reply-to: internet-drafts@ietf.org > > > > Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt > > > > X-C5I-RSN: 1/0/935/41368/44754 > > > > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > > > directories. > > > > > > > > Title : IP Address Schemes for Bidirectional Forwarding > Detection > > > > (BFD) on Link Aggregation Group (LAG) Interfaces > > > > Author(s) : Manav Bhatia > > > > Marc Binderberger > > > > Sami Boutros > > > > Nobo Akiya > > > > Filename : draft-mmsn-bfd-on-lags-address-00.txt > > > > Pages : 5 > > > > Date : 2012-02-08 > > > > > > > > This document describes techniques which can be used by > a router > > > > to obtain or discover remote neighbor IP address in order to=20 > > > > establish micro Bidirectional Forwarding Detection > (BFD) sessions > > > [BFD-ON-LAGS]. > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > > > txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > This Internet-Draft can be retrieved at: > > > > > > > > ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00 > > > .t > > > > xt > > > > > > > > _______________________________________________ > > > > I-D-Announce mailing list > > > > I-D-Announce@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > > > > > > > -- > > > Toms. > > > > This e-mail message is intended for the recipient only and contains informa= tion 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, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion 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, p= hone or fax, and then delete the original and all copies thereof. From glen.kent@gmail.com Fri Feb 10 13:11:43 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 0AAF521F888F for ; Fri, 10 Feb 2012 13:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Vp6SZe3ouQmO for ; Fri, 10 Feb 2012 13:11:40 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 41DEC21F8887 for ; Fri, 10 Feb 2012 13:11:40 -0800 (PST) Received: by ghbg16 with SMTP id g16so2001043ghb.31 for ; Fri, 10 Feb 2012 13:11:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=sPl3ornCX6jolEgf3u5SDtjhFIoof4FZ+Jq07MdvR0Q=; b=nFQ1Z6ArSy+N6EPMizM/oowaUHjgxxFkx/FvS9M0ZhThjZWo6/ibtme9q20f0+DwEq 9umJV/FEh+KrU4kxaRzuKCXsEq4ICQjL9t+w0CZUWP3frT0K4sEGZh11c3GurqVJ8Mmj vj5OUKzTcM6iwzMjR1TGYmZokeo15Dpvy67I8= MIME-Version: 1.0 Received: by 10.50.208.1 with SMTP id ma1mr16527325igc.4.1328908284207; Fri, 10 Feb 2012 13:11:24 -0800 (PST) Received: by 10.43.44.66 with HTTP; Fri, 10 Feb 2012 13:11:24 -0800 (PST) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Sat, 11 Feb 2012 02:41:24 +0530 Message-ID: Subject: Re: IP Address Schemes for BFD on LAG interfaces From: Glen Kent To: "Bhatia, Manav (Manav)" , rtg-bfd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 21:11:43 -0000 Hi Manav, I like the idea of discovery since manual configuration is not possible in all deployments. I would prefer multicast since other discovery protocols use multicast. I also find it rather unnatural to see 127/8 range out on the wire. Ideally, this should never exit the box. RFC 5735 says the following about 127/8 - "As described in [RFC1122], Section 3.2.1.3, addresses within the entire 127.0.0.0/8 block do not legitimately appear on any network anywhere." Glen On Fri, Feb 10, 2012 at 9:50 AM, Bhatia, Manav (Manav) wrote: > Hi Mach, > > Yes, the idea is to just retain one mechanism. > > I know you like multicast! ;-) > > This is btw exactly the opinion that will be useful in zeroing on a final= discovery mechanism. It would be good if others too can chime in with thei= r thoughts on this. > > Cheers, Manav > >> -----Original Message----- >> From: Mach Chen [mailto:mach.chen@huawei.com] >> Sent: Friday, February 10, 2012 7:54 AM >> To: Bhatia, Manav (Manav); Tom Sanders; Nitin Bahadur >> Cc: rtg-bfd@ietf.org >> Subject: RE: IP Address Schemes for BFD on LAG interfaces >> >> Hi Manav, Toms and all, >> >> Firstly, I share the concern of Nitin, and agree with Toms's >> point: one dynamic remote address learning solution is >> enough. From your reply, the authors also intend to keep only >> one solution, great! >> >> > Both proposals have their pros and cons and the authors of >> the draft >> > are not biased towards any particular solution (multicast >> or 127/8). >> > We would like the members of the WG to reach a consensus on which >> > proposal they would like to see going forward (if one has >> to be chosen from the two). >> >> Are there any analysis about the pros and cons? >> >> I personally prefer Multicast, because: >> >> 1. For the micro-BFD, we need a well-known Multicast MAC, if >> use Multicast for remote address learning, the Multicast MAC >> can be used for both remote address and MAC address learning; >> >> 2. The micro-BFD draft proposes to use unicast IP for L3 >> connectivity test, but the member link will be also used for >> L3 mulitcast forwarding, so use Multicast for remote address >> learning could test the L3 multicast connectivity at least one time; >> >> 3. On the other hand, if use 127/8, the receiver needs to >> combine extra information(e.g., UDP port) to identify the >> learning message. >> >> >> Best regards, >> Mach >> >> > -----Original Message----- >> > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On >> > Behalf Of Bhatia, Manav (Manav) >> > Sent: Friday, February 10, 2012 9:24 AM >> > To: Tom Sanders; Nitin Bahadur >> > Cc: rtg-bfd@ietf.org >> > Subject: RE: IP Address Schemes for BFD on LAG interfaces >> > >> > Hi Toms, >> > >> > >> > > >> > > I could be completely off the mark in which case the authors can >> > > correct me. But this seemed to me to be the high order bit of the >> > > document. >> > >> > Perfect! What you've said above is absolutely correct. >> > >> > > >> > > Question to the authors: >> > > >> > > (1) 127/8 seems to be vague. Shouldnt you be specifying >> an exact /32 >> > > address that should be used? >> > >> > The idea is to let implementations choose a destination IP address >> > randomly from the 127/8 range. This is consistent with what >> has been >> > described in RFC >> > 5884 (BFD for MPLS LSPs). >> > > >> > > (2) Do you think its wise to float two proposals that vendors can >> > > chose. Cant we have just one - either multicast or the >> > > 127/8 unicast? >> > > Why do we need two proposals? That would imo also address Nitin's >> > > concern (which i believe is quite valid). >> > >> > Both proposals have their pros and cons and the authors of >> the draft >> > are not biased towards any particular solution (multicast >> or 127/8). >> > We would like the members of the WG to reach a consensus on which >> > proposal they would like to see going forward (if one has >> to be chosen from the two). >> > >> > Hope this helps. >> > >> > Cheers, Manav >> > >> > > >> > > Toms >> > > >> > > On 09/02/2012, Nitin Bahadur wrote: >> > > > Hi Manav, >> > > > >> > > > =A0 The draft specifies multiple mechanisms and section 4.2 >> > > lists that >> > > > all MUST be supported. This doesn't make sense from a vendor >> > > > perspective IMO. If "all vendors" have to implement >> "all options", >> > > > then why not just have 1 option ! >> > > > >> > > > Having multiple options also leads to inter-op issue among >> > > vendors. We >> > > > have seen that story with multiple other protocols. >> > > > >> > > > Thanks >> > > > Nitin >> > > > >> > > > >> > > > On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" >> > > > >> > > > wrote: >> > > > >> > > > Hi, >> > > > >> > > > There were some concerns about operational complexity >> that using >> > > > unicast addresses for micro BFD sessions would entail. We >> > > have written >> > > > a short draft that alleviates such concerns by suggesting few >> > > > mechanisms that nodes can use to auto discover remote >> neighbor IP >> > > > addresses before establishing micro BFD sessions. >> > > > >> > > > Would be great if the WG can review and provide feedback on >> > > this draft. >> > > > >> > > > The URL for this Internet-Draft is: >> > > > >> > > >> http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. >> > > > txt >> > > > >> > > > Cheers, Manav >> > > > >> > > > -- >> > > > >> > > > From: internet-drafts@ietf.org >> > > > To: i-d-announce@ietf.org >> > > > Reply-to: internet-drafts@ietf.org >> > > > Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt >> > > > X-C5I-RSN: 1/0/935/41368/44754 >> > > > >> > > > A New Internet-Draft is available from the on-line >> Internet-Drafts >> > > > directories. >> > > > >> > > > Title : IP Address Schemes for Bidirectional Forwarding >> Detection >> > > > (BFD) on Link Aggregation Group (LAG) Interfaces >> > > > Author(s) : Manav Bhatia >> > > > Marc Binderberger >> > > > Sami Boutros >> > > > Nobo Akiya >> > > > Filename : draft-mmsn-bfd-on-lags-address-00.txt >> > > > Pages : 5 >> > > > Date : 2012-02-08 >> > > > >> > > > This document describes techniques which can be used by >> a router >> > > > to obtain or discover remote neighbor IP address in order to >> > > > establish micro Bidirectional Forwarding Detection >> (BFD) sessions >> > > [BFD-ON-LAGS]. >> > > > >> > > > >> > > > >> > > > A URL for this Internet-Draft is: >> > > > >> > > >> http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. >> > > > txt >> > > > >> > > > Internet-Drafts are also available by anonymous FTP at: >> > > > ftp://ftp.ietf.org/internet-drafts/ >> > > > >> > > > This Internet-Draft can be retrieved at: >> > > > >> > > >> ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00 >> > > .t >> > > > xt >> > > > >> > > > _______________________________________________ >> > > > I-D-Announce mailing list >> > > > I-D-Announce@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/i-d-announce >> > > > Internet-Draft directories: http://www.ietf.org/shadow.html or >> > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > > >> > > > >> > > > >> > > >> > > >> > > -- >> > > Toms. >> > > >> From gregory.mirsky@ericsson.com Fri Feb 10 13:35:41 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 64FC121F8510 for ; Fri, 10 Feb 2012 13:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 7juRz7aCdGnA for ; Fri, 10 Feb 2012 13:35:40 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 38E6021F850F for ; Fri, 10 Feb 2012 13:35:40 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q1ALZZVX002724; Fri, 10 Feb 2012 15:35:36 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.105]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 10 Feb 2012 16:35:28 -0500 From: Gregory Mirsky To: Glen Kent , "Bhatia, Manav (Manav)" , "rtg-bfd@ietf.org" Date: Fri, 10 Feb 2012 16:35:27 -0500 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: AczoOJ0MZvKYE+JHRhe5I/5F7ulvuAAAX3iw Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" 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: Fri, 10 Feb 2012 21:35:41 -0000 =20 Hi Kent, I believe that 127/8 addresses do not require manual configuration and auto= -discovery support because they are randomly selected as DA by the sender a= nd not checked by the reciever. RE: sending 127/8 on the wire. Since we're to use IP over Ethernet EtherTyp= e, formally 127/8 is on the wire as IP DA. But I'd note that RFC 1112 defin= es host behavior whereas RFC 1812 requires not to forward (by default) pack= ets with destination address on 127/8 network. Thus we guaranteed that micr= o-BFD packets would not be leaked by far-end node. Regards, Greg -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Glen Kent Sent: Friday, February 10, 2012 1:11 PM To: Bhatia, Manav (Manav); rtg-bfd@ietf.org Subject: Re: IP Address Schemes for BFD on LAG interfaces Hi Manav, I like the idea of discovery since manual configuration is not possible in = all deployments. I would prefer multicast since other discovery protocols use multicast. I a= lso find it rather unnatural to see 127/8 range out on the wire. Ideally, t= his should never exit the box. RFC 5735 says the following about 127/8 - "A= s described in [RFC1122], Section 3.2.1.3, addresses within the entire 127.= 0.0.0/8 block do not legitimately appear on any network anywhere." Glen On Fri, Feb 10, 2012 at 9:50 AM, Bhatia, Manav (Manav) wrote: > Hi Mach, > > Yes, the idea is to just retain one mechanism. > > I know you like multicast! ;-) > > This is btw exactly the opinion that will be useful in zeroing on a final= discovery mechanism. It would be good if others too can chime in with thei= r thoughts on this. > > Cheers, Manav > >> -----Original Message----- >> From: Mach Chen [mailto:mach.chen@huawei.com] >> Sent: Friday, February 10, 2012 7:54 AM >> To: Bhatia, Manav (Manav); Tom Sanders; Nitin Bahadur >> Cc: rtg-bfd@ietf.org >> Subject: RE: IP Address Schemes for BFD on LAG interfaces >> >> Hi Manav, Toms and all, >> >> Firstly, I share the concern of Nitin, and agree with Toms's >> point: one dynamic remote address learning solution is enough. From=20 >> your reply, the authors also intend to keep only one solution, great! >> >> > Both proposals have their pros and cons and the authors of >> the draft >> > are not biased towards any particular solution (multicast >> or 127/8). >> > We would like the members of the WG to reach a consensus on which=20 >> > proposal they would like to see going forward (if one has >> to be chosen from the two). >> >> Are there any analysis about the pros and cons? >> >> I personally prefer Multicast, because: >> >> 1. For the micro-BFD, we need a well-known Multicast MAC, if use=20 >> Multicast for remote address learning, the Multicast MAC can be used=20 >> for both remote address and MAC address learning; >> >> 2. The micro-BFD draft proposes to use unicast IP for L3 connectivity=20 >> test, but the member link will be also used for >> L3 mulitcast forwarding, so use Multicast for remote address learning=20 >> could test the L3 multicast connectivity at least one time; >> >> 3. On the other hand, if use 127/8, the receiver needs to combine=20 >> extra information(e.g., UDP port) to identify the learning message. >> >> >> Best regards, >> Mach >> >> > -----Original Message----- >> > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 >> > Behalf Of Bhatia, Manav (Manav) >> > Sent: Friday, February 10, 2012 9:24 AM >> > To: Tom Sanders; Nitin Bahadur >> > Cc: rtg-bfd@ietf.org >> > Subject: RE: IP Address Schemes for BFD on LAG interfaces >> > >> > Hi Toms, >> > >> > >> > > >> > > I could be completely off the mark in which case the authors can=20 >> > > correct me. But this seemed to me to be the high order bit of the=20 >> > > document. >> > >> > Perfect! What you've said above is absolutely correct. >> > >> > > >> > > Question to the authors: >> > > >> > > (1) 127/8 seems to be vague. Shouldnt you be specifying >> an exact /32 >> > > address that should be used? >> > >> > The idea is to let implementations choose a destination IP address=20 >> > randomly from the 127/8 range. This is consistent with what >> has been >> > described in RFC >> > 5884 (BFD for MPLS LSPs). >> > > >> > > (2) Do you think its wise to float two proposals that vendors can=20 >> > > chose. Cant we have just one - either multicast or the >> > > 127/8 unicast? >> > > Why do we need two proposals? That would imo also address Nitin's=20 >> > > concern (which i believe is quite valid). >> > >> > Both proposals have their pros and cons and the authors of >> the draft >> > are not biased towards any particular solution (multicast >> or 127/8). >> > We would like the members of the WG to reach a consensus on which=20 >> > proposal they would like to see going forward (if one has >> to be chosen from the two). >> > >> > Hope this helps. >> > >> > Cheers, Manav >> > >> > > >> > > Toms >> > > >> > > On 09/02/2012, Nitin Bahadur wrote: >> > > > Hi Manav, >> > > > >> > > > =A0 The draft specifies multiple mechanisms and section 4.2 >> > > lists that >> > > > all MUST be supported. This doesn't make sense from a vendor=20 >> > > > perspective IMO. If "all vendors" have to implement >> "all options", >> > > > then why not just have 1 option ! >> > > > >> > > > Having multiple options also leads to inter-op issue among >> > > vendors. We >> > > > have seen that story with multiple other protocols. >> > > > >> > > > Thanks >> > > > Nitin >> > > > >> > > > >> > > > On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" >> > > > >> > > > wrote: >> > > > >> > > > Hi, >> > > > >> > > > There were some concerns about operational complexity >> that using >> > > > unicast addresses for micro BFD sessions would entail. We >> > > have written >> > > > a short draft that alleviates such concerns by suggesting few=20 >> > > > mechanisms that nodes can use to auto discover remote >> neighbor IP >> > > > addresses before establishing micro BFD sessions. >> > > > >> > > > Would be great if the WG can review and provide feedback on >> > > this draft. >> > > > >> > > > The URL for this Internet-Draft is: >> > > > >> > > >> http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. >> > > > txt >> > > > >> > > > Cheers, Manav >> > > > >> > > > -- >> > > > >> > > > From: internet-drafts@ietf.org >> > > > To: i-d-announce@ietf.org >> > > > Reply-to: internet-drafts@ietf.org >> > > > Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt >> > > > X-C5I-RSN: 1/0/935/41368/44754 >> > > > >> > > > A New Internet-Draft is available from the on-line >> Internet-Drafts >> > > > directories. >> > > > >> > > > Title : IP Address Schemes for Bidirectional Forwarding >> Detection >> > > > (BFD) on Link Aggregation Group (LAG) Interfaces >> > > > Author(s) : Manav Bhatia >> > > > Marc Binderberger >> > > > Sami Boutros >> > > > Nobo Akiya >> > > > Filename : draft-mmsn-bfd-on-lags-address-00.txt >> > > > Pages : 5 >> > > > Date : 2012-02-08 >> > > > >> > > > This document describes techniques which can be used by >> a router >> > > > to obtain or discover remote neighbor IP address in order to=20 >> > > > establish micro Bidirectional Forwarding Detection >> (BFD) sessions >> > > [BFD-ON-LAGS]. >> > > > >> > > > >> > > > >> > > > A URL for this Internet-Draft is: >> > > > >> > > >> http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. >> > > > txt >> > > > >> > > > Internet-Drafts are also available by anonymous FTP at: >> > > > ftp://ftp.ietf.org/internet-drafts/ >> > > > >> > > > This Internet-Draft can be retrieved at: >> > > > >> > > >> ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00 >> > > .t >> > > > xt >> > > > >> > > > _______________________________________________ >> > > > I-D-Announce mailing list >> > > > I-D-Announce@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/i-d-announce >> > > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >> > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > > >> > > > >> > > > >> > > >> > > >> > > -- >> > > Toms. >> > > >> From marc@sniff.de Fri Feb 10 14:24:37 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5A121F860B for ; Fri, 10 Feb 2012 14:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 En4RxqgiLg-Y for ; Fri, 10 Feb 2012 14:24:36 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5633A21F8635 for ; Fri, 10 Feb 2012 14:24:35 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 9176A2AA0F; Fri, 10 Feb 2012 22:24:15 +0000 (GMT) Subject: Re: IP Address Schemes for BFD on LAG interfaces Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Fri, 10 Feb 2012 23:24:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <51C80FCE-D3FC-4D51-9E67-2EAD5670EDF2@sniff.de> References: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com>, , To: Tom Sanders , Alexander Vainshtein , Gregory Mirsky 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: Fri, 10 Feb 2012 22:24:37 -0000 Hello Greg, Alexander et al., well, Alexander has some point. RFC5884 gets away IMHO because the IP = TTL must be "1". And in case of multiple labels for the LSP it states in = section 7 [...] If the label stack has a depth greater than one, the TTL of the inner MPLS label MAY be set to 1. This may be necessary for certain FECs to enable the egress LSR's control plane to receive the packet [RFC4379]. So I think RFC5884 uses the TTL method to ensure the packet gets punted = up to the control plane. ("I think" as the last paragraph of section 4 has some vagueness which I = decided to ignore when implementing but meanwhile I wonder ...). Back to the Address Scheme, you mentioned in you earlier email: "One possible disadvantage of using single well-known mcast IP address = as DA in micro-BFD mode, IMO, is that to receipient initial BFD packets = (Your Discriminator is still zeroed) hard to differentiate, they all are = the same but My Discriminator. Should not be a problem but might cause = some issues nevertheless." The micro-session draft requires the use of "interface information of = the member link" to demultiplex the initial micro-session BFD packets. I = also don't see how a randomly chosen address out of 127/8 can help the = receiver side to do a meaningful differentiation (?). (not against the random choice although Tom mentioned in another email = that one could simply chose a fixed address out of 127/8 if that range = is to be used) Anyway, this is a good discussion :-) Regards, Marc On 2012-02-10, at 21:18 , Gregory Mirsky wrote: > Dear Sasha, > AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is = optional. Thus use of Router Alert is not mandated by RFC 5884. >=20 > What do you think? >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20= > Sent: Friday, February 10, 2012 12:10 PM > To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; = Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces >=20 > Dear Greg, > RFC 5884 indeed does not explicitly requires any form of Router Alert. > However, it uses LSP Ping (RFC 4379) for bootstrapping the BFD = sessions - and this, in its turn, uses Router Alert. >=20 > So I am not sure that reference to RFC 5884 is appropriate either. >=20 > Did I miss something? >=20 > Regards, > Sasha >=20 >=20 >=20 > ________________________________________ > From: Gregory Mirsky [gregory.mirsky@ericsson.com] > Sent: Friday, February 10, 2012 8:51 PM > To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen; Tom = Sanders; Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces >=20 > Dear Sasha, > Thank you for pointing to RA use in LSP Ping. I agree that reference = to RFC 4379 is not the most appropriate. I think that RFC 5884 is more = suitable as reference since both address single hop BFD and thus Router = Alert is not required. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Friday, February 10, 2012 10:09 AM > To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; = Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces >=20 > Dear Greg, Manav and all, >=20 > I have strong doubts regarding using destination IP address in the = 127/8 range in the initial micro-BFD packets for the peer address = discovery. >=20 > In particular, I think that the reference to LSP Ping (RFC 4379) is = incorrect, because LSP Ping Echo packets MUST set the Router Alert = option in the IP header (see Section 4.3. "Sending an MPLS Echo = Request") in conjunction with using Destination IP address from the = 127/8 range. >=20 > Many IP stacks silently discarded received packets with Destination IP = address in the 127/8 range unless it is accompanied by the Router Alert = option. RFC 1122 and RFC 1812 definitely allow (and even request) that. > RFC 4379 has taken care to provide for backward compatibility with = these requirements. >=20 > Adding the Router Alert option to the initial packets of the micro-BFD = session could in principle resolve this contradiction but would actually = result in one more step away from reuse (claimed) of existing = implementations of RFC 5881. >=20 > My 2c, > Sasha >=20 >=20 >=20 > ________________________________________ > From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of = Gregory Mirsky [gregory.mirsky@ericsson.com] > Sent: Friday, February 10, 2012 7:13 PM > To: Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces >=20 > Hi Manav, > Then you know where my heart is. It randomly picks from 127/8 range. = ;) One possible disadvantage of using single well-known mcast IP address = as DA in micro-BFD mode, IMO, is that to receipient initial BFD packets = (Your Discriminator is still zeroed) hard to differentiate, they all are = the same but My Discriminator. Should not be a problem but might cause = some issues nevertheless. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Bhatia, Manav (Manav) > Sent: Thursday, February 09, 2012 8:20 PM > To: Mach Chen; Tom Sanders; Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces >=20 > Hi Mach, >=20 > Yes, the idea is to just retain one mechanism. >=20 > I know you like multicast! ;-) >=20 > This is btw exactly the opinion that will be useful in zeroing on a = final discovery mechanism. It would be good if others too can chime in = with their thoughts on this. >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: Mach Chen [mailto:mach.chen@huawei.com] >> Sent: Friday, February 10, 2012 7:54 AM >> To: Bhatia, Manav (Manav); Tom Sanders; Nitin Bahadur >> Cc: rtg-bfd@ietf.org >> Subject: RE: IP Address Schemes for BFD on LAG interfaces >>=20 >> Hi Manav, Toms and all, >>=20 >> Firstly, I share the concern of Nitin, and agree with Toms's >> point: one dynamic remote address learning solution is enough. =46rom=20= >> your reply, the authors also intend to keep only one solution, great! >>=20 >>> Both proposals have their pros and cons and the authors of >> the draft >>> are not biased towards any particular solution (multicast >> or 127/8). >>> We would like the members of the WG to reach a consensus on which=20 >>> proposal they would like to see going forward (if one has >> to be chosen from the two). >>=20 >> Are there any analysis about the pros and cons? >>=20 >> I personally prefer Multicast, because: >>=20 >> 1. For the micro-BFD, we need a well-known Multicast MAC, if use=20 >> Multicast for remote address learning, the Multicast MAC can be used=20= >> for both remote address and MAC address learning; >>=20 >> 2. The micro-BFD draft proposes to use unicast IP for L3 connectivity=20= >> test, but the member link will be also used for >> L3 mulitcast forwarding, so use Multicast for remote address learning=20= >> could test the L3 multicast connectivity at least one time; >>=20 >> 3. On the other hand, if use 127/8, the receiver needs to combine=20 >> extra information(e.g., UDP port) to identify the learning message. >>=20 >>=20 >> Best regards, >> Mach >>=20 >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20= >>> Behalf Of Bhatia, Manav (Manav) >>> Sent: Friday, February 10, 2012 9:24 AM >>> To: Tom Sanders; Nitin Bahadur >>> Cc: rtg-bfd@ietf.org >>> Subject: RE: IP Address Schemes for BFD on LAG interfaces >>>=20 >>> Hi Toms, >>>=20 >>>=20 >>>>=20 >>>> I could be completely off the mark in which case the authors can=20 >>>> correct me. But this seemed to me to be the high order bit of the=20= >>>> document. >>>=20 >>> Perfect! What you've said above is absolutely correct. >>>=20 >>>>=20 >>>> Question to the authors: >>>>=20 >>>> (1) 127/8 seems to be vague. Shouldnt you be specifying >> an exact /32 >>>> address that should be used? >>>=20 >>> The idea is to let implementations choose a destination IP address=20= >>> randomly from the 127/8 range. This is consistent with what >> has been >>> described in RFC >>> 5884 (BFD for MPLS LSPs). >>>>=20 >>>> (2) Do you think its wise to float two proposals that vendors can=20= >>>> chose. Cant we have just one - either multicast or the >>>> 127/8 unicast? >>>> Why do we need two proposals? That would imo also address Nitin's=20= >>>> concern (which i believe is quite valid). >>>=20 >>> Both proposals have their pros and cons and the authors of >> the draft >>> are not biased towards any particular solution (multicast >> or 127/8). >>> We would like the members of the WG to reach a consensus on which=20 >>> proposal they would like to see going forward (if one has >> to be chosen from the two). >>>=20 >>> Hope this helps. >>>=20 >>> Cheers, Manav >>>=20 >>>>=20 >>>> Toms >>>>=20 >>>> On 09/02/2012, Nitin Bahadur wrote: >>>>> Hi Manav, >>>>>=20 >>>>> The draft specifies multiple mechanisms and section 4.2 >>>> lists that >>>>> all MUST be supported. This doesn't make sense from a vendor=20 >>>>> perspective IMO. If "all vendors" have to implement >> "all options", >>>>> then why not just have 1 option ! >>>>>=20 >>>>> Having multiple options also leads to inter-op issue among >>>> vendors. We >>>>> have seen that story with multiple other protocols. >>>>>=20 >>>>> Thanks >>>>> Nitin >>>>>=20 >>>>>=20 >>>>> On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" >>>>> >>>>> wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> There were some concerns about operational complexity >> that using >>>>> unicast addresses for micro BFD sessions would entail. We >>>> have written >>>>> a short draft that alleviates such concerns by suggesting few=20 >>>>> mechanisms that nodes can use to auto discover remote >> neighbor IP >>>>> addresses before establishing micro BFD sessions. >>>>>=20 >>>>> Would be great if the WG can review and provide feedback on >>>> this draft. >>>>>=20 >>>>> The URL for this Internet-Draft is: >>>>>=20 >>>>=20 >> = http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. >>>>> txt >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>> -- >>>>>=20 >>>>> From: internet-drafts@ietf.org >>>>> To: i-d-announce@ietf.org >>>>> Reply-to: internet-drafts@ietf.org >>>>> Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt >>>>> X-C5I-RSN: 1/0/935/41368/44754 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line >> Internet-Drafts >>>>> directories. >>>>>=20 >>>>> Title : IP Address Schemes for Bidirectional Forwarding >> Detection >>>>> (BFD) on Link Aggregation Group (LAG) Interfaces >>>>> Author(s) : Manav Bhatia >>>>> Marc Binderberger >>>>> Sami Boutros >>>>> Nobo Akiya >>>>> Filename : draft-mmsn-bfd-on-lags-address-00.txt >>>>> Pages : 5 >>>>> Date : 2012-02-08 >>>>>=20 >>>>> This document describes techniques which can be used by >> a router >>>>> to obtain or discover remote neighbor IP address in order to=20 >>>>> establish micro Bidirectional Forwarding Detection >> (BFD) sessions >>>> [BFD-ON-LAGS]. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> A URL for this Internet-Draft is: >>>>>=20 >>>>=20 >> = http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. >>>>> txt >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> This Internet-Draft can be retrieved at: >>>>>=20 >>>>=20 >> ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00 >>>> .t >>>>> xt >>>>>=20 >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Toms. >>>>=20 >>=20 >=20 > 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 > 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 gregory.mirsky@ericsson.com Fri Feb 10 14:43:36 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B2321F84EF for ; Fri, 10 Feb 2012 14:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 0lIqiqPT5zcc for ; Fri, 10 Feb 2012 14:43:34 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE2521F84EB for ; Fri, 10 Feb 2012 14:43:34 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q1AMhI4k013216; Fri, 10 Feb 2012 16:43:20 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.105]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 10 Feb 2012 17:43:13 -0500 From: Gregory Mirsky To: Marc Binderberger , Tom Sanders , Alexander Vainshtein Date: Fri, 10 Feb 2012 17:43:11 -0500 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: AczoQr5v38hEAAZaTV+YqnnuAOSw0gAAITrQ Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com>, , <51C80FCE-D3FC-4D51-9E67-2EAD5670EDF2@sniff.de> In-Reply-To: <51C80FCE-D3FC-4D51-9E67-2EAD5670EDF2@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 10 Feb 2012 22:43:36 -0000 Hi Marc, I believe that regardless of addressing method IP TTL in micro-BFD must be = set to 1 because it is single-hop BFD. And RFC 5884 does that for the same = reason - LSP is a single hop segment, a link. Setting MPLS TTL to expire is= , in a way, similar to VCCV Control Channel Type 3 that uses TTL expiration= . Ethernet doesn't have TTL field and there might be existing equipment tha= t would drop 127/8 addressed IP packets and micro-BFD would not work. But t= he same would be the case if multicast addressing with new well-known addre= ss partially deployed. Regards, Greg -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de]=20 Sent: Friday, February 10, 2012 2:24 PM To: Tom Sanders; Alexander Vainshtein; Gregory Mirsky Cc: Bhatia, Manav (Manav); Mach Chen; Nitin Bahadur; rtg-bfd@ietf.org Subject: Re: IP Address Schemes for BFD on LAG interfaces Hello Greg, Alexander et al., well, Alexander has some point. RFC5884 gets away IMHO because the IP TTL m= ust be "1". And in case of multiple labels for the LSP it states in section= 7 [...] If the label stack has a depth greater than one, the TTL of the inner MPLS label MAY be set to 1. This may be necessary for certain FECs to enable the egress LSR's control plane to receive the packet [RFC4379]. So I think RFC5884 uses the TTL method to ensure the packet gets punted up = to the control plane. ("I think" as the last paragraph of section 4 has some vagueness which I de= cided to ignore when implementing but meanwhile I wonder ...). Back to the Address Scheme, you mentioned in you earlier email: "One possible disadvantage of using single well-known mcast IP address as D= A in micro-BFD mode, IMO, is that to receipient initial BFD packets (Your D= iscriminator is still zeroed) hard to differentiate, they all are the same = but My Discriminator. Should not be a problem but might cause some issues n= evertheless." The micro-session draft requires the use of "interface information of the m= ember link" to demultiplex the initial micro-session BFD packets. I also do= n't see how a randomly chosen address out of 127/8 can help the receiver si= de to do a meaningful differentiation (?). (not against the random choice although Tom mentioned in another email that= one could simply chose a fixed address out of 127/8 if that range is to be= used) Anyway, this is a good discussion :-) Regards, Marc On 2012-02-10, at 21:18 , Gregory Mirsky wrote: > Dear Sasha, > AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is option= al. Thus use of Router Alert is not mandated by RFC 5884. >=20 > What do you think? >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Friday, February 10, 2012 12:10 PM > To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders;=20 > Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces >=20 > Dear Greg, > RFC 5884 indeed does not explicitly requires any form of Router Alert. > However, it uses LSP Ping (RFC 4379) for bootstrapping the BFD sessions -= and this, in its turn, uses Router Alert. >=20 > So I am not sure that reference to RFC 5884 is appropriate either. >=20 > Did I miss something? >=20 > Regards, > Sasha >=20 >=20 >=20 > ________________________________________ > From: Gregory Mirsky [gregory.mirsky@ericsson.com] > Sent: Friday, February 10, 2012 8:51 PM > To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen; Tom=20 > Sanders; Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces >=20 > Dear Sasha, > Thank you for pointing to RA use in LSP Ping. I agree that reference to R= FC 4379 is not the most appropriate. I think that RFC 5884 is more suitable= as reference since both address single hop BFD and thus Router Alert is no= t required. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Friday, February 10, 2012 10:09 AM > To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders;=20 > Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces >=20 > Dear Greg, Manav and all, >=20 > I have strong doubts regarding using destination IP address in the 127/8 = range in the initial micro-BFD packets for the peer address discovery. >=20 > In particular, I think that the reference to LSP Ping (RFC 4379) is incor= rect, because LSP Ping Echo packets MUST set the Router Alert option in the= IP header (see Section 4.3. "Sending an MPLS Echo Request") in conjunction= with using Destination IP address from the 127/8 range. >=20 > Many IP stacks silently discarded received packets with Destination IP ad= dress in the 127/8 range unless it is accompanied by the Router Alert optio= n. RFC 1122 and RFC 1812 definitely allow (and even request) that. > RFC 4379 has taken care to provide for backward compatibility with these = requirements. >=20 > Adding the Router Alert option to the initial packets of the micro-BFD se= ssion could in principle resolve this contradiction but would actually resu= lt in one more step away from reuse (claimed) of existing implementations = of RFC 5881. >=20 > My 2c, > Sasha >=20 >=20 >=20 > ________________________________________ > From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of=20 > Gregory Mirsky [gregory.mirsky@ericsson.com] > Sent: Friday, February 10, 2012 7:13 PM > To: Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces >=20 > Hi Manav, > Then you know where my heart is. It randomly picks from 127/8 range. ;) O= ne possible disadvantage of using single well-known mcast IP address as DA = in micro-BFD mode, IMO, is that to receipient initial BFD packets (Your Dis= criminator is still zeroed) hard to differentiate, they all are the same bu= t My Discriminator. Should not be a problem but might cause some issues nev= ertheless. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 > Behalf Of Bhatia, Manav (Manav) > Sent: Thursday, February 09, 2012 8:20 PM > To: Mach Chen; Tom Sanders; Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces >=20 > Hi Mach, >=20 > Yes, the idea is to just retain one mechanism. >=20 > I know you like multicast! ;-) >=20 > This is btw exactly the opinion that will be useful in zeroing on a final= discovery mechanism. It would be good if others too can chime in with thei= r thoughts on this. >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: Mach Chen [mailto:mach.chen@huawei.com] >> Sent: Friday, February 10, 2012 7:54 AM >> To: Bhatia, Manav (Manav); Tom Sanders; Nitin Bahadur >> Cc: rtg-bfd@ietf.org >> Subject: RE: IP Address Schemes for BFD on LAG interfaces >>=20 >> Hi Manav, Toms and all, >>=20 >> Firstly, I share the concern of Nitin, and agree with Toms's >> point: one dynamic remote address learning solution is enough. From=20 >> your reply, the authors also intend to keep only one solution, great! >>=20 >>> Both proposals have their pros and cons and the authors of >> the draft >>> are not biased towards any particular solution (multicast >> or 127/8). >>> We would like the members of the WG to reach a consensus on which=20 >>> proposal they would like to see going forward (if one has >> to be chosen from the two). >>=20 >> Are there any analysis about the pros and cons? >>=20 >> I personally prefer Multicast, because: >>=20 >> 1. For the micro-BFD, we need a well-known Multicast MAC, if use=20 >> Multicast for remote address learning, the Multicast MAC can be used=20 >> for both remote address and MAC address learning; >>=20 >> 2. The micro-BFD draft proposes to use unicast IP for L3 connectivity=20 >> test, but the member link will be also used for >> L3 mulitcast forwarding, so use Multicast for remote address learning=20 >> could test the L3 multicast connectivity at least one time; >>=20 >> 3. On the other hand, if use 127/8, the receiver needs to combine=20 >> extra information(e.g., UDP port) to identify the learning message. >>=20 >>=20 >> Best regards, >> Mach >>=20 >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 >>> Behalf Of Bhatia, Manav (Manav) >>> Sent: Friday, February 10, 2012 9:24 AM >>> To: Tom Sanders; Nitin Bahadur >>> Cc: rtg-bfd@ietf.org >>> Subject: RE: IP Address Schemes for BFD on LAG interfaces >>>=20 >>> Hi Toms, >>>=20 >>>=20 >>>>=20 >>>> I could be completely off the mark in which case the authors can=20 >>>> correct me. But this seemed to me to be the high order bit of the=20 >>>> document. >>>=20 >>> Perfect! What you've said above is absolutely correct. >>>=20 >>>>=20 >>>> Question to the authors: >>>>=20 >>>> (1) 127/8 seems to be vague. Shouldnt you be specifying >> an exact /32 >>>> address that should be used? >>>=20 >>> The idea is to let implementations choose a destination IP address=20 >>> randomly from the 127/8 range. This is consistent with what >> has been >>> described in RFC >>> 5884 (BFD for MPLS LSPs). >>>>=20 >>>> (2) Do you think its wise to float two proposals that vendors can=20 >>>> chose. Cant we have just one - either multicast or the >>>> 127/8 unicast? >>>> Why do we need two proposals? That would imo also address Nitin's=20 >>>> concern (which i believe is quite valid). >>>=20 >>> Both proposals have their pros and cons and the authors of >> the draft >>> are not biased towards any particular solution (multicast >> or 127/8). >>> We would like the members of the WG to reach a consensus on which=20 >>> proposal they would like to see going forward (if one has >> to be chosen from the two). >>>=20 >>> Hope this helps. >>>=20 >>> Cheers, Manav >>>=20 >>>>=20 >>>> Toms >>>>=20 >>>> On 09/02/2012, Nitin Bahadur wrote: >>>>> Hi Manav, >>>>>=20 >>>>> The draft specifies multiple mechanisms and section 4.2 >>>> lists that >>>>> all MUST be supported. This doesn't make sense from a vendor=20 >>>>> perspective IMO. If "all vendors" have to implement >> "all options", >>>>> then why not just have 1 option ! >>>>>=20 >>>>> Having multiple options also leads to inter-op issue among >>>> vendors. We >>>>> have seen that story with multiple other protocols. >>>>>=20 >>>>> Thanks >>>>> Nitin >>>>>=20 >>>>>=20 >>>>> On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" >>>>> >>>>> wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> There were some concerns about operational complexity >> that using >>>>> unicast addresses for micro BFD sessions would entail. We >>>> have written >>>>> a short draft that alleviates such concerns by suggesting few=20 >>>>> mechanisms that nodes can use to auto discover remote >> neighbor IP >>>>> addresses before establishing micro BFD sessions. >>>>>=20 >>>>> Would be great if the WG can review and provide feedback on >>>> this draft. >>>>>=20 >>>>> The URL for this Internet-Draft is: >>>>>=20 >>>>=20 >> http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. >>>>> txt >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>> -- >>>>>=20 >>>>> From: internet-drafts@ietf.org >>>>> To: i-d-announce@ietf.org >>>>> Reply-to: internet-drafts@ietf.org >>>>> Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt >>>>> X-C5I-RSN: 1/0/935/41368/44754 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line >> Internet-Drafts >>>>> directories. >>>>>=20 >>>>> Title : IP Address Schemes for Bidirectional Forwarding >> Detection >>>>> (BFD) on Link Aggregation Group (LAG) Interfaces >>>>> Author(s) : Manav Bhatia >>>>> Marc Binderberger >>>>> Sami Boutros >>>>> Nobo Akiya >>>>> Filename : draft-mmsn-bfd-on-lags-address-00.txt >>>>> Pages : 5 >>>>> Date : 2012-02-08 >>>>>=20 >>>>> This document describes techniques which can be used by >> a router >>>>> to obtain or discover remote neighbor IP address in order to=20 >>>>> establish micro Bidirectional Forwarding Detection >> (BFD) sessions >>>> [BFD-ON-LAGS]. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> A URL for this Internet-Draft is: >>>>>=20 >>>>=20 >> http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. >>>>> txt >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> This Internet-Draft can be retrieved at: >>>>>=20 >>>>=20 >> ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00 >>>> .t >>>>> xt >>>>>=20 >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Toms. >>>>=20 >>=20 >=20 > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f 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 > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f 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 marc@sniff.de Fri Feb 10 15:46:11 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 A4A1C21F85C6 for ; Fri, 10 Feb 2012 15:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=-0.677, 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 0aK2UHjqDh34 for ; Fri, 10 Feb 2012 15:46:10 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FDE21F86B2 for ; Fri, 10 Feb 2012 15:46:09 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 78EDF2AA0F; Fri, 10 Feb 2012 23:46:06 +0000 (GMT) Subject: Re: IP Address Schemes for BFD on LAG interfaces Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Sat, 11 Feb 2012 00:46:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com>, , <51C80FCE-D3FC-4D51-9E67-2EAD5670EDF2@sniff.de> To: Gregory Mirsky 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: Fri, 10 Feb 2012 23:46:11 -0000 Hello Gregory, I beg to differ on the TTL part. Singlehop async BFD uses typically TTL = =3D 255; RFC5884 is the exception.=20 And for reasons of having a simple security mechanism I would like to = see TTL 255 in use (you can use the more "CPU intensive" option of = authentication but I would argue against this as a mandatory method). Anyway, interesting aspect which I missed when we wrote the draft: if = the choice of the IP address has an impact on the TTL. I warm up for = "learn IP address by configuration" ;-) - simple idea, simple code. Regards, Marc On 2012-02-10, at 23:43 , Gregory Mirsky wrote: > Hi Marc, > I believe that regardless of addressing method IP TTL in micro-BFD = must be set to 1 because it is single-hop BFD. And RFC 5884 does that = for the same reason - LSP is a single hop segment, a link. Setting MPLS = TTL to expire is, in a way, similar to VCCV Control Channel Type 3 that = uses TTL expiration. Ethernet doesn't have TTL field and there might be = existing equipment that would drop 127/8 addressed IP packets and = micro-BFD would not work. But the same would be the case if multicast = addressing with new well-known address partially deployed. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de]=20 > Sent: Friday, February 10, 2012 2:24 PM > To: Tom Sanders; Alexander Vainshtein; Gregory Mirsky > Cc: Bhatia, Manav (Manav); Mach Chen; Nitin Bahadur; rtg-bfd@ietf.org > Subject: Re: IP Address Schemes for BFD on LAG interfaces >=20 > Hello Greg, Alexander et al., >=20 > well, Alexander has some point. RFC5884 gets away IMHO because the IP = TTL must be "1". And in case of multiple labels for the LSP it states in = section 7 >=20 > [...] If the label stack has a depth = greater > than one, the TTL of the inner MPLS label MAY be set to 1. This may > be necessary for certain FECs to enable the egress LSR's control > plane to receive the packet [RFC4379]. >=20 >=20 > So I think RFC5884 uses the TTL method to ensure the packet gets = punted up to the control plane. >=20 > ("I think" as the last paragraph of section 4 has some vagueness which = I decided to ignore when implementing but meanwhile I wonder ...). >=20 >=20 > Back to the Address Scheme, you mentioned in you earlier email: >=20 > "One possible disadvantage of using single well-known mcast IP address = as DA in micro-BFD mode, IMO, is that to receipient initial BFD packets = (Your Discriminator is still zeroed) hard to differentiate, they all are = the same but My Discriminator. Should not be a problem but might cause = some issues nevertheless." >=20 >=20 > The micro-session draft requires the use of "interface information of = the member link" to demultiplex the initial micro-session BFD packets. I = also don't see how a randomly chosen address out of 127/8 can help the = receiver side to do a meaningful differentiation (?). > (not against the random choice although Tom mentioned in another email = that one could simply chose a fixed address out of 127/8 if that range = is to be used) >=20 >=20 > Anyway, this is a good discussion :-) >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 > On 2012-02-10, at 21:18 , Gregory Mirsky wrote: >=20 >> Dear Sasha, >> AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is = optional. Thus use of Router Alert is not mandated by RFC 5884. >>=20 >> What do you think? >>=20 >> Regards, >> Greg >>=20 >> -----Original Message----- >> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >> Sent: Friday, February 10, 2012 12:10 PM >> To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders;=20 >> Nitin Bahadur >> Cc: rtg-bfd@ietf.org >> Subject: RE: IP Address Schemes for BFD on LAG interfaces >>=20 >> Dear Greg, >> RFC 5884 indeed does not explicitly requires any form of Router = Alert. >> However, it uses LSP Ping (RFC 4379) for bootstrapping the BFD = sessions - and this, in its turn, uses Router Alert. >>=20 >> So I am not sure that reference to RFC 5884 is appropriate either. >>=20 >> Did I miss something? >>=20 >> Regards, >> Sasha >>=20 >>=20 >>=20 >> ________________________________________ >> From: Gregory Mirsky [gregory.mirsky@ericsson.com] >> Sent: Friday, February 10, 2012 8:51 PM >> To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen; Tom=20 >> Sanders; Nitin Bahadur >> Cc: rtg-bfd@ietf.org >> Subject: RE: IP Address Schemes for BFD on LAG interfaces >>=20 >> Dear Sasha, >> Thank you for pointing to RA use in LSP Ping. I agree that reference = to RFC 4379 is not the most appropriate. I think that RFC 5884 is more = suitable as reference since both address single hop BFD and thus Router = Alert is not required. >>=20 >> Regards, >> Greg >>=20 >> -----Original Message----- >> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >> Sent: Friday, February 10, 2012 10:09 AM >> To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders;=20 >> Nitin Bahadur >> Cc: rtg-bfd@ietf.org >> Subject: RE: IP Address Schemes for BFD on LAG interfaces >>=20 >> Dear Greg, Manav and all, >>=20 >> I have strong doubts regarding using destination IP address in the = 127/8 range in the initial micro-BFD packets for the peer address = discovery. >>=20 >> In particular, I think that the reference to LSP Ping (RFC 4379) is = incorrect, because LSP Ping Echo packets MUST set the Router Alert = option in the IP header (see Section 4.3. "Sending an MPLS Echo = Request") in conjunction with using Destination IP address from the = 127/8 range. >>=20 >> Many IP stacks silently discarded received packets with Destination = IP address in the 127/8 range unless it is accompanied by the Router = Alert option. RFC 1122 and RFC 1812 definitely allow (and even request) = that. >> RFC 4379 has taken care to provide for backward compatibility with = these requirements. >>=20 >> Adding the Router Alert option to the initial packets of the = micro-BFD session could in principle resolve this contradiction but = would actually result in one more step away from reuse (claimed) of = existing implementations of RFC 5881. >>=20 >> My 2c, >> Sasha >>=20 >>=20 >>=20 >> ________________________________________ >> From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf = Of=20 >> Gregory Mirsky [gregory.mirsky@ericsson.com] >> Sent: Friday, February 10, 2012 7:13 PM >> To: Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur >> Cc: rtg-bfd@ietf.org >> Subject: RE: IP Address Schemes for BFD on LAG interfaces >>=20 >> Hi Manav, >> Then you know where my heart is. It randomly picks from 127/8 range. = ;) One possible disadvantage of using single well-known mcast IP address = as DA in micro-BFD mode, IMO, is that to receipient initial BFD packets = (Your Discriminator is still zeroed) hard to differentiate, they all are = the same but My Discriminator. Should not be a problem but might cause = some issues nevertheless. >>=20 >> Regards, >> Greg >>=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20= >> Behalf Of Bhatia, Manav (Manav) >> Sent: Thursday, February 09, 2012 8:20 PM >> To: Mach Chen; Tom Sanders; Nitin Bahadur >> Cc: rtg-bfd@ietf.org >> Subject: RE: IP Address Schemes for BFD on LAG interfaces >>=20 >> Hi Mach, >>=20 >> Yes, the idea is to just retain one mechanism. >>=20 >> I know you like multicast! ;-) >>=20 >> This is btw exactly the opinion that will be useful in zeroing on a = final discovery mechanism. It would be good if others too can chime in = with their thoughts on this. >>=20 >> Cheers, Manav >>=20 >>> -----Original Message----- >>> From: Mach Chen [mailto:mach.chen@huawei.com] >>> Sent: Friday, February 10, 2012 7:54 AM >>> To: Bhatia, Manav (Manav); Tom Sanders; Nitin Bahadur >>> Cc: rtg-bfd@ietf.org >>> Subject: RE: IP Address Schemes for BFD on LAG interfaces >>>=20 >>> Hi Manav, Toms and all, >>>=20 >>> Firstly, I share the concern of Nitin, and agree with Toms's >>> point: one dynamic remote address learning solution is enough. =46rom=20= >>> your reply, the authors also intend to keep only one solution, = great! >>>=20 >>>> Both proposals have their pros and cons and the authors of >>> the draft >>>> are not biased towards any particular solution (multicast >>> or 127/8). >>>> We would like the members of the WG to reach a consensus on which=20= >>>> proposal they would like to see going forward (if one has >>> to be chosen from the two). >>>=20 >>> Are there any analysis about the pros and cons? >>>=20 >>> I personally prefer Multicast, because: >>>=20 >>> 1. For the micro-BFD, we need a well-known Multicast MAC, if use=20 >>> Multicast for remote address learning, the Multicast MAC can be used=20= >>> for both remote address and MAC address learning; >>>=20 >>> 2. The micro-BFD draft proposes to use unicast IP for L3 = connectivity=20 >>> test, but the member link will be also used for >>> L3 mulitcast forwarding, so use Multicast for remote address = learning=20 >>> could test the L3 multicast connectivity at least one time; >>>=20 >>> 3. On the other hand, if use 127/8, the receiver needs to combine=20 >>> extra information(e.g., UDP port) to identify the learning message. >>>=20 >>>=20 >>> Best regards, >>> Mach >>>=20 >>>> -----Original Message----- >>>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20= >>>> Behalf Of Bhatia, Manav (Manav) >>>> Sent: Friday, February 10, 2012 9:24 AM >>>> To: Tom Sanders; Nitin Bahadur >>>> Cc: rtg-bfd@ietf.org >>>> Subject: RE: IP Address Schemes for BFD on LAG interfaces >>>>=20 >>>> Hi Toms, >>>>=20 >>>>=20 >>>>>=20 >>>>> I could be completely off the mark in which case the authors can=20= >>>>> correct me. But this seemed to me to be the high order bit of the=20= >>>>> document. >>>>=20 >>>> Perfect! What you've said above is absolutely correct. >>>>=20 >>>>>=20 >>>>> Question to the authors: >>>>>=20 >>>>> (1) 127/8 seems to be vague. Shouldnt you be specifying >>> an exact /32 >>>>> address that should be used? >>>>=20 >>>> The idea is to let implementations choose a destination IP address=20= >>>> randomly from the 127/8 range. This is consistent with what >>> has been >>>> described in RFC >>>> 5884 (BFD for MPLS LSPs). >>>>>=20 >>>>> (2) Do you think its wise to float two proposals that vendors can=20= >>>>> chose. Cant we have just one - either multicast or the >>>>> 127/8 unicast? >>>>> Why do we need two proposals? That would imo also address Nitin's=20= >>>>> concern (which i believe is quite valid). >>>>=20 >>>> Both proposals have their pros and cons and the authors of >>> the draft >>>> are not biased towards any particular solution (multicast >>> or 127/8). >>>> We would like the members of the WG to reach a consensus on which=20= >>>> proposal they would like to see going forward (if one has >>> to be chosen from the two). >>>>=20 >>>> Hope this helps. >>>>=20 >>>> Cheers, Manav >>>>=20 >>>>>=20 >>>>> Toms >>>>>=20 >>>>> On 09/02/2012, Nitin Bahadur wrote: >>>>>> Hi Manav, >>>>>>=20 >>>>>> The draft specifies multiple mechanisms and section 4.2 >>>>> lists that >>>>>> all MUST be supported. This doesn't make sense from a vendor=20 >>>>>> perspective IMO. If "all vendors" have to implement >>> "all options", >>>>>> then why not just have 1 option ! >>>>>>=20 >>>>>> Having multiple options also leads to inter-op issue among >>>>> vendors. We >>>>>> have seen that story with multiple other protocols. >>>>>>=20 >>>>>> Thanks >>>>>> Nitin >>>>>>=20 >>>>>>=20 >>>>>> On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> There were some concerns about operational complexity >>> that using >>>>>> unicast addresses for micro BFD sessions would entail. We >>>>> have written >>>>>> a short draft that alleviates such concerns by suggesting few=20 >>>>>> mechanisms that nodes can use to auto discover remote >>> neighbor IP >>>>>> addresses before establishing micro BFD sessions. >>>>>>=20 >>>>>> Would be great if the WG can review and provide feedback on >>>>> this draft. >>>>>>=20 >>>>>> The URL for this Internet-Draft is: >>>>>>=20 >>>>>=20 >>> = http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. >>>>>> txt >>>>>>=20 >>>>>> Cheers, Manav >>>>>>=20 >>>>>> -- >>>>>>=20 >>>>>> From: internet-drafts@ietf.org >>>>>> To: i-d-announce@ietf.org >>>>>> Reply-to: internet-drafts@ietf.org >>>>>> Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt >>>>>> X-C5I-RSN: 1/0/935/41368/44754 >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line >>> Internet-Drafts >>>>>> directories. >>>>>>=20 >>>>>> Title : IP Address Schemes for Bidirectional Forwarding >>> Detection >>>>>> (BFD) on Link Aggregation Group (LAG) Interfaces >>>>>> Author(s) : Manav Bhatia >>>>>> Marc Binderberger >>>>>> Sami Boutros >>>>>> Nobo Akiya >>>>>> Filename : draft-mmsn-bfd-on-lags-address-00.txt >>>>>> Pages : 5 >>>>>> Date : 2012-02-08 >>>>>>=20 >>>>>> This document describes techniques which can be used by >>> a router >>>>>> to obtain or discover remote neighbor IP address in order to=20 >>>>>> establish micro Bidirectional Forwarding Detection >>> (BFD) sessions >>>>> [BFD-ON-LAGS]. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> A URL for this Internet-Draft is: >>>>>>=20 >>>>>=20 >>> = http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. >>>>>> txt >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> This Internet-Draft can be retrieved at: >>>>>>=20 >>>>>=20 >>> ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00 >>>>> .t >>>>>> xt >>>>>>=20 >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Toms. >>>>>=20 >>>=20 >>=20 >> 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 >> 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 >=20 > -- > Marc Binderberger >=20 -- Marc Binderberger From Alexander.Vainshtein@ecitele.com Sat Feb 11 01:13: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 A0E2021F8419 for ; Sat, 11 Feb 2012 01:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.543 X-Spam-Level: X-Spam-Status: No, score=-4.543 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 JqUUzL4S5bPd for ; Sat, 11 Feb 2012 01:12:58 -0800 (PST) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id A674E21F8478 for ; Sat, 11 Feb 2012 01:12:57 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1328951565!4558681!2 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 13366 invoked from network); 11 Feb 2012 09:12:47 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-16.tower-21.messagelabs.com with SMTP; 11 Feb 2012 09:12:47 -0000 X-AuditID: 93eaf2e7-b7f2a6d000000e7d-38-4f363cf4104f Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id D0.A6.03709.4FC363F4; Sat, 11 Feb 2012 12:03:32 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Sat, 11 Feb 2012 11:12:45 +0200 From: Alexander Vainshtein To: Gregory Mirsky , "Bhatia, Manav (Manav)" , Mach Chen , Tom Sanders , Nitin Bahadur Date: Sat, 11 Feb 2012 11:10:35 +0200 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: Aczm4BTZKNK9QL1IRoSgcwePoSmyvgASFNfW//+ygwCAAJvUAP//bq/Q//637+D//JixYADbdleo///zHjD//8zLYP//mE4Q//5X6Rw= Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com>, , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILsWRmVeSWpSXmKPExsUy+dWnL7pfbMz8Df79M7d4/qSL0eLCWmGL OffusVo09LazWXz+s43R4uqnlUwObB6tz/ayevz6epXNY+esu+weLUfesnosWfKTyeN601X2 ALaoBkabxLy8/JLEklSFlNTiZFulgKLMssTkSiWFzBRbJUMlhYKcxOTU3NS8ElulxIKC1LwU JTsuG6BgZp5Cal5yfkpmXrqtkmewv66FhamlrqGSnZqyobE1V0hGZrFCqm5uYmaOQm5qcXFi eqoCUATkkbyU1BSFtPwihZKMVIWihMnMGd96/Qsaoit29HUxNjD2u3cxcnJICJhI/Gv9ygZh i0lcuLceyObiEBLYyyhx9+wUFpCEkMAURolpD0JBbDYBW4lNq++CFYkI3GaUePpkJRNIgllA U6LpxGd2EJtFQFWi5883sLiwgKXE5d7pYLaIgJXErmVvoewyiYlz3oIt4BUIlGj7soQNYtlc FomLzxxAbE6BCIn+S/3MIDYj0HXfT62B2iUucevJfCaIqwUkluw5zwxhi0q8fPyPFaJeVOJO +3pGiHodiQW7P7FB2NoSyxa+ZobYKyhxcuYTFoheSYmDK26wTGAUn4VkxSwk7bOQtM9C0r6A kWUVo2hmTkFJUm66gaFeanJmSWpOql5yfu4mRkhSer6D8dd8lUOMAhyMSjy8CxpM/YVYE8uK K3MPMUpyMCmJ8vLomPkL8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuH1egVUzpuSWFmVWpQPk7IA hvJEZinu5HxQXJfEGxsYoHCUxHmfJr/xFRJIBya67NTUgtQimFYZDg4lCd4eA6CNgkWp6akV aZk5JQhpJg5OkM08QJtXgNTwFhck5hZnpkPkTzEac0z9t+4CI8fB9vUXGIVY8vLzUqXEeeeA lAqAlGaU5sFNA+Wk+v///79iFAf6XJh3JUgVDzB5ws17BbSKCWiV9DkTkFXALAKXkmpgnO0m 2sDdteq8Xme13syd/kVbrk4/4qcWcOBZvEniv623w4oqjh2f1ttVcdVbYYPl99nFmbPiXq0S XhEUf3z3Y+4oy93aZw80qkiv7N4/WSqh06pP86TRxn+V0w6FqK9bNbuF4/fqa08OJD68wFsv +fLys6fPGC1VerWa116XVm4IXCMe8FR2nxJLcUaioRZzUXEiALYpLkkkBAAA 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: Sat, 11 Feb 2012 09:13:00 -0000 Dear Greg, I will re-check RFC 5884 and come back to you soon. Regards, Sasha ________________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Friday, February 10, 2012 10:18 PM To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nit= in Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Dear Sasha, AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is optional.= Thus use of Router Alert is not mandated by RFC 5884. What do you think? Regards, Greg -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Friday, February 10, 2012 12:10 PM To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bah= adur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Dear Greg, RFC 5884 indeed does not explicitly requires any form of Router Alert. However, it uses LSP Ping (RFC 4379) for bootstrapping the BFD sessions - an= d this, in its turn, uses Router Alert. So I am not sure that reference to RFC 5884 is appropriate either. Did I miss something? Regards, Sasha ________________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Friday, February 10, 2012 8:51 PM To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nit= in Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Dear Sasha, Thank you for pointing to RA use in LSP Ping. I agree that reference to RFC= 4379 is not the most appropriate. I think that RFC 5884 is more suitable as= reference since both address single hop BFD and thus Router Alert is not re= quired. Regards, Greg -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Friday, February 10, 2012 10:09 AM To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bah= adur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Dear Greg, Manav and all, I have strong doubts regarding using destination IP address in the 127/8 ran= ge in the initial micro-BFD packets for the peer address discovery. In particular, I think that the reference to LSP Ping (RFC 4379) is incorrec= t, because LSP Ping Echo packets MUST set the Router Alert option in the IP= header (see Section 4.3. "Sending an MPLS Echo Request") in conjunction wit= h using Destination IP address from the 127/8 range. Many IP stacks silently discarded received packets with Destination IP addre= ss in the 127/8 range unless it is accompanied by the Router Alert option. R= FC 1122 and RFC 1812 definitely allow (and even request) that. RFC 4379 has taken care to provide for backward compatibility with these req= uirements. Adding the Router Alert option to the initial packets of the micro-BFD sessi= on could in principle resolve this contradiction but would actually result i= n one more step away from reuse (claimed) of existing implementations of RF= C 5881. My 2c, Sasha ________________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of Grego= ry Mirsky [gregory.mirsky@ericsson.com] Sent: Friday, February 10, 2012 7:13 PM To: Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Hi Manav, Then you know where my heart is. It randomly picks from 127/8 range. ;) One= possible disadvantage of using single well-known mcast IP address as DA in= micro-BFD mode, IMO, is that to receipient initial BFD packets (Your Discri= minator is still zeroed) hard to differentiate, they all are the same but My= Discriminator. Should not be a problem but might cause some issues neverthe= less. Regards, Greg -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf O= f Bhatia, Manav (Manav) Sent: Thursday, February 09, 2012 8:20 PM To: Mach Chen; Tom Sanders; Nitin Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Hi Mach, Yes, the idea is to just retain one mechanism. I know you like multicast! ;-) This is btw exactly the opinion that will be useful in zeroing on a final di= scovery mechanism. It would be good if others too can chime in with their th= oughts on this. Cheers, Manav > -----Original Message----- > From: Mach Chen [mailto:mach.chen@huawei.com] > Sent: Friday, February 10, 2012 7:54 AM > To: Bhatia, Manav (Manav); Tom Sanders; Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces > > Hi Manav, Toms and all, > > Firstly, I share the concern of Nitin, and agree with Toms's > point: one dynamic remote address learning solution is enough. From > your reply, the authors also intend to keep only one solution, great! > > > Both proposals have their pros and cons and the authors of > the draft > > are not biased towards any particular solution (multicast > or 127/8). > > We would like the members of the WG to reach a consensus on which > > proposal they would like to see going forward (if one has > to be chosen from the two). > > Are there any analysis about the pros and cons? > > I personally prefer Multicast, because: > > 1. For the micro-BFD, we need a well-known Multicast MAC, if use > Multicast for remote address learning, the Multicast MAC can be used > for both remote address and MAC address learning; > > 2. The micro-BFD draft proposes to use unicast IP for L3 connectivity > test, but the member link will be also used for > L3 mulitcast forwarding, so use Multicast for remote address learning > could test the L3 multicast connectivity at least one time; > > 3. On the other hand, if use 127/8, the receiver needs to combine > extra information(e.g., UDP port) to identify the learning message. > > > Best regards, > Mach > > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > > Behalf Of Bhatia, Manav (Manav) > > Sent: Friday, February 10, 2012 9:24 AM > > To: Tom Sanders; Nitin Bahadur > > Cc: rtg-bfd@ietf.org > > Subject: RE: IP Address Schemes for BFD on LAG interfaces > > > > Hi Toms, > > > > > > > > > > I could be completely off the mark in which case the authors can > > > correct me. But this seemed to me to be the high order bit of the > > > document. > > > > Perfect! What you've said above is absolutely correct. > > > > > > > > Question to the authors: > > > > > > (1) 127/8 seems to be vague. Shouldnt you be specifying > an exact /32 > > > address that should be used? > > > > The idea is to let implementations choose a destination IP address > > randomly from the 127/8 range. This is consistent with what > has been > > described in RFC > > 5884 (BFD for MPLS LSPs). > > > > > > (2) Do you think its wise to float two proposals that vendors can > > > chose. Cant we have just one - either multicast or the > > > 127/8 unicast? > > > Why do we need two proposals? That would imo also address Nitin's > > > concern (which i believe is quite valid). > > > > Both proposals have their pros and cons and the authors of > the draft > > are not biased towards any particular solution (multicast > or 127/8). > > We would like the members of the WG to reach a consensus on which > > proposal they would like to see going forward (if one has > to be chosen from the two). > > > > Hope this helps. > > > > Cheers, Manav > > > > > > > > Toms > > > > > > On 09/02/2012, Nitin Bahadur wrote: > > > > Hi Manav, > > > > > > > > The draft specifies multiple mechanisms and section 4.2 > > > lists that > > > > all MUST be supported. This doesn't make sense from a vendor > > > > perspective IMO. If "all vendors" have to implement > "all options", > > > > then why not just have 1 option ! > > > > > > > > Having multiple options also leads to inter-op issue among > > > vendors. We > > > > have seen that story with multiple other protocols. > > > > > > > > Thanks > > > > Nitin > > > > > > > > > > > > On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" > > > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > There were some concerns about operational complexity > that using > > > > unicast addresses for micro BFD sessions would entail. We > > > have written > > > > a short draft that alleviates such concerns by suggesting few > > > > mechanisms that nodes can use to auto discover remote > neighbor IP > > > > addresses before establishing micro BFD sessions. > > > > > > > > Would be great if the WG can review and provide feedback on > > > this draft. > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > > > txt > > > > > > > > Cheers, Manav > > > > > > > > -- > > > > > > > > From: internet-drafts@ietf.org > > > > To: i-d-announce@ietf.org > > > > Reply-to: internet-drafts@ietf.org > > > > Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt > > > > X-C5I-RSN: 1/0/935/41368/44754 > > > > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > > > directories. > > > > > > > > Title : IP Address Schemes for Bidirectional Forwarding > Detection > > > > (BFD) on Link Aggregation Group (LAG) Interfaces > > > > Author(s) : Manav Bhatia > > > > Marc Binderberger > > > > Sami Boutros > > > > Nobo Akiya > > > > Filename : draft-mmsn-bfd-on-lags-address-00.txt > > > > Pages : 5 > > > > Date : 2012-02-08 > > > > > > > > This document describes techniques which can be used by > a router > > > > to obtain or discover remote neighbor IP address in order to > > > > establish micro Bidirectional Forwarding Detection > (BFD) sessions > > > [BFD-ON-LAGS]. > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > > > txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > This Internet-Draft can be retrieved at: > > > > > > > > ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00 > > > .t > > > > xt > > > > > > > > _______________________________________________ > > > > I-D-Announce mailing list > > > > I-D-Announce@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > > > > > > > -- > > > Toms. > > > > 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. 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. 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 Alexander.Vainshtein@ecitele.com Sat Feb 11 02:26: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 CEA5E21F8598 for ; Sat, 11 Feb 2012 02:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.557 X-Spam-Level: X-Spam-Status: No, score=-4.557 tagged_above=-999 required=5 tests=[AWL=0.645, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 9VXgEPu2Tup1 for ; Sat, 11 Feb 2012 02:26:19 -0800 (PST) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id D284221F8593 for ; Sat, 11 Feb 2012 02:26:18 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1328955976!11454844!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 7507 invoked from network); 11 Feb 2012 10:26:17 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-12.tower-21.messagelabs.com with SMTP; 11 Feb 2012 10:26:17 -0000 X-AuditID: 93eaf2e7-b7f2a6d000000e7d-28-4f364e2de09d Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id D2.E6.03709.D2E463F4; Sat, 11 Feb 2012 13:17:02 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Sat, 11 Feb 2012 12:26:15 +0200 From: Alexander Vainshtein To: Gregory Mirsky , Mach Chen Date: Sat, 11 Feb 2012 12:24:41 +0200 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: Aczm4BTZKNK9QL1IRoSgcwePoSmyvgASFNfW//+ygwCAAJvUAP//bq/Q//637+D//JixYADbdleo///zHjD//8zLYP//mE4Q//5IPtg= Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com>, , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C760116342AE509ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTeUgUURzmzYzraE5N6/W0/him+9jNxbLtWMlAsKgsCoqCbJp97U7tzmwz o7QRtV0aWrlZdiyEHXZgh7ZRRBe4JHRh24UVFUF2bRmRlhShzThl/tN/33zf977vN4/fI3Fz KD6TFEQVySLnYU2JxO7Y1w6LdU5OYVZTYIT9XWs5sEfPJNvbf10E0/CCn98emwq23GiLK6it /YHNxRcHwFROFCWVUxHjRArvYOfKQgnH+1lGcDpYG8v4PByPvEhUHSzn8yHRyeYmTtVIQWSQ yEtOQXQ52BnzCy12+4RJFhubO3yILXtK4gK3oDDI4uUED+NFisK5EKMx+qiiEzmZFZLMqG7E yMt24+6K5k7g23YYW9O9tR0PgNLPoBwkkJAeD993BHADp8Hoy3pTOUgkzfQ1AJ9uOo/pgpne A2DVdkLHJtoBw6demHScQi+A3ytKe3icHgU33WyP1zFBD4M1Xw1/Mj0JPtyxDzP8k+Hl421/ cAmMNrX0FFP0PPii5S4wug4S8P7baTpOoBfBygeVPR6gDdd5+zRmdKXDZ601mDE0DWuv3vvz A6nww+uuOMOfCp+X1QPDL8HnVxrijK6B8NaBVsLwZ8DGk0+IIEgL9YkN9TkS6nPE4K3wSfUe k4HHwOOHP+IGtsD9XRGiL38IxNeBVMHjU5d7XVk2K+IFFXmQlZe8YWCs0btL4GfN0AigScAm UYcCEwrNcVyJ4vdGQAaJsanU6rycQnP/5ZLT7+YUd5Fc7EFKBEASZ1OomTHNTjk5/1okS3+l fO32d+GZ/XhJ3wK1KDsr6/8fbDr1hv8020y7tN1chZAPyX9zBpMkC6mwXj9QRi60ZoXgUf/J GJmgj5GkjRHUPZTi47yK4DL02yCbrO46GwVkY1l9FJgJURJRZjpVpltp3eouFnvT9Ce1obu7 OwbStWtINgKTtC3uzYtpVZhWNah5vF6lvaReKTMA7tT1X3rdkTPL2rlq73p578R5LcgT2lw1 smH0OX/+BVC/LD/P3lx55FjXvnttxesa704fFr51ovzZibrhA3LSrmRUvG0KthzlG6Cvg5i8 Mbw4adDYcbMuNX05G14ZRK2dwffSRxknd56//qrA0rHkUUbKKXes6EzEvNLW+GjLwjsjkllC cXO20biscL8B2yqsvy0EAAA= 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: Sat, 11 Feb 2012 10:26:21 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760116342AE509ILPTMAIL02e_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Dear Greg, Regarding your claim that ""use of LSP Ping to bootstrap a BFD session over= MPLS LSP is optional" - quoting from RFC 5884: In Section 4 "Theory of operation" To enable fault detection procedures specified in this document, for a particular MPLS LSP, this document requires the ingress and egress LSRs to be configured. This includes configuration for supporting BFD and LSP Ping as specified in this document. It also includes configuration that enables the ingress LSR to determine the method used by the egress LSR to identify Operations, Administration, and Maintenance (OAM) packets, e.g., whether the Time to Live (TTL) of the innermost MPLS label needs to be set to 1 to enable the egress LSR to identify the OAM packet. For fault detection for MPLS PWs, this document assumes that the PW control channel type [RFC5085] is configured and the support of LSP Ping is also configured. In Section 6 "Session Establishment": A BFD session is bootstrapped using LSP Ping. ... To establish a BFD session, an LSP Ping Echo request message MUST carry the local discriminator assigned by the ingress LSR for the BFD session. This MUST subsequently be used as the My Discriminator field in the BFD session packets sent by the ingress LSR. And from Section 6.1. "BFD Discriminator TLV in LSP Ping": LSP Ping Echo request and Echo reply messages carry a BFD discriminator TLV for the purpose of session establishment as described above. IANA has assigned a type value of 15 to this TLV. This TLV has a length of 4. The value contains the 4-byte local discriminator that the LSR, sending the LSP Ping message, associates with the BFD session. If the BFD session is not in UP state, the periodic LSP Ping Echo request messages MUST include the BFD Discriminator TLV. The highlighted text suggests to me that RFC 5884 mandates usage of LSP Ping= for bootstrapping of BFD sessions. Taking into account that it supports BFD= session per FEC for a given LSP, I do not see any alternative to this metho= d. Did I miss something substantial? Regards, Sasha ________________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Friday, February 10, 2012 10:18 PM To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nit= in Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Dear Sasha, AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is optional.= Thus use of Router Alert is not mandated by RFC 5884. What do you think? Regards, Greg -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Friday, February 10, 2012 12:10 PM To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bah= adur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Dear Greg, RFC 5884 indeed does not explicitly requires any form of Router Alert. However, it uses LSP Ping (RFC 4379) for bootstrapping the BFD sessions - an= d this, in its turn, uses Router Alert. So I am not sure that reference to RFC 5884 is appropriate either. Did I miss something? Regards, Sasha ________________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Friday, February 10, 2012 8:51 PM To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nit= in Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Dear Sasha, Thank you for pointing to RA use in LSP Ping. I agree that reference to RFC= 4379 is not the most appropriate. I think that RFC 5884 is more suitable as= reference since both address single hop BFD and thus Router Alert is not re= quired. Regards, Greg -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Friday, February 10, 2012 10:09 AM To: Gregory Mirsky; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bah= adur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Dear Greg, Manav and all, I have strong doubts regarding using destination IP address in the 127/8 ran= ge in the initial micro-BFD packets for the peer address discovery. In particular, I think that the reference to LSP Ping (RFC 4379) is incorrec= t, because LSP Ping Echo packets MUST set the Router Alert option in the IP= header (see Section 4.3. "Sending an MPLS Echo Request") in conjunction wit= h using Destination IP address from the 127/8 range. Many IP stacks silently discarded received packets with Destination IP addre= ss in the 127/8 range unless it is accompanied by the Router Alert option. R= FC 1122 and RFC 1812 definitely allow (and even request) that. RFC 4379 has taken care to provide for backward compatibility with these req= uirements. Adding the Router Alert option to the initial packets of the micro-BFD sessi= on could in principle resolve this contradiction but would actually result i= n one more step away from reuse (claimed) of existing implementations of RF= C 5881. My 2c, Sasha ________________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of Grego= ry Mirsky [gregory.mirsky@ericsson.com] Sent: Friday, February 10, 2012 7:13 PM To: Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Hi Manav, Then you know where my heart is. It randomly picks from 127/8 range. ;) One= possible disadvantage of using single well-known mcast IP address as DA in= micro-BFD mode, IMO, is that to receipient initial BFD packets (Your Discri= minator is still zeroed) hard to differentiate, they all are the same but My= Discriminator. Should not be a problem but might cause some issues neverthe= less. Regards, Greg -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf O= f Bhatia, Manav (Manav) Sent: Thursday, February 09, 2012 8:20 PM To: Mach Chen; Tom Sanders; Nitin Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Hi Mach, Yes, the idea is to just retain one mechanism. I know you like multicast! ;-) This is btw exactly the opinion that will be useful in zeroing on a final di= scovery mechanism. It would be good if others too can chime in with their th= oughts on this. Cheers, Manav > -----Original Message----- > From: Mach Chen [mailto:mach.chen@huawei.com] > Sent: Friday, February 10, 2012 7:54 AM > To: Bhatia, Manav (Manav); Tom Sanders; Nitin Bahadur > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces > > Hi Manav, Toms and all, > > Firstly, I share the concern of Nitin, and agree with Toms's > point: one dynamic remote address learning solution is enough. From > your reply, the authors also intend to keep only one solution, great! > > > Both proposals have their pros and cons and the authors of > the draft > > are not biased towards any particular solution (multicast > or 127/8). > > We would like the members of the WG to reach a consensus on which > > proposal they would like to see going forward (if one has > to be chosen from the two). > > Are there any analysis about the pros and cons? > > I personally prefer Multicast, because: > > 1. For the micro-BFD, we need a well-known Multicast MAC, if use > Multicast for remote address learning, the Multicast MAC can be used > for both remote address and MAC address learning; > > 2. The micro-BFD draft proposes to use unicast IP for L3 connectivity > test, but the member link will be also used for > L3 mulitcast forwarding, so use Multicast for remote address learning > could test the L3 multicast connectivity at least one time; > > 3. On the other hand, if use 127/8, the receiver needs to combine > extra information(e.g., UDP port) to identify the learning message. > > > Best regards, > Mach > > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > > Behalf Of Bhatia, Manav (Manav) > > Sent: Friday, February 10, 2012 9:24 AM > > To: Tom Sanders; Nitin Bahadur > > Cc: rtg-bfd@ietf.org > > Subject: RE: IP Address Schemes for BFD on LAG interfaces > > > > Hi Toms, > > > > > > > > > > I could be completely off the mark in which case the authors can > > > correct me. But this seemed to me to be the high order bit of the > > > document. > > > > Perfect! What you've said above is absolutely correct. > > > > > > > > Question to the authors: > > > > > > (1) 127/8 seems to be vague. Shouldnt you be specifying > an exact /32 > > > address that should be used? > > > > The idea is to let implementations choose a destination IP address > > randomly from the 127/8 range. This is consistent with what > has been > > described in RFC > > 5884 (BFD for MPLS LSPs). > > > > > > (2) Do you think its wise to float two proposals that vendors can > > > chose. Cant we have just one - either multicast or the > > > 127/8 unicast? > > > Why do we need two proposals? That would imo also address Nitin's > > > concern (which i believe is quite valid). > > > > Both proposals have their pros and cons and the authors of > the draft > > are not biased towards any particular solution (multicast > or 127/8). > > We would like the members of the WG to reach a consensus on which > > proposal they would like to see going forward (if one has > to be chosen from the two). > > > > Hope this helps. > > > > Cheers, Manav > > > > > > > > Toms > > > > > > On 09/02/2012, Nitin Bahadur wrote: > > > > Hi Manav, > > > > > > > > The draft specifies multiple mechanisms and section 4.2 > > > lists that > > > > all MUST be supported. This doesn't make sense from a vendor > > > > perspective IMO. If "all vendors" have to implement > "all options", > > > > then why not just have 1 option ! > > > > > > > > Having multiple options also leads to inter-op issue among > > > vendors. We > > > > have seen that story with multiple other protocols. > > > > > > > > Thanks > > > > Nitin > > > > > > > > > > > > On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" > > > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > There were some concerns about operational complexity > that using > > > > unicast addresses for micro BFD sessions would entail. We > > > have written > > > > a short draft that alleviates such concerns by suggesting few > > > > mechanisms that nodes can use to auto discover remote > neighbor IP > > > > addresses before establishing micro BFD sessions. > > > > > > > > Would be great if the WG can review and provide feedback on > > > this draft. > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > > > txt > > > > > > > > Cheers, Manav > > > > > > > > -- > > > > > > > > From: internet-drafts@ietf.org > > > > To: i-d-announce@ietf.org > > > > Reply-to: internet-drafts@ietf.org > > > > Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt > > > > X-C5I-RSN: 1/0/935/41368/44754 > > > > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > > > directories. > > > > > > > > Title : IP Address Schemes for Bidirectional Forwarding > Detection > > > > (BFD) on Link Aggregation Group (LAG) Interfaces > > > > Author(s) : Manav Bhatia > > > > Marc Binderberger > > > > Sami Boutros > > > > Nobo Akiya > > > > Filename : draft-mmsn-bfd-on-lags-address-00.txt > > > > Pages : 5 > > > > Date : 2012-02-08 > > > > > > > > This document describes techniques which can be used by > a router > > > > to obtain or discover remote neighbor IP address in order to > > > > establish micro Bidirectional Forwarding Detection > (BFD) sessions > > > [BFD-ON-LAGS]. > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > > > txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > This Internet-Draft can be retrieved at: > > > > > > > > ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00 > > > .t > > > > xt > > > > > > > > _______________________________________________ > > > > I-D-Announce mailing list > > > > I-D-Announce@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > > > > > > > -- > > > Toms. > > > > 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. 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. 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. --_000_A3C5DF08D38B6049839A6F553B331C760116342AE509ILPTMAIL02e_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable

Dear Greg,

Regarding your claim that ""use= of LSP Ping to bootstrap a BFD session over MPLS LSP is optional" - q<= /font>uoting from RFC 5884:

In Section 4 "Theory of operation&quo= t;

 

   To enable fault detection procedures specified in this do=
cument, for
   a particular MPLS LSP, this document requires the ingress and egress
   LSRs to be configured.  This in=
cludes configuration for supporting
   BFD and LSP Ping as specified in this document.  It also includes
   configuration that enables the ingress LSR to determine the method
   used by the egress LSR to identify Operations, Administration, and
   Maintenance (OAM) packets, e.g., whether the Time to Live (TTL) of
   the innermost MPLS label needs to be set to 1 to enable the egress

   LSR to identify the OAM packet.  For fault detection for MPLS PWs,
   this document assumes that the PW control channel type [RFC5085] is
   configured and the support of LSP Ping is also configured.
 
In Section 6 "Session Establishment":

 

A=
 BFD session is bootstrapped using LSP Ping. 


...


   To establish a=
 BFD session, an LSP Ping
   Echo request message MUST carry the local discriminator assigned by
   the ingress LSR for the BFD session.  This MUST subsequently be used
   as the My Discriminator field in the BFD session packets sent by the
   ingress LSR.




And from Section 6.1. "BFD Discriminator TLV in LSP Ping":


 



   LSP Ping Echo r=
equest and Echo reply messages carry a BFD
   discriminator TLV for the purpose of session establishment as
   described above.  IANA has assigned a type value of 15 to this TLV=
.
   This TLV has a length of 4.  The value contains the 4-byte local
   discriminator that the LSR, sending the LSP Ping message, associates
   with the BFD session.

   If the BFD session is not in UP=
 state, the periodic LSP Ping Echo
   request messages MUST include the BFD Discriminator TLV.



 





The highlighted text suggests to me that RFC 5884 mandates=
 usage of LSP Ping for bootstrapping of BFD sessions. Taking int=
o account that it supports BFD session per FEC for a given LSP, I do not see=
 any alternative to this method.


 


 


Did I miss something substantial?

 


Regards,


     Sasha


 


 






________________________________________

From: Gregory Mirsky [gregory.mirsky@ericsson.com]=


Sent: Friday, February 10, 2012 10:18 PM

To: Alexander Vainshtein; Bhatia, Manav (Ma=
nav); Mach Chen; Tom Sanders; Nitin Bahadur=


Cc: rtg-bfd@ietf.org

Subject: RE: IP Address Schemes for BFD on LAG interfaces



Dear Sasha,

AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is optional.=
 Thus use of Router Alert is not mandated by RFC 5884.



What do you think?



        Regards,

            &nbs=
p;   Greg



-----Original Message-----

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@e=
citele.com]

Sent: Friday, February 10, 2012 12:10 PM

To: Gregory Mirsky; Bhatia, Manav (Manav=
); Mach Chen; Tom Sanders; Nitin Bahadur

Cc: rtg-bfd@ietf.org

Subject: RE: IP Address Schemes for BFD on LAG interfaces



Dear Greg,

RFC 5884 indeed does not explicitly requires any form of Router Alert.

However, it uses LSP Ping (RFC 4379) for bootstrapping the BFD sessions - an=
d this, in its turn, uses Router Alert.



So I am not sure that reference to RFC 5884 is appropriate either.



Did I miss something?



Regards,

     Sasha







________________________________________

From: Gregory Mirsky [gregory.mirsky@ericsson.com<=
a>]

Sent: Friday, February 10, 2012 8:51 PM

To: Alexander Vainshtein; Bhatia, Manav (Ma=
nav); Mach Chen; Tom Sanders; Nitin Bahadur=


Cc: rtg-bfd@ietf.org

Subject: RE: IP Address Schemes for BFD on LAG interfaces



Dear Sasha,

Thank you for pointing to RA use in LSP Ping. I agree that reference to RFC=
 4379 is not the most appropriate. I think that RFC 5884 is more suitable as=
 reference since both address single hop BFD and thus Router Alert is not re=
quired.



        Regards,

            &nbs=
p;   Greg



-----Original Message-----

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@e=
citele.com]

Sent: Friday, February 10, 2012 10:09 AM

To: Gregory Mirsky; Bhatia, Manav (Manav=
); Mach Chen; Tom Sanders; Nitin Bahadur

Cc: rtg-bfd@ietf.org

Subject: RE: IP Address Schemes for BFD on LAG interfaces



Dear Greg, Manav and all,



I have strong doubts regarding using destination IP address in the 127/8 ran=
ge in the initial micro-BFD packets for the peer address discovery.



In particular, I think that the reference to LSP Ping (RFC 4379) is incorrec=
t, because LSP Ping Echo packets MUST set the Router Alert option in the IP=
 header (see Section 4.3. "Sending an MPLS Echo Request") in conju=
nction with using Destination IP address
 from the 127/8 range.



Many IP stacks silently discarded received packets with Destination IP addre=
ss in the 127/8 range unless it is accompanied by the Router Alert option. R=
FC 1122 and RFC 1812 definitely allow (and even request) that.

RFC 4379 has taken care to provide for backward compatibility with these req=
uirements.



Adding the Router Alert option to the initial packets of the micro-BFD sessi=
on could in principle resolve this contradiction but would actually result i=
n one more step away from reuse (claimed) of  existing implementations=
 of RFC 5881.



My 2c,

     Sasha







________________________________________

From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org<=
a>] On Behalf Of Gregory Mirsky [gregory.mirsk=
y@ericsson.com]

Sent: Friday, February 10, 2012 7:13 PM

To: Bhatia, Manav (Manav); Mach Chen; Tom S=
anders; Nitin Bahadur

Cc: rtg-bfd@ietf.org

Subject: RE: IP Address Schemes for BFD on LAG interfaces



Hi Manav,

Then you know where my heart is. It randomly picks from 127/8 range. ;) One=
 possible disadvantage of using single well-known mcast I=
P address as DA in micro-BFD mode, IMO, is that to receipient=
 initial BFD packets (Your Discriminator
 is still zeroed) hard to differentiate, they all are the same but My Discri=
minator. Should not be a problem but might cause some issues nevertheless.


        Regards,

            &nbs=
p;   Greg



-----Original Message-----

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ie=
tf.org] On Behalf Of Bhatia, Manav (Manav)

Sent: Thursday, February 09, 2012 8:20 PM

To: Mach Chen; Tom Sanders; Nitin Bahadur
Cc: rtg-bfd@ietf.org

Subject: RE: IP Address Schemes for BFD on LAG interfaces



Hi Mach,



Yes, the idea is to just retain one mechanism.



I know you like multicast! ;-)



This is btw exactly the opinion that will be useful in zeroing on a final di=
scovery mechanism. It would be good if others too can chime in with their th=
oughts on this.



Cheers, Manav



> -----Original Message-----

> From: Mach Chen [mailto:mach.chen@huawei.com]

> Sent: Friday, February 10, 2012 7:54 AM

> To: Bhatia, Manav (Manav); Tom Sanders=
; Nitin Bahadur

> Cc: rtg-bfd@ietf.org

> Subject: RE: IP Address Schemes for BFD on LAG interfaces

>

> Hi Manav, Toms and all,

>

> Firstly, I share the concern of Nitin, and agree with Tom=
s's

> point: one dynamic remote address learning solution is enough. From

> your reply, the authors also intend to keep only one solution, great!
>

> > Both proposals have their pros and cons and the authors of

> the draft

> > are not biased towards any particular solution (multicast

> or 127/8).

> > We would like the members of the WG to reach a consensus on which<=
br>
> > proposal they would like to see going forward (if one has

> to be chosen from the two).

>

> Are there any analysis about the pros and cons?

>

> I personally prefer Multicast, because:

>

> 1. For the micro-BFD, we need a well-known Multicast MAC, if use

> Multicast for remote address learning, the Multicast MAC can be used
> for both remote address and MAC address learning;

>

> 2. The micro-BFD draft proposes to use unicast IP fo=
r L3 connectivity

> test, but the member link will be also used for

> L3 mulitcast forwarding, so use Multicast for remote=
 address learning

> could test the L3 multicast connectivity at least one time;

>

> 3. On the other hand, if use 127/8, the receiver needs to combine

> extra information(e.g., UDP port) to identify the learning message.

>

>

> Best regards,

> Mach

>

> > -----Original Message-----

> > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-=
bounces@ietf.org] On

> > Behalf Of Bhatia, Manav (Manav)
> > Sent: Friday, February 10, 2012 9:24 AM

> > To: Tom Sanders; Nitin Bahadur
> > Cc: rtg-bfd@ietf.org

> > Subject: RE: IP Address Schemes for BFD on LAG interfaces

> >

> > Hi Toms,

> >

> >

> > >

> > > I could be completely off the mark in which case the authors=
 can

> > > correct me. But this seemed to me to be the high order bit of=
 the

> > > document.

> >

> > Perfect! What you've said above is absolutely correct.

> >

> > >

> > > Question to the authors:

> > >

> > > (1) 127/8 seems to be vague. Shouldnt you=
 be specifying

> an exact /32

> > > address that should be used?

> >

> > The idea is to let implementations choose a destination IP address=


> > randomly from the 127/8 range. This is consistent with what

> has been

> > described in RFC

> > 5884 (BFD for MPLS LSPs).

> > >

> > > (2) Do you think its wise to float two proposals that vendors=
 can

> > > chose. Cant we have just one - either multicast or the

> > > 127/8 unicast?

> > > Why do we need two proposals? That would imo also address Nitin's

> > > concern (which i believe is quite valid).<=
br>
> >

> > Both proposals have their pros and cons and the authors of

> the draft

> > are not biased towards any particular solution (multicast

> or 127/8).

> > We would like the members of the WG to reach a consensus on which<=
br>
> > proposal they would like to see going forward (if one has

> to be chosen from the two).

> >

> > Hope this helps.

> >

> > Cheers, Manav

> >

> > >

> > > Toms

> > >

> > > On 09/02/2012, Nitin Bahadur <nitinb@juniper.net> wrote:

> > > > Hi Manav,

> > > >

> > > >   The draft specifies multiple mechanisms and=
 section 4.2

> > > lists that

> > > > all MUST be supported. This doesn't make sense from a ve=
ndor

> > > > perspective IMO. If "all vendors" have to impl=
ement

> "all options",

> > > > then why not just have 1 option !

> > > >

> > > > Having multiple options also leads to inter-op issue amo=
ng

> > > vendors. We

> > > > have seen that story with multiple other protocols.

> > > >

> > > > Thanks

> > > > Nitin

> > > >

> > > >

> > > > On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)"

> > > > <manav.bhatia@alcatel-lucent.com>
> > > > wrote:

> > > >

> > > > Hi,

> > > >

> > > > There were some concerns about operational complexity
> that using

> > > > unicast addresses for micro BFD sessi=
ons would entail. We

> > > have written

> > > > a short draft that alleviates such concerns by suggestin=
g few

> > > > mechanisms that nodes can use to auto discover remote
> neighbor IP

> > > > addresses before establishing micro BFD sessions.

> > > >

> > > > Would be great if the WG can review and provide feedback=
 on

> > > this draft.

> > > >

> > > > The URL for this Internet-Draft is:

> > > >

> > >

> http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.<=
br>
> > > > txt

> > > >

> > > > Cheers, Manav

> > > >

> > > > --

> > > >

> > > > From: internet-drafts@ietf.org

> > > > To: i-d-announce@ietf.org

> > > > Reply-to: internet-drafts@ietf.org

> > > > Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.t=
xt

> > > > X-C5I-RSN: 1/0/935/41368/44754

> > > >

> > > > A New Internet-Draft is available from the on-line

> Internet-Drafts

> > > > directories.

> > > >

> > > > Title : IP Address Schemes for Bidirectional Forwarding<=
br>
> Detection

> > > > (BFD) on Link Aggregation Group (LAG) Interfaces

> > > > Author(s) : Manav Bhatia

> > > > Marc Binderberger

> > > > Sami Boutros

> > > > Nobo Akiya

> > > > Filename : draft-mmsn-bfd-on-lags-address-00.txt

> > > > Pages : 5

> > > > Date : 2012-02-08

> > > >

> > > > This document describes techniques which can be used by<=
br>
> a router

> > > > to obtain or discover remote neighbor IP address in orde=
r to

> > > > establish micro Bidirectional Forwarding Detection

> (BFD) sessions

> > > [BFD-ON-LAGS].

> > > >

> > > >

> > > >

> > > > A URL for this Internet-Draft is:

> > > >

> > >

> http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.<=
br>
> > > > txt

> > > >

> > > > Internet-Drafts are also available by anonymous FTP at:<=
br>
> > > > ftp://ftp.ietf.org/internet-drafts/

> > > >

> > > > This Internet-Draft can be retrieved at:

> > > >

> > >

> ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00
> > > .t

> > > > xt

> > > >

> > > > _______________________________________________

> > > > I-D-Announce mailing list

> > > > I-D-Announce@ietf.org

> > > > https://www.ietf.org/mailman/listinfo/i-d-announce

> > > > Internet-Draft directories: http://www.ietf.org/shadow.h=
tml or

> > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt

> > > >

> > > >

> > > >

> > >

> > >

> > > --

> > > Toms.

> > >

>



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.



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.



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.





--_000_A3C5DF08D38B6049839A6F553B331C760116342AE509ILPTMAIL02e_--

From marc@sniff.de  Sat Feb 11 02:46:40 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 00E6C21F85A5 for ; Sat, 11 Feb 2012 02:46:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.066
X-Spam-Level: 
X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 iTvt7jnrFlD7 for ; Sat, 11 Feb 2012 02:46:39 -0800 (PST)
Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 685AD21F858E for ; Sat, 11 Feb 2012 02:46:38 -0800 (PST)
Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 496402AA0F; Sat, 11 Feb 2012 10:46:36 +0000 (GMT)
Subject: Re: IP Address Schemes for BFD on LAG interfaces
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-2-610158770
From: Marc Binderberger 
In-Reply-To: <9FF62A05-99C0-4E48-A5E5-CA24FD9C953F@sniff.de>
Date: Sat, 11 Feb 2012 11:46:33 +0100
Message-Id: <39DA64CF-D9B5-4661-AE4B-0250168EC7CB@sniff.de>
References:  <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com>,  ,  ,   <9FF62A05-99C0-4E48-A5E5-CA24FD9C953F@sniff.de>
To: Alexander Vainshtein , Gregory Mirsky 
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: Sat, 11 Feb 2012 10:46:40 -0000

--Apple-Mail-2-610158770
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hello Alexander and Greg,

> The highlighted text suggests to me that RFC 5884 mandates usage of =
LSP Ping for bootstrapping of BFD sessions. Taking into account that it =
supports BFD session per FEC for a given LSP, I do not see any =
alternative to this method.


I agree. The first sentence in section 6 was already enough for me. It =
seems obvious to me that RFC5884 is tightly coupling BFD and LSP ping, =
nothing optional.

Now Greg's email had 2 statements:

"AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is =
optional. Thus use of Router Alert is not mandated by RFC 5884."


The first sentence you have answered. For the second sentence I assume =
this is related to BFD packets (?). And indeed RFC5884 is not mentioning =
router alert a single time, neither as option nor as label. My =
understanding is the BFD packet has no router alert option in it's IP =
header.

I have sent an email to George, one of the authors of RFC5884 and =
RFC4379, why LSP ping echo requests - with an IP header very similar to =
BFD in RFC5884 - need to carry RA option but BFD does not.


> Did I miss something substantial?


If so then you are not alone ;-)


Regards, Marc



On 2012-02-11, at 11:24 , Alexander Vainshtein wrote:

> Dear Greg,
> Regarding your claim that ""use of LSP Ping to bootstrap a BFD session =
over MPLS LSP is optional" - quoting from RFC 5884:
> In Section 4 "Theory of operation"
> =20
>    To enable fault detection procedures specified in this document, =
for
>    a particular MPLS LSP, this document requires the ingress and =
egress
>    LSRs to be configured.  This includes configuration for supporting
>    BFD and LSP Ping as specified in this document.  It also includes
>    configuration that enables the ingress LSR to determine the method
>    used by the egress LSR to identify Operations, Administration, and
>    Maintenance (OAM) packets, e.g., whether the Time to Live (TTL) of
>    the innermost MPLS label needs to be set to 1 to enable the egress
>    LSR to identify the OAM packet.  For fault detection for MPLS PWs,
>    this document assumes that the PW control channel type [RFC5085] is
>    configured and the support of LSP Ping is also configured.
> =20
> In Section 6 "Session Establishment":
> =20
> A BFD session is bootstrapped using LSP Ping.=20
> ...
>    To establish a BFD session, an LSP Ping
>    Echo request message MUST carry the local discriminator assigned by
>    the ingress LSR for the BFD session.  This MUST subsequently be =
used
>    as the My Discriminator field in the BFD session packets sent by =
the
>    ingress LSR.
>=20
> And from Section 6.1. "BFD Discriminator TLV in LSP Ping":
> =20
>    LSP Ping Echo request and Echo reply messages carry a BFD
>    discriminator TLV for the purpose of session establishment as
>    described above.  IANA has assigned a type value of 15 to this TLV.
>    This TLV has a length of 4.  The value contains the 4-byte local
>    discriminator that the LSR, sending the LSP Ping message, =
associates
>    with the BFD session.
>=20
>    If the BFD session is not in UP state, the periodic LSP Ping Echo
>    request messages MUST include the BFD Discriminator TLV.
> =20
>=20
> The highlighted text suggests to me that RFC 5884 mandates usage of =
LSP Ping for bootstrapping of BFD sessions. Taking into account that it =
supports BFD session per FEC for a given LSP, I do not see any =
alternative to this method.
> =20
> =20
> Did I miss something substantial?
> =20
> Regards,
>      Sasha
> =20
> =20
>=20
>=20
> ________________________________________
> From: Gregory Mirsky [gregory.mirsky@ericsson.com]
> Sent: Friday, February 10, 2012 10:18 PM
> To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen; Tom =
Sanders; Nitin Bahadur
> Cc: rtg-bfd@ietf.org
> Subject: RE: IP Address Schemes for BFD on LAG interfaces
>=20
> Dear Sasha,
> AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is =
optional. Thus use of Router Alert is not mandated by RFC 5884.
>=20
> What do you think?
>=20
>         Regards,
>                 Greg
>=20

--
Marc Binderberger           


--Apple-Mail-2-610158770
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hello Alexander and Greg,

The highlighted =
text suggests to me that RFC 5884 mandates usage of LSP =
Ping for bootstrapping of BFD sessions. Taking into =
account that it supports BFD session per FEC for a given LSP, I do not =
see any alternative to this =
method.

I agree. The first sentence in section 6 was =
already enough for me. It seems obvious to me that RFC5884 is tightly =
coupling BFD and LSP ping, nothing =
optional.

Now Greg's email had 2 statements:

"AFAIK, use of LSP Ping to bootstrap a BFD =
session over MPLS LSP is optional. Thus use of Router Alert is not =
mandated by RFC 5884."


The first sentence you have answered. For the =
second sentence I assume this is related to BFD packets (?). And indeed =
RFC5884 is not mentioning router alert a single time, neither as option =
nor as label. My understanding is the BFD packet has no router alert =
option in it's IP header.

I have sent an email to George, one of the =
authors of RFC5884 and RFC4379, why LSP ping echo requests - with an IP =
header very similar to BFD in RFC5884 - need to carry RA option but BFD =
does not.


Did I miss something =
substantial?

If so then you are not alone =
;-)


Regards, Marc



On =
2012-02-11, at 11:24 , Alexander Vainshtein wrote:

Dear =
Greg,
Regarding your claim that ""use of LSP Ping to =
bootstrap a BFD session over MPLS LSP is optional" - quoting from =
RFC 5884:
In Section 4 "Theory of =
operation"
 
   To =
enable fault detection procedures specified in this document, for
   a particular MPLS LSP, this document requires the ingress and egress
   LSRs to be configured.  This includes configuration for supporting
   BFD and LSP Ping as specified in this document.  It also =
includes
   configuration that enables the ingress LSR to determine the method
   used by the egress LSR to identify Operations, Administration, and
   Maintenance (OAM) packets, e.g., whether the Time to Live (TTL) of
   the innermost MPLS label needs to be set to 1 to enable the egress

   LSR =
to identify the OAM packet.  For fault detection for MPLS PWs,
   this document assumes that the PW control channel type [RFC5085] is
   configured and the support of LSP Ping is also =
configured.
 
In Section 6 =
"Session Establishment":
 
A BFD session is bootstrapped using LSP Ping. =

   =
To establish a BFD =
session, an LSP Ping
   Echo request message MUST carry the local discriminator assigned by
   the ingress LSR for the BFD session.  This MUST subsequently be used
   as the My Discriminator field in the BFD session packets sent by the
   ingress LSR.

And from =
Section 6.1. "BFD Discriminator TLV in LSP Ping":
 
   =
LSP Ping Echo =
request and Echo reply messages carry a BFD
   discriminator TLV for the purpose of session establishment as
   described above.  IANA has assigned a type value of 15 to this =
TLV.
   This TLV has a length of 4.  The value contains the 4-byte local
   discriminator that the LSR, sending the LSP Ping message, associates
   with the BFD session.

   If the BFD =
session is not in UP state, the periodic LSP Ping Echo
   request messages MUST include the BFD Discriminator =
TLV.
 

The highlighted =
text suggests to me that RFC 5884 =
mandates usage of LSP Ping for bootstrapping of BFD =
sessions. Taking into account that it =
supports BFD session per FEC for a given LSP, I do not see any =
alternative to this method.
 
 
Did I miss something =
substantial?
 
Regards,
     Sasha
 
 
 [gregory.mirsky@ericsson.com<=
a>]
Sent: Friday, February 10, 2012 10:18 PM
To: =
Alexander Vainshtein; =
Bhatia, Manav (Manav); Mach =
Chen; Tom Sanders; Nitin Bahadur
Cc:<=
span class=3D"Apple-converted-space"> rtg-bfd@ietf.org
Sub=
ject: RE: IP Address Schemes for BFD on LAG interfaces

Dear =
Sasha,
AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS =
LSP is optional. Thus use of Router Alert is not mandated by RFC =
5884.

What do you =
think?

        =
Regards,
          &n=
bsp;     =
Greg




--
marc@sniff.de>



=

--Apple-Mail-2-610158770--

From Alexander.Vainshtein@ecitele.com  Sat Feb 11 07:26:02 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 D9D4321F84FC for ; Sat, 11 Feb 2012 07:26:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.628
X-Spam-Level: 
X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-1.310, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 3pB84GX7mANR for ; Sat, 11 Feb 2012 07:26:01 -0800 (PST)
Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id D77D721F84EB for ; Sat, 11 Feb 2012 07:26:00 -0800 (PST)
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328973955!14936350!2
X-Originating-IP: [147.234.242.234]
X-StarScan-Version: 6.5.5; banners=-,-,-
Received: (qmail 8457 invoked from network); 11 Feb 2012 15:25:58 -0000
Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-12.tower-216.messagelabs.com with SMTP; 11 Feb 2012 15:25:58 -0000
X-AuditID: 93eaf2e7-b7f2a6d000000e7d-03-4f36946a6281
Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 20.B7.03709.A64963F4; Sat, 11 Feb 2012 18:16:42 +0200 (IST)
Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sat, 11 Feb 2012 17:25:57 +0200
From: Alexander Vainshtein 
To: Marc Binderberger , Gregory Mirsky 
Date: Sat, 11 Feb 2012 17:24:22 +0200
Subject: RE: IP Address Schemes for BFD on LAG interfaces
Thread-Topic: IP Address Schemes for BFD on LAG interfaces
Thread-Index: AczoqjhUBN8XoVqwTFSztlbRX8f6HwAJZGcU
Message-ID: 
References:  <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com>,  ,   ,    <9FF62A05-99C0-4E48-A5E5-CA24FD9C953F@sniff.de>, <39DA64CF-D9B5-4661-AE4B-0250168EC7CB@sniff.de>
In-Reply-To: <39DA64CF-D9B5-4661-AE4B-0250168EC7CB@sniff.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C760116342AE50AILPTMAIL02e_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELsWRmVeSWpSXmKPExsUy+dWnL7rZU8z8DR7GWzx/0sVocWGtsMXs K/+ZLT7/2cbowOLx6+tVNo+WI29ZPZYs+cnk0bq6myWAJaqB0SYxLy+/JLEkVSEltTjZVimg KLMsMblSSSEzxVbJUEmhICcxOTU3Na/EVimxoCA1L0XJjssGKJiZp5Cal5yfkpmXbqvkGeyv a2FhaqlrqGSnpmxobM0VkpFZrJCqm5uYmaOQm1pcnJieqgAUAbk5LyU1RSEtv0ihJCNVoShh MnPGn5PTWQsWzGSseNbM08B4q5Gxi5GTQ0LARGL7563MELaYxIV769m6GLk4hAT2M0rs/vqO FcKZxijx4/gTVpAqNgFbiU2r77KB2CICoRJfT04B62YW8JaYMr8fzGYRUJXovX2cCcQWFrCU uNw7nQmi3kpi17K3ULaRxIWVn8Cu4BUIlDg09STUsgusEtfPrwJbxilgI7Ht50awoYxA530/ tYYJYpm4xK0n85kgzhaQWLLnPNQLohIvH/9jhagXlbjTvp4Roj5f4m7nHDaIZYISJ2c+YYGo l5Q4uOIGywRGsVlIxs5C0jILSQtEXE/ixtQpbBC2tsSyha+ZIWxdiRn/DrEgiy9gZF/FKJqZ U1CSlJtuYKiXmpxZkpqTqpecn7uJEZKgnu9g/DVf5RCjAAejEg/vggZTfyHWxLLiytxDjJIc TEqivP/azPyF+JLyUyozEosz4otKc1KLDzFKcDArifCmOgPleFMSK6tSi/JhUq7A4J/ILMWd nA9KBiXxxgYGuDlK4rxPk9/4CgmkAxNndmpqQWoRzBwZDg4lCd5f7UArBItS01Mr0jJzShDS TBycIGfwAJ3xA6SGt7ggMbc4Mx0if4pRUUqc9wJIQgAkkVGaB9cLykr1////f8UoDvS0MO9J kCoeYKKF634FNJgJaLD0OROQwcCMA5eSamB8KPZ6XfesML7rzwuzlB7GfEmv+XZ/rtD/SZyX HfL3et/NNnTR6KjuirlX+eXrelbH12fa6sVnGG3oKohz9r10sen7+6ez5x9/eXdOxP25Udu2 m6p++h+w1Tt9p+PS4AyODCaznDm8+s9u7v43xW/t1qWJq4WflnFP5eNsjTDpUC/Jtt74vm6D EktxRqKhFnNRcSIAfIEFeSUEAAA=
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: Sat, 11 Feb 2012 15:26:03 -0000

--_000_A3C5DF08D38B6049839A6F553B331C760116342AE50AILPTMAIL02e_
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable

Marc hi,
Lots of thanks for a prompt response.

Regarding your question to George "why LSP ping echo requests - with an IP h=
eader very similar to BFD in RFC5884 - need to carry RA option but BFD does=
 not" - I can only offer my guess (FWIW):

LSP Ping  verifies (among other things) consistency between the CP and DP. H=
ence it takes care of the use case when the MPLS Echo request packet is proc=
essed by an LSR that is not related to the original LSP being pinged (e.g.,=
 because DP is broken). RA option in the IP header effectively guarantees th=
at the packet goes to the control plane instead of just being discarded,

BFD in LSP assumes that the CP and DP are congruent and just checks the DP i=
ntegrity. If the BFD-in-LSP packet ends in a wrong LSR, the BFD session will=
 fail, but BFD will not happen in isolating the DP fault that has caused thi=
s. Hence no need for RA option.

 My 2c,
     Sasha


________________________________
From: Marc Binderberger [marc@sniff.de]
Sent: Saturday, February 11, 2012 12:46 PM
To: Alexander Vainshtein; Gregory Mirsky
Cc: Mach Chen; rtg-bfd@ietf.org
Subject: Re: IP Address Schemes for BFD on LAG interfaces

Hello Alexander and Greg,

The highlighted text suggests to me that RFC 5884 mandates usage of LSP Ping=
 for bootstrapping of BFD sessions. Taking into account that it supports BFD=
 session per FEC for a given LSP, I do not see any alternative to this metho=
d.

I agree. The first sentence in section 6 was already enough for me. It seems=
 obvious to me that RFC5884 is tightly coupling BFD and LSP ping, nothing op=
tional.

Now Greg's email had 2 statements:

"AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is optional=
. Thus use of Router Alert is not mandated by RFC 5884."


The first sentence you have answered. For the second sentence I assume this=
 is related to BFD packets (?). And indeed RFC5884 is not mentioning router=
 alert a single time, neither as option nor as label. My understanding is th=
e BFD packet has no router alert option in it's IP header.

I have sent an email to George, one of the authors of RFC5884 and RFC4379, w=
hy LSP ping echo requests - with an IP header very similar to BFD in RFC5884=
 - need to carry RA option but BFD does not.


Did I miss something substantial?

If so then you are not alone ;-)


Regards, Marc



On 2012-02-11, at 11:24 , Alexander Vainshtein wrote:

Dear Greg,
Regarding your claim that ""use of LSP Ping to bootstrap a BFD session over=
 MPLS LSP is optional" - quoting from RFC 5884:
In Section 4 "Theory of operation"



   To enable fault detection procedures specified in this document, for
   a particular MPLS LSP, this document requires the ingress and egress
   LSRs to be configured.  This includes configuration for supporting
   BFD and LSP Ping as specified in this document.  It also includes
   configuration that enables the ingress LSR to determine the method
   used by the egress LSR to identify Operations, Administration, and
   Maintenance (OAM) packets, e.g., whether the Time to Live (TTL) of
   the innermost MPLS label needs to be set to 1 to enable the egress


   LSR to identify the OAM packet.  For fault detection for MPLS PWs,
   this document assumes that the PW control channel type [RFC5085] is
   configured and the support of LSP Ping is also configured.



In Section 6 "Session Establishment":



A BFD session is bootstrapped using LSP Ping.

...

   To establish a BFD session, an LSP Ping
   Echo request message MUST carry the local discriminator assigned by
   the ingress LSR for the BFD session.  This MUST subsequently be used
   as the My Discriminator field in the BFD session packets sent by the
   ingress LSR.

And from Section 6.1. "BFD Discriminator TLV in LSP Ping":



   LSP Ping Echo request and Echo reply messages carry a BFD
   discriminator TLV for the purpose of session establishment as
   described above.  IANA has assigned a type value of 15 to this TLV.
   This TLV has a length of 4.  The value contains the 4-byte local
   discriminator that the LSR, sending the LSP Ping message, associates
   with the BFD session.

   If the BFD session is not in UP state, the periodic LSP Ping Echo
   request messages MUST include the BFD Discriminator TLV.



The highlighted text suggests to me that RFC 5884 mandates usage of LSP Ping=
 for bootstrapping of BFD sessions. Taking into account that it supports BFD=
 session per FEC for a given LSP, I do not see any alternative to this metho=
d.





Did I miss something substantial?



Regards,
     Sasha






________________________________________
From: Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Friday, February 10, 2012 10:18 PM
To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nit=
in Bahadur
Cc: rtg-bfd@ietf.org
Subject: RE: IP Address Schemes for BFD on LAG interfaces

Dear Sasha,
AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is optional.=
 Thus use of Router Alert is not mandated by RFC 5884.

What do you think?

        Regards,
                Greg


--
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.


--_000_A3C5DF08D38B6049839A6F553B331C760116342AE50AILPTMAIL02e_
Content-Type: text/html; charset="iso-8859-1"
content-transfer-encoding: quoted-printable










Marc hi,


Lots of thanks for a prompt response.


 


Regarding your question to George "=
why LSP ping echo requests - with an IP header very similar to BFD in RFC588=
4 - need to carry RA option but BFD does not" - I can only offer m=
y guess (FWIW):


 


LSP Ping  verifies (among other thi=
ngs) consistency between the CP and DP. Hence it takes care of the use case=
 when the MPLS Echo request packet is processed by an LSR that is not relate=
d to the original LSP being pinged (e.g.,
 because DP is broken). RA option in the IP header effectively gua=
rantees that the packet goes to the control plane instead of=
 just being discarded,


 


BFD in LSP assumes that the CP and DP ar=
e congruent and just checks the DP integrity. If the BFD-in-LSP packet ends=
 in a wrong LSR, the BFD session will fail, but BFD will not happen in isola=
ting the DP fault that has caused
 this. Hence no need for RA option.


 


 My 2c,


     Sasha

 


&nb=
sp;





From: Marc Binderb=
erger [marc@sniff.de]

Sent: Saturday, February 11, 2012 12:46 PM

To: Alexander Vainshtein; Gregory Mirsky

Cc: Mach Chen; rtg-bfd@ietf.org

Subject: Re: IP Address Schemes for BFD on LAG interfaces












Hello Alexander and Greg,












The highlighted text suggests to me that RFC 5884 ma=
ndates usage of LSP Ping for bootstrapping of BFD sessions. Taking into
 account that it supports BFD session per FEC for a given LSP, I do not see=
 any alternative to this method.













I agree. The first sentence in section 6 was=
 already enough for me. It seems obvious to me that RFC5884 is tightly coupl=
ing BFD and LSP ping, nothing optional.







Now Greg's email had 2 statements:







"AFAIK, use of LSP Ping to bootstrap a=
 BFD session over MPLS LSP is optional. Thus use of Router Alert is not mand=
ated by RFC 5884."












The first sentence you have answered. For th=
e second sentence I assume this is related to BFD packets (?). And indeed RF=
C5884 is not mentioning router alert
 a single time, neither as option nor as label. My understanding is the BFD=
 packet has no router alert option in it's IP header.







I have sent an email to George, one of the a=
uthors of RFC5884 and RFC4379, why LSP ping echo requests - with an IP heade=
r very similar to BFD in RFC5884 - need
 to carry RA option but BFD does not.


















Did I miss something substantial?













If so then you are not alone ;-)












Regards, Marc

















On 2012-02-11, at 11:24 , Alexander Vainshtein wrote:








Dear Greg,


Regarding your claim that ""use of LSP Ping to bootstrap a B=
FD session over MPLS LSP is optional" - quoting from RFC 5884:



In Section 4 "Theory of operation"


 



   To enable fault detection procedures specified in this document, for
   a particular MPLS LSP, this document requires the ingress and egress
   LSRs to be configured.  =
This includes configuration for supporting
   BFD and LSP Ping as specified in this document.  It also includes
   configuration that enables the ingress LSR to determine the method
   used by the egress LSR to identify Operations, Administration, and
   Maintenance (OAM) packets, e.g., whether the Time to Live (TTL) of
   the innermost MPLS label needs to be set to 1 to enable the egress



   LSR to identify the OAM packet.  For fault detection for MPLS PWs,
   this document assumes that the PW control channel type [RFC5085] is
   configured and the support of LSP Ping is also configured.


 


In Section 6 "Session Establishment":


 


A BFD session is=
 bootstrapped using LSP Ping. 


...


   To establish a BFD=
 session, an LSP Ping
   Echo request message MUST carry the local discriminator assigned by
   the ingress LSR for the BFD session.  This MUST subsequently be used
   as the My Discriminator field in the BFD session packets sent by the
   ingress LSR.




And from Section 6.1. "BFD Discriminator TLV in LSP Ping":


 



   LSP Ping Echo reque=
st and Echo reply messages carry a BFD
   discriminator TLV for the purpose of session establishment as
   described above.  IANA has assigned a type value of 15 to this TLV=
.
   This TLV has a length of 4.  The value contains the 4-byte local
   discriminator that the LSR, sending the LSP Ping message, associates
   with the BFD session.

   If the BFD session is no=
t in UP state, the periodic LSP Ping Echo
   request messages MUST include the BFD Discriminator TLV.



 





The highlighted text suggests to me that RFC 5884 mandates usage of LSP Ping for boot=
strapping of BFD sessions. Taking into account that it supports BFD session
 per FEC for a given LSP, I do not see any alternative to this method.


 


 


Did I miss something substantial?


 


Regards,


     Sasha


 


 






________________________________________

From: Gregory Mirsky =
[gregory.mirsky@ericsson.com]

Sent: Friday, February 10, 2012 10:18 PM

To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach C=
hen; Tom Sanders; Nitin Bahadur

Cc: rtg-bfd@ietf.org

Subject: RE: IP Address Schemes for BFD on LAG interfaces



Dear Sasha,

AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is optional.=
 Thus use of Router Alert is not mandated by RFC 5884.



What do you think?



        Regards,

            &nbs=
p;   Greg






















--

Marc Binderberger           <marc@sniff.de>













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.





--_000_A3C5DF08D38B6049839A6F553B331C760116342AE50AILPTMAIL02e_--

From gregimirsky@gmail.com  Sat Feb 11 07:49:59 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 04AF721F84FC for ; Sat, 11 Feb 2012 07:49:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.48
X-Spam-Level: 
X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.234,  BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 c1ZtZqOx0KCJ for ; Sat, 11 Feb 2012 07:49:58 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C2C7221F84C9 for ; Sat, 11 Feb 2012 07:49:57 -0800 (PST)
Received: by obbwd15 with SMTP id wd15so5903471obb.31 for ; Sat, 11 Feb 2012 07:49:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l3KCex/JvsbaS35vpt00QtQxUWAGtw4sMcmIFONZ7Ho=; b=ZsQyQMSFKl1B8zKd5haYSeuZPkQxpO3BPAFC+B1m3K/xZv2Q8oGL9xUh6s2wmbGdvt 8K4OGN228mpk7H7HdPmrEvfSNjm4Saepj80LrPy8xnJU+/CQ7Ww221L1NaFP5nZH1z1l oK/OlNNGjwN7rVIrkWTe3aIfM0LCikR5IUZNU=
MIME-Version: 1.0
Received: by 10.60.1.2 with SMTP id 2mr2155654oei.16.1328975397239; Sat, 11 Feb 2012 07:49:57 -0800 (PST)
Received: by 10.182.38.67 with HTTP; Sat, 11 Feb 2012 07:49:57 -0800 (PST)
In-Reply-To: <39DA64CF-D9B5-4661-AE4B-0250168EC7CB@sniff.de>
References:  <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com>       <9FF62A05-99C0-4E48-A5E5-CA24FD9C953F@sniff.de> <39DA64CF-D9B5-4661-AE4B-0250168EC7CB@sniff.de>
Date: Sat, 11 Feb 2012 07:49:57 -0800
Message-ID: 
Subject: Re: IP Address Schemes for BFD on LAG interfaces
From: Greg Mirsky 
To: Marc Binderberger 
Content-Type: multipart/alternative; boundary=e89a8fb1fe2877ba7c04b8b232a6
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: Sat, 11 Feb 2012 15:49:59 -0000

--e89a8fb1fe2877ba7c04b8b232a6
Content-Type: text/plain; charset=ISO-8859-1

Dear Sasha, Marc, et al.
Greatly appreciate our discussion.
The LSP Ping is widely used mechanism to bootstrap BFD sessions over MPLS
LSP because of PHP. If an operator disables PHP then no bootstrapping
needed. Alternatively, mapping might be statically configured on the remote
LER.

My $.02

Kind regards,
Greg

On Sat, Feb 11, 2012 at 2:46 AM, Marc Binderberger  wrote:

> Hello Alexander and Greg,
>
> The highlighted text suggests to me that RFC 5884 mandates usage of LSP
> Ping for bootstrapping of BFD sessions. Taking into account that it
> supports BFD session per FEC for a given LSP, I do not see any alternative
> to this method.
>
>
> I agree. The first sentence in section 6 was already enough for me. It
> seems obvious to me that RFC5884 is tightly coupling BFD and LSP ping,
> nothing optional.
>
> Now Greg's email had 2 statements:
>
> "AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is
> optional. Thus use of Router Alert is not mandated by RFC 5884."
>
>
> The first sentence you have answered. For the second sentence I assume
> this is related to BFD packets (?). And indeed RFC5884 is not mentioning
> router alert a single time, neither as option nor as label. My
> understanding is the BFD packet has no router alert option in it's IP
> header.
>
> I have sent an email to George, one of the authors of RFC5884 and RFC4379,
> why LSP ping echo requests - with an IP header very similar to BFD in
> RFC5884 - need to carry RA option but BFD does not.
>
>
> Did I miss something substantial?
>
>
> If so then you are not alone ;-)
>
>
> Regards, Marc
>
>
>
> On 2012-02-11, at 11:24 , Alexander Vainshtein wrote:
>
> Dear Greg,
> Regarding your claim that ""use of LSP Ping to bootstrap a BFD session
> over MPLS LSP is optional" - quoting from RFC 5884:
> In Section 4 "Theory of operation"
>
>
>
>    To enable fault detection procedures specified in this document, for
>    a particular MPLS LSP, this document requires the ingress and egress
>    LSRs to be configured.  This includes configuration for supporting
>    BFD and LSP Ping as specified in this document.  It also includes
>    configuration that enables the ingress LSR to determine the method
>    used by the egress LSR to identify Operations, Administration, and
>    Maintenance (OAM) packets, e.g., whether the Time to Live (TTL) of
>    the innermost MPLS label needs to be set to 1 to enable the egress
>
>    LSR to identify the OAM packet.  For fault detection for MPLS PWs,
>    this document assumes that the PW control channel type [RFC5085] is
>    configured and the support of LSP Ping is also configured.
>
>
>
> In Section 6 "Session Establishment":
>
>
>
> A BFD session is bootstrapped using LSP Ping.
>
> ...
>
>    To establish a BFD session, an LSP Ping
>    Echo request message MUST carry the local discriminator assigned by
>    the ingress LSR for the BFD session.  This MUST subsequently be used
>    as the My Discriminator field in the BFD session packets sent by the
>    ingress LSR.
>
>
> And from Section 6.1. "BFD Discriminator TLV in LSP Ping":
>
>
>
>    LSP Ping Echo request and Echo reply messages carry a BFD
>    discriminator TLV for the purpose of session establishment as
>    described above.  IANA has assigned a type value of 15 to this TLV.
>    This TLV has a length of 4.  The value contains the 4-byte local
>    discriminator that the LSR, sending the LSP Ping message, associates
>    with the BFD session.
>
>    If the BFD session is not in UP state, the periodic LSP Ping Echo
>    request messages MUST include the BFD Discriminator TLV.
>
>
>
> The highlighted text suggests to me that RFC 5884 mandates usage of LSP
> Ping for bootstrapping of BFD sessions. Taking into account that it
> supports BFD session per FEC for a given LSP, I do not see any alternative
> to this method.
>
>
>
>
> Did I miss something substantial?
>
>
> Regards,
>      Sasha
>
>
>
>
>
>
> ________________________________________
> From: Gregory Mirsky [gregory.mirsky@ericsson.com]
> Sent: Friday, February 10, 2012 10:18 PM
> To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen; Tom
> Sanders; Nitin Bahadur
> Cc: rtg-bfd@ietf.org
> Subject: RE: IP Address Schemes for BFD on LAG interfaces
>
> Dear Sasha,
> AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is
> optional. Thus use of Router Alert is not mandated by RFC 5884.
>
> What do you think?
>
>         Regards,
>                 Greg
>
>
> --
> Marc Binderberger           
>
>

--e89a8fb1fe2877ba7c04b8b232a6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Dear Sasha, Marc, et al.
Greatly appreciate our discussion.
The=20
LSP Ping is widely used mechanism to bootstrap BFD sessions over MPLS=20
LSP because of PHP. If an operator disables PHP then no bootstrapping=20
needed. Alternatively, mapping might be statically configured on the=20
remote LER.


My $.02

Kind regards,
Greg

=
On Sat, Feb 11, 2012 at 2:46 AM, Marc Binderberger <marc@sniff.de> wrote:


Hello Alexander and Greg,=




=



The=A0highlighted text=A0suggests=A0to me that =
RFC 5884 mandates usage of LSP Ping for bootstrapping of BFD sessions.=A0Ta=
king=A0into account that it supports BFD session per FEC for a given=
 LSP, I do not see any alternative to this method.



I agree. The first sentence in section 6 was already en=
ough for me. It seems obvious to me that RFC5884 is tightly coupling BFD an=
d LSP ping, nothing optional.



Now Greg's email=
 had 2 statements:



&q=
uot;AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is opti=
onal. Thus use of Router Alert is not mandated by RFC 5884."




The first se=
ntence you have answered. For the second sentence I assume this is related =
to BFD packets (?). And indeed RFC5884 is not mentioning router alert a sin=
gle time, neither as option nor as label. My understanding is the BFD packe=
t has no router alert option in it's IP header.



I have sent an email=
 to George, one of the authors of RFC5884 and RFC4379, why LSP ping echo re=
quests - with an IP header very similar to BFD in RFC5884 - need to carry R=
A option but BFD does not.



=



Did I miss something substantial?
<=
/div>



If so then you are not alone ;-)




Re=
gards, Marc





On 2012-02-11, at 11:24 , Alexander =
Vainshtein wrote:



Dear Greg,
Regard=
ing your claim that ""use of LSP Ping to bootstrap a BFD session =
over MPLS LSP is optional" - quoting from RFC 5884:


In Section 4 "Theory of operation"
=A0


   To enable fault detection procedures specified in this document, for
   a particular MPLS LSP, this document requires the ingress and egress
   LSRs to be configured.  =
This includes configuration for supporting
   BFD and LSP Ping as specified in this document.  It also includes
   configuration that enables the ingress LSR to determine the method
   used by the egress LSR to identify Operations, Administration, and
   Maintenance (OAM) packets, e.g., whether the Time to Live (TTL) of
   the innermost MPLS label needs to be set to 1 to enable the egress

   LSR to identi=
fy the OAM packet.  For fau=
lt detection for MPLS PWs,
   this document assumes that the PW control channel type [RFC5085] is
   configured and the support of LSP Ping is also configured.
<=
pre style=3D"margin-right:0px;text-indent:0px;letter-spacing:normal;text-tr=
ansform:none;font:normal normal normal 13px/1.2em monospace;margin-left:0px=
;margin-bottom:0px;margin-top:0px;word-spacing:0px">
=A0
In Section 6 "Session =
Establishment":
=A0
A BFD session is bootstrapped using LSP Ping.
...
   To establish a BFD sessi=
on, an LSP Ping
   Echo request message MUST carry the local discriminator assigned by
   the ingress LSR for the BFD session.  This MUST subsequently be used
   as the My Discriminator field in the BFD session packets sent by the
   ingress LSR.

And from Section 6.1. "BFD Discriminator TLV in LSP Ping":

=A0

   LSP Ping Echo request an=
d Echo reply messages carry a BFD
   discriminator TLV for the purpose of session establishment as
   described above.  IANA has assigned a type value of 15 to this TL=
V.
   This TLV has a length of 4.  The value contains the 4-byte local
   discriminator that the LSR, sending the LSP Ping message, associates
   with the BFD session.

   If the BFD session is no=
t in UP state, the periodic LSP Ping Echo
   request messages MUST include the BFD Discriminator TLV.

=A0

=
The=A0highlighted text=A0suggests=A0to me that RFC 5884= mandates usage of LSP Ping for bootstrapping of BFD sessions.=A0Taking<= /a>=A0into account that it supports BFD session per FEC for a = given LSP, I do not see any alternative to this method.

=A0

Did I miss something substantial?

Regards,

=A0<= /p>

=A0



___________________= _____________________
From: Gregory=A0Mirsky=A0[gregory.mirsky= @ericsson.com]
Sent: Friday, February 10, 2012 10:18 PM
To: Alexander Vainshtein= ; Bhatia,=A0Manav=A0(Manav)= ; Mach Chen; Tom Sanders;=A0Nitin=A0Bahadur
Cc:=A0rt= g-bfd@ietf.org
Subject: RE: IP Address Schemes for BFD= on LAG interfaces

Dear Sasha,
AFAIK, use of LSP Ping to bootstra= p a BFD session over MPLS LSP is optional. Thus use of Router Alert is not = mandated by RFC 5884.

What do you think?

=A0=A0=A0=A0=A0=A0=A0 Regards,
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Greg


--
Marc Binderberger =A0 =A0 =A0 =A0 =A0 <= ;marc@sniff.de>


--e89a8fb1fe2877ba7c04b8b232a6-- From Alexander.Vainshtein@ecitele.com Sat Feb 11 21:43:11 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 A6E4C21F85A2 for ; Sat, 11 Feb 2012 21:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-1.284, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 fDpxZvom9b80 for ; Sat, 11 Feb 2012 21:43:10 -0800 (PST) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 3182921F853B for ; Sat, 11 Feb 2012 21:43:08 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1329025385!14980224!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 10207 invoked from network); 12 Feb 2012 05:43:05 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-12.tower-216.messagelabs.com with SMTP; 12 Feb 2012 05:43:05 -0000 X-AuditID: 93eaf2e7-b7fb46d000005f52-59-4f375d496fab Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id A9.D1.24402.94D573F4; Sun, 12 Feb 2012 08:33:45 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sun, 12 Feb 2012 07:43:04 +0200 From: Alexander Vainshtein To: Greg Mirsky Date: Sun, 12 Feb 2012 07:41:28 +0200 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: Aczo1Jd91yD/p3NmTmCL8XtYphvJewAczR94 Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com> <9FF62A05-99C0-4E48-A5E5-CA24FD9C953F@sniff.de> <39DA64CF-D9B5-4661-AE4B-0250168EC7CB@sniff.de>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C760116342AE50BILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTfWwLYRjP27u2t24nt9rsXZGcM+ary8psHav4CLY/pBv+QWRO+2ovrndN r2RDKCGsQnzMUJKVzPfHkvmIrwQVhoTNpjKCLNtYDJEwxiKrux6zRNxfv3t+H89zl+chMGOl 3kRwgh/5BJZndAZ8b9fnbnPR0jx79uFnY6zfqt5orZ0dQWA99DSGWb/8vAym44W9X6O6wquh V/rCmpofmsItZ7bjxfjiAChgBUH0s35EO5HksDHFPm416yhnaM5pYywM7eVZB/IgwW9jWK8X CU5mmoH+5ymQZZxAI8EhOjnBZWOKFtjNVuvkfLOFmTZ6pGXSVMNCNyfRyOxhOZ72IEliXYiW K8suYu5T1wN6b30NKOtrDGsDoCsIgiCBgFQOjF7q1Kl4CGx8XRvHRuomgK0NOUFgkHEVgFfb m3GF0FE2WHfmVVyUQmXCisv1egVj1DoYfv5Cq2CcGgV7K2/H64OpfNi8Y79G1U+B145//I0n wqY7F+NDkFQJ7NlYoVebVergvc/dcXOCTNRGY3EDkKfreXhWozZLgy86qjXq1BSsudGAqTgV vmvv06r6VPhyay1Q9SLcUtGtUZslwwcHO3BVnw5vn2zBd4EhoQGxoQGW0ACLWs+CLfsqdSoe D48feY+p2AwP9EXwgfUw0J8GqRzv9S/3uLItWcjB+RGPshyipw6oK9V5BfRWZ0QARQAmiWwc kWc3atnVUrknAtIJDZNKIrtcGrRcdJa7Wcld6lvFIykCIIExKSSalWs3kk62fA3yiX+o2fLv 342ZEh2ivLyCv3RSdvb/X5g08o3jwzwj5ZKXcyVCXuT7kzOMIBhINhXL7ZN9yIXKVnC8/y+t IRKUMZLkMc4rGlLysh6Jc6n8QzDClEaGFYJSCPcqod+rHNOGWCzWBdLkjx5M1imqJPnU+t1d crBGDh76OEcJlg+nnzIFwKatj6j7UgvfzZ8oych/VPZg/pLot/y2gifCKd2t4eLm+vQJoDWv raqAeIuaQmfnRI5yPy80J85buHTtetP2zjEfnn2PHm2YU5K5s3pqyqc9hyp6cpOPzX3cui00 dka4PhhYkzMXPzyrLZZpMEwZbrTPzE1cUnpXhLSUt+jY+HPt1xlccrOWcZhPYn8BZmiv6ScE AAA= 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, 12 Feb 2012 05:43:11 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760116342AE50BILPTMAIL02e_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Dear Greg, Lots of thanks for a prompt response. Regarding your statement " If an operator disables PHP then no bootstrapping= needed": IMHO any form of LSP merge (and not just PHP) requires bootstrapping for BFD= . Please consider the case of MP2P LSPs created by LDP when LSPs for a given I= Pv4 or IPv6 prefix originate at different head-end LSRs merge at some point= along the way so that the tail-end LSR cannot use the ingress label to disa= mbiguate the source even if this label is not popped. This is why RFC 6428 (that is limited to MPLS-TP with its prohibition on LSP= merge) does not require LPP ping for the bootstrapping of BFD sessions whil= e RFC 5884 requires it. My 2c, Sasha ________________________________ From: Greg Mirsky [gregimirsky@gmail.com] Sent: Saturday, February 11, 2012 5:49 PM To: Marc Binderberger Cc: Alexander Vainshtein; Gregory Mirsky; rtg-bfd@ietf.org Subject: Re: IP Address Schemes for BFD on LAG interfaces Dear Sasha, Marc, et al. Greatly appreciate our discussion. The LSP Ping is widely used mechanism to bootstrap BFD sessions over MPLS LS= P because of PHP. If an operator disables PHP then no bootstrapping needed.= Alternatively, mapping might be statically configured on the remote LER. My $.02 Kind regards, Greg On Sat, Feb 11, 2012 at 2:46 AM, Marc Binderberger > wrote: Hello Alexander and Greg, The highlighted text suggests to me that RFC 5884 mandates usage of LSP Ping= for bootstrapping of BFD sessions. Taking into account that it supports BFD= session per FEC for a given LSP, I do not see any alternative to this metho= d. I agree. The first sentence in section 6 was already enough for me. It seems= obvious to me that RFC5884 is tightly coupling BFD and LSP ping, nothing op= tional. Now Greg's email had 2 statements: "AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is optional= . Thus use of Router Alert is not mandated by RFC 5884." The first sentence you have answered. For the second sentence I assume this= is related to BFD packets (?). And indeed RFC5884 is not mentioning router= alert a single time, neither as option nor as label. My understanding is th= e BFD packet has no router alert option in it's IP header. I have sent an email to George, one of the authors of RFC5884 and RFC4379, w= hy LSP ping echo requests - with an IP header very similar to BFD in RFC5884= - need to carry RA option but BFD does not. Did I miss something substantial? If so then you are not alone ;-) Regards, Marc On 2012-02-11, at 11:24 , Alexander Vainshtein wrote: Dear Greg, Regarding your claim that ""use of LSP Ping to bootstrap a BFD session over= MPLS LSP is optional" - quoting from RFC 5884: In Section 4 "Theory of operation" To enable fault detection procedures specified in this document, for a particular MPLS LSP, this document requires the ingress and egress LSRs to be configured. This includes configuration for supporting BFD and LSP Ping as specified in this document. It also includes configuration that enables the ingress LSR to determine the method used by the egress LSR to identify Operations, Administration, and Maintenance (OAM) packets, e.g., whether the Time to Live (TTL) of the innermost MPLS label needs to be set to 1 to enable the egress LSR to identify the OAM packet. For fault detection for MPLS PWs, this document assumes that the PW control channel type [RFC5085] is configured and the support of LSP Ping is also configured. In Section 6 "Session Establishment": A BFD session is bootstrapped using LSP Ping. ... To establish a BFD session, an LSP Ping Echo request message MUST carry the local discriminator assigned by the ingress LSR for the BFD session. This MUST subsequently be used as the My Discriminator field in the BFD session packets sent by the ingress LSR. And from Section 6.1. "BFD Discriminator TLV in LSP Ping": LSP Ping Echo request and Echo reply messages carry a BFD discriminator TLV for the purpose of session establishment as described above. IANA has assigned a type value of 15 to this TLV. This TLV has a length of 4. The value contains the 4-byte local discriminator that the LSR, sending the LSP Ping message, associates with the BFD session. If the BFD session is not in UP state, the periodic LSP Ping Echo request messages MUST include the BFD Discriminator TLV. The highlighted text suggests to me that RFC 5884 mandates usage of LSP Ping= for bootstrapping of BFD sessions. Taking into account that it supports BFD= session per FEC for a given LSP, I do not see any alternative to this metho= d. Did I miss something substantial? Regards, Sasha ________________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Friday, February 10, 2012 10:18 PM To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nit= in Bahadur Cc: rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Dear Sasha, AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is optional.= Thus use of Router Alert is not mandated by RFC 5884. What do you think? Regards, Greg -- 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. --_000_A3C5DF08D38B6049839A6F553B331C760116342AE50BILPTMAIL02e_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
Dear Greg,
Lots of thanks for a prompt response.
 
Regarding your statement " If an op= erator disables PHP then no bootstrapping needed":
 
IMHO any form of LSP merge (and not just= PHP) requires bootstrapping for BFD.
Please c<= /font>onsider the case of MP2P LSPs created by LDP when LSPs for a given&nbs= p;IPv4 or IPv6 prefix originate at different head-end LSRs merge at some poi= nt along the way so that the tail-end LSR cannot use the ingress label to disambiguate the source even if this la= bel is not popped.
 
This is why RFC 6428 (that is limited to= MPLS-TP with its prohibition on LSP merge) does not require LPP ping for th= e bootstrapping of BFD sessions while RFC 5884 requires it.
 
My 2c,
     Sasha
 
 
 
From: Greg Mirsky= [gregimirsky@gmail.com]
Sent: Saturday, February 11, 2012 5:49 PM
To: Marc Binderberger
Cc: Alexander Vainshtein; Gregory Mirsky; rtg-bfd@ietf.org
Subject: Re: IP Address Schemes for BFD on LAG interfaces

Dear Sasha, Marc, et al.
Greatly appreciate our discussion.
The LSP Ping is widely used mechanism to bootstrap BFD sessions over MPLS LS= P because of PHP. If an operator disables PHP then no bootstrapping needed.= Alternatively, mapping might be statically configured on the remote LER.
My $.02

Kind regards,
Greg

On Sat, Feb 11, 2012 at 2:46 AM, Marc Binderberge= r <marc@sniff.de> wrote:
Hello Alexander and Greg,

The highlighted text suggests = to me that RFC 5884 mandates usage of LSP Ping for bootstrapping of BFD sess= ions. Taking into account that it supports BFD session per FEC for a given LSP, I do not see any alternative to this m= ethod.

I agree. The first sen= tence in section 6 was already enough for me. It seems obvious to me that RF= C5884 is tightly coupling BFD and LSP ping, nothing optional.<= /div>

Now Greg's email had 2= statements:

"AFAIK, use of LS= P Ping to bootstrap a BFD session over MPLS LSP is optional. Thus use of Rou= ter Alert is not mandated by RFC 5884."


The first sentence you= have answered. For the second sentence I assume this is related to BFD pack= ets (?). And indeed RFC5884 is not mentioning router alert a single time, ne= ither as option nor as label. My understanding is the BFD packet has no router alert option in it's IP heade= r.

I have sent an email t= o George, one of the authors of RFC5884 and RFC4379, why LSP ping echo reque= sts - with an IP header very similar to BFD in RFC5884 - need to carry RA op= tion but BFD does not.


Did I miss something substantial?

If so then you are not= alone ;-)


Regards, Marc



On 2012-02-11, at 11:24 , Alexander Vainshtein wrote:

Dear Greg,
Regarding your claim that ""use of LSP Ping to bootstrap a B= FD session over MPLS LSP is optional" - quoting from RFC 5884:
In Section 4 "Theory of operation"

 

   To enable f=
ault detection procedures specified in this document, for
   a particular MPLS LSP, this document requires the ingress and egress
   LSRs to be configured.  =
This includes configuration for supporting
   BFD and LSP Ping as specified in this document.  It also includes
   configuration that enables the ingress LSR to determine the method
   used by the egress LSR to identify Operations, Administration, and
   Maintenance (OAM) packets, e.g., whether the Time to Live (TTL) of
   the innermost MPLS label needs to be set to 1 to enable the egress

   LSR to iden=
tify the OAM packet.  For f=
ault detection for MPLS PWs,
   this document assumes that the PW control channel type [RFC5085] is
   configured and the support of LSP Ping is also configured.
&n=
bsp;
In Section 6 "Session Establishment":<=
/font>
 
A BFD session is bootstrapped using LSP Ping. 



...


   To establish a BFD session, an LSP Pin=
g
   Echo request message MUST carry the local discriminator assigned by
   the ingress LSR for the BFD session.  This MUST subsequently be used
   as the My Discriminator field in the BFD session packets sent by the
   ingress LSR.




And from Section 6.1. "BFD Discriminator TLV in LSP Ping":


 



   LSP Ping Echo request and Echo reply m=
essages carry a BFD
   discriminator TLV for the purpose of session establishment as
   described above.  IANA has assigned a type value of 15 to this TLV=
.
   This TLV has a length of 4.  The value contains the 4-byte local
   discriminator that the LSR, sending the LSP Ping message, associates
   with the BFD session.

   If the BFD session is no=
t in UP state, the periodic LSP Ping Echo
   request messages MUST include the BFD Discriminator TLV.



 





The highlighted text suggests to me that=
 RFC 5884 mandates usage of LSP Ping for bootstrapping of BFD sessions. =
;Taking into account that it supports BFD session p=
er FEC for a given LSP, I do not see any alternative to
 this method.


 


 


Did I miss something substantial?


 


Regards,


     Sasha


 


 






________________________________________

From: Gregory Mirsky [gregory.mirsky@ericsson.com]

Sent: Friday, February 10, 2012 10:18 PM

To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen; Tom Sanders; Nitin<=
/a> Bahadur

Cc: rtg-bfd@ietf.org

Subject: RE: IP Address Schemes for BFD on LAG interfaces



Dear Sasha,

AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is optional.=
 Thus use of Router Alert is not mandated by RFC 5884.



What do you think?



        Regards,

            &nbs=
p;   Greg

--
Marc Binderberger &nbs= p;         <marc@sni= ff.de>


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.

--_000_A3C5DF08D38B6049839A6F553B331C760116342AE50BILPTMAIL02e_-- From gregimirsky@gmail.com Sat Feb 11 21:54:30 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 6F86621F85B1 for ; Sat, 11 Feb 2012 21:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 qpFE6pwT4-Ae for ; Sat, 11 Feb 2012 21:54:29 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 168DC21F84FE for ; Sat, 11 Feb 2012 21:54:29 -0800 (PST) Received: by obbwd15 with SMTP id wd15so6358499obb.31 for ; Sat, 11 Feb 2012 21:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZA+MdjDEmYI/C1fbA74dLhnbideeyLUTULYnPEPXAns=; b=tFRjsVJpmAEj0DWxjDG74nsxvJTVaMWiOTvsMw4Ko89lNeFF49aFacWTdHf/zuAA5k nSqXsqdJzRNim/Of1EB7/4IUQ361eOyiVsPEH9zZ9hjvDBE56S3OnPLwgQRuWG1HTgBQ GP94TVd5SpBfgcHqPy6Bj/3765QBOhXxKfD0g= MIME-Version: 1.0 Received: by 10.60.27.6 with SMTP id p6mr2886428oeg.36.1329026068645; Sat, 11 Feb 2012 21:54:28 -0800 (PST) Received: by 10.182.38.67 with HTTP; Sat, 11 Feb 2012 21:54:28 -0800 (PST) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com> <9FF62A05-99C0-4E48-A5E5-CA24FD9C953F@sniff.de> <39DA64CF-D9B5-4661-AE4B-0250168EC7CB@sniff.de> Date: Sat, 11 Feb 2012 21:54:28 -0800 Message-ID: Subject: Re: IP Address Schemes for BFD on LAG interfaces From: Greg Mirsky To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=e89a8fb1ef18b805fb04b8bdfe09 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, 12 Feb 2012 05:54:30 -0000 --e89a8fb1ef18b805fb04b8bdfe09 Content-Type: text/plain; charset=ISO-8859-1 Dear Sasha, yes, MPLS-TP indeed excludes LSP merge but it doesn't exclude PHP (I still wonder why it is). AFAIK, PHP is disabled by default but, I imagine, can be enabled in MPLS-TP network, hence MPLS LSP bootstrapping would come handy. But I've brought up PHP to illustrate that use of MPLS LSP Ping as bootstrapping mechanism for MPLS BFD is not mandatory but optional. Kind regards, Greg On Sat, Feb 11, 2012 at 9:41 PM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Dear Greg, > Lots of thanks for a prompt response. > > Regarding your statement " If an operator disables PHP then no > bootstrapping needed": > > IMHO any form of LSP merge (and not just PHP) requires bootstrapping for > BFD. > Please consider the case of MP2P LSPs created by LDP when LSPs for a > given IPv4 or IPv6 prefix originate at different head-end LSRs merge at > some point along the way so that the tail-end LSR cannot use the ingress > label to disambiguate the source even if this label is not popped. > > This is why RFC 6428 (that is limited to MPLS-TP with its prohibition on > LSP merge) does not require LPP ping for the bootstrapping of BFD sessions > while RFC 5884 requires it. > > My 2c, > Sasha > > > > ------------------------------ > *From:* Greg Mirsky [gregimirsky@gmail.com] > *Sent:* Saturday, February 11, 2012 5:49 PM > *To:* Marc Binderberger > *Cc:* Alexander Vainshtein; Gregory Mirsky; rtg-bfd@ietf.org > *Subject:* Re: IP Address Schemes for BFD on LAG interfaces > > Dear Sasha, Marc, et al. > Greatly appreciate our discussion. > The LSP Ping is widely used mechanism to bootstrap BFD sessions over MPLS > LSP because of PHP. If an operator disables PHP then no bootstrapping > needed. Alternatively, mapping might be statically configured on the remote > LER. > > My $.02 > > Kind regards, > Greg > > On Sat, Feb 11, 2012 at 2:46 AM, Marc Binderberger wrote: > >> Hello Alexander and Greg, >> >> The highlighted text suggests to me that RFC 5884 mandates usage of >> LSP Ping for bootstrapping of BFD sessions. Taking into account that it >> supports BFD session per FEC for a given LSP, I do not see any alternative >> to this method. >> >> >> I agree. The first sentence in section 6 was already enough for me. It >> seems obvious to me that RFC5884 is tightly coupling BFD and LSP ping, >> nothing optional. >> >> Now Greg's email had 2 statements: >> >> "AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is >> optional. Thus use of Router Alert is not mandated by RFC 5884." >> >> >> The first sentence you have answered. For the second sentence I assume >> this is related to BFD packets (?). And indeed RFC5884 is not mentioning >> router alert a single time, neither as option nor as label. My >> understanding is the BFD packet has no router alert option in it's IP >> header. >> >> I have sent an email to George, one of the authors of RFC5884 and >> RFC4379, why LSP ping echo requests - with an IP header very similar to BFD >> in RFC5884 - need to carry RA option but BFD does not. >> >> >> Did I miss something substantial? >> >> >> If so then you are not alone ;-) >> >> >> Regards, Marc >> >> >> >> On 2012-02-11, at 11:24 , Alexander Vainshtein wrote: >> >> Dear Greg, >> Regarding your claim that ""use of LSP Ping to bootstrap a BFD session >> over MPLS LSP is optional" - quoting from RFC 5884: >> In Section 4 "Theory of operation" >> >> >> >> To enable fault detection procedures specified in this document, for >> a particular MPLS LSP, this document requires the ingress and egress >> LSRs to be configured. This includes configuration for supporting >> BFD and LSP Ping as specified in this document. It also includes >> configuration that enables the ingress LSR to determine the method >> used by the egress LSR to identify Operations, Administration, and >> Maintenance (OAM) packets, e.g., whether the Time to Live (TTL) of >> the innermost MPLS label needs to be set to 1 to enable the egress >> >> LSR to identify the OAM packet. For fault detection for MPLS PWs, >> this document assumes that the PW control channel type [RFC5085] is >> configured and the support of LSP Ping is also configured. >> >> >> >> In Section 6 "Session Establishment": >> >> >> >> A BFD session is bootstrapped using LSP Ping. >> >> ... >> >> To establish a BFD session, an LSP Ping >> Echo request message MUST carry the local discriminator assigned by >> the ingress LSR for the BFD session. This MUST subsequently be used >> as the My Discriminator field in the BFD session packets sent by the >> ingress LSR. >> >> >> And from Section 6.1. "BFD Discriminator TLV in LSP Ping": >> >> >> >> LSP Ping Echo request and Echo reply messages carry a BFD >> discriminator TLV for the purpose of session establishment as >> described above. IANA has assigned a type value of 15 to this TLV. >> This TLV has a length of 4. The value contains the 4-byte local >> discriminator that the LSR, sending the LSP Ping message, associates >> with the BFD session. >> >> If the BFD session is not in UP state, the periodic LSP Ping Echo >> request messages MUST include the BFD Discriminator TLV. >> >> >> >> The highlighted text suggests to me that RFC 5884 mandates usage of LSP >> Ping for bootstrapping of BFD sessions. Taking into account that it >> supports BFD session per FEC for a given LSP, I do not see any alternative >> to this method. >> >> >> >> >> Did I miss something substantial? >> >> >> Regards, >> Sasha >> >> >> >> >> >> >> ________________________________________ >> From: Gregory Mirsky [gregory.mirsky@ericsson.com] >> Sent: Friday, February 10, 2012 10:18 PM >> To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen; Tom >> Sanders; Nitin Bahadur >> Cc: rtg-bfd@ietf.org >> Subject: RE: IP Address Schemes for BFD on LAG interfaces >> >> Dear Sasha, >> AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is >> optional. Thus use of Router Alert is not mandated by RFC 5884. >> >> What do you think? >> >> Regards, >> Greg >> >> >> -- >> 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. > --e89a8fb1ef18b805fb04b8bdfe09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Sasha,
yes, MPLS-TP indeed excludes LSP merge but it doesn't ex= clude PHP (I still wonder why it is). AFAIK, PHP is disabled by default but= , I imagine, can be enabled in MPLS-TP network, hence MPLS LSP bootstrappin= g would come handy.
But I've brought up PHP to illustrate that use of MPLS LSP Ping as boot= strapping mechanism for MPLS BFD is not mandatory but optional.

Kind= regards,
Greg

On Sat, Feb 11, 2012 at= 9:41 PM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:
Dear Greg,
Lots of thanks for a prompt response.
=A0
Regarding your statement " I= f an operator disables PHP then no bootstrapping needed":
=A0
IMHO any form of LSP merge (and not jus= t PHP) requires bootstrapping for BFD.
Please c= onsider the case of MP2P LSPs created by LDP when LSPs for a given= =A0IPv4 or IPv6 prefix originate at different head-end LSRs merge at some p= oint along the way so that the tail-end LSR cannot use the ingress label to disambiguate the source even if this l= abel is not popped.
=A0
This is why RFC 6428 (that is limited t= o MPLS-TP with its prohibition on LSP merge) does not require LPP ping for = the bootstrapping of BFD sessions while RFC 5884 requires it.
=A0
My 2c,
=A0=A0=A0=A0 Sasha
=A0
=A0
=A0
Dear Sasha, Marc, et al.
Greatly appreciate our discussion.
The LSP Ping is widely used mechanism to bootstrap BFD sessions over MPLS L= SP because of PHP. If an operator disables PHP then no bootstrapping needed= . Alternatively, mapping might be statically configured on the remote LER.<= br>
My $.02

Kind regards,
Greg

On Sat, Feb 11, 2012 at 2:46 AM, Marc Binderberg= er <marc@sniff.de>= ; wrote:
Hello Alexander and Greg,

The=A0highlighted text=A0suggests=A0to me that = RFC 5884 mandates usage of LSP Ping for bootstrapping of BFD sessions.=A0Ta= king=A0into account that it supports BFD session per FEC for a given LSP, I do not see any alternative to this = method.

I agree. The first sen= tence in section 6 was already enough for me. It seems obvious to me that R= FC5884 is tightly coupling BFD and LSP ping, nothing optional.

Now Greg's email h= ad 2 statements:

"AFAIK, use of LS= P Ping to bootstrap a BFD session over MPLS LSP is optional. Thus use of Ro= uter Alert is not mandated by RFC 5884."


The first sentence you= have answered. For the second sentence I assume this is related to BFD pac= kets (?). And indeed RFC5884 is not mentioning router alert a single time, = neither as option nor as label. My understanding is the BFD packet has no router alert option in it's IP = header.

I have sent an email t= o George, one of the authors of RFC5884 and RFC4379, why LSP ping echo requ= ests - with an IP header very similar to BFD in RFC5884 - need to carry RA = option but BFD does not.


Did I miss something substantial?

If so then you are not= alone ;-)


Regards, Marc



On 2012-02-11, at 11:24 , Alexander Vainshtein wrote:

Dear Greg,
Regarding your claim that ""use of LSP Ping to bootstrap a BF= D session over MPLS LSP is optional" - quoting from RFC 5884:
In Section 4 "Theory of operation"

   To enable fault dete=
ction procedures specified in this document, for
   a particular MPLS LSP, this document requires the ingress and egress
   LSRs to be configured.  =
This includes configuration for supporting
   BFD and LSP Ping as specified in this document.  It also includes
   configuration that enables the ingress LSR to determine the method
   used by the egress LSR to identify Operations, Administration, and
   Maintenance (OAM) packets, e.g., whether the Time to Live (TTL) of
   the innermost MPLS label needs to be set to 1 to enable the egress

   LSR to identify the =
OAM packet.  For fault dete=
ction for MPLS PWs,
   this document assumes that the PW control channel type [RFC5085] is
   configured and the support of LSP Ping is also configured.
=A0
In Section 6 "Session Establishment":


=A0


A BFD session is bootstrapp=
ed using LSP Ping. 




...


   To establish a BFD session, an LSP Ping
   Echo request message MUST carry the local discriminator assigned by
   the ingress LSR for the BFD session.  This MUST subsequently be used
   as the My Discriminator field in the BFD session packets sent by the
   ingress LSR.




And from Section 6.1. "BFD Discriminator TLV in LSP Ping":




   LSP Ping Echo request and Echo reply messages c=
arry a BFD
   discriminator TLV for the purpose of session establishment as
   described above.  IANA has assigned a type value of 15 to this TL=
V.
   This TLV has a length of 4.  The value contains the 4-byte local
   discriminator that the LSR, sending the LSP Ping message, associates
   with the BFD session.

   If the BFD session is no=
t in UP state, the periodic LSP Ping Echo
   request messages MUST include the BFD Discriminator TLV.





The=A0highlighted text=A0suggests=A0to me that RFC 5884=
 mandates usage of LSP Ping for bootstrapping of BFD sessions.=A0Taking<=
/a>=A0into account that it supports BFD session per FEC for a =
given LSP, I do not see any alternative to
 this method.

Did I miss something substantial?

Regards,

=A0=A0=A0=A0 Sasha



________________________________________
From: Gregory=A0Mirsky=A0[gregory.mirsky@ericsson.com<= a>]
Sent: Friday, February 10, 2012 10:18 PM
To: Alexander Vainshtein; Bhatia,=A0Manav= =A0(Manav); Mach Chen; Tom Sanders;=A0Nitin<= /a>=A0Bahadur
Cc:=A0rt= g-bfd@ietf.org
Subject: RE: IP Address Schemes for BFD on LAG interfaces

Dear Sasha,
AFAIK, use of LSP Ping to bootstrap a BFD session over MPLS LSP is optional= . Thus use of Router Alert is not mandated by RFC 5884.

What do you think?

=A0=A0=A0=A0=A0=A0=A0 Regards,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Greg


--
Marc Binderber= ger =A0 =A0 =A0 =A0 =A0 <marc@sniff.de>


This e-mail message is intended for the recipient only and contains informa= tion 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, p= hone or fax, and then delete the original and all copies thereof.


--e89a8fb1ef18b805fb04b8bdfe09-- From paul.hitchen@bt.com Thu Feb 16 01:45:43 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 3919F21F871D for ; Thu, 16 Feb 2012 01:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=1.601, BAYES_00=-2.599, 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 f0XpK2nVnca1 for ; Thu, 16 Feb 2012 01:45:38 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 2511D21F8717 for ; Thu, 16 Feb 2012 01:45:38 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 16 Feb 2012 09:45:37 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.230]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Thu, 16 Feb 2012 09:45:36 +0000 From: To: , , , Date: Thu, 16 Feb 2012 09:45:36 +0000 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: AczoOJ0MZvKYE+JHRhe5I/5F7ulvuAAAX3iwARSljEg= Message-ID: <4BF3B24B46BEA246BB7D832A32CF706133A6E20266@EMV65-UKRD.domain1.systemhost.net> References: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com> , In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB 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: Thu, 16 Feb 2012 09:45:43 -0000 Hi Greg, Like Glen I prefer the multicast approach, it aligns with existing discover= y approaches and IP addressing for other 'control' plane protocols on links= . From an operational perspective I think it'll make more sense to someone = fault tracing a link, more likely to spot it's a link local address and rem= ember it's the 'start-up' address used for BFD micro sessions. Also depende= nt on deployments the multicast approach packets might more easily map into= existing security policies and any classification/scheduling QoS schemas. I would add however that I have no issue with having to configure a static = mapping for the micro BFD session endpoint address - if it means a quicker = delivery of implementable solutions.=20 regards Paul Hitchen BT Innovate & Design=20 ________________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of Greg= ory Mirsky [gregory.mirsky@ericsson.com] Sent: 10 February 2012 21:35 To: Glen Kent; Bhatia, Manav (Manav); rtg-bfd@ietf.org Subject: RE: IP Address Schemes for BFD on LAG interfaces Hi Kent, I believe that 127/8 addresses do not require manual configuration and auto= -discovery support because they are randomly selected as DA by the sender a= nd not checked by the reciever. RE: sending 127/8 on the wire. Since we're to use IP over Ethernet EtherTyp= e, formally 127/8 is on the wire as IP DA. But I'd note that RFC 1112 defin= es host behavior whereas RFC 1812 requires not to forward (by default) pack= ets with destination address on 127/8 network. Thus we guaranteed that micr= o-BFD packets would not be leaked by far-end node. Regards, Greg -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Glen Kent Sent: Friday, February 10, 2012 1:11 PM To: Bhatia, Manav (Manav); rtg-bfd@ietf.org Subject: Re: IP Address Schemes for BFD on LAG interfaces Hi Manav, I like the idea of discovery since manual configuration is not possible in = all deployments. I would prefer multicast since other discovery protocols use multicast. I a= lso find it rather unnatural to see 127/8 range out on the wire. Ideally, t= his should never exit the box. RFC 5735 says the following about 127/8 - "A= s described in [RFC1122], Section 3.2.1.3, addresses within the entire 127.= 0.0.0/8 block do not legitimately appear on any network anywhere." Glen On Fri, Feb 10, 2012 at 9:50 AM, Bhatia, Manav (Manav) wrote: > Hi Mach, > > Yes, the idea is to just retain one mechanism. > > I know you like multicast! ;-) > > This is btw exactly the opinion that will be useful in zeroing on a final= discovery mechanism. It would be good if others too can chime in with thei= r thoughts on this. > > Cheers, Manav > >> -----Original Message----- >> From: Mach Chen [mailto:mach.chen@huawei.com] >> Sent: Friday, February 10, 2012 7:54 AM >> To: Bhatia, Manav (Manav); Tom Sanders; Nitin Bahadur >> Cc: rtg-bfd@ietf.org >> Subject: RE: IP Address Schemes for BFD on LAG interfaces >> >> Hi Manav, Toms and all, >> >> Firstly, I share the concern of Nitin, and agree with Toms's >> point: one dynamic remote address learning solution is enough. From >> your reply, the authors also intend to keep only one solution, great! >> >> > Both proposals have their pros and cons and the authors of >> the draft >> > are not biased towards any particular solution (multicast >> or 127/8). >> > We would like the members of the WG to reach a consensus on which >> > proposal they would like to see going forward (if one has >> to be chosen from the two). >> >> Are there any analysis about the pros and cons? >> >> I personally prefer Multicast, because: >> >> 1. For the micro-BFD, we need a well-known Multicast MAC, if use >> Multicast for remote address learning, the Multicast MAC can be used >> for both remote address and MAC address learning; >> >> 2. The micro-BFD draft proposes to use unicast IP for L3 connectivity >> test, but the member link will be also used for >> L3 mulitcast forwarding, so use Multicast for remote address learning >> could test the L3 multicast connectivity at least one time; >> >> 3. On the other hand, if use 127/8, the receiver needs to combine >> extra information(e.g., UDP port) to identify the learning message. >> >> >> Best regards, >> Mach >> >> > -----Original Message----- >> > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On >> > Behalf Of Bhatia, Manav (Manav) >> > Sent: Friday, February 10, 2012 9:24 AM >> > To: Tom Sanders; Nitin Bahadur >> > Cc: rtg-bfd@ietf.org >> > Subject: RE: IP Address Schemes for BFD on LAG interfaces >> > >> > Hi Toms, >> > >> > >> > > >> > > I could be completely off the mark in which case the authors can >> > > correct me. But this seemed to me to be the high order bit of the >> > > document. >> > >> > Perfect! What you've said above is absolutely correct. >> > >> > > >> > > Question to the authors: >> > > >> > > (1) 127/8 seems to be vague. Shouldnt you be specifying >> an exact /32 >> > > address that should be used? >> > >> > The idea is to let implementations choose a destination IP address >> > randomly from the 127/8 range. This is consistent with what >> has been >> > described in RFC >> > 5884 (BFD for MPLS LSPs). >> > > >> > > (2) Do you think its wise to float two proposals that vendors can >> > > chose. Cant we have just one - either multicast or the >> > > 127/8 unicast? >> > > Why do we need two proposals? That would imo also address Nitin's >> > > concern (which i believe is quite valid). >> > >> > Both proposals have their pros and cons and the authors of >> the draft >> > are not biased towards any particular solution (multicast >> or 127/8). >> > We would like the members of the WG to reach a consensus on which >> > proposal they would like to see going forward (if one has >> to be chosen from the two). >> > >> > Hope this helps. >> > >> > Cheers, Manav >> > >> > > >> > > Toms >> > > >> > > On 09/02/2012, Nitin Bahadur wrote: >> > > > Hi Manav, >> > > > >> > > > The draft specifies multiple mechanisms and section 4.2 >> > > lists that >> > > > all MUST be supported. This doesn't make sense from a vendor >> > > > perspective IMO. If "all vendors" have to implement >> "all options", >> > > > then why not just have 1 option ! >> > > > >> > > > Having multiple options also leads to inter-op issue among >> > > vendors. We >> > > > have seen that story with multiple other protocols. >> > > > >> > > > Thanks >> > > > Nitin >> > > > >> > > > >> > > > On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" >> > > > >> > > > wrote: >> > > > >> > > > Hi, >> > > > >> > > > There were some concerns about operational complexity >> that using >> > > > unicast addresses for micro BFD sessions would entail. We >> > > have written >> > > > a short draft that alleviates such concerns by suggesting few >> > > > mechanisms that nodes can use to auto discover remote >> neighbor IP >> > > > addresses before establishing micro BFD sessions. >> > > > >> > > > Would be great if the WG can review and provide feedback on >> > > this draft. >> > > > >> > > > The URL for this Internet-Draft is: >> > > > >> > > >> http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. >> > > > txt >> > > > >> > > > Cheers, Manav >> > > > >> > > > -- >> > > > >> > > > From: internet-drafts@ietf.org >> > > > To: i-d-announce@ietf.org >> > > > Reply-to: internet-drafts@ietf.org >> > > > Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt >> > > > X-C5I-RSN: 1/0/935/41368/44754 >> > > > >> > > > A New Internet-Draft is available from the on-line >> Internet-Drafts >> > > > directories. >> > > > >> > > > Title : IP Address Schemes for Bidirectional Forwarding >> Detection >> > > > (BFD) on Link Aggregation Group (LAG) Interfaces >> > > > Author(s) : Manav Bhatia >> > > > Marc Binderberger >> > > > Sami Boutros >> > > > Nobo Akiya >> > > > Filename : draft-mmsn-bfd-on-lags-address-00.txt >> > > > Pages : 5 >> > > > Date : 2012-02-08 >> > > > >> > > > This document describes techniques which can be used by >> a router >> > > > to obtain or discover remote neighbor IP address in order to >> > > > establish micro Bidirectional Forwarding Detection >> (BFD) sessions >> > > [BFD-ON-LAGS]. >> > > > >> > > > >> > > > >> > > > A URL for this Internet-Draft is: >> > > > >> > > >> http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. >> > > > txt >> > > > >> > > > Internet-Drafts are also available by anonymous FTP at: >> > > > ftp://ftp.ietf.org/internet-drafts/ >> > > > >> > > > This Internet-Draft can be retrieved at: >> > > > >> > > >> ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00 >> > > .t >> > > > xt >> > > > >> > > > _______________________________________________ >> > > > I-D-Announce mailing list >> > > > I-D-Announce@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/i-d-announce >> > > > Internet-Draft directories: http://www.ietf.org/shadow.html or >> > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > > >> > > > >> > > > >> > > >> > > >> > > -- >> > > Toms. >> > > >>= From toms.sanders@gmail.com Thu Feb 16 04:41:02 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 6352B21F87E0 for ; Thu, 16 Feb 2012 04:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 76UCbggS6XUF for ; Thu, 16 Feb 2012 04:40:58 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCC2121F87D7 for ; Thu, 16 Feb 2012 04:40:57 -0800 (PST) Received: by werg1 with SMTP id g1so442252wer.31 for ; Thu, 16 Feb 2012 04:40:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+BUiPSWh1trochJq1ZAEq+UZz0AOW/1ht9ps2bPh77o=; b=nVWBvjHIj1b3NHkzW8L2tMapxBUYLT1F3awB/odhpbaoOiDsKPh5Kzglx/2Vv8zpig lBFuhn0QdR4f4N8dYK2NTqWA3g/6+uZvAIWew/myn+TQ1nk6dFdnW9+cY3jHItTHj1JE gnN7ZOzxyahR0OSNW4GRh1DLW5S1QfdQV11A0= MIME-Version: 1.0 Received: by 10.180.82.39 with SMTP id f7mr4167894wiy.19.1329396056933; Thu, 16 Feb 2012 04:40:56 -0800 (PST) Received: by 10.223.115.81 with HTTP; Thu, 16 Feb 2012 04:40:56 -0800 (PST) In-Reply-To: <4BF3B24B46BEA246BB7D832A32CF706133A6E20266@EMV65-UKRD.domain1.systemhost.net> References: <7C362EEF9C7896468B36C9B79200D8350D02B49873@INBANSXCHMBSA1.in.alcatel-lucent.com> <4BF3B24B46BEA246BB7D832A32CF706133A6E20266@EMV65-UKRD.domain1.systemhost.net> Date: Thu, 16 Feb 2012 18:10:56 +0530 Message-ID: Subject: Re: IP Address Schemes for BFD on LAG interfaces From: Tom Sanders To: paul.hitchen@bt.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 16 Feb 2012 12:41:02 -0000 I too would prefer to use a multicast address as all other mechanisms that use 127/8 range seem to rely on other mechanisms (router alert, ttl, etc) to punt the packet to CPU. I also agree with what somebody had earlier said on the list, that 127/8 should never leave the box. While i dont expect to see a switch between two micro BFD end points, but there is nothing that precludes the possibility of inserting one. In that case, i dont want us to be sending L3 traffic destined to 127/8 as behavior of snooping switches when dealing with this address range could be undefined. I am certain that there will not be any snooping devices or intermediaries dropping L3 traffic for 128/8, but one can never be too certain. This problem btw just does not exist when using a well known multicast address range for end node discovery. Toms. On 16 February 2012 15:15, wrote: > Hi Greg, > > Like Glen I prefer the multicast approach, it aligns with existing discov= ery approaches and IP addressing for other 'control' plane protocols on lin= ks. From an operational perspective I think it'll make more sense to someon= e fault tracing a link, more likely to spot it's a link local address and r= emember it's the 'start-up' address used for BFD micro sessions. Also depen= dent on deployments the multicast approach packets might more easily map in= to existing security policies and any classification/scheduling QoS schemas= . > > I would add however that I have no issue with having to configure a stati= c mapping for the micro BFD session endpoint address - if it means a quicke= r delivery of implementable solutions. > > regards > > Paul Hitchen > BT Innovate & Design > > ________________________________________ > From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of Gr= egory Mirsky [gregory.mirsky@ericsson.com] > Sent: 10 February 2012 21:35 > To: Glen Kent; Bhatia, Manav (Manav); rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces > > Hi Kent, > I believe that 127/8 addresses do not require manual configuration and au= to-discovery support because they are randomly selected as DA by the sender= and not checked by the reciever. > RE: sending 127/8 on the wire. Since we're to use IP over Ethernet EtherT= ype, formally 127/8 is on the wire as IP DA. But I'd note that RFC 1112 def= ines host behavior whereas RFC 1812 requires not to forward (by default) pa= ckets with destination address on 127/8 network. Thus we guaranteed that mi= cro-BFD packets would not be leaked by far-end node. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg > > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of Glen Kent > Sent: Friday, February 10, 2012 1:11 PM > To: Bhatia, Manav (Manav); rtg-bfd@ietf.org > Subject: Re: IP Address Schemes for BFD on LAG interfaces > > Hi Manav, > > I like the idea of discovery since manual configuration is not possible i= n all deployments. > > I would prefer multicast since other discovery protocols use multicast. I= also find it rather unnatural to see 127/8 range out on the wire. Ideally,= this should never exit the box. RFC 5735 says the following about 127/8 - = "As described in [RFC1122], Section 3.2.1.3, addresses within the entire 12= 7.0.0.0/8 block do not legitimately appear on any network anywhere." > > Glen > > On Fri, Feb 10, 2012 at 9:50 AM, Bhatia, Manav (Manav) wrote: >> Hi Mach, >> >> Yes, the idea is to just retain one mechanism. >> >> I know you like multicast! ;-) >> >> This is btw exactly the opinion that will be useful in zeroing on a fina= l discovery mechanism. It would be good if others too can chime in with the= ir thoughts on this. >> >> Cheers, Manav >> >>> -----Original Message----- >>> From: Mach Chen [mailto:mach.chen@huawei.com] >>> Sent: Friday, February 10, 2012 7:54 AM >>> To: Bhatia, Manav (Manav); Tom Sanders; Nitin Bahadur >>> Cc: rtg-bfd@ietf.org >>> Subject: RE: IP Address Schemes for BFD on LAG interfaces >>> >>> Hi Manav, Toms and all, >>> >>> Firstly, I share the concern of Nitin, and agree with Toms's >>> point: one dynamic remote address learning solution is enough. From >>> your reply, the authors also intend to keep only one solution, great! >>> >>> > Both proposals have their pros and cons and the authors of >>> the draft >>> > are not biased towards any particular solution (multicast >>> or 127/8). >>> > We would like the members of the WG to reach a consensus on which >>> > proposal they would like to see going forward (if one has >>> to be chosen from the two). >>> >>> Are there any analysis about the pros and cons? >>> >>> I personally prefer Multicast, because: >>> >>> 1. For the micro-BFD, we need a well-known Multicast MAC, if use >>> Multicast for remote address learning, the Multicast MAC can be used >>> for both remote address and MAC address learning; >>> >>> 2. The micro-BFD draft proposes to use unicast IP for L3 connectivity >>> test, but the member link will be also used for >>> L3 mulitcast forwarding, so use Multicast for remote address learning >>> could test the L3 multicast connectivity at least one time; >>> >>> 3. On the other hand, if use 127/8, the receiver needs to combine >>> extra information(e.g., UDP port) to identify the learning message. >>> >>> >>> Best regards, >>> Mach >>> >>> > -----Original Message----- >>> > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On >>> > Behalf Of Bhatia, Manav (Manav) >>> > Sent: Friday, February 10, 2012 9:24 AM >>> > To: Tom Sanders; Nitin Bahadur >>> > Cc: rtg-bfd@ietf.org >>> > Subject: RE: IP Address Schemes for BFD on LAG interfaces >>> > >>> > Hi Toms, >>> > >>> > >>> > > >>> > > I could be completely off the mark in which case the authors can >>> > > correct me. But this seemed to me to be the high order bit of the >>> > > document. >>> > >>> > Perfect! What you've said above is absolutely correct. >>> > >>> > > >>> > > Question to the authors: >>> > > >>> > > (1) 127/8 seems to be vague. Shouldnt you be specifying >>> an exact /32 >>> > > address that should be used? >>> > >>> > The idea is to let implementations choose a destination IP address >>> > randomly from the 127/8 range. This is consistent with what >>> has been >>> > described in RFC >>> > 5884 (BFD for MPLS LSPs). >>> > > >>> > > (2) Do you think its wise to float two proposals that vendors can >>> > > chose. Cant we have just one - either multicast or the >>> > > 127/8 unicast? >>> > > Why do we need two proposals? That would imo also address Nitin's >>> > > concern (which i believe is quite valid). >>> > >>> > Both proposals have their pros and cons and the authors of >>> the draft >>> > are not biased towards any particular solution (multicast >>> or 127/8). >>> > We would like the members of the WG to reach a consensus on which >>> > proposal they would like to see going forward (if one has >>> to be chosen from the two). >>> > >>> > Hope this helps. >>> > >>> > Cheers, Manav >>> > >>> > > >>> > > Toms >>> > > >>> > > On 09/02/2012, Nitin Bahadur wrote: >>> > > > Hi Manav, >>> > > > >>> > > > =C2=A0 The draft specifies multiple mechanisms and section 4.2 >>> > > lists that >>> > > > all MUST be supported. This doesn't make sense from a vendor >>> > > > perspective IMO. If "all vendors" have to implement >>> "all options", >>> > > > then why not just have 1 option ! >>> > > > >>> > > > Having multiple options also leads to inter-op issue among >>> > > vendors. We >>> > > > have seen that story with multiple other protocols. >>> > > > >>> > > > Thanks >>> > > > Nitin >>> > > > >>> > > > >>> > > > On 2/9/12 5:05 AM, "Bhatia, Manav (Manav)" >>> > > > >>> > > > wrote: >>> > > > >>> > > > Hi, >>> > > > >>> > > > There were some concerns about operational complexity >>> that using >>> > > > unicast addresses for micro BFD sessions would entail. We >>> > > have written >>> > > > a short draft that alleviates such concerns by suggesting few >>> > > > mechanisms that nodes can use to auto discover remote >>> neighbor IP >>> > > > addresses before establishing micro BFD sessions. >>> > > > >>> > > > Would be great if the WG can review and provide feedback on >>> > > this draft. >>> > > > >>> > > > The URL for this Internet-Draft is: >>> > > > >>> > > >>> http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. >>> > > > txt >>> > > > >>> > > > Cheers, Manav >>> > > > >>> > > > -- >>> > > > >>> > > > From: internet-drafts@ietf.org >>> > > > To: i-d-announce@ietf.org >>> > > > Reply-to: internet-drafts@ietf.org >>> > > > Subject: I-D Action: draft-mmsn-bfd-on-lags-address-00.txt >>> > > > X-C5I-RSN: 1/0/935/41368/44754 >>> > > > >>> > > > A New Internet-Draft is available from the on-line >>> Internet-Drafts >>> > > > directories. >>> > > > >>> > > > Title : IP Address Schemes for Bidirectional Forwarding >>> Detection >>> > > > (BFD) on Link Aggregation Group (LAG) Interfaces >>> > > > Author(s) : Manav Bhatia >>> > > > Marc Binderberger >>> > > > Sami Boutros >>> > > > Nobo Akiya >>> > > > Filename : draft-mmsn-bfd-on-lags-address-00.txt >>> > > > Pages : 5 >>> > > > Date : 2012-02-08 >>> > > > >>> > > > This document describes techniques which can be used by >>> a router >>> > > > to obtain or discover remote neighbor IP address in order to >>> > > > establish micro Bidirectional Forwarding Detection >>> (BFD) sessions >>> > > [BFD-ON-LAGS]. >>> > > > >>> > > > >>> > > > >>> > > > A URL for this Internet-Draft is: >>> > > > >>> > > >>> http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. >>> > > > txt >>> > > > >>> > > > Internet-Drafts are also available by anonymous FTP at: >>> > > > ftp://ftp.ietf.org/internet-drafts/ >>> > > > >>> > > > This Internet-Draft can be retrieved at: >>> > > > >>> > > >>> ftp://ftp.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00 >>> > > .t >>> > > > xt >>> > > > >>> > > > _______________________________________________ >>> > > > I-D-Announce mailing list >>> > > > I-D-Announce@ietf.org >>> > > > https://www.ietf.org/mailman/listinfo/i-d-announce >>> > > > Internet-Draft directories: http://www.ietf.org/shadow.html or >>> > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> > > > >>> > > > >>> > > > >>> > > >>> > > >>> > > -- >>> > > Toms. >>> > > >>> --=20 Toms. From jhaas@slice.pfrc.org Mon Feb 20 12:33: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 DFA0A21F8559 for ; Mon, 20 Feb 2012 12:33:15 -0800 (PST) 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 C4ZoV5sa7Ezg for ; Mon, 20 Feb 2012 12:33:15 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6E221F8557 for ; Mon, 20 Feb 2012 12:33:15 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3EAA717023B; Mon, 20 Feb 2012 15:33:15 -0500 (EST) Date: Mon, 20 Feb 2012 15:33:15 -0500 From: Jeffrey Haas To: "Bhatia, Manav (Manav)" Subject: Re: IP Address Schemes for BFD on LAG interfaces Message-ID: <20120220203315.GI6584@slice> References: <7C362EEF9C7896468B36C9B79200D8350D02AB456F@INBANSXCHMBSA1.in.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02AB456F@INBANSXCHMBSA1.in.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, 20 Feb 2012 20:33:16 -0000 On Thu, Feb 09, 2012 at 09:35:38AM +0530, Bhatia, Manav (Manav) wrote: > There were some concerns about operational complexity that using unicast addresses for micro BFD sessions would entail. We have written a short draft that alleviates such concerns by suggesting few mechanisms that nodes can use to auto discover remote neighbor IP addresses before establishing micro BFD sessions. > > Would be great if the WG can review and provide feedback on this draft. > > The URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.txt Two comments with my WG chair hat off: 1. I agree with Nitin and others: Once we've come to some consensus, the document should be reduced to one bootstrapping mechanism. 2. My personal preference would be multicast. (Yes, Mach... :-) However, I'd encourage the authors to consider implications on switched links. In such a configuration what sort of issues could you run into? With the hat on: Once we come to consensus as to the mechanism, we should consider merging the discovery document and the LAG document unless we find that the LAG document is more general. An example would be an application to MPLS LAG. -- Jeff From jhaas@slice.pfrc.org Mon Feb 20 12:46:50 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0EB21F8618 for ; Mon, 20 Feb 2012 12:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.152 X-Spam-Level: X-Spam-Status: No, score=-102.152 tagged_above=-999 required=5 tests=[AWL=0.113, 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 E9GZ92ql6BYc for ; Mon, 20 Feb 2012 12:46:50 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8DF21F862D for ; Mon, 20 Feb 2012 12:46:50 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 086E7170362; Mon, 20 Feb 2012 15:46:50 -0500 (EST) Date: Mon, 20 Feb 2012 15:46:50 -0500 From: Jeffrey Haas To: Jeffrey Haas Subject: Re: IP Address Schemes for BFD on LAG interfaces Message-ID: <20120220204649.GK6584@slice> References: <7C362EEF9C7896468B36C9B79200D8350D02AB456F@INBANSXCHMBSA1.in.alcatel-lucent.com> <20120220203315.GI6584@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120220203315.GI6584@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, 20 Feb 2012 20:46:50 -0000 Clarification to my last post: On Mon, Feb 20, 2012 at 03:33:15PM -0500, Jeffrey Haas wrote: > On Thu, Feb 09, 2012 at 09:35:38AM +0530, Bhatia, Manav (Manav) wrote: > > There were some concerns about operational complexity that using unicast addresses for micro BFD sessions would entail. We have written a short draft that alleviates such concerns by suggesting few mechanisms that nodes can use to auto discover remote neighbor IP addresses before establishing micro BFD sessions. > > > > Would be great if the WG can review and provide feedback on this draft. > > > > The URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.txt [...] > 2. My personal preference would be multicast. However, this would require clarification of when we send unicast vs. multicast when we're signaling DOWN/ADMINDOWN. As an example, when we're transitioning to down we may wish to send DetectMult packets to the last known unicast address prior to transitioning back to multicast. -- Jeff From jhaas@slice.pfrc.org Mon Feb 20 13:01:03 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 EDFA221F86C9 for ; Mon, 20 Feb 2012 13:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.156 X-Spam-Level: X-Spam-Status: No, score=-102.156 tagged_above=-999 required=5 tests=[AWL=0.109, 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 Gs28jfCBOUya for ; Mon, 20 Feb 2012 13:01:02 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5897621F86C7 for ; Mon, 20 Feb 2012 13:01:02 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0BC4717035C; Mon, 20 Feb 2012 16:01:02 -0500 (EST) Date: Mon, 20 Feb 2012 16:01:02 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Reminder about Contributor responsibilities regarding IPR; BFD over LAG Message-ID: <20120220210102.GL6584@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: Mon, 20 Feb 2012 21:01:03 -0000 Working Group, There's been good energy and collaboration on the BFD over LAG discussion. Since there's been good consensus regarding a new charter item covering that work, I've requested our AD to have our charter amended. This is a good time to point out that part of the reason why there's so much energy on the topic is a number of vendors support various flavors of proprietary BFD over LAG and we're in need of an open, interoperable solution. To that end, let me please remind you of your responsibilities as IETF Contributors: http://www.ietf.org/about/note-well.html http://tools.ietf.org/html/rfc3979 etc. While it is perhaps early to request IPR disclosure prior to having the work in a draft-ietf-bfd- document, we're at the point of gaining consensus over design decisions for what should be in such a draft. To help the WG make an informed decision about the solution, please gather and publish your IPR disclosures. -- Jeff & Dave From toms.sanders@gmail.com Mon Feb 20 17:12:17 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 CAEC221F84F5 for ; Mon, 20 Feb 2012 17:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 vR00jNK+A2MW for ; Mon, 20 Feb 2012 17:12:16 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 843A721F84EC for ; Mon, 20 Feb 2012 17:12:16 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so3655405wgb.13 for ; Mon, 20 Feb 2012 17:12:09 -0800 (PST) Received-SPF: pass (google.com: domain of toms.sanders@gmail.com designates 10.216.132.28 as permitted sender) client-ip=10.216.132.28; Authentication-Results: mr.google.com; spf=pass (google.com: domain of toms.sanders@gmail.com designates 10.216.132.28 as permitted sender) smtp.mail=toms.sanders@gmail.com; dkim=pass header.i=toms.sanders@gmail.com Received: from mr.google.com ([10.216.132.28]) by 10.216.132.28 with SMTP id n28mr5536677wei.35.1329786729738 (num_hops = 1); Mon, 20 Feb 2012 17:12:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wpiTX/ZNMsp9BLw9gsKEoDh51aEHpDM1YHVTugDg43A=; b=DweaWUJXD7ABsmqraiPHzfooWhJFU4bbTHY+3ubAlSrTtseyLjbUtMbmt/+g6OTj2D ymKWa3NocvvhnAr+7JvQ1dsPO1tN2CbrZregR5qvJRfNSGR36oRb4f8JPzAQX8v0inJd h25B7Bqbix/Gg5yUfx9/wiXcUpCGO/g4t3l4Y= MIME-Version: 1.0 Received: by 10.216.132.28 with SMTP id n28mr4617376wei.35.1329786729616; Mon, 20 Feb 2012 17:12:09 -0800 (PST) Received: by 10.223.62.67 with HTTP; Mon, 20 Feb 2012 17:12:09 -0800 (PST) In-Reply-To: <20120220203315.GI6584@slice> References: <7C362EEF9C7896468B36C9B79200D8350D02AB456F@INBANSXCHMBSA1.in.alcatel-lucent.com> <20120220203315.GI6584@slice> Date: Tue, 21 Feb 2012 06:42:09 +0530 Message-ID: Subject: Re: IP Address Schemes for BFD on LAG interfaces From: Tom Sanders To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 21 Feb 2012 01:12:17 -0000 Hi Jeff, >> There were some concerns about operational complexity that using unicast= addresses for micro BFD sessions would entail. We have written a short dra= ft that alleviates such concerns by suggesting few mechanisms that nodes ca= n use to auto discover remote neighbor IP addresses before establishing mic= ro BFD sessions. >> >> Would be great if the WG can review and provide feedback on this draft. >> >> The URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00.tx= t > > Two comments with my WG chair hat off: > 1. I agree with Nitin and others: Once we've come to some consensus, the > document should be reduced to one bootstrapping mechanism. > 2. My personal preference would be multicast. (Yes, Mach... :-) =C2=A0How= ever, > I'd encourage the authors to consider implications on switched links. =C2= =A0In > such a configuration what sort of issues could you run into? Multicast seems to be a clear winner here. > > With the hat on: > Once we come to consensus as to the mechanism, we should consider merging > the discovery document and the LAG document unless we find that the LAG I would rather that we keep the discovery mechanism outside the main document since the earlier document is quite generic. > document is more general. =C2=A0An example would be an application to MPL= S LAG. What is a MPLS LAG? Is it an MPLS tunnel over a LAG or a LAG where the constituent "links" are MPLS tunnels (something like a composite link). I trust its the latter that youre alluding to. In that case, we will require a different discovery mechanism entailing a new draft. Thus its better to keep discovery separate from the main draft. Toms. From manav.bhatia@alcatel-lucent.com Mon Feb 20 20:59:13 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 F157721F853A for ; Mon, 20 Feb 2012 20:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.834 X-Spam-Level: X-Spam-Status: No, score=-6.834 tagged_above=-999 required=5 tests=[AWL=-0.235, 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 bE4fhf6TSIFE for ; Mon, 20 Feb 2012 20:59:12 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3752D21F852B for ; Mon, 20 Feb 2012 20:59:06 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q1L4x1vC026077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Feb 2012 22:59:03 -0600 (CST) 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 q1L4wxfl014699 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Feb 2012 10:28:59 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 21 Feb 2012 10:28:59 +0530 From: "Bhatia, Manav (Manav)" To: Jeffrey Haas Date: Tue, 21 Feb 2012 10:27:15 +0530 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: AczwDuMg4xlraM9dSYaNB1RhrXP9MQARAhYw Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02BE0F7B@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <20120220203315.GI6584@slice> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 04:59:13 -0000 Jeff, =20 > > Would be great if the WG can review and provide feedback on=20 > this draft. > >=20 > > The URL for this Internet-Draft is:=20 > >=20 > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-00. > > txt >=20 > Two comments with my WG chair hat off: > 1. I agree with Nitin and others: Once we've come to some=20 > consensus, the document should be reduced to one=20 > bootstrapping mechanism. Yes that's the idea. The WG seems to be converging towards multicast.=20 > 2. My personal preference would be multicast. (Yes, Mach...=20 > :-) However, I'd encourage the authors to consider=20 > implications on switched links. In such a configuration what=20 > sort of issues could you run into? >=20 > With the hat on: > Once we come to consensus as to the mechanism, we should=20 > consider merging the discovery document and the LAG document=20 > unless we find that the LAG document is more general. An=20 > example would be an application to MPLS LAG. I would prefer to keep the discovery mechanism outside the base draft becau= se including this in the base draft will force implementations to implement= the discovery process (which is orthogonal to how we need to run BFD on ea= ch member link of LAG). There are use cases where there isnt a need for a d= iscovery mechanism and a few vendors may choose not to implement this unles= s asked for by their customers. By including the discovery mechanism in the= base draft, any implementation not supporting this would be non compliant = to the BFDoLAGs standard. OTOH if we include this mechanism as a MAY or a S= HOULD then we could have interoperability issues where two compliant implem= entations may not be able to use this mechanism.=20 I would like to keep this as a separate draft and implementations claiming = compliance to draft-mmsn-bfd-* will be able to use a discovery mechanism. We could also have other link types (composite links having MPLS tunnels as= constituents) that may need a BFD discovery process other than what has be= en described in draft-mmsn-bfd-*. Those would anyways be described in a dif= ferent draft. Given this I see no good reason for us to include this in the= base draft. Cheers, Manav= From manav.bhatia@alcatel-lucent.com Mon Feb 20 22:42: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 364FC21F8621 for ; Mon, 20 Feb 2012 22:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.83 X-Spam-Level: X-Spam-Status: No, score=-6.83 tagged_above=-999 required=5 tests=[AWL=-0.231, 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 dqeIiAtbzCiB for ; Mon, 20 Feb 2012 22:42:31 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 44FE621F8620 for ; Mon, 20 Feb 2012 22:42:30 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q1L6gQVj020689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 21 Feb 2012 00:42:29 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q1L6gQp2025255 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 21 Feb 2012 12:12:26 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 21 Feb 2012 12:12:26 +0530 From: "Bhatia, Manav (Manav)" To: "rtg-bfd@ietf.org" Date: Tue, 21 Feb 2012 12:10:41 +0530 Subject: RE: IETF 83 meeting - call for presentations Thread-Topic: IETF 83 meeting - call for presentations Thread-Index: AczRoRClYtLalosbTlS3AP6Li+UwTwetmDuw Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02BE1007@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <20120113031130.GF7464@slice> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 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, 21 Feb 2012 06:42:32 -0000 Hi, We're nearing the IETF and it would be good if we can list any open and con= tentious issues before the meeting so that those can be addressed in the f2= f discussion. This will also give us a sense of how far we are wrt arriving= at a consensus on this particular draft. I'd rather that we discuss some of the outstanding issues than us spend tim= e on mundane stuff that can be easily found in the document. The latest version can be found here: http://tools.ietf.org/id/draft-mmm-bfd-on-lags-03.txt Looking forward to hear from the WG members. Cheers, Manav > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 > Sent: Friday, January 13, 2012 8:42 AM > To: Bhatia, Manav (Manav) > Cc: Jeffrey Haas; rtg-bfd@ietf.org > Subject: Re: IETF 83 meeting - call for presentations >=20 > On Fri, Jan 13, 2012 at 06:28:32AM +0530, Bhatia, Manav (Manav) wrote: > > I'd like a slot for presenting BFD over LAG members.=20 > >=20 > > Will a 10 min slot work? :-) >=20 > I figured we'd allocate half an hour to start with. :-) >=20 > Given that I've had requests for two other time slots on top=20 > of this, if we get another I'll need to ask for a longer session. >=20 > -- Jeff > = From manav.bhatia@alcatel-lucent.com Tue Feb 21 05:33: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 A034321F847F for ; Tue, 21 Feb 2012 05:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.826 X-Spam-Level: X-Spam-Status: No, score=-6.826 tagged_above=-999 required=5 tests=[AWL=-0.227, 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 X6Ug5TILbZhh for ; Tue, 21 Feb 2012 05:33:52 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B508321F847C for ; Tue, 21 Feb 2012 05:33:52 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q1LDXlg8024026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Feb 2012 07:33:51 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q1LDXkfs028834 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Feb 2012 19:03:47 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 21 Feb 2012 19:03:47 +0530 From: "Bhatia, Manav (Manav)" To: Jeffrey Haas Date: Tue, 21 Feb 2012 19:04:28 +0530 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: AczwEMyoF4s4Rji8ScmXT1DEDKX6swAjEFqg Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02BE1173@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D02AB456F@INBANSXCHMBSA1.in.alcatel-lucent.com> <20120220203315.GI6584@slice> <20120220204649.GK6584@slice> In-Reply-To: <20120220204649.GK6584@slice> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 13:33:56 -0000 Hi Jeff, > > > The URL for this Internet-Draft is:=20 > > >=20 > http://www.ietf.org/internet-drafts/draft-mmsn-bfd-on-lags-address-0 > > > 0.txt > [...] > > 2. My personal preference would be multicast. >=20 > However, this would require clarification of when we send unicast vs. > multicast when we're signaling DOWN/ADMINDOWN. As an=20 > example, when we're transitioning to down we may wish to send=20 > DetectMult packets to the last known unicast address prior to=20 > transitioning back to multicast. We have some text that talks about this in Sec 3.2 "Each router will discover the remote IP address by examining the source IP in micro BFD session packets. When transitioning into INIT or UP states, discovered neighbor IP address MUST be used as destination address in the IP header. Micro BFD sessions are to proceed as described in [RFC5880] and [BFD-ON-LAGS]. When a micro BFD session needs to start over the session bring-up logic, destination address in the IP header MUST be reset to a well-known link-local multicast IP address. " Is this good enough or would you like some more clarification here? Cheers, Manav= From jhaas@slice.pfrc.org Tue Feb 21 07:20:58 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA5B21F880C for ; Tue, 21 Feb 2012 07:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.163 X-Spam-Level: X-Spam-Status: No, score=-102.163 tagged_above=-999 required=5 tests=[AWL=0.102, 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 ON8P718ux9i4 for ; Tue, 21 Feb 2012 07:20:57 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3486421F87F5 for ; Tue, 21 Feb 2012 07:20:57 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id C3596170364; Tue, 21 Feb 2012 10:20:56 -0500 (EST) Date: Tue, 21 Feb 2012 10:20:56 -0500 From: Jeffrey Haas To: "Bhatia, Manav (Manav)" Subject: Re: IP Address Schemes for BFD on LAG interfaces Message-ID: <20120221152056.GE11722@slice> References: <7C362EEF9C7896468B36C9B79200D8350D02AB456F@INBANSXCHMBSA1.in.alcatel-lucent.com> <20120220203315.GI6584@slice> <20120220204649.GK6584@slice> <7C362EEF9C7896468B36C9B79200D8350D02BE1173@INBANSXCHMBSA1.in.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02BE1173@INBANSXCHMBSA1.in.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: Tue, 21 Feb 2012 15:20:58 -0000 On Tue, Feb 21, 2012 at 07:04:28PM +0530, Bhatia, Manav (Manav) wrote: > > However, this would require clarification of when we send unicast vs. > > multicast when we're signaling DOWN/ADMINDOWN. As an > > example, when we're transitioning to down we may wish to send > > DetectMult packets to the last known unicast address prior to > > transitioning back to multicast. > > We have some text that talks about this in Sec 3.2 > > "Each router will > discover the remote IP address by examining the source IP in micro > BFD session packets. When transitioning into INIT or UP states, > discovered neighbor IP address MUST be used as destination address in > the IP header. Micro BFD sessions are to proceed as described in > [RFC5880] and [BFD-ON-LAGS]. When a micro BFD session needs to start > over the session bring-up logic, destination address in the IP header > MUST be reset to a well-known link-local multicast IP address. " > > Is this good enough or would you like some more clarification here? I'd like some clarification. Down is a natural part of our state machine and it'd be nice, IMO, to make sure that sessions that may have some state in an implementation (rather than a potential catch-all state machine that spawns new sessions) get the chance to be torn down a bit more explicitly using unicast. In an ideal world, the fact that the down is arriving as multicast shouldn't matter. I'm somewhat cynical about that. If the WG consensus is that multicast is fine for all Down/AdminDown traffic, I'll cede my point. :-) -- Jeff From jhaas@slice.pfrc.org Tue Feb 21 07:22:26 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2A321F8842 for ; Tue, 21 Feb 2012 07:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.099, 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 0B0Wi0gQ-i24 for ; Tue, 21 Feb 2012 07:22:24 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C9E3721F885C for ; Tue, 21 Feb 2012 07:22:23 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9A7EB170368; Tue, 21 Feb 2012 10:22:23 -0500 (EST) Date: Tue, 21 Feb 2012 10:22:23 -0500 From: Jeffrey Haas To: Tom Sanders Subject: Re: IP Address Schemes for BFD on LAG interfaces Message-ID: <20120221152223.GF11722@slice> References: <7C362EEF9C7896468B36C9B79200D8350D02AB456F@INBANSXCHMBSA1.in.alcatel-lucent.com> <20120220203315.GI6584@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Tue, 21 Feb 2012 15:22:27 -0000 On Tue, Feb 21, 2012 at 06:42:09AM +0530, Tom Sanders wrote: > What is a MPLS LAG? > > Is it an MPLS tunnel over a LAG or a LAG where the constituent "links" > are MPLS tunnels (something like a composite link). > > I trust its the latter that youre alluding to. In that case, we will > require a different discovery mechanism entailing a new draft. Thus > its better to keep discovery separate from the main draft. I was indeed talking about composite links. I think you and Manav (in a separate message) have made good cause for keeping the bootstrapping in a separate draft. -- Jeff From Alexander.Vainshtein@ecitele.com Tue Feb 21 08:02:05 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0C021F8834 for ; Tue, 21 Feb 2012 08:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.591 X-Spam-Level: X-Spam-Status: No, score=-4.591 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 VJ69rb-WhN4X for ; Tue, 21 Feb 2012 08:02:03 -0800 (PST) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 5A30C21F8833 for ; Tue, 21 Feb 2012 08:02:03 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1329840120!10079594!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 22664 invoked from network); 21 Feb 2012 16:02:01 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-7.tower-174.messagelabs.com with SMTP; 21 Feb 2012 16:02:01 -0000 X-AuditID: 93eaf2e7-b7f976d000000ef3-be-4f43cb86bd7e Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id FB.92.03827.68BC34F4; Tue, 21 Feb 2012 18:51:18 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 21 Feb 2012 18:01:28 +0200 From: Alexander Vainshtein To: Jeffrey Haas Date: Tue, 21 Feb 2012 18:01:27 +0200 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: AczwrCrDb+6veohtSIiUb3P0FO7Y6wAA8gxA Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02AB456F@INBANSXCHMBSA1.in.alcatel-lucent.com> <20120220203315.GI6584@slice> <20120220204649.GK6584@slice> <7C362EEF9C7896468B36C9B79200D8350D02BE1173@INBANSXCHMBSA1.in.alcatel-lucent.com> <20120221152056.GE11722@slice> In-Reply-To: <20120221152056.GE11722@slice> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTa0zTUBjNbbdZ5mrqeOxK1JT6CD42NwUzHyO+g1GDiv4hIpbtslW3blkL ATGIxieJBqOROEiYQsD4iEqU+EIFEwO+QEl8EEVR0AgaUDEqUWdLETH217n3nPOd7zbfR+D6 Hk00wfEi8vOsm9FoVQc7P/Uad91ZmGRuK59mvV77QW0taW1VWz//qAbz8MSdb2rUieXl37HE 5n0X1CvxlHwwl+V5r8iKiHYgwW5jVvq5LNaew9Ccw8ZYGNrnZu3Ig3jRxrA+H+IdTIKW/u+b K8k4nka83evgeKeNWZqcZLRa42cZLUzCxHGWGXO0a1ycQCOjh+XctAcJAutEtHSz4TzuKms5 DnwvYXZloB7kg5vhBSCMgFQcbHpYAxQcBZtaz2gKgJbQUzUA1jY8HzgcAvDo/QJcVmkoG6w6 KRNhRAQVA0tDe/sxTmXA9y2n+rGKmgAP7KxWyzicmgWb9xVhin42vFzxYQBPh30NL/qTSWoV fFrcjSlhhRjsCx4cJhNh1BR4rKyxHwOpva+3T2FKmAG2tJdiStsULL/aiCs4Er57/Uut6CPh s91ngKKfCoNXPg00OgVWHO3CleCRsOFIu0rxjoK1x5+oCoEhMCQiMMQeGGIPDLEHgeoEiOTc PjHd4zRbTMjOiciNTHavpwoo8/L2IugrHV8HKAIwOjK2ZmGSXs1mCTmeOjCKwJhI8qd8NSLd 68hxsYIrzZ/pRkIdgATORJBlQYkjHWzOZuT3/qGs0m8+gEcPt3ulyeTFtBlm8z8HxkCeYBOS 9JRTGrtNCPmQ/491NEEwkMSuS1VH+pETZWdwbvEvjRFhcrJOSm67JicLPtYjcE6Fvw2MxMcb 7U1Ar+K9PIo2kI9lESWLXJn8YB15UbaGQqFOYJDeHE6+lVU6aY0GK3VKIZgUsiM0Xw6R1mOQ is4HK+4uOJ1ckkIuqJ/5qnXs4kVFAYspd8zZZcVB8660lNXLDesOx+d1n4tasb/t8yUvLaZm F6UX6noqtu91vu/CK7+dvNcbCEXkZW5cYvqi3dIRd6u0JD6352e9aptu6oQvHWNiYFYltcf0 PHZtU+YDS/ejLPeINry49/X6mElpmm+PUhmV4GItk3G/wP4Gu053qQMEAAA= 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, 21 Feb 2012 16:02:05 -0000 Jeff and all, IMHO and FWIW the doubts regarding usage of different addresses in different= states actually hides a very simple fact: Discovery of the peer address to be used in the micro-BFD session) should b= e separated from the micro-BFD session. I've said in one of my earlier emails that, for LAG with LACP (where micro-B= FD sessions are initiated by the LACP) one could use the peer port MAC addre= ss in a non-IP encapsulation of the BFD packets. Since the WG consensus goes now towards using IP-based encapsulation, I sugg= est a separate multicast-based peer discovery protocol that would return bot= h IP address of the peer LAG and the MAC address of the peer port. Micro-BF= D sessions would then be initiated by this protocol and use the same destina= tion addresses (IP and MAC) for the life span of the micro-BFD session. We could use something like Router Discovery Protocol (RFC 1256) for IPv4 or= Neighbor Discovery Protocol for IPv6. The only modification is that the adv= ertisement messages would have to be transmitted separately on each LAG memb= er link. Do I miss something substantial? Regards, Sasha > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Jeffrey Haas > Sent: Tuesday, February 21, 2012 5:21 PM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: Re: IP Address Schemes for BFD on LAG interfaces > > On Tue, Feb 21, 2012 at 07:04:28PM +0530, Bhatia, Manav (Manav) wrote: > > > However, this would require clarification of when we send unicast vs. > > > multicast when we're signaling DOWN/ADMINDOWN. As an > > > example, when we're transitioning to down we may wish to send > > > DetectMult packets to the last known unicast address prior to > > > transitioning back to multicast. > > > > We have some text that talks about this in Sec 3.2 > > > > "Each router will > > discover the remote IP address by examining the source IP in micro > > BFD session packets. When transitioning into INIT or UP states, > > discovered neighbor IP address MUST be used as destination address in > > the IP header. Micro BFD sessions are to proceed as described in > > [RFC5880] and [BFD-ON-LAGS]. When a micro BFD session needs to start > > over the session bring-up logic, destination address in the IP header > > MUST be reset to a well-known link-local multicast IP address. " > > > > Is this good enough or would you like some more clarification here? > > I'd like some clarification. Down is a natural part of our state machine > and it'd be nice, IMO, to make sure that sessions that may have some state > in an implementation (rather than a potential catch-all state machine that > spawns new sessions) get the chance to be torn down a bit more explicitly > using unicast. > > In an ideal world, the fact that the down is arriving as multicast shouldn= 't > matter. I'm somewhat cynical about that. > > If the WG consensus is that multicast is fine for all Down/AdminDown > traffic, I'll cede my point. :-) > > -- Jeff 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 Tue Feb 21 08:36:20 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 CDC1721F880D for ; Tue, 21 Feb 2012 08:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 i3u6rwAgvVC2 for ; Tue, 21 Feb 2012 08:36:20 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9960C21F8806 for ; Tue, 21 Feb 2012 08:36:19 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id AEC682AA0F; Tue, 21 Feb 2012 16:36:17 +0000 (GMT) Subject: Re: IP Address Schemes for BFD on LAG interfaces Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Tue, 21 Feb 2012 17:36:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C362EEF9C7896468B36C9B79200D8350D02AB456F@INBANSXCHMBSA1.in.alcatel-lucent.com> <20120220203315.GI6584@slice> <20120220204649.GK6584@slice> <7C362EEF9C7896468B36C9B79200D8350D02BE1173@INBANSXCHMBSA1.in.alcatel-lucent.com> <20120221152056.GE11722@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: Tue, 21 Feb 2012 16:36:20 -0000 Hello Alexander, > Do I miss something substantial? in my opinion: simplicity.=20 Using the first BFD packets for auto discovery of MAC and IP address is = smart in this sense. Having an extra protocol means we extend the state = machine by an "discovery" state (even if it never shows up in a BFD = packet), i.e. Discover -> Down -> Init -> Up -> Down (-> Discover?). The "life span of the micro-BFD session" still needs a discussion - = which is what we are into now anyway, wondering if multiplier Down = packets should be transmitted with unicast IP/MAC before falling back to = multicast IP and dedicated (or multicast) MAC. At least for the initial problem to solve - which is BFD over an = Ethernet (and maybe POS) LAG for IP networks - we should have something = simple as the task itself it not so terribly complicated ;-) And for the generalization of a LAG like the "composite MPLS links" I = don't like to make a statement yet; it may turn out they are better = served with other mechanism (like RFC5884 bootstrapping for the = composite MPLS links example). Regards, Marc On 2012-02-21, at 17:01 , Alexander Vainshtein wrote: > Jeff and all, > IMHO and FWIW the doubts regarding usage of different addresses in = different states actually hides a very simple fact: > Discovery of the peer address to be used in the micro-BFD session) = should be separated from the micro-BFD session. >=20 > I've said in one of my earlier emails that, for LAG with LACP (where = micro-BFD sessions are initiated by the LACP) one could use the peer = port MAC address in a non-IP encapsulation of the BFD packets. >=20 > Since the WG consensus goes now towards using IP-based encapsulation, = I suggest a separate multicast-based peer discovery protocol that would = return both IP address of the peer LAG and the MAC address of the peer = port. Micro-BFD sessions would then be initiated by this protocol and = use the same destination addresses (IP and MAC) for the life span of the = micro-BFD session. >=20 > We could use something like Router Discovery Protocol (RFC 1256) for = IPv4 or Neighbor Discovery Protocol for IPv6. The only modification is = that the advertisement messages would have to be transmitted separately = on each LAG member link. >=20 > Do I miss something substantial? >=20 > Regards, > Sasha >=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On >> Behalf Of Jeffrey Haas >> Sent: Tuesday, February 21, 2012 5:21 PM >> To: Bhatia, Manav (Manav) >> Cc: rtg-bfd@ietf.org >> Subject: Re: IP Address Schemes for BFD on LAG interfaces >>=20 >> On Tue, Feb 21, 2012 at 07:04:28PM +0530, Bhatia, Manav (Manav) = wrote: >>>> However, this would require clarification of when we send unicast = vs. >>>> multicast when we're signaling DOWN/ADMINDOWN. As an >>>> example, when we're transitioning to down we may wish to send >>>> DetectMult packets to the last known unicast address prior to >>>> transitioning back to multicast. >>>=20 >>> We have some text that talks about this in Sec 3.2 >>>=20 >>> "Each router will >>> discover the remote IP address by examining the source IP in micro >>> BFD session packets. When transitioning into INIT or UP states, >>> discovered neighbor IP address MUST be used as destination address = in >>> the IP header. Micro BFD sessions are to proceed as described in >>> [RFC5880] and [BFD-ON-LAGS]. When a micro BFD session needs to = start >>> over the session bring-up logic, destination address in the IP = header >>> MUST be reset to a well-known link-local multicast IP address. " >>>=20 >>> Is this good enough or would you like some more clarification here? >>=20 >> I'd like some clarification. Down is a natural part of our state = machine >> and it'd be nice, IMO, to make sure that sessions that may have some = state >> in an implementation (rather than a potential catch-all state machine = that >> spawns new sessions) get the chance to be torn down a bit more = explicitly >> using unicast. >>=20 >> In an ideal world, the fact that the down is arriving as multicast = shouldn't >> matter. I'm somewhat cynical about that. >>=20 >> If the WG consensus is that multicast is fine for all Down/AdminDown >> traffic, I'll cede my point. :-) >>=20 >> -- Jeff >=20 >=20 > 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 Alexander.Vainshtein@ecitele.com Tue Feb 21 08:48:03 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 187BE21F884B for ; Tue, 21 Feb 2012 08:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.101 X-Spam-Level: X-Spam-Status: No, score=-3.101 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 TzK7t8V-CguZ for ; Tue, 21 Feb 2012 08:48:02 -0800 (PST) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id DBE4C21F8834 for ; Tue, 21 Feb 2012 08:47:58 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1329842871!15624335!2 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 21374 invoked from network); 21 Feb 2012 16:47:56 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-10.tower-216.messagelabs.com with SMTP; 21 Feb 2012 16:47:56 -0000 X-AuditID: 93eaf2e7-b7f976d000000ef3-a4-4f43d6698be7 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id A6.63.03827.966D34F4; Tue, 21 Feb 2012 19:37:45 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 21 Feb 2012 18:47:55 +0200 From: Alexander Vainshtein To: Marc Binderberger Date: Tue, 21 Feb 2012 18:47:54 +0200 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: AczwtrAX8VqjhGowTDK5D3VElxgUhwAAZJcw Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02AB456F@INBANSXCHMBSA1.in.alcatel-lucent.com> <20120220203315.GI6584@slice> <20120220204649.GK6584@slice> <7C362EEF9C7896468B36C9B79200D8350D02BE1173@INBANSXCHMBSA1.in.alcatel-lucent.com> <20120221152056.GE11722@slice> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCJsWRmVeSWpSXmKPExsUy+dWnL7qZ15z9Dab2K1nsP/iW1WL2lf/M Fp//bGN0YPZYsuQnk8fl3q2sHq2ru1kCmKMaGG0S8/LySxJLUhVSUouTbZUCijLLEpMrlRQy U2yVDJUUCnISk1NzU/NKbJUSCwpS81KU7LgUMIANUFlmnkJqXnJ+SmZeuq2SZ7C/roWFqaWu oZKdmrKhsTVXSEZmsUKqbm5iZo5CbmpxcWJ6qgJQJGELc8bXe4UF17UrZu7sYmlgnKrUxcjJ ISFgIrF33TdGCFtM4sK99WwgtpDAfkaJSdO1uxi5gOxpjBL/f64CS7AJ2EpsWn0XzBYRUJW4 +/oQWDOzgIdE39bdYHEWoHjD3DZmEFtYwFLicu90Joh6K4ldy95C2UYSu74fYwexeQUCJRYv m8UGsayLWaL1632wBKeAjcSEJb/BGhiBrvt+ag0TxDJxiVtP5jNBXC0gsWTPeWYIW1Ti5eN/ rBD1ohJ32tdDHacjsWD3JzYIW1ti2cLXzBCLBSVOznzCAtErKXFwxQ2WCYzis5CsmIWkfRaS 9llI2hcwsqxiFM3MKShJyk03MNRLTc4sSc1J1UvOz93ECEktz3cw/pqvcohRgINRiYdXY6+z vxBrYllxZe4hRkkOJiVRXtNjQCG+pPyUyozE4oz4otKc1OJDjBIczEoivIsXAOV4UxIrq1KL 8mFSFsBgnsgsxZ2cD0yXeSXxxgYGKBwlcd5ViXb+QgLpwESXnZpakFoE0yrDwaEkwct1Cmiq YFFqempFWmZOCUKaiYMTZDMP0GYVkBre4oLE3OLMdIj8KUZjjo8Hnlxg5Jj24fkFRiGWvPy8 VClx3hcngUoFQEozSvPgpoEyS/3///9fMYoDfS7M+xOkigeYleDmvQJaxQS0quW/I8gqYBaB S0k1MJYmCp/OMoqffqeS9Xj+azcRD+M3nXvK8653FOk/zuKVce8WPFw08bRFHjODc1jIm8zl 925Z2oTcW58jc5vl2GktDrEbdppeu9cnqX3m9I7ZkalwnaHpz7zcZ/afH25XaU2XLhXtfbzh 3J13xqrPWHRT/WRlqs/L6m/wC92todZ/xXPmkZOLlViKMxINtZiLihMBAMKG7AcEAAA= 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, 21 Feb 2012 16:48:03 -0000 Dear Marc, I agree that "using the first BFD packets for auto discovery of MAC and IP a= ddress is smart". But I do not think it is simple, and I am a great believer in the KISS princ= iple. As for the additional states - there would be no difference with the normal= BFD operation as described in RFC 5881 IMHO. Regards, Sasha > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Tuesday, February 21, 2012 6:36 PM > To: Alexander Vainshtein > Cc: Jeffrey Haas; rtg-bfd@ietf.org > Subject: Re: IP Address Schemes for BFD on LAG interfaces > > Hello Alexander, > > > Do I miss something substantial? > > > in my opinion: simplicity. > > Using the first BFD packets for auto discovery of MAC and IP address is sm= art > in this sense. Having an extra protocol means we extend the state machine > by an "discovery" state (even if it never shows up in a BFD packet), i.e. > Discover -> Down -> Init -> Up -> Down (-> Discover?). > > The "life span of the micro-BFD session" still needs a discussion - which= is > what we are into now anyway, wondering if multiplier Down packets should > be transmitted with unicast IP/MAC before falling back to multicast IP and > dedicated (or multicast) MAC. > > At least for the initial problem to solve - which is BFD over an Ethernet= (and > maybe POS) LAG for IP networks - we should have something simple as the > task itself it not so terribly complicated ;-) > > And for the generalization of a LAG like the "composite MPLS links" I don'= t > like to make a statement yet; it may turn out they are better served with > other mechanism (like RFC5884 bootstrapping for the composite MPLS links > example). > > > Regards, Marc > > > > On 2012-02-21, at 17:01 , Alexander Vainshtein wrote: > > > Jeff and all, > > IMHO and FWIW the doubts regarding usage of different addresses in > different states actually hides a very simple fact: > > Discovery of the peer address to be used in the micro-BFD session) shoul= d > be separated from the micro-BFD session. > > > > I've said in one of my earlier emails that, for LAG with LACP (where mic= ro- > BFD sessions are initiated by the LACP) one could use the peer port MAC > address in a non-IP encapsulation of the BFD packets. > > > > Since the WG consensus goes now towards using IP-based encapsulation, I > suggest a separate multicast-based peer discovery protocol that would > return both IP address of the peer LAG and the MAC address of the peer > port. Micro-BFD sessions would then be initiated by this protocol and use > the same destination addresses (IP and MAC) for the life span of the micro= - > BFD session. > > > > We could use something like Router Discovery Protocol (RFC 1256) for IPv= 4 > or Neighbor Discovery Protocol for IPv6. The only modification is that the > advertisement messages would have to be transmitted separately on each > LAG member link. > > > > Do I miss something substantial? > > > > Regards, > > Sasha > > > >> -----Original Message----- > >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > >> Behalf Of Jeffrey Haas > >> Sent: Tuesday, February 21, 2012 5:21 PM > >> To: Bhatia, Manav (Manav) > >> Cc: rtg-bfd@ietf.org > >> Subject: Re: IP Address Schemes for BFD on LAG interfaces > >> > >> On Tue, Feb 21, 2012 at 07:04:28PM +0530, Bhatia, Manav (Manav) wrote: > >>>> However, this would require clarification of when we send unicast vs. > >>>> multicast when we're signaling DOWN/ADMINDOWN. As an > >>>> example, when we're transitioning to down we may wish to send > >>>> DetectMult packets to the last known unicast address prior to > >>>> transitioning back to multicast. > >>> > >>> We have some text that talks about this in Sec 3.2 > >>> > >>> "Each router will > >>> discover the remote IP address by examining the source IP in micro > >>> BFD session packets. When transitioning into INIT or UP states, > >>> discovered neighbor IP address MUST be used as destination address i= n > >>> the IP header. Micro BFD sessions are to proceed as described in > >>> [RFC5880] and [BFD-ON-LAGS]. When a micro BFD session needs to > start > >>> over the session bring-up logic, destination address in the IP heade= r > >>> MUST be reset to a well-known link-local multicast IP address. " > >>> > >>> Is this good enough or would you like some more clarification here? > >> > >> I'd like some clarification. Down is a natural part of our state machi= ne > >> and it'd be nice, IMO, to make sure that sessions that may have some > state > >> in an implementation (rather than a potential catch-all state machine > that > >> spawns new sessions) get the chance to be torn down a bit more > explicitly > >> using unicast. > >> > >> In an ideal world, the fact that the down is arriving as multicast shou= ldn't > >> matter. I'm somewhat cynical about that. > >> > >> If the WG consensus is that multicast is fine for all Down/AdminDown > >> traffic, I'll cede my point. :-) > >> > >> -- Jeff > > > > > > 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. > > > > -- > 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 manav.bhatia@alcatel-lucent.com Tue Feb 21 17:34: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 E0AE021E8033 for ; Tue, 21 Feb 2012 17:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.822 X-Spam-Level: X-Spam-Status: No, score=-8.822 tagged_above=-999 required=5 tests=[AWL=1.777, 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 kr5cR-svF3uz for ; Tue, 21 Feb 2012 17:34:24 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id CBD3621E8016 for ; Tue, 21 Feb 2012 17:34:24 -0800 (PST) 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 q1M1YH0V011566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Feb 2012 19:34:19 -0600 (CST) 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 q1M1YGjn019496 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 22 Feb 2012 07:04:16 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 22 Feb 2012 07:04:15 +0530 From: "Bhatia, Manav (Manav)" To: Alexander Vainshtein , Marc Binderberger Date: Wed, 22 Feb 2012 07:04:26 +0530 Subject: RE: IP Address Schemes for BFD on LAG interfaces Thread-Topic: IP Address Schemes for BFD on LAG interfaces Thread-Index: AczwtrAX8VqjhGowTDK5D3VElxgUhwAAZJcwABHlQsA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02BE11CC@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D02AB456F@INBANSXCHMBSA1.in.alcatel-lucent.com> <20120220203315.GI6584@slice> <20120220204649.GK6584@slice> <7C362EEF9C7896468B36C9B79200D8350D02BE1173@INBANSXCHMBSA1.in.alcatel-lucent.com> <20120221152056.GE11722@slice> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.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: Wed, 22 Feb 2012 01:34:26 -0000 Hi Sasha, I don't think involving an external protocol to influence BFD state machine= ry complies with the KISS principle. There are several things that can pote= ntially break. Take authentication for example. You could use HMAC-SHA to p= rotect BFD sessions. Do you get similar security with RFC 1256? In the secu= rity world your entire security is only as secure as your weakest link. If = someone can easily spoof the "discovery" messages then your entire micro BF= D session security is compromised. Its best to keep things in tight control= and as statisticians say, best to design a system with minimum degrees of = freedom. Cheers, Manav > -----Original Message----- > From: rtg-bfd-bounces@ietf.org=20 > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Alexander Vainshtein > Sent: Tuesday, February 21, 2012 10:18 PM > To: Marc Binderberger > Cc: rtg-bfd@ietf.org > Subject: RE: IP Address Schemes for BFD on LAG interfaces >=20 > Dear Marc, > I agree that "using the first BFD packets for auto discovery=20 > of MAC and IP address is smart".=20 > But I do not think it is simple, and I am a great believer in=20 > the KISS principle. >=20 > As for the additional states - there would be no difference=20 > with the normal BFD operation as described in RFC 5881 IMHO. >=20 > Regards, > Sasha >=20 >=20 > > -----Original Message----- > > From: Marc Binderberger [mailto:marc@sniff.de] > > Sent: Tuesday, February 21, 2012 6:36 PM > > To: Alexander Vainshtein > > Cc: Jeffrey Haas; rtg-bfd@ietf.org > > Subject: Re: IP Address Schemes for BFD on LAG interfaces > >=20 > > Hello Alexander, > >=20 > > > Do I miss something substantial? > >=20 > >=20 > > in my opinion: simplicity. > >=20 > > Using the first BFD packets for auto discovery of MAC and=20 > IP address=20 > > is smart in this sense. Having an extra protocol means we=20 > extend the=20 > > state machine by an "discovery" state (even if it never=20 > shows up in a BFD packet), i.e. > > Discover -> Down -> Init -> Up -> Down (-> Discover?). > >=20 > > The "life span of the micro-BFD session" still needs a discussion -=20 > > which is what we are into now anyway, wondering if multiplier Down=20 > > packets should be transmitted with unicast IP/MAC before=20 > falling back=20 > > to multicast IP and dedicated (or multicast) MAC. > >=20 > > At least for the initial problem to solve - which is BFD over an=20 > > Ethernet (and maybe POS) LAG for IP networks - we should have=20 > > something simple as the task itself it not so terribly=20 > complicated ;-) > >=20 > > And for the generalization of a LAG like the "composite=20 > MPLS links" I=20 > > don't like to make a statement yet; it may turn out they are better=20 > > served with other mechanism (like RFC5884 bootstrapping for the=20 > > composite MPLS links example). > >=20 > >=20 > > Regards, Marc > >=20 > >=20 > >=20 > > On 2012-02-21, at 17:01 , Alexander Vainshtein wrote: > >=20 > > > Jeff and all, > > > IMHO and FWIW the doubts regarding usage of different addresses in > > different states actually hides a very simple fact: > > > Discovery of the peer address to be used in the micro-BFD=20 > session)=20 > > > should > > be separated from the micro-BFD session. > > > > > > I've said in one of my earlier emails that, for LAG with=20 > LACP (where=20 > > > micro- > > BFD sessions are initiated by the LACP) one could use the peer port=20 > > MAC address in a non-IP encapsulation of the BFD packets. > > > > > > Since the WG consensus goes now towards using IP-based=20 > > > encapsulation, I > > suggest a separate multicast-based peer discovery protocol=20 > that would=20 > > return both IP address of the peer LAG and the MAC address=20 > of the peer=20 > > port. Micro-BFD sessions would then be initiated by this=20 > protocol and=20 > > use the same destination addresses (IP and MAC) for the=20 > life span of=20 > > the micro- BFD session. > > > > > > We could use something like Router Discovery Protocol=20 > (RFC 1256) for=20 > > > IPv4 > > or Neighbor Discovery Protocol for IPv6. The only=20 > modification is that=20 > > the advertisement messages would have to be transmitted=20 > separately on=20 > > each LAG member link. > > > > > > Do I miss something substantial? > > > > > > Regards, > > > Sasha > > > > > >> -----Original Message----- > > >> From: rtg-bfd-bounces@ietf.org=20 > [mailto:rtg-bfd-bounces@ietf.org] On=20 > > >> Behalf Of Jeffrey Haas > > >> Sent: Tuesday, February 21, 2012 5:21 PM > > >> To: Bhatia, Manav (Manav) > > >> Cc: rtg-bfd@ietf.org > > >> Subject: Re: IP Address Schemes for BFD on LAG interfaces > > >> > > >> On Tue, Feb 21, 2012 at 07:04:28PM +0530, Bhatia, Manav=20 > (Manav) wrote: > > >>>> However, this would require clarification of when we=20 > send unicast vs. > > >>>> multicast when we're signaling DOWN/ADMINDOWN. As an example,=20 > > >>>> when we're transitioning to down we may wish to send=20 > DetectMult=20 > > >>>> packets to the last known unicast address prior to=20 > transitioning=20 > > >>>> back to multicast. > > >>> > > >>> We have some text that talks about this in Sec 3.2 > > >>> > > >>> "Each router will > > >>> discover the remote IP address by examining the=20 > source IP in micro > > >>> BFD session packets. When transitioning into INIT or=20 > UP states, > > >>> discovered neighbor IP address MUST be used as=20 > destination address in > > >>> the IP header. Micro BFD sessions are to proceed as=20 > described in > > >>> [RFC5880] and [BFD-ON-LAGS]. When a micro BFD=20 > session needs to > > start > > >>> over the session bring-up logic, destination address=20 > in the IP header > > >>> MUST be reset to a well-known link-local multicast IP=20 > address. " > > >>> > > >>> Is this good enough or would you like some more=20 > clarification here? > > >> > > >> I'd like some clarification. Down is a natural part of=20 > our state=20 > > >> machine and it'd be nice, IMO, to make sure that=20 > sessions that may=20 > > >> have some > > state > > >> in an implementation (rather than a potential catch-all state=20 > > >> machine > > that > > >> spawns new sessions) get the chance to be torn down a bit more > > explicitly > > >> using unicast. > > >> > > >> In an ideal world, the fact that the down is arriving as=20 > multicast=20 > > >> shouldn't matter. I'm somewhat cynical about that. > > >> > > >> If the WG consensus is that multicast is fine for all=20 > > >> Down/AdminDown traffic, I'll cede my point. :-) > > >> > > >> -- Jeff > > > > > > > > > This e-mail message is intended for the recipient only=20 > and contains > > information which is CONFIDENTIAL and which may be=20 > proprietary to ECI=20 > > Telecom. If you have received this transmission in error, please=20 > > inform us by e-mail, phone or fax, and then delete the=20 > original and all copies thereof. > > > > >=20 > > -- > > Marc Binderberger >=20 >=20 >=20 > This e-mail message is intended for the recipient only and=20 > contains information which is CONFIDENTIAL and which may be=20 > proprietary to ECI Telecom. If you have received this=20 > transmission in error, please inform us by e-mail, phone or=20 > fax, and then delete the original and all copies thereof. >=20 > = From toms.sanders@gmail.com Wed Feb 22 07:52:54 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 9CFDD21F883B for ; Wed, 22 Feb 2012 07:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 HTBiyVRN8Ecc for ; Wed, 22 Feb 2012 07:52:54 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BFB1A21F8809 for ; Wed, 22 Feb 2012 07:52:53 -0800 (PST) Received: by werg1 with SMTP id g1so151248wer.31 for ; Wed, 22 Feb 2012 07:52:53 -0800 (PST) Received-SPF: pass (google.com: domain of toms.sanders@gmail.com designates 10.180.93.194 as permitted sender) client-ip=10.180.93.194; Authentication-Results: mr.google.com; spf=pass (google.com: domain of toms.sanders@gmail.com designates 10.180.93.194 as permitted sender) smtp.mail=toms.sanders@gmail.com; dkim=pass header.i=toms.sanders@gmail.com Received: from mr.google.com ([10.180.93.194]) by 10.180.93.194 with SMTP id cw2mr36510779wib.0.1329925973028 (num_hops = 1); Wed, 22 Feb 2012 07:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=SYe0p5UlxK5PxkyfoURFaQcIgQZEx33EQpWqarNi5d8=; b=TBa/Gd6Qy+3m2CKF6hJXvhNY1T66Rh28wV8DjHcHRT4A2ik+/RTCak28Y6i2Le3EKn oHM4rJLbSBLNXEuj/jryn99M1sL/53NY1Yg22yWj4XLR11g2sXb92UQ6AxStp8O/TGhj 3ciOUhd/L9Yc7xYZBjxpm/XSbRBptaEz8yuCY= MIME-Version: 1.0 Received: by 10.180.93.194 with SMTP id cw2mr30212723wib.0.1329925972943; Wed, 22 Feb 2012 07:52:52 -0800 (PST) Received: by 10.223.62.67 with HTTP; Wed, 22 Feb 2012 07:52:52 -0800 (PST) Date: Wed, 22 Feb 2012 21:22:52 +0530 Message-ID: Subject: TTL of micro BFD packets? From: Tom Sanders To: rtg-bfd@ietf.org Content-Type: text/plain; charset=UTF-8 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, 22 Feb 2012 15:52:54 -0000 Hi, Just wondering. What will the TTL be set to for the micro BFD packets? Will it be 1 or set to 255 by the sender and checked to be 254 by the receiver? We should be chary in specifying the TTL as that would mean that the micro BFD packets can never traverse multiple IP hops. Is that ok? I think it is as long as we assume that a micro BFD session can only be established between two back to back routers. However, that precludes the possibility of supporting micro BFD sessions over a composite link. Or perhaps that never ever was the intention, eh? Personally i would like it to remain unspecified for future extensibility. -- Toms. From marc@sniff.de Wed Feb 22 08:03:45 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 D261421F887F for ; Wed, 22 Feb 2012 08:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 ankHEhlfRN3s for ; Wed, 22 Feb 2012 08:03:39 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DF921F87DD for ; Wed, 22 Feb 2012 08:03:39 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 632FB2AA0F; Wed, 22 Feb 2012 16:03:37 +0000 (GMT) Subject: Re: TTL of micro BFD packets? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Wed, 22 Feb 2012 17:03:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tom Sanders 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: Wed, 22 Feb 2012 16:03:45 -0000 Hello Tom, I agree we should have flexibility. Now draft-mmm-03 is specific for = IP/UDP packets over LAG and does not really cover "composite XYZ". There = is just a discussion if we need to generalize the draft. To allow for the low-cost security mechanism we have with other = single-hop BFD sessions I would like to see TTL=3D255 for IP/UDP = encapsulated BFD packets for LAG member links. Similar to RFC5880 we can = relax the TTL requirements when authentication is used. My $0.02 Regards, Marc On 2012-02-22, at 16:52 , Tom Sanders wrote: > Hi, >=20 > Just wondering. What will the TTL be set to for the micro BFD packets? > Will it be 1 or set to 255 by the sender and checked to be 254 by the > receiver? >=20 > We should be chary in specifying the TTL as that would mean that the > micro BFD packets can never traverse multiple IP hops. Is that ok? I > think it is as long as we assume that a micro BFD session can only be > established between two back to back routers. However, that precludes > the possibility of supporting micro BFD sessions over a composite > link. Or perhaps that never ever was the intention, eh? >=20 > Personally i would like it to remain unspecified for future = extensibility. >=20 > --=20 > Toms. >=20 -- Marc Binderberger From gregory.mirsky@ericsson.com Wed Feb 22 08:41:34 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 D4F7E21F886B for ; Wed, 22 Feb 2012 08:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 oODPv40Rg6+j for ; Wed, 22 Feb 2012 08:41:34 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0708E21F885B for ; Wed, 22 Feb 2012 08:41:33 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q1MGfVLp010296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Feb 2012 10:41:31 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.76]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 22 Feb 2012 11:41:27 -0500 From: Gregory Mirsky To: Tom Sanders , "rtg-bfd@ietf.org" Date: Wed, 22 Feb 2012 11:41:26 -0500 Subject: RE: TTL of micro BFD packets? Thread-Topic: TTL of micro BFD packets? Thread-Index: AczxehZQlKdhQnn/RR+3fXckRyTqRwABaXhg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-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, 22 Feb 2012 16:41:34 -0000 Hi Tom, I wonder why support of micro-BFD on IP-enabled composite links (that by it= self seems to me as strong limitation) would require IP TTL of more then on= e hop? If member link is logical, not physical then it appears as layer vio= lation as composite links are always between the same two routers. Or you r= efer to another model of composite links not the one in draft-ietf-rtgwg-cl= -requirement-05? Regards, Greg -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Tom Sanders Sent: Wednesday, February 22, 2012 7:53 AM To: rtg-bfd@ietf.org Subject: TTL of micro BFD packets? Hi, Just wondering. What will the TTL be set to for the micro BFD packets? Will it be 1 or set to 255 by the sender and checked to be 254 by the recei= ver? We should be chary in specifying the TTL as that would mean that the micro = BFD packets can never traverse multiple IP hops. Is that ok? I think it is = as long as we assume that a micro BFD session can only be established betwe= en two back to back routers. However, that precludes the possibility of sup= porting micro BFD sessions over a composite link. Or perhaps that never eve= r was the intention, eh? Personally i would like it to remain unspecified for future extensibility. -- Toms. From manav.bhatia@alcatel-lucent.com Wed Feb 22 17:30:53 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1300B21E801D for ; Wed, 22 Feb 2012 17:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.851 X-Spam-Level: X-Spam-Status: No, score=-6.851 tagged_above=-999 required=5 tests=[AWL=-0.252, 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 5cfjvRD1ACDQ for ; Wed, 22 Feb 2012 17:30:52 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7F95921E8013 for ; Wed, 22 Feb 2012 17:30:52 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q1N1UkfK018118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Feb 2012 19:30:49 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q1N1UgO5007762 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 23 Feb 2012 07:00:45 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 23 Feb 2012 07:00:42 +0530 From: "Bhatia, Manav (Manav)" To: Tom Sanders , "rtg-bfd@ietf.org" Date: Thu, 23 Feb 2012 07:02:57 +0530 Subject: RE: TTL of micro BFD packets? Thread-Topic: TTL of micro BFD packets? Thread-Index: AczxegzUYLYILlx7SxO9eaD6j5jVSgATyYag Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02BE14A7@INBANSXCHMBSA1.in.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.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, 23 Feb 2012 01:30:53 -0000 Hi Tom, > Just wondering. What will the TTL be set to for the micro BFD packets? > Will it be 1 or set to 255 by the sender and checked to be=20 > 254 by the receiver? Should be the latter. >=20 > We should be chary in specifying the TTL as that would mean=20 > that the micro BFD packets can never traverse multiple IP=20 > hops. Is that ok? I think it is as long as we assume that a=20 I think it should be ok. You don't want micro BFD packets to be traversing = multiple IP hops. > micro BFD session can only be established between two back to=20 > back routers. However, that precludes the possibility of=20 > supporting micro BFD sessions over a composite link. Or=20 > perhaps that never ever was the intention, eh? composite link, as the name suggests is just a "link", and as such should o= nly be one IP hop. >=20 > Personally i would like it to remain unspecified for future=20 > extensibility. This to me would be a hack! :-) The intention of the draft-mmm- is to monitor individual component links in= a bundle and to remove a link for L3 forwarding if the micro session over = that link goes down. I don't see why we would need multiple hops if its onl= y the "link" liveliness that we're interested in. While we have taken an ex= ample of a LAG as a bundle there is really nothing that precludes the possi= bility of that bundle being a composite link comprising of MPLS tunnels or = something else. In that case the "link" could be an MPLS tunnel. Yes, we have some text that's specific to IEEE 802.1ax and LACP, but the id= ea can be generalized to work for other bundles that have separate componen= t links. The draft specifically talks about IEEE 802.1ax and LACP since tha= t's what our customers have been specifically asking us to fix. Cheers, Manav >=20 > -- > Toms. > = From gregimirsky@gmail.com Thu Feb 23 16:07: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 344D921F88B3 for ; Thu, 23 Feb 2012 16:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, 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 oVwsf3GLoYGB for ; Thu, 23 Feb 2012 16:07:06 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 49BE521F88A2 for ; Thu, 23 Feb 2012 16:07:06 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2458410obb.31 for ; Thu, 23 Feb 2012 16:07:05 -0800 (PST) Received-SPF: pass (google.com: domain of gregimirsky@gmail.com designates 10.182.159.65 as permitted sender) client-ip=10.182.159.65; Authentication-Results: mr.google.com; spf=pass (google.com: domain of gregimirsky@gmail.com designates 10.182.159.65 as permitted sender) smtp.mail=gregimirsky@gmail.com; dkim=pass header.i=gregimirsky@gmail.com Received: from mr.google.com ([10.182.159.65]) by 10.182.159.65 with SMTP id xa1mr1453080obb.25.1330042025973 (num_hops = 1); Thu, 23 Feb 2012 16:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZD9hqlOJkyHqcGa6sfzNiE9oUrTTKe0UEG267bu51kQ=; b=pc6Ze5xUiUDb+rWI1FSgn3gE06TxQlIoSsPikpsUt5fvBXEpGkaWvesTp/XWwT3Oso JFP9WvM3n6z5PmkBCS5gL4t5MlaEU5lKPsGi7LH638M0fJprK3AK7NPI7dbxGtnheaWn dtfmFqKUup1j1jC4xVbnlxnN8teAOiCiyqkWQ= MIME-Version: 1.0 Received: by 10.182.159.65 with SMTP id xa1mr1268651obb.25.1330042025811; Thu, 23 Feb 2012 16:07:05 -0800 (PST) Received: by 10.182.38.67 with HTTP; Thu, 23 Feb 2012 16:07:05 -0800 (PST) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02BE14A7@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D02BE14A7@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Thu, 23 Feb 2012 16:07:05 -0800 Message-ID: Subject: Re: TTL of micro BFD packets? From: Greg Mirsky To: "Bhatia, Manav (Manav)" Content-Type: multipart/alternative; boundary=14dae9399b917c209604b9aa8a45 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, 24 Feb 2012 00:07:07 -0000 --14dae9399b917c209604b9aa8a45 Content-Type: text/plain; charset=ISO-8859-1 Dear Manav, you've brought interesting scneario in your example of composite that has MPLS LSP as member link: "In that case the "link" could be an MPLS tunnel." In this case, would use of multicast IP address for multi-BFD and 127/8 for BFD with IP/UDP encapsulation over the same MPLS LSP be slightly confusing? Regards, Greg On Wed, Feb 22, 2012 at 5:32 PM, Bhatia, Manav (Manav) < manav.bhatia@alcatel-lucent.com> wrote: > Hi Tom, > > > Just wondering. What will the TTL be set to for the micro BFD packets? > > Will it be 1 or set to 255 by the sender and checked to be > > 254 by the receiver? > > Should be the latter. > > > > > We should be chary in specifying the TTL as that would mean > > that the micro BFD packets can never traverse multiple IP > > hops. Is that ok? I think it is as long as we assume that a > > I think it should be ok. You don't want micro BFD packets to be traversing > multiple IP hops. > > > micro BFD session can only be established between two back to > > back routers. However, that precludes the possibility of > > supporting micro BFD sessions over a composite link. Or > > perhaps that never ever was the intention, eh? > > composite link, as the name suggests is just a "link", and as such should > only be one IP hop. > > > > > Personally i would like it to remain unspecified for future > > extensibility. > > This to me would be a hack! :-) > > The intention of the draft-mmm- is to monitor individual component links > in a bundle and to remove a link for L3 forwarding if the micro session > over that link goes down. I don't see why we would need multiple hops if > its only the "link" liveliness that we're interested in. While we have > taken an example of a LAG as a bundle there is really nothing that > precludes the possibility of that bundle being a composite link comprising > of MPLS tunnels or something else. In that case the "link" could be an MPLS > tunnel. > > Yes, we have some text that's specific to IEEE 802.1ax and LACP, but the > idea can be generalized to work for other bundles that have separate > component links. The draft specifically talks about IEEE 802.1ax and LACP > since that's what our customers have been specifically asking us to fix. > > Cheers, Manav > > > > > -- > > Toms. > > --14dae9399b917c209604b9aa8a45 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Manav,
you've brought interesting scneario in your example of c= omposite that has MPLS LSP as member link:
"In that case the "= link" could be an MPLS tunnel."
In this case, would use of mul= ticast IP address for multi-BFD and 127/8 for BFD with IP/UDP encapsulation= over the same MPLS LSP be slightly confusing?

Regards,
Greg

On Wed, Feb 22, 2012= at 5:32 PM, Bhatia, Manav (Manav) <manav.bhatia@alcatel-lucent.com> wrote:
Hi Tom,

> Just wondering. What will the TTL be set to for the micro BFD packets?=
> Will it be 1 or set to 255 by the sender and checked to be
> 254 by the receiver?

Should be the latter.

>
> We should be chary in specifying the TTL as that would mean
> that the micro BFD packets can never traverse multiple IP
> hops. Is that ok? I think it is as long as we assume that a

I think it should be ok. You don't want micro BFD packets to be t= raversing multiple IP hops.

> micro BFD session can only be established between two back to
> back routers. However, that precludes the possibility of
> supporting micro BFD sessions over a composite link. Or
> perhaps that never ever was the intention, eh?

composite link, as the name suggests is just a "link", and = as such should only be one IP hop.

>
> Personally i would like it to remain unspecified for future
> extensibility.

This to me would be a hack! :-)

The intention of the draft-mmm- is to monitor individual component links in= a bundle and to remove a link for L3 forwarding if the micro session over = that link goes down. I don't see why we would need multiple hops if its= only the "link" liveliness that we're interested in. While w= e have taken an example of a LAG as a bundle there is really nothing that p= recludes the possibility of that bundle being a composite link comprising o= f MPLS tunnels or something else. In that case the "link" could b= e an MPLS tunnel.

Yes, we have some text that's specific to IEEE 802.1ax and LACP, but th= e idea can be generalized to work for other bundles that have separate comp= onent links. The draft specifically talks about IEEE 802.1ax and LACP since= that's what our customers have been specifically asking us to fix.

Cheers, Manav

>
> --
> Toms.
>

--14dae9399b917c209604b9aa8a45-- From Alexander.Vainshtein@ecitele.com Sat Feb 25 22:15: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 4ED5321F860D for ; Sat, 25 Feb 2012 22:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.086 X-Spam-Level: X-Spam-Status: No, score=-3.086 tagged_above=-999 required=5 tests=[AWL=-0.883, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 mdz4MW92w+Ot for ; Sat, 25 Feb 2012 22:15:24 -0800 (PST) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 18D5621F860F for ; Sat, 25 Feb 2012 22:15:23 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1330236921!16933993!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 23519 invoked from network); 26 Feb 2012 06:15:21 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-12.tower-216.messagelabs.com with SMTP; 26 Feb 2012 06:15:21 -0000 X-AuditID: 93eaf2e7-b7f976d000000ef3-94-4f49d9871240 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id B6.8B.03827.789D94F4; Sun, 26 Feb 2012 09:04:39 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sun, 26 Feb 2012 08:15:20 +0200 From: Alexander Vainshtein To: Greg Mirsky , "Bhatia, Manav (Manav)" Date: Sun, 26 Feb 2012 08:13:17 +0200 Subject: RE: TTL of micro BFD packets? Thread-Topic: TTL of micro BFD packets? Thread-Index: Aczyh/xVpDlUObp0S0OO2dbtPmOHFQBxLIlV Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02BE14A7@INBANSXCHMBSA1.in.alcatel-lucent.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTfUgTYRzm3W3zXF6cU9vrCLquNNQmLgsWur4g0UhWVlCW1rW9bUfbbdyt aAa1ogjt26CPkWhoqZVEJVqaRZJgQkwrwz4cQdmHSdAHhn3Ze1yZ0f313O95nt/zvi+/H0no I1ojyQt+JAqcm9Xq1McGP3427XucZ8t4MDTbMnx8QGM5HYloLJ++N4EFRO7eV22a3Ouh/qjc mpoR1TKiMAiyOUHw+jk/YhxIslvZZSK/lbMHWIZ3WFkzy/jcnB15kOC3spzPhwQHO0/H/Pdl YxkvMEiwex284LSyeStsJotlzlyTmZ2XPM2cmaVb6eIlBpk8HO9mPEiSOCdicGVDI+HqOX0T +FoSt9WcHFIHwdH4MkCSkJ4Ny4d2lIFoDCfB7sglbRnQkXr6FoCHhru1MqGnjwP4tCVFxlra Cq9c6NfK3njaARver5HLBJ0Cd3d+ipKxmk6CJ59fjpIlcXQy7KjOV9Qz4MD+hQqcBXsuFsti il4O+372q5TQtwDeqa0EMhGNidYT5RoZA3yyL10XVUqSAT55WalSTkzDmhthQsEJ8O2Ln7/1 CfDZvktA0c+EVa0ftQpOg+fOvCOU4Fh499RLteJNhLfr+tRHgCE0LiI0zh4aZw+Ns1cB9XmQ wLt9/o0eZ4Y5Hdl5P3KjdLvXcwUok/L6GvhaOb0d0CRgY6iq5jybXsNtlQKedpBIqtgEqrEL lyZu9DoCLk5yrRe3uJHUDiBJsPHU+0bMUQ4uUIJE7x/Kgt/4KGGcYPfimRT86zMzMv75YQ3U jLU5Nj3txAO3GSEfEv9YJ5MkCyn6Hu4aKyIn2raJd/v/0ioyWk6OwclLZQ0l+TiPxDsVvgtM NRook0zQMuHaIox55bXYOTo6OggM+J5xVKqsisFLM+YexI1VuPH8H4vlxngZxihjEJR0UCPC t8l7gqUG0bOkYlV36YH6HoN+/8FSITM1v6DhzdnOnIL7dExJB6yPSg6vGRhWN6x+rikuqg20 DRVdHXxUfthWmZZY/TCSXz3FEghn9fZeAMawrk6rtxnTS9cdKNoevygH2nuad1VMDWZXNHXa mA/v3uxY/PSEmBTOKWTVkoszpxKixP0CxqVkV/EDAAA= 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, 26 Feb 2012 06:15:25 -0000 Dear Greg & Manav, I concur with Greg. if the "link? Is a P2P LSP carrying IP, Ethernet encapsulation would not be= preserved. It could be an Ethernet PW, but in this case you would not have to worry abo= ut IP TTL. And, what is IMHO much more important, you would probably use Bfd for the LS= P or BFD in VCCV for the PW and not a much more complicated microiBFD sessio= n. i'd like to reiterate my statement that the primary use case for micro-BFD s= essions is the situation where nativr lin failure indicatuons are not avail= able. Making these sessions into a kind of theSwiss army knife is not justif= ied IMHO. Regards, Sasha ________________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of Greg= Mirsky [gregimirsky@gmail.com] Sent: Friday, February 24, 2012 2:07 AM To: Bhatia, Manav (Manav) Cc: rtg-bfd@ietf.org Subject: Re: TTL of micro BFD packets? Dear Manav, you've brought interesting scneario in your example of composite that has MP= LS LSP as member link: "In that case the "link" could be an MPLS tunnel." In this case, would use of multicast IP address for multi-BFD and 127/8 for= BFD with IP/UDP encapsulation over the same MPLS LSP be slightly confusing? Regards, Greg On Wed, Feb 22, 2012 at 5:32 PM, Bhatia, Manav (Manav) > wrote: Hi Tom, > Just wondering. What will the TTL be set to for the micro BFD packets? > Will it be 1 or set to 255 by the sender and checked to be > 254 by the receiver? Should be the latter. > > We should be chary in specifying the TTL as that would mean > that the micro BFD packets can never traverse multiple IP > hops. Is that ok? I think it is as long as we assume that a I think it should be ok. You don't want micro BFD packets to be traversing m= ultiple IP hops. > micro BFD session can only be established between two back to > back routers. However, that precludes the possibility of > supporting micro BFD sessions over a composite link. Or > perhaps that never ever was the intention, eh? composite link, as the name suggests is just a "link", and as such should on= ly be one IP hop. > > Personally i would like it to remain unspecified for future > extensibility. This to me would be a hack! :-) The intention of the draft-mmm- is to monitor individual component links in= a bundle and to remove a link for L3 forwarding if the micro session over t= hat link goes down. I don't see why we would need multiple hops if its only= the "link" liveliness that we're interested in. While we have taken an exam= ple of a LAG as a bundle there is really nothing that precludes the possibil= ity of that bundle being a composite link comprising of MPLS tunnels or some= thing else. In that case the "link" could be an MPLS tunnel. Yes, we have some text that's specific to IEEE 802.1ax and LACP, but the ide= a can be generalized to work for other bundles that have separate component= links. The draft specifically talks about IEEE 802.1ax and LACP since that'= s what our customers have been specifically asking us to fix. Cheers, Manav > > -- > Toms. > 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.