From mailman-bounces@core3.amsl.com Fri Feb 1 06:34:33 2008 Return-Path: X-Original-To: ietfarch-rtg-bfd-archive@core3.amsl.com Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8B829300E for ; Fri, 1 Feb 2008 06:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBAuKAP8-ahN for ; Fri, 1 Feb 2008 06:34:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA8262A3EFE for ; Fri, 1 Feb 2008 06:11:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: rtg-bfd-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:08:29 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/rtg-bfd/rtg-bfd-archive%40megatron.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 06:34:38 2008 Return-Path: X-Original-To: ietfarch-rtg-bfd-archive@core3.amsl.com Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C4C32935DF for ; Fri, 1 Feb 2008 06:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrMICTSdDKsm for ; Fri, 1 Feb 2008 06:34:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBC6C28E1F8 for ; Fri, 1 Feb 2008 06:11:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: rtg-bfd-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:08:28 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/rtg-bfd/rtg-bfd-archive%40megatron.ietf.org From rtg-bfd-bounces@ietf.org Wed Feb 13 13:52:25 2008 Return-Path: X-Original-To: ietfarch-rtg-bfd-archive@core3.amsl.com Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ECB43A6FC1; Wed, 13 Feb 2008 13:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.614 X-Spam-Level: X-Spam-Status: No, score=-3.614 tagged_above=-999 required=5 tests=[AWL=2.385, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, 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 v7e2He8woh7W; Wed, 13 Feb 2008 13:52:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 415C23A6C33; Wed, 13 Feb 2008 13:52:25 -0800 (PST) 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 B65B83A6C33 for ; Wed, 13 Feb 2008 13:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 luaePBLAZyur for ; Wed, 13 Feb 2008 13:52:22 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id A89AF3A67B1 for ; Wed, 13 Feb 2008 13:52:22 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m1DLrjY10242 for ; Wed, 13 Feb 2008 16:53:45 -0500 (EST) Received: from [64.102.159.125] (dhcp-64-102-159-125.cisco.com [64.102.159.125]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m1DLsKu08944 for ; Wed, 13 Feb 2008 16:54:20 -0500 (EST) Message-ID: <47B366E9.2090300@cisco.com> Date: Wed, 13 Feb 2008 16:53:45 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: BFD WG Subject: Small LC Comment on bfd-base-07 X-Enigmail-Version: 0.95.6 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi, A quick comment on a possible small inconsistency that was brought up in pwe3: In concatenated paths/iw, the Diag can have values of 6/8 without the Session State being (Admin)Down: http://tools.ietf.org/html/draft-ietf-bfd-base-07#section-6.8.17 Two diagnostic codes are defined for this purpose: Concatenated Path Down and Reverse Concatenated Path Down. ... A system MAY signal one of these failure states by simply setting bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD session is not taken down. If Demand mode is not active on the remote system, no other action is necessary, as the diagnostic code will be carried via the periodic transmission of BFD Control packets. But the definition of Diag (and bfd.LocalDiag) says (or implies) that there needs to be a state change to Down or AdminDown: Diagnostic (Diag) A diagnostic code specifying the local system's reason for the last session state change to states Down or AdminDown. bfd.LocalDiag The diagnostic code specifying the reason for the most recent local session state change to states Down or AdminDown. Thanks, -- --Carlos Pignataro. Escalation RTP - cisco Systems From rtg-bfd-bounces@ietf.org Thu Feb 14 10:17:19 2008 Return-Path: X-Original-To: ietfarch-rtg-bfd-archive@core3.amsl.com Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417FF28CFAE; Thu, 14 Feb 2008 10:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_39=0.6, 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 1gqDAhEsJ8IL; Thu, 14 Feb 2008 10:17:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C99F28CFAF; Thu, 14 Feb 2008 10:17:16 -0800 (PST) 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 DF7513A7086 for ; Thu, 14 Feb 2008 10:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 FEUqPgKllC1J for ; Thu, 14 Feb 2008 10:17:14 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 1D3443A68A4 for ; Thu, 14 Feb 2008 10:17:14 -0800 (PST) Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Thu, 14 Feb 2008 10:17:43 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Feb 2008 10:16:57 -0800 Received: from nimbus-sc.juniper.net (nimbus-sc.juniper.net [172.16.12.13]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m1EIGVq56610; Thu, 14 Feb 2008 10:16:31 -0800 (PST) (envelope-from dkatz@juniper.net) Message-Id: <3AF13E92-9A08-4A8F-BB7A-3C69492C9D05@juniper.net> From: Dave Katz To: Carlos Pignataro In-Reply-To: <47B366E9.2090300@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: Small LC Comment on bfd-base-07 Date: Thu, 14 Feb 2008 10:16:31 -0800 References: <47B366E9.2090300@cisco.com> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 14 Feb 2008 18:16:57.0316 (UTC) FILETIME=[C8D12A40:01C86F35] Cc: BFD WG 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-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Good catch. The Diag field has morphed over the long lifetime of BFD, and the language about Down/AdminDown has obviously been overtaken by events. We'll have to wordsmith some vague language that points out that the Diag field says something about the last event of interest other than the session coming up. --Dave On Feb 13, 2008, at 1:53 PM, Carlos Pignataro wrote: > Hi, > > A quick comment on a possible small inconsistency that was brought > up in pwe3: In concatenated paths/iw, the Diag can have values of > 6/8 without the Session State being (Admin)Down: > > http://tools.ietf.org/html/draft-ietf-bfd-base-07#section-6.8.17 > > Two diagnostic codes are defined for this purpose: Concatenated > Path > Down and Reverse Concatenated Path Down. > ... > A system MAY signal one of these failure states by simply setting > bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD > session is not taken down. If Demand mode is not active on the > remote system, no other action is necessary, as the diagnostic code > will be carried via the periodic transmission of BFD Control > packets. > > But the definition of Diag (and bfd.LocalDiag) says (or implies) > that there needs to be a state change to Down or AdminDown: > > Diagnostic (Diag) > > A diagnostic code specifying the local system's reason for the > last session state change to states Down or AdminDown. > > bfd.LocalDiag > > The diagnostic code specifying the reason for the most recent > local session state change to states Down or AdminDown. > > Thanks, > > -- > --Carlos Pignataro. > Escalation RTP - cisco Systems > > From rtg-bfd-bounces@ietf.org Thu Feb 14 10:32:35 2008 Return-Path: X-Original-To: ietfarch-rtg-bfd-archive@core3.amsl.com Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1C553A70C1; Thu, 14 Feb 2008 10:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, 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 Cu2bYUPfLcs9; Thu, 14 Feb 2008 10:32:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B93853A68CC; Thu, 14 Feb 2008 10:32:35 -0800 (PST) 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 C502A3A68CC for ; Thu, 14 Feb 2008 10:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 0x1b2q0sRAWX for ; Thu, 14 Feb 2008 10:32:33 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8D1823A6871 for ; Thu, 14 Feb 2008 10:32:33 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 Feb 2008 13:33:55 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1EIXtIc032192; Thu, 14 Feb 2008 13:33:55 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1EIXrWD004329; Thu, 14 Feb 2008 18:33:53 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Feb 2008 13:33:52 -0500 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Feb 2008 13:33:52 -0500 In-Reply-To: <3AF13E92-9A08-4A8F-BB7A-3C69492C9D05@juniper.net> References: <47B366E9.2090300@cisco.com> <3AF13E92-9A08-4A8F-BB7A-3C69492C9D05@juniper.net> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <849C71E2-71A6-455E-8F4C-1DA4FBC4FFF2@cisco.com> Content-Transfer-Encoding: 7bit From: David Ward Subject: Re: Small LC Comment on bfd-base-07 Date: Thu, 14 Feb 2008 12:33:51 -0600 To: Dave Katz X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 14 Feb 2008 18:33:52.0671 (UTC) FILETIME=[26040AF0:01C86F38] Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: BFD WG , David Ward 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-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Vague language is also good if we need to add new/more diags and not be "trapped." -DWard On Feb 14, 2008, at 12:16 PM, Dave Katz wrote: > Good catch. The Diag field has morphed over the long lifetime of > BFD, and the language about Down/AdminDown has obviously been > overtaken by events. We'll have to wordsmith some vague language > that points out that the Diag field says something about the last > event of interest other than the session coming up. > > --Dave > > On Feb 13, 2008, at 1:53 PM, Carlos Pignataro wrote: > >> Hi, >> >> A quick comment on a possible small inconsistency that was brought >> up in pwe3: In concatenated paths/iw, the Diag can have values of >> 6/8 without the Session State being (Admin)Down: >> >> http://tools.ietf.org/html/draft-ietf-bfd-base-07#section-6.8.17 >> >> Two diagnostic codes are defined for this purpose: Concatenated >> Path >> Down and Reverse Concatenated Path Down. >> ... >> A system MAY signal one of these failure states by simply setting >> bfd.LocalDiag to the appropriate diagnostic code. Note that the >> BFD >> session is not taken down. If Demand mode is not active on the >> remote system, no other action is necessary, as the diagnostic code >> will be carried via the periodic transmission of BFD Control >> packets. >> >> But the definition of Diag (and bfd.LocalDiag) says (or implies) >> that there needs to be a state change to Down or AdminDown: >> >> Diagnostic (Diag) >> >> A diagnostic code specifying the local system's reason for the >> last session state change to states Down or AdminDown. >> >> bfd.LocalDiag >> >> The diagnostic code specifying the reason for the most >> recent >> local session state change to states Down or AdminDown. >> >> Thanks, >> >> -- >> --Carlos Pignataro. >> Escalation RTP - cisco Systems >> >> > From rtg-bfd-bounces@ietf.org Thu Feb 14 11:48:19 2008 Return-Path: X-Original-To: ietfarch-rtg-bfd-archive@core3.amsl.com Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D58528D0A3; Thu, 14 Feb 2008 11:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[AWL=1.703, 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 ZLhUCuw3euBy; Thu, 14 Feb 2008 11:48:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A483A708C; Thu, 14 Feb 2008 11:48:18 -0800 (PST) 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 122BD28D070 for ; Thu, 14 Feb 2008 11:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 qfHR3QWro4mx for ; Thu, 14 Feb 2008 11:48:17 -0800 (PST) Received: from manos.scc.mi.org (manos.scc.mi.org [204.11.140.250]) by core3.amsl.com (Postfix) with ESMTP id 288E93A68DA for ; Thu, 14 Feb 2008 11:48:17 -0800 (PST) Received: by manos.scc.mi.org (Postfix, from userid 1025) id A2CD14E4A2; Thu, 14 Feb 2008 14:49:38 -0500 (EST) Date: Thu, 14 Feb 2008 14:49:38 -0500 From: Jeffrey Haas To: David Ward Subject: Re: Small LC Comment on bfd-base-07 Message-ID: <20080214194938.GA23158@scc.mi.org> References: <47B366E9.2090300@cisco.com> <3AF13E92-9A08-4A8F-BB7A-3C69492C9D05@juniper.net> <849C71E2-71A6-455E-8F4C-1DA4FBC4FFF2@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <849C71E2-71A6-455E-8F4C-1DA4FBC4FFF2@cisco.com> User-Agent: Mutt/1.5.9i Cc: BFD WG , Dave Katz 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-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org On Thu, Feb 14, 2008 at 12:33:51PM -0600, David Ward wrote: > Vague language is also good if we need to add new/more diags and not > be "trapped." I think this may be less dire than you're implying. Consider the case where a session not in one of the down states always resets the Diagnostic to 0 when not in an error state. In order for the session to be reset, you must also reset to the down state. In the mean time, you've had the opportunity to pull the current Diagnostic off the wire. The BFD protocol itself need not necessarily cache this, but the management infrastructure probably should as part of the "I'm down!" callback. Thus, for example, the MIB could have a bfdSessDiagLastDown object along with the bfdSessDiag object which would represent the current diag value in the protocol. Trap objects become slightly more interesting because they'd might want to represent a transition out of diagnostic state 0 and potentially back. -- Jeff From rtg-bfd-bounces@ietf.org Thu Feb 14 11:53:08 2008 Return-Path: X-Original-To: ietfarch-rtg-bfd-archive@core3.amsl.com Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DB328D11D; Thu, 14 Feb 2008 11:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[AWL=1.460, 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 mvw0AlJzC5Mi; Thu, 14 Feb 2008 11:53:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFC7628D106; Thu, 14 Feb 2008 11:53:07 -0800 (PST) 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 48BBA28D106 for ; Thu, 14 Feb 2008 11:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 HNP9TtiIk1QL for ; Thu, 14 Feb 2008 11:53:06 -0800 (PST) Received: from manos.scc.mi.org (manos.scc.mi.org [204.11.140.250]) by core3.amsl.com (Postfix) with ESMTP id 8EB3D28D0FF for ; Thu, 14 Feb 2008 11:53:06 -0800 (PST) Received: by manos.scc.mi.org (Postfix, from userid 1025) id 413B24E4A2; Thu, 14 Feb 2008 14:54:28 -0500 (EST) Date: Thu, 14 Feb 2008 14:54:28 -0500 From: Jeffrey Haas To: Jeffrey Haas Subject: Re: Small LC Comment on bfd-base-07 Message-ID: <20080214195428.GA18178@scc.mi.org> References: <47B366E9.2090300@cisco.com> <3AF13E92-9A08-4A8F-BB7A-3C69492C9D05@juniper.net> <849C71E2-71A6-455E-8F4C-1DA4FBC4FFF2@cisco.com> <20080214194938.GA23158@scc.mi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080214194938.GA23158@scc.mi.org> User-Agent: Mutt/1.5.9i Cc: BFD WG , David Ward , Dave Katz 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-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org On Thu, Feb 14, 2008 at 02:49:38PM -0500, Jeffrey Haas wrote: > Thus, for example, the MIB could have a bfdSessDiagLastDown object along Tom and Zafar had already caught this: bfdSessPerfLastCommLostDiag -- Jeff From rtg-bfd-bounces@ietf.org Thu Feb 28 14:16:52 2008 Return-Path: X-Original-To: ietfarch-rtg-bfd-archive@core3.amsl.com Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEC6528C788; Thu, 28 Feb 2008 14:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.003 X-Spam-Level: X-Spam-Status: No, score=-4.003 tagged_above=-999 required=5 tests=[AWL=2.596, 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 yLBD0ih1Seui; Thu, 28 Feb 2008 14:16:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9738128C3CB; Thu, 28 Feb 2008 14:16:52 -0800 (PST) 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 7430528C385 for ; Thu, 28 Feb 2008 14:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 fRykKgHWrWz2 for ; Thu, 28 Feb 2008 14:16:45 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 70E893A6AE1 for ; Thu, 28 Feb 2008 14:16:45 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m1SMGc607142 for ; Thu, 28 Feb 2008 17:16:38 -0500 (EST) Received: from [64.102.159.125] (dhcp-64-102-159-125.cisco.com [64.102.159.125]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m1SMHGu16806; Thu, 28 Feb 2008 17:17:16 -0500 (EST) Message-ID: <47C732C5.60608@cisco.com> Date: Thu, 28 Feb 2008 17:16:37 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: BFD WG Subject: WGLC comments on bfd-mpls-05 X-Enigmail-Version: 0.95.6 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Please find a couple of comments regarding bfd-mpls-05. I realize this is way past end of WGLC, but I hope the comments are useful and can be given consideration. 3.1. BFD for MPLS LSPs: Motivation The LSP may be associated with any of the following FECs: a) RSVP IPv4/IPv6 Session [RFC3209] b) LDP IPv4/IPv6 prefix [RFC3036] c) VPN IPv4/IPv6 prefix [RFC4364] d) Layer 2 VPN [L2-VPN] e) Layer 2 Circuit ID [RFC4447] Does item e) refer to both the PWid FEC and the Generalized PWid FEC (128 and 129)? Are BGP Labeled IPv4/IPv6 prefixes [RFC3107] excluded for a reason? Also, for the e) FECs, there is the VCCV signaling aspects to be considered, from RFC4447 / RFC5085 to provide the VCCV control channel associated with the PW before BFD could be sent. Please also see last comment. --- 3.2. Using BFD in Conjunction with LSP-Ping a) Association of a LSP-Ping echo request message with a FEC. In the case of Penultimate Hop Popping (PHP), for a single label stack LSP, the only way to associate a fault detection message with a FEC is by carrying the FEC in the message. Is this the case not only for PHP but also for UHP with exp-null? Additionally for aggregated FECs in general (e.g., in the case of per-VRF label vs. per-VPNv4-FEC label, etc) the same applies but OTOH there would need to be only one BFD session per "vrf aggregated fec" (since it's the same label stack for different VPNv4 FECs, and the LSP being tested is identical), correct? Could this be clarified in the document? LSP-Ping provides this functionality. Next-hop label allocation also makes it necessary to carry the FEC in the fault detection message as the label alone is not sufficient to identify the LSP being verified. ... i) LSP-Ping is used for boot-strapping the BFD session as described later in this document. There seem to be cases where there is no need for boot-strapping the BFD session with LSP-Ping. For example, for PWs, both ends can start sending BFD Control messages with Your Discr value of zero in an Active role, as the PW Label provides the context to bootstrap the session. --- 4. Theory of Operation If there are multiple alternate paths from an ingress LSR to an egress LSR for a LDP IP FEC, LSP-Ping traceroute MAY be used to determine each of these alternate paths. A BFD session SHOULD be established for each alternate path that is discovered. There may also be multiple ECMPs for other FECs, like VPNv4/VPNv6 prefixes. Does this SHOULD apply to those as well? For other FECs, there wouldn't be ECMPs (e.g., PWs RFC 4928), should that be explicitly mentioned? --- 5. Initialization and Demultiplexing A BFD session may be established for a FEC associated with a MPLS LSP. As desribed above in the case of PHP and next-hop label allocation the BFD control packet received by the egress LSR does not contain sufficient information to associate it with a BFD session. Hence the demultiplexing MUST be done using the remote discriminator field in the received BFD control packet. The exchange of BFD discriminators for this purpose is described in the next section. 6. Session Establishment To establish a BFD session a LSP-Ping echo request message MUST carry the local discriminator assigned by the ingress LSR for the BFD session. This MUST subsequently be used as the My Discriminator field in the BFD session packets sent by the ingress LSR. There seem to be other additional cases besides PHP where discriminators need to be exchanged/boot-strapped (e.g., UHP and single label), but situations where it's not needed (e.g., PWs). Should these cases be enumerated/framed or clarified? Is this "MUST" (the first one in Section 6) too strong considering cases where bootstrapping with LSP-Ping is not needed (e.g., PWs) or should the MUST be conditioned to the cases where is needed? --- 6. Session Establishment On receipt of the LSP-Ping echo request message, the egress LSR MUST send a BFD control packet to the ingress LSR. ... 7. Encapsulation BFD control packets sent by the egress LSR are UDP packets. The source IP address is a routable address of the replier; the source port is the well-known UDP port 3784. The destination IP address and UDP port MUST be copied from the source IP address and UDP port of the control packet received from the ingress LSR. LSP-Ping (ingress->egress) is used to exchange the ingress My Discriminator. And then a BFD Control packet (egress->ingress) is used to exchange the egress My Discriminator. Section 6 says that the egress replies with a BFD Control packet (before it has received a BFD Control packet from ingress), and Section 7 says that the egress copies the dest UDP port from the source's ingress. Therefore it seems that the destination UDP Port of the first BFD Control packet (from egress to ingress) is unspecified, and could be anything in the [49152 .. 65535] range since: The BFD control packet sent by the ingress LSR MUST be a UDP packet with a well known destination port 3784 [BFD-IP] and a source port assigned by the sender as per the procedures in [BFD-IP]. Should the egress use also 3784 as destination port in the first BFD Control packet? Should the port be also included in the LSP-Ping message? Or should the UDP port be allowed to change in the first packet from the ingress->egress? If the egress uses 3784 as dest UDP port, these two requirements from [BFD-IP] seem to end up contradicting on this case: The same UDP source port number MUST be used for all BFD Control packets associated with a particular session. The source port number SHOULD be unique among all BFD sessions on the system. ... but the number of distinct uses of the same UDP source port number SHOULD be minimize So that would seem to leave the other two options (send the UDP Port in the LSP-Ping, or allow for the UDP Port to change during the handshake. --- 7. Encapsulation For MPLS PWs, alternatively, the presence of a fault detection message may be indicated by setting a bit in the control word [VCCV]. This procedure needs signaling or static configuration to create the VCCV control channel before BFD packets could be exchanged over the control channel (with the bit in the CW). Are more details needed? See below as well. --- 7. Encapsulation In this case the destination IP address, used in a BFD session established for one such alternate path, is the address in the 127/8 range discovered by LSP-ping traceroute [RFC4379] to exercise that particular alternate path. A nit, where it says "is the address", there may be (and typically will be) multiple addresses from 127/8 to exercise a particular ECMP. Should that say "is one address from the 127/8 ... that exercises..."? Also, there is no mention of BFD Echo adjunct function to the asynchronous mode. --- 11.2. Informative References [VCCV] T. Nadeau, C. Pignataro, R. Aggarwal, "Pseudo Wire (PW) Virtual Circuit Connection Verification ((VCCV)", draft-ietf-pwe3-vccv-13.txt This reference points to rev 13 of this document. In the subsequent revision, this document was split into what resulted in RFC 5085 and the ID draft-ietf-pwe3-vccv-bfd. It seems that some citations refer to the former, while others to the latter, and they appear to be made in a Normative fashion (e.g., because the VCCV control channel needs to exist in order to send BFD packets over it). However, given that PWs need an associated VCCV control channel, do not need LSP-Ping boot-strapping (as can get the context from the PW label), should this document point to draft-ietf-pwe3-vccv-bfd (that goes into different BFD functional modes) for the PW case instead of also defining it here, since it has a number of specific unique issues? Thanks, -- --Carlos Pignataro. Escalation RTP - cisco Systems From rtg-bfd-bounces@ietf.org Fri Feb 29 05:27:07 2008 Return-Path: X-Original-To: ietfarch-rtg-bfd-archive@core3.amsl.com Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506B728C6AF; Fri, 29 Feb 2008 05:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.059 X-Spam-Level: * X-Spam-Status: No, score=1.059 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, HTML_MESSAGE=1, J_CHICKENPOX_75=0.6, MIME_QP_LONG_LINE=1.396, RELAY_IS_203=0.994] 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 Ryuqd62YXJ4H; Fri, 29 Feb 2008 05:27:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D02828C2E3; Fri, 29 Feb 2008 05:27:07 -0800 (PST) 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 38F7A3A6A56 for ; Fri, 29 Feb 2008 05:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 MVIpAXMq9mbg for ; Fri, 29 Feb 2008 05:27:01 -0800 (PST) Received: from gws04.hcl.in (gws04.mail.hcl.in [203.105.186.20]) by core3.amsl.com (Postfix) with ESMTP id A874E28C2E3 for ; Fri, 29 Feb 2008 05:27:00 -0800 (PST) Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id DDD11360118 for ; Fri, 29 Feb 2008 18:56:50 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws04.hcl.in (Postfix) with ESMTP id D1FA136002Bfor ; Fri, 29 Feb 2008 18:56:50 +0530 (IST) Received: from CHN-HCLT-EVS01.HCLT.CORP.HCL.IN ([10.101.26.15]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 18:56:49 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [BFD] bfd-mpls-05 Date: Fri, 29 Feb 2008 18:56:36 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BFD] bfd-mpls-05 thread-index: Ach6V524HEMtqqH+QQyYX5ZEIwChqgAeFOKz References: <47C732C5.60608@cisco.com> From: "Damodharan SP - TLS , Chennai" To: X-OriginalArrivalTime: 29 Feb 2008 13:26:49.0513 (UTC) FILETIME=[BD277990:01C87AD6] X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-20.4425 TC:1F TRN:93 TV:5.0.1023(15758.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Type: multipart/mixed; boundary="=_Boundary_oGmeWdOcB0aVkVDj9fQ6" 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-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org This is a multi-part message in MIME format. --=_Boundary_oGmeWdOcB0aVkVDj9fQ6 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable WGLC comments on bfd-mpls-05=0A= =0A= =0A= =0A=
=0A=
Hi,
=0A=
   As per my = understanding of bfd mpls and the comments from = the below mail
=0A=
 
=0A=
   In = "draft-ietf-bfd-mpls-05.txt"
=0A=
       The UDP destination port = to be used for control packets from egress to ingress is not = clear.
=0A=
       
=0A=
   case = 1.  "BFD control packets sent by the egress LSR are UDP = packets. The
       source IP address = is a routable address of the replier; the = source
       port is the well-known UDP = port 3784.  The destination IP address = and
       UDP port MUST be copied from = the source IP address and UDP port of
       = the control packet received from the ingress LSR."
=0A=

       -> It means = that the UDP destination port for the packet from egress to = ingress
=0A=
           = should be copied from source udp port of the packet received the = ingress.
=0A=
     
=0A=
  case =  2.  "The BFD control packet sent by the egress LSR to = the ingress LSR MAY
       be routed = based on the destination IP address as per the = procedures
       in = [BFD-MHOP]."
=0A=
 
=0A=
       BFD-MHOP("draft-ietf-bfd-multihop-06.txt") = :
=0A=
       "The encapsulation of = BFD Control packets for multihop application = in
        IPv4 and IPv6 is = identical to that defined in [BFD-1HOP], except = that
        the UDP = destination port MUST have a value of 4784.  This can aid = in  
        the = demultiplexing and internal routing of incoming BFD = packets."
=0A=
          
=0A=
       -> It means that = the UDP destination port must be 4784.
=0A=

So =  1. Which UDP destination port to use for the control packet from = egress to ingress (case 1 or case 2)?
=0A=
      2. Destination IP address to be = used for the control packets from egress to ingress
=0A=
          before = receiving the bfd packets from ingress(after BFD Discriminator TLV is = exchanged by lsp ping)?
=0A=
 
=0A=
Regards,
=0A=
Damodharan.S
=0A=
=0A=
=0A=
=0A=
From: = rtg-bfd-bounces@ietf.org on behalf of Carlos Pignataro
Sent: = Fri 2/29/2008 3:46 AM
To: BFD WG
Subject: WGLC = comments on bfd-mpls-05

=0A=

=0A=

Please find a couple of comments regarding = bfd-mpls-05. I realize this
is way past end of WGLC, but I hope the = comments are useful and can be
given consideration.


3.1. = BFD for MPLS LSPs: = Motivation

       The LSP may = be  associated with any of the following = FECs:
         a) RSVP = IPv4/IPv6 Session = [RFC3209]
         b) LDP = IPv4/IPv6 prefix = [RFC3036]
         c) VPN = IPv4/IPv6 prefix = [RFC4364]
         d) Layer 2 = VPN [L2-VPN]
         e) = Layer 2 Circuit ID [RFC4447]

Does item e) refer to both the PWid = FEC and the Generalized PWid FEC
(128 and 129)?

Are BGP = Labeled IPv4/IPv6 prefixes [RFC3107] excluded for a reason?

Also, = for the e) FECs, there is the VCCV signaling aspects to = be
considered, from RFC4447 / RFC5085 to provide the VCCV control = channel
associated with the PW before BFD could be sent. Please also = see last
comment.

---

3.2. Using BFD in Conjunction = with LSP-Ping

        a) = Association of a LSP-Ping echo request message with a FEC. = In
      the case of Penultimate Hop Popping = (PHP), for a single label stack
      LSP, = the only way to associate a fault detection message with a = FEC
      is by carrying the FEC in the = message.

Is this the case not only for PHP but also for UHP with = exp-null?
Additionally for aggregated FECs in general (e.g., in the = case of
per-VRF label vs. per-VPNv4-FEC label, etc) the same applies = but OTOH
there would need to be only one BFD session per "vrf = aggregated fec"
(since it's the same label stack for different VPNv4 = FECs, and the LSP
being tested is identical), correct? Could this be = clarified in the
document?

      = LSP-Ping provides this
      functionality. = Next-hop label allocation also makes it necessary = to
      carry the FEC in the fault = detection message as the label alone = is
      not sufficient to identify the LSP = being verified.
...
      i) LSP-Ping is = used for boot-strapping the BFD session as = described
      later in this = document.

There seem to be cases where there is no need for = boot-strapping the BFD
session with LSP-Ping. For example, for PWs, = both ends can start sending
BFD Control messages with Your Discr = value of zero in an Active role, as
the PW Label provides the context = to bootstrap the session.

---

4. Theory of = Operation

      If there are multiple = alternate paths from an ingress LSR to = an
      egress LSR for a LDP IP FEC, = LSP-Ping traceroute MAY be used to
      = determine each of these alternate paths. A BFD session SHOULD = be
      established for each alternate path = that is discovered.

There may also be multiple ECMPs for other = FECs, like VPNv4/VPNv6
prefixes. Does this SHOULD apply to those as = well? For other FECs, there
wouldn't be ECMPs (e.g., PWs RFC 4928), = should that be explicitly mentioned?

---

5. Initialization = and Demultiplexing


    A BFD session may be = established for a FEC associated with a MPLS
    LSP. = As desribed above in the case of PHP and next-hop = label
    allocation the BFD control packet received = by the egress LSR does not
    contain sufficient = information to associate it with a BFD session.
    = Hence the demultiplexing MUST be done using the remote = discriminator
    field in the received BFD control = packet. The exchange of BFD
    discriminators for = this purpose is described in the next section.

6. Session = Establishment

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

There seem to be other = additional cases besides PHP where discriminators
need to be = exchanged/boot-strapped (e.g., UHP and single label), but
situations = where it's not needed (e.g., PWs). Should these cases = be
enumerated/framed or clarified? Is this "MUST" (the first one in = Section
6) too strong considering cases where bootstrapping with = LSP-Ping is not
needed (e.g., PWs) or should the MUST be conditioned = to the cases where
is needed?

---

6. Session = Establishment

    On receipt of the LSP-Ping echo = request message, the egress LSR MUST
    send a BFD = control packet to the ingress LSR.
...
7. = Encapsulation

    BFD control packets sent by the = egress LSR are UDP packets. The
    source IP address = is a routable address of the replier; the source
    = port is the well-known UDP port 3784.  The destination IP address = and
    UDP port MUST be copied from the source IP = address and UDP port of
    the control packet = received from the ingress LSR.

LSP-Ping (ingress->egress) is = used to exchange the ingress My
Discriminator. And then a BFD Control = packet (egress->ingress) is used
to exchange the egress My = Discriminator. Section 6 says that the egress
replies with a BFD = Control packet (before it has received a BFD Control
packet from = ingress), and Section 7 says that the egress copies the dest
UDP port = from the source's ingress. Therefore it seems that the
destination = UDP Port of the first BFD Control packet (from egress to
ingress) is = unspecified, and could be anything in the [49152 .. 65535]
range = since:

    The BFD control packet sent by the = ingress LSR MUST be a UDP packet
    with a well known = destination port 3784 [BFD-IP] and a source port
    = assigned by the sender as per the procedures in [BFD-IP].

Should = the egress use also 3784 as destination port in the first BFD
Control = packet? Should the port be also included in the LSP-Ping
message? Or = should the UDP port be allowed to change in the first packet
from the = ingress->egress?
If the egress uses 3784 as dest UDP port, these = two requirements from
[BFD-IP] seem to end up contradicting on this = case:

    The same UDP
    = source port number MUST be used for all BFD Control = packets
    associated with a particular = session.  The source port number SHOULD
    be = unique among all BFD sessions on the system.
    = ...
    but the number of distinct uses = of
    the same UDP source port number SHOULD be = minimize

So that would seem to leave the other two options (send = the UDP Port in
the LSP-Ping, or allow for the UDP Port to change = during the handshake.

---

7. = Encapsulation

    For MPLS PWs, = alternatively,
    the presence of a fault detection = message may be indicated by setting
    a bit in the = control word [VCCV].

This procedure needs signaling or static = configuration to create the
VCCV control channel before BFD packets = could be exchanged over the
control channel (with the bit in the CW). = Are more details needed? See
below as well.

---

7. = Encapsulation

      In this case the = destination IP address, used in a
      BFD = session established for one such alternate path, is the = address
      in the 127/8 range discovered = by LSP-ping traceroute [RFC4379] to
      = exercise that particular alternate path.

A nit, where it says "is = the address", there may be (and typically will
be) multiple addresses = from 127/8 to exercise a particular ECMP. Should
that say "is one = address from the 127/8 ... that exercises..."?

Also, there is no = mention of BFD Echo adjunct function to the
asynchronous = mode.

---

11.2. Informative = References

      = [VCCV]     T. Nadeau, C. Pignataro, R. = Aggarwal,
          =        "Pseudo Wire (PW) Virtual Circuit = Connection = Verification
         &nb= sp;       ((VCCV)", = draft-ietf-pwe3-vccv-13.txt

This reference points to rev 13 of = this document. In the subsequent
revision, this document was split = into what resulted in RFC 5085 and the
ID draft-ietf-pwe3-vccv-bfd. = It seems that some citations refer to the
former, while others to the = latter, and they appear to be made in a
Normative fashion (e.g., = because the VCCV control channel needs to exist
in order to send BFD = packets over it).
However, given that PWs need an associated VCCV = control channel, do not
need LSP-Ping boot-strapping (as can get the = context from the PW label),
should this document point to = draft-ietf-pwe3-vccv-bfd (that goes into
different BFD functional = modes) for the PW case instead of also defining
it here, since it has = a number of specific unique issues?

Thanks,

--
--Carlos = Pignataro.
Escalation RTP - cisco = Systems



--=_Boundary_oGmeWdOcB0aVkVDj9fQ6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- --=_Boundary_oGmeWdOcB0aVkVDj9fQ6-- From rtg-bfd-bounces@ietf.org Fri Feb 29 08:38:21 2008 Return-Path: X-Original-To: ietfarch-rtg-bfd-archive@core3.amsl.com Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 048DA28C68C; Fri, 29 Feb 2008 08:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.795 X-Spam-Level: X-Spam-Status: No, score=-3.795 tagged_above=-999 required=5 tests=[AWL=2.204, BAYES_00=-2.599, J_CHICKENPOX_75=0.6, 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 R78S9gJEBxsC; Fri, 29 Feb 2008 08:38:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E41228C42C; Fri, 29 Feb 2008 08:38:20 -0800 (PST) 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 412B93A67D0 for ; Fri, 29 Feb 2008 08:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 eEMQtr8CE58p for ; Fri, 29 Feb 2008 08:38:12 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 3DF5028C608 for ; Fri, 29 Feb 2008 08:37:42 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m1TGbYu19303; Fri, 29 Feb 2008 11:37:34 -0500 (EST) Received: from [64.102.159.125] (dhcp-64-102-159-125.cisco.com [64.102.159.125]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m1TGcCu20122; Fri, 29 Feb 2008 11:38:12 -0500 (EST) Message-ID: <47C834CE.6010607@cisco.com> Date: Fri, 29 Feb 2008 11:37:34 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: "Damodharan SP - TLS , Chennai" Subject: Re: [BFD] bfd-mpls-05 References: <47C732C5.60608@cisco.com> In-Reply-To: X-Enigmail-Version: 0.95.6 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org On 2/29/2008 8:26 AM, Damodharan SP - TLS , Chennai said the following: > Hi, > As per my understanding of bfd mpls and the comments from the below mail > > In "draft-ietf-bfd-mpls-05.txt" > The UDP destination port to be used for control packets from > egress to ingress is not clear. > > case 1. "BFD control packets sent by the egress LSR are UDP packets. The > source IP address is a routable address of the replier; the source > port is the well-known UDP port 3784. The destination IP address and > UDP port MUST be copied from the source IP address and UDP port of > the control packet received from the ingress LSR." > > -> It means that the UDP destination port for the packet from > egress to ingress > should be copied from source udp port of the packet received > the ingress. > > case 2. "The BFD control packet sent by the egress LSR to the > ingress LSR MAY > be routed based on the destination IP address as per the procedures > in [BFD-MHOP]." > > BFD-MHOP("draft-ietf-bfd-multihop-06.txt > ") > : > "The encapsulation of BFD Control packets for multihop application in > IPv4 and IPv6 is identical to that defined in [BFD-1HOP > ], > except that > the UDP destination port MUST have a value of 4784. This can > aid in > the demultiplexing and internal routing of incoming BFD packets." > > -> It means that the UDP destination port must be 4784. > > So 1. Which UDP destination port to use for the control packet from > egress to ingress (case 1 or case 2)? > 2. Destination IP address to be used for the control packets from > egress to ingress > before receiving the bfd packets from ingress(after BFD > Discriminator TLV is exchanged by lsp ping)? Perhaps one direct solution is to require the egress send it's local discriminator in an LSP-Ping echo reply (currently MAY), and have the LSP ingress LSR send the first BFD Control packet. Like: On receipt of the LSP-Ping echo request message, the egress LSR MUST reply with an LSP-Ping echo reply message conveying its own local discriminator assigned by it to the BFD session for the LSP. ... Once the ingress LSR learns the local discriminator assigned by the egress LSR for a given BFD session from the LSP-Ping reply, it MUST send a BFD control packet... Or have the egress chose the source port in the BFD control packet and use the well-known port as destination. Thanks, --Carlos. > > Regards, > Damodharan.S > ------------------------------------------------------------------------ > *From:* rtg-bfd-bounces@ietf.org on behalf of Carlos Pignataro > *Sent:* Fri 2/29/2008 3:46 AM > *To:* BFD WG > *Subject:* WGLC comments on bfd-mpls-05 > > > Please find a couple of comments regarding bfd-mpls-05. I realize this > is way past end of WGLC, but I hope the comments are useful and can be > given consideration. > > > 3.1. BFD for MPLS LSPs: Motivation > > The LSP may be associated with any of the following FECs: > a) RSVP IPv4/IPv6 Session [RFC3209] > b) LDP IPv4/IPv6 prefix [RFC3036] > c) VPN IPv4/IPv6 prefix [RFC4364] > d) Layer 2 VPN [L2-VPN] > e) Layer 2 Circuit ID [RFC4447] > > Does item e) refer to both the PWid FEC and the Generalized PWid FEC > (128 and 129)? > > Are BGP Labeled IPv4/IPv6 prefixes [RFC3107] excluded for a reason? > > Also, for the e) FECs, there is the VCCV signaling aspects to be > considered, from RFC4447 / RFC5085 to provide the VCCV control channel > associated with the PW before BFD could be sent. Please also see last > comment. > > --- > > 3.2. Using BFD in Conjunction with LSP-Ping > > a) Association of a LSP-Ping echo request message with a FEC. In > the case of Penultimate Hop Popping (PHP), for a single label stack > LSP, the only way to associate a fault detection message with a FEC > is by carrying the FEC in the message. > > Is this the case not only for PHP but also for UHP with exp-null? > Additionally for aggregated FECs in general (e.g., in the case of > per-VRF label vs. per-VPNv4-FEC label, etc) the same applies but OTOH > there would need to be only one BFD session per "vrf aggregated fec" > (since it's the same label stack for different VPNv4 FECs, and the LSP > being tested is identical), correct? Could this be clarified in the > document? > > LSP-Ping provides this > functionality. Next-hop label allocation also makes it necessary to > carry the FEC in the fault detection message as the label alone is > not sufficient to identify the LSP being verified. > ... > i) LSP-Ping is used for boot-strapping the BFD session as described > later in this document. > > There seem to be cases where there is no need for boot-strapping the BFD > session with LSP-Ping. For example, for PWs, both ends can start sending > BFD Control messages with Your Discr value of zero in an Active role, as > the PW Label provides the context to bootstrap the session. > > --- > > 4. Theory of Operation > > If there are multiple alternate paths from an ingress LSR to an > egress LSR for a LDP IP FEC, LSP-Ping traceroute MAY be used to > determine each of these alternate paths. A BFD session SHOULD be > established for each alternate path that is discovered. > > There may also be multiple ECMPs for other FECs, like VPNv4/VPNv6 > prefixes. Does this SHOULD apply to those as well? For other FECs, there > wouldn't be ECMPs (e.g., PWs RFC 4928), should that be explicitly mentioned? > > --- > > 5. Initialization and Demultiplexing > > > A BFD session may be established for a FEC associated with a MPLS > LSP. As desribed above in the case of PHP and next-hop label > allocation the BFD control packet received by the egress LSR does not > contain sufficient information to associate it with a BFD session. > Hence the demultiplexing MUST be done using the remote discriminator > field in the received BFD control packet. The exchange of BFD > discriminators for this purpose is described in the next section. > > 6. Session Establishment > > To establish a BFD session a LSP-Ping echo > request message MUST carry the local discriminator assigned by the > ingress LSR for the BFD session. This MUST subsequently be used as > the My Discriminator field in the BFD session packets sent by the > ingress LSR. > > There seem to be other additional cases besides PHP where discriminators > need to be exchanged/boot-strapped (e.g., UHP and single label), but > situations where it's not needed (e.g., PWs). Should these cases be > enumerated/framed or clarified? Is this "MUST" (the first one in Section > 6) too strong considering cases where bootstrapping with LSP-Ping is not > needed (e.g., PWs) or should the MUST be conditioned to the cases where > is needed? > > --- > > 6. Session Establishment > > On receipt of the LSP-Ping echo request message, the egress LSR MUST > send a BFD control packet to the ingress LSR. > ... > 7. Encapsulation > > BFD control packets sent by the egress LSR are UDP packets. The > source IP address is a routable address of the replier; the source > port is the well-known UDP port 3784. The destination IP address and > UDP port MUST be copied from the source IP address and UDP port of > the control packet received from the ingress LSR. > > LSP-Ping (ingress->egress) is used to exchange the ingress My > Discriminator. And then a BFD Control packet (egress->ingress) is used > to exchange the egress My Discriminator. Section 6 says that the egress > replies with a BFD Control packet (before it has received a BFD Control > packet from ingress), and Section 7 says that the egress copies the dest > UDP port from the source's ingress. Therefore it seems that the > destination UDP Port of the first BFD Control packet (from egress to > ingress) is unspecified, and could be anything in the [49152 .. 65535] > range since: > > The BFD control packet sent by the ingress LSR MUST be a UDP packet > with a well known destination port 3784 [BFD-IP] and a source port > assigned by the sender as per the procedures in [BFD-IP]. > > Should the egress use also 3784 as destination port in the first BFD > Control packet? Should the port be also included in the LSP-Ping > message? Or should the UDP port be allowed to change in the first packet > from the ingress->egress? > If the egress uses 3784 as dest UDP port, these two requirements from > [BFD-IP] seem to end up contradicting on this case: > > The same UDP > source port number MUST be used for all BFD Control packets > associated with a particular session. The source port number SHOULD > be unique among all BFD sessions on the system. > ... > but the number of distinct uses of > the same UDP source port number SHOULD be minimize > > So that would seem to leave the other two options (send the UDP Port in > the LSP-Ping, or allow for the UDP Port to change during the handshake. > > --- > > 7. Encapsulation > > For MPLS PWs, alternatively, > the presence of a fault detection message may be indicated by setting > a bit in the control word [VCCV]. > > This procedure needs signaling or static configuration to create the > VCCV control channel before BFD packets could be exchanged over the > control channel (with the bit in the CW). Are more details needed? See > below as well. > > --- > > 7. Encapsulation > > In this case the destination IP address, used in a > BFD session established for one such alternate path, is the address > in the 127/8 range discovered by LSP-ping traceroute [RFC4379] to > exercise that particular alternate path. > > A nit, where it says "is the address", there may be (and typically will > be) multiple addresses from 127/8 to exercise a particular ECMP. Should > that say "is one address from the 127/8 ... that exercises..."? > > Also, there is no mention of BFD Echo adjunct function to the > asynchronous mode. > > --- > > 11.2. Informative References > > [VCCV] T. Nadeau, C. Pignataro, R. Aggarwal, > "Pseudo Wire (PW) Virtual Circuit Connection Verification > ((VCCV)", draft-ietf-pwe3-vccv-13.txt > > This reference points to rev 13 of this document. In the subsequent > revision, this document was split into what resulted in RFC 5085 and the > ID draft-ietf-pwe3-vccv-bfd. It seems that some citations refer to the > former, while others to the latter, and they appear to be made in a > Normative fashion (e.g., because the VCCV control channel needs to exist > in order to send BFD packets over it). > However, given that PWs need an associated VCCV control channel, do not > need LSP-Ping boot-strapping (as can get the context from the PW label), > should this document point to draft-ietf-pwe3-vccv-bfd (that goes into > different BFD functional modes) for the PW case instead of also defining > it here, since it has a number of specific unique issues? > > Thanks, > > -- > --Carlos Pignataro. > Escalation RTP - cisco Systems > > > > > ------------------------------------------------------------------------ > > DISCLAIMER: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of > this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- -- --Carlos Pignataro. Escalation RTP - cisco Systems