From mach@huawei.com Fri Sep 18 20:27:15 2009 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 EF6CC3A68CC for ; Fri, 18 Sep 2009 20:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.083 X-Spam-Level: * X-Spam-Status: No, score=1.083 tagged_above=-999 required=5 tests=[AWL=-1.023, 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 Vi8no-Uhn0-G for ; Fri, 18 Sep 2009 20:27:15 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 21D8C3A6824 for ; Fri, 18 Sep 2009 20:27:15 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ700MGN8AJBU@szxga01-in.huawei.com> for rtg-bfd@ietf.org; Sat, 19 Sep 2009 11:27:56 +0800 (CST) Received: from m55527c ([10.111.12.100]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ700FO58AH2F@szxga01-in.huawei.com> for rtg-bfd@ietf.org; Sat, 19 Sep 2009 11:27:55 +0800 (CST) Date: Sat, 19 Sep 2009 11:27:45 +0800 From: Mach Chen Subject: Multiple BFD sessions over one path To: 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=gb2312; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal 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 Sep 2009 03:27:16 -0000 Hi, After reading the two drafts (draft-ietf-bfd-generic-05 and draft-ietf-bfd-v4v6-1hop-09), I have some confusion about the session limitation over a specific network-layer path. Section 2 of draft-ietf-bfd-v4v6-1hop-09 says: "Each BFD session between a pair of systems MUST traverse a separate network-layer path in both directions..." But section 6 of draft-ietf-bfd-generic-05 says: "...if multiple differentiated services [DIFFSERV] are being operated over IPv4, an independent BFD session may be run for each service level...", this implicates that there may be mulitiple BFD sessions over one network-layer(ipv4) path, but it seems that this is not allowed in draft-ietf-bfd-v4v6-1hop-09. How to understand this conflict? or do I miss something? Best regards, Mach Chen From dkatz@juniper.net Fri Sep 18 23:40:41 2009 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 5940D3A6407 for ; Fri, 18 Sep 2009 23:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 X4qumeu7MkjG for ; Fri, 18 Sep 2009 23:40:40 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id E12AB3A63D3 for ; Fri, 18 Sep 2009 23:40:39 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSrR9Gqr3Z2Nph8gXIQKjrNX4gW1ZwaCo@postini.com; Fri, 18 Sep 2009 23:41:36 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.1.375.2; Fri, 18 Sep 2009 23:40:01 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2009 23:40:01 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2009 23:40:00 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2009 23:39: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 n8J6dx027486; Fri, 18 Sep 2009 23:39:59 -0700 (PDT) (envelope-from dkatz@juniper.net) From: Dave Katz To: Mach Chen In-Reply-To: Subject: Re: Multiple BFD sessions over one path X-Priority: 3 References: Message-ID: <52B6048D-137E-4B97-A688-686134B32D92@juniper.net> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Date: Sat, 19 Sep 2009 00:39:58 -0600 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Sep 2009 06:39:59.0977 (UTC) FILETIME=[0291DD90:01CA38F4] 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 Sep 2009 06:40:41 -0000 The point of the text in 1hop is that there isn't any use in having more than one session over a "path", and in any case it can't be done because there would be no way to demultiplex the initial packet of multiple sessions on the same "path" (because the first packet carries discriminator 0). But diffserv is essentially a tunnel of sorts; each service level has potentially different forwarding characteristics, so it may be useful to run BFD over more than one level (and the sessions can be demultiplexed because they are contextualized by the diffserv level). Essentially, each diffserv service level is considered to be a separate path, not unlike GRE or IPsec or what have you. Implementors are free to do as they please; the point of the text is to not preclude creative use of BFD where it can be useful. --Dave On Sep 18, 2009, at 9:27 PM, Mach Chen wrote: > Hi, > > After reading the two drafts (draft-ietf-bfd-generic-05 and draft- > ietf-bfd-v4v6-1hop-09), I have some confusion about the session > limitation over a specific network-layer path. > > Section 2 of draft-ietf-bfd-v4v6-1hop-09 says: > "Each BFD session between a pair of systems MUST traverse a separate > network-layer path in both directions..." > > But section 6 of draft-ietf-bfd-generic-05 says: > "...if multiple differentiated services [DIFFSERV] are being > operated over IPv4, an independent BFD session may be run for each > service level...", this implicates that there may be mulitiple BFD > sessions over one network-layer(ipv4) path, but it seems that this > is not allowed in draft-ietf-bfd-v4v6-1hop-09. How to understand > this conflict? or do I miss something? > > Best regards, > Mach Chen > > > > From mach@huawei.com Sat Sep 19 01:06:35 2009 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 A02093A6A42 for ; Sat, 19 Sep 2009 01:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.731 X-Spam-Level: X-Spam-Status: No, score=0.731 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 og981z1ehzOh for ; Sat, 19 Sep 2009 01:06:35 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CBBA23A6A37 for ; Sat, 19 Sep 2009 01:06:34 -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 <0KQ700AMDL887G@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Sat, 19 Sep 2009 16:07:20 +0800 (CST) Received: from m55527c ([10.111.12.100]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ700HE0L87FI@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Sat, 19 Sep 2009 16:07:20 +0800 (CST) Date: Sat, 19 Sep 2009 16:07:16 +0800 From: Mach Chen Subject: Re: Multiple BFD sessions over one path In-reply-to: <52B6048D-137E-4B97-A688-686134B32D92@juniper.net> To: Dave Katz Message-id: <96CF4B519831459FAEE47FB142EE2BB0@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=response Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <52B6048D-137E-4B97-A688-686134B32D92@juniper.net> 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 Sep 2009 08:06:35 -0000 Hi Dave, Thanks for your response! Based on your explanation, the point is whether there is a way to demultiplex the initial patcket, if there is, means no need to limit the BFD sesion. So, IMHO, it's better to clarify this in 1hop(since the draft is still in IESG review state, seems not too late to do it:-). Have a good weekend! Best regards, Mach -------------------------------------------------- From: "Dave Katz" Sent: Saturday, September 19, 2009 2:39 PM To: "Mach Chen" Cc: Subject: Re: Multiple BFD sessions over one path > The point of the text in 1hop is that there isn't any use in having more > than one session over a "path", and in any case it can't be done because > there would be no way to demultiplex the initial packet of multiple > sessions on the same "path" (because the first packet carries > discriminator 0). > > But diffserv is essentially a tunnel of sorts; each service level has > potentially different forwarding characteristics, so it may be useful to > run BFD over more than one level (and the sessions can be demultiplexed > because they are contextualized by the diffserv level). > > Essentially, each diffserv service level is considered to be a separate > path, not unlike GRE or IPsec or what have you. > > Implementors are free to do as they please; the point of the text is to > not preclude creative use of BFD where it can be useful. > > --Dave > > > > On Sep 18, 2009, at 9:27 PM, Mach Chen wrote: > >> Hi, >> >> After reading the two drafts (draft-ietf-bfd-generic-05 and draft- >> ietf-bfd-v4v6-1hop-09), I have some confusion about the session >> limitation over a specific network-layer path. >> >> Section 2 of draft-ietf-bfd-v4v6-1hop-09 says: >> "Each BFD session between a pair of systems MUST traverse a separate >> network-layer path in both directions..." >> >> But section 6 of draft-ietf-bfd-generic-05 says: >> "...if multiple differentiated services [DIFFSERV] are being operated >> over IPv4, an independent BFD session may be run for each service >> level...", this implicates that there may be mulitiple BFD sessions over >> one network-layer(ipv4) path, but it seems that this is not allowed in >> draft-ietf-bfd-v4v6-1hop-09. How to understand this conflict? or do I >> miss something? >> >> Best regards, >> Mach Chen >> >> >> >> > From dkatz@juniper.net Sat Sep 19 02:10:23 2009 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 1FDC13A6926 for ; Sat, 19 Sep 2009 02:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 1OSBvCsiaLTc for ; Sat, 19 Sep 2009 02:10:22 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 1225C3A6963 for ; Sat, 19 Sep 2009 02:10:21 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSrSgNPlNlZXx8VsnXGCoglo/jL2PT3pm@postini.com; Sat, 19 Sep 2009 02:11: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.1.375.2; Sat, 19 Sep 2009 02:09:04 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 19 Sep 2009 02:09:04 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 19 Sep 2009 02:09:04 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 19 Sep 2009 02:09:03 -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 n8J993035616; Sat, 19 Sep 2009 02:09:03 -0700 (PDT) (envelope-from dkatz@juniper.net) From: Dave Katz To: Mach Chen In-Reply-To: <96CF4B519831459FAEE47FB142EE2BB0@m55527c> Subject: Re: Multiple BFD sessions over one path X-Priority: 3 References: <52B6048D-137E-4B97-A688-686134B32D92@juniper.net> <96CF4B519831459FAEE47FB142EE2BB0@m55527c> Message-ID: <989F4C42-6F46-4BC0-8E37-F928BFA6F955@juniper.net> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Date: Sat, 19 Sep 2009 03:09:02 -0600 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Sep 2009 09:09:03.0677 (UTC) FILETIME=[D56E2ED0:01CA3908] 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 Sep 2009 09:10:23 -0000 But the point is that, the way 1hop is specified, there is *no* way to demultiplex the initial packet--thus the requirement. The only mechanism for multiple sessions is to have multiple paths, with one session per path. A "path" ends up with the somewhat reflexive definition of "something you can demultiplex by." As such, I believe that the language in the two drafts is proper. --Dave On Sep 19, 2009, at 2:07 AM, Mach Chen wrote: > Hi Dave, > > Thanks for your response! > > Based on your explanation, the point is whether there is a way to > demultiplex the initial patcket, if there is, means no need to limit > the BFD sesion. So, IMHO, it's better to clarify this in 1hop(since > the draft is still in IESG review state, seems not too late to do > it:-). > > Have a good weekend! > > Best regards, > Mach > > > -------------------------------------------------- > From: "Dave Katz" > Sent: Saturday, September 19, 2009 2:39 PM > To: "Mach Chen" > Cc: > Subject: Re: Multiple BFD sessions over one path > >> The point of the text in 1hop is that there isn't any use in >> having more than one session over a "path", and in any case it >> can't be done because there would be no way to demultiplex the >> initial packet of multiple sessions on the same "path" (because >> the first packet carries discriminator 0). >> >> But diffserv is essentially a tunnel of sorts; each service level >> has potentially different forwarding characteristics, so it may be >> useful to run BFD over more than one level (and the sessions can >> be demultiplexed because they are contextualized by the diffserv >> level). >> >> Essentially, each diffserv service level is considered to be a >> separate path, not unlike GRE or IPsec or what have you. >> >> Implementors are free to do as they please; the point of the text >> is to not preclude creative use of BFD where it can be useful. >> >> --Dave >> From vishwas.ietf@gmail.com Sat Sep 19 13:40:07 2009 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 505AD3A68C6 for ; Sat, 19 Sep 2009 13:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 P-iHrau4nxKw for ; Sat, 19 Sep 2009 13:40:04 -0700 (PDT) Received: from mail-yw0-f192.google.com (mail-yw0-f192.google.com [209.85.211.192]) by core3.amsl.com (Postfix) with ESMTP id 9A23C3A689D for ; Sat, 19 Sep 2009 13:40:03 -0700 (PDT) Received: by ywh30 with SMTP id 30so2550927ywh.31 for ; Sat, 19 Sep 2009 13:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MWg6pBzy/4T3Cdn75hpzPin/0zvstQo2UXgXNXxqIqY=; b=csUlCvAiub2+nIkLwzndFD5tXwjOgJYdxri5cY+ErISb627NNbbtVCh79G1EE3zhCp zP8xJkwNmt/br9SRIm7uR2IUatSYFlP2k+RDSJeTNC6YLAcX9dvk01r4R96/5YRee6EB Ib6LBBYI0b4OxlQxjUtkY731opYaXbQIYDepM= 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=VFCFACYfznpkuawPW+hstA7cP4Z3wpcVBkKq1jL56tgzmXp8cOnu4iIao6HdyAgIDx ilckMF+6eDj/1e++DoBUJ11xxI7NNVxZiz4507K9OP8+lAZeCb9G1Td9/xSYDjZ+ezgr ALD6WTVXcIocc7WUrnGOx+lieOnOzyyd4il9k= MIME-Version: 1.0 Received: by 10.150.239.15 with SMTP id m15mr5635735ybh.109.1253392857185; Sat, 19 Sep 2009 13:40:57 -0700 (PDT) In-Reply-To: <989F4C42-6F46-4BC0-8E37-F928BFA6F955@juniper.net> References: <52B6048D-137E-4B97-A688-686134B32D92@juniper.net> <96CF4B519831459FAEE47FB142EE2BB0@m55527c> <989F4C42-6F46-4BC0-8E37-F928BFA6F955@juniper.net> Date: Sat, 19 Sep 2009 13:40:57 -0700 Message-ID: <77ead0ec0909191340o5defdaf3g8cc28620d1b1adfa@mail.gmail.com> Subject: Re: Multiple BFD sessions over one path From: Vishwas Manral 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: Sat, 19 Sep 2009 20:40:07 -0000 Hi Dave, On Sat, Sep 19, 2009 at 2:09 AM, Dave Katz wrote: > But the point is that, the way 1hop is specified, there is *no* way to > demultiplex the initial packet--thus the requirement. Like in BFD for MPLS LSP's, if we have negotiated the session discriminator offline or have configured it statically we can demultiplex the first packets too. Thanks, Vishwas From dkatz@juniper.net Sat Sep 19 13:56:40 2009 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 4B08F3A6875 for ; Sat, 19 Sep 2009 13:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 X75G9fohSvcv for ; Sat, 19 Sep 2009 13:56:39 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 4DCBD3A684A for ; Sat, 19 Sep 2009 13:56:39 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSrVFvdCNsRl0yT4G1GMf7EHXsDnJgLAS@postini.com; Sat, 19 Sep 2009 13:57:37 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.1.375.2; Sat, 19 Sep 2009 13:54:22 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 19 Sep 2009 13:54:23 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 19 Sep 2009 13:54:22 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 19 Sep 2009 13:54:21 -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 n8JKsLM48340; Sat, 19 Sep 2009 13:54:21 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: From: Dave Katz To: Vishwas Manral In-Reply-To: <77ead0ec0909191340o5defdaf3g8cc28620d1b1adfa@mail.gmail.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: Multiple BFD sessions over one path Date: Sat, 19 Sep 2009 14:54:20 -0600 References: <52B6048D-137E-4B97-A688-686134B32D92@juniper.net> <96CF4B519831459FAEE47FB142EE2BB0@m55527c> <989F4C42-6F46-4BC0-8E37-F928BFA6F955@juniper.net> <77ead0ec0909191340o5defdaf3g8cc28620d1b1adfa@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Sep 2009 20:54:21.0741 (UTC) FILETIME=[5CF64DD0:01CA396B] 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 Sep 2009 20:56:40 -0000 The 1hop spec explicitly disallows this. This isn't to say that other applications are possible, but the point of the 1hop spec is to provide an interoperable baseline for a particular type of deployment. --Dave On Sep 19, 2009, at 2:40 PM, Vishwas Manral wrote: > Hi Dave, > > On Sat, Sep 19, 2009 at 2:09 AM, Dave Katz wrote: >> But the point is that, the way 1hop is specified, there is *no* way >> to >> demultiplex the initial packet--thus the requirement. > Like in BFD for MPLS LSP's, if we have negotiated the session > discriminator offline or have configured it statically we can > demultiplex the first packets too. > > Thanks, > Vishwas > From ldunbar@huawei.com Wed Sep 23 09:33:59 2009 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 4CA9A3A69DE for ; Wed, 23 Sep 2009 09:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[AWL=2.409, BAYES_00=-2.599, 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 XKnB8i5lQvYl for ; Wed, 23 Sep 2009 09:33:54 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id EFFE53A68A7 for ; Wed, 23 Sep 2009 09:33:53 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQF00JC0NEBOB@usaga02-in.huawei.com> for rtg-bfd@ietf.org; Wed, 23 Sep 2009 09:35:00 -0700 (PDT) Received: from L735042 ([10.124.12.51]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQF008C2NEBEV@usaga02-in.huawei.com> for rtg-bfd@ietf.org; Wed, 23 Sep 2009 09:34:59 -0700 (PDT) Date: Wed, 23 Sep 2009 11:34:58 -0500 From: Linda Dunbar Subject: How to enforce BFD to be sent over different paths between two systems? To: rtg-bfd@ietf.org, dkatz@juniper.com, dward@cisco.com Message-id: <006601ca3c6b$cab7a280$330c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_1cZFBBNht28q4mEdwiXYbQ)" Thread-index: Aco8a8pOPsowpBNPQ/m7PYkUq2PRqg== 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, 23 Sep 2009 16:33:59 -0000 This is a multi-part message in MIME format. --Boundary_(ID_1cZFBBNht28q4mEdwiXYbQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dave, I have some questions on "draft-ietf-bfd-base-09.txt". Hope you can help. 1. Section 3: 3rd line of the first paragraph states "A pair of systems transmit BFD packets periodically over each path between the two systems". Question: when there are multiple paths between two systems, do you mean to have multiple BFD sessions between those two systems, with each session covering individual path? How to enforce each path being traversed? 2. The Echo function is pretty much like "Ping". Each system can initiate a "Ping" to another system. Is "periodic Ping" an accurate description of the "Echo function"? 3. Section 4.1 under the "Control Plane Independent" sub-section: The first paragraph states "if clear, the transmitting system's BFD implementation share fate with its control plane". Question: When the transmitting system is running multiple routing protocols, more than one signaling schemes for different services, is it necessary to indicate which routing protocol and which signaling protocol? Actually, BFD is to test connectivity which can be up when the corresponding control plane is done. What is the reason to have BFD share fate with its transmitting system's control plane? 4. The BFD's Control Packet Format described in Section 4.1 has a bit field for Demand mode. Why not having a bit field for the other two modes (Async and Echo)? 5. Is the Discriminator field of the BFD' Control Packet Format same as unique identifier for particular BFD session from one system? Why not call it Identifier? Is it negotiated between the two systems? 6. Section 6.18.17 Concatenated Paths In transport network, Concatenated paths mean to combine (or bundle) multiple paths to form a bigger path which has higher bandwidth. Therefore, failure on one of the paths concatenated together will not cause connectivity problem for the two systems exchanging BFD. This failure will only cause the bandwidth of the concatenated path to be smaller. Do you mean that when one of the paths within a concatenated path fail, the BFD should indicate this partial failure of the concatenated path? 7. Editorial: Section 2 Design: 6th line of the first paragraph: "making it useful in concert with"? Is it a typo? Thank you very much for helping me. Best Regards, Linda Dunbar Advanced Technology Dept, Wireline Networks, Huawei Technologies, Inc. --Boundary_(ID_1cZFBBNht28q4mEdwiXYbQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dave,

 

I have some questions on “draft-ietf-bfd-base-09.txt”. Hope you can help.

 

  1. Section 3: 3rd line of the first paragraph states “A pair of systems transmit BFD packets periodically over each path between the two systems”.

 

Question: when there are multiple paths between two systems, do you mean to have multiple BFD sessions between those two systems, with each session covering individual path? How to enforce each path being traversed?

 

  1. The Echo function is pretty much like “Ping”. Each system can initiate a “Ping” to another system. Is “periodic Ping” an accurate description of the “Echo function”?

 

 

  1. Section 4.1 under the “Control Plane Independent” sub-section:

The first paragraph states “if clear, the transmitting system’s BFD implementation share fate with its control plane”.

Question: When the transmitting system is running multiple routing protocols, more than one signaling schemes for different services, is it necessary to indicate which routing protocol and which signaling protocol?    Actually, BFD is to test connectivity which can be up when the corresponding control plane is done. What is the reason to have BFD share fate with its transmitting system’s control plane?

 

  1. The BFD’s Control Packet Format described in Section 4.1 has a bit field for Demand mode. Why not having a bit field for the other two modes (Async and Echo)?

 

  1. Is the Discriminator field of the BFD’ Control Packet Format same as unique identifier for particular BFD session from one system? Why not call it Identifier? Is it negotiated between the two systems?

 

  1. Section 6.18.17 Concatenated Paths

In transport network, Concatenated paths mean to combine (or bundle) multiple paths to form a bigger path which has higher bandwidth. Therefore, failure on one of the paths concatenated together will not cause connectivity problem for the two systems exchanging BFD. This failure will only cause the bandwidth of the concatenated path to be smaller. Do you mean that when one of the paths within a concatenated path fail, the BFD should indicate this partial failure of the concatenated path?

 

  1. Editorial: Section 2 Design: 6th line of the first paragraph: “making it useful in concert with”? Is it a typo?

 

Thank you very much for helping me.

 

Best Regards, Linda Dunbar

Advanced Technology Dept, Wireline Networks,

Huawei Technologies, Inc.

 

--Boundary_(ID_1cZFBBNht28q4mEdwiXYbQ)-- From davari@broadcom.com Wed Sep 23 09:51:53 2009 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 33FC03A6906 for ; Wed, 23 Sep 2009 09:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, 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 YeMPBRSF1BtG for ; Wed, 23 Sep 2009 09:51:46 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 5C0173A686C for ; Wed, 23 Sep 2009 09:51:46 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 23 Sep 2009 09:52:39 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Wed, 23 Sep 2009 09:52:39 -0700 From: "Shahram Davari" To: "Linda Dunbar" , "rtg-bfd@ietf.org" , "dkatz@juniper.com" , "dward@cisco.com" Date: Wed, 23 Sep 2009 09:52:37 -0700 Subject: RE: How to enforce BFD to be sent over different paths between two systems? Thread-Topic: How to enforce BFD to be sent over different paths between two systems? Thread-Index: Aco8a8pOPsowpBNPQ/m7PYkUq2PRqgAAL1Ng Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6815751C5DC@SJEXCHCCR02.corp.ad.broadcom.com> References: <006601ca3c6b$cab7a280$330c7c0a@china.huawei.com> In-Reply-To: <006601ca3c6b$cab7a280$330c7c0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 66A48DDD5S418960034-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6815751C5DCSJEXCHCCR02co_ 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, 23 Sep 2009 16:51:53 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6815751C5DCSJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Linda, I am sure Dave will answer these questions better that I do, but let me giv= e you my 2c inline. Regards, Shahram ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Linda Dunbar Sent: Wednesday, September 23, 2009 9:35 AM To: rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com Subject: How to enforce BFD to be sent over different paths between two sys= tems? Dave, I have some questions on "draft-ietf-bfd-base-09.txt". Hope you can help. 1. Section 3: 3rd line of the first paragraph states "A pair of systems t= ransmit BFD packets periodically over each path between the two systems". Question: when there are multiple paths between two systems, do you mean to= have multiple BFD sessions between those two systems, with each session co= vering individual path? How to enforce each path being traversed? SD> For example there can be multiple LSPs between two systems and you need= to run BFD separately on each LSP. 1. The Echo function is pretty much like "Ping". Each system can initiate= a "Ping" to another system. Is "periodic Ping" an accurate description of = the "Echo function"? SD> Your understanding is correct. But note that Echo packets are not BFD = packets. BFD just negotiates the Echo interval. 1. Section 4.1 under the "Control Plane Independent" sub-section: The first paragraph states "if clear, the transmitting system's BFD impleme= ntation share fate with its control plane". Question: When the transmitting system is running multiple routing protocol= s, more than one signaling schemes for different services, is it necessary = to indicate which routing protocol and which signaling protocol? Actuall= y, BFD is to test connectivity which can be up when the corresponding contr= ol plane is done. What is the reason to have BFD share fate with its transm= itting system's control plane? SD> Every LSP or PW or tunnel that runs BFD could be setup using an instanc= e of control plane. We don't care about the control plane of the client or= server layers. What this bit indicates is the control-plane for the layer = you are running the BFD on. 1. The BFD's Control Packet Format described in Section 4.1 has a bit fie= ld for Demand mode. Why not having a bit field for the other two modes (Asy= nc and Echo)? SD> If D=3D0 it means Async mode. For Echo, if a system does not want t= o receive Echo it can set "Required Min Echo RX Interval " =3D 0 . And the= re is not need to signal that you want to Tx Echo. 1. Is the Discriminator field of the BFD' Control Packet Format same as u= nique identifier for particular BFD session from one system? Why not call i= t Identifier? Is it negotiated between the two systems? SD> the Discr is a locally unique number (not globally) very similar to = an LSP MPLS label that is distributed from a downstream node. It it not neg= otiated. 1. Section 6.18.17 Concatenated Paths In transport network, Concatenated paths mean to combine (or bundle) multip= le paths to form a bigger path which has higher bandwidth. Therefore, failu= re on one of the paths concatenated together will not cause connectivity pr= oblem for the two systems exchanging BFD. This failure will only cause the = bandwidth of the concatenated path to be smaller. Do you mean that when one= of the paths within a concatenated path fail, the BFD should indicate this= partial failure of the concatenated path? SD> As far as I know concatenated paths in transport networks mean stitchin= g two connections such as two LSPs. 1. Editorial: Section 2 Design: 6th line of the first paragraph: "making = it useful in concert with"? Is it a typo? Thank you very much for helping me. Best Regards, Linda Dunbar Advanced Technology Dept, Wireline Networks, Huawei Technologies, Inc. --_000_2C2F1EBA8050E74EA81502D5740B4BD6815751C5DCSJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hi=20 Linda,
 
I am=20 sure Dave will answer these questions better that I do, but let me give you= my=20 2c inline.
 
Regards,
Shahram

From: rtg-bfd-bounces@ietf.org=20 [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Linda=20 Dunbar
Sent: Wednesday, September 23, 2009 9:35 AM
To:= =20 rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com
Subject: How= to=20 enforce BFD to be sent over different paths between two=20 systems?

Dave,

 

I have some questions on=20 “draft-ietf-bfd-base-09.txt”. Hope you can help.

 

  1. <= SPAN=20 style=3D"FONT-SIZE: 12pt; FONT-FAMILY: Arial">Section 3: 3rd l= ine of=20 the first paragraph states “A pair of systems transmit BFD packets= =20 periodically over each path between the two systems”.  
    2. =
 
&nbs= p;

Question: when there are mult= iple=20 paths between two systems, do you mean to have multiple BFD sessions betwee= n=20 those two systems, with each session covering individual path? How to enfor= ce=20 each path being traversed?  

 

SD> For example there can= be=20 multiple LSPs between two systems and you need to run BFD separately on eac= h=20 LSP.  

 

  1. <= SPAN=20 style=3D"FONT-SIZE: 12pt; FONT-FAMILY: Arial">The Echo function is pretty= much=20 like “Ping”. Each system c= an initiate a=20 “Ping” to another system. = Is “periodic=20 Ping” an accurate description of= the “Echo=20 function”?  
    2. =
  
 SD> Your understand= ing is=20 correct. But note that Echo packets are not BFD packets. BFD just negotiate= s the=20 Echo interval.

 

 

  1. Section 4.1 = under the=20 “Control Plane Independent” sub-section:

The first paragraph states &#= 8220;if=20 clear, the transmitting system’s BFD implementation share fate with i= ts control=20 plane”.

Question: When the transmitti= ng=20 system is running multiple routing protocols, more than one signaling schem= es=20 for different services, is it necessary to indicate which routing protocol = and=20 which signaling protocol?    Actually, BFD is to test=20 connectivity which can be up when the corresponding control plane is done. = What=20 is the reason to have BFD share fate with its transmitting system’s c= ontrol=20 plane?  

 

SD> Every LSP or PW or tu= nnel that=20 runs BFD could be setup using an instance of control plane.  We d= on't=20 care about the control plane of the client or server layers. What this bit= =20 indicates is the control-plane for the layer you are running the BFD=20 on.

 

  1. <= SPAN=20 style=3D"FONT-SIZE: 12pt; FONT-FAMILY: Arial">The BFD’s Control Pac= ket Format=20 described in Section 4.1 has a bit field for Demand mode. Why not having = a bit=20 field for the other two modes (Async and Echo)?  
    2. =
   = ;=20 SD> If D=3D0 it means Async mode. For Echo, if a system does n= ot want=20 to receive Echo it can set  "Required Min Echo RX Interval&nbs= p;" =3D=20 0 . And there is not need to signal that you want to Tx=20 Echo.

 

  1. <= SPAN=20 style=3D"FONT-SIZE: 12pt; FONT-FAMILY: Arial">Is the Discriminator field = of the=20 BFD’ Control Packet Format same as unique identifier for particular= BFD=20 session from one system? Why not call it Identifier? Is it negotiated bet= ween=20 the two systems?  
    2. =
   SD> the Disc= r is=20 a locally unique number (not globally) very similar to an LSP MPL= S=20 label that is distributed from a downstream node. It it not=20 negotiated.

 

  1. Section 6.18= .17=20 Concatenated Paths

In transport network, Concate= nated=20 paths mean to combine (or bundle) multiple paths to form a bigger path whic= h has=20 higher bandwidth. Therefore, failure on one of the paths concatenated toget= her=20 will not cause connectivity problem for the two systems exchanging BFD. Thi= s=20 failure will only cause the bandwidth of the concatenated path to be smalle= r. Do=20 you mean that when one of the paths within a concatenated path fail, the BF= D=20 should indicate this partial failure of the concatenated path?  

 

SD> As far as I know conc= atenated=20 paths in transport networks mean stitching two connections such a= s two=20 LSPs. 

 

  1. Editorial: S= ection 2=20 Design: 6th line of the first paragraph: “making it usef= ul in=20 concert with”? Is it a typo?

 

Thank you very much for helpi= ng me.=20

 

Best Regards, Linda=20 Dunbar

Advanced Techno= logy=20 Dept, Wireline Networks,

Huawei Technologies,=20 Inc.

 

--_000_2C2F1EBA8050E74EA81502D5740B4BD6815751C5DCSJEXCHCCR02co_-- From ldunbar@huawei.com Wed Sep 23 10:08:55 2009 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 286FC28C157 for ; Wed, 23 Sep 2009 10:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599, 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 fvriYZqZW9+W for ; Wed, 23 Sep 2009 10:08:37 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 40BCE3A6A5A for ; Wed, 23 Sep 2009 10:08:37 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQF00J4DP06OB@usaga02-in.huawei.com> for rtg-bfd@ietf.org; Wed, 23 Sep 2009 10:09:43 -0700 (PDT) Received: from L735042 ([10.124.12.51]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQF008YEP03EV@usaga02-in.huawei.com> for rtg-bfd@ietf.org; Wed, 23 Sep 2009 10:09:42 -0700 (PDT) Date: Wed, 23 Sep 2009 12:09:38 -0500 From: Linda Dunbar Subject: RE: How to enforce BFD to be sent over different paths between two systems? In-reply-to: <2C2F1EBA8050E74EA81502D5740B4BD6815751C5DC@SJEXCHCCR02.corp.ad.broadcom.com> To: 'Shahram Davari' , rtg-bfd@ietf.org, dkatz@juniper.net, dward@cisco.com Message-id: <008b01ca3c70$a39ed6a0$330c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_Ju/+Vxd/F1GPn82G7VCUtQ)" Thread-index: Aco8a8pOPsowpBNPQ/m7PYkUq2PRqgAAL1NgAAC2TdA= References: <006601ca3c6b$cab7a280$330c7c0a@china.huawei.com> <2C2F1EBA8050E74EA81502D5740B4BD6815751C5DC@SJEXCHCCR02.corp.ad.broadcom.com> 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, 23 Sep 2009 17:08:55 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Ju/+Vxd/F1GPn82G7VCUtQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Shahram, Thank you very much for the answers. Maybe some wording can be improved. For example, if the text says "transmitting BFD" over multiple paths, it is better to define what "path" means. To many people, especially people with transport network background, paths mean physical paths. Different LDP or LSP paths between two systems may not traverse all the paths between two systems. I understand that the intent of BFD is to let BFD run over various media. But the description of the protocol is under the assumption that BFD is running over a path which source can control, like LSP or LDP. For IP forwarding, the source can't control which path to traverse from A to B. It is up to intermediate nodes to choose a path. Linda Dunbar _____ From: Shahram Davari [mailto:davari@broadcom.com] Sent: Wednesday, September 23, 2009 11:53 AM To: Linda Dunbar; rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com Subject: RE: How to enforce BFD to be sent over different paths between two systems? Hi Linda, I am sure Dave will answer these questions better that I do, but let me give you my 2c inline. Regards, Shahram _____ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, September 23, 2009 9:35 AM To: rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com Subject: How to enforce BFD to be sent over different paths between two systems? Dave, I have some questions on "draft-ietf-bfd-base-09.txt". Hope you can help. 1. Section 3: 3rd line of the first paragraph states "A pair of systems transmit BFD packets periodically over each path between the two systems". Question: when there are multiple paths between two systems, do you mean to have multiple BFD sessions between those two systems, with each session covering individual path? How to enforce each path being traversed? SD> For example there can be multiple LSPs between two systems and you need to run BFD separately on each LSP. 2. The Echo function is pretty much like "Ping". Each system can initiate a "Ping" to another system. Is "periodic Ping" an accurate description of the "Echo function"? SD> Your understanding is correct. But note that Echo packets are not BFD packets. BFD just negotiates the Echo interval. 3. Section 4.1 under the "Control Plane Independent" sub-section: The first paragraph states "if clear, the transmitting system's BFD implementation share fate with its control plane". Question: When the transmitting system is running multiple routing protocols, more than one signaling schemes for different services, is it necessary to indicate which routing protocol and which signaling protocol? Actually, BFD is to test connectivity which can be up when the corresponding control plane is done. What is the reason to have BFD share fate with its transmitting system's control plane? SD> Every LSP or PW or tunnel that runs BFD could be setup using an instance of control plane. We don't care about the control plane of the client or server layers. What this bit indicates is the control-plane for the layer you are running the BFD on. 4. The BFD's Control Packet Format described in Section 4.1 has a bit field for Demand mode. Why not having a bit field for the other two modes (Async and Echo)? SD> If D=0 it means Async mode. For Echo, if a system does not want to receive Echo it can set "Required Min Echo RX Interval " = 0 . And there is not need to signal that you want to Tx Echo. 5. Is the Discriminator field of the BFD' Control Packet Format same as unique identifier for particular BFD session from one system? Why not call it Identifier? Is it negotiated between the two systems? SD> the Discr is a locally unique number (not globally) very similar to an LSP MPLS label that is distributed from a downstream node. It it not negotiated. 6. Section 6.18.17 Concatenated Paths In transport network, Concatenated paths mean to combine (or bundle) multiple paths to form a bigger path which has higher bandwidth. Therefore, failure on one of the paths concatenated together will not cause connectivity problem for the two systems exchanging BFD. This failure will only cause the bandwidth of the concatenated path to be smaller. Do you mean that when one of the paths within a concatenated path fail, the BFD should indicate this partial failure of the concatenated path? SD> As far as I know concatenated paths in transport networks mean stitching two connections such as two LSPs. 7. Editorial: Section 2 Design: 6th line of the first paragraph: "making it useful in concert with"? Is it a typo? Thank you very much for helping me. Best Regards, Linda Dunbar Advanced Technology Dept, Wireline Networks, Huawei Technologies, Inc. --Boundary_(ID_Ju/+Vxd/F1GPn82G7VCUtQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Shahram,

 

Thank you very much for the answers.

Maybe some wording can be improved. For example, if the text says “transmitting BFD” over multiple paths, it is better to define what “path” means. To many people, especially people with transport network background, paths mean physical paths. Different LDP or LSP paths between two systems may not traverse all the paths between two systems.

 

I understand that the intent of BFD is to let BFD run over various media. But the description of the protocol is under the assumption that BFD is running over a path which source can control, like LSP or LDP. For IP forwarding, the source can’t control which path to traverse from A to B. It is up to intermediate nodes to choose a path.  

 

 Linda Dunbar

 

From: Shahram Davari [mailto:davari@broadcom.com]
Sent: Wednesday, September 23, 2009 11:53 AM
To: Linda Dunbar; rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com
Subject: RE: How to enforce BFD to be sent over different paths between two systems?

 

Hi Linda,

 

I am sure Dave will answer these questions better that I do, but let me give you my 2c inline.

 

Regards,

Shahram

 

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, September 23, 2009 9:35 AM
To: rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com
Subject: How to enforce BFD to be sent over different paths between two systems?

Dave,

 

I have some questions on “draft-ietf-bfd-base-09.txt”. Hope you can help.

 

1.      Section 3: 3rd line of the first paragraph states “A pair of systems transmit BFD packets periodically over each path between the two systems”.  

 

 

Question: when there are multiple paths between two systems, do you mean to have multiple BFD sessions between those two systems, with each session covering individual path? How to enforce each path being traversed?  

 

SD> For example there can be multiple LSPs between two systems and you need to run BFD separately on each LSP.  

 

2.      The Echo function is pretty much like “Ping”. Each system can initiate a “Ping” to another system. Is “periodic Ping” an accurate description of the “Echo function”?  

  

 SD> Your understanding is correct. But note that Echo packets are not BFD packets. BFD just negotiates the Echo interval.

 

 

3.      Section 4.1 under the “Control Plane Independent” sub-section:

The first paragraph states “if clear, the transmitting system’s BFD implementation share fate with its control plane”.

Question: When the transmitting system is running multiple routing protocols, more than one signaling schemes for different services, is it necessary to indicate which routing protocol and which signaling protocol?    Actually, BFD is to test connectivity which can be up when the corresponding control plane is done. What is the reason to have BFD share fate with its transmitting system’s control plane?  

 

SD> Every LSP or PW or tunnel that runs BFD could be setup using an instance of control plane.  We don't care about the control plane of the client or server layers. What this bit indicates is the control-plane for the layer you are running the BFD on.

 

4.      The BFD’s Control Packet Format described in Section 4.1 has a bit field for Demand mode. Why not having a bit field for the other two modes (Async and Echo)?  

    SD> If D=0 it means Async mode. For Echo, if a system does not want to receive Echo it can set  "Required Min Echo RX Interval " = 0 . And there is not need to signal that you want to Tx Echo.

 

5.      Is the Discriminator field of the BFD’ Control Packet Format same as unique identifier for particular BFD session from one system? Why not call it Identifier? Is it negotiated between the two systems?  

   SD> the Discr is a locally unique number (not globally) very similar to an LSP MPLS label that is distributed from a downstream node. It it not negotiated.

 

6.      Section 6.18.17 Concatenated Paths

In transport network, Concatenated paths mean to combine (or bundle) multiple paths to form a bigger path which has higher bandwidth. Therefore, failure on one of the paths concatenated together will not cause connectivity problem for the two systems exchanging BFD. This failure will only cause the bandwidth of the concatenated path to be smaller. Do you mean that when one of the paths within a concatenated path fail, the BFD should indicate this partial failure of the concatenated path?  

 

SD> As far as I know concatenated paths in transport networks mean stitching two connections such as two LSPs. 

 

7.      Editorial: Section 2 Design: 6th line of the first paragraph: “making it useful in concert with”? Is it a typo?

 

Thank you very much for helping me.

 

Best Regards, Linda Dunbar

Advanced Technology Dept, Wireline Networks,

Huawei Technologies, Inc.

 

--Boundary_(ID_Ju/+Vxd/F1GPn82G7VCUtQ)-- From davari@broadcom.com Wed Sep 23 10:31:14 2009 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 6F43928C168 for ; Wed, 23 Sep 2009 10:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, 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 YdIa0WXRuT-c for ; Wed, 23 Sep 2009 10:30:36 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id EDFD83A6A4B for ; Wed, 23 Sep 2009 10:30:35 -0700 (PDT) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 23 Sep 2009 10:31:29 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Wed, 23 Sep 2009 10:31:29 -0700 From: "Shahram Davari" To: "Linda Dunbar" , "rtg-bfd@ietf.org" , "dkatz@juniper.net" , "dward@cisco.com" Date: Wed, 23 Sep 2009 10:31:28 -0700 Subject: RE: How to enforce BFD to be sent over different paths between two systems? Thread-Topic: How to enforce BFD to be sent over different paths between two systems? Thread-Index: Aco8a8pOPsowpBNPQ/m7PYkUq2PRqgAAL1NgAAC2TdAAAQ2AUA== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6815751C5EE@SJEXCHCCR02.corp.ad.broadcom.com> References: <006601ca3c6b$cab7a280$330c7c0a@china.huawei.com> <2C2F1EBA8050E74EA81502D5740B4BD6815751C5DC@SJEXCHCCR02.corp.ad.broadcom.com> <008b01ca3c70$a39ed6a0$330c7c0a@china.huawei.com> In-Reply-To: <008b01ca3c70$a39ed6a0$330c7c0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 66A484FB39G27909867-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6815751C5EESJEXCHCCR02co_ 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, 23 Sep 2009 17:31:14 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6815751C5EESJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Linda, That is correct. For IP there is only one path (shortest path) between two= systems. Regards, Shahram ________________________________ From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Wednesday, September 23, 2009 10:10 AM To: Shahram Davari; rtg-bfd@ietf.org; dkatz@juniper.net; dward@cisco.com Subject: RE: How to enforce BFD to be sent over different paths between two= systems? Hi Shahram, Thank you very much for the answers. Maybe some wording can be improved. For example, if the text says "transmit= ting BFD" over multiple paths, it is better to define what "path" means. To= many people, especially people with transport network background, paths me= an physical paths. Different LDP or LSP paths between two systems may not t= raverse all the paths between two systems. I understand that the intent of BFD is to let BFD run over various media. B= ut the description of the protocol is under the assumption that BFD is runn= ing over a path which source can control, like LSP or LDP. For IP forwardin= g, the source can't control which path to traverse from A to B. It is up to= intermediate nodes to choose a path. Linda Dunbar ________________________________ From: Shahram Davari [mailto:davari@broadcom.com] Sent: Wednesday, September 23, 2009 11:53 AM To: Linda Dunbar; rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com Subject: RE: How to enforce BFD to be sent over different paths between two= systems? Hi Linda, I am sure Dave will answer these questions better that I do, but let me giv= e you my 2c inline. Regards, Shahram ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Linda Dunbar Sent: Wednesday, September 23, 2009 9:35 AM To: rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com Subject: How to enforce BFD to be sent over different paths between two sys= tems? Dave, I have some questions on "draft-ietf-bfd-base-09.txt". Hope you can help. 1. Section 3: 3rd line of the first paragraph states "A pair of system= s transmit BFD packets periodically over each path between the two systems"= . Question: when there are multiple paths between two systems, do you mean to= have multiple BFD sessions between those two systems, with each session co= vering individual path? How to enforce each path being traversed? SD> For example there can be multiple LSPs between two systems and you need= to run BFD separately on each LSP. 2. The Echo function is pretty much like "Ping". Each system can initi= ate a "Ping" to another system. Is "periodic Ping" an accurate description = of the "Echo function"? SD> Your understanding is correct. But note that Echo packets are not BFD = packets. BFD just negotiates the Echo interval. 3. Section 4.1 under the "Control Plane Independent" sub-section: The first paragraph states "if clear, the transmitting system's BFD impleme= ntation share fate with its control plane". Question: When the transmitting system is running multiple routing protocol= s, more than one signaling schemes for different services, is it necessary = to indicate which routing protocol and which signaling protocol? Actuall= y, BFD is to test connectivity which can be up when the corresponding contr= ol plane is done. What is the reason to have BFD share fate with its transm= itting system's control plane? SD> Every LSP or PW or tunnel that runs BFD could be setup using an instanc= e of control plane. We don't care about the control plane of the client or= server layers. What this bit indicates is the control-plane for the layer = you are running the BFD on. 4. The BFD's Control Packet Format described in Section 4.1 has a bit = field for Demand mode. Why not having a bit field for the other two modes (= Async and Echo)? SD> If D=3D0 it means Async mode. For Echo, if a system does not want t= o receive Echo it can set "Required Min Echo RX Interval " =3D 0 . And the= re is not need to signal that you want to Tx Echo. 5. Is the Discriminator field of the BFD' Control Packet Format same a= s unique identifier for particular BFD session from one system? Why not cal= l it Identifier? Is it negotiated between the two systems? SD> the Discr is a locally unique number (not globally) very similar to = an LSP MPLS label that is distributed from a downstream node. It it not neg= otiated. 6. Section 6.18.17 Concatenated Paths In transport network, Concatenated paths mean to combine (or bundle) multip= le paths to form a bigger path which has higher bandwidth. Therefore, failu= re on one of the paths concatenated together will not cause connectivity pr= oblem for the two systems exchanging BFD. This failure will only cause the = bandwidth of the concatenated path to be smaller. Do you mean that when one= of the paths within a concatenated path fail, the BFD should indicate this= partial failure of the concatenated path? SD> As far as I know concatenated paths in transport networks mean stitchin= g two connections such as two LSPs. 7. Editorial: Section 2 Design: 6th line of the first paragraph: "maki= ng it useful in concert with"? Is it a typo? Thank you very much for helping me. Best Regards, Linda Dunbar Advanced Technology Dept, Wireline Networks, Huawei Technologies, Inc. --_000_2C2F1EBA8050E74EA81502D5740B4BD6815751C5EESJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hi=20 Linda,
 
That=20 is correct. For IP there is only one path (shortest path)  between two= =20 systems.
 
Regards,
Shahram

From: Linda Dunbar [mailto:ldunbar@huaw= ei.com]=20
Sent: Wednesday, September 23, 2009 10:10 AM
To: Shahr= am=20 Davari; rtg-bfd@ietf.org; dkatz@juniper.net; dward@cisco.com
Subject:= =20 RE: How to enforce BFD to be sent over different paths between two=20 systems?

Hi Shahram,=20

 

Thank you very m= uch for=20 the answers.

Maybe some wordi= ng can=20 be improved. For example, if the text says “transmitting BFD” o= ver multiple=20 paths, it is better to define what “path” means. To many people= , especially=20 people with transport network background, paths mean physical paths. Differ= ent=20 LDP or LSP paths between two systems may not traverse all the paths between= two=20 systems.

 

I understand tha= t the=20 intent of BFD is to let BFD run over various media. But the description of = the=20 protocol is under the assumption that BFD is running over a path which sour= ce=20 can control, like LSP or LDP. For IP forwarding, the source can’t con= trol which=20 path to traverse from A to B. It is up to intermediate nodes to choose a pa= th.=20  

 

 Linda=20 Dunbar

 

From: Shahram=20 Davari [mailto:davari@broadcom.com]
Sent: Wednesday, September 23, 2009 = 11:53=20 AM
To: Linda Dunbar;=20 rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com
Subject: RE: How to enforce BFD to b= e sent=20 over different paths between two systems?

 

H= i=20 Linda,

 

I= am sure=20 Dave will answer these questions better that I do, but let me give you my 2= c=20 inline.

 

Regards,<= /FONT>

Shahram

 

From:=20 rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, September 23, 2009 = 9:35=20 AM
To: rtg-bfd@ietf.org;= =20 dkatz@juniper.com; dward@cisco.com
Subject: How to enforce BFD to be se= nt over=20 different paths between two systems?

Dave,

 

I have some questions on=20 “draft-ietf-bfd-base-09.txt”. Hope you can help.

 

= 1.     =20 Section 3: 3rd line of the first pa= ragraph=20 states “A pair of systems transmit BFD packets periodically over each= path=20 between the two systems”.  

 

 

Question: when there are mult= iple=20 paths between two systems, do you mean to have multiple BFD sessions betwee= n=20 those two systems, with each session covering individual path? How to enfor= ce=20 each path being traversed?  

 

SD> For = example=20 there can be multiple LSPs between two systems and you need to run BFD=20 separately on each LSP.  

 

= 2.     =20 The Echo function is pretty much like “<= st1:place=20 w:st=3D"on">Ping”. Each system can initiate a “Ping” to another system. Is “periodic <= st1:place=20 w:st=3D"on">Ping” an accurate description of the “E= cho=20 function”?  

  

 SD>&nbs= p;Your=20 understanding is correct. But note that Echo packets are not BFD packets. B= FD=20 just negotiates the Echo interval.

 

 

= <= SPAN=20 style=3D"mso-list: Ignore">3.     =20 Section 4.1 under the “Control Plane Ind= ependent”=20 sub-section:

The first paragraph states &#= 8220;if=20 clear, the transmitting system’s BFD implementation share fate with i= ts control=20 plane”.

Question: When the transmitti= ng=20 system is running multiple routing protocols, more than one signaling schem= es=20 for different services, is it necessary to indicate which routing protocol = and=20 which signaling protocol?    Actually, BFD is to test=20 connectivity which can be up when the corresponding control plane is done. = What=20 is the reason to have BFD share fate with its transmitting system’s c= ontrol=20 plane?  

 

S= D>=20 Every LSP or PW or tunnel that runs BFD could be setup using an=20 instance of control plane.  We don't care about the control plane of t= he=20 client or server layers. What this bit indicates is the control-plane for t= he=20 layer you are running the BFD on.

 

= 4.     =20 The BFD’s Control Packet Format describe= d in Section=20 4.1 has a bit field for Demand mode. Why not having a bit field for the oth= er=20 two modes (Async and Echo)?  

  &nbs= p;=20 SD> If D=3D0 it means Async mode. For Echo, if a system does n= ot want=20 to receive Echo it can set  "Required Min Ech= o RX=20 Interval " =3D 0 . And there is not need to signal that you want = to Tx=20 Echo.

 

= 5.     =20 Is the Discriminator field of the BFD’ C= ontrol Packet=20 Format same as unique identifier for particular BFD session from one system= ? Why=20 not call it Identifier? Is it negotiated between the two=20 systems?  

  =20 SD> the Discr is a locally unique number (not globally) very=20 similar to an LSP MPLS label that is distributed from a downstrea= m=20 node. It it not negotiated.

 

= <= SPAN=20 style=3D"mso-list: Ignore">6.     =20 Section 6.18.17 Concatenated Paths=20

In transport network, Concate= nated=20 paths mean to combine (or bundle) multiple paths to form a bigger path whic= h has=20 higher bandwidth. Therefore, failure on one of the paths concatenated toget= her=20 will not cause connectivity problem for the two systems exchanging BFD. Thi= s=20 failure will only cause the bandwidth of the concatenated path to be smalle= r. Do=20 you mean that when one of the paths within a concatenated path fail, the BF= D=20 should indicate this partial failure of the concatenated=20 path?  

 

SD> As f= ar as I=20 know concatenated paths in transport networks mean stitching two= =20 connections such as two LSPs. 

 

= <= SPAN=20 style=3D"mso-list: Ignore">7.     =20 Editorial: Section 2 Design: 6th li= ne of=20 the first paragraph: “making it useful in concert with”? Is it = a typo?=20

 

Thank you very much for helpi= ng me.=20

 

Best Regards, Linda=20 Dunbar

= Advanced=20 Technology Dept, Wireline Networks,

Huawei Technologies,=20 Inc.

 

<= /HTML> --_000_2C2F1EBA8050E74EA81502D5740B4BD6815751C5EESJEXCHCCR02co_-- From vishwas.ietf@gmail.com Wed Sep 23 10:34:24 2009 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 364063A6988 for ; Wed, 23 Sep 2009 10:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 Ya+f6zVGQGl3 for ; Wed, 23 Sep 2009 10:34:23 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id C175E3A6AAC for ; Wed, 23 Sep 2009 10:34:22 -0700 (PDT) Received: by yxe30 with SMTP id 30so1214155yxe.29 for ; Wed, 23 Sep 2009 10:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y5LJhf5iAA4OIVLbu5o3xkvPOYgQFwAZ29ElV/I9gZI=; b=xSW0/NC6uLGGNi+LFw5FPe+UsFko5STS679YrG2cmoYiReKErglRQCO7HjrRBfqCNL NoZzs3H06IWJtycLV6MiEIYMXYMlwxtb3IbOjbwuPN0/0SqZ7OsArux+SomG/uaJP21i rp9lqKRR9J6659JwKwTrxyBqiQti4nv6J8N8g= 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=hQJ0BULHOUHf5gYizB48tq780jtlYVfwR8j51I72aqd9juPuRDEDVcR65ZvfG23x6b B5+LUrrNfAeLyZEgZXcH34OFiqEmFls/oOnKKBEmH3aDzdJ/tICKdXWdmUF20gPcEz0v ZJGAT9fuQLSy0FZY3nS3VpCyobx9tv0f2X3pI= MIME-Version: 1.0 Received: by 10.150.239.15 with SMTP id m15mr4489295ybh.336.1253727324882; Wed, 23 Sep 2009 10:35:24 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6815751C5EE@SJEXCHCCR02.corp.ad.broadcom.com> References: <006601ca3c6b$cab7a280$330c7c0a@china.huawei.com> <2C2F1EBA8050E74EA81502D5740B4BD6815751C5DC@SJEXCHCCR02.corp.ad.broadcom.com> <008b01ca3c70$a39ed6a0$330c7c0a@china.huawei.com> <2C2F1EBA8050E74EA81502D5740B4BD6815751C5EE@SJEXCHCCR02.corp.ad.broadcom.com> Date: Wed, 23 Sep 2009 10:35:24 -0700 Message-ID: <77ead0ec0909231035g31d58c0bq4ae325e251e94d69@mail.gmail.com> Subject: Re: How to enforce BFD to be sent over different paths between two systems? From: Vishwas Manral To: Shahram Davari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" , "dkatz@juniper.net" , "dward@cisco.com" 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, 23 Sep 2009 17:34:24 -0000 Hi Shahram, > That is correct. For IP there is only one path (shortest path) =A0between= two > systems. Except ofcourse for the ECMP case. Thanks, Vishwas > ________________________________ > From: Linda Dunbar [mailto:ldunbar@huawei.com] > Sent: Wednesday, September 23, 2009 10:10 AM > To: Shahram Davari; rtg-bfd@ietf.org; dkatz@juniper.net; dward@cisco.com > Subject: RE: How to enforce BFD to be sent over different paths between t= wo > systems? > > Hi Shahram, > > > > Thank you very much for the answers. > > Maybe some wording can be improved. For example, if the text says > =93transmitting BFD=94 over multiple paths, it is better to define what = =93path=94 > means. To many people, especially people with transport network backgroun= d, > paths mean physical paths. Different LDP or LSP paths between two systems > may not traverse all the paths between two systems. > > > > I understand that the intent of BFD is to let BFD run over various media. > But the description of the protocol is under the assumption that BFD is > running over a path which source can control, like LSP or LDP. For IP > forwarding, the source can=92t control which path to traverse from A to B= . It > is up to intermediate nodes to choose a path. > > > > =A0Linda Dunbar > > > > ________________________________ > > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Wednesday, September 23, 2009 11:53 AM > To: Linda Dunbar; rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com > Subject: RE: How to enforce BFD to be sent over different paths between t= wo > systems? > > > > Hi Linda, > > > > I am sure Dave will answer these questions better that I do, but let me g= ive > you my 2c inline. > > > > Regards, > > Shahram > > > > ________________________________ > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f > Of Linda Dunbar > Sent: Wednesday, September 23, 2009 9:35 AM > To: rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com > Subject: How to enforce BFD to be sent over different paths between two > systems? > > Dave, > > > > I have some questions on =93draft-ietf-bfd-base-09.txt=94. Hope you can h= elp. > > > > 1.=A0=A0=A0=A0=A0 Section 3: 3rd line of the first paragraph states =93A = pair of systems > transmit BFD packets periodically over each path between the two systems= =94. > > > > > > Question: when there are multiple paths between two systems, do you mean = to > have multiple BFD sessions between those two systems, with each session > covering individual path? How to enforce each path being traversed? > > > > SD>=A0For example there can be multiple LSPs between two systems and you = need > to run BFD separately on each LSP. > > > > 2.=A0=A0=A0=A0=A0 The Echo function is pretty much like =93Ping=94. Each = system can > initiate a =93Ping=94 to another system. Is =93periodic Ping=94 an accura= te > description of the =93Echo function=94? > > > > =A0SD>=A0Your understanding is correct. But note that Echo packets are no= t BFD > packets. BFD just negotiates the Echo interval. > > > > > > 3.=A0=A0=A0=A0=A0 Section 4.1 under the =93Control Plane Independent=94 s= ub-section: > > The first paragraph states =93if clear, the transmitting system=92s BFD > implementation share fate with its control plane=94. > > Question: When the transmitting system is running multiple routing > protocols, more than one signaling schemes for different services, is it > necessary to indicate which routing protocol and which signaling protocol= ? > =A0=A0=A0Actually, BFD is to test connectivity which can be up when the > corresponding control plane is done. What is the reason to have BFD share > fate with its transmitting system=92s control plane? > > > > SD> Every LSP or PW=A0or tunnel that runs BFD could be setup using=A0an i= nstance > of control plane. =A0We don't care about the control plane of the client = or > server layers. What this bit indicates is the control-plane for the layer > you are running the BFD on. > > > > 4.=A0=A0=A0=A0=A0 The BFD=92s Control Packet Format described in Section = 4.1 has a bit > field for Demand mode. Why not having a bit field for the other two modes > (Async and Echo)? > > =A0=A0=A0 SD>=A0If D=3D0 it means Async=A0mode. For Echo, if a system doe= s not want to > receive Echo it can set=A0 "Required Min Echo RX Interval=A0" =3D 0=A0. A= nd there is > not need to signal that you want to Tx Echo. > > > > 5.=A0=A0=A0=A0=A0 Is the Discriminator field of the BFD=92 Control Packet= Format same as > unique identifier for particular BFD session from one system? Why not cal= l > it Identifier? Is it negotiated between the two systems? > > =A0=A0 SD>=A0the Discr is a=A0locally unique number (not globally) very s= imilar to > an=A0LSP MPLS label=A0that is distributed from a downstream node.=A0It it= not > negotiated. > > > > 6.=A0=A0=A0=A0=A0 Section 6.18.17 Concatenated Paths > > In transport network, Concatenated paths mean to combine (or bundle) > multiple paths to form a bigger path which has higher bandwidth. Therefor= e, > failure on one of the paths concatenated together will not cause > connectivity problem for the two systems exchanging BFD. This failure wil= l > only cause the bandwidth of the concatenated path to be smaller. Do you m= ean > that when one of the paths within a concatenated path fail, the BFD shoul= d > indicate this partial failure of the concatenated path? > > > > SD>=A0As far as I know concatenated paths=A0in transport networks mean=A0= stitching > two connections such as two LSPs. > > > > 7.=A0=A0=A0=A0=A0 Editorial: Section 2 Design: 6th line of the first para= graph: > =93making it useful in concert with=94? Is it a typo? > > > > Thank you very much for helping me. > > > > Best Regards, Linda Dunbar > > Advanced Technology Dept, Wireline Networks, > > Huawei Technologies, Inc. > > From ldunbar@huawei.com Wed Sep 23 12:10:44 2009 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 AA4B93A67CC for ; Wed, 23 Sep 2009 12:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=0.803, BAYES_00=-2.599, 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 tnnEg799zvMn for ; Wed, 23 Sep 2009 12:10:34 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id ACA373A681E for ; Wed, 23 Sep 2009 12:10:34 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQF00A06UNGOB@usaga04-in.huawei.com> for rtg-bfd@ietf.org; Wed, 23 Sep 2009 14:11:41 -0500 (CDT) Received: from L735042 ([10.124.12.51]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQF00A2WUNC6W@usaga04-in.huawei.com> for rtg-bfd@ietf.org; Wed, 23 Sep 2009 14:11:40 -0500 (CDT) Date: Wed, 23 Sep 2009 14:11:36 -0500 From: Linda Dunbar Subject: RE: How to enforce BFD to be sent over different paths between two systems? In-reply-to: <2C2F1EBA8050E74EA81502D5740B4BD6815751C5EE@SJEXCHCCR02.corp.ad.broadcom.com> To: 'Shahram Davari' , rtg-bfd@ietf.org, dkatz@juniper.net, dward@cisco.com Message-id: <00a201ca3c81$ad690870$330c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_6RU4Vg/Wqo6k1QBlw0FzRw)" Thread-index: Aco8a8pOPsowpBNPQ/m7PYkUq2PRqgAAL1NgAAC2TdAAAQ2AUAADgZCg References: <006601ca3c6b$cab7a280$330c7c0a@china.huawei.com> <2C2F1EBA8050E74EA81502D5740B4BD6815751C5DC@SJEXCHCCR02.corp.ad.broadcom.com> <008b01ca3c70$a39ed6a0$330c7c0a@china.huawei.com> <2C2F1EBA8050E74EA81502D5740B4BD6815751C5EE@SJEXCHCCR02.corp.ad.broadcom.com> 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, 23 Sep 2009 19:10:44 -0000 This is a multi-part message in MIME format. --Boundary_(ID_6RU4Vg/Wqo6k1QBlw0FzRw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT There is also ECMP for IP forwarding. Linda _____ From: Shahram Davari [mailto:davari@broadcom.com] Sent: Wednesday, September 23, 2009 12:31 PM To: Linda Dunbar; rtg-bfd@ietf.org; dkatz@juniper.net; dward@cisco.com Subject: RE: How to enforce BFD to be sent over different paths between two systems? Hi Linda, That is correct. For IP there is only one path (shortest path) between two systems. Regards, Shahram _____ From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Wednesday, September 23, 2009 10:10 AM To: Shahram Davari; rtg-bfd@ietf.org; dkatz@juniper.net; dward@cisco.com Subject: RE: How to enforce BFD to be sent over different paths between two systems? Hi Shahram, Thank you very much for the answers. Maybe some wording can be improved. For example, if the text says "transmitting BFD" over multiple paths, it is better to define what "path" means. To many people, especially people with transport network background, paths mean physical paths. Different LDP or LSP paths between two systems may not traverse all the paths between two systems. I understand that the intent of BFD is to let BFD run over various media. But the description of the protocol is under the assumption that BFD is running over a path which source can control, like LSP or LDP. For IP forwarding, the source can't control which path to traverse from A to B. It is up to intermediate nodes to choose a path. Linda Dunbar _____ From: Shahram Davari [mailto:davari@broadcom.com] Sent: Wednesday, September 23, 2009 11:53 AM To: Linda Dunbar; rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com Subject: RE: How to enforce BFD to be sent over different paths between two systems? Hi Linda, I am sure Dave will answer these questions better that I do, but let me give you my 2c inline. Regards, Shahram _____ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, September 23, 2009 9:35 AM To: rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com Subject: How to enforce BFD to be sent over different paths between two systems? Dave, I have some questions on "draft-ietf-bfd-base-09.txt". Hope you can help. 1. Section 3: 3rd line of the first paragraph states "A pair of systems transmit BFD packets periodically over each path between the two systems". Question: when there are multiple paths between two systems, do you mean to have multiple BFD sessions between those two systems, with each session covering individual path? How to enforce each path being traversed? SD> For example there can be multiple LSPs between two systems and you need to run BFD separately on each LSP. 2. The Echo function is pretty much like "Ping". Each system can initiate a "Ping" to another system. Is "periodic Ping" an accurate description of the "Echo function"? SD> Your understanding is correct. But note that Echo packets are not BFD packets. BFD just negotiates the Echo interval. 3. Section 4.1 under the "Control Plane Independent" sub-section: The first paragraph states "if clear, the transmitting system's BFD implementation share fate with its control plane". Question: When the transmitting system is running multiple routing protocols, more than one signaling schemes for different services, is it necessary to indicate which routing protocol and which signaling protocol? Actually, BFD is to test connectivity which can be up when the corresponding control plane is done. What is the reason to have BFD share fate with its transmitting system's control plane? SD> Every LSP or PW or tunnel that runs BFD could be setup using an instance of control plane. We don't care about the control plane of the client or server layers. What this bit indicates is the control-plane for the layer you are running the BFD on. 4. The BFD's Control Packet Format described in Section 4.1 has a bit field for Demand mode. Why not having a bit field for the other two modes (Async and Echo)? SD> If D=0 it means Async mode. For Echo, if a system does not want to receive Echo it can set "Required Min Echo RX Interval " = 0 . And there is not need to signal that you want to Tx Echo. 5. Is the Discriminator field of the BFD' Control Packet Format same as unique identifier for particular BFD session from one system? Why not call it Identifier? Is it negotiated between the two systems? SD> the Discr is a locally unique number (not globally) very similar to an LSP MPLS label that is distributed from a downstream node. It it not negotiated. 6. Section 6.18.17 Concatenated Paths In transport network, Concatenated paths mean to combine (or bundle) multiple paths to form a bigger path which has higher bandwidth. Therefore, failure on one of the paths concatenated together will not cause connectivity problem for the two systems exchanging BFD. This failure will only cause the bandwidth of the concatenated path to be smaller. Do you mean that when one of the paths within a concatenated path fail, the BFD should indicate this partial failure of the concatenated path? SD> As far as I know concatenated paths in transport networks mean stitching two connections such as two LSPs. 7. Editorial: Section 2 Design: 6th line of the first paragraph: "making it useful in concert with"? Is it a typo? Thank you very much for helping me. Best Regards, Linda Dunbar Advanced Technology Dept, Wireline Networks, Huawei Technologies, Inc. --Boundary_(ID_6RU4Vg/Wqo6k1QBlw0FzRw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

There is also ECMP for IP forwarding.

 

Linda

 

From: Shahram Davari [mailto:davari@broadcom.com]
Sent: Wednesday, September 23, 2009 12:31 PM
To: Linda Dunbar; rtg-bfd@ietf.org; dkatz@juniper.net; dward@cisco.com
Subject: RE: How to enforce BFD to be sent over different paths between two systems?

 

Hi Linda,

 

That is correct. For IP there is only one path (shortest path)  between two systems.

 

Regards,

Shahram

 

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Wednesday, September 23, 2009 10:10 AM
To: Shahram Davari; rtg-bfd@ietf.org; dkatz@juniper.net; dward@cisco.com
Subject: RE: How to enforce BFD to be sent over different paths between two systems?

Hi Shahram,

 

Thank you very much for the answers.

Maybe some wording can be improved. For example, if the text says “transmitting BFD” over multiple paths, it is better to define what “path” means. To many people, especially people with transport network background, paths mean physical paths. Different LDP or LSP paths between two systems may not traverse all the paths between two systems.

 

I understand that the intent of BFD is to let BFD run over various media. But the description of the protocol is under the assumption that BFD is running over a path which source can control, like LSP or LDP. For IP forwarding, the source can’t control which path to traverse from A to B. It is up to intermediate nodes to choose a path.  

 

 Linda Dunbar

 

From: Shahram Davari [mailto:davari@broadcom.com]
Sent: Wednesday, September 23, 2009 11:53 AM
To: Linda Dunbar; rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com
Subject: RE: How to enforce BFD to be sent over different paths between two systems?

 

Hi Linda,

 

I am sure Dave will answer these questions better that I do, but let me give you my 2c inline.

 

Regards,

Shahram

 

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, September 23, 2009 9:35 AM
To: rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com
Subject: How to enforce BFD to be sent over different paths between two systems?

Dave,

 

I have some questions on “draft-ietf-bfd-base-09.txt”. Hope you can help.

 

1.      Section 3: 3rd line of the first paragraph states “A pair of systems transmit BFD packets periodically over each path between the two systems”.  

 

 

Question: when there are multiple paths between two systems, do you mean to have multiple BFD sessions between those two systems, with each session covering individual path? How to enforce each path being traversed?  

 

SD> For example there can be multiple LSPs between two systems and you need to run BFD separately on each LSP.  

 

2.      The Echo function is pretty much like “Ping”. Each system can initiate a “Ping” to another system. Is “periodic Ping” an accurate description of the “Echo function”?  

  

 SD> Your understanding is correct. But note that Echo packets are not BFD packets. BFD just negotiates the Echo interval.

 

 

3.      Section 4.1 under the “Control Plane Independent” sub-section:

The first paragraph states “if clear, the transmitting system’s BFD implementation share fate with its control plane”.

Question: When the transmitting system is running multiple routing protocols, more than one signaling schemes for different services, is it necessary to indicate which routing protocol and which signaling protocol?    Actually, BFD is to test connectivity which can be up when the corresponding control plane is done. What is the reason to have BFD share fate with its transmitting system’s control plane?  

 

SD> Every LSP or PW or tunnel that runs BFD could be setup using an instance of control plane.  We don't care about the control plane of the client or server layers. What this bit indicates is the control-plane for the layer you are running the BFD on.

 

4.      The BFD’s Control Packet Format described in Section 4.1 has a bit field for Demand mode. Why not having a bit field for the other two modes (Async and Echo)?  

    SD> If D=0 it means Async mode. For Echo, if a system does not want to receive Echo it can set  "Required Min Echo RX Interval " = 0 . And there is not need to signal that you want to Tx Echo.

 

5.      Is the Discriminator field of the BFD’ Control Packet Format same as unique identifier for particular BFD session from one system? Why not call it Identifier? Is it negotiated between the two systems?  

   SD> the Discr is a locally unique number (not globally) very similar to an LSP MPLS label that is distributed from a downstream node. It it not negotiated.

 

6.      Section 6.18.17 Concatenated Paths

In transport network, Concatenated paths mean to combine (or bundle) multiple paths to form a bigger path which has higher bandwidth. Therefore, failure on one of the paths concatenated together will not cause connectivity problem for the two systems exchanging BFD. This failure will only cause the bandwidth of the concatenated path to be smaller. Do you mean that when one of the paths within a concatenated path fail, the BFD should indicate this partial failure of the concatenated path?  

 

SD> As far as I know concatenated paths in transport networks mean stitching two connections such as two LSPs. 

 

7.      Editorial: Section 2 Design: 6th line of the first paragraph: “making it useful in concert with”? Is it a typo?

 

Thank you very much for helping me.

 

Best Regards, Linda Dunbar

Advanced Technology Dept, Wireline Networks,

Huawei Technologies, Inc.

 

--Boundary_(ID_6RU4Vg/Wqo6k1QBlw0FzRw)-- From mach@huawei.com Wed Sep 23 19:54:00 2009 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 C2F253A69F6 for ; Wed, 23 Sep 2009 19:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.031 X-Spam-Level: X-Spam-Status: No, score=0.031 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, 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 1aCQqTN8ZTpY for ; Wed, 23 Sep 2009 19:53:59 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 55D343A68B8 for ; Wed, 23 Sep 2009 19:53:45 -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 <0KQG00M25G34P3@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Thu, 24 Sep 2009 10:54:40 +0800 (CST) Received: from m55527c ([10.111.12.100]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQG00CT6G32QK@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Thu, 24 Sep 2009 10:54:40 +0800 (CST) Date: Thu, 24 Sep 2009 10:54:37 +0800 From: Mach Chen Subject: Re: How to enforce BFD to be sent over different paths between twosystems? In-reply-to: <77ead0ec0909231035g31d58c0bq4ae325e251e94d69@mail.gmail.com> To: Vishwas Manral , Shahram Davari Message-id: <75634DDF1614436FA4456B82E9D30337@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=windows-1252; reply-type=original Content-transfer-encoding: 8BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <006601ca3c6b$cab7a280$330c7c0a@china.huawei.com> <2C2F1EBA8050E74EA81502D5740B4BD6815751C5DC@SJEXCHCCR02.corp.ad.broadcom.com> <008b01ca3c70$a39ed6a0$330c7c0a@china.huawei.com> <2C2F1EBA8050E74EA81502D5740B4BD6815751C5EE@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec0909231035g31d58c0bq4ae325e251e94d69@mail.gmail.com> Cc: rtg-bfd@ietf.org, dkatz@juniper.net, dward@cisco.com 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, 24 Sep 2009 02:54:00 -0000 Hi, For LDP LSP, it also has the same ECMP issue. Could I say that BFD is suitable for any ECMP scenario? Best regards, Mach -------------------------------------------------- From: "Vishwas Manral" Sent: Thursday, September 24, 2009 1:35 AM To: "Shahram Davari" Cc: ; ; Subject: Re: How to enforce BFD to be sent over different paths between twosystems? > Hi Shahram, > >> That is correct. For IP there is only one path (shortest path) between >> two >> systems. > Except ofcourse for the ECMP case. > > Thanks, > Vishwas > >> ________________________________ >> From: Linda Dunbar [mailto:ldunbar@huawei.com] >> Sent: Wednesday, September 23, 2009 10:10 AM >> To: Shahram Davari; rtg-bfd@ietf.org; dkatz@juniper.net; dward@cisco.com >> Subject: RE: How to enforce BFD to be sent over different paths between >> two >> systems? >> >> Hi Shahram, >> >> >> >> Thank you very much for the answers. >> >> Maybe some wording can be improved. For example, if the text says >> “transmitting BFD” over multiple paths, it is better to define what >> “path” >> means. To many people, especially people with transport network >> background, >> paths mean physical paths. Different LDP or LSP paths between two systems >> may not traverse all the paths between two systems. >> >> >> >> I understand that the intent of BFD is to let BFD run over various media. >> But the description of the protocol is under the assumption that BFD is >> running over a path which source can control, like LSP or LDP. For IP >> forwarding, the source can’t control which path to traverse from A to B. >> It >> is up to intermediate nodes to choose a path. >> >> >> >> Linda Dunbar >> >> >> >> ________________________________ >> >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Wednesday, September 23, 2009 11:53 AM >> To: Linda Dunbar; rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com >> Subject: RE: How to enforce BFD to be sent over different paths between >> two >> systems? >> >> >> >> Hi Linda, >> >> >> >> I am sure Dave will answer these questions better that I do, but let me >> give >> you my 2c inline. >> >> >> >> Regards, >> >> Shahram >> >> >> >> ________________________________ >> >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On >> Behalf >> Of Linda Dunbar >> Sent: Wednesday, September 23, 2009 9:35 AM >> To: rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com >> Subject: How to enforce BFD to be sent over different paths between two >> systems? >> >> Dave, >> >> >> >> I have some questions on “draft-ietf-bfd-base-09.txt”. Hope you can help. >> >> >> >> 1. Section 3: 3rd line of the first paragraph states “A pair of >> systems >> transmit BFD packets periodically over each path between the two systems”. >> >> >> >> >> >> Question: when there are multiple paths between two systems, do you mean >> to >> have multiple BFD sessions between those two systems, with each session >> covering individual path? How to enforce each path being traversed? >> >> >> >> SD> For example there can be multiple LSPs between two systems and you >> need >> to run BFD separately on each LSP. >> >> >> >> 2. The Echo function is pretty much like “Ping”. Each system can >> initiate a “Ping” to another system. Is “periodic Ping” an accurate >> description of the “Echo function”? >> >> >> >> SD> Your understanding is correct. But note that Echo packets are not >> BFD >> packets. BFD just negotiates the Echo interval. >> >> >> >> >> >> 3. Section 4.1 under the “Control Plane Independent” sub-section: >> >> The first paragraph states “if clear, the transmitting system’s BFD >> implementation share fate with its control plane”. >> >> Question: When the transmitting system is running multiple routing >> protocols, more than one signaling schemes for different services, is it >> necessary to indicate which routing protocol and which signaling >> protocol? >> Actually, BFD is to test connectivity which can be up when the >> corresponding control plane is done. What is the reason to have BFD share >> fate with its transmitting system’s control plane? >> >> >> >> SD> Every LSP or PW or tunnel that runs BFD could be setup using an >> instance >> of control plane. We don't care about the control plane of the client or >> server layers. What this bit indicates is the control-plane for the layer >> you are running the BFD on. >> >> >> >> 4. The BFD’s Control Packet Format described in Section 4.1 has a >> bit >> field for Demand mode. Why not having a bit field for the other two modes >> (Async and Echo)? >> >> SD> If D=0 it means Async mode. For Echo, if a system does not want >> to >> receive Echo it can set "Required Min Echo RX Interval " = 0 . And there >> is >> not need to signal that you want to Tx Echo. >> >> >> >> 5. Is the Discriminator field of the BFD’ Control Packet Format same >> as >> unique identifier for particular BFD session from one system? Why not >> call >> it Identifier? Is it negotiated between the two systems? >> >> SD> the Discr is a locally unique number (not globally) very similar >> to >> an LSP MPLS label that is distributed from a downstream node. It it not >> negotiated. >> >> >> >> 6. Section 6.18.17 Concatenated Paths >> >> In transport network, Concatenated paths mean to combine (or bundle) >> multiple paths to form a bigger path which has higher bandwidth. >> Therefore, >> failure on one of the paths concatenated together will not cause >> connectivity problem for the two systems exchanging BFD. This failure >> will >> only cause the bandwidth of the concatenated path to be smaller. Do you >> mean >> that when one of the paths within a concatenated path fail, the BFD >> should >> indicate this partial failure of the concatenated path? >> >> >> >> SD> As far as I know concatenated paths in transport networks mean >> stitching >> two connections such as two LSPs. >> >> >> >> 7. Editorial: Section 2 Design: 6th line of the first paragraph: >> “making it useful in concert with”? Is it a typo? >> >> >> >> Thank you very much for helping me. >> >> >> >> Best Regards, Linda Dunbar >> >> Advanced Technology Dept, Wireline Networks, >> >> Huawei Technologies, Inc. >> >> > From mach@huawei.com Wed Sep 23 19:59:48 2009 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 740DE3A696F for ; Wed, 23 Sep 2009 19:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.044 X-Spam-Level: X-Spam-Status: No, score=-0.044 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 aX3yyqXgM0CK for ; Wed, 23 Sep 2009 19:59:47 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 23EE53A67FF for ; Wed, 23 Sep 2009 19:59:47 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQG0007XGD8B2@szxga01-in.huawei.com> for rtg-bfd@ietf.org; Thu, 24 Sep 2009 11:00:44 +0800 (CST) Received: from m55527c ([10.111.12.100]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQG00M3ZGD66V@szxga01-in.huawei.com> for rtg-bfd@ietf.org; Thu, 24 Sep 2009 11:00:44 +0800 (CST) Date: Thu, 24 Sep 2009 11:00:42 +0800 From: Mach Chen Subject: Re: How to enforce BFD to be sent over different paths betweentwosystems? In-reply-to: <75634DDF1614436FA4456B82E9D30337@m55527c> To: Mach Chen , Vishwas Manral , Shahram Davari 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=windows-1252; reply-type=response Content-transfer-encoding: 8BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <006601ca3c6b$cab7a280$330c7c0a@china.huawei.com> <2C2F1EBA8050E74EA81502D5740B4BD6815751C5DC@SJEXCHCCR02.corp.ad.broadcom.com> <008b01ca3c70$a39ed6a0$330c7c0a@china.huawei.com> <2C2F1EBA8050E74EA81502D5740B4BD6815751C5EE@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec0909231035g31d58c0bq4ae325e251e94d69@mail.gmail.com> <75634DDF1614436FA4456B82E9D30337@m55527c> Cc: rtg-bfd@ietf.org, dkatz@juniper.net, dward@cisco.com 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, 24 Sep 2009 02:59:48 -0000 Correct:-) "Suitable" should be "not suilable" -------------------------------------------------- From: "Mach Chen" Sent: Thursday, September 24, 2009 10:54 AM To: "Vishwas Manral" ; "Shahram Davari" Cc: ; ; Subject: Re: How to enforce BFD to be sent over different paths betweentwosystems? > Hi, > > For LDP LSP, it also has the same ECMP issue. > > Could I say that BFD is suitable for any ECMP scenario? > > Best regards, > Mach > > > -------------------------------------------------- > From: "Vishwas Manral" > Sent: Thursday, September 24, 2009 1:35 AM > To: "Shahram Davari" > Cc: ; ; > Subject: Re: How to enforce BFD to be sent over different paths between > twosystems? > >> Hi Shahram, >> >>> That is correct. For IP there is only one path (shortest path) between >>> two >>> systems. >> Except ofcourse for the ECMP case. >> >> Thanks, >> Vishwas >> >>> ________________________________ >>> From: Linda Dunbar [mailto:ldunbar@huawei.com] >>> Sent: Wednesday, September 23, 2009 10:10 AM >>> To: Shahram Davari; rtg-bfd@ietf.org; dkatz@juniper.net; dward@cisco.com >>> Subject: RE: How to enforce BFD to be sent over different paths between >>> two >>> systems? >>> >>> Hi Shahram, >>> >>> >>> >>> Thank you very much for the answers. >>> >>> Maybe some wording can be improved. For example, if the text says >>> “transmitting BFD” over multiple paths, it is better to define what >>> “path” >>> means. To many people, especially people with transport network >>> background, >>> paths mean physical paths. Different LDP or LSP paths between two >>> systems >>> may not traverse all the paths between two systems. >>> >>> >>> >>> I understand that the intent of BFD is to let BFD run over various >>> media. >>> But the description of the protocol is under the assumption that BFD is >>> running over a path which source can control, like LSP or LDP. For IP >>> forwarding, the source can’t control which path to traverse from A to B. >>> It >>> is up to intermediate nodes to choose a path. >>> >>> >>> >>> Linda Dunbar >>> >>> >>> >>> ________________________________ >>> >>> From: Shahram Davari [mailto:davari@broadcom.com] >>> Sent: Wednesday, September 23, 2009 11:53 AM >>> To: Linda Dunbar; rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com >>> Subject: RE: How to enforce BFD to be sent over different paths between >>> two >>> systems? >>> >>> >>> >>> Hi Linda, >>> >>> >>> >>> I am sure Dave will answer these questions better that I do, but let me >>> give >>> you my 2c inline. >>> >>> >>> >>> Regards, >>> >>> Shahram >>> >>> >>> >>> ________________________________ >>> >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On >>> Behalf >>> Of Linda Dunbar >>> Sent: Wednesday, September 23, 2009 9:35 AM >>> To: rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com >>> Subject: How to enforce BFD to be sent over different paths between two >>> systems? >>> >>> Dave, >>> >>> >>> >>> I have some questions on “draft-ietf-bfd-base-09.txt”. Hope you can >>> help. >>> >>> >>> >>> 1. Section 3: 3rd line of the first paragraph states “A pair of >>> systems >>> transmit BFD packets periodically over each path between the two >>> systems”. >>> >>> >>> >>> >>> >>> Question: when there are multiple paths between two systems, do you mean >>> to >>> have multiple BFD sessions between those two systems, with each session >>> covering individual path? How to enforce each path being traversed? >>> >>> >>> >>> SD> For example there can be multiple LSPs between two systems and you >>> need >>> to run BFD separately on each LSP. >>> >>> >>> >>> 2. The Echo function is pretty much like “Ping”. Each system can >>> initiate a “Ping” to another system. Is “periodic Ping” an accurate >>> description of the “Echo function”? >>> >>> >>> >>> SD> Your understanding is correct. But note that Echo packets are not >>> BFD >>> packets. BFD just negotiates the Echo interval. >>> >>> >>> >>> >>> >>> 3. Section 4.1 under the “Control Plane Independent” sub-section: >>> >>> The first paragraph states “if clear, the transmitting system’s BFD >>> implementation share fate with its control plane”. >>> >>> Question: When the transmitting system is running multiple routing >>> protocols, more than one signaling schemes for different services, is it >>> necessary to indicate which routing protocol and which signaling >>> protocol? >>> Actually, BFD is to test connectivity which can be up when the >>> corresponding control plane is done. What is the reason to have BFD >>> share >>> fate with its transmitting system’s control plane? >>> >>> >>> >>> SD> Every LSP or PW or tunnel that runs BFD could be setup using an >>> instance >>> of control plane. We don't care about the control plane of the client >>> or >>> server layers. What this bit indicates is the control-plane for the >>> layer >>> you are running the BFD on. >>> >>> >>> >>> 4. The BFD’s Control Packet Format described in Section 4.1 has a >>> bit >>> field for Demand mode. Why not having a bit field for the other two >>> modes >>> (Async and Echo)? >>> >>> SD> If D=0 it means Async mode. For Echo, if a system does not want >>> to >>> receive Echo it can set "Required Min Echo RX Interval " = 0 . And >>> there is >>> not need to signal that you want to Tx Echo. >>> >>> >>> >>> 5. Is the Discriminator field of the BFD’ Control Packet Format >>> same as >>> unique identifier for particular BFD session from one system? Why not >>> call >>> it Identifier? Is it negotiated between the two systems? >>> >>> SD> the Discr is a locally unique number (not globally) very similar >>> to >>> an LSP MPLS label that is distributed from a downstream node. It it not >>> negotiated. >>> >>> >>> >>> 6. Section 6.18.17 Concatenated Paths >>> >>> In transport network, Concatenated paths mean to combine (or bundle) >>> multiple paths to form a bigger path which has higher bandwidth. >>> Therefore, >>> failure on one of the paths concatenated together will not cause >>> connectivity problem for the two systems exchanging BFD. This failure >>> will >>> only cause the bandwidth of the concatenated path to be smaller. Do you >>> mean >>> that when one of the paths within a concatenated path fail, the BFD >>> should >>> indicate this partial failure of the concatenated path? >>> >>> >>> >>> SD> As far as I know concatenated paths in transport networks mean >>> stitching >>> two connections such as two LSPs. >>> >>> >>> >>> 7. Editorial: Section 2 Design: 6th line of the first paragraph: >>> “making it useful in concert with”? Is it a typo? >>> >>> >>> >>> Thank you very much for helping me. >>> >>> >>> >>> Best Regards, Linda Dunbar >>> >>> Advanced Technology Dept, Wireline Networks, >>> >>> Huawei Technologies, Inc. >>> >>> >> From dkatz@juniper.net Mon Sep 28 12:34:53 2009 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 09AA028C0DE for ; Mon, 28 Sep 2009 12:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=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 OpCmYMN4Yt89 for ; Mon, 28 Sep 2009 12:34:51 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 9B1EF3A6920 for ; Mon, 28 Sep 2009 12:34:50 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSsEQII1IjEcvLQsUbFvxLQgvzvRSBVzz@postini.com; Mon, 28 Sep 2009 12:36:09 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.1.375.2; Mon, 28 Sep 2009 12:26:30 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 12:26:30 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 12:26:29 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 12:26:29 -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 n8SJQSM82642; Mon, 28 Sep 2009 12:26:28 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <2CBD2C94-3383-4BD0-9D30-2D5F9216F194@juniper.net> From: Dave Katz To: Linda Dunbar In-Reply-To: <006601ca3c6b$cab7a280$330c7c0a@china.huawei.com> Content-Type: multipart/alternative; boundary="Apple-Mail-1-980881115" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: How to enforce BFD to be sent over different paths between two systems? Date: Mon, 28 Sep 2009 13:26:27 -0600 References: <006601ca3c6b$cab7a280$330c7c0a@china.huawei.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Sep 2009 19:26:29.0555 (UTC) FILETIME=[94365030:01CA4071] Cc: rtg-bfd@ietf.org, dward@cisco.com, dkatz@juniper.com 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: Mon, 28 Sep 2009 19:34:53 -0000 --Apple-Mail-1-980881115 Content-Type: text/plain; charset="WINDOWS-1252"; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Sep 23, 2009, at 10:34 AM, Linda Dunbar wrote: > Dave, > > I have some questions on =93draft-ietf-bfd-base-09.txt=94. Hope you = can =20 > help. > > Section 3: 3rd line of the first paragraph states =93A pair of systems = =20 > transmit BFD packets periodically over each path between the two =20 > systems=94. > > Question: when there are multiple paths between two systems, do you =20= > mean to have multiple BFD sessions between those two systems, with =20 > each session covering individual path? How to enforce each path =20 > being traversed? The idea is that a BFD session protects a path, and if multiple paths =20= are present, the operator/implementor can protect any or all of them. =20= "Enforcement" is outside the scope, but is most often a matter of =20 configuration (configuring BFD to run on an interface or an LSP or =20 whatever it may be.) > > The Echo function is pretty much like =93Ping=94. Each system can =20 > initiate a =93Ping=94 to another system. Is =93periodic Ping=94 an = accurate =20 > description of the =93Echo function=94? > More or less, with two additions. First, the echo protocol itself is =20= unspecified, so implementors can put whatever they want in the =20 packets, and this could presumably have some additional added value. =20= Second, the failure of the echo protocol is reflected in the control =20 protocol, so there is a standardized (more or less) mechanism to =20 signal that failure to the far end and to react to the failure. > > Section 4.1 under the =93Control Plane Independent=94 sub-section: > The first paragraph states =93if clear, the transmitting system=92s = BFD =20 > implementation share fate with its control plane=94. > Question: When the transmitting system is running multiple routing =20 > protocols, more than one signaling schemes for different services, =20 > is it necessary to indicate which routing protocol and which =20 > signaling protocol? Actually, BFD is to test connectivity which =20 > can be up when the corresponding control plane is done. What is the =20= > reason to have BFD share fate with its transmitting system=92s control = =20 > plane? The most common reason to share fate with the control plane is to =20 implement BFD in the control plane, which is where many =20 implementations start. BFD doesn't know or care about whether zero or =20= more routing protocols are running; the protocol is protecting the =20 data path over which the routing protocol runs. How BFD interacts =20 with some or all of those protocols is outside the spec (though =20 strongly hinted at in the Generic spec.) We have taken pains to keep =20= BFD very loosely coupled with the rest of the system; BFD tests the =20 path, and if it detects a failure, other parts of the system =20 (typically routing protocols) are advised of this. If multiple routing protocols are running over IPv4, there will be a =20 single BFD session running over the IPv4 path between systems, and a =20 failure of that BFD session would typically be signaled to each =20 protocol. > > The BFD=92s Control Packet Format described in Section 4.1 has a bit =20= > field for Demand mode. Why not having a bit field for the other two =20= > modes (Async and Echo)? Because it is not necessary to signal them in this way; the bits =20 would be redundant and/or useless. > > Is the Discriminator field of the BFD=92 Control Packet Format same as = =20 > unique identifier for particular BFD session from one system? Why =20 > not call it Identifier? Is it negotiated between the two systems? That's what we called it. It discriminates between multiple sessions =20= between the same pair of systems. > > > Section 6.18.17 Concatenated Paths > In transport network, Concatenated paths mean to combine (or bundle) =20= > multiple paths to form a bigger path which has higher bandwidth. =20 > Therefore, failure on one of the paths concatenated together will =20 > not cause connectivity problem for the two systems exchanging BFD. =20 > This failure will only cause the bandwidth of the concatenated path =20= > to be smaller. Do you mean that when one of the paths within a =20 > concatenated path fail, the BFD should indicate this partial failure =20= > of the concatenated path? In my dictionary, "concatenation" is the process of hooking things =20 together "in a chain or series." Bundling is not concatenation, at =20 least in the general definition of the word, since it is parallel. The point of this section is to point out that an end-to-end path may =20= be stitched together out of segments of various technologies, and BFD =20= may run over only part of this end-to-end path. If a failure is =20 detected by other means on an adjacent segment (say, OAM), this can be =20= signaled through BFD to the system connecting to the next segment, =20 with the idea that the failure can be signaled all the way to the end, =20= even though the bit over which BFD is running may not have failed =20 itself. This is an interworking hack. > > Editorial: Section 2 Design: 6th line of the first paragraph: =20 > =93making it useful in concert with=94? Is it a typo? No, just my somewhat arcane choice of wording. "In concert with" =20 means "along with" or "in combination with". > > > Thank you very much for helping me. > > Best Regards, Linda Dunbar > Advanced Technology Dept, Wireline Networks, > Huawei Technologies, Inc. > --Apple-Mail-1-980881115 Content-Type: text/html; charset="WINDOWS-1252" Content-Transfer-Encoding: quoted-printable
On Sep 23, 2009, = at 10:34 AM, Linda Dunbar wrote:

I = have some questions on =93draft-ietf-bfd-base-09.txt=94. Hope you can = help.
  • Section 3: 3rd line of the first paragraph = states =93A pair of systems transmit BFD packets periodically over each = path between the two systems=94.
    •  
    Question: when there are multiple paths between = two systems, do you mean to have multiple BFD sessions between those two = systems, with each session covering individual path? How to enforce each = path being = traversed?

    The idea is that a BFD session protects a path, and = if multiple paths are present, the operator/implementor can protect any = or all of them.  "Enforcement" is outside the scope, but is most = often a matter of configuration (configuring BFD to run on an interface = or an LSP or whatever it may be.)

  • The Echo function is pretty much like =93Ping=94. Each system can initiate a =93Ping=94 to another system. Is =93periodic Ping=94 an accurate description of the =93Echo = function=94?
  • Section 4.1 under the =93Control Plane = Independent=94 sub-section:
    • The first paragraph states =93if clear, the = transmitting system=92s BFD implementation share fate with its control = plane=94.
  • The BFD=92s Control Packet Format described in = Section 4.1 has a bit field for Demand mode. Why not having a bit field = for the other two modes (Async and = Echo)?

    • Because it is not necessary to signal them in this = way;  the bits would be redundant and/or = useless.

    2. Is the Discriminator field of the BFD=92 Control = Packet Format same as unique identifier for particular BFD session from = one system? Why not call it Identifier? Is it negotiated between the two = systems?

    That's what we called it.  It discriminates = between multiple sessions between the same pair of = systems.

     
    1. Section 6.18.17 = Concatenated Paths
    In transport network, Concatenated paths mean to = combine (or bundle) multiple paths to form a bigger path which has = higher bandwidth. Therefore, failure on one of the paths concatenated = together will not cause connectivity problem for the two systems = exchanging BFD. This failure will only cause the bandwidth of the = concatenated path to be smaller. Do you mean that when one of the paths = within a concatenated path fail, the BFD should indicate this partial = failure of the concatenated = path?
    =

    In my dictionary, "concatenation" is the process of = hooking things together "in a chain or series."  Bundling is not = concatenation, at least in the general definition of the word, since it = is parallel.

    The point of this section is to = point out that an end-to-end path may be stitched together out of = segments of various technologies, and BFD may run over only part of this = end-to-end path.  If a failure is detected by other means on an = adjacent segment (say, OAM), this can be signaled through BFD to the = system connecting to the next segment, with the idea that the failure = can be signaled all the way to the end, even though the bit over which = BFD is running may not have failed itself.

    This = is an interworking hack.

  • Editorial: Section 2 Design: 6th line of the first = paragraph: =93making it useful in concert with=94? Is it a = typo?

    • No, just my somewhat arcane choice of wording. =  "In concert with" means "along with" or "in combination = with".


     
    Thank you very much for helping = me.
    Advanced = Technology Dept, Wireline Networks,
    Huawei Technologies, Inc.
    <2C2F1EBA8050E74EA81502D5740B4BD6815751C5DC@SJEXCHCCR02.corp.ad.broadcom.com> <008b01ca3c70$a39ed6a0$330c7c0a@china.huawei.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Sep 2009 19:35:01.0199 (UTC) FILETIME=[C52CFDF0:01CA4072] Cc: rtg-bfd@ietf.org, dward@cisco.com 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: Mon, 28 Sep 2009 19:40:54 -0000 --Apple-Mail-2-981392936 Content-Type: text/plain; charset="WINDOWS-1252"; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable "Path" is a very generic term; it is unfortunate that there is some =20 conflict in terminology, but those of us steeped in network layer =20 technology don't view paths as being physical. For what it's worth, there is this bit in the spec: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course.) =46rom the standpoint of BFD running at the network layer, you are =20 correct in pointing out that the endpoint may not be able to choose =20 the physical path over which the packets will fly (particularly with =20 MPLS). However, from BFD's standpoint in this case, the MPLS LSP *is* =20= the path. If the LSP gets moved around to a different physical path =20 beneath it, BFD at this layer will not know nor care; its sole =20 purpose is to let the end system know whether or not the LSP is viable. Note that one could run BFD at multiple layers; a BFD session could =20 run over each individual physical link if that was interesting, =20 independent of BFD being run over the LSP. This is in fact likely to =20 be the case if the LSPs are being built with the assistance of routing =20= protocols being run directly over the physical links, for example. --Dave On Sep 23, 2009, at 11:09 AM, Linda Dunbar wrote: > Hi Shahram, > > Thank you very much for the answers. > Maybe some wording can be improved. For example, if the text says =20 > =93transmitting BFD=94 over multiple paths, it is better to define = what =20 > =93path=94 means. To many people, especially people with transport =20 > network background, paths mean physical paths. Different LDP or LSP =20= > paths between two systems may not traverse all the paths between two =20= > systems. > > I understand that the intent of BFD is to let BFD run over various =20 > media. But the description of the protocol is under the assumption =20 > that BFD is running over a path which source can control, like LSP =20 > or LDP. For IP forwarding, the source can=92t control which path to =20= > traverse from A to B. It is up to intermediate nodes to choose a path. > > Linda Dunbar > > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Wednesday, September 23, 2009 11:53 AM > To: Linda Dunbar; rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com > Subject: RE: How to enforce BFD to be sent over different paths =20 > between two systems? > > Hi Linda, > > I am sure Dave will answer these questions better that I do, but let =20= > me give you my 2c inline. > > Regards, > Shahram > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On =20= > Behalf Of Linda Dunbar > Sent: Wednesday, September 23, 2009 9:35 AM > To: rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com > Subject: How to enforce BFD to be sent over different paths between =20= > two systems? > > Dave, > > I have some questions on =93draft-ietf-bfd-base-09.txt=94. Hope you = can =20 > help. > > 1. Section 3: 3rd line of the first paragraph states =93A pair of = =20 > systems transmit BFD packets periodically over each path between the =20= > two systems=94. > > > Question: when there are multiple paths between two systems, do you =20= > mean to have multiple BFD sessions between those two systems, with =20 > each session covering individual path? How to enforce each path =20 > being traversed? > > SD> For example there can be multiple LSPs between two systems and =20 > you need to run BFD separately on each LSP. > > 2. The Echo function is pretty much like =93Ping=94. Each system =20= > can initiate a =93Ping=94 to another system. Is =93periodic Ping=94 an = =20 > accurate description of the =93Echo function=94? > > SD> Your understanding is correct. But note that Echo packets are =20 > not BFD packets. BFD just negotiates the Echo interval. > > > 3. Section 4.1 under the =93Control Plane Independent=94 = sub-section: > The first paragraph states =93if clear, the transmitting system=92s = BFD =20 > implementation share fate with its control plane=94. > Question: When the transmitting system is running multiple routing =20 > protocols, more than one signaling schemes for different services, =20 > is it necessary to indicate which routing protocol and which =20 > signaling protocol? Actually, BFD is to test connectivity which =20 > can be up when the corresponding control plane is done. What is the =20= > reason to have BFD share fate with its transmitting system=92s control = =20 > plane? > > SD> Every LSP or PW or tunnel that runs BFD could be setup using an =20= > instance of control plane. We don't care about the control plane of =20= > the client or server layers. What this bit indicates is the control-=20= > plane for the layer you are running the BFD on. > > 4. The BFD=92s Control Packet Format described in Section 4.1 has = =20 > a bit field for Demand mode. Why not having a bit field for the =20 > other two modes (Async and Echo)? > SD> If D=3D0 it means Async mode. For Echo, if a system does not =20= > want to receive Echo it can set "Required Min Echo RX Interval " =3D =20= > 0 . And there is not need to signal that you want to Tx Echo. > > 5. Is the Discriminator field of the BFD=92 Control Packet Format = =20 > same as unique identifier for particular BFD session from one =20 > system? Why not call it Identifier? Is it negotiated between the two =20= > systems? > SD> the Discr is a locally unique number (not globally) very =20 > similar to an LSP MPLS label that is distributed from a downstream =20 > node. It it not negotiated. > > 6. Section 6.18.17 Concatenated Paths > In transport network, Concatenated paths mean to combine (or bundle) =20= > multiple paths to form a bigger path which has higher bandwidth. =20 > Therefore, failure on one of the paths concatenated together will =20 > not cause connectivity problem for the two systems exchanging BFD. =20 > This failure will only cause the bandwidth of the concatenated path =20= > to be smaller. Do you mean that when one of the paths within a =20 > concatenated path fail, the BFD should indicate this partial failure =20= > of the concatenated path? > > SD> As far as I know concatenated paths in transport networks mean =20 > stitching two connections such as two LSPs. > > 7. Editorial: Section 2 Design: 6th line of the first =20 > paragraph: =93making it useful in concert with=94? Is it a typo? > > Thank you very much for helping me. > > Best Regards, Linda Dunbar > Advanced Technology Dept, Wireline Networks, > Huawei Technologies, Inc. > --Apple-Mail-2-981392936 Content-Type: text/html; charset="WINDOWS-1252" Content-Transfer-Encoding: quoted-printable "Path" is a very generic term; =  it is unfortunate that there is some conflict in terminology, but = those of us steeped in network layer technology don't view paths as = being physical.

    For what it's worth, there is this = bit in the spec:

     BFD can provide = failure detection on any kind of path between
     systems, = including direct physical links, virtual circuits, = tunnels,
     MPLS LSPs, multihop routed paths, and = unidirectional links (so long
     as there is some return = path, of course.)

    =46rom the standpoint of BFD = running at the network layer, you are correct in pointing out that the = endpoint may not be able to choose the physical path over which the = packets will fly (particularly with MPLS).  However, from BFD's = standpoint in this case, the MPLS LSP *is* the path.  If the LSP = gets moved around to a different physical path beneath it, BFD at this = layer will not know nor care;  its sole purpose is to let the end = system know whether or not the LSP is = viable.

    Note that one could run BFD at multiple = layers;  a BFD session could run over each individual physical link = if that was interesting, independent of BFD being run over the LSP. This = is in fact likely to be the case if the LSPs are being built with the = assistance of routing protocols being run directly over the physical = links, for = example.

    --Dave

    On = Sep 23, 2009, at 11:09 AM, Linda Dunbar wrote:

    Hi Shahram,
    Thank you very much for the = answers.
    Maybe some wording can be improved. For example, if the = text says =93transmitting BFD=94 over multiple paths, it is better to = define what =93path=94 means. To many people, especially people with = transport network background, paths mean physical paths. Different LDP = or LSP paths between two systems may not traverse all the paths between = two systems.
    I understand that the intent of BFD is to let BFD run = over various media. But the description of the protocol is under the = assumption that BFD is running over a path which source can control, = like LSP or LDP. For IP forwarding, the source can=92t control which = path to traverse from A to B. It is up to intermediate nodes to choose a = path.  
     Linda Dunbar
    From: Shahram = Davari [mailto:davari@broadcom.com] 
    Sent: Wednesday, September 23, = 2009 11:53 AM
     Linda = Dunbar; rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com
     RE: How to enforce BFD to = be sent over different paths between two = systems?
    Hi = Linda,
    I am sure Dave will answer = these questions better that I do, but let me give you my 2c = inline.

     rtg-bfd-bounces@ietf.org = [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Linda = Dunbar
    Sent: Wednesday, September 23, = 2009 9:35 AM
     rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com
     How to enforce BFD to be = sent over different paths between two = systems?

    I = have some questions on =93draft-ietf-bfd-base-09.txt=94. Hope you can = help.
     <= /font>Section = 3: 3rd line = of the first paragraph states =93A pair of systems transmit BFD packets = periodically over each path between the two = systems=94.  
     
     
    Question: when there are multiple paths between = two systems, do you mean to have multiple BFD sessions between those two = systems, with each session covering individual path? How to enforce each = path being traversed?  
     
    SD> For example there can be = multiple LSPs between two systems and you need to run BFD separately on = each LSP.  
     
    2.      <= /font>The Echo = function is pretty much like =93Ping=94= . Each system can initiate a =93Ping=94= to another system. Is =93periodic Ping=94 an accurate description of the =93Echo = function=94?  
     SD> Your = understanding is correct. But note that Echo packets are not BFD = packets. BFD just negotiates the Echo = interval.
    3. <= /font>Section = 4.1 under the =93Control Plane Independent=94 = sub-section:
    The = first paragraph states =93if clear, the transmitting system=92s BFD = implementation share fate with its control = plane=94.
     
     
    SD> Every LSP or PW or tunnel = that runs BFD could be setup using an instance of control plane. =  We don't care about the control plane of the client or server = layers. What this bit indicates is the control-plane for the layer you = are running the BFD on.
     
    4.      <= /font>The = BFD=92s Control Packet Format described in Section 4.1 has a bit field = for Demand mode. Why not having a bit field for the other two modes = (Async and Echo)?  
        = SD> If D=3D0 it means Async mode. For Echo, if a system = does not want to receive Echo it can set  "Required = Min Echo RX Interval " =3D 0 . And there is not need to signal = that you want to Tx Echo.
     
    5.      <= /font>Is the = Discriminator field of the BFD=92 Control Packet Format same as unique = identifier for particular BFD session from one system? Why not call it = Identifier? Is it negotiated between the two = systems?  
       SD> the = Discr is a locally unique number (not globally) very similar to = an LSP MPLS label that is distributed from a downstream = node. It it not = negotiated.
    6. <= /font>Section = 6.18.17 Concatenated Paths
    In transport network, Concatenated paths mean to = combine (or bundle) multiple paths to form a bigger path which has = higher bandwidth. Therefore, failure on one of the paths concatenated = together will not cause connectivity problem for the two systems = exchanging BFD. This failure will only cause the bandwidth of the = concatenated path to be smaller. Do you mean that when one of the paths = within a concatenated path fail, the BFD should indicate this partial = failure of the concatenated path? SD> As far as I know = concatenated paths in transport networks mean stitching two = connections such as two LSPs. 
     
    7.      <= /font> line of the first = paragraph: =93making it useful in concert with=94? Is it a = typo?
     
    Best Regards, Linda = Dunbar
    Advanced Technology Dept, Wireline = Networks,
    List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 19:46:42 -0000 BFD is suitable for any multipath scenario in which the sessions can =20 be bound to those individual paths by one means or another. This is a =20= somewhat reflexive statement, but it gets at the heart of the =20 problem: if you can't distinguish multiple paths from the vantage =20 point of where BFD is running, you can't have multiple sessions. This tension is most obvious in the L1/L2 bundling case; if BFD sees =20= only the aggregate interface, there's no use in having multiple =20 sessions (and you can't demultiplex the sessions without some other =20 help, such as out-of-band discriminator exchange.) One could imagine running BFD on each individual link of a bundle and =20= then having a separate session that runs over the bundle (or not) but =20= it looks like BFD won't get much traction at L2 so this is moot. In the usual IP ECMP case, BFD is suitable because sessions can be =20 bound to each of the individual L2 paths (by physical or logical =20 interface, for example.) --Dave On Sep 23, 2009, at 9:00 PM, Mach Chen wrote: > Correct:-) > > "Suitable" should be "not suilable" > > > -------------------------------------------------- > From: "Mach Chen" > Sent: Thursday, September 24, 2009 10:54 AM > To: "Vishwas Manral" ; "Shahram Davari" = > > Cc: ; ; > Subject: Re: How to enforce BFD to be sent over different paths =20 > betweentwosystems? > >> Hi, >> >> For LDP LSP, it also has the same ECMP issue. >> >> Could I say that BFD is suitable for any ECMP scenario? >> >> Best regards, >> Mach >> >> >> -------------------------------------------------- >> From: "Vishwas Manral" >> Sent: Thursday, September 24, 2009 1:35 AM >> To: "Shahram Davari" >> Cc: ; ; >> Subject: Re: How to enforce BFD to be sent over different paths =20 >> between twosystems? >> >>> Hi Shahram, >>> >>>> That is correct. For IP there is only one path (shortest path) =20 >>>> between two >>>> systems. >>> Except ofcourse for the ECMP case. >>> >>> Thanks, >>> Vishwas >>> >>>> ________________________________ >>>> From: Linda Dunbar [mailto:ldunbar@huawei.com] >>>> Sent: Wednesday, September 23, 2009 10:10 AM >>>> To: Shahram Davari; rtg-bfd@ietf.org; dkatz@juniper.net; = dward@cisco.com >>>> Subject: RE: How to enforce BFD to be sent over different paths =20 >>>> between two >>>> systems? >>>> >>>> Hi Shahram, >>>> >>>> >>>> >>>> Thank you very much for the answers. >>>> >>>> Maybe some wording can be improved. For example, if the text says >>>> =93transmitting BFD=94 over multiple paths, it is better to define =20= >>>> what =93path=94 >>>> means. To many people, especially people with transport network =20 >>>> background, >>>> paths mean physical paths. Different LDP or LSP paths between two =20= >>>> systems >>>> may not traverse all the paths between two systems. >>>> >>>> >>>> >>>> I understand that the intent of BFD is to let BFD run over =20 >>>> various media. >>>> But the description of the protocol is under the assumption that =20= >>>> BFD is >>>> running over a path which source can control, like LSP or LDP. =20 >>>> For IP >>>> forwarding, the source can=92t control which path to traverse from =20= >>>> A to B. It >>>> is up to intermediate nodes to choose a path. >>>> >>>> >>>> >>>> Linda Dunbar >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> From: Shahram Davari [mailto:davari@broadcom.com] >>>> Sent: Wednesday, September 23, 2009 11:53 AM >>>> To: Linda Dunbar; rtg-bfd@ietf.org; dkatz@juniper.com; = dward@cisco.com >>>> Subject: RE: How to enforce BFD to be sent over different paths =20 >>>> between two >>>> systems? >>>> >>>> >>>> >>>> Hi Linda, >>>> >>>> >>>> >>>> I am sure Dave will answer these questions better that I do, but =20= >>>> let me give >>>> you my 2c inline. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Shahram >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] =20= >>>> On Behalf >>>> Of Linda Dunbar >>>> Sent: Wednesday, September 23, 2009 9:35 AM >>>> To: rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com >>>> Subject: How to enforce BFD to be sent over different paths =20 >>>> between two >>>> systems? >>>> >>>> Dave, >>>> >>>> >>>> >>>> I have some questions on =93draft-ietf-bfd-base-09.txt=94. Hope you = =20 >>>> can help. >>>> >>>> >>>> >>>> 1. Section 3: 3rd line of the first paragraph states =93A pair = =20 >>>> of systems >>>> transmit BFD packets periodically over each path between the two =20= >>>> systems=94. >>>> >>>> >>>> >>>> >>>> >>>> Question: when there are multiple paths between two systems, do =20 >>>> you mean to >>>> have multiple BFD sessions between those two systems, with each =20 >>>> session >>>> covering individual path? How to enforce each path being traversed? >>>> >>>> >>>> >>>> SD> For example there can be multiple LSPs between two systems =20 >>>> and you need >>>> to run BFD separately on each LSP. >>>> >>>> >>>> >>>> 2. The Echo function is pretty much like =93Ping=94. Each = system =20 >>>> can >>>> initiate a =93Ping=94 to another system. Is =93periodic Ping=94 an = accurate >>>> description of the =93Echo function=94? >>>> >>>> >>>> >>>> SD> Your understanding is correct. But note that Echo packets are =20= >>>> not BFD >>>> packets. BFD just negotiates the Echo interval. >>>> >>>> >>>> >>>> >>>> >>>> 3. Section 4.1 under the =93Control Plane Independent=94 sub-=20= >>>> section: >>>> >>>> The first paragraph states =93if clear, the transmitting system=92s = BFD >>>> implementation share fate with its control plane=94. >>>> >>>> Question: When the transmitting system is running multiple routing >>>> protocols, more than one signaling schemes for different =20 >>>> services, is it >>>> necessary to indicate which routing protocol and which signaling =20= >>>> protocol? >>>> Actually, BFD is to test connectivity which can be up when the >>>> corresponding control plane is done. What is the reason to have =20 >>>> BFD share >>>> fate with its transmitting system=92s control plane? >>>> >>>> >>>> >>>> SD> Every LSP or PW or tunnel that runs BFD could be setup using =20= >>>> an instance >>>> of control plane. We don't care about the control plane of the =20 >>>> client or >>>> server layers. What this bit indicates is the control-plane for =20 >>>> the layer >>>> you are running the BFD on. >>>> >>>> >>>> >>>> 4. The BFD=92s Control Packet Format described in Section 4.1 =20= >>>> has a bit >>>> field for Demand mode. Why not having a bit field for the other =20 >>>> two modes >>>> (Async and Echo)? >>>> >>>> SD> If D=3D0 it means Async mode. For Echo, if a system does not = =20 >>>> want to >>>> receive Echo it can set "Required Min Echo RX Interval " =3D 0 . =20= >>>> And there is >>>> not need to signal that you want to Tx Echo. >>>> >>>> >>>> >>>> 5. Is the Discriminator field of the BFD=92 Control Packet =20 >>>> Format same as >>>> unique identifier for particular BFD session from one system? Why =20= >>>> not call >>>> it Identifier? Is it negotiated between the two systems? >>>> >>>> SD> the Discr is a locally unique number (not globally) very =20 >>>> similar to >>>> an LSP MPLS label that is distributed from a downstream node. It =20= >>>> it not >>>> negotiated. >>>> >>>> >>>> >>>> 6. Section 6.18.17 Concatenated Paths >>>> >>>> In transport network, Concatenated paths mean to combine (or =20 >>>> bundle) >>>> multiple paths to form a bigger path which has higher bandwidth. =20= >>>> Therefore, >>>> failure on one of the paths concatenated together will not cause >>>> connectivity problem for the two systems exchanging BFD. This =20 >>>> failure will >>>> only cause the bandwidth of the concatenated path to be smaller. =20= >>>> Do you mean >>>> that when one of the paths within a concatenated path fail, the =20 >>>> BFD should >>>> indicate this partial failure of the concatenated path? >>>> >>>> >>>> >>>> SD> As far as I know concatenated paths in transport networks =20 >>>> mean stitching >>>> two connections such as two LSPs. >>>> >>>> >>>> >>>> 7. Editorial: Section 2 Design: 6th line of the first =20 >>>> paragraph: >>>> =93making it useful in concert with=94? Is it a typo? >>>> >>>> >>>> >>>> Thank you very much for helping me. >>>> >>>> >>>> >>>> Best Regards, Linda Dunbar >>>> >>>> Advanced Technology Dept, Wireline Networks, >>>> >>>> Huawei Technologies, Inc. >>>> >>>> > From vishwas.ietf@gmail.com Mon Sep 28 16:33:22 2009 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 000B83A6825 for ; Mon, 28 Sep 2009 16:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3X--qLGzJVA for ; Mon, 28 Sep 2009 16:33:21 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id B89973A6964 for ; Mon, 28 Sep 2009 16:33:20 -0700 (PDT) Received: by yxe30 with SMTP id 30so6743365yxe.29 for ; Mon, 28 Sep 2009 16:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UIPvYnqz9MGEyRuEt0aCCbn6QmNqVP6Q7KvIaV6N9V0=; b=rGlD543BlDxBjhXuvdf1cWigwA0pre29vevZitqJdnszyafa9afnwzlTW4iwSGCYus 6lvpsCGVZntnyVuBGWIuMZf5w1o/6kYpHnFggISOUeCuN8aOVWGFT8nKsvNh8O/bbO4i gy3bQg43v0jjsjF5/OAbardcgN6YyiNfUks9I= 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=ceokJBhsAmCFJvCbdQqe2oYKJ7CA8s1zez24Cx5YwkgoY+C9PkHk9S1VyKLS1uTMA/ ETGY05q6Xran1fpwIRb5hAfzaG5NCRBgcjoypeKVq8u4qXNGq48IRt3a+KkL8AnMVcRF SWusUzqEZyLLwMEiBtGLHkLXJX/HxWmVHN2eE= MIME-Version: 1.0 Received: by 10.150.55.4 with SMTP id d4mr8783294yba.318.1254180876123; Mon, 28 Sep 2009 16:34:36 -0700 (PDT) In-Reply-To: <75634DDF1614436FA4456B82E9D30337@m55527c> References: <006601ca3c6b$cab7a280$330c7c0a@china.huawei.com> <2C2F1EBA8050E74EA81502D5740B4BD6815751C5DC@SJEXCHCCR02.corp.ad.broadcom.com> <008b01ca3c70$a39ed6a0$330c7c0a@china.huawei.com> <2C2F1EBA8050E74EA81502D5740B4BD6815751C5EE@SJEXCHCCR02.corp.ad.broadcom.com> <77ead0ec0909231035g31d58c0bq4ae325e251e94d69@mail.gmail.com> <75634DDF1614436FA4456B82E9D30337@m55527c> Date: Mon, 28 Sep 2009 16:34:36 -0700 Message-ID: <77ead0ec0909281634u7f555531k7cc39404d3bb7f5c@mail.gmail.com> Subject: Re: How to enforce BFD to be sent over different paths between twosystems? From: Vishwas Manral To: Mach Chen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: dward@cisco.com, rtg-bfd@ietf.org, dkatz@juniper.net 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: Mon, 28 Sep 2009 23:33:22 -0000 Hi Mach, On Wed, Sep 23, 2009 at 7:54 PM, Mach Chen wrote: > > Could I say that BFD is suitable for any ECMP scenario? If the two paths are at the head end we could force the packets out of the different interfaces otherwise based on the FEC the packets could be forced on particular path, but we may not be able to exercise every ECMP path (if the routing convergence time is more than the BFD detection time). Thanks, Vishwas > Best regards, > Mach > > > -------------------------------------------------- > From: "Vishwas Manral" > Sent: Thursday, September 24, 2009 1:35 AM > To: "Shahram Davari" > Cc: ; ; > Subject: Re: How to enforce BFD to be sent over different paths between > twosystems? > >> Hi Shahram, >> >>> That is correct. For IP there is only one path (shortest path) =A0betwe= en >>> two >>> systems. >> >> Except ofcourse for the ECMP case. >> >> Thanks, >> Vishwas >> >>> ________________________________ >>> From: Linda Dunbar [mailto:ldunbar@huawei.com] >>> Sent: Wednesday, September 23, 2009 10:10 AM >>> To: Shahram Davari; rtg-bfd@ietf.org; dkatz@juniper.net; dward@cisco.co= m >>> Subject: RE: How to enforce BFD to be sent over different paths between >>> two >>> systems? >>> >>> Hi Shahram, >>> >>> >>> >>> Thank you very much for the answers. >>> >>> Maybe some wording can be improved. For example, if the text says >>> =93transmitting BFD=94 over multiple paths, it is better to define what >>> =A0=93path=94 >>> means. To many people, especially people with transport network >>> background, >>> paths mean physical paths. Different LDP or LSP paths between two syste= ms >>> may not traverse all the paths between two systems. >>> >>> >>> >>> I understand that the intent of BFD is to let BFD run over various medi= a. >>> But the description of the protocol is under the assumption that BFD is >>> running over a path which source can control, like LSP or LDP. For IP >>> forwarding, the source can=92t control which path to traverse from A to= B. >>> It >>> is up to intermediate nodes to choose a path. >>> >>> >>> >>> =A0Linda Dunbar >>> >>> >>> >>> ________________________________ >>> >>> From: Shahram Davari [mailto:davari@broadcom.com] >>> Sent: Wednesday, September 23, 2009 11:53 AM >>> To: Linda Dunbar; rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com >>> Subject: RE: How to enforce BFD to be sent over different paths between >>> two >>> systems? >>> >>> >>> >>> Hi Linda, >>> >>> >>> >>> I am sure Dave will answer these questions better that I do, but let me >>> give >>> you my 2c inline. >>> >>> >>> >>> Regards, >>> >>> Shahram >>> >>> >>> >>> ________________________________ >>> >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On >>> Behalf >>> Of Linda Dunbar >>> Sent: Wednesday, September 23, 2009 9:35 AM >>> To: rtg-bfd@ietf.org; dkatz@juniper.com; dward@cisco.com >>> Subject: How to enforce BFD to be sent over different paths between two >>> systems? >>> >>> Dave, >>> >>> >>> >>> I have some questions on =93draft-ietf-bfd-base-09.txt=94. Hope you can= help. >>> >>> >>> >>> 1. =A0 =A0 =A0Section 3: 3rd line of the first paragraph states =93A pa= ir of >>> systems >>> transmit BFD packets periodically over each path between the two >>> systems=94. >>> >>> >>> >>> >>> >>> Question: when there are multiple paths between two systems, do you mea= n >>> to >>> have multiple BFD sessions between those two systems, with each session >>> covering individual path? How to enforce each path being traversed? >>> >>> >>> >>> SD> For example there can be multiple LSPs between two systems and you >>> need >>> to run BFD separately on each LSP. >>> >>> >>> >>> 2. =A0 =A0 =A0The Echo function is pretty much like =93Ping=94. Each sy= stem can >>> initiate a =93Ping=94 to another system. Is =93periodic Ping=94 an accu= rate >>> description of the =93Echo function=94? >>> >>> >>> >>> =A0SD> Your understanding is correct. But note that Echo packets are no= t >>> BFD >>> packets. BFD just negotiates the Echo interval. >>> >>> >>> >>> >>> >>> 3. =A0 =A0 =A0Section 4.1 under the =93Control Plane Independent=94 sub= -section: >>> >>> The first paragraph states =93if clear, the transmitting system=92s BFD >>> implementation share fate with its control plane=94. >>> >>> Question: When the transmitting system is running multiple routing >>> protocols, more than one signaling schemes for different services, is i= t >>> necessary to indicate which routing protocol and which signaling >>> protocol? >>> =A0 Actually, BFD is to test connectivity which can be up when the >>> corresponding control plane is done. What is the reason to have BFD sha= re >>> fate with its transmitting system=92s control plane? >>> >>> >>> >>> SD> Every LSP or PW or tunnel that runs BFD could be setup using an >>> instance >>> of control plane. =A0We don't care about the control plane of the clien= t or >>> server layers. What this bit indicates is the control-plane for the lay= er >>> you are running the BFD on. >>> >>> >>> >>> 4. =A0 =A0 =A0The BFD=92s Control Packet Format described in Section 4.= 1 has a >>> bit >>> field for Demand mode. Why not having a bit field for the other two mod= es >>> (Async and Echo)? >>> >>> =A0 =A0SD> If D=3D0 it means Async mode. For Echo, if a system does not= want to >>> receive Echo it can set =A0"Required Min Echo RX Interval " =3D 0 . And= there >>> is >>> not need to signal that you want to Tx Echo. >>> >>> >>> >>> 5. =A0 =A0 =A0Is the Discriminator field of the BFD=92 Control Packet F= ormat same >>> as >>> unique identifier for particular BFD session from one system? Why not >>> call >>> it Identifier? Is it negotiated between the two systems? >>> >>> =A0 SD> the Discr is a locally unique number (not globally) very simila= r to >>> an LSP MPLS label that is distributed from a downstream node. It it not >>> negotiated. >>> >>> >>> >>> 6. =A0 =A0 =A0Section 6.18.17 Concatenated Paths >>> >>> In transport network, Concatenated paths mean to combine (or bundle) >>> multiple paths to form a bigger path which has higher bandwidth. >>> Therefore, >>> failure on one of the paths concatenated together will not cause >>> connectivity problem for the two systems exchanging BFD. This failure >>> will >>> only cause the bandwidth of the concatenated path to be smaller. Do you >>> mean >>> that when one of the paths within a concatenated path fail, the BFD >>> should >>> indicate this partial failure of the concatenated path? >>> >>> >>> >>> SD> As far as I know concatenated paths in transport networks mean >>> stitching >>> two connections such as two LSPs. >>> >>> >>> >>> 7. =A0 =A0 =A0Editorial: Section 2 Design: 6th line of the first paragr= aph: >>> =93making it useful in concert with=94? Is it a typo? >>> >>> >>> >>> Thank you very much for helping me. >>> >>> >>> >>> Best Regards, Linda Dunbar >>> >>> Advanced Technology Dept, Wireline Networks, >>> >>> Huawei Technologies, Inc. >>> >>> >> >