From mach@huawei.com Tue Jun 1 02:35:24 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D563A68A5 for ; Tue, 1 Jun 2010 02:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeQwttFWEfeT for ; Tue, 1 Jun 2010 02:35:23 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 056BD3A68A7 for ; Tue, 1 Jun 2010 02:35:23 -0700 (PDT) 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 <0L3B001OKX7Z6K@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Tue, 01 Jun 2010 17:33:35 +0800 (CST) Received: from m55527c ([10.110.98.169]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3B00LHPX7YJZ@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Tue, 01 Jun 2010 17:33:35 +0800 (CST) Date: Tue, 01 Jun 2010 17:33:34 +0800 From: Mach Chen Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01 In-reply-to: To: Mukund Mani , rtg-bfd@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 01 Jun 2010 09:35:24 -0000 Hi Mukund, Sorry for the delay response! The case you described maybe occur, and strictly speaking, it is not very accurate to mention that the "Backward direction BFD session exists" as return code, how about "BFD session collision"? or do you have any other suggestions? Best regards, Mach -------------------------------------------------- From: "Mukund Mani" Sent: Monday, May 31, 2010 3:04 AM To: Subject: Query on draft-chen-mpls-bfd-enhancement-01 > Hi > > Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could the draft > authors kindly clarify the same: > > Section 4 on session establishment mentions the following: > > If node with the larger IP receives LSP ping > message signaling BFD session with Session Control TLV, LSP ping > reply must be transmitted with "Backward direction BFD session > exists" to the ingress LSR. > > > > In the case of BFD session provisioned on both nodes in the Active > mode, the LSP Ping for the backward direction BFD session could be > received even when the forward direction session is not yet > established. In that case is it correct to mention that the "Backward > direction BFD session exists" as return code? > > > Kindly let me know if I am missing something here... > > > With Regards > > Mukund > From glen.kent@gmail.com Tue Jun 1 17:17:15 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 451CF3A67F5 for ; Tue, 1 Jun 2010 17:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaXkztd+kF3B for ; Tue, 1 Jun 2010 17:17:12 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id B751E3A68DF for ; Tue, 1 Jun 2010 17:17:11 -0700 (PDT) Received: by gwj19 with SMTP id 19so4277078gwj.31 for ; Tue, 01 Jun 2010 17:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3aYD9OQJXmsCtCbzkWmZJ/Q3wG78vtkH70ru7nTk2FE=; b=pMF+yOg2hnFU61SY1TOArnODdgCgZUaQPbPgawgFb6EOLxEeoaIeMqWOxdPw72t/ya aGA5f9FEmtQQlR6ElLKF6shUimsUqpxlQs/W2lVZgSvNnlr22RGaN4EsR+jeHdVj8M9Z MU/PXYct6uXcAr9x+Yb/52/fBgwthIUEpsoaI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Y6ZZKlYwBYC4N6iAocrcVNHw0mphJdhaAvLafuQFtqlquYgioAh1Q5rkSFox3z7q1I UrD/l/WQ6J0iY0duXSMCAkU9/+jWjMZ3ybHOCVkDZFgjMTP+z7GKh+2Bxienm5lzyoDH HqJb4fo1ECXrHuTMZvd7aM6eeTD+IPxgmZi2s= MIME-Version: 1.0 Received: by 10.101.203.27 with SMTP id f27mr7555059anq.239.1275437819185; Tue, 01 Jun 2010 17:16:59 -0700 (PDT) Received: by 10.100.248.18 with HTTP; Tue, 1 Jun 2010 17:16:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 Jun 2010 05:46:59 +0530 Message-ID: Subject: Re: BFD alternate path? From: Glen Kent To: Vishwas Manral 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.9 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, 02 Jun 2010 00:17:15 -0000 Hi Vishwas, I'll summarize my understanding. Please let me know if i am way off the mar= k. In case of BFD between directly connected nexthops (e.g. when running over an IP interface for OSPF, static routes) then we need to ensure that BFD packets dont follow the IP route and instead are *always* only sent out on that interface. This will ensure that if this interface goes down then we STOP sending BFD packets, as otherwise, the BFD packets may take an alternate IP path. In case of multihop BFD sessions, BFD must follow the IP path, which means that if the interface goes down, then BFD should take up an alternate path if available to reach the other peer. Is this correct? Glen On Tue, Jun 1, 2010 at 8:54 AM, Vishwas Manral wro= te: > Hi Glen, > > If I wanted to monitor if the peer was UP and not just an interface UP > I could use that. > > One example I can give you is in LMP, we can have multiple control > channels over individual interfaces for a control adjacency for a > neighbor. So if the peer crashed I would want to bring down the > control adjacency, but if an interface went down I would want to keep > the control adjacency UP. > > One way could be have a different BFD session over each control > channel. Another way is to have a control channel which is not bound > to an interface. So in case there is another way the rerouting can > happen even before BFD can trigger it (loss of carrier), we can use a > single BFD session to the peer router. > > Hope that is of some help. > > Thanks, > Vishwas > > On Mon, May 31, 2010 at 8:00 PM, Glen Kent wrote: >> Hi Vishwas, >> >> Dont intend to be picky, but .. >> >>> >>> In single hop cases the BFD session is generally bound to the >>> interface. So the BFD session will brought down. >> >> You use "generally". Does it mean that there would be instances when >> the BFD session for a directly connected nexthop will NOT be tied to >> an interface. If so, when and under what circumstances would that >> happen? >> >> Glen >> >>> >>> Thanks, >>> Vishwas >>> >>> On Mon, May 31, 2010 at 5:13 PM, Glen Kent wrote: >>>> Vishwas, >>>> >>>> This might work for a multihop session. How about directly connected >>>> next-hops that i brought up in my previous email. >>>> >>>> A -- B >>>> | =A0 =A0 =A0| >>>> C ---+ >>>> >>>> In this case if link A-B fails, will BFD on A and B use the alternate >>>> path via C (assume its the default gateway in for both A and B)? More >>>> details in my previous email. >>>> >>>> Glen >>>> >>>> On Tue, Jun 1, 2010 at 4:58 AM, Vishwas Manral wrote: >>>>> Hi Glen, >>>>> >>>>> If you want to monitor that a session goes over a particular link you >>>>> can impose the restriction to a Multihop session in which case the BF= D >>>>> session will fail. >>>>> >>>>> If we do not impose the restriction the session will stay UP. I do no= t >>>>> see any sort of collision of interests. It depends on what an operato= r >>>>> wants and can get the right behavior using BFD. >>>>> >>>>> Thanks, >>>>> Vishwas >>>>> >>>>> On Mon, May 31, 2010 at 3:56 PM, Glen Kent wrot= e: >>>>>>> >>>>>>> However in some cases (multihop sessions), the BFD session timers w= ill >>>>>>> be set to higher value so that the lower level sessions can converg= e >>>>>> >>>>>> In case of multihop sessions, say between two IBGP =A0peers, what is= a >>>>>> lower level session here? Is this the IGP? >>>>>> >>>>>> My doubt is this: >>>>>> >>>>>> A -- B >>>>>> | =A0 =A0 =A0| >>>>>> C ---+ >>>>>> >>>>>> A and B are directly connected. A can also reach B via C. I am runni= ng >>>>>> a BFD session between A and B. Since A and B are directly connected, >>>>>> BFD packets will always use the A-B interface. However, if A-B fails= , >>>>>> then will BFD packets take the alternate path available via C to rea= ch >>>>>> the other end. I am not sure if this will happen as its a >>>>>> chicken-and-egg problem - BFD can take the alternate path only if th= e >>>>>> IGP recomputes the path. IGP can recompute only when it learns that >>>>>> A-B has gone down, and its most probably only BFD that can inform th= e >>>>>> IGP that A-B has gone down (assume for instance when there is a swit= ch >>>>>> in between A and B and the switch goes down). >>>>>> >>>>>> Also, what will happen if there is a default route on both A and B v= ia >>>>>> C. In that case BFD need not wait for the IGP to reconverge. It can >>>>>> always take the alternate path. Will in such cases, BFD take the >>>>>> alternate path and keep the session alive? If it does that then its >>>>>> wrong as the physical link has indeed gone down. >>>>>> >>>>>> Glen >>>>>> >>>>>>> faster (which will result in the session staying up). If we do not >>>>>>> want the behavior we can set the timers to smaller values. This >>>>>>> however is a choice of the operator. >>>>>>> >>>>>>> Thanks, >>>>>>> Vishwas >>>>>>> >>>>>>> On Sun, May 30, 2010 at 9:12 PM, Glen Kent wr= ote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Assume the link that i have between two BFD enabled routers A and = B >>>>>>>> goes down. Will BFD, since its riding on top of UDP, automatically >>>>>>>> follow the routing table and try to find an alternate path to keep= the >>>>>>>> connectivity alive? >>>>>>>> >>>>>>>> If Yes, then this will result in BFD session remaining up, while t= he >>>>>>>> link is down. Is this acceptable? >>>>>>>> >>>>>>>> Glen >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From glen.kent@gmail.com Tue Jun 1 17:20:21 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1493A6833 for ; Tue, 1 Jun 2010 17:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17vhVqtqYBL4 for ; Tue, 1 Jun 2010 17:20:20 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id B906E3A67F5 for ; Tue, 1 Jun 2010 17:20:20 -0700 (PDT) Received: by gwj19 with SMTP id 19so4278994gwj.31 for ; Tue, 01 Jun 2010 17:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=fUC9OcjrG+QEDkyVp/K/znol1JWghJkr8Ee4Bxyc//c=; b=g8DAFtqly0vk9YqdKuGIGChB6XUDaVH8XiXmBHJjg6WkDCo5iLrAr2MVelEH91jveo qRHay5rvFOvSRSb5Rvqa9i+mTDAydhzYpNPQ+3ONGgv0XfoC3ciFYpQFilWwbKnswcmY UUMy8tqJcNX8LehOtXEMHlFEEBhnPBXy4pUaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NvvzT3MXaWbUjuaoWbzl1V9fAmB7FopJipv7xuHreIh+UlkGLbyK+tKTtuplPQpSir 5vsa8RyQXW9UKBwurdhc5naFfqfd8r/W2JNxia6nC5UCmJVPKLWd993oeRw5DEjvsebK x0lRqwIn7O6T9/CvXzGkog3Btz4c0/B6YvX44= MIME-Version: 1.0 Received: by 10.100.243.23 with SMTP id q23mr7637091anh.147.1275438004841; Tue, 01 Jun 2010 17:20:04 -0700 (PDT) Received: by 10.100.248.18 with HTTP; Tue, 1 Jun 2010 17:20:04 -0700 (PDT) Date: Wed, 2 Jun 2010 05:50:04 +0530 Message-ID: Subject: BFD on LAN From: Glen Kent To: rtg-bfd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jun 2010 00:20:21 -0000 Hi, Since BFD does not use a mcast address does it mean that it will form a full mesh of unicast BFD sessions on a LAN? Glen From rrahman@cisco.com Tue Jun 1 17:23:26 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 663D63A67F5 for ; Tue, 1 Jun 2010 17:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOsklBqtnqQw for ; Tue, 1 Jun 2010 17:23:25 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BD5DE3A6833 for ; Tue, 1 Jun 2010 17:23:21 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANVABUytJV2c/2dsb2JhbACeDXGnJpoahRMEg0U X-IronPort-AV: E=Sophos;i="4.53,343,1272844800"; d="scan'208";a="116931372" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 02 Jun 2010 00:23:08 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o520N8Zl020324; Wed, 2 Jun 2010 00:23:08 GMT Received: from xmb-rcd-204.cisco.com ([72.163.62.211]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jun 2010 19:23:08 -0500 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: BFD on LAN Date: Tue, 1 Jun 2010 19:23:03 -0500 Message-ID: <654701C60BCC7C4EBD533B89D72BDFEA01718E1A@XMB-RCD-204.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD on LAN Thread-Index: AcsB6WEVmMdWoyl1TZubVUh7hLz4hwAAE79w References: From: "Reshad Rahman (rrahman)" To: "Glen Kent" , X-OriginalArrivalTime: 02 Jun 2010 00:23:08.0798 (UTC) FILETIME=[C701C1E0:01CB01E9] X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jun 2010 00:23:26 -0000 Yes. -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Glen Kent Sent: Tuesday, June 01, 2010 8:20 PM To: rtg-bfd@ietf.org Subject: BFD on LAN Hi, Since BFD does not use a mcast address does it mean that it will form a full mesh of unicast BFD sessions on a LAN? Glen From vishwas.ietf@gmail.com Tue Jun 1 18:35:52 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B20E3A6877 for ; Tue, 1 Jun 2010 18:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.039 X-Spam-Level: X-Spam-Status: No, score=-1.039 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDsV4skpa-DR for ; Tue, 1 Jun 2010 18:35:47 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 5BAA33A685A for ; Tue, 1 Jun 2010 18:35:46 -0700 (PDT) Received: by gwj19 with SMTP id 19so4327610gwj.31 for ; Tue, 01 Jun 2010 18:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3jmnXvJUoxXKLy/Yh4lYjdC4c6Qajzhs2AFcj4ZBegw=; b=p2I2wZtZLI2jyHwGbydbwFsPHCw7wJ+rno882tApJSfskuAXkboh0RCVECemA7np6T 3HD82IdjRkgA0pO2AlFGZaGGt7Vy3iqyE7Mv40LtY1sDIjhSxHHEeCkOMNYbZNR1DgVx B/ciJ+SIAmrSLml9C00s5jsThgTBTRUNifEoA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JPHQCoq2ltW3T8fPgGEhIipO3qIHX1Ux3YM4Xkg5bKRi0OZnOoNHI3gDcuHnABxz99 kJqEzzBMB9QtZ8UE84zCiOVShMU3Azl4VoVkmZj7Y2Br0kIn4TUpf7Jpjyf1e/7EQzke /8z6Xdz14IINJOoAa+R9MAJVhJfoWLFtksJbs= MIME-Version: 1.0 Received: by 10.150.188.11 with SMTP id l11mr7011011ybf.197.1275442531179; Tue, 01 Jun 2010 18:35:31 -0700 (PDT) Received: by 10.150.95.5 with HTTP; Tue, 1 Jun 2010 18:35:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Jun 2010 18:35:31 -0700 Message-ID: Subject: Re: BFD alternate path? From: Vishwas Manral To: Glen Kent 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.9 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, 02 Jun 2010 01:35:52 -0000 Hi Glen, Yes your understanding is correct. Thanks, Vishwas On Tue, Jun 1, 2010 at 5:16 PM, Glen Kent wrote: > Hi Vishwas, > > I'll summarize my understanding. Please let me know if i am way off the m= ark. > > In case of BFD between directly connected nexthops (e.g. when running > over an IP interface for OSPF, static routes) then we need to ensure > that BFD packets dont follow the IP route and instead are *always* > only sent out on that interface. This will ensure that if this > interface goes down then we STOP sending BFD packets, as otherwise, > the BFD packets may take an alternate IP path. > > In case of multihop BFD sessions, BFD must follow the IP path, which > means that if the interface goes down, then BFD should take up an > alternate path if available to reach the other peer. > > Is this correct? > > Glen > > On Tue, Jun 1, 2010 at 8:54 AM, Vishwas Manral w= rote: >> Hi Glen, >> >> If I wanted to monitor if the peer was UP and not just an interface UP >> I could use that. >> >> One example I can give you is in LMP, we can have multiple control >> channels over individual interfaces for a control adjacency for a >> neighbor. So if the peer crashed I would want to bring down the >> control adjacency, but if an interface went down I would want to keep >> the control adjacency UP. >> >> One way could be have a different BFD session over each control >> channel. Another way is to have a control channel which is not bound >> to an interface. So in case there is another way the rerouting can >> happen even before BFD can trigger it (loss of carrier), we can use a >> single BFD session to the peer router. >> >> Hope that is of some help. >> >> Thanks, >> Vishwas >> >> On Mon, May 31, 2010 at 8:00 PM, Glen Kent wrote: >>> Hi Vishwas, >>> >>> Dont intend to be picky, but .. >>> >>>> >>>> In single hop cases the BFD session is generally bound to the >>>> interface. So the BFD session will brought down. >>> >>> You use "generally". Does it mean that there would be instances when >>> the BFD session for a directly connected nexthop will NOT be tied to >>> an interface. If so, when and under what circumstances would that >>> happen? >>> >>> Glen >>> >>>> >>>> Thanks, >>>> Vishwas >>>> >>>> On Mon, May 31, 2010 at 5:13 PM, Glen Kent wrote= : >>>>> Vishwas, >>>>> >>>>> This might work for a multihop session. How about directly connected >>>>> next-hops that i brought up in my previous email. >>>>> >>>>> A -- B >>>>> | =A0 =A0 =A0| >>>>> C ---+ >>>>> >>>>> In this case if link A-B fails, will BFD on A and B use the alternate >>>>> path via C (assume its the default gateway in for both A and B)? More >>>>> details in my previous email. >>>>> >>>>> Glen >>>>> >>>>> On Tue, Jun 1, 2010 at 4:58 AM, Vishwas Manral wrote: >>>>>> Hi Glen, >>>>>> >>>>>> If you want to monitor that a session goes over a particular link yo= u >>>>>> can impose the restriction to a Multihop session in which case the B= FD >>>>>> session will fail. >>>>>> >>>>>> If we do not impose the restriction the session will stay UP. I do n= ot >>>>>> see any sort of collision of interests. It depends on what an operat= or >>>>>> wants and can get the right behavior using BFD. >>>>>> >>>>>> Thanks, >>>>>> Vishwas >>>>>> >>>>>> On Mon, May 31, 2010 at 3:56 PM, Glen Kent wro= te: >>>>>>>> >>>>>>>> However in some cases (multihop sessions), the BFD session timers = will >>>>>>>> be set to higher value so that the lower level sessions can conver= ge >>>>>>> >>>>>>> In case of multihop sessions, say between two IBGP =A0peers, what i= s a >>>>>>> lower level session here? Is this the IGP? >>>>>>> >>>>>>> My doubt is this: >>>>>>> >>>>>>> A -- B >>>>>>> | =A0 =A0 =A0| >>>>>>> C ---+ >>>>>>> >>>>>>> A and B are directly connected. A can also reach B via C. I am runn= ing >>>>>>> a BFD session between A and B. Since A and B are directly connected= , >>>>>>> BFD packets will always use the A-B interface. However, if A-B fail= s, >>>>>>> then will BFD packets take the alternate path available via C to re= ach >>>>>>> the other end. I am not sure if this will happen as its a >>>>>>> chicken-and-egg problem - BFD can take the alternate path only if t= he >>>>>>> IGP recomputes the path. IGP can recompute only when it learns that >>>>>>> A-B has gone down, and its most probably only BFD that can inform t= he >>>>>>> IGP that A-B has gone down (assume for instance when there is a swi= tch >>>>>>> in between A and B and the switch goes down). >>>>>>> >>>>>>> Also, what will happen if there is a default route on both A and B = via >>>>>>> C. In that case BFD need not wait for the IGP to reconverge. It can >>>>>>> always take the alternate path. Will in such cases, BFD take the >>>>>>> alternate path and keep the session alive? If it does that then its >>>>>>> wrong as the physical link has indeed gone down. >>>>>>> >>>>>>> Glen >>>>>>> >>>>>>>> faster (which will result in the session staying up). If we do not >>>>>>>> want the behavior we can set the timers to smaller values. This >>>>>>>> however is a choice of the operator. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vishwas >>>>>>>> >>>>>>>> On Sun, May 30, 2010 at 9:12 PM, Glen Kent w= rote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Assume the link that i have between two BFD enabled routers A and= B >>>>>>>>> goes down. Will BFD, since its riding on top of UDP, automaticall= y >>>>>>>>> follow the routing table and try to find an alternate path to kee= p the >>>>>>>>> connectivity alive? >>>>>>>>> >>>>>>>>> If Yes, then this will result in BFD session remaining up, while = the >>>>>>>>> link is down. Is this acceptable? >>>>>>>>> >>>>>>>>> Glen >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From vishwas.ietf@gmail.com Tue Jun 1 22:00:31 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4573A68F8 for ; Tue, 1 Jun 2010 22:00:31 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBQTqcUw7CMi for ; Tue, 1 Jun 2010 22:00:30 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 1FAC33A6853 for ; Tue, 1 Jun 2010 22:00:30 -0700 (PDT) Received: by gyh4 with SMTP id 4so4444364gyh.31 for ; Tue, 01 Jun 2010 22:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=HqTLgoerrjCudqneynRqCEyYoOudrij0mWmb5AOPYZ4=; b=t7n3TkcIpW2NsDq2dtsarTxQ41l8Kde0PP9IeOvcG91Y6y8fqgyLaYSJt3swqmghUF kIhnlH60Zm0rIpxSjGbJBnzS4T1M3lVGI2H9aIBEqnX81CkHlPcEAB7NX6ClPbM0PXfj Ebbab/uEmAumuU+XCHo3oMWgQXadnSFZyuu6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bblOCjNrRweoJ+HZozbHr4+pEAPIYE/oi+XZmhsVAE+XNcJS2T0/U0IqzPKg1ArtQo UKTHoLIiVawnyVJcmMcI8fRrSKFUF4f/U+Fcath8/R7bQyBnS7DLqdI+xSSyloAZZkZ0 xD9qs+YPqSlYD7vKx87lfb1g0n/vwa12p3Ofk= MIME-Version: 1.0 Received: by 10.151.19.22 with SMTP id w22mr7423912ybi.349.1275454814999; Tue, 01 Jun 2010 22:00:14 -0700 (PDT) Received: by 10.150.95.5 with HTTP; Tue, 1 Jun 2010 22:00:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Jun 2010 22:00:14 -0700 Message-ID: Subject: Re: BFD on LAN From: Vishwas Manral To: Glen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jun 2010 05:00:31 -0000 Hi Glen, Reshad is right. We could have a FULL mesh, or if we wanted to only check particular reachability we could have BFD sessions between DROther and DR/ BDR. this however would be an optimization for OSPF and IS-IS. Thanks, Vishwas On Tue, Jun 1, 2010 at 5:20 PM, Glen Kent wrote: > Hi, > > Since BFD does not use a mcast address does it mean that it will form > a full mesh of unicast BFD sessions on a LAN? > > Glen > From pekkas@netcore.fi Tue Jun 1 22:35:32 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8259A3A6951 for ; Tue, 1 Jun 2010 22:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx+ygapwzCHK for ; Tue, 1 Jun 2010 22:35:27 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id DC6973A69CB for ; Tue, 1 Jun 2010 22:35:26 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id o525Yx4S028705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Jun 2010 08:34:59 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id o525YwrU028702 for ; Wed, 2 Jun 2010 08:34:58 +0300 Date: Wed, 2 Jun 2010 08:34:58 +0300 (EEST) From: Pekka Savola To: rtg-bfd@ietf.org Subject: Re: RFC 5880 on Bidirectional Forwarding Detection (BFD) In-Reply-To: <20100601193844.2A7C2E069E@rfc-editor.org> Message-ID: References: <20100601193844.2A7C2E069E@rfc-editor.org> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96 at otso.netcore.fi X-Virus-Status: Clean X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jun 2010 05:35:32 -0000 On Tue, 1 Jun 2010, rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > RFC 5880 > > Title: Bidirectional Forwarding Detection (BFD) > Author: D. Katz, D. Ward > Status: Standards Track > Stream: IETF > Date: June 2010 > Mailbox: dkatz@juniper.net, > dward@juniper.net > Pages: 49 > Characters: 110279 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-bfd-base-11.txt > > URL: http://www.rfc-editor.org/rfc/rfc5880.txt Congratulations. It has been a long road :-) I can't resist the temptation of quoting a message *) from DaveK Jan 2004: > The drafts state Category as Informational, but I think this > definitely should be Standards Track! If we can find a way to progress the work without it being bogged down forever, and without it becoming watered down by the legions of folks that would like to change it, I don't have any objection. My experience over the years does not give me a lot of hope. [...] And from AlexZ in Mar 2004 **): There has been some interest in having a more formal home for the BFD work, so we're creating a (hopefully) very focused and short-lived WG for it. Below is the proposed WG charter that Daves and I have crafted. Please read and comment. Time flies :-) * )http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg00010.html **) http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg00019.html From dkatz@juniper.net Wed Jun 2 11:00:04 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53C33A68B7 for ; Wed, 2 Jun 2010 11:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2wEH7gToGbJ for ; Wed, 2 Jun 2010 11:00:01 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id BB44D28B797 for ; Wed, 2 Jun 2010 11:00:00 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTAacEyMT6J1Y7whtb3Zql4rbepMfxh3o@postini.com; Wed, 02 Jun 2010 10:59:48 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Wed, 2 Jun 2010 10:57:20 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Jun 2010 10:57:20 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jun 2010 10:57:20 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Jun 2010 10:57:19 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o52HvJb14644; Wed, 2 Jun 2010 10:57:19 -0700 (PDT) (envelope-from dkatz@juniper.net) Subject: Re: BFD on LAN MIME-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset="us-ascii" From: Dave Katz In-Reply-To: Date: Wed, 2 Jun 2010 11:57:18 -0600 Content-Transfer-Encoding: quoted-printable Message-ID: <2C4DEEEA-8C13-425D-9D66-57C4B7BEE962@juniper.net> References: To: Glen Kent X-Mailer: Apple Mail (2.1078) X-OriginalArrivalTime: 02 Jun 2010 17:57:19.0665 (UTC) FILETIME=[0B762210:01CB027D] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jun 2010 18:00:04 -0000 Yes, this is on purpose. The biggest benefit is that the intervals are = negotiated pairwise, so faster systems are not held hostage to slower = systems. It's also the case that the use of multicast in control protocols is = usually overrated (unicast replies are typically necessary, so the = reduction in traffic is often uninteresting, and the complexity required = to make multicast work becomes ugly--EIGRP is one of the worst offenders = along these lines.) IS-IS is the only protocol I've seen that leverages = multicast well. There are protocols that use multicast for discovery but do the bulk of = their work over unicast (e.g., LDP). BFD effectively uses this model = when supporting IGPs, by letting the IGP take care of discovery. --Dave On Jun 1, 2010, at 6:20 PM, Glen Kent wrote: > Hi, >=20 > Since BFD does not use a mcast address does it mean that it will form > a full mesh of unicast BFD sessions on a LAN? >=20 > Glen >=20 From dkatz@juniper.net Wed Jun 2 11:01:21 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E378328C0E9 for ; Wed, 2 Jun 2010 11:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VipWdHNkQcRu for ; Wed, 2 Jun 2010 11:01:21 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id BF64A3A6972 for ; Wed, 2 Jun 2010 11:01:17 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTAacYJZw4wKSKad7rbtg8MkUM0VwOSss@postini.com; Wed, 02 Jun 2010 11:01:08 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Wed, 2 Jun 2010 10:59:00 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Jun 2010 10:59:00 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jun 2010 10:58:59 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Jun 2010 10:58:59 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o52Hwwb14673; Wed, 2 Jun 2010 10:58:58 -0700 (PDT) (envelope-from dkatz@juniper.net) Subject: Re: RFC 5880 on Bidirectional Forwarding Detection (BFD) MIME-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset="us-ascii" From: Dave Katz In-Reply-To: Date: Wed, 2 Jun 2010 11:58:57 -0600 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20100601193844.2A7C2E069E@rfc-editor.org> To: Pekka Savola X-Mailer: Apple Mail (2.1078) X-OriginalArrivalTime: 02 Jun 2010 17:58:59.0242 (UTC) FILETIME=[46D060A0:01CB027D] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jun 2010 18:01:22 -0000 You *did* have to bring that up. ;-) On the other hand, it's been deployed for nearly as long, so at least = part of the intent was achieved... Thanks to you and everyone else for your help... --Dave On Jun 1, 2010, at 11:34 PM, Pekka Savola wrote: > On Tue, 1 Jun 2010, rfc-editor@rfc-editor.org wrote: >> A new Request for Comments is now available in online RFC libraries. >> RFC 5880 >>=20 >> Title: Bidirectional Forwarding Detection (BFD) >> Author: D. Katz, D. Ward >> Status: Standards Track >> Stream: IETF >> Date: June 2010 >> Mailbox: dkatz@juniper.net, >> dward@juniper.net >> Pages: 49 >> Characters: 110279 >> Updates/Obsoletes/SeeAlso: None >>=20 >> I-D Tag: draft-ietf-bfd-base-11.txt >>=20 >> URL: http://www.rfc-editor.org/rfc/rfc5880.txt >=20 >=20 > Congratulations. It has been a long road :-) >=20 > I can't resist the temptation of quoting a message *) from DaveK Jan = 2004: >=20 >> The drafts state Category as Informational, but I think this >> definitely should be Standards Track! >=20 > If we can find a way to progress the work without it being bogged down = forever, and without it becoming watered down by the legions of folks = that would like to change it, I don't have any objection. My experience = over the years does not give me a lot of hope. [...] >=20 > And from AlexZ in Mar 2004 **): >=20 > There has been some interest in having a more formal home for the BFD > work, so we're creating a (hopefully) very focused and short-lived WG > for it. Below is the proposed WG charter that Daves and I have > crafted. Please read and comment. >=20 > Time flies :-) >=20 > * )http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg00010.html > **) http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg00019.html >=20 From Adrian.Farrel@huawei.com Wed Jun 2 16:28:07 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798EF3A6A51 for ; Wed, 2 Jun 2010 16:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.418 X-Spam-Level: X-Spam-Status: No, score=-0.418 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_20=-0.74, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ef8IrLI730A for ; Wed, 2 Jun 2010 16:28:05 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 49B153A6926 for ; Wed, 2 Jun 2010 16:28:05 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3E00HUXUIG61@usaga01-in.huawei.com> for rtg-bfd@ietf.org; Wed, 02 Jun 2010 16:27:52 -0700 (PDT) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3E00JRDUICLX@usaga01-in.huawei.com> for rtg-bfd@ietf.org; Wed, 02 Jun 2010 16:27:52 -0700 (PDT) Date: Wed, 02 Jun 2010 18:32:45 +0100 From: Adrian Farrel Subject: Re: RFC 5880 on Bidirectional Forwarding Detection (BFD) To: Pekka Savola Message-id: <3F3D535E8E324F65A9D175A679F6393F@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20100601193844.2A7C2E069E@rfc-editor.org> Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 23:28:07 -0000 Pekka Savola sed... > Congratulations. It has been a long road :-) [SNIP] > Time flies :-) Yes, indeed. Like a banana! Well done WG. Adrian From jhaas@slice.pfrc.org Wed Jun 2 20:47:06 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D925E3A6835 for ; Wed, 2 Jun 2010 20:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+nHealJobPi for ; Wed, 2 Jun 2010 20:47:05 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 489B13A6920 for ; Wed, 2 Jun 2010 20:47:05 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9ACE622433C; Thu, 3 Jun 2010 03:46:52 +0000 (UTC) Date: Thu, 3 Jun 2010 03:46:52 +0000 From: Jeffrey Haas To: Pekka Savola Subject: Re: RFC 5880 on Bidirectional Forwarding Detection (BFD) Message-ID: <20100603034652.GA12558@slice> References: <20100601193844.2A7C2E069E@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jun 2010 03:47:07 -0000 On Wed, Jun 02, 2010 at 08:34:58AM +0300, Pekka Savola wrote: > Congratulations. It has been a long road :-) It has indeed. > And from AlexZ in Mar 2004 **): > > There has been some interest in having a more formal home for the BFD > work, so we're creating a (hopefully) very focused and short-lived WG > for it. Below is the proposed WG charter that Daves and I have > crafted. Please read and comment. The group has been nicely focused and certainly not as brief as Alex had suggested when the ADs asked if I'd pick up the co-chair job. We got the job done in fewer drafts than the last BGP spec rev even though sometimes I didn't think we would. Congratulations and thanks to all who have helped us turn out good standards. -- Jeff From mukund.mani@gmail.com Thu Jun 3 00:40:29 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F7673A67EB for ; Thu, 3 Jun 2010 00:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.029 X-Spam-Level: X-Spam-Status: No, score=-0.029 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bp94lqHM8DdV for ; Thu, 3 Jun 2010 00:40:28 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 1C8E13A67E7 for ; Thu, 3 Jun 2010 00:40:28 -0700 (PDT) Received: by vws11 with SMTP id 11so3819330vws.31 for ; Thu, 03 Jun 2010 00:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=Do8GREShBravpIpBDAdYQ2XmxVhR5dkJMNilkPRdPKI=; b=DUihvJfXOAl0GKZpUVskiT7EyK34gPv8RVpQp5DRKQOYs6OlI5OAu3toodCsw5R4WK VoYRigigUoMUci7BaXL79I3bu4hRD2yABSwiaUFFmOuhhicWOGNv2CcsXf1NEGcSDyyq 3rEwKDyK3tOILKcliFvOun+oraWNLtscIMjzc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=X64K8qYUTaW7ulQpUGTPYhzKuf5UCJe+kocbM/ssN2T+cAYEndJmZA5kM+0Y2DICiK Gv9/m1CzgpoHyYX4/VZu9uCt9VqcFTT2wjEuHijSWHUu7OqTgyamPDWq0Plx60qESJlo cP/r/YDmHRZoP1mKFU+XAvVeujlODLmwmudRM= MIME-Version: 1.0 Received: by 10.229.236.65 with SMTP id kj1mr1802767qcb.37.1275550812295; Thu, 03 Jun 2010 00:40:12 -0700 (PDT) Received: by 10.229.73.206 with HTTP; Thu, 3 Jun 2010 00:40:12 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Jun 2010 13:10:12 +0530 Message-ID: Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01 From: Mukund Mani To: mach@huawei.com, rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=0016e64ddace0f517f04881b5175 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jun 2010 07:40:29 -0000 --0016e64ddace0f517f04881b5175 Content-Type: text/plain; charset=ISO-8859-1 Hi Mach Maybe "BFD session set-up in progress" ?? Also you mention: "The case you described *maybe* occur" As for me this will *always* occur if I configure both the ends in Active mode, because enabling BFD would initiate the LSP Ping for BFD bootstrap. Am I correct on this? On the whole I have had another question for quite some time which I have been asking in the MPLS-TP group also. My question was w.r.t the draft-asm-mpls-tp-bfd-cc-cv-04 which defines CC/CV and RDI mechanism using BFD and relates the number of sessions to protection switching architectures. But I would like to co-relate the details here to have a clear understanding on the BFD operation itself... For co-routed bi-directional LSP the forward and reverse path will be associated at the LER's. Also the same relationship exists for forward and reverse path of associated bi-directional LSP's in the LER's and the common LSR's. So why cant I use this inherent relationship to decide whether to have a single or two BFD sessions for a bidirectional LSP? Basically trying to figure out the need for the explicit mechanism using Return Path TLV and Session Control TLV mentioned in the draft "draft-chen-mpls-bfd-enhancement-01". I agree that for a pair of Uni-directional LSP's, using Return Path and Session Control TLV might be useful but why do we need this for associated and co-routed LSP? With Regards Mukund On Tue, Jun 1, 2010 at 3:03 PM, Mach Chen wrote: > Hi Mukund, > > Sorry for the delay response! > > The case you described maybe occur, and strictly speaking, it is not very > accurate to mention that the "Backward direction BFD session exists" as > return code, how about "BFD session collision"? or do you have any other > suggestions? > > Best regards, > Mach > -------------------------------------------------- > From: "Mukund Mani" > Sent: Monday, May 31, 2010 3:04 AM > To: > Subject: Query on draft-chen-mpls-bfd-enhancement-01 > > > Hi >> >> Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could the draft >> authors kindly clarify the same: >> >> Section 4 on session establishment mentions the following: >> >> If node with the larger IP receives LSP ping >> message signaling BFD session with Session Control TLV, LSP ping >> reply must be transmitted with "Backward direction BFD session >> exists" to the ingress LSR. >> >> >> >> In the case of BFD session provisioned on both nodes in the Active >> mode, the LSP Ping for the backward direction BFD session could be >> received even when the forward direction session is not yet >> established. In that case is it correct to mention that the "Backward >> direction BFD session exists" as return code? >> >> >> Kindly let me know if I am missing something here... >> >> >> With Regards >> >> Mukund >> >> --0016e64ddace0f517f04881b5175 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Mach
=A0
Maybe "BFD session set-up in progress" ??=A0
=A0
Also you mention: =A0"The case you described maybe occur"
As for me this will=A0always occur if=A0I configure b= oth the ends in Active mode, because enabling BFD would initiate the LSP Pi= ng for BFD bootstrap. Am=A0I correct on this?
=A0
On the whole I have had another question for quite some time which I h= ave been asking in the MPLS-TP group also.
My question was w.r.t the draft-asm-mpls-tp-bfd-cc-cv-04 which defines= CC/CV and RDI mechanism using BFD and relates the number of sessions to pr= otection switching=A0architectures. But I would like to co-relate the detai= ls=A0here to have a clear understanding on the BFD operation itself...
=A0
For co-routed bi-directional LSP the forward and reverse path will be = associated at the LER's. Also the same relationship exists for forward = and reverse path of associated bi-directional LSP's in the LER's an= d the common LSR's.
=A0
So why cant I use this inherent relationship to decide whether to have= a single or two BFD sessions for a bidirectional LSP?
Basically trying to figure out the need for the explicit mechanism usi= ng=A0Return Path TLV and Session Control TLV mentioned in=A0the draft "= ;draft-chen-mpls-bfd-enhancement-01".
I agree that for a pair of Uni-directional LSP's, using Return Pat= h and Session Control TLV might be useful but why do we need this for assoc= iated and co-routed LSP?
=A0
With Regards
Mukund

On Tue, Jun 1, 2010 at 3:03 PM, Mach Chen <mach@h= uawei.com> wrote:
Hi Mukund,

Sorry for the = delay response!

The case you described maybe occur, and strictly spe= aking, it is not very accurate to mention that the "Backward direction= BFD session exists" as return code, how about "BFD session colli= sion"? or do you have any other suggestions?

Best regards,
Mach
----------------------------------------------= ----
From: "Mukund Mani" <mukund.mani@gmail.com>
Sent: Monday, Ma= y 31, 2010 3:04 AM
To: <rtg-bfd@ietf.= org>
Subject: Query on draft-chen-mpls-bfd-enhancement-01=20


Hi

Have a query w.r.t &qu= ot;draft-chen-mpls-bfd-enhancement-01". Could the draft
authors kin= dly clarify the same:

Section 4 on session establishment mentions the following:

If no= de with the larger IP receives LSP ping
message signaling BFD session wi= th Session Control TLV, LSP ping
reply must be transmitted with "Ba= ckward direction BFD session
exists" to the ingress LSR.



In the case of BFD session = provisioned on both nodes in the Active
mode, the LSP Ping for the backw= ard direction BFD session could be
received even when the forward direct= ion session is not yet
established. In that case is it correct to mention that the "Backward<= br>direction BFD session exists" as return code?


Kindly let= me know if I am missing something here...


With Regards

Mukund


--0016e64ddace0f517f04881b5175-- From mach@huawei.com Thu Jun 3 02:49:26 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 898863A6944; Thu, 3 Jun 2010 02:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJSQDoSP1iEg; Thu, 3 Jun 2010 02:49:25 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id A173E3A684B; Thu, 3 Jun 2010 02:49:24 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3F00L92N9YIG@szxga02-in.huawei.com>; Thu, 03 Jun 2010 17:49:10 +0800 (CST) Received: from m55527c ([10.110.98.169]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3F00GTZN9XNN@szxga02-in.huawei.com>; Thu, 03 Jun 2010 17:49:10 +0800 (CST) Date: Thu, 03 Jun 2010 17:49:09 +0800 From: Mach Chen Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01 In-reply-to: To: Mukund Mani , rtg-bfd@ietf.org Message-id: <2303DFD3C2884F2DB7C194CA0C60367D@m55527c> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: Cc: mpls-tp@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jun 2010 09:49:26 -0000 Hi Mukund, Please see inline... -------------------------------------------------- From: "Mukund Mani" Sent: Thursday, June 03, 2010 3:40 PM To: ; Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01 > Hi Mach > > Maybe "BFD session set-up in progress" ?? Sounds better! > > Also you mention: "The case you described *maybe* occur" > As for me this will *always* occur if I configure both the ends in Active > mode, because enabling BFD would initiate the LSP Ping for BFD bootstrap. > Am I correct on this? A node (with smart implementation) with lower IP address should not initiate the LSP Ping for BFD bootstrap for the LSP(s) if it has already received an LSP Ping. So it depends on which end will firstly initiate the LSP Ping. > > On the whole I have had another question for quite some time which I have > been asking in the MPLS-TP group also. > My question was w.r.t the draft-asm-mpls-tp-bfd-cc-cv-04 which defines > CC/CV > and RDI mechanism using BFD and relates the number of sessions to > protection > switching architectures. But I would like to co-relate the details here to > have a clear understanding on the BFD operation itself... I totally agree with you on this. Although protection switching is normally based on BFD detection results, but, IMHO, the number of BFD sessions should not closely coupled with the protection switching types(e.g., 1:1,1+1...). > > For co-routed bi-directional LSP the forward and reverse path will be > associated at the LER's. Also the same relationship exists for forward and > reverse path of associated bi-directional LSP's in the LER's and the > common > LSR's. My understanding of co-routed bi-directional LSP is that it "associated" at all nodes(including LERs and LSRs) along the LSP. > > So why cant I use this inherent relationship to decide whether to have a > single or two BFD sessions for a bidirectional LSP? I am not sure what's your meaning about the inherent relationship. Do you suggest: one BFD session for co-routed bi-dir LSP and two BFD sessions for associated bi-dir LSP, or just one BFD session for bi-dir LSP (no matter what co-routed or associated)? For co-routed and associated bidirectional LSP, IMHO, they should be treated as the same construct. From the view of their clients, there is no difference between the co-routed and associated bidirection LSP. Why there requires associated bidirectional LSP, that is becase there is no co-routed bidirectional LSP(e.g., the devices do support yet) and bidirectional LSPs are desired. Now that we have associated two unidirectional LSPs into one associated bidirectional LSP, it is logically to treat it as a real bidirectional LSP. That means, there should be no difference in protection switching between co-routed and associated bidrectional LSP. > Basically trying to figure out the need for the explicit mechanism > using Return Path TLV and Session Control TLV mentioned in the draft > "draft-chen-mpls-bfd-enhancement-01". > I agree that for a pair of Uni-directional LSP's, using Return Path and > Session Control TLV might be useful but why do we need this for associated > and co-routed LSP? It depends on how you want each direction of a bidirectional LSP to be operated (independent or coordinated). If you want each direction of the bidirectional LSP to be protected and switched independently, there should be separate BFD session for each direction, or only one BFD session is needed. In our draft, if the LSP is bidirectional(co-routed or associated), there is no need to carry the Return Path TLV, only Session Control TLV is required, which is used to control how many BFD sessions should be setup over the LSP. IMHO, if we want the LSP could be operated either as independent or coodinated, a BFD session control mechanism(using Session Control TLV or other means(e.g., in MPLS-TP scenario, using a bit of GACh flag field)) is needed. Best regards, Mach > > With Regards > Mukund > > On Tue, Jun 1, 2010 at 3:03 PM, Mach Chen wrote: > >> Hi Mukund, >> >> Sorry for the delay response! >> >> The case you described maybe occur, and strictly speaking, it is not very >> accurate to mention that the "Backward direction BFD session exists" as >> return code, how about "BFD session collision"? or do you have any other >> suggestions? >> >> Best regards, >> Mach >> -------------------------------------------------- >> From: "Mukund Mani" >> Sent: Monday, May 31, 2010 3:04 AM >> To: >> Subject: Query on draft-chen-mpls-bfd-enhancement-01 >> >> >> Hi >>> >>> Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could the draft >>> authors kindly clarify the same: >>> >>> Section 4 on session establishment mentions the following: >>> >>> If node with the larger IP receives LSP ping >>> message signaling BFD session with Session Control TLV, LSP ping >>> reply must be transmitted with "Backward direction BFD session >>> exists" to the ingress LSR. >>> >>> >>> >>> In the case of BFD session provisioned on both nodes in the Active >>> mode, the LSP Ping for the backward direction BFD session could be >>> received even when the forward direction session is not yet >>> established. In that case is it correct to mention that the "Backward >>> direction BFD session exists" as return code? >>> >>> >>> Kindly let me know if I am missing something here... >>> >>> >>> With Regards >>> >>> Mukund >>> >>> > From gregimirsky@gmail.com Thu Jun 3 10:47:37 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2773728C162; Thu, 3 Jun 2010 10:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.858 X-Spam-Level: X-Spam-Status: No, score=-0.858 tagged_above=-999 required=5 tests=[AWL=-0.860, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQuhr0aIjS0S; Thu, 3 Jun 2010 10:47:21 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 1B03F28C0D7; Thu, 3 Jun 2010 10:47:18 -0700 (PDT) Received: by vws11 with SMTP id 11so409549vws.31 for ; Thu, 03 Jun 2010 10:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=9Rh6aMdS/I7OLtizfkeAKYCjgAVbnrrItjBGusI9ywM=; b=AtCyAxKzNIxtVxslesVHeFSclpcSndvWCMjUc0YlyeO3fEkoLUidd3wUW50xvvJ8Ab lk6SkRKTL64j+98j4nHWuSiGFDgn0bZin0qkqaid1Kk5T1HZMi6ufblbnj0+zA+chpQx PQ9PUsvgjYxuIt5AcuiBprcoriOwB/dsZ0/VE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EMvf+UB2iqXknEfhTxvRAyOdnP+8+sOTlBjF/iKkGC1qQUyIO3KcSiajQuoMavf7AN Qn76UOEQKQfJAkKaLkkMbWQuuB+7d7tIoSC+FALHpZocrR6K7QtkBlPIw8wg0zeuLydJ BMZjfu1J52dQc6ociUgg+shVYYzlaW4WLQmAY= MIME-Version: 1.0 Received: by 10.220.107.158 with SMTP id b30mr7050423vcp.105.1275587220137; Thu, 03 Jun 2010 10:47:00 -0700 (PDT) Received: by 10.220.171.147 with HTTP; Thu, 3 Jun 2010 10:47:00 -0700 (PDT) In-Reply-To: <2303DFD3C2884F2DB7C194CA0C60367D@m55527c> References: <2303DFD3C2884F2DB7C194CA0C60367D@m55527c> Date: Thu, 3 Jun 2010 10:47:00 -0700 Message-ID: Subject: Re: [mpls-tp] Query on draft-chen-mpls-bfd-enhancement-01 From: Greg Mirsky To: Mach Chen Content-Type: multipart/alternative; boundary=00c09f8e5c5122e919048823cbce Cc: Mukund Mani , rtg-bfd@ietf.org, ccamp@ietf.org, mpls-tp@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jun 2010 17:47:37 -0000 --00c09f8e5c5122e919048823cbce Content-Type: text/plain; charset=ISO-8859-1 Dear Mach, I very much agree with your view that "It depends on how you want each direction of a bidirectional LSP to be operated [GIM>> perhaps "protected" is closer] (independent or coordinated). If you want each direction of the bidirectional LSP to be protected and switched independently, there should be separate BFD session for each direction, or only one BFD session is needed." But I'd differ that associated and co-routed bidirectional LSP should be viewed as the same construct. They certainly may be viewed this way but I wouldn't see that as "should". If, for example, associated bidirectional LSP has assymetric BW for each direction, it would might be reasonable to have two independent BFD sessions and protect each direction independently. At the same time, bidirectional linear LSP will always be co-routed and using independent BFD session for each direction and independent protection doesn't seem practical. And I agree that BFD control mechanism is needed. I think it can be part of overall OAM control mechanism that is being worked on by CCAMP WG (I've added the CCAMP to the discussion). Best regards, Greg On Thu, Jun 3, 2010 at 2:49 AM, Mach Chen wrote: > Hi Mukund, > > Please see inline... > > > -------------------------------------------------- > From: "Mukund Mani" > Sent: Thursday, June 03, 2010 3:40 PM > To: ; > Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01 > > > Hi Mach >> >> Maybe "BFD session set-up in progress" ?? >> > > Sounds better! > > > >> Also you mention: "The case you described *maybe* occur" >> As for me this will *always* occur if I configure both the ends in Active >> mode, because enabling BFD would initiate the LSP Ping for BFD bootstrap. >> Am I correct on this? >> > > A node (with smart implementation) with lower IP address should not > initiate the LSP Ping for BFD bootstrap for the LSP(s) if it has already > received an LSP Ping. So it depends on which end will firstly initiate the > LSP Ping. > > > >> On the whole I have had another question for quite some time which I have >> been asking in the MPLS-TP group also. >> My question was w.r.t the draft-asm-mpls-tp-bfd-cc-cv-04 which defines >> CC/CV >> and RDI mechanism using BFD and relates the number of sessions to >> protection >> switching architectures. But I would like to co-relate the details here to >> have a clear understanding on the BFD operation itself... >> > I totally agree with you on this. Although protection switching is normally > based on BFD detection results, but, IMHO, the number of BFD sessions should > not closely coupled with the protection switching types(e.g., 1:1,1+1...). > > > >> For co-routed bi-directional LSP the forward and reverse path will be >> associated at the LER's. Also the same relationship exists for forward and >> reverse path of associated bi-directional LSP's in the LER's and the >> common >> LSR's. >> > My understanding of co-routed bi-directional LSP is that it "associated" at > all nodes(including LERs and LSRs) along the LSP. > > > >> So why cant I use this inherent relationship to decide whether to have a >> single or two BFD sessions for a bidirectional LSP? >> > I am not sure what's your meaning about the inherent relationship. Do you > suggest: one BFD session for co-routed bi-dir LSP and two BFD sessions for > associated bi-dir LSP, or just one BFD session for bi-dir LSP (no matter > what co-routed or associated)? > > For co-routed and associated bidirectional LSP, IMHO, they should be > treated as the same construct. From the view of their clients, there is no > difference between the co-routed and associated bidirection LSP. Why there > requires associated bidirectional LSP, that is becase there is no co-routed > bidirectional LSP(e.g., the devices do support yet) and bidirectional LSPs > are desired. Now that we have associated two unidirectional LSPs into one > associated bidirectional LSP, it is logically to treat it as a real > bidirectional LSP. That means, there should be no difference in protection > switching between co-routed and associated bidrectional LSP. > > > Basically trying to figure out the need for the explicit mechanism >> using Return Path TLV and Session Control TLV mentioned in the draft >> "draft-chen-mpls-bfd-enhancement-01". >> I agree that for a pair of Uni-directional LSP's, using Return Path and >> Session Control TLV might be useful but why do we need this for associated >> and co-routed LSP? >> > > It depends on how you want each direction of a bidirectional LSP to be > operated (independent or coordinated). If you want each direction of the > bidirectional LSP to be protected and switched independently, there should > be separate BFD session for each direction, or only one BFD session is > needed. > > In our draft, if the LSP is bidirectional(co-routed or associated), there > is no need to carry the Return Path TLV, only Session Control TLV is > required, which is used to control how many BFD sessions should be setup > over the LSP. IMHO, if we want the LSP could be operated either as > independent or coodinated, a BFD session control mechanism(using Session > Control TLV or other means(e.g., in MPLS-TP scenario, using a bit of GACh > flag field)) is needed. > > Best regards, > Mach > > > >> With Regards >> Mukund >> >> On Tue, Jun 1, 2010 at 3:03 PM, Mach Chen wrote: >> >> Hi Mukund, >>> >>> Sorry for the delay response! >>> >>> The case you described maybe occur, and strictly speaking, it is not very >>> accurate to mention that the "Backward direction BFD session exists" as >>> return code, how about "BFD session collision"? or do you have any other >>> suggestions? >>> >>> Best regards, >>> Mach >>> -------------------------------------------------- >>> From: "Mukund Mani" >>> Sent: Monday, May 31, 2010 3:04 AM >>> To: >>> Subject: Query on draft-chen-mpls-bfd-enhancement-01 >>> >>> >>> Hi >>> >>>> >>>> Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could the draft >>>> authors kindly clarify the same: >>>> >>>> Section 4 on session establishment mentions the following: >>>> >>>> If node with the larger IP receives LSP ping >>>> message signaling BFD session with Session Control TLV, LSP ping >>>> reply must be transmitted with "Backward direction BFD session >>>> exists" to the ingress LSR. >>>> >>>> >>>> >>>> In the case of BFD session provisioned on both nodes in the Active >>>> mode, the LSP Ping for the backward direction BFD session could be >>>> received even when the forward direction session is not yet >>>> established. In that case is it correct to mention that the "Backward >>>> direction BFD session exists" as return code? >>>> >>>> >>>> Kindly let me know if I am missing something here... >>>> >>>> >>>> With Regards >>>> >>>> Mukund >>>> >>>> >>>> >> _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > --00c09f8e5c5122e919048823cbce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Mach,
I very much agree with your view that "It depends on how= you want each direction of a bidirectional LSP to be=20 operated [GIM>> perhaps "= protected" is closer] (independent or coordinated). If you want= each direction of the bidirectional LSP to be protected and switched independently, there=20 should be separate BFD session for each direction, or only one BFD=20 session is needed."
But I'd differ that associated and co-route= d bidirectional LSP should be viewed as the same construct. They certainly = may be viewed this way but I wouldn't see that as "should". I= f, for example, associated bidirectional LSP has assymetric BW for each dir= ection, it would might be reasonable to have two independent BFD sessions a= nd protect each direction independently. At the same time, bidirectional li= near LSP will always be co-routed and using independent BFD session for eac= h direction and independent protection doesn't seem practical.
And I agree that BFD control mechanism is needed. I think it can be part of= overall OAM control mechanism that is being worked on by CCAMP WG (I'v= e added the CCAMP to the discussion).

Best regards,
Greg

On Thu, Jun 3, 2010 at 2:49 AM, Mach Chen <mach@huawei.com&= gt; wrote:
Hi Mukund,

Please see inline...


--------------------------------------------------
From: "Mukund Mani" <mukund.mani@gmail.com>
Sent: Thursday, June 03, 2010 3:40 PM
To: <mach@huawei.co= m>; <rtg-bf= d@ietf.org>
Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01
<= br>
Hi Mach

Maybe "BFD session set-up in progress" ??

Sounds better!



Also you mention: =A0"The case you described *maybe* occur"
As for me this will *always* occur if I configure both the ends in Active mode, because enabling BFD would initiate the LSP Ping for BFD bootstrap. Am I correct on this?

A node (with smart implementation) with lower IP address should not initiat= e the LSP Ping for BFD bootstrap for the LSP(s) if it has already received = an LSP Ping. So it depends on which end will firstly initiate the LSP Ping.=



On the whole I have had another question for quite some time which I have been asking in the MPLS-TP group also.
My question was w.r.t the draft-asm-mpls-tp-bfd-cc-cv-04 which defines CC/C= V
and RDI mechanism using BFD and relates the number of sessions to protectio= n
switching architectures. But I would like to co-relate the details here to<= br> have a clear understanding on the BFD operation itself...
I totally agree with you on this. Although protection switching is normally= based on BFD detection results, but, IMHO, the number of BFD sessions shou= ld not closely coupled with the protection switching types(e.g., 1:1,1+1...= ).



For co-routed bi-directional LSP the forward and reverse path will be
associated at the LER's. Also the same relationship exists for forward = and
reverse path of associated bi-directional LSP's in the LER's and th= e common
LSR's.
My understanding of co-routed bi-directional LSP is that it "associate= d" at all nodes(including LERs and LSRs) along the LSP.



So why cant I use this inherent relationship to decide whether to have a single or two BFD sessions for a bidirectional LSP?
I am not sure what's your meaning about the inherent relationship. Do y= ou suggest: one BFD session for co-routed bi-dir LSP and two BFD sessions f= or associated bi-dir LSP, or just one BFD session for bi-dir LSP (no matter= what co-routed or associated)?

For co-routed and associated bidirectional LSP, IMHO, they should be treate= d as the same construct. From the view of their clients, there is no differ= ence between the co-routed and associated bidirection LSP. Why there requir= es associated bidirectional LSP, that is becase there is no co-routed bidir= ectional LSP(e.g., the devices do support yet) and bidirectional LSPs are d= esired. Now that we have associated two unidirectional LSPs into one associ= ated bidirectional LSP, it is logically to treat it as a real bidirectional= LSP. That means, there should be no difference in protection switching bet= ween co-routed and associated bidrectional LSP.


Basically trying to figure out the need for the explicit mechanism
using Return Path TLV and Session Control TLV mentioned in the draft
"draft-chen-mpls-bfd-enhancement-01".
I agree that for a pair of Uni-directional LSP's, using Return Path and=
Session Control TLV might be useful but why do we need this for associated<= br> and co-routed LSP?

It depends on how you want each direction of a bidirectional LSP to be oper= ated (independent or coordinated). If you want each direction of the bidire= ctional LSP to be protected and switched independently, there should be sep= arate BFD session for each direction, or only one BFD session is needed.
In our draft, if the LSP is bidirectional(co-routed or associated), there i= s no need to carry the Return Path TLV, only Session Control TLV is require= d, which is used to control how many BFD sessions should be setup over the = LSP. IMHO, if we want the LSP could be operated either as independent or co= odinated, a BFD session control mechanism(using Session Control TLV or othe= r means(e.g., in MPLS-TP scenario, using a bit of GACh flag field)) is need= ed.

Best regards,
Mach



With Regards
Mukund

On Tue, Jun 1, 2010 at 3:03 PM, Mach Chen <mach@huawei.com> wrote:

Hi Mukund,

Sorry for the delay response!

The case you described maybe occur, and strictly speaking, it is not very accurate to mention that the "Backward direction BFD session exists&qu= ot; as
return code, how about "BFD session collision"? or do you have an= y other
suggestions?

Best regards,
Mach
--------------------------------------------------
From: "Mukund Mani" <mukund.mani@gmail.com>
Sent: Monday, May 31, 2010 3:04 AM
To: <rtg-bfd@ietf.= org>
Subject: Query on draft-chen-mpls-bfd-enhancement-01


Hi

Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could th= e draft
authors kindly clarify the same:

Section 4 on session establishment mentions the following:

If node with the larger IP receives LSP ping
message signaling BFD session with Session Control TLV, LSP ping
reply must be transmitted with "Backward direction BFD session
exists" to the ingress LSR.



In the case of BFD session provisioned on both nodes in the Active
mode, the LSP Ping for the backward direction BFD session could be
received even when the forward direction session is not yet
established. In that case is it correct to mention that the "Backward<= br> direction BFD session exists" as return code?


Kindly let me know if I am missing something here...


With Regards

Mukund



_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/mpls-tp

--00c09f8e5c5122e919048823cbce-- From mukund.mani@gmail.com Thu Jun 3 12:06:17 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE6F3A6890; Thu, 3 Jun 2010 12:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNJ3VPINSRCF; Thu, 3 Jun 2010 12:06:16 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 91F773A6359; Thu, 3 Jun 2010 12:06:15 -0700 (PDT) Received: by gyh4 with SMTP id 4so355143gyh.31 for ; Thu, 03 Jun 2010 12:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=1i0Ag8WpKmGhmzYeTjdwx3+/1/kPFeT3hRbc8R4a7uE=; b=IWeLYvfDkC3tFYsOUfZhOmIrXx+20+GkHTHV8qmaJ/aplVREH703TDHOMXjRmNP4bN 88feeLhCoMy18bObVPUtPNm5IVbExaxwx8qbqfN4pW89o3A3NVLLxr34Kkw6eLJqxYvh G6FV6YfUoTewrFgU30m5Y0sxk7NCIzLdjYvm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jKnOOdzsNM/FQLCAP8kfNfYYRH/MuZJEwm0AQS/8PgS0fOkkcVmBGFz9Z/8j7AMerx otPoi0Q+aEmAeFa6iaeGWIyrKnn8IS59i56QRo9T2wWuJgWFgLM3v3fSWD/KkAqBezQz OoWzRrhsjJnj6+vgmLQemZOAPORyE1L90x44c= MIME-Version: 1.0 Received: by 10.224.87.75 with SMTP id v11mr5098677qal.397.1275591957376; Thu, 03 Jun 2010 12:05:57 -0700 (PDT) Received: by 10.229.73.206 with HTTP; Thu, 3 Jun 2010 12:05:57 -0700 (PDT) In-Reply-To: References: <2303DFD3C2884F2DB7C194CA0C60367D@m55527c> Date: Fri, 4 Jun 2010 00:35:57 +0530 Message-ID: Subject: Re: [mpls-tp] Query on draft-chen-mpls-bfd-enhancement-01 From: Mukund Mani To: Greg Mirsky , mach@huawei.com Content-Type: multipart/alternative; boundary=00c09f89980e8196f5048824e5a4 Cc: rtg-bfd@ietf.org, ccamp@ietf.org, mpls-tp@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jun 2010 19:06:18 -0000 --00c09f89980e8196f5048824e5a4 Content-Type: text/plain; charset=ISO-8859-1 Hi Mach Thanks for the response.. So in that case the BFD session initiator shall include the Session Control TLV in the Echo Request only when the bidirectional LSP is to be protected in a co-ordinated fashion. You also mention in the draft that "If there is no Session Control TLV carried in the echo request, it's up to the egress LSR to decide whether to initiate another BFD session for the backward direction LSP" Does this imply that when a Session Control TLV is not included by the peer, it can still end up in one BFD session?? (based on the egress LSR's decision) With Regards Mukund On Thu, Jun 3, 2010 at 11:17 PM, Greg Mirsky wrote: > Dear Mach, > I very much agree with your view that "It depends on how you want each > direction of a bidirectional LSP to be operated [GIM>> perhaps "protected" > is closer] (independent or coordinated). If you want each direction of the > bidirectional LSP to be protected and switched independently, there should > be separate BFD session for each direction, or only one BFD session is > needed." > But I'd differ that associated and co-routed bidirectional LSP should be > viewed as the same construct. They certainly may be viewed this way but I > wouldn't see that as "should". If, for example, associated bidirectional LSP > has assymetric BW for each direction, it would might be reasonable to have > two independent BFD sessions and protect each direction independently. At > the same time, bidirectional linear LSP will always be co-routed and using > independent BFD session for each direction and independent protection > doesn't seem practical. > And I agree that BFD control mechanism is needed. I think it can be part of > overall OAM control mechanism that is being worked on by CCAMP WG (I've > added the CCAMP to the discussion). > > Best regards, > Greg > > On Thu, Jun 3, 2010 at 2:49 AM, Mach Chen wrote: > >> Hi Mukund, >> >> Please see inline... >> >> >> -------------------------------------------------- >> From: "Mukund Mani" >> Sent: Thursday, June 03, 2010 3:40 PM >> To: ; >> Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01 >> >> >> Hi Mach >>> >>> Maybe "BFD session set-up in progress" ?? >>> >> >> Sounds better! >> >> >> >>> Also you mention: "The case you described *maybe* occur" >>> As for me this will *always* occur if I configure both the ends in Active >>> mode, because enabling BFD would initiate the LSP Ping for BFD bootstrap. >>> Am I correct on this? >>> >> >> A node (with smart implementation) with lower IP address should not >> initiate the LSP Ping for BFD bootstrap for the LSP(s) if it has already >> received an LSP Ping. So it depends on which end will firstly initiate the >> LSP Ping. >> >> >> >>> On the whole I have had another question for quite some time which I have >>> been asking in the MPLS-TP group also. >>> My question was w.r.t the draft-asm-mpls-tp-bfd-cc-cv-04 which defines >>> CC/CV >>> and RDI mechanism using BFD and relates the number of sessions to >>> protection >>> switching architectures. But I would like to co-relate the details here >>> to >>> have a clear understanding on the BFD operation itself... >>> >> I totally agree with you on this. Although protection switching is >> normally based on BFD detection results, but, IMHO, the number of BFD >> sessions should not closely coupled with the protection switching >> types(e.g., 1:1,1+1...). >> >> >> >>> For co-routed bi-directional LSP the forward and reverse path will be >>> associated at the LER's. Also the same relationship exists for forward >>> and >>> reverse path of associated bi-directional LSP's in the LER's and the >>> common >>> LSR's. >>> >> My understanding of co-routed bi-directional LSP is that it "associated" >> at all nodes(including LERs and LSRs) along the LSP. >> >> >> >>> So why cant I use this inherent relationship to decide whether to have a >>> single or two BFD sessions for a bidirectional LSP? >>> >> I am not sure what's your meaning about the inherent relationship. Do you >> suggest: one BFD session for co-routed bi-dir LSP and two BFD sessions for >> associated bi-dir LSP, or just one BFD session for bi-dir LSP (no matter >> what co-routed or associated)? >> >> For co-routed and associated bidirectional LSP, IMHO, they should be >> treated as the same construct. From the view of their clients, there is no >> difference between the co-routed and associated bidirection LSP. Why there >> requires associated bidirectional LSP, that is becase there is no co-routed >> bidirectional LSP(e.g., the devices do support yet) and bidirectional LSPs >> are desired. Now that we have associated two unidirectional LSPs into one >> associated bidirectional LSP, it is logically to treat it as a real >> bidirectional LSP. That means, there should be no difference in protection >> switching between co-routed and associated bidrectional LSP. >> >> >> Basically trying to figure out the need for the explicit mechanism >>> using Return Path TLV and Session Control TLV mentioned in the draft >>> "draft-chen-mpls-bfd-enhancement-01". >>> I agree that for a pair of Uni-directional LSP's, using Return Path and >>> Session Control TLV might be useful but why do we need this for >>> associated >>> and co-routed LSP? >>> >> >> It depends on how you want each direction of a bidirectional LSP to be >> operated (independent or coordinated). If you want each direction of the >> bidirectional LSP to be protected and switched independently, there should >> be separate BFD session for each direction, or only one BFD session is >> needed. >> >> In our draft, if the LSP is bidirectional(co-routed or associated), there >> is no need to carry the Return Path TLV, only Session Control TLV is >> required, which is used to control how many BFD sessions should be setup >> over the LSP. IMHO, if we want the LSP could be operated either as >> independent or coodinated, a BFD session control mechanism(using Session >> Control TLV or other means(e.g., in MPLS-TP scenario, using a bit of GACh >> flag field)) is needed. >> >> Best regards, >> Mach >> >> >> >>> With Regards >>> Mukund >>> >>> On Tue, Jun 1, 2010 at 3:03 PM, Mach Chen wrote: >>> >>> Hi Mukund, >>>> >>>> Sorry for the delay response! >>>> >>>> The case you described maybe occur, and strictly speaking, it is not >>>> very >>>> accurate to mention that the "Backward direction BFD session exists" as >>>> return code, how about "BFD session collision"? or do you have any other >>>> suggestions? >>>> >>>> Best regards, >>>> Mach >>>> -------------------------------------------------- >>>> From: "Mukund Mani" >>>> Sent: Monday, May 31, 2010 3:04 AM >>>> To: >>>> Subject: Query on draft-chen-mpls-bfd-enhancement-01 >>>> >>>> >>>> Hi >>>> >>>>> >>>>> Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could the >>>>> draft >>>>> authors kindly clarify the same: >>>>> >>>>> Section 4 on session establishment mentions the following: >>>>> >>>>> If node with the larger IP receives LSP ping >>>>> message signaling BFD session with Session Control TLV, LSP ping >>>>> reply must be transmitted with "Backward direction BFD session >>>>> exists" to the ingress LSR. >>>>> >>>>> >>>>> >>>>> In the case of BFD session provisioned on both nodes in the Active >>>>> mode, the LSP Ping for the backward direction BFD session could be >>>>> received even when the forward direction session is not yet >>>>> established. In that case is it correct to mention that the "Backward >>>>> direction BFD session exists" as return code? >>>>> >>>>> >>>>> Kindly let me know if I am missing something here... >>>>> >>>>> >>>>> With Regards >>>>> >>>>> Mukund >>>>> >>>>> >>>>> >>> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> > > --00c09f89980e8196f5048824e5a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mach

Thanks for the response.. So in that case t= he BFD session initiator shall include the Session Control TLV in the Echo = Request only when the bidirectional LSP is to be protected in a co-ordinate= d fashion.=A0

You also mention in the draft that=A0

&quo= t;If there is no Session Control TLV car= ried in the echo request, it's up to the egress LSR to decide whether to initiate another BFD session for the b= ackward direction LSP"

=
Does this imply that when a Session Control TLV is= not included by the peer, it can still end up in one BFD session?? (based = on the egress LSR's decision)



With Regards
Mukund

On Thu, Jun 3, 2010 at 11:17 PM, Greg Mirsky <gregimirsky@gmail.com>= ; wrote:
Dear Mach,
I very much agree with your v= iew that "It depends on how you want each direction of a bidirectional= LSP to be=20 operated [GIM>> perhaps "pr= otected" is closer] (independent or coordinated). If you want e= ach direction of the bidirectional LSP to be protected and switched independently, there=20 should be separate BFD session for each direction, or only one BFD=20 session is needed."
But I'd differ that associated and co-route= d bidirectional LSP should be viewed as the same construct. They certainly = may be viewed this way but I wouldn't see that as "should". I= f, for example, associated bidirectional LSP has assymetric BW for each dir= ection, it would might be reasonable to have two independent BFD sessions a= nd protect each direction independently. At the same time, bidirectional li= near LSP will always be co-routed and using independent BFD session for eac= h direction and independent protection doesn't seem practical.
And I agree that BFD control mechanism is needed. I think it can be part of= overall OAM control mechanism that is being worked on by CCAMP WG (I'v= e added the CCAMP to the discussion).

Best regards,
Greg

On Thu, Ju= n 3, 2010 at 2:49 AM, Mach Chen <mach@huawei.com> wrote:
Hi Mukund,

Please see inline...


--------------------------------------------------
From: "Mukund Mani" <mukund.mani@gmail.com>
Sent: Thursday, June 03, 2010 3:40 PM
To: <mach@huawei.co= m>; <rtg-bf= d@ietf.org>
Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01


Hi Mach

Maybe "BFD session set-up in progress" ??

Sounds better!



Also you mention: =A0"The case you described *maybe* occur"
As for me this will *always* occur if I configure both the ends in Active mode, because enabling BFD would initiate the LSP Ping for BFD bootstrap. Am I correct on this?

A node (with smart implementation) with lower IP address should not initiat= e the LSP Ping for BFD bootstrap for the LSP(s) if it has already received = an LSP Ping. So it depends on which end will firstly initiate the LSP Ping.=



On the whole I have had another question for quite some time which I have been asking in the MPLS-TP group also.
My question was w.r.t the draft-asm-mpls-tp-bfd-cc-cv-04 which defines CC/C= V
and RDI mechanism using BFD and relates the number of sessions to protectio= n
switching architectures. But I would like to co-relate the details here to<= br> have a clear understanding on the BFD operation itself...
I totally agree with you on this. Although protection switching is normally= based on BFD detection results, but, IMHO, the number of BFD sessions shou= ld not closely coupled with the protection switching types(e.g., 1:1,1+1...= ).



For co-routed bi-directional LSP the forward and reverse path will be
associated at the LER's. Also the same relationship exists for forward = and
reverse path of associated bi-directional LSP's in the LER's and th= e common
LSR's.
My understanding of co-routed bi-directional LSP is that it "associate= d" at all nodes(including LERs and LSRs) along the LSP.



So why cant I use this inherent relationship to decide whether to have a single or two BFD sessions for a bidirectional LSP?
I am not sure what's your meaning about the inherent relationship. Do y= ou suggest: one BFD session for co-routed bi-dir LSP and two BFD sessions f= or associated bi-dir LSP, or just one BFD session for bi-dir LSP (no matter= what co-routed or associated)?

For co-routed and associated bidirectional LSP, IMHO, they should be treate= d as the same construct. From the view of their clients, there is no differ= ence between the co-routed and associated bidirection LSP. Why there requir= es associated bidirectional LSP, that is becase there is no co-routed bidir= ectional LSP(e.g., the devices do support yet) and bidirectional LSPs are d= esired. Now that we have associated two unidirectional LSPs into one associ= ated bidirectional LSP, it is logically to treat it as a real bidirectional= LSP. That means, there should be no difference in protection switching bet= ween co-routed and associated bidrectional LSP.


Basically trying to figure out the need for the explicit mechanism
using Return Path TLV and Session Control TLV mentioned in the draft
"draft-chen-mpls-bfd-enhancement-01".
I agree that for a pair of Uni-directional LSP's, using Return Path and=
Session Control TLV might be useful but why do we need this for associated<= br> and co-routed LSP?

It depends on how you want each direction of a bidirectional LSP to be oper= ated (independent or coordinated). If you want each direction of the bidire= ctional LSP to be protected and switched independently, there should be sep= arate BFD session for each direction, or only one BFD session is needed.
In our draft, if the LSP is bidirectional(co-routed or associated), there i= s no need to carry the Return Path TLV, only Session Control TLV is require= d, which is used to control how many BFD sessions should be setup over the = LSP. IMHO, if we want the LSP could be operated either as independent or co= odinated, a BFD session control mechanism(using Session Control TLV or othe= r means(e.g., in MPLS-TP scenario, using a bit of GACh flag field)) is need= ed.

Best regards,
Mach



With Regards
Mukund

On Tue, Jun 1, 2010 at 3:03 PM, Mach Chen <mach@huawei.com> wrote:

Hi Mukund,

Sorry for the delay response!

The case you described maybe occur, and strictly speaking, it is not very accurate to mention that the "Backward direction BFD session exists&qu= ot; as
return code, how about "BFD session collision"? or do you have an= y other
suggestions?

Best regards,
Mach
--------------------------------------------------
From: "Mukund Mani" <mukund.mani@gmail.com>
Sent: Monday, May 31, 2010 3:04 AM
To: <rtg-bfd@ietf.= org>
Subject: Query on draft-chen-mpls-bfd-enhancement-01


Hi

Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could th= e draft
authors kindly clarify the same:

Section 4 on session establishment mentions the following:

If node with the larger IP receives LSP ping
message signaling BFD session with Session Control TLV, LSP ping
reply must be transmitted with "Backward direction BFD session
exists" to the ingress LSR.



In the case of BFD session provisioned on both nodes in the Active
mode, the LSP Ping for the backward direction BFD session could be
received even when the forward direction session is not yet
established. In that case is it correct to mention that the "Backward<= br> direction BFD session exists" as return code?


Kindly let me know if I am missing something here...


With Regards

Mukund



_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/mpls-tp


--00c09f89980e8196f5048824e5a4-- From manav.bhatia@alcatel-lucent.com Thu Jun 3 16:34:09 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB78D3A67FB for ; Thu, 3 Jun 2010 16:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.287 X-Spam-Level: X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysUYyaPTg8OC for ; Thu, 3 Jun 2010 16:34:05 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 7315D3A680B for ; Thu, 3 Jun 2010 16:34:04 -0700 (PDT) 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 o53NXlTa002189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 3 Jun 2010 18:33:50 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o53NXjMJ011795 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 4 Jun 2010 05:03:47 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 4 Jun 2010 05:03:45 +0530 From: "Bhatia, Manav (Manav)" To: "rtg-bfd@ietf.org" Date: Fri, 4 Jun 2010 05:03:45 +0530 Subject: FW: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt Thread-Topic: FW: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt Thread-Index: AcsDdTVgyEmzAXlZRjSrI6j3gFKA7A== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CCF8FAFC0@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.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jun 2010 23:34:10 -0000 Hi, Now that we're done with the base specs can we get some feedback on this dr= aft? Most of the WGs in the ROUTING area have already moved to HMAC-SHA and= we would like BFD also to move from MD5 and keyed-SHA towards stronger cry= pto algos. In addition to this, it also introduces two new generic authenti= cation types that can be used for specifying any auth algo for BFD. Again n= othing new and this is already in place for ISIS, OSPF, etc. Cheers, Manav ----- Forwarded Message ---- From: "Internet-Drafts@ietf.org" To: i-d-announce@ietf.org Sent: Thu, June 3, 2010 10:30:02 PM Subject: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : BFD Generic Cryptographic Authentication Author(s) : M. Bhatia, V. Manral Filename : draft-bhatia-bfd-crypto-auth-02.txt Pages : 12 Date : 2010-6-3 =20 This document proposes an extension for Bidirectional Forwarding=20 Detection (BFD) to allow the use of any cryptographic authentication=20 algorithm in addition to the already documented authentication=20 schemes, described in the base specification. =20 Although this document has been written specifically to introduce two=20 new Authentication types it describes how BFD can use National=20 Institute of Standards and Technology (NIST) Secure Hash Standard=20 family of algorithms (SHS) to authenticate the control packets, the=20 method described in this document is generic and can be used to=20 extend BFD to support any cryptographic hash function in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bhatia-bfd-crypto-auth-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India = From minto@juniper.net Thu Jun 3 16:39:27 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204C23A67FB for ; Thu, 3 Jun 2010 16:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wvw6QicB2cDK for ; Thu, 3 Jun 2010 16:39:26 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 0B2153A67ED for ; Thu, 3 Jun 2010 16:39:25 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTAg9H6aIh2EHTPB+mNcO/Kswh0taqH3N@postini.com; Thu, 03 Jun 2010 16:39:13 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 3 Jun 2010 16:38:18 -0700 From: Minto Jeyananth To: "Bhatia, Manav (Manav)" , "rtg-bfd@ietf.org" Date: Thu, 3 Jun 2010 16:38:16 -0700 Subject: RE: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt Thread-Topic: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt Thread-Index: AcsDdTVgyEmzAXlZRjSrI6j3gFKA7AAAEROg Message-ID: <05542EC42316164383B5180707A489EE1D66537C3E@EMBX02-HQ.jnpr.net> References: <7C362EEF9C7896468B36C9B79200D8350CCF8FAFC0@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CCF8FAFC0@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-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jun 2010 23:39:27 -0000 =20 It's really interesting to see how many protocol implementations exist f= or SHA and stronger crypto algorithm.=20 -minto=20 |-----Original Message----- |From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf |Of Bhatia, Manav (Manav) |Sent: Thursday, June 03, 2010 4:34 PM |To: rtg-bfd@ietf.org |Subject: FW: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt | |Hi, | |Now that we're done with the base specs can we get some feedback on this |draft? Most of the WGs in the ROUTING area have already moved to HMAC-SHA |and we would like BFD also to move from MD5 and keyed-SHA towards stronger |crypto algos. In addition to this, it also introduces two new generic |authentication types that can be used for specifying any auth algo for BFD= . |Again nothing new and this is already in place for ISIS, OSPF, etc. | |Cheers, Manav | From manav.bhatia@alcatel-lucent.com Thu Jun 3 16:56:52 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B2C3A6862 for ; Thu, 3 Jun 2010 16:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.482 X-Spam-Level: X-Spam-Status: No, score=-1.482 tagged_above=-999 required=5 tests=[AWL=1.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ourwyVwSPmj6 for ; Thu, 3 Jun 2010 16:56:51 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 699573A6813 for ; Thu, 3 Jun 2010 16:56:50 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o53NuXIu001894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Jun 2010 18:56:36 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o53NuWue012730 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Jun 2010 05:26:33 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 4 Jun 2010 05:26:33 +0530 From: "Bhatia, Manav (Manav)" To: Minto Jeyananth , "rtg-bfd@ietf.org" Date: Fri, 4 Jun 2010 05:26:31 +0530 Subject: RE: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt Thread-Topic: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt Thread-Index: AcsDdTVgyEmzAXlZRjSrI6j3gFKA7AAAEROgAAChLcA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350CCF8FAFC1@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CCF8FAFC0@INBANSXCHMBSA1.in.alcatel-lucent.com> <05542EC42316164383B5180707A489EE1D66537C3E@EMBX02-HQ.jnpr.net> In-Reply-To: <05542EC42316164383B5180707A489EE1D66537C3E@EMBX02-HQ.jnpr.net> 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-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jun 2010 23:56:52 -0000 Minto, Its already started appearing in the RFPs. You might also want to look at the work being done in KARP and OPSEC WGs if= you havent already. Cheers, Manav > -----Original Message----- > From: Minto Jeyananth [mailto:minto@juniper.net]=20 > Sent: Friday, June 04, 2010 5.08 AM > To: Bhatia, Manav (Manav); rtg-bfd@ietf.org > Subject: RE: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt=20 >=20 > =20 >=20 > It's really interesting to see how many protocol=20 > implementations exist for SHA and stronger crypto algorithm.=20 >=20 > -minto=20 >=20 > |-----Original Message----- > |From: rtg-bfd-bounces@ietf.org=20 > [mailto:rtg-bfd-bounces@ietf.org] On Behalf > |Of Bhatia, Manav (Manav) > |Sent: Thursday, June 03, 2010 4:34 PM > |To: rtg-bfd@ietf.org > |Subject: FW: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt > | > |Hi, > | > |Now that we're done with the base specs can we get some=20 > feedback on this > |draft? Most of the WGs in the ROUTING area have already=20 > moved to HMAC-SHA > |and we would like BFD also to move from MD5 and keyed-SHA=20 > towards stronger > |crypto algos. In addition to this, it also introduces two new generic > |authentication types that can be used for specifying any=20 > auth algo for BFD. > |Again nothing new and this is already in place for ISIS, OSPF, etc. > | > |Cheers, Manav > | > = From mach@huawei.com Fri Jun 4 03:50:30 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EBB83A6A63; Fri, 4 Jun 2010 03:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.565 X-Spam-Level: X-Spam-Status: No, score=-0.565 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_50=0.001, J_CHICKENPOX_32=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOpSXs7ZNere; Fri, 4 Jun 2010 03:50:28 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 8CE403A698B; Fri, 4 Jun 2010 03:50:27 -0700 (PDT) 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 <0L3H00307KRO6F@szxga03-in.huawei.com>; Fri, 04 Jun 2010 18:50:12 +0800 (CST) Received: from m55527c ([10.110.98.169]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3H00667KRNJ6@szxga03-in.huawei.com>; Fri, 04 Jun 2010 18:50:12 +0800 (CST) Date: Fri, 04 Jun 2010 18:50:11 +0800 From: Mach Chen Subject: Re: [mpls-tp] Query on draft-chen-mpls-bfd-enhancement-01 In-reply-to: To: Greg Mirsky Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <2303DFD3C2884F2DB7C194CA0C60367D@m55527c> Cc: Mukund Mani , rtg-bfd@ietf.org, ccamp@ietf.org, mpls-tp@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jun 2010 10:50:30 -0000 Dear Greg, Thanks for your response! Although co-routed bidirectional LSP may also has assymetric BW for each direction and be protected and swithed for each direction in theory, I basically agree with your analysis about co-routed bidirectional LSP, it does not seem practical, one direction of a co-routed bi-dir LSP broken, usually means the other direction of the LSP is broken too, and of cause the whole LSP is actually broken even if one direction may be OK. So requiring a co-routed bidirectional to be operated as a single entity is reasonable. What I mean they should be treated as the same construt is from the view of protection switching, now that it is called and used as a bidirectioanl LSP, it is resonalbe to be protected and switched as single LSP. But since an associated bi-dir LSP is combined with two different LSPs and each LSP has its own fate, when one LSP is broken, usually the other LSP is OK, and from the view of the whole associated bi-dir LSP, it is non-workable now and should be switched to another protection associated bi-dir LSP(if not, why we need to combine the two unidirectional LSP into a bidirectional LSP?). >From the view of fault localizaion and associated bi-dir LSP re-construction, we should better know which component LSP is broken, hence independent BFD session for each component LSP is necessary. Best regards, Mach -------------------------------------------------- From: "Greg Mirsky" Sent: Friday, June 04, 2010 1:47 AM To: "Mach Chen" Cc: "Mukund Mani" ; ; ; Subject: Re: [mpls-tp] Query on draft-chen-mpls-bfd-enhancement-01 > Dear Mach, > I very much agree with your view that "It depends on how you want each > direction of a bidirectional LSP to be operated [GIM>> perhaps "protected" > is closer] (independent or coordinated). If you want each direction of the > bidirectional LSP to be protected and switched independently, there should > be separate BFD session for each direction, or only one BFD session is > needed." > But I'd differ that associated and co-routed bidirectional LSP should be > viewed as the same construct. They certainly may be viewed this way but I > wouldn't see that as "should". If, for example, associated bidirectional > LSP > has assymetric BW for each direction, it would might be reasonable to have > two independent BFD sessions and protect each direction independently. At > the same time, bidirectional linear LSP will always be co-routed and using > independent BFD session for each direction and independent protection > doesn't seem practical. > And I agree that BFD control mechanism is needed. I think it can be part > of > overall OAM control mechanism that is being worked on by CCAMP WG (I've > added the CCAMP to the discussion). > > Best regards, > Greg > > On Thu, Jun 3, 2010 at 2:49 AM, Mach Chen wrote: > >> Hi Mukund, >> >> Please see inline... >> >> >> -------------------------------------------------- >> From: "Mukund Mani" >> Sent: Thursday, June 03, 2010 3:40 PM >> To: ; >> Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01 >> >> >> Hi Mach >>> >>> Maybe "BFD session set-up in progress" ?? >>> >> >> Sounds better! >> >> >> >>> Also you mention: "The case you described *maybe* occur" >>> As for me this will *always* occur if I configure both the ends in >>> Active >>> mode, because enabling BFD would initiate the LSP Ping for BFD >>> bootstrap. >>> Am I correct on this? >>> >> >> A node (with smart implementation) with lower IP address should not >> initiate the LSP Ping for BFD bootstrap for the LSP(s) if it has already >> received an LSP Ping. So it depends on which end will firstly initiate >> the >> LSP Ping. >> >> >> >>> On the whole I have had another question for quite some time which I >>> have >>> been asking in the MPLS-TP group also. >>> My question was w.r.t the draft-asm-mpls-tp-bfd-cc-cv-04 which defines >>> CC/CV >>> and RDI mechanism using BFD and relates the number of sessions to >>> protection >>> switching architectures. But I would like to co-relate the details here >>> to >>> have a clear understanding on the BFD operation itself... >>> >> I totally agree with you on this. Although protection switching is >> normally >> based on BFD detection results, but, IMHO, the number of BFD sessions >> should >> not closely coupled with the protection switching types(e.g., >> 1:1,1+1...). >> >> >> >>> For co-routed bi-directional LSP the forward and reverse path will be >>> associated at the LER's. Also the same relationship exists for forward >>> and >>> reverse path of associated bi-directional LSP's in the LER's and the >>> common >>> LSR's. >>> >> My understanding of co-routed bi-directional LSP is that it "associated" >> at >> all nodes(including LERs and LSRs) along the LSP. >> >> >> >>> So why cant I use this inherent relationship to decide whether to have a >>> single or two BFD sessions for a bidirectional LSP? >>> >> I am not sure what's your meaning about the inherent relationship. Do you >> suggest: one BFD session for co-routed bi-dir LSP and two BFD sessions >> for >> associated bi-dir LSP, or just one BFD session for bi-dir LSP (no matter >> what co-routed or associated)? >> >> For co-routed and associated bidirectional LSP, IMHO, they should be >> treated as the same construct. From the view of their clients, there is >> no >> difference between the co-routed and associated bidirection LSP. Why >> there >> requires associated bidirectional LSP, that is becase there is no >> co-routed >> bidirectional LSP(e.g., the devices do support yet) and bidirectional >> LSPs >> are desired. Now that we have associated two unidirectional LSPs into one >> associated bidirectional LSP, it is logically to treat it as a real >> bidirectional LSP. That means, there should be no difference in >> protection >> switching between co-routed and associated bidrectional LSP. >> >> >> Basically trying to figure out the need for the explicit mechanism >>> using Return Path TLV and Session Control TLV mentioned in the draft >>> "draft-chen-mpls-bfd-enhancement-01". >>> I agree that for a pair of Uni-directional LSP's, using Return Path and >>> Session Control TLV might be useful but why do we need this for >>> associated >>> and co-routed LSP? >>> >> >> It depends on how you want each direction of a bidirectional LSP to be >> operated (independent or coordinated). If you want each direction of the >> bidirectional LSP to be protected and switched independently, there >> should >> be separate BFD session for each direction, or only one BFD session is >> needed. >> >> In our draft, if the LSP is bidirectional(co-routed or associated), there >> is no need to carry the Return Path TLV, only Session Control TLV is >> required, which is used to control how many BFD sessions should be setup >> over the LSP. IMHO, if we want the LSP could be operated either as >> independent or coodinated, a BFD session control mechanism(using Session >> Control TLV or other means(e.g., in MPLS-TP scenario, using a bit of GACh >> flag field)) is needed. >> >> Best regards, >> Mach >> >> >> >>> With Regards >>> Mukund >>> >>> On Tue, Jun 1, 2010 at 3:03 PM, Mach Chen wrote: >>> >>> Hi Mukund, >>>> >>>> Sorry for the delay response! >>>> >>>> The case you described maybe occur, and strictly speaking, it is not >>>> very >>>> accurate to mention that the "Backward direction BFD session exists" as >>>> return code, how about "BFD session collision"? or do you have any >>>> other >>>> suggestions? >>>> >>>> Best regards, >>>> Mach >>>> -------------------------------------------------- >>>> From: "Mukund Mani" >>>> Sent: Monday, May 31, 2010 3:04 AM >>>> To: >>>> Subject: Query on draft-chen-mpls-bfd-enhancement-01 >>>> >>>> >>>> Hi >>>> >>>>> >>>>> Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could the >>>>> draft >>>>> authors kindly clarify the same: >>>>> >>>>> Section 4 on session establishment mentions the following: >>>>> >>>>> If node with the larger IP receives LSP ping >>>>> message signaling BFD session with Session Control TLV, LSP ping >>>>> reply must be transmitted with "Backward direction BFD session >>>>> exists" to the ingress LSR. >>>>> >>>>> >>>>> >>>>> In the case of BFD session provisioned on both nodes in the Active >>>>> mode, the LSP Ping for the backward direction BFD session could be >>>>> received even when the forward direction session is not yet >>>>> established. In that case is it correct to mention that the "Backward >>>>> direction BFD session exists" as return code? >>>>> >>>>> >>>>> Kindly let me know if I am missing something here... >>>>> >>>>> >>>>> With Regards >>>>> >>>>> Mukund >>>>> >>>>> >>>>> >>> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> > From mach@huawei.com Fri Jun 4 03:50:34 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479143A6A63; Fri, 4 Jun 2010 03:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.479 X-Spam-Level: X-Spam-Status: No, score=0.479 tagged_above=-999 required=5 tests=[AWL=-1.627, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8qjTkGWVTH7; Fri, 4 Jun 2010 03:50:31 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A86D43A6A65; Fri, 4 Jun 2010 03:50:30 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3H00F0IKRT8Q@szxga05-in.huawei.com>; Fri, 04 Jun 2010 18:50:17 +0800 (CST) Received: from m55527c ([10.110.98.169]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3H00EDZKRR1U@szxga05-in.huawei.com>; Fri, 04 Jun 2010 18:50:17 +0800 (CST) Date: Fri, 04 Jun 2010 18:50:15 +0800 From: Mach Chen Subject: Re: [mpls-tp] Query on draft-chen-mpls-bfd-enhancement-01 In-reply-to: To: Mukund Mani , Greg Mirsky Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <2303DFD3C2884F2DB7C194CA0C60367D@m55527c> Cc: rtg-bfd@ietf.org, ccamp@ietf.org, mpls-tp@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jun 2010 10:50:34 -0000 Hi Mukund, Please see inline... -------------------------------------------------- From: "Mukund Mani" Sent: Friday, June 04, 2010 3:05 AM To: "Greg Mirsky" ; Cc: ; ; Subject: Re: [mpls-tp] Query on draft-chen-mpls-bfd-enhancement-01 > Hi Mach > > Thanks for the response.. So in that case the BFD session initiator shall > include the Session Control TLV in the Echo Request only when the > bidirectional LSP is to be protected in a co-ordinated fashion. Yes. > > You also mention in the draft that > > "If there is no Session Control TLV carried in the echo request, it's up > to > the egress LSR to decide whether to initiate another BFD session for the > backward direction LSP" > > Does this imply that when a Session Control TLV is not included by the > peer, > it can still end up in one BFD session?? (based on the egress LSR's > decision) There is one more sentence you did not quote: "..this is the same as the definition in [BFD-MPLS]." So, if there is no session Control TLV included, the procedure is same as current BFD for MPLS specification. The BFD session is only trigered by the configuration/policy at the egress, it does not relate to whether it received a LSP Ping bootstrap message. Best regards, Mach > > > > With Regards > Mukund > > On Thu, Jun 3, 2010 at 11:17 PM, Greg Mirsky > wrote: > >> Dear Mach, >> I very much agree with your view that "It depends on how you want each >> direction of a bidirectional LSP to be operated [GIM>> perhaps >> "protected" >> is closer] (independent or coordinated). If you want each direction of >> the >> bidirectional LSP to be protected and switched independently, there >> should >> be separate BFD session for each direction, or only one BFD session is >> needed." >> But I'd differ that associated and co-routed bidirectional LSP should be >> viewed as the same construct. They certainly may be viewed this way but I >> wouldn't see that as "should". If, for example, associated bidirectional >> LSP >> has assymetric BW for each direction, it would might be reasonable to >> have >> two independent BFD sessions and protect each direction independently. At >> the same time, bidirectional linear LSP will always be co-routed and >> using >> independent BFD session for each direction and independent protection >> doesn't seem practical. >> And I agree that BFD control mechanism is needed. I think it can be part >> of >> overall OAM control mechanism that is being worked on by CCAMP WG (I've >> added the CCAMP to the discussion). >> >> Best regards, >> Greg >> >> On Thu, Jun 3, 2010 at 2:49 AM, Mach Chen wrote: >> >>> Hi Mukund, >>> >>> Please see inline... >>> >>> >>> -------------------------------------------------- >>> From: "Mukund Mani" >>> Sent: Thursday, June 03, 2010 3:40 PM >>> To: ; >>> Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01 >>> >>> >>> Hi Mach >>>> >>>> Maybe "BFD session set-up in progress" ?? >>>> >>> >>> Sounds better! >>> >>> >>> >>>> Also you mention: "The case you described *maybe* occur" >>>> As for me this will *always* occur if I configure both the ends in >>>> Active >>>> mode, because enabling BFD would initiate the LSP Ping for BFD >>>> bootstrap. >>>> Am I correct on this? >>>> >>> >>> A node (with smart implementation) with lower IP address should not >>> initiate the LSP Ping for BFD bootstrap for the LSP(s) if it has already >>> received an LSP Ping. So it depends on which end will firstly initiate >>> the >>> LSP Ping. >>> >>> >>> >>>> On the whole I have had another question for quite some time which I >>>> have >>>> been asking in the MPLS-TP group also. >>>> My question was w.r.t the draft-asm-mpls-tp-bfd-cc-cv-04 which defines >>>> CC/CV >>>> and RDI mechanism using BFD and relates the number of sessions to >>>> protection >>>> switching architectures. But I would like to co-relate the details here >>>> to >>>> have a clear understanding on the BFD operation itself... >>>> >>> I totally agree with you on this. Although protection switching is >>> normally based on BFD detection results, but, IMHO, the number of BFD >>> sessions should not closely coupled with the protection switching >>> types(e.g., 1:1,1+1...). >>> >>> >>> >>>> For co-routed bi-directional LSP the forward and reverse path will be >>>> associated at the LER's. Also the same relationship exists for forward >>>> and >>>> reverse path of associated bi-directional LSP's in the LER's and the >>>> common >>>> LSR's. >>>> >>> My understanding of co-routed bi-directional LSP is that it "associated" >>> at all nodes(including LERs and LSRs) along the LSP. >>> >>> >>> >>>> So why cant I use this inherent relationship to decide whether to have >>>> a >>>> single or two BFD sessions for a bidirectional LSP? >>>> >>> I am not sure what's your meaning about the inherent relationship. Do >>> you >>> suggest: one BFD session for co-routed bi-dir LSP and two BFD sessions >>> for >>> associated bi-dir LSP, or just one BFD session for bi-dir LSP (no matter >>> what co-routed or associated)? >>> >>> For co-routed and associated bidirectional LSP, IMHO, they should be >>> treated as the same construct. From the view of their clients, there is >>> no >>> difference between the co-routed and associated bidirection LSP. Why >>> there >>> requires associated bidirectional LSP, that is becase there is no >>> co-routed >>> bidirectional LSP(e.g., the devices do support yet) and bidirectional >>> LSPs >>> are desired. Now that we have associated two unidirectional LSPs into >>> one >>> associated bidirectional LSP, it is logically to treat it as a real >>> bidirectional LSP. That means, there should be no difference in >>> protection >>> switching between co-routed and associated bidrectional LSP. >>> >>> >>> Basically trying to figure out the need for the explicit mechanism >>>> using Return Path TLV and Session Control TLV mentioned in the draft >>>> "draft-chen-mpls-bfd-enhancement-01". >>>> I agree that for a pair of Uni-directional LSP's, using Return Path and >>>> Session Control TLV might be useful but why do we need this for >>>> associated >>>> and co-routed LSP? >>>> >>> >>> It depends on how you want each direction of a bidirectional LSP to be >>> operated (independent or coordinated). If you want each direction of the >>> bidirectional LSP to be protected and switched independently, there >>> should >>> be separate BFD session for each direction, or only one BFD session is >>> needed. >>> >>> In our draft, if the LSP is bidirectional(co-routed or associated), >>> there >>> is no need to carry the Return Path TLV, only Session Control TLV is >>> required, which is used to control how many BFD sessions should be setup >>> over the LSP. IMHO, if we want the LSP could be operated either as >>> independent or coodinated, a BFD session control mechanism(using Session >>> Control TLV or other means(e.g., in MPLS-TP scenario, using a bit of >>> GACh >>> flag field)) is needed. >>> >>> Best regards, >>> Mach >>> >>> >>> >>>> With Regards >>>> Mukund >>>> >>>> On Tue, Jun 1, 2010 at 3:03 PM, Mach Chen wrote: >>>> >>>> Hi Mukund, >>>>> >>>>> Sorry for the delay response! >>>>> >>>>> The case you described maybe occur, and strictly speaking, it is not >>>>> very >>>>> accurate to mention that the "Backward direction BFD session exists" >>>>> as >>>>> return code, how about "BFD session collision"? or do you have any >>>>> other >>>>> suggestions? >>>>> >>>>> Best regards, >>>>> Mach >>>>> -------------------------------------------------- >>>>> From: "Mukund Mani" >>>>> Sent: Monday, May 31, 2010 3:04 AM >>>>> To: >>>>> Subject: Query on draft-chen-mpls-bfd-enhancement-01 >>>>> >>>>> >>>>> Hi >>>>> >>>>>> >>>>>> Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could the >>>>>> draft >>>>>> authors kindly clarify the same: >>>>>> >>>>>> Section 4 on session establishment mentions the following: >>>>>> >>>>>> If node with the larger IP receives LSP ping >>>>>> message signaling BFD session with Session Control TLV, LSP ping >>>>>> reply must be transmitted with "Backward direction BFD session >>>>>> exists" to the ingress LSR. >>>>>> >>>>>> >>>>>> >>>>>> In the case of BFD session provisioned on both nodes in the Active >>>>>> mode, the LSP Ping for the backward direction BFD session could be >>>>>> received even when the forward direction session is not yet >>>>>> established. In that case is it correct to mention that the "Backward >>>>>> direction BFD session exists" as return code? >>>>>> >>>>>> >>>>>> Kindly let me know if I am missing something here... >>>>>> >>>>>> >>>>>> With Regards >>>>>> >>>>>> Mukund >>>>>> >>>>>> >>>>>> >>>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >> >> > From manav.bhatia@alcatel-lucent.com Tue Jun 8 01:53:22 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E0BB28C130 for ; Tue, 8 Jun 2010 01:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QS7t9sueBNTM for ; Tue, 8 Jun 2010 01:53:21 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 5EC2528C129 for ; Tue, 8 Jun 2010 01:53:20 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o588rH1w025982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Jun 2010 03:53:19 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o588rGvm018290 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Jun 2010 14:23:16 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Tue, 8 Jun 2010 14:23:16 +0530 From: "Bhatia, Manav (Manav)" To: Vishwas Manral Date: Tue, 8 Jun 2010 14:23:15 +0530 Subject: RE: BFD on LAN Thread-Topic: BFD on LAN Thread-Index: AcsCEIZGFXWUJYzITauwFOxUu32GHAE1wAwA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CCF8FB74C@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.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 08 Jun 2010 08:53:22 -0000 Hi Vishwas, I would presume that we would create a BFD session with only the DR/BDR. Wh= y should two DROther routers have a BFD session with each other in the cont= ext of OSPF? AFAIK, they are not even aware of the presence of the other. Cheers, Manav=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org=20 > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vishwas Manral > Sent: Wednesday, June 02, 2010 10.30 AM > To: Glen Kent > Cc: rtg-bfd@ietf.org > Subject: Re: BFD on LAN >=20 > Hi Glen, >=20 > Reshad is right. >=20 > We could have a FULL mesh, or if we wanted to only check particular > reachability we could have BFD sessions between DROther and DR/ BDR. > this however would be an optimization for OSPF and IS-IS. >=20 > Thanks, > Vishwas >=20 > On Tue, Jun 1, 2010 at 5:20 PM, Glen Kent wrote: > > Hi, > > > > Since BFD does not use a mcast address does it mean that it=20 > will form > > a full mesh of unicast BFD sessions on a LAN? > > > > Glen > > > = From minto@juniper.net Tue Jun 8 06:54:52 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8F128C1B1 for ; Tue, 8 Jun 2010 06:54:52 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqZ7YoDFniJ4 for ; Tue, 8 Jun 2010 06:54:51 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 020E928C1BD for ; Tue, 8 Jun 2010 06:54:50 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTA5Lqe2KRxxNtUO7U6bvB2DLdKBEEbAj@postini.com; Tue, 08 Jun 2010 06:54:52 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 8 Jun 2010 06:54:07 -0700 From: Minto Jeyananth To: "Bhatia, Manav (Manav)" , Vishwas Manral Date: Tue, 8 Jun 2010 06:54:06 -0700 Subject: RE: BFD on LAN Thread-Topic: BFD on LAN Thread-Index: AcsCEIZGFXWUJYzITauwFOxUu32GHAE1wAwAAAo6ytA= Message-ID: <05542EC42316164383B5180707A489EE1D66C88E5B@EMBX02-HQ.jnpr.net> References: <7C362EEF9C7896468B36C9B79200D8350CCF8FB74C@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CCF8FB74C@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.9 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, 08 Jun 2010 13:54:52 -0000 Manav,=20 DRother may use other DRother routers to forward traffic. I know one imple= mentation even provide a knob to control it :).=20 -minto =20 |-----Original Message----- |From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf |Of Bhatia, Manav (Manav) |Sent: Tuesday, June 08, 2010 1:53 AM |To: Vishwas Manral |Cc: rtg-bfd@ietf.org |Subject: RE: BFD on LAN | |Hi Vishwas, | |I would presume that we would create a BFD session with only the DR/BDR. |Why should two DROther routers have a BFD session with each other in the |context of OSPF? AFAIK, they are not even aware of the presence of the |other. | |Cheers, Manav | From vishwas.ietf@gmail.com Tue Jun 8 07:23:09 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D36928C1AC for ; Tue, 8 Jun 2010 07:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOFt6oQWJOXy for ; Tue, 8 Jun 2010 07:23:08 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 59E2E28C19C for ; Tue, 8 Jun 2010 07:23:08 -0700 (PDT) Received: by pwi8 with SMTP id 8so2229570pwi.31 for ; Tue, 08 Jun 2010 07:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=wkqhRMIDzvlvXGa08nw3ny8GLDlf3dFd3zgJrd5310k=; b=vpExIBjVtiRB62IEqgjsVDhfNcUyJ0EYNtsl0CHSNOu4ba85Q7JVRjLmKYtB7Y8k8u jIyoLZUpj9Y0pxC1exEtw9VuWofI8R/ZBUto96w+CgvGz/7TDosXwhrTghtTMZdh34NB XXHdUNXc4MHUgzVz8kr3c7+LTacAygvDAxSDU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WRfy17EKVl5vA248x3HdIHgVJnIGC7vufqC8SKlte86AZl3ajk7E9v2VdfdwHdpG6b H1/uGpkVE91N5zpVed5K8qYNgqpHAL8sm7x0HDrsUgqBlMWLvek0h+NRBzSrtCd2CBgC OdUSwi7sFKolgCDOohntQGmMkuQNX0SzKLdrY= MIME-Version: 1.0 Received: by 10.142.117.5 with SMTP id p5mr12022193wfc.23.1276006984536; Tue, 08 Jun 2010 07:23:04 -0700 (PDT) Received: by 10.142.233.7 with HTTP; Tue, 8 Jun 2010 07:23:04 -0700 (PDT) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CCF8FB74C@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CCF8FB74C@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Tue, 8 Jun 2010 07:23:04 -0700 Message-ID: Subject: Re: BFD on LAN From: Vishwas Manral To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 08 Jun 2010 14:23:09 -0000 Hi Manav, They have adjacencies which are parked in 2-way state. You are right from the control plane perspective the sessions may not be required. Thanks, Vishwas On Tue, Jun 8, 2010 at 1:53 AM, Bhatia, Manav (Manav) wrote: > Hi Vishwas, > > I would presume that we would create a BFD session with only the DR/BDR. Why should two DROther routers have a BFD session with each other in the context of OSPF? AFAIK, they are not even aware of the presence of the other. > > Cheers, Manav > >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org >> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vishwas Manral >> Sent: Wednesday, June 02, 2010 10.30 AM >> To: Glen Kent >> Cc: rtg-bfd@ietf.org >> Subject: Re: BFD on LAN >> >> Hi Glen, >> >> Reshad is right. >> >> We could have a FULL mesh, or if we wanted to only check particular >> reachability we could have BFD sessions between DROther and DR/ BDR. >> this however would be an optimization for OSPF and IS-IS. >> >> Thanks, >> Vishwas >> >> On Tue, Jun 1, 2010 at 5:20 PM, Glen Kent wrote: >> > Hi, >> > >> > Since BFD does not use a mcast address does it mean that it >> will form >> > a full mesh of unicast BFD sessions on a LAN? >> > >> > Glen >> > >> From manav.bhatia@alcatel-lucent.com Tue Jun 8 11:33:04 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4897E3A68E8 for ; Tue, 8 Jun 2010 11:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MItU0kR16WtW for ; Tue, 8 Jun 2010 11:33:03 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 4CDB53A68D9 for ; Tue, 8 Jun 2010 11:33:03 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o58IWvhB000556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Jun 2010 13:32:59 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o58IWufY018244 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Jun 2010 00:02:56 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 9 Jun 2010 00:02:55 +0530 From: "Bhatia, Manav (Manav)" To: Vishwas Manral Date: Wed, 9 Jun 2010 00:02:53 +0530 Subject: RE: BFD on LAN Thread-Topic: BFD on LAN Thread-Index: AcsHFiOjcSwNb5XxRB675goF3jMd2wAIqGEA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CCF8FB8A1@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CCF8FB74C@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-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 08 Jun 2010 18:33:04 -0000 Hi Vishwas, Yup, obviously that's correct. What I meant was that they are not in the FU= LL state. Cheers, Manav > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 > Sent: Tuesday, June 08, 2010 7.53 PM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: Re: BFD on LAN >=20 > Hi Manav, >=20 > They have adjacencies which are parked in 2-way state. >=20 > You are right from the control plane perspective the sessions may not > be required. >=20 > Thanks, > Vishwas >=20 > On Tue, Jun 8, 2010 at 1:53 AM, Bhatia, Manav (Manav) > wrote: > > Hi Vishwas, > > > > I would presume that we would create a BFD session with=20 > only the DR/BDR. Why should two DROther routers have a BFD=20 > session with each other in the context of OSPF? AFAIK, they=20 > are not even aware of the presence of the other. > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: rtg-bfd-bounces@ietf.org > >> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vishwas Manral > >> Sent: Wednesday, June 02, 2010 10.30 AM > >> To: Glen Kent > >> Cc: rtg-bfd@ietf.org > >> Subject: Re: BFD on LAN > >> > >> Hi Glen, > >> > >> Reshad is right. > >> > >> We could have a FULL mesh, or if we wanted to only check particular > >> reachability we could have BFD sessions between DROther=20 > and DR/ BDR. > >> this however would be an optimization for OSPF and IS-IS. > >> > >> Thanks, > >> Vishwas > >> > >> On Tue, Jun 1, 2010 at 5:20 PM, Glen Kent=20 > wrote: > >> > Hi, > >> > > >> > Since BFD does not use a mcast address does it mean that it > >> will form > >> > a full mesh of unicast BFD sessions on a LAN? > >> > > >> > Glen > >> > > >> > = From dkatz@juniper.net Tue Jun 8 12:08:17 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6943A67D9 for ; Tue, 8 Jun 2010 12:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWU64PIU1hTE for ; Tue, 8 Jun 2010 12:08:16 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 4CA4A3A6781 for ; Tue, 8 Jun 2010 12:08:16 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTA6VG0+nk8l4yI7nsf3bX6CFa+uBwMnT@postini.com; Tue, 08 Jun 2010 12:08:18 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Tue, 8 Jun 2010 11:54:13 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Jun 2010 11:54:13 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jun 2010 11:54:12 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Jun 2010 11:54:12 -0700 Received: from nimbus-sc.juniper.net (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o58IsCb96027; Tue, 8 Jun 2010 11:54:12 -0700 (PDT) (envelope-from dkatz@juniper.net) Subject: Re: BFD on LAN MIME-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset="us-ascii" From: Dave Katz In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CCF8FB74C@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Tue, 8 Jun 2010 11:54:11 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <03169BB5-F182-43FD-A09B-A6A46B302821@juniper.net> References: <7C362EEF9C7896468B36C9B79200D8350CCF8FB74C@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1078) X-OriginalArrivalTime: 08 Jun 2010 18:54:12.0219 (UTC) FILETIME=[FBFB0CB0:01CB073B] Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 08 Jun 2010 19:08:17 -0000 On Jun 8, 2010, at 1:53 AM, Bhatia, Manav (Manav) wrote: > Hi Vishwas, >=20 > I would presume that we would create a BFD session with only the = DR/BDR. Why should two DROther routers have a BFD session with each = other in the context of OSPF? AFAIK, they are not even aware of the = presence of the other. Well, OSPF routers forward directly through each other (by virtue of = being neighbors) regardless of DR-ship, so if you're actually trying to = protect the forwarding path, running BFD makes sense. One could argue that running sessions only with the DR/BDR is nearly as = good, since a failed DROther router will show up as not being adjacent = to the Network LSA and thus forwarding will be stopped, but that = potentially adds additional latency to the process. Also, a full mesh of BFD provides protection against non-transitive = connectivity in broadcast domains. Whether this is an actual concern is = probably arguable, though I'll point out that my crappy powerline = ethernet boxes at home do this regularly (I guess I won't build a = transit POP in my house.) As switching continues to get more = complicated, this may be a bigger issue than it was in the days of = orange hoses and vampire taps. --Dave >=20 > Cheers, Manav=20 >=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org=20 >> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vishwas Manral >> Sent: Wednesday, June 02, 2010 10.30 AM >> To: Glen Kent >> Cc: rtg-bfd@ietf.org >> Subject: Re: BFD on LAN >>=20 >> Hi Glen, >>=20 >> Reshad is right. >>=20 >> We could have a FULL mesh, or if we wanted to only check particular >> reachability we could have BFD sessions between DROther and DR/ BDR. >> this however would be an optimization for OSPF and IS-IS. >>=20 >> Thanks, >> Vishwas >>=20 >> On Tue, Jun 1, 2010 at 5:20 PM, Glen Kent = wrote: >>> Hi, >>>=20 >>> Since BFD does not use a mcast address does it mean that it=20 >> will form >>> a full mesh of unicast BFD sessions on a LAN? >>>=20 >>> Glen >>>=20 >>=20 >=20 From jhaas@slice.pfrc.org Tue Jun 15 08:43:24 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD56D3A6923 for ; Tue, 15 Jun 2010 08:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRqV0Lx-9PBF for ; Tue, 15 Jun 2010 08:43:24 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 343353A6830 for ; Tue, 15 Jun 2010 08:43:24 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8A1912240CD; Tue, 15 Jun 2010 15:43:28 +0000 (UTC) Date: Tue, 15 Jun 2010 15:43:28 +0000 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Notice of change of affiliation Message-ID: <20100615154328.GA29945@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Adrian Farrel X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 15 Jun 2010 15:43:25 -0000 Working Group, In the spirit of full transparency, I'd like to let everyone know that I have joined Juniper Networks. Juniper, as you know, is also my co-chair Dave Ward's employer. We've discussed this with the ADs and we don't think there will be any issues relating to keeping the working group running fairly and impartially. I'd like to think we both have a reputation for championing good standards work regardless of what the domain on the right hand side of our @ says on a particular day of the week. If you have any concerns, please feel free to raise them to the Routing ADs or Dave and I. -- Jeff From glen.kent@gmail.com Wed Jun 16 17:31:24 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342853A682E for ; Wed, 16 Jun 2010 17:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONgqboLoOEnF for ; Wed, 16 Jun 2010 17:31:22 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 1B0C13A67B5 for ; Wed, 16 Jun 2010 17:31:19 -0700 (PDT) Received: by gwj16 with SMTP id 16so4688145gwj.31 for ; Wed, 16 Jun 2010 17:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=2S9AKEsiISB9/QB4COL7rrgGcTED7mAXRkjvJV8IsWU=; b=Wvz3gb42yDGYK65O2XktkCUlfnWl+0yyfoONT5We+MHQmP5/ayFlm3qRDBFwB/9xQw ByvJYacGGiQ0IuAzsLB5gl5aabJ26ICaIw4K+2pMDY+4OpAzsFR3NkEyaR1/gxa0Xrrj H0eogtT4lk637cyI9zO+a4fgF868ivF1ye13M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=QJRW10LUkIZyOUzQnd0MWyvy0sgTp0kXapxFzYHY0mHu7ofjUdBwjtkPMX1MvYDXrY 5AsT5Pv5NveMGd+Z662pwLR0ECAo9b7zgpUA5i+nBFQlTPEGa3c0C4coNOOAHI+AnkG5 Bmc9446K/UdsScXeujeD+RW2c+MLx27MCyJD0= MIME-Version: 1.0 Received: by 10.101.105.22 with SMTP id h22mr7802141anm.35.1276734680646; Wed, 16 Jun 2010 17:31:20 -0700 (PDT) Received: by 10.100.4.3 with HTTP; Wed, 16 Jun 2010 17:31:20 -0700 (PDT) Date: Thu, 17 Jun 2010 06:01:20 +0530 Message-ID: Subject: Multiple BFD sessions and Discriminator From: Glen Kent To: rtg-bfd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 17 Jun 2010 00:31:24 -0000 Hi, If multiple BFD sessions exist on a LAN segment between two nodes, the BFD descriminator is used to demultiplex the BFD control packets to the appropriate BFD session. Given this I am unable to envisage a case where i will have multiple BFD sessions between the same set of nodes. Assume i have the following setup: Router A ---- Router B I am running BFD on the interface connecting the two routers I am running OSPF between them and its using BFD I have a static route on A for which the nexthop is B, and that too is covered using BFD. Is this the scenario where i will have multiple BFD sessions between the two sets of routers? What is the utility of having two sessions. Why cant just one session work. If BFD goes down, then it can locally inform both OSPF and the static route manager on A about this, so that router A can take the appropriate action. How does having multiple BFD sessions help? One reason that i can think of is, if the user wants different Rx and Tx intervals. However, this seems inane. Why would anybody want to detect one failure quicker than the other? Or is it that we only assume multiple BFD sessions between the same set of routers in case of multihop BFD? Glen From jhaas@slice.pfrc.org Wed Jun 16 17:50:51 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E4828C1B1 for ; Wed, 16 Jun 2010 17:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwxpVSO+iX5L for ; Wed, 16 Jun 2010 17:50:50 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 64F063A68F0 for ; Wed, 16 Jun 2010 17:50:50 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7D6652240C6; Thu, 17 Jun 2010 00:50:55 +0000 (UTC) Date: Thu, 17 Jun 2010 00:50:55 +0000 From: Jeffrey Haas To: Glen Kent Subject: Re: Multiple BFD sessions and Discriminator Message-ID: <20100617005055.GA12536@slice> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 17 Jun 2010 00:50:51 -0000 On Thu, Jun 17, 2010 at 06:01:20AM +0530, Glen Kent wrote: > Is this the scenario where i will have multiple BFD sessions between > the two sets of routers? You want RFC 5881, section 3. There will be one session between two systems over a given interface. RFC 5880, section 6.3 may also be helpful. > How does having multiple BFD sessions help? You would have one session between systems on a given interface for each address family. E.g. ipv4, ipv6. -- Jeff From dkatz@juniper.net Wed Jun 16 18:45:59 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A42E53A688E for ; Wed, 16 Jun 2010 18:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hMBUwZLxUbN for ; Wed, 16 Jun 2010 18:45:52 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 5F22E3A6784 for ; Wed, 16 Jun 2010 18:45:51 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTBl+UzZTY4mkp3Yh2ry0Fuo90rgMlU0H@postini.com; Wed, 16 Jun 2010 18:45:56 PDT Received: from p-emfe03-sac.jnpr.net (66.129.254.75) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Wed, 16 Jun 2010 18:42:20 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe03-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jun 2010 18:42:20 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jun 2010 18:42:19 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jun 2010 18:42:17 -0700 Received: from dkatz-sslvpn-nc.jnpr.net (dkatz-sslvpn-nc.jnpr.net [172.24.234.67]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o5H1gGb59666; Wed, 16 Jun 2010 18:42:16 -0700 (PDT) (envelope-from dkatz@juniper.net) Subject: Re: Multiple BFD sessions and Discriminator MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Dave Katz In-Reply-To: Date: Wed, 16 Jun 2010 18:42:16 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <98D6BDDE-A432-4738-8510-78F68B5B3C98@juniper.net> References: To: Glen Kent X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 17 Jun 2010 01:42:17.0744 (UTC) FILETIME=[51CBA900:01CB0DBE] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 17 Jun 2010 01:45:59 -0000 If you have separate V4 and V6 sessions, the two sessions are = demultiplexed first at the encapsulating data protocol (V4 vs. V6) so = they don't occupy the same namespace or any other universe. Each session protects the data protocol on top of which it runs, so in = this case, V4 and V6 have separate fate, as they should. You're exactly right about the reasons not to have multiple sessions = when running over the same L3 protocol (OSPF2 and v4 static routes, = etc.) --Dave On Jun 16, 2010, at 5:31 PM, Glen Kent wrote: > Hi, >=20 > If multiple BFD sessions exist on a LAN segment between two nodes, the > BFD descriminator is used to demultiplex the BFD control packets to > the appropriate BFD session. Given this I am unable to envisage a case > where i will have multiple BFD sessions between the same set of nodes. >=20 > Assume i have the following setup: >=20 > Router A ---- Router B >=20 > I am running BFD on the interface connecting the two routers > I am running OSPF between them and its using BFD > I have a static route on A for which the nexthop is B, and that too is > covered using BFD. >=20 > Is this the scenario where i will have multiple BFD sessions between > the two sets of routers? >=20 > What is the utility of having two sessions. Why cant just one session > work. If BFD goes down, then it can locally inform both OSPF and the > static route manager on A about this, so that router A can take the > appropriate action. >=20 > How does having multiple BFD sessions help? >=20 > One reason that i can think of is, if the user wants different Rx and > Tx intervals. However, this seems inane. Why would anybody want to > detect one failure quicker than the other? >=20 > Or is it that we only assume multiple BFD sessions between the same > set of routers in case of multihop BFD? >=20 > Glen >=20 From glen.kent@gmail.com Wed Jun 16 19:08:41 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91533A68B7 for ; Wed, 16 Jun 2010 19:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRVG+0IRLi2G for ; Wed, 16 Jun 2010 19:08:40 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id BC4173A67AF for ; Wed, 16 Jun 2010 19:08:40 -0700 (PDT) Received: by yxt33 with SMTP id 33so2334515yxt.31 for ; Wed, 16 Jun 2010 19:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=IAXyLHBuYIMz9oC3Ocyfa/3HnyJ0i+rPE6wEoDa9Ijc=; b=ROojH7e5rkEIUWDL0Fu8/nLoAn6lFREcf33Tfo9VlbLILqDyB4Ps/xl5+uzDfcfU3e eMM2re+PU1bIgk9+z9kPHLIhPTs4+Cmn4MF2fm9Z6mwNf718VE6WOicuPF6xOj8tlxrT glRdp/MXg6y4wxS8Lhcx1stcOW0BXNO9fTRPg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PltTKkA1nkgS+NCyIIbNdeN3rRTsGfpnR6nVCOcxKjdRc91wSjpv/XnX+N2tZXqBg7 7e/T6b6/WVJ2V/6hpr+hk/yqZGc5C0uJYAPbyw5rQrHWARTYIy56mka64rQcTk7iWUQz FhR8Zvn/G5hWDDbuB4VgowcokWRg9Fbdo9gUk= MIME-Version: 1.0 Received: by 10.101.133.38 with SMTP id k38mr7908617ann.162.1276740521149; Wed, 16 Jun 2010 19:08:41 -0700 (PDT) Received: by 10.100.4.3 with HTTP; Wed, 16 Jun 2010 19:08:41 -0700 (PDT) In-Reply-To: <98D6BDDE-A432-4738-8510-78F68B5B3C98@juniper.net> References: <98D6BDDE-A432-4738-8510-78F68B5B3C98@juniper.net> Date: Thu, 17 Jun 2010 07:38:41 +0530 Message-ID: Subject: Re: Multiple BFD sessions and Discriminator From: Glen Kent To: Dave Katz Content-Type: text/plain; charset=ISO-8859-1 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 17 Jun 2010 02:08:41 -0000 Hi Dave, Ok, so we dont need a discriminator to disambiguate between v4 and v6 directly connected sessions. We can thus infer that discriminator is really required *only* for multihop BFD sessions. Is this correct? And the reason its required there is because i could have, to cite one example, multiple LSPs from router A to router B and i would like to run BFD on each of these paths. Using the source IP and dest IP is not enough as this would be same for all the BFD packets over each of these paths, and hence the discriminator. On a single hop BFD, i can simply use the source IP and dest IP to disambiguate between different BFD sessions. Glen On Thu, Jun 17, 2010 at 7:12 AM, Dave Katz wrote: > If you have separate V4 and V6 sessions, the two sessions are demultiplexed first at the encapsulating data protocol (V4 vs. V6) so they don't occupy the same namespace or any other universe. > > Each session protects the data protocol on top of which it runs, so in this case, V4 and V6 have separate fate, as they should. > > You're exactly right about the reasons not to have multiple sessions when running over the same L3 protocol (OSPF2 and v4 static routes, etc.) > > --Dave > > > On Jun 16, 2010, at 5:31 PM, Glen Kent wrote: > >> Hi, >> >> If multiple BFD sessions exist on a LAN segment between two nodes, the >> BFD descriminator is used to demultiplex the BFD control packets to >> the appropriate BFD session. Given this I am unable to envisage a case >> where i will have multiple BFD sessions between the same set of nodes. >> >> Assume i have the following setup: >> >> Router A ---- Router B >> >> I am running BFD on the interface connecting the two routers >> I am running OSPF between them and its using BFD >> I have a static route on A for which the nexthop is B, and that too is >> covered using BFD. >> >> Is this the scenario where i will have multiple BFD sessions between >> the two sets of routers? >> >> What is the utility of having two sessions. Why cant just one session >> work. If BFD goes down, then it can locally inform both OSPF and the >> static route manager on A about this, so that router A can take the >> appropriate action. >> >> How does having multiple BFD sessions help? >> >> One reason that i can think of is, if the user wants different Rx and >> Tx intervals. However, this seems inane. Why would anybody want to >> detect one failure quicker than the other? >> >> Or is it that we only assume multiple BFD sessions between the same >> set of routers in case of multihop BFD? >> >> Glen >> > > From dkatz@juniper.net Wed Jun 16 20:28:50 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7488E3A69F2 for ; Wed, 16 Jun 2010 20:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.138 X-Spam-Level: X-Spam-Status: No, score=-4.138 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJVAA0EFBHvL for ; Wed, 16 Jun 2010 20:28:49 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 151613A6783 for ; Wed, 16 Jun 2010 20:28:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTBmWdBfDGxT0cXlXOcLmNHINqj2IFb5I@postini.com; Wed, 16 Jun 2010 20:28:54 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.2.254.0; Wed, 16 Jun 2010 20:25:53 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jun 2010 20:25:53 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jun 2010 20:25:53 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jun 2010 20:25:52 -0700 Received: from dkatz-sslvpn-nc.jnpr.net (dkatz-sslvpn-nc.jnpr.net [172.24.234.67]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o5H3Pnb62186; Wed, 16 Jun 2010 20:25:49 -0700 (PDT) (envelope-from dkatz@juniper.net) Subject: Re: Multiple BFD sessions and Discriminator MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Dave Katz In-Reply-To: Date: Wed, 16 Jun 2010 20:25:47 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <98D6BDDE-A432-4738-8510-78F68B5B3C98@juniper.net> To: Glen Kent X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 17 Jun 2010 03:25:52.0852 (UTC) FILETIME=[CA49E140:01CB0DCC] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 17 Jun 2010 03:28:50 -0000 On Jun 16, 2010, at 7:08 PM, Glen Kent wrote: > Hi Dave, >=20 > Ok, so we dont need a discriminator to disambiguate between v4 and v6 > directly connected sessions. We can thus infer that discriminator is > really required *only* for multihop BFD sessions. Is this correct? >=20 > And the reason its required there is because i could have, to cite one > example, multiple LSPs from router A to router B and i would like to > run BFD on each of these paths. >=20 > Using the source IP and dest IP is not enough as this would be same > for all the BFD packets over each of these paths, and hence the > discriminator. On a single hop BFD, i can simply use the source IP and > dest IP to disambiguate between different BFD sessions. This is true in some contexts (and you could add the input interface to = the list of demuxing values) but the base spec is very specific: Once the remote end echoes back the local discriminator, all further received packets are demultiplexed based on the Your Discriminator field only (which means that, among other things, the source address field can change or the interface over which the packets are received can change, but the packets will still be associated with the proper session). Once the discriminator value is established, it is the *only* thing used = to demultiplex the packet to the appropriate BFD session--not source or = destination address, and not input interface. This allows for almost = anything to change--the addresses, even the other guy's discriminator = value. You're free to change your own discriminator value, and the = other guy will parrot it back at you, and you can still demux your = packets. It is true that you could sort out one-hop sessions with other things = (you can't solely use the IP address because it could change if you're = talking over an unnumbered link, for example) but we chose to have a = single mechanism for simplicity--it is always the same, regardless of = application (one-hop, multihop, etc.), and medium (LAN, point-to-point.) = It also allows other things to change that might be outside the purview = of BFD (such as addresses). It also minimizes assumptions about the = encapsulation of the BFD packet, since it could be run in places other = than the network layer. As such, having a single, well-defined, = fully-contained mechanism to demultiplex packets was deemed critical. --Dave >=20 > Glen >=20 > On Thu, Jun 17, 2010 at 7:12 AM, Dave Katz wrote: >> If you have separate V4 and V6 sessions, the two sessions are = demultiplexed first at the encapsulating data protocol (V4 vs. V6) so = they don't occupy the same namespace or any other universe. >>=20 >> Each session protects the data protocol on top of which it runs, so = in this case, V4 and V6 have separate fate, as they should. >>=20 >> You're exactly right about the reasons not to have multiple sessions = when running over the same L3 protocol (OSPF2 and v4 static routes, = etc.) >>=20 >> --Dave >>=20 >>=20 >> On Jun 16, 2010, at 5:31 PM, Glen Kent wrote: >>=20 >>> Hi, >>>=20 >>> If multiple BFD sessions exist on a LAN segment between two nodes, = the >>> BFD descriminator is used to demultiplex the BFD control packets to >>> the appropriate BFD session. Given this I am unable to envisage a = case >>> where i will have multiple BFD sessions between the same set of = nodes. >>>=20 >>> Assume i have the following setup: >>>=20 >>> Router A ---- Router B >>>=20 >>> I am running BFD on the interface connecting the two routers >>> I am running OSPF between them and its using BFD >>> I have a static route on A for which the nexthop is B, and that too = is >>> covered using BFD. >>>=20 >>> Is this the scenario where i will have multiple BFD sessions between >>> the two sets of routers? >>>=20 >>> What is the utility of having two sessions. Why cant just one = session >>> work. If BFD goes down, then it can locally inform both OSPF and the >>> static route manager on A about this, so that router A can take the >>> appropriate action. >>>=20 >>> How does having multiple BFD sessions help? >>>=20 >>> One reason that i can think of is, if the user wants different Rx = and >>> Tx intervals. However, this seems inane. Why would anybody want to >>> detect one failure quicker than the other? >>>=20 >>> Or is it that we only assume multiple BFD sessions between the same >>> set of routers in case of multihop BFD? >>>=20 >>> Glen >>>=20 >>=20 >>=20 >=20 From jhaas@slice.pfrc.org Fri Jun 18 15:02:00 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FCEB3A68D3 for ; Fri, 18 Jun 2010 15:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJwbfWVo+0MI for ; Fri, 18 Jun 2010 15:01:59 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 6EAB53A69E4 for ; Fri, 18 Jun 2010 15:01:59 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6C6662240C5; Fri, 18 Jun 2010 22:02:05 +0000 (UTC) Date: Fri, 18 Jun 2010 22:02:05 +0000 From: Jeffrey Haas To: Dave Katz Subject: Re: New draft notification: draft-dz-bfd-extensions-for-vl-packets-00 Message-ID: <20100618220205.GF1484@slice> References: <41EF2177-5EA7-4469-AFAC-9E075E5299F6@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41EF2177-5EA7-4469-AFAC-9E075E5299F6@juniper.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jun 2010 22:02:00 -0000 [Commenting on an older thread as an individual contributor] On Tue, Mar 02, 2010 at 04:21:26PM -0800, Dave Katz wrote: > I'll have to examine the proposal carefully, but my first reaction is > that you can do most of this today without changing the protocol, by > simply padding the packets in which BFD is carried, without changing the > BFD header (or the receiving implementation) at all, since the spec only > requires that the BFD packet fit inside of whatever it is being carried > within (UDP, typically). For that matter, the spec would allow the BFD > packet itself to be padded (since only the lower bound of packet length > is supposed to be checked) but that would be more likely to run afoul of > out-of-spec implementations. I had made a similar comment in my last set of comments on the BFD base spec before it had gone to RFC. However, rather than utilizing the control packet mode to do this particular type of probing, I'd suggest instead that this is an excellent application of echo mode. As an example, echo packets could be exchanged at an initial small size, S. The detection multiplier for purposes of probing should be set to a relatively large value, e.g. 5. The payload of the echo packet would contain information that can be used to determine if a particular size of packet was successfully looped through the remote BFD speaker. For example, it could contain a 4 byte number of the number of bytes of the payload along with padding. The system then proceeds to probe the max size by transmitting one packet out of the 5 from the above example with a larger size at a given step interval. When the large packets are consistently lost due to excessive size, the size threshold has been determined. The actual threshold can be determined by bisecting the space. Practically speaking, this would also allow the system to have 2 types of detection: forwarding detection and large packet detection. It would be the transmitting system's prerogative to determine if it is going to call the large MTU path "down" or not. Since only 1:5 (per example) of the echo packets could be lost due to MTU the session should survive temporary loss of other-sized packets. -- Jeff From jhaas@slice.pfrc.org Fri Jun 18 16:55:45 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEE563A6A8F for ; Fri, 18 Jun 2010 16:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdY182-Q+-HD for ; Fri, 18 Jun 2010 16:55:45 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 26A363A69D7 for ; Fri, 18 Jun 2010 16:55:45 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 06BE822414E; Fri, 18 Jun 2010 23:55:50 +0000 (UTC) Date: Fri, 18 Jun 2010 23:55:50 +0000 From: Jeffrey Haas To: "Bhatia, Manav (Manav)" Subject: Re: FW: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt Message-ID: <20100618235550.GB2079@slice> References: <7C362EEF9C7896468B36C9B79200D8350CCF8FAFC0@INBANSXCHMBSA1.in.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CCF8FAFC0@INBANSXCHMBSA1.in.alcatel-lucent.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jun 2010 23:55:46 -0000 Manav, [Speaking as co-chair] We are discussing charter issues with our ADs right now and will likely be accepting new working group work items in the near future. On Fri, Jun 04, 2010 at 05:03:45AM +0530, Bhatia, Manav (Manav) wrote: > Now that we're done with the base specs can we get some feedback on this > draft? Most of the WGs in the ROUTING area have already moved to HMAC-SHA > and we would like BFD also to move from MD5 and keyed-SHA towards stronger > crypto algos. In addition to this, it also introduces two new generic > authentication types that can be used for specifying any auth algo for > BFD. Again nothing new and this is already in place for ISIS, OSPF, etc. [Speaking as an individual contributor] Your proposal seems reasonable. As I'm sure you're aware, much of the procedural review for your text describing HMAC will need help from outside of the BFD working group. I think the recommendation that SHA-256 being a MUST may be a bit too strong at this point in time. While I certainly wouldn't argue with a cryptographer about the weakness of the SHA-1/MD5 mechanisms, the level of protection we get out of them today is probably adequate for a while for BFD. Requiring SHA-256, especially with HMAC, may put too much of a burder on certain implementations over the shorter term. As such, I'd recommend that HMAC-SHA1 should be your MUST and that HMAC-256 should be a SHOULD. (Also, if I understand the algorithms correctly, SHA-2 is different enough implementation-wise from SHA-1 that hardware assist may require new silicon.) -- Jeff From manav.bhatia@alcatel-lucent.com Fri Jun 18 17:13:04 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD88B3A69DF for ; Fri, 18 Jun 2010 17:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.342 X-Spam-Level: X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[AWL=1.257, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9Bw5pyo0vu7 for ; Fri, 18 Jun 2010 17:13:03 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id A4F733A6A94 for ; Fri, 18 Jun 2010 17:13:03 -0700 (PDT) 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 o5J0D5D4001937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 Jun 2010 19:13:07 -0500 (CDT) 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 o5J0D4T8005950 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 19 Jun 2010 05:43:04 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Sat, 19 Jun 2010 05:43:04 +0530 From: "Bhatia, Manav (Manav)" To: Jeffrey Haas Date: Sat, 19 Jun 2010 05:43:02 +0530 Subject: RE: FW: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt Thread-Topic: FW: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt Thread-Index: AcsPQcsxebYn0eddT6K01Mk2P5Q2FgAADNhw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CCFC9EB8B@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CCF8FAFC0@INBANSXCHMBSA1.in.alcatel-lucent.com> <20100618235550.GB2079@slice> In-Reply-To: <20100618235550.GB2079@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-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 19 Jun 2010 00:13:04 -0000 Hi Jeff, =20 > Your proposal seems reasonable. As I'm sure you're aware, much of the > procedural review for your text describing HMAC will need help from > outside of the BFD working group. Sure.=20 Nothing really new here. We have already done this for OSPF in RFC 5709 and= IS-IS in RFC 5310. >=20 > I think the recommendation that SHA-256 being a MUST may be a=20 > bit too strong > at this point in time. While I certainly wouldn't argue with a > cryptographer about the weakness of the SHA-1/MD5 mechanisms,=20 > the level of > protection we get out of them today is probably adequate for=20 > a while for > BFD. Requiring SHA-256, especially with HMAC, may put too=20 > much of a burder > on certain implementations over the shorter term. As such,=20 > I'd recommend > that HMAC-SHA1 should be your MUST and that HMAC-256 should=20 > be a SHOULD. I agree with you that we could change HMAC-SHA1 as a MUST and HMAC-SHA256 a= s a SHOULD and all others as a MAY, however, it was while working on RFC 57= 09 that we changed the requirement for HMAC-256 from a SHOULD to a MUST bas= ed on the feedback that we received from the Security ADs.=20 Cheers, Manav From jhaas@slice.pfrc.org Fri Jun 18 17:37:09 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 311D43A67D0 for ; Fri, 18 Jun 2010 17:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.591 X-Spam-Level: X-Spam-Status: No, score=-0.591 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx8CZ8+JSr1i for ; Fri, 18 Jun 2010 17:37:08 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id BE2A13A63D3 for ; Fri, 18 Jun 2010 17:37:05 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B290A22415E; Sat, 19 Jun 2010 00:37:11 +0000 (UTC) Date: Sat, 19 Jun 2010 00:37:11 +0000 From: Jeffrey Haas To: "Bhatia, Manav (Manav)" Subject: Re: FW: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt Message-ID: <20100619003711.GA3075@slice> References: <7C362EEF9C7896468B36C9B79200D8350CCF8FAFC0@INBANSXCHMBSA1.in.alcatel-lucent.com> <20100618235550.GB2079@slice> <7C362EEF9C7896468B36C9B79200D8350CCFC9EB8B@INBANSXCHMBSA1.in.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CCFC9EB8B@INBANSXCHMBSA1.in.alcatel-lucent.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 19 Jun 2010 00:37:09 -0000 On Sat, Jun 19, 2010 at 05:43:02AM +0530, Bhatia, Manav (Manav) wrote: > I agree with you that we could change HMAC-SHA1 as a MUST and HMAC-SHA256 > as a SHOULD and all others as a MAY, however, it was while working on RFC > 5709 that we changed the requirement for HMAC-256 from a SHOULD to a MUST > based on the feedback that we received from the Security ADs. I understand the logic of the security ADs, but I think the result is potentially unfortunate. To agree with a prior post by Minto, I think we're likely to see deployment of SHA-2 based implementations lag the SHA-1 based implementation, but YMMV. It's only unfortunate in the sense that this may yield implementations that support multiple keys for SHA-1 but cannot support the MUST for the SHA-256 MAC. [Attn: Nobo, et al.] This incidentally reminds me: The change to need a index to select the key will have impacts on the MIB. In particular, this means that instead of having a single session key associated with the session, it will be necessary for the session to point to a key table of some form. > Cheers, Manav -- Jeff From manav.bhatia@alcatel-lucent.com Fri Jun 18 17:49:36 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D6B3A6873 for ; Fri, 18 Jun 2010 17:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gcqcmmUIMnD for ; Fri, 18 Jun 2010 17:49:35 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 099ED3A67D0 for ; Fri, 18 Jun 2010 17:49:34 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o5J0nXrx013733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 Jun 2010 19:49:35 -0500 (CDT) 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 o5J0nWK9006496 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 19 Jun 2010 06:19:32 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sat, 19 Jun 2010 06:19:32 +0530 From: "Bhatia, Manav (Manav)" To: Jeffrey Haas Date: Sat, 19 Jun 2010 06:19:30 +0530 Subject: RE: FW: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt Thread-Topic: FW: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt Thread-Index: AcsPR5EhbvB3SrnJTG+2bvc4GxrXCQAADgAQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CCFC9EB8C@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CCF8FAFC0@INBANSXCHMBSA1.in.alcatel-lucent.com> <20100618235550.GB2079@slice> <7C362EEF9C7896468B36C9B79200D8350CCFC9EB8B@INBANSXCHMBSA1.in.alcatel-lucent.com> <20100619003711.GA3075@slice> In-Reply-To: <20100619003711.GA3075@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 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 19 Jun 2010 00:49:36 -0000 Hi Jeff, =20 > On Sat, Jun 19, 2010 at 05:43:02AM +0530, Bhatia, Manav (Manav) wrote: > > I agree with you that we could change HMAC-SHA1 as a MUST=20 > and HMAC-SHA256 > > as a SHOULD and all others as a MAY, however, it was while=20 > working on RFC > > 5709 that we changed the requirement for HMAC-256 from a=20 > SHOULD to a MUST > > based on the feedback that we received from the Security ADs.=20 >=20 > I understand the logic of the security ADs, but I think the result is > potentially unfortunate. To agree with a prior post by=20 > Minto, I think we're > likely to see deployment of SHA-2 based implementations lag the SHA-1 > based implementation, but YMMV. It's only unfortunate in the=20 > sense that > this may yield implementations that support multiple keys for=20 > SHA-1 but > cannot support the MUST for the SHA-256 MAC. I think we can start with SHA1 as a MUST and SHA-256 as a SHOULD and all ot= hers as a MAY. Do you want me to respin a new version with these changes if= there are no further comments.=20 BTW given the current trend, we can expect that by the time this draft reac= hes the IESG most implementations would have anyways started work on moving= towards SHA2 (so we can flip the MUSTs and the SHOULDs then)!! ;-) This draft in addition to introducing HMAC-SHA also introduces a new generi= c authentication TLV that should be used for auth purposes. This way we don= 't need to get a new code point from IANA each time we add support for a ne= w algorithm and it also keeps some folks happy as we've minimized the amoun= t of information that we are exposing about the auth that BFD is currently = using. This would put BFD's authentication scheme inline with how its done for IS-= IS and OSPF currently. Cheers, Manav >=20 > [Attn: Nobo, et al.] > This incidentally reminds me: The change to need a index to=20 > select the key > will have impacts on the MIB. In particular, this means that=20 > instead of > having a single session key associated with the session, it will be > necessary for the session to point to a key table of some form. >=20 > > Cheers, Manav >=20 > -- Jeff > = From nobo@cisco.com Sat Jun 19 07:04:08 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793583A69DA for ; Sat, 19 Jun 2010 07:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLbp+kblOVyu for ; Sat, 19 Jun 2010 07:04:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B25843A68AE for ; Sat, 19 Jun 2010 07:04:07 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP9qHEyrR7Hu/2dsb2JhbACfGHGnM5lvhRsEg1Q X-IronPort-AV: E=Sophos;i="4.53,444,1272844800"; d="scan'208";a="262703334" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 19 Jun 2010 14:04:13 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o5JE4EK1024485; Sat, 19 Jun 2010 14:04:14 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); Sat, 19 Jun 2010 07:04:13 -0700 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: FW: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt Date: Sat, 19 Jun 2010 07:04:10 -0700 Message-ID: In-Reply-To: <20100619003711.GA3075@slice> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt Thread-Index: AcsPR4/74ZACwfrvSX62C3sAwXw0wwAb+TuA References: <7C362EEF9C7896468B36C9B79200D8350CCF8FAFC0@INBANSXCHMBSA1.in.alcatel-lucent.com> <20100618235550.GB2079@slice> <7C362EEF9C7896468B36C9B79200D8350CCFC9EB8B@INBANSXCHMBSA1.in.alcatel-lucent.com> <20100619003711.GA3075@slice> From: "Nobo Akiya (nobo)" To: "Jeffrey Haas" , "Bhatia, Manav (Manav)" X-OriginalArrivalTime: 19 Jun 2010 14:04:13.0887 (UTC) FILETIME=[4C4F84F0:01CB0FB8] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 19 Jun 2010 14:04:08 -0000 Hello Jeffrey, Manav,=20 > [Attn: Nobo, et al.] > This incidentally reminds me: The change to need a index to=20 > select the key will have impacts on the MIB. In particular,=20 > this means that instead of having a single session key=20 > associated with the session, it will be necessary for the=20 > session to point to a key table of some form. This has been brought up in the past, and consensus at the time swayed towards nay. Let me take this offline and discuss with couple of folks first. Thanx, Nobo