From nobody Wed Jun 4 08:06:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CD11A0277 for ; Wed, 4 Jun 2014 08:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ-exr3dFrlN for ; Wed, 4 Jun 2014 08:06:47 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CBA271A02E3 for ; Wed, 4 Jun 2014 08:06:41 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A4EA4C2A4; Wed, 4 Jun 2014 11:06:35 -0400 (EDT) Date: Wed, 4 Jun 2014 11:06:35 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: [mcr+ietf@sandelman.ca: second call: NomCom 2014-2015 Call for Volunteers] Message-ID: <20140604150635.GB7069@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/WyxxH-KNBp1NGgBRJY-2RQYWyfA X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jun 2014 15:06:49 -0000 ----- Forwarded message from Michael Richardson ----- Date: Tue, 03 Jun 2014 15:17:47 -0400 From: Michael Richardson To: ietf@ietf.org, WG Chairs Subject: second call: NomCom 2014-2015 Call for Volunteers The IETF nominating committee (nomcom) process for 2014-15 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG (including IETF Chair). This is the second call for volunteers. (and you may have seen it more than once) If your name is on the below, then you have volunteered and are qualified. If you have heard from me, but are not on the list, then there is some problem, and you should have gotten a query from me to determine your eligibility. If you have volunteered and not heard from him, then please resend; it got lost. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. Let's break the 200 volunteer mark again this year! We are at 54 volunteers so far. The details of the operation of the nomcom can be found in RFC 3777, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are IETF 85(Atlanta), \ 86(Orlando), \ 87(Berlin), *** ANY THREE! 88(Vancouver), / 89(London) / If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2015 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: To be confirmed IAB: Joel Halpern Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler IESG: Pete Resnick (Applications) Ted Lemon (Internet) Joel Jaeggli (Operations and Management) Richard Barnes (RAI) Adrian Farrel* (Routing) Stephen Farrell (Security) Spencer Dawkins (Transport) Jari Arkko (Gen) (names with * have publically indicated they will not serve another term) The primary activity for this nomcom will begin in July 2014 and should be completed in January 2015. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is also a very rewarding experience. It is very important that you be able to attend IETF91 to conduct interviews. Being at IETF90 is useful for training. Being at IETF92 is not essential. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 22, 2013, as follows: To: nomcom-chair-2014@ietf.org Subject: Nomcom 2014-15 Volunteer Please include the following information in the email body: Your Full Name: __________-- Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: _______________ [] Telephone: _______________________ // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2014/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Michael Richardson mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org ===== qualified volunteers so far, in alphabetical order by first name ANM Zaheduzzaman Sarker Adam Montville Bill VerSteeg Carl Williams Carlos Martinez Charles Eckel DHRUV DHODY Dacheng Zhang Dapeng Liu Donald Eastlake Eric VYNCKE Fernando Gont Fred Baker Gonzalo Salgueiro Hongyu Li Hosnieh Rafiee Hugo Salgado John E Drake John Levine John Scudder Linda Dunbar Lingli Deng Louis (Lou) Berger Luca Martini Lucy Yong Mach Chen Mark Townsley Matt Lepinski Mehmet Ersue Melinda Shore Min Ye Ning Zong Ole Troan Pascal Thubert Paul Hoffman Peter Yee Ralph Droms Ron Bonica Ross Callon Ross Finlayson Sam K. Aldrin Sanjay Mishra Sheng JIANG Shucheng Liu Stephan Friedl Stephan Wenger Stephen Kent Suhas Nandakumar Tim Wicinski Tissa Senevirathne Toerless Eckert Wassim Haddad Xiaohu XU Yuanlong Jiang -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- ----- End forwarded message ----- From nobody Wed Jun 4 09:09:47 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011271A02FE; Wed, 4 Jun 2014 09:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JinxrNNGcaLU; Wed, 4 Jun 2014 09:09:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6233F1A0302; Wed, 4 Jun 2014 09:09:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-mib-22.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140604160938.18618.50146.idtracker@ietfa.amsl.com> Date: Wed, 04 Jun 2014 09:09:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/qA1u92qG2NGGuUOhXbO1b50nCEE Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 16:09:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD Management Information Base Authors : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-mib-22.txt Pages : 38 Date : 2014-06-04 Abstract: This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-mib-22 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-mib-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 5 09:30:48 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621531A0193 for ; Thu, 5 Jun 2014 09:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6--h3nkDQeXw for ; Thu, 5 Jun 2014 09:30:45 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3DD1A023E for ; Thu, 5 Jun 2014 09:30:44 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s55GUSDC023310; Thu, 5 Jun 2014 17:30:28 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s55GUR39023298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Jun 2014 17:30:28 +0100 From: "Adrian Farrel" To: , References: <20140529171320.29323.7853.idtracker@ietfa.amsl.com> <01b301cf7c05$dd290f10$977b2d30$@olddog.co.uk> <53888792.1020101@cisco.com> In-Reply-To: <53888792.1020101@cisco.com> Subject: RE: FW: Internal WG Review: Recharter of Bidirectional Forwarding Detection (bfd) Date: Thu, 5 Jun 2014 17:30:27 +0100 Message-ID: <000701cf80db$75e663e0$61b32ba0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFwRIDYOQ03pWsxXfvckQbJJkw1EAGq62j/ANtvccKcDO71AA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20740.000 X-TM-AS-Result: No--21.433-10.0-31-10 X-imss-scan-details: No--21.433-10.0-31-10 X-TMASE-MatchedRID: QW5G6BKkLTon2WEbWzq9rQhWgIsZuXlPguwtqyXlE6EgbNDlPT+rW9Gu loT4hVHXJ5JIsjNSnpUEQ8zyNXvDzbnuANUvLzt6syNb+yeIRAoA+oYiKiJvtRxUkJPe1WBq8xO 4isLpZaH2Uu67LwlPZMlHH2cMwOTvwzy65XFSg4ORfvUfL+585h852jgffnmII0YrtQLsSUyYOk zFff9r6uUZRFWonBXbH8IzPj64bS8te+Q5hYIzqpznQc/i5PeoLlEAF+4MtAy1kYyHkzONrBMGt PkUyFbdCEuVF6nuSDFftuJwrFEhTbew1twePJJB3QfwsVk0UbslCGssfkpInQ== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/8sbQiWaM0YW0WHWF3utBwplo8RA X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 16:30:47 -0000 Hi Stewart, Pedantry noted :-) > > The BFD Working Group is chartered to standardize and support the > > bidirectional forwarding detection protocol (BFD) and its = extensions. A > > core goal of the working group is to standardize BFD in the context = of > > IP routing, or protocols such as MPLS that are based on IP routing, = in a > > way that will encourage multiple, inter-operable vendor = implementations. >=20 > Isn't BFD also used to support TRILL (which has no basis on IP)? It may be true that many other folk use BFD for all sorts of things. = That doesn't change the fact of "a core goal of the working group" > >> Important characteristics of BFD include: > >> > >> - Simple, fixed-field encoding to facilitate implementations in > >> hardware. > > Well it does have options. Perhaps you just mean hardware efficient > encoding. Yeah, that is a bit ambiguous. I think we can say that the core protocol = uses simple, fixed-field encodings and it is only the options (which = are, erm, optional) that cause variable encoding. > >> - Path independence: BFD can provide failure detection on any kind = of > Any kind of path is a bit ambitious! In the IP context, isn't this true? Let's run BFD over avian carriers to = show that this works. > >> 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). > >> > >> - Ability to be bootstrapped by any other protocol that = automatically > >> forms peer, neighbor or adjacency relationships to seed BFD = endpoint > >> discovery. > > Similarly here "any" is very ambitious. I think BFD doesn't care what protocol bootstraps it. Cheers, Adrian From nobody Thu Jun 5 10:17:06 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD321A01A0; Thu, 5 Jun 2014 10:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9mO6VESndaq; Thu, 5 Jun 2014 10:17:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0E31A0220; Thu, 5 Jun 2014 10:16:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd) X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140605171658.6927.41576.idtracker@ietfa.amsl.com> Date: Thu, 05 Jun 2014 10:16:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/7CfHyY9H3Kj_ursye-HQbJTDbG4 Cc: bfd WG X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 17:17:05 -0000 The Bidirectional Forwarding Detection (bfd) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Bidirectional Forwarding Detection (bfd) ------------------------------------------------ Current Status: Active WG Chairs: Nobo Akiya Jeffrey Haas Technical advisors: Dave Katz David Ward Assigned Area Director: Adrian Farrel Mailing list Address: rtg-bfd@ietf.org To Subscribe: rtg-bfd-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ Charter: The BFD Working Group is chartered to standardize and support the bidirectional forwarding detection protocol (BFD) and its extensions. A core goal of the working group is to standardize BFD in the context of IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. The Working Group will also provide advice and guidance on BFD to other working groups or standards bodies as requested. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware. - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: 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). - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. The working group is currently chartered to complete the following work items: 1. Develop further MIB modules for BFD and submit them to the IESG for publication as Proposed Standards. 2a. Provide a generic keying-based cryptographic authentication mechanism for the BFD protocol developing the work of the KARP working group. This mechanism will support authentication through a key identifier for the BFD session's Security Association rather than specifying new authentication extensions. 2b. Provide extensions to the BFD MIB in support of the generic keying- based cryptographic authentication mechanism. 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks. 4. Provide an informational document to recommend standardized timers and timer operations for BFD when used in different applications. 5. Define a mechanism to perform single-ended path (i.e. continuity) verification based on the BFD specification. Allow such a mechanism to work both proactively and on-demand, without prominent initial delay. Allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG will work closely with at least the following other WGs: ISIS, OSPF, SPRING. The working group will maintain a relationship with the MPLS working group. Milestones: Done - Submit the base protocol specification to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for MPLS LSPs to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit the BFD MIB to the IESG to be considered as a Proposed Standard Done - Submit the BFD over LAG mechanism to the IESG to be considered as a Proposed Standard Jun 2014 - Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard Jan 2015 - Submit a BFD MIB extension in support of the generic keying document to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the BFD Common Intervals document to the IESG to be considered as an Informational RFC From nobody Fri Jun 6 08:24:36 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DCD1A010D; Fri, 6 Jun 2014 08:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEV5ZaiF0lH3; Fri, 6 Jun 2014 08:24:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A6B1A01AB; Fri, 6 Jun 2014 08:24:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Protocol Action: 'Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management' to Proposed Standard (draft-ietf-bfd-tc-mib-08.txt) X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140606152421.2201.57684.idtracker@ietfa.amsl.com> Date: Fri, 06 Jun 2014 08:24:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/is_kWGRDlGbh7DxkYTPxtZKeTOo Cc: bfd mailing list , bfd chair , RFC Editor X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 15:24:33 -0000 The IESG has approved the following document: - 'Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management' (draft-ietf-bfd-tc-mib-08.txt) as Proposed Standard This document is the product of the Bidirectional Forwarding Detection Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-bfd-tc-mib/ Technical Summary This document defines two Management Information Base (MIB) modules that contain Textual Conventions to represent commonly used Bidirectional Forwarding Detection (BFD) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD related MIB modules that would otherwise define their own representations. Working Group Summary This document received commentary from multiple individuals that have had prior SNMP MIB authoring and implementation experience. The document was also reviewed in the context of additional BFD work besides providing base MIB functionality for the above RFCs. This includes BFD multi-point, BFD over LAG. It also has been reviewed as being the basis MIB for the BFD MPLS MIB. Document Quality As is typical with MIB documents, several vendors implement the contents of the BFD MIB in various enterprise MIBs with greater or lesser attention paid to the exact structure of this document. MIBs are seldom fully finished at vendors until the publication of the MIB as an RFC wherein all the code points are finalized with IANA and other authorities. In particular, the Textual-Convention draft covers various TCs that do not share consistent implementations across the vendors. By publishing an RFC, these code points will become normalized across the vendors. Being a MIB document, review by the MIB doctors is always appreciated. Personnel Document Shepherd: Jeffrey Haas Responsible AD: Adrian Farrel From nobody Fri Jun 6 08:39:14 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160B51A0229; Fri, 6 Jun 2014 08:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tND0bMDzfNtq; Fri, 6 Jun 2014 08:39:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 432F51A02C2; Fri, 6 Jun 2014 08:39:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Protocol Action: 'BFD Management Information Base' to Proposed Standard (draft-ietf-bfd-mib-22.txt) X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140606153907.29285.78102.idtracker@ietfa.amsl.com> Date: Fri, 06 Jun 2014 08:39:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/idq8Tm4sMCjfYsT6J5gevBYrH2Y Cc: bfd mailing list , bfd chair , RFC Editor X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 15:39:13 -0000 The IESG has approved the following document: - 'BFD Management Information Base' (draft-ietf-bfd-mib-22.txt) as Proposed Standard This document is the product of the Bidirectional Forwarding Detection Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-bfd-mib/ Technical Summary This documen defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol. Working Group Summary This document received commentary from multiple individuals that have had prior SNMP MIB authoring and implementation experience. The document was also reviewed in the context of additional BFD work besides providing base MIB functionality for the above RFCs. This includes BFD multi-point, BFD over LAG. It also has been reviewed as being the basis MIB for the BFD MPLS MIB. The working group, authors, and WG chairs discussed the issue of write- access in its own right and in the context of the IESG statement on this topic. The conclusion was that the level of write-access in this document is correct, consistent with implementations of both agents and management stations, and appropriate. If the majority of work on this document had not pre-dated the IESG statement, things might have been somewhat different, but it was felt that the current state of this document is correct. Document Quality As is typical with MIB documents, several vendors implement the contents of the BFD MIB in various enterprise MIBs with greater or lesser attention paid to the exact structure of this document. MIBs are seldom fully finished at vendors until the publication of the MIB as an RFC wherein all the code points are finalized with IANA and other authorities. In particular, the Textual-Convention draft covers various TCs that do not share consistent implementations across the vendors. By publishing an RFC, these code points will become normalized across the vendors. Being a MIB document, review by the MIB doctors is always appreciated. Personnel Document Shepherd: Jeffrey Haas Responsible AD: Adrian Farrel From nobody Tue Jun 10 05:10:40 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FF61A0037; Tue, 10 Jun 2014 03:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4aHLatOpmvz; Tue, 10 Jun 2014 03:22:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A255D1A0035; Tue, 10 Jun 2014 03:22:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFG49607; Tue, 10 Jun 2014 10:22:05 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Jun 2014 11:22:04 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.193]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 10 Jun 2014 18:21:59 +0800 From: Qin Wu To: "nvo3@ietf.org" , "sfc@ietf.org" , "rtg-bfd@ietf.org" Subject: RE: Introduction to TIME Mailing List Thread-Topic: Introduction to TIME Mailing List Thread-Index: Ac+Ed/EqiWfsJ33vSgy5XLhDzjJJGgAHZNhA Date: Tue, 10 Jun 2014 10:21:57 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/mixed; boundary="_004_B8F9A780D330094D99AF023C5877DABA84549706nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/e1hVudMAuqNYwAk6Q4IGDiB0lKM X-Mailman-Approved-At: Tue, 10 Jun 2014 05:10:39 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 10:22:09 -0000 --_004_B8F9A780D330094D99AF023C5877DABA84549706nkgeml501mbschi_ Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA84549706nkgeml501mbschi_" --_000_B8F9A780D330094D99AF023C5877DABA84549706nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RllJLg0Kt6K8/sjLOiBUaW1lIFttYWlsdG86dGltZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFFp biBXdQ0Kt6LLzcqxvOQ6IDIwMTTE6jbUwjEwyNUgMTQ6NDgNCsrVvP7IyzogdGltZUBpZXRmLm9y Zw0Ks63LzTogUm9tYXNjYW51LCBEYW4gKERhbik7IE1pc2hhZWwgV2V4bGVyDQrW98ziOiBbVGlt ZV0gSW50cm9kdWN0aW9uIHRvIFRJTUUgTWFpbGluZyBMaXN0DQoNCkRlYXIgYWxsLA0KDQoNClRo aXMgaXMgdG8gaW50cm9kdWNlIHRoZSBUSU1FIG1haWxpbmcgbGlzdC4gVElNRSBzdGFuZHMgZm9y IKGwVHJhbnNwb3J0IEluZGVwZW5kZW50IE9BTSBpbiBNdWx0aS1MYXllciBOZXR3b3JrIEVudGl0 eaGxIC4NCg0KDQpUaGlzIG1haWxpbmcgbGlzdCBpcyBuZXdseSBjcmVhdGVkIGFzIGEgcmVzdWx0 IG9mIGEgQk9GIHJlcXVlc3QgcHJvcG9zYWwgdG8gT1BTIEFyZWEgcmVjZW50bHkuIEhlcmUgaXMg YW4gaW5pdGlhbCBkZXNjcmlwdGlvbiBvZiB0aGUgcHJvYmxlbSBpbg0KDQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13dy1vcHNhd2ctbXVsdGktbGF5ZXItb2FtLTAwDQph bmQgd2UgYXJlIGxvb2tpbmcgZm9yIGRpc2N1c3Npb24gYW5kIGZlZWRiYWNrIG9uIHRoaXMgbGlz dCwgYXMgd2VsbCBhcyBleHBlY3RpbmcgdG8gaGFtbWVyIG91dCBhIGNvbmNyZXRlIHNjb3BlIGFu ZCBnZXQgdGhlIGZpcnN0IHZlcnNpb24gb2YgZHJhZnQNCmNoYXJ0ZXIgY29taW5nIG91dCB0aHJv dWdoIHRoaXMgZGlzY3Vzc2lvbiAuDQoNCkJhY2tncm91bmQ6DQoNCiAgVGhlIGJhc2ljIGNvbmNl cHRzIG9mIE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uLCBhbmQgTWFpbnRlbmFuY2UgKE9BTSkg YW5kIHRoZQ0KICAgZnVuY3Rpb25hbCByb2xlcyBpbiBtb25pdG9yaW5nIGFuZCBkaWFnbm9zaW5n IHRoZSBiZWhhdmlvciBvZiB0ZWxlY29tbXVuaWNhdGlvbnMgbmV0d29ya3MNCiAgIGhhdmUgYmVl biBsb25nIHRlcm0gc3R1ZGllZCBhdCB0aGUgTGF5ZXIgMSYyICYgTGF5ZXIgMyBsZXZlbHMuICBU aGUgY3VycmVudCBwcmFjdGljZSBpcyB0aGF0DQogICBtYW55IHRlY2hub2xvZ2llcyBhbmQgbGF5 ZXJzIGhhdmUgdGhlaXIgb3duIE9BTSBwcm90b2NvbHMuICAgVGhlcmUgaXMgbGl0dGxlIG9yIG5v DQogICByZS11c2Ugb2Ygc29mdHdhcmUgYW5kIGhhcmR3YXJlIGZvciBlYWNoIGV4aXN0aW5nIE9B TSBwcm90b2NvbC4gVmVuZG9ycyBhbmQgb3BlcmF0b3JzIHdhc3RlDQphIGxvdCB0aHJvdWdoIHRo ZSB3aG9sZSBPQU0gbGlmZS1jeWNsZSB3aGVuIGEgbmV3IHRlY2hub2xvZ3kgaXMgaW50cm9kdWNl ZC4gSW50ZWdyYXRpb24gb2YgT0FNDQphY3Jvc3MgbXVsdGlwbGUgdGVjaG5vbG9naWVzIGlzIGV4 dHJlbWVseSBkaWZmaWN1bHQuIFdoZW4gaGF2aW5nIG5ldHdvcmtzIHdpdGggbW9yZSB0aGFuIG9u ZSB0ZWNobm9sb2d5LA0KbWFpbnRlbmFuY2UgYW5kIHRyb3VibGVzaG9vdGluZyBhcmUgZG9uZSBw ZXIgdGVjaG5vbG9neQ0KICAgYW5kIGxheWVyLCBvcGVyYXRpb24gcHJvY2VzcyBjYW4gYmUgdmVy eSBjdW1iZXJzb21lLiBJbiBtYW55IGNhc2VzIGl0IGlzIGRlc2lyYWJsZSB0byBoYXZlIGENCiAg IGdlbmVyaWMgT0FNIHRvIGNvdmVyIGhldGVyb2dlbmVvdXMgbmV0d29ya2luZyB0ZWNobm9sb2dp ZXMuIEdlbmVyaWMgT0FNIHRvb2xzIHNob3VsZCBiZQ0KICAgZGVwbG95ZWQgb3ZlciB2YXJpb3Vz IGVuY2Fwc3VsYXRpbmcgcHJvdG9jb2xzLCBhbmQgaW4gdmFyaW91cyBtZWRpdW0gdHlwZXMuDQoN CiAgIEFuIGV4YW1wbGUgb2YgYW4gZW52aXJvbm1lbnQgaW4gd2hpY2ggYSBnZW5lcmljIGFuZCBp bnRlZ3JhdGVkIE9BTSBwcm90b2NvbCB3b3VsZCBiZQ0KICAgdmFsdWFibGUgaXMgU2VydmljZSBG dW5jdGlvbiBDaGFpbmluZy4gQSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIGlzIGNvbXBvc2Vk IGJ5IGEgc2VyaWVzIG9mDQogICBzZXJ2aWNlIEZ1bmN0aW9ucywgdGhhdCBjYW4gYWN0IGluIGRp ZmZlcmVudCBsYXllcnMgYnV0IHByb3ZpZGluZyBhbiBlbmQtdG8tZW5kIGNoYWluIG9yIHBhdGgN CiAgIGZyb20gYSBzb3VyY2UgdG8gZGVzdGluYXRpb24gaW4gYSBnaXZlbiBvcmRlci4gIEluIHNl cnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgRW52aXJvbm1lbnQsIGl0IGlzDQogICBuZWNlc3Nhcnkg dG8gcHJvdmlkZSBlbmQgdG8gZW5kIE9BTSBhY3Jvc3MgY2VydGFpbiBvciBhbGwgZW50aXRpZXMg YW5kIGludm9sdmluZyBtYW55IGxheWVycy4NCiAgIE9BTSBpbmZvcm1hdGlvbiBzaG91bGQgYmUg ZXhjaGFuZ2VkIGJldHdlZW4gc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50IGxheWVycyB3 aGlsZQ0KICAgdXNpbmcgdmFyaW91cyBlbmNhcHN1bGF0aW5nIHByb3RvY29scy4gIEluIHNvbWUg Y2FzZXMgT0FNIHNob3VsZCBjcm9zcyBkaWZmZXJlbnQNCiAgIGFkbWluaXN0cmF0aW9uIGFuZC9v ciBtYWludGVuYW5jZSBkb21haW5zLg0KDQpUaGUgcHVycG9zZSBvZiB0aGUgbGlzdDoNCg0KICAg MS51bmRlcnN0YW5kaW5nIGFuZCBkaXNjdXNzaW5nIHRoZSB0aW1lcyB3aGVuIGFuIE9BTQ0KICAg cHJvdG9jb2wgY2FuIGJlIHR1bmVkIGFuZCBvcHRpbWlzZWQgZm9yIGEgc3BlY2lmaWMgZGF0YSBw bGFuZSAoZm9yIGV4YW1wbGUsIE9BTSBpbiBhIHBhY2tldA0KICAgbmV0d29yayBjYW4gYmUgdmVy eSBkaWZmZXJlbnQgZnJvbSBPQU0gaW4gYSBjaXJjdWl0IHN3aXRjaGVkIG5ldHdvcmsgYmVjYXVz ZSBvZiB0aGUNCiAgIGRpZmZlcmVudCBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIG5ldHdvcmspDQoN CjIuYW5kIHNlZWtpbmcgdGhlIGJlc3Qgd2F5czoNCg0KICAgICAgICBPIEV4Y2hhbmdlIE9BTSBp bmZvcm1hdGlvbiBhdCB0aGUgc2VydmljZSBsYXllciBhdG9wIG9mIGxheWVyIDMNCg0KTyBBYnN0 cmFjdCBPQU0gaW5mb3JtYXRpb24gY29tbW9uIHRvIGRpZmZlcmVudCBsYXllcg0KDQpPIFByb3Zp ZGUgdGhlbSB2aWEgdW5pZmllZCBpbnRlcmZhY2UgdG8gbWFuYWdlbWVudCBlbnRpdGllcy4NCg0K TyBTZXQgdXAgTWFpbnRlbmFuY2UgRG9tYWlucyAoTUQpIGFuZCBNYWludGVuYW5jZSBJbnRlcm1l ZGlhdGUgUG9pbnRzIChNSVApDQoNCk8gRW5hYmxlIE9BTSBmdW5jdGlvbiBhdCBkaWZmZXJlbnQg bGF5ZXIgaW4gdGhlIG11bHRpLWxheWVyIG5ldHdvcmsNCg0KTyBBY3RpdmF0ZSBPQU0gZnVuY3Rp b24gYSBkaWZmZXJlbnQgbGF5ZXIgYW5kIHByb3ZpZGUgcmVzdWx0cyB0byBtYW5hZ2VtZW50IGVu dGl0eQ0KDQpUaGlzIG1haWxpbmcgbGlzdCBpcyBpbnRlbmRlZCB0byBlbmFibGUgZGlzY3Vzc2lv biBvZiB0aGUgYXJjaGl0ZWN0dXJlLCB1c2UtY2FzZXMvYXBwbGljYWJpbGl0eSwgYW5kDQpyZXF1 aXJlbWVudHMgdGhhdCBwcm92aWRlIGdlbmVyaWMgYW5kIGludGVncmF0ZWQgT0FNIGNvdmVyaW5n IHZhcmlvdXMgaGV0ZXJvZ2VuZW91cyBuZXR3b3JrIHRlY2hub2xvZ2llcy4NCg0KTyBBbmFseXNl IGFuZCB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbnQgbW90aXZhdGlvbnMgYW5kIG9wcG9ydHVuaXRp ZXMgZm9yIG9wdGltaXNhdGlvbiBvZiBPQU0gaW4gZGlmZmVyZW50DQp0ZWNobm9sb2d5IG5ldHdv cmtzLCBhbmQgdGhlIHRyYWRlLW9mZnMgYmV0d2VlbiB0aG9zZSBvcHRpbWlzYXRpb25zIGFuZCB0 aGUNCiBvdmVyYWxsIGFkdmFudGFnZSBvZiBhIGdlbmVyaWMgT0FNIG1lY2hhbmlzbS4NCg0KTyBT ZXQgb3V0IHRoZSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgYXJjaGl0ZWN0dXJlIGZvciB0aGUNCiAg ICAgVHJhbnNwb3J0IEluZGVwZW5kZW50IE9BTSBpbiB0aGUgbXVsdGktbGF5ZXIgbmV0d29yayBh bmQgb3V0bGluZXMgdGhlIHByb2JsZW1zDQogICAgIGVuY291bnRlcmVkIHdpdGggZXhpc3Rpbmcg T0FNIHByb3RvY29sIHZhcmlldHkgYW5kIHRoZWlyIGltcGFjdCBvbiBpbnRyb2R1Y3Rpb24gb2Yg bmV3IHRlY2hub2xvZ2llcy4NCg0KWW91IGNhbiBzdWJzY3JpYmUgdG8gdGhlIGxpc3QgYXQ6IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGltZS4NCg0KDQpUbyBwb3N0IGEg bWVzc2FnZSB0byBhbGwgdGhlIGxpc3QgbWVtYmVycywgc2VuZCBlbWFpbCB0byB0aW1lIGF0IGll dGYub3JnLg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KUWluJkRhbg0K --_000_B8F9A780D330094D99AF023C5877DABA84549706nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

FYI.

=B7=A2=BC=FE=C8=CB: Time [mailto:time-bounces@ietf.org] =B4=FA=B1=ED = Qin Wu
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA6=D4=C2<= span lang=3D"EN-US">10=C8=D5 14:48
=CA=D5=BC=FE=C8=CB: time@ietf.org
=B3=AD=CB=CD: Romascanu, Dan (Dan); Mishael Wexler
=D6=F7=CC=E2: [Time] Introduction to TIME Mailing List

 

Dear all,

 

 

This is to introduce the TIME m= ailing list. TIME stands for =A1=B0Transport Independent OAM in Multi-Layer= Network Entity=A1=B1 .

 

This mailing list is newly c= reated as a result of a BOF request proposal to OPS Area recently. Here is = an initial description of the problem in

https://datatracker.iet= f.org/doc/draft-ww-opsawg-multi-layer-oam-00

and we are looking for discussi= on and feedback on this list, as well as expecting to hammer out a concrete= scope and get the first version of draft

charter coming out through this= discussion .

 

Background:

 

  The basic concepts of Op= erations, Administration, and Maintenance (OAM) and the

   functional roles i= n monitoring and diagnosing the behavior of telecommunications networks

   have been lon= g term studied at the Layer 1&2 & Layer 3 levels.  The current= practice is that

   many technolo= gies and layers have their own OAM protocols.   There is little o= r no

   re-use of software= and hardware for each existing OAM protocol. Vendors and operators waste

a= lot through the whole OAM life-cycle when a new technology is introduced. = Integration of OAM

a= cross multiple technologies is extremely difficult. When having networks wi= th more than one technology,

m= aintenance and troubleshooting are done per technology

   and layer, operati= on process can be very cumbersome. In many cases it is desirable to have a

   generic OAM t= o cover heterogeneous networking technologies. Generic OAM tools should be<= o:p>

   deployed over vari= ous encapsulating protocols, and in various medium types.=

 

   An example of an e= nvironment in which a generic and integrated OAM protocol would be

   valuable is S= ervice Function Chaining. A Service Function Chaining is composed by a seri= es of

   service Functions,= that can act in different layers but providing an end-to-end chain or path=

   from a source to d= estination in a given order.  In service function chaining Environment= , it is

   necessary to provi= de end to end OAM across certain or all entities and involving many layers.=  

   OAM informati= on should be exchanged between service functions in different layers while

   using various= encapsulating protocols.  In some cases OAM should cross different

   administratio= n and/or maintenance domains.

 

The purpose of the list:

 

   1.understanding an= d discussing the times when an OAM

   protocol can = be tuned and optimised for a specific data plane (for example, OAM in a pac= ket

   network can b= e very different from OAM in a circuit switched network because of the

   different cha= racteristics of the network)

 

2= .and seeking the best ways:

<= o:p> 

      =   O Exchange OAM information at the service layer atop of layer 3

 

O = Abstract OAM information common to different layer

 

O = Provide them via unified interface to management entities.

 

O = Set up Maintenance Domains (MD) and Maintenance Intermediate Points (MIP)

 

O = Enable OAM function at different layer in the multi-layer network

 

O = Activate OAM function a different layer and provide results to management e= ntity

 

This mailing list is intended t= o enable discussion of the architecture, use-cases/applicability, and

requirements that provide gener= ic and integrated OAM covering various heterogeneous network technologies.<= o:p>

 

O = Analyse and understand the different motivations and opportunities for opti= misation of OAM in different

te= chnology networks, and the trade-offs between those optimisations and the

&n= bsp;overall advantage of a generic OAM mechanism.

 

O = Set out the problem statement and architecture for the

     Transp= ort Independent OAM in the multi-layer network and outlines the problems

     encoun= tered with existing OAM protocol variety and their impact on introduction o= f new technologies.

 

You can subscribe to the list a= t: https://www.ietf.org/mailman/listinfo/time.

 

 

To post a message to all the li= st members, send email to time at ietf.org.

 

 

Best Regards,=

 

Qin&Dan

--_000_B8F9A780D330094D99AF023C5877DABA84549706nkgeml501mbschi_-- --_004_B8F9A780D330094D99AF023C5877DABA84549706nkgeml501mbschi_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Tue, 10 Jun 2014 07:00:08 GMT"; modification-date="Tue, 10 Jun 2014 07:00:08 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRpbWUgbWFp bGluZyBsaXN0DQpUaW1lQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RpbWUNCg== --_004_B8F9A780D330094D99AF023C5877DABA84549706nkgeml501mbschi_-- From nobody Tue Jun 10 06:53:48 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953651A011F for ; Tue, 10 Jun 2014 06:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6ymDu9q1h0O for ; Tue, 10 Jun 2014 06:53:41 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEA41A0113 for ; Tue, 10 Jun 2014 06:53:41 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0F140C22F; Tue, 10 Jun 2014 09:53:41 -0400 (EDT) Date: Tue, 10 Jun 2014 09:53:41 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: BFD re-charter complete Message-ID: <20140610135340.GA19601@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/oI_HZToz8QzrfSUEJXU6CpOTEy8 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 13:53:46 -0000 Working Group, Our updated charter was approved by the IESG. The S-BFD work is officially in scope now! Per our prior discussion, authors please submit the following documents as draft-ietf-bfd-*: draft-aldrin-bfd-seamless-use-case (Milestone: November 2014) draft-akiya-bfd-seamless-base (Milestone: March 2015) The following documents are known to be work of interest, but aren't quite ready for adoption. Please kick off additional discussions to drive that work forward: draft-akiya-bfd-seamless-ip draft-akiya-bfd-seamless-sr draft-akiya-bfd-seamless-alert-discrim My recommendation is to drive the IP case first. -- Jeff ----- Forwarded message from The IESG ----- Date: Thu, 05 Jun 2014 10:16:58 -0700 From: The IESG To: IETF-Announce Cc: bfd WG Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd) The Bidirectional Forwarding Detection (bfd) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Bidirectional Forwarding Detection (bfd) ------------------------------------------------ Current Status: Active WG Chairs: Nobo Akiya Jeffrey Haas Technical advisors: Dave Katz David Ward Assigned Area Director: Adrian Farrel Mailing list Address: rtg-bfd@ietf.org To Subscribe: rtg-bfd-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ Charter: The BFD Working Group is chartered to standardize and support the bidirectional forwarding detection protocol (BFD) and its extensions. A core goal of the working group is to standardize BFD in the context of IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. The Working Group will also provide advice and guidance on BFD to other working groups or standards bodies as requested. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware. - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: 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). - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. The working group is currently chartered to complete the following work items: 1. Develop further MIB modules for BFD and submit them to the IESG for publication as Proposed Standards. 2a. Provide a generic keying-based cryptographic authentication mechanism for the BFD protocol developing the work of the KARP working group. This mechanism will support authentication through a key identifier for the BFD session's Security Association rather than specifying new authentication extensions. 2b. Provide extensions to the BFD MIB in support of the generic keying- based cryptographic authentication mechanism. 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks. 4. Provide an informational document to recommend standardized timers and timer operations for BFD when used in different applications. 5. Define a mechanism to perform single-ended path (i.e. continuity) verification based on the BFD specification. Allow such a mechanism to work both proactively and on-demand, without prominent initial delay. Allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG will work closely with at least the following other WGs: ISIS, OSPF, SPRING. The working group will maintain a relationship with the MPLS working group. Milestones: Done - Submit the base protocol specification to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for MPLS LSPs to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit the BFD MIB to the IESG to be considered as a Proposed Standard Done - Submit the BFD over LAG mechanism to the IESG to be considered as a Proposed Standard Jun 2014 - Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard Jan 2015 - Submit a BFD MIB extension in support of the generic keying document to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the BFD Common Intervals document to the IESG to be considered as an Informational RFC ----- End forwarded message ----- From nobody Tue Jun 10 07:40:33 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779DD1B27C4; Tue, 10 Jun 2014 07:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NO4V6U6LMVOk; Tue, 10 Jun 2014 07:40:16 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E081A017F; Tue, 10 Jun 2014 07:40:16 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id j17so4136202oag.10 for ; Tue, 10 Jun 2014 07:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=p5+9mw/bfwBp5Eoio6DaiMOk98F7f9k4auYeVjF38Fc=; b=tCZoOaOhqm4MiyHBrT0KJONhTsjVA7PPz3M6+hvnzRvf/YRGAz31eH3KaoRy5GxITZ O0GSuOG3cPIOchZO/NF2zQNQRwzzk6KWOKan0lPkoy0cNqOYVoq1VYvneFAKhotXnB8W eNLEgY638vgir6WXpWlknIGD4Not0yI4vIWHYPpzUb78j5voQ+gYxcWXCjmz/biPktf+ L0YX8/z+QirDMyOzgfDCGvjlyUFoCW4g9w/j1gAuMM0Jo864o2ZlgB3PKO8Wn8u2ppdW jrGTjlRkJ5WyaUqfGHzeO+ofAeK96SPDQpebiHjb4LpSAyzxa1HFkQk5lJfcmotQ8Ss7 1c5A== MIME-Version: 1.0 X-Received: by 10.182.65.167 with SMTP id y7mr31852782obs.29.1402411215609; Tue, 10 Jun 2014 07:40:15 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Tue, 10 Jun 2014 07:40:15 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Tue, 10 Jun 2014 07:40:15 -0700 (PDT) In-Reply-To: <20140610135340.GA19601@pfrc> References: <20140610135340.GA19601@pfrc> Date: Tue, 10 Jun 2014 07:40:15 -0700 Message-ID: Subject: Re: BFD re-charter complete From: Manav Bhatia To: Jeffrey Haas , "rtg-bfd@ietf.org" , OSPF - OSPF WG List Content-Type: multipart/alternative; boundary=089e0158a91055f3ff04fb7c4e38 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/61Kg4fBDyWtA7MA_V5vZXuVV6J4 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 14:40:26 -0000 --089e0158a91055f3ff04fb7c4e38 Content-Type: text/plain; charset=UTF-8 Hi Jeff, What about the ospf/isis extn drafts for distributing the sbfd discriminators? I guess these would be owned by the respective IGP WGs. Is this correct? Cheers, Manav -- Thumb typed by Manav On Jun 10, 2014 7:23 PM, "Jeffrey Haas" wrote: > Working Group, > > Our updated charter was approved by the IESG. The S-BFD work is officially > in scope now! > > Per our prior discussion, authors please submit the following documents as > draft-ietf-bfd-*: > > draft-aldrin-bfd-seamless-use-case (Milestone: November 2014) > draft-akiya-bfd-seamless-base (Milestone: March 2015) > > The following documents are known to be work of interest, but aren't quite > ready for adoption. Please kick off additional discussions to drive that > work forward: > > draft-akiya-bfd-seamless-ip > draft-akiya-bfd-seamless-sr > draft-akiya-bfd-seamless-alert-discrim > > My recommendation is to drive the IP case first. > > -- Jeff > > > > > > ----- Forwarded message from The IESG ----- > > Date: Thu, 05 Jun 2014 10:16:58 -0700 > From: The IESG > To: IETF-Announce > Cc: bfd WG > Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd) > > The Bidirectional Forwarding Detection (bfd) working group in the Routing > Area of the IETF has been rechartered. For additional information please > contact the Area Directors or the WG Chairs. > > Bidirectional Forwarding Detection (bfd) > ------------------------------------------------ > Current Status: Active WG > > Chairs: > Nobo Akiya > Jeffrey Haas > > Technical advisors: > Dave Katz > David Ward > > Assigned Area Director: > Adrian Farrel > > Mailing list > Address: rtg-bfd@ietf.org > To Subscribe: rtg-bfd-request@ietf.org > Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ > > Charter: > > The BFD Working Group is chartered to standardize and support the > bidirectional forwarding detection protocol (BFD) and its extensions. A > core goal of the working group is to standardize BFD in the context of > IP routing, or protocols such as MPLS that are based on IP routing, in a > way that will encourage multiple, inter-operable vendor implementations. > > The Working Group will also provide advice and guidance on BFD to other > working groups or standards bodies as requested. > > BFD is a protocol intended to detect faults in the bidirectional path > between two forwarding engines, including physical interfaces, > subinterfaces, data link(s), and to the extent possible the forwarding > engines themselves, with potentially very low latency. It operates > independently of media, data protocols, and routing protocols. An > additional goal is to provide a single mechanism that can be used for > liveness detection over any media, at any protocol layer, with > a wide range of detection times and overhead, to avoid a proliferation > of different methods. > > Important characteristics of BFD include: > > - Simple, fixed-field encoding to facilitate implementations in > hardware. > > - Independence of the data protocol being forwarded between two systems. > BFD packets are carried as the payload of whatever encapsulating > protocol is appropriate for the medium and network. > > - Path independence: 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). > > - Ability to be bootstrapped by any other protocol that automatically > forms peer, neighbor or adjacency relationships to seed BFD endpoint > discovery. > > The working group is currently chartered to complete the following work > items: > > 1. Develop further MIB modules for BFD and submit them to the IESG for > publication as Proposed Standards. > > 2a. Provide a generic keying-based cryptographic authentication > mechanism for the BFD protocol developing the work of the KARP > working group. This mechanism will support authentication through > a key identifier for the BFD session's Security Association rather > than specifying new authentication extensions. > > 2b. Provide extensions to the BFD MIB in support of the generic keying- > based cryptographic authentication mechanism. > > 2c. Specify cryptographic authentication procedures for the BFD protocol > using HMAC-SHA-256 (possibly truncated to a smaller integrity check > value but not beyond commonly accepted lengths to ensure security) using > the generic keying-based cryptographic authentication mechanism. > > 3. Provide an extension to the BFD core protocol in support of point-to- > multipoint links and networks. > > 4. Provide an informational document to recommend standardized timers > and timer operations for BFD when used in different applications. > > 5. Define a mechanism to perform single-ended path (i.e. continuity) > verification based on the BFD specification. Allow such a mechanism to > work both proactively and on-demand, without prominent initial delay. > Allow the mechanism to maintain multiple sessions to a target entity and > between the same pair of network entities. In doing this work, the WG > will work closely with at least the following other WGs: ISIS, OSPF, > SPRING. > > The working group will maintain a relationship with the MPLS working > group. > > Milestones: > Done - Submit the base protocol specification to the IESG to be > considered as a Proposed Standard > Done - Submit BFD encapsulation and usage profile for single-hop > IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed > Standard > Done - Submit BFD encapsulation and usage profile for MPLS LSPs to > the IESG to be considered as a Proposed Standard > Done - Submit BFD encapsulation and usage profile for multi-hop > IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed > Standard > Done - Submit the BFD MIB to the IESG to be considered as a > Proposed Standard > Done - Submit the BFD over LAG mechanism to the IESG to be > considered as a Proposed Standard > Jun 2014 - Submit the the document on BFD point-to-multipoint support > to the IESG to be considered as a Proposed Standard > Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be > considered as a Proposed Standard > Jan 2015 - Submit the generic keying based cryptographic authentication > mechanism to the IESG to be considered as a Proposed Standard > Jan 2015 - Submit a BFD MIB extension in support of the generic keying > document to the IESG to be considered as a Proposed Standard > Jan 2015 - Submit the cryptographic authentication procedures for BFD > to the IESG to be considered as a Proposed Standard > Jan 2015 - Submit the BFD Common Intervals document to the IESG to be > considered as an Informational RFC > > > ----- End forwarded message ----- > > --089e0158a91055f3ff04fb7c4e38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Jeff,

What about the ospf/isis extn drafts for distributing the sbfd discrimin= ators? I guess these would be owned by the respective IGP WGs. Is this corr= ect?

Cheers, Manav

--
Thumb typed by Manav

On Jun 10, 2014 7:23 PM, "Jeffrey Haas"= ; <jhaas@pfrc.org> wrote:
Working Group,

Our updated charter was approved by the IESG. =C2=A0The S-BFD work is offic= ially
in scope now!

Per our prior discussion, authors please submit the following documents as<= br> draft-ietf-bfd-*:

draft-aldrin-bfd-seamless-use-case (Milestone: November 2014)
draft-akiya-bfd-seamless-base (Milestone: March 2015)

The following documents are known to be work of interest, but aren't qu= ite
ready for adoption. =C2=A0Please kick off additional discussions to drive t= hat
work forward:

draft-akiya-bfd-seamless-ip
draft-akiya-bfd-seamless-sr
draft-akiya-bfd-seamless-alert-discrim

My recommendation is to drive the IP case first.

-- Jeff





----- Forwarded message from The IESG <iesg-secretary@ietf.org> -----

Date: Thu, 05 Jun 2014 10:16:58 -0700
From: The IESG <iesg-secretar= y@ietf.org>
To: IETF-Announce <ietf-announ= ce@ietf.org>
Cc: bfd WG <rtg-bfd@ietf.org>=
Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd)
The Bidirectional Forwarding Detection (bfd) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs.

Bidirectional Forwarding Detection (bfd)
------------------------------------------------
Current Status: Active WG

Chairs:
=C2=A0 Nobo Akiya <nobo@cisco.com&= gt;
=C2=A0 Jeffrey Haas <jhaas@pfrc.org>

Technical advisors:
=C2=A0 Dave Katz <dkatz@juniper.net= >
=C2=A0 David Ward <dward@cisco.com>

Assigned Area Director:
=C2=A0 Adrian Farrel <adrian@oldd= og.co.uk>

Mailing list
=C2=A0 Address: rtg-bfd@ietf.org =C2=A0 To Subscribe: rtg-bfd-re= quest@ietf.org
=C2=A0 Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/

Charter:

The BFD Working Group is chartered to standardize and support the
bidirectional forwarding detection protocol (BFD) and its extensions. =C2= =A0A
core goal of the working group is to standardize BFD in the context of
IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations.
The Working Group will also provide advice and guidance on BFD to other
working groups or standards bodies as requested.

BFD is a protocol intended to detect faults in the bidirectional path
between two forwarding engines, including physical interfaces,
subinterfaces, data link(s), and to the extent possible the forwarding
engines themselves, with potentially very low latency. It operates
independently of media, data protocols, and routing protocols. An
additional goal is to provide a single mechanism that can be used for
liveness detection over any media, at any protocol layer, with
a wide range of detection times and overhead, to avoid a proliferation
of different methods.

Important characteristics of BFD include:

- Simple, fixed-field encoding to facilitate implementations in
=C2=A0 hardware.

- Independence of the data protocol being forwarded between two systems. =C2=A0 BFD packets are carried as the payload of whatever encapsulating
=C2=A0 protocol is appropriate for the medium and network.

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

- Ability to be bootstrapped by any other protocol that automatically
=C2=A0 forms peer, neighbor or adjacency relationships to seed BFD endpoint=
=C2=A0 discovery.

The working group is currently chartered to complete the following work
items:

1. Develop further MIB modules for BFD and submit them to the IESG for
publication as Proposed Standards.

2a. Provide a generic keying-based cryptographic authentication
mechanism for the BFD protocol developing the work of the KARP
working group. =C2=A0This mechanism =C2=A0will support authentication throu= gh
a key identifier for the BFD session's Security Association rather
than specifying new authentication extensions.

2b. Provide extensions to the BFD MIB in support of the generic keying-
based cryptographic authentication mechanism.

2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check
value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism.

3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks.

4. Provide an informational document to recommend standardized timers
and timer operations for BFD when used in different applications.

5. Define a mechanism to perform single-ended path (i.e. continuity)
verification based on the BFD specification. =C2=A0Allow such a mechanism t= o
work both proactively and on-demand, without prominent initial delay.
Allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG
will work closely with at least the following other WGs: ISIS, OSPF,
SPRING.

The working group will maintain a relationship with the MPLS working
group.

Milestones:
=C2=A0 Done =C2=A0 =C2=A0 - Submit the base protocol specification to the I= ESG to be
considered as a Proposed Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit BFD encapsulation and usage profile for = single-hop
IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed
Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit BFD encapsulation and usage profile for = MPLS LSPs to
the IESG to be considered as a Proposed Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit BFD encapsulation and usage profile for = multi-hop
IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed
Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit the BFD MIB to the IESG to be considered= as a
Proposed Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit the BFD over LAG mechanism to the IESG t= o be
considered as a Proposed Standard
=C2=A0 Jun 2014 - Submit the the document on BFD point-to-multipoint suppor= t
to the IESG to be considered as a Proposed Standard
=C2=A0 Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be
considered as a Proposed Standard
=C2=A0 Jan 2015 - Submit the generic keying based cryptographic authenticat= ion
mechanism to the IESG to be considered as a Proposed Standard
=C2=A0 Jan 2015 - Submit a BFD MIB extension in support of the generic keyi= ng
document to the IESG to be considered as a Proposed Standard
=C2=A0 Jan 2015 - Submit the cryptographic authentication procedures for BF= D
to the IESG to be considered as a Proposed Standard
=C2=A0 Jan 2015 - Submit the BFD Common Intervals document to the IESG to b= e
considered as an Informational RFC


----- End forwarded message -----

--089e0158a91055f3ff04fb7c4e38-- From nobody Tue Jun 10 08:10:53 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1835C1B27FF; Tue, 10 Jun 2014 08:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPrY6wnpWnhE; Tue, 10 Jun 2014 08:10:50 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id ED67E1B2802; Tue, 10 Jun 2014 08:10:49 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 92A63C22F; Tue, 10 Jun 2014 11:10:49 -0400 (EDT) Date: Tue, 10 Jun 2014 11:10:49 -0400 From: Jeffrey Haas To: Manav Bhatia Subject: Re: BFD re-charter complete Message-ID: <20140610151049.GA20397@pfrc> References: <20140610135340.GA19601@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/AtRLyEFw7eQOyu_7cT2syUm1U4s Cc: OSPF - OSPF WG List , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 15:10:52 -0000 Manav, On Tue, Jun 10, 2014 at 07:40:15AM -0700, Manav Bhatia wrote: > What about the ospf/isis extn drafts for distributing the sbfd > discriminators? I guess these would be owned by the respective IGP WGs. Is > this correct? I believe we'll want those drafts in the specific protocol WGs. My suggestion is to ask for agenda slots to discuss the item. BFD WG discussion certainly seemed to suggest that there was still things that needed to be discussed related to the use case, especially in the segment routing/SPRING solution spaces. -- Jeff From nobody Tue Jun 10 10:03:36 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92BC1B2820; Tue, 10 Jun 2014 09:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQsT7-9wlV-e; Tue, 10 Jun 2014 09:35:01 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164AD1B2821; Tue, 10 Jun 2014 09:35:01 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-e7-5396e2ed1618 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 57.30.27529.DE2E6935; Tue, 10 Jun 2014 12:50:21 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 12:34:55 -0400 From: Acee Lindem To: Manav Bhatia , Jeffrey Haas , "rtg-bfd@ietf.org" , OSPF - OSPF WG List Subject: Re: [OSPF] BFD re-charter complete Thread-Topic: [OSPF] BFD re-charter complete Thread-Index: AQHPhLn1+tGMsKmUlUiLuM+ShUV36JtqWA6A Date: Tue, 10 Jun 2014 16:34:55 +0000 Message-ID: References: <20140610135340.GA19601@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_CFBC813F3100Aaceelindemericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyuXRPgu7bR9OCDZ6st7TYf/Atq8XlSW3s Fi337rFbfP6zjdGBxWPnrLvsHkuW/GTyuNy7lTWAOYrLJiU1J7MstUjfLoEro2f/TKaC11MZ Ky4+K29gnFLXxcjJISFgIrHs/V42CFtM4sK99UA2F4eQwFFGiedPX7FCOMsZJU6sX80OUsUm oCPx/NE/ZpCEiMBURollc/pYQBLCAtoSS37+YwSxRYCKel4+ZoWwjSQOvvwEVsMioCoxd+5/ pi5GDg5eAVOJw60uIGEhgQKJpQ+vgV3BKRAo0XJsNhOIzQh00fdTa8BsZgFxiVtP5jNBXCog sWTPeWYIW1Ti5eN/YKtEBfQkmrveMELEFSX29U9nh+iNkuh/PA/sBF4BQYmTM5+wTGAUnYVk 7CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DFUr7XEi4t3GZHVLGDkWMXIUVqcWpabbmSw iREYjcck2HR3MO55aXmIUYCDUYmHV+H6tGAh1sSy4srcQ4zSHCxK4rzaN6uChQTSE0tSs1NT C1KL4otKc1KLDzEycXBKNTAuuZ8hWKQc0sBdNcUhW2+N7xzbQ9fTloayTricFxZffbG44NXL sMtz7sgfUVt7/cnyi7+PlK/Jf+t28sNb2yuhnvXvLvusFREy/vS8Ys1v7V7+fOuT+TO+zeic JnxURVtu7zmDPc92enj7sxrNz/H/MNUkTUT79o+XU26+VTpw0NLwxk0VvpogJZbijERDLeai 4kQAhGrMRacCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/0iisIPKakojsADY6_eu7lFFTfyk X-Mailman-Approved-At: Tue, 10 Jun 2014 10:03:34 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 16:35:09 -0000 --_000_CFBC813F3100Aaceelindemericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Manav, From: Manav Bhatia > Date: Tuesday, June 10, 2014 7:40 AM To: Jeffrey Haas >, "rtg-bfd@ietf.org= " >, OSP= F - OSPF WG List > Subject: Re: [OSPF] BFD re-charter complete Hi Jeff, What about the ospf/isis extn drafts for distributing the sbfd discriminato= rs? I guess these would be owned by the respective IGP WGs. Is this correct= ? Since the IGP drafts contain solely the TLV encoding and IGP flooding speci= fications, there is reason for them to be homed anywhere else. Thanks, Acee Cheers, Manav -- Thumb typed by Manav On Jun 10, 2014 7:23 PM, "Jeffrey Haas" > wrote: Working Group, Our updated charter was approved by the IESG. The S-BFD work is officially in scope now! Per our prior discussion, authors please submit the following documents as draft-ietf-bfd-*: draft-aldrin-bfd-seamless-use-case (Milestone: November 2014) draft-akiya-bfd-seamless-base (Milestone: March 2015) The following documents are known to be work of interest, but aren't quite ready for adoption. Please kick off additional discussions to drive that work forward: draft-akiya-bfd-seamless-ip draft-akiya-bfd-seamless-sr draft-akiya-bfd-seamless-alert-discrim My recommendation is to drive the IP case first. -- Jeff ----- Forwarded message from The IESG > ----- Date: Thu, 05 Jun 2014 10:16:58 -0700 From: The IESG > To: IETF-Announce > Cc: bfd WG > Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd) The Bidirectional Forwarding Detection (bfd) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Bidirectional Forwarding Detection (bfd) ------------------------------------------------ Current Status: Active WG Chairs: Nobo Akiya > Jeffrey Haas > Technical advisors: Dave Katz > David Ward > Assigned Area Director: Adrian Farrel > Mailing list Address: rtg-bfd@ietf.org To Subscribe: rtg-bfd-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ Charter: The BFD Working Group is chartered to standardize and support the bidirectional forwarding detection protocol (BFD) and its extensions. A core goal of the working group is to standardize BFD in the context of IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. The Working Group will also provide advice and guidance on BFD to other working groups or standards bodies as requested. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware. - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: 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). - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. The working group is currently chartered to complete the following work items: 1. Develop further MIB modules for BFD and submit them to the IESG for publication as Proposed Standards. 2a. Provide a generic keying-based cryptographic authentication mechanism for the BFD protocol developing the work of the KARP working group. This mechanism will support authentication through a key identifier for the BFD session's Security Association rather than specifying new authentication extensions. 2b. Provide extensions to the BFD MIB in support of the generic keying- based cryptographic authentication mechanism. 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks. 4. Provide an informational document to recommend standardized timers and timer operations for BFD when used in different applications. 5. Define a mechanism to perform single-ended path (i.e. continuity) verification based on the BFD specification. Allow such a mechanism to work both proactively and on-demand, without prominent initial delay. Allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG will work closely with at least the following other WGs: ISIS, OSPF, SPRING. The working group will maintain a relationship with the MPLS working group. Milestones: Done - Submit the base protocol specification to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for MPLS LSPs to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit the BFD MIB to the IESG to be considered as a Proposed Standard Done - Submit the BFD over LAG mechanism to the IESG to be considered as a Proposed Standard Jun 2014 - Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard Jan 2015 - Submit a BFD MIB extension in support of the generic keying document to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the BFD Common Intervals document to the IESG to be considered as an Informational RFC ----- End forwarded message ----- --_000_CFBC813F3100Aaceelindemericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Manav, 

From: Manav Bhatia <manavbhatia@gmail.com>
Date: Tuesday, June 10, 2014 7:40 A= M
To: Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, OSPF - OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] BFD re-charter = complete

Hi Jeff,

What about the ospf/isis extn drafts for distributing the sbfd discrimin= ators? I guess these would be owned by the respective IGP WGs. Is this corr= ect?
Since the IGP drafts contain solely the TLV encoding and IGP flooding = specifications, there is reason for them to be homed anywhere else. 

Thanks,
Acee 



Cheers, Manav

--
Thumb typed by Manav

On Jun 10, 2014 7:23 PM, "Jeffrey Haas"= ; <jhaas@pfrc.org> wrote:
Working Group,

Our updated charter was approved by the IESG.  The S-BFD work is offic= ially
in scope now!

Per our prior discussion, authors please submit the following documents as<= br> draft-ietf-bfd-*:

draft-aldrin-bfd-seamless-use-case (Milestone: November 2014)
draft-akiya-bfd-seamless-base (Milestone: March 2015)

The following documents are known to be work of interest, but aren't quite<= br> ready for adoption.  Please kick off additional discussions to drive t= hat
work forward:

draft-akiya-bfd-seamless-ip
draft-akiya-bfd-seamless-sr
draft-akiya-bfd-seamless-alert-discrim

My recommendation is to drive the IP case first.

-- Jeff





----- Forwarded message from The IESG <iesg-secretary@ietf.org> -----

Date: Thu, 05 Jun 2014 10:16:58 -0700
From: The IESG <iesg-secretar= y@ietf.org>
To: IETF-Announce <ietf-announ= ce@ietf.org>
Cc: bfd WG <rtg-bfd@ietf.org>=
Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd)
The Bidirectional Forwarding Detection (bfd) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs.

Bidirectional Forwarding Detection (bfd)
------------------------------------------------
Current Status: Active WG

Chairs:
  Nobo Akiya <nobo@cisco.com&= gt;
  Jeffrey Haas <jhaas@pfrc.org>

Technical advisors:
  Dave Katz <dkatz@juniper.net= >
  David Ward <dward@cisco.com>

Assigned Area Director:
  Adrian Farrel <adrian@oldd= og.co.uk>

Mailing list
  Address: rtg-bfd@ietf.org   To Subscribe: rtg-bfd-re= quest@ietf.org
  Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/

Charter:

The BFD Working Group is chartered to standardize and support the
bidirectional forwarding detection protocol (BFD) and its extensions.  = ;A
core goal of the working group is to standardize BFD in the context of
IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations.
The Working Group will also provide advice and guidance on BFD to other
working groups or standards bodies as requested.

BFD is a protocol intended to detect faults in the bidirectional path
between two forwarding engines, including physical interfaces,
subinterfaces, data link(s), and to the extent possible the forwarding
engines themselves, with potentially very low latency. It operates
independently of media, data protocols, and routing protocols. An
additional goal is to provide a single mechanism that can be used for
liveness detection over any media, at any protocol layer, with
a wide range of detection times and overhead, to avoid a proliferation
of different methods.

Important characteristics of BFD include:

- Simple, fixed-field encoding to facilitate implementations in
  hardware.

- Independence of the data protocol being forwarded between two systems.   BFD packets are carried as the payload of whatever encapsulating
  protocol is appropriate for the medium and network.

- Path independence: 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).

- Ability to be bootstrapped by any other protocol that automatically
  forms peer, neighbor or adjacency relationships to seed BFD endpoint=
  discovery.

The working group is currently chartered to complete the following work
items:

1. Develop further MIB modules for BFD and submit them to the IESG for
publication as Proposed Standards.

2a. Provide a generic keying-based cryptographic authentication
mechanism for the BFD protocol developing the work of the KARP
working group.  This mechanism  will support authentication throu= gh
a key identifier for the BFD session's Security Association rather
than specifying new authentication extensions.

2b. Provide extensions to the BFD MIB in support of the generic keying-
based cryptographic authentication mechanism.

2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check
value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism.

3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks.

4. Provide an informational document to recommend standardized timers
and timer operations for BFD when used in different applications.

5. Define a mechanism to perform single-ended path (i.e. continuity)
verification based on the BFD specification.  Allow such a mechanism t= o
work both proactively and on-demand, without prominent initial delay.
Allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG
will work closely with at least the following other WGs: ISIS, OSPF,
SPRING.

The working group will maintain a relationship with the MPLS working
group.

Milestones:
  Done     - Submit the base protocol specification to the I= ESG to be
considered as a Proposed Standard
  Done     - Submit BFD encapsulation and usage profile for = single-hop
IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed
Standard
  Done     - Submit BFD encapsulation and usage profile for = MPLS LSPs to
the IESG to be considered as a Proposed Standard
  Done     - Submit BFD encapsulation and usage profile for = multi-hop
IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed
Standard
  Done     - Submit the BFD MIB to the IESG to be considered= as a
Proposed Standard
  Done     - Submit the BFD over LAG mechanism to the IESG t= o be
considered as a Proposed Standard
  Jun 2014 - Submit the the document on BFD point-to-multipoint suppor= t
to the IESG to be considered as a Proposed Standard
  Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be
considered as a Proposed Standard
  Jan 2015 - Submit the generic keying based cryptographic authenticat= ion
mechanism to the IESG to be considered as a Proposed Standard
  Jan 2015 - Submit a BFD MIB extension in support of the generic keyi= ng
document to the IESG to be considered as a Proposed Standard
  Jan 2015 - Submit the cryptographic authentication procedures for BF= D
to the IESG to be considered as a Proposed Standard
  Jan 2015 - Submit the BFD Common Intervals document to the IESG to b= e
considered as an Informational RFC


----- End forwarded message -----

 --_000_CFBC813F3100Aaceelindemericssoncom_-- From nobody Tue Jun 10 10:03:55 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB83D1A019B; Tue, 10 Jun 2014 09:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WH-g-_gj-1t; Tue, 10 Jun 2014 09:50:47 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8EC1A021E; Tue, 10 Jun 2014 09:50:46 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-c5-5396e434b30d Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 36.DA.11744.434E6935; Tue, 10 Jun 2014 12:55:48 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 12:50:44 -0400 From: Acee Lindem To: Acee Lindem , Manav Bhatia , Jeffrey Haas , "rtg-bfd@ietf.org" , OSPF - OSPF WG List Subject: Re: [OSPF] BFD re-charter complete Thread-Topic: [OSPF] BFD re-charter complete Thread-Index: AQHPhLn1+tGMsKmUlUiLuM+ShUV36JtqWA6AgAAEbAA= Date: Tue, 10 Jun 2014 16:50:45 +0000 Message-ID: References: <20140610135340.GA19601@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_CFBC84C131017aceelindemericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyuXRPgq7Jk2nBBs+WKFrsP/iW1eLypDZ2 i5Z799gtPv/ZxujA4rFz1l12jyVLfjJ5XO7dyhrAHMVlk5Kak1mWWqRvl8CV8eDDd6aCmWsZ K94/OMvawHh9EmMXIyeHhICJxMWLm5khbDGJC/fWs3UxcnEICRxllLjUc4QZwlnOKHHq4gqw DjYBHYnnj/6BJUQE9jNK/N75GaxdWEBbYsnPf2BFIkBFPS8fs0LYVhJrPt8Bs1kEVCXWH7gF VM/BwStgKjHjhwfEgjmMEm1XzrGCxDkFzCTap/iClDMCXfT91BomEJtZQFzi1pP5TBCXCkgs 2XMe6mpRiZeP/4GNFxXQk2juegP1maLEvv7p7BC9URIX1rxmA7F5BQQlTs58wjKBUXQWkrGz kJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHUL3WEhM2v0RRs4CRYxUjR2lxalluupHhJkZg RB6TYHPcwbjgk+UhRgEORiUeXoXr04KFWBPLiitzDzFKc7AoifPuuVYVLCSQnliSmp2aWpBa FF9UmpNafIiRiYNTqoHRwfClZcErwS1dJ9awvflrZRxz/dWXHSLme0V9wzqvyQmlHzATEjJ7 IJ/XmLBpYZgCT8fxPu+LMd8bfr4LqdnT+zIxWkfsZrn8zxgtpQutUYdafHprfh158Pv6nPvz 92s4Rh+y+x5ZV1p/kNX1sMLx+kaLU9Ia7Kd1BN75Wdel87+/eTf+0SMlluKMREMt5qLiRACE ZPoMqQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/GrV6lF8eypw0jN0jM2o9tMSkbsI X-Mailman-Approved-At: Tue, 10 Jun 2014 10:03:55 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 16:50:50 -0000 --_000_CFBC84C131017aceelindemericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Ericsson > Date: Tuesday, June 10, 2014 9:34 AM To: Manav Bhatia >, Jef= frey Haas >, "rtg-bfd@ietf.org" >, OSPF - OSP= F WG List > Subject: Re: [OSPF] BFD re-charter complete Hi Manav, From: Manav Bhatia > Date: Tuesday, June 10, 2014 7:40 AM To: Jeffrey Haas >, "rtg-bfd@ietf.org= " >, OSP= F - OSPF WG List > Subject: Re: [OSPF] BFD re-charter complete Hi Jeff, What about the ospf/isis extn drafts for distributing the sbfd discriminato= rs? I guess these would be owned by the respective IGP WGs. Is this correct= ? Since the IGP drafts contain solely the TLV encoding and IGP flooding speci= fications, there is reason for them to be homed anywhere else. All, I meant "no reason for them to be homed anywhere else". Thanks, Acee Thanks, Acee Cheers, Manav -- Thumb typed by Manav On Jun 10, 2014 7:23 PM, "Jeffrey Haas" > wrote: Working Group, Our updated charter was approved by the IESG. The S-BFD work is officially in scope now! Per our prior discussion, authors please submit the following documents as draft-ietf-bfd-*: draft-aldrin-bfd-seamless-use-case (Milestone: November 2014) draft-akiya-bfd-seamless-base (Milestone: March 2015) The following documents are known to be work of interest, but aren't quite ready for adoption. Please kick off additional discussions to drive that work forward: draft-akiya-bfd-seamless-ip draft-akiya-bfd-seamless-sr draft-akiya-bfd-seamless-alert-discrim My recommendation is to drive the IP case first. -- Jeff ----- Forwarded message from The IESG > ----- Date: Thu, 05 Jun 2014 10:16:58 -0700 From: The IESG > To: IETF-Announce > Cc: bfd WG > Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd) The Bidirectional Forwarding Detection (bfd) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Bidirectional Forwarding Detection (bfd) ------------------------------------------------ Current Status: Active WG Chairs: Nobo Akiya > Jeffrey Haas > Technical advisors: Dave Katz > David Ward > Assigned Area Director: Adrian Farrel > Mailing list Address: rtg-bfd@ietf.org To Subscribe: rtg-bfd-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ Charter: The BFD Working Group is chartered to standardize and support the bidirectional forwarding detection protocol (BFD) and its extensions. A core goal of the working group is to standardize BFD in the context of IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. The Working Group will also provide advice and guidance on BFD to other working groups or standards bodies as requested. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware. - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: 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). - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. The working group is currently chartered to complete the following work items: 1. Develop further MIB modules for BFD and submit them to the IESG for publication as Proposed Standards. 2a. Provide a generic keying-based cryptographic authentication mechanism for the BFD protocol developing the work of the KARP working group. This mechanism will support authentication through a key identifier for the BFD session's Security Association rather than specifying new authentication extensions. 2b. Provide extensions to the BFD MIB in support of the generic keying- based cryptographic authentication mechanism. 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks. 4. Provide an informational document to recommend standardized timers and timer operations for BFD when used in different applications. 5. Define a mechanism to perform single-ended path (i.e. continuity) verification based on the BFD specification. Allow such a mechanism to work both proactively and on-demand, without prominent initial delay. Allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG will work closely with at least the following other WGs: ISIS, OSPF, SPRING. The working group will maintain a relationship with the MPLS working group. Milestones: Done - Submit the base protocol specification to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for MPLS LSPs to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit the BFD MIB to the IESG to be considered as a Proposed Standard Done - Submit the BFD over LAG mechanism to the IESG to be considered as a Proposed Standard Jun 2014 - Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard Jan 2015 - Submit a BFD MIB extension in support of the generic keying document to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the BFD Common Intervals document to the IESG to be considered as an Informational RFC ----- End forwarded message ----- --_000_CFBC84C131017aceelindemericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5F8456B945CB024CAAFE3BB80C6193FF@ericsson.com> Content-Transfer-Encoding: quoted-printable
Date: Tuesday, June 10, 2014 9:34 A= M
To: Manav Bhatia <manavbhatia@gmail.com>, Jeffrey Haas <= jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, OSPF - OSPF WG List <ospf@ietf.org= >
Subject: Re: [OSPF] BFD re-charter = complete

Hi Manav, 

From: Manav Bhatia <manavbhatia@gmail.com>
Date: Tuesday, June 10, 2014 7:40 A= M
To: Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, OSPF - OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] BFD re-charter = complete

Hi Jeff,

What about the ospf/isis extn drafts for distributing the sbfd discrimin= ators? I guess these would be owned by the respective IGP WGs. Is this corr= ect?
Since the IGP drafts contain solely the TLV encoding and IGP flooding = specifications, there is reason for them to be homed anywhere else. 

All,
I meant "no reason for them to be homed anywhere else". = ;
Thanks,
Acee 






Thanks,
Acee 



Cheers, Manav

--
Thumb typed by Manav

On Jun 10, 2014 7:23 PM, "Jeffrey Haas"= ; <jhaas@pfrc.org> wrote:
Working Group,

Our updated charter was approved by the IESG.  The S-BFD work is offic= ially
in scope now!

Per our prior discussion, authors please submit the following documents as<= br> draft-ietf-bfd-*:

draft-aldrin-bfd-seamless-use-case (Milestone: November 2014)
draft-akiya-bfd-seamless-base (Milestone: March 2015)

The following documents are known to be work of interest, but aren't quite<= br> ready for adoption.  Please kick off additional discussions to drive t= hat
work forward:

draft-akiya-bfd-seamless-ip
draft-akiya-bfd-seamless-sr
draft-akiya-bfd-seamless-alert-discrim

My recommendation is to drive the IP case first.

-- Jeff





----- Forwarded message from The IESG <iesg-secretary@ietf.org> -----

Date: Thu, 05 Jun 2014 10:16:58 -0700
From: The IESG <iesg-secretar= y@ietf.org>
To: IETF-Announce <ietf-announ= ce@ietf.org>
Cc: bfd WG <rtg-bfd@ietf.org>=
Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd)
The Bidirectional Forwarding Detection (bfd) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs.

Bidirectional Forwarding Detection (bfd)
------------------------------------------------
Current Status: Active WG

Chairs:
  Nobo Akiya <nobo@cisco.com&= gt;
  Jeffrey Haas <jhaas@pfrc.org>

Technical advisors:
  Dave Katz <dkatz@juniper.net= >
  David Ward <dward@cisco.com>

Assigned Area Director:
  Adrian Farrel <adrian@oldd= og.co.uk>

Mailing list
  Address: rtg-bfd@ietf.org   To Subscribe: rtg-bfd-re= quest@ietf.org
  Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/

Charter:

The BFD Working Group is chartered to standardize and support the
bidirectional forwarding detection protocol (BFD) and its extensions.  = ;A
core goal of the working group is to standardize BFD in the context of
IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations.
The Working Group will also provide advice and guidance on BFD to other
working groups or standards bodies as requested.

BFD is a protocol intended to detect faults in the bidirectional path
between two forwarding engines, including physical interfaces,
subinterfaces, data link(s), and to the extent possible the forwarding
engines themselves, with potentially very low latency. It operates
independently of media, data protocols, and routing protocols. An
additional goal is to provide a single mechanism that can be used for
liveness detection over any media, at any protocol layer, with
a wide range of detection times and overhead, to avoid a proliferation
of different methods.

Important characteristics of BFD include:

- Simple, fixed-field encoding to facilitate implementations in
  hardware.

- Independence of the data protocol being forwarded between two systems.   BFD packets are carried as the payload of whatever encapsulating
  protocol is appropriate for the medium and network.

- Path independence: 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).

- Ability to be bootstrapped by any other protocol that automatically
  forms peer, neighbor or adjacency relationships to seed BFD endpoint=
  discovery.

The working group is currently chartered to complete the following work
items:

1. Develop further MIB modules for BFD and submit them to the IESG for
publication as Proposed Standards.

2a. Provide a generic keying-based cryptographic authentication
mechanism for the BFD protocol developing the work of the KARP
working group.  This mechanism  will support authentication throu= gh
a key identifier for the BFD session's Security Association rather
than specifying new authentication extensions.

2b. Provide extensions to the BFD MIB in support of the generic keying-
based cryptographic authentication mechanism.

2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check
value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism.

3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks.

4. Provide an informational document to recommend standardized timers
and timer operations for BFD when used in different applications.

5. Define a mechanism to perform single-ended path (i.e. continuity)
verification based on the BFD specification.  Allow such a mechanism t= o
work both proactively and on-demand, without prominent initial delay.
Allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG
will work closely with at least the following other WGs: ISIS, OSPF,
SPRING.

The working group will maintain a relationship with the MPLS working
group.

Milestones:
  Done     - Submit the base protocol specification to the I= ESG to be
considered as a Proposed Standard
  Done     - Submit BFD encapsulation and usage profile for = single-hop
IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed
Standard
  Done     - Submit BFD encapsulation and usage profile for = MPLS LSPs to
the IESG to be considered as a Proposed Standard
  Done     - Submit BFD encapsulation and usage profile for = multi-hop
IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed
Standard
  Done     - Submit the BFD MIB to the IESG to be considered= as a
Proposed Standard
  Done     - Submit the BFD over LAG mechanism to the IESG t= o be
considered as a Proposed Standard
  Jun 2014 - Submit the the document on BFD point-to-multipoint suppor= t
to the IESG to be considered as a Proposed Standard
  Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be
considered as a Proposed Standard
  Jan 2015 - Submit the generic keying based cryptographic authenticat= ion
mechanism to the IESG to be considered as a Proposed Standard
  Jan 2015 - Submit a BFD MIB extension in support of the generic keyi= ng
document to the IESG to be considered as a Proposed Standard
  Jan 2015 - Submit the cryptographic authentication procedures for BF= D
to the IESG to be considered as a Proposed Standard
  Jan 2015 - Submit the BFD Common Intervals document to the IESG to b= e
considered as an Informational RFC


----- End forwarded message -----

 --_000_CFBC84C131017aceelindemericssoncom_-- From nobody Tue Jun 10 10:28:40 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B601A00D4; Tue, 10 Jun 2014 10:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9lxViERnScz; Tue, 10 Jun 2014 10:28:18 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 14BEA1A0040; Tue, 10 Jun 2014 10:28:18 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C9012C1AA; Tue, 10 Jun 2014 13:28:17 -0400 (EDT) Date: Tue, 10 Jun 2014 13:28:17 -0400 From: Jeffrey Haas To: Acee Lindem Subject: Re: [OSPF] BFD re-charter complete Message-ID: <20140610172817.GA28513@pfrc> References: <20140610135340.GA19601@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/aCaD6EZ5hRHJNloSrn9oaecY7G8 Cc: "rtg-bfd@ietf.org" , OSPF - OSPF WG List X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 17:28:20 -0000 Acee, On Tue, Jun 10, 2014 at 04:50:45PM +0000, Acee Lindem wrote: > Hi Jeff, > > What about the ospf/isis extn drafts for distributing the sbfd discriminators? I guess these would be owned by the respective IGP WGs. Is this correct? That's my belief. > > Since the IGP drafts contain solely the TLV encoding and IGP flooding > specifications, there is [no] reason for them to be homed anywhere else. More importantly, I think the "what we want to distribute" is the easy part of the problem. As WG discussion (mostly for the ISIS extention, if I recall correctly) had already suggested we may have specific need for help from the IGP groups to scope a given BFD discriminator that is distributed by the IGP. I don't believe I've yet read a draft for this in OSPF and thus don't know if the concern I had was the same as ISIS. -- Jeff From nobody Tue Jun 10 10:50:05 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725C41A0259; Tue, 10 Jun 2014 10:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Was33e0pkRfo; Tue, 10 Jun 2014 10:49:43 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36AC21A0240; Tue, 10 Jun 2014 10:49:43 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id uy5so6005572obc.3 for ; Tue, 10 Jun 2014 10:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7C6UJpry1Gn/wbF8ZZlsdnwxBrYGMkOZbcwKxy2LcsU=; b=WF8huHlBmEyqsh1oIfYSY/RCokz5pqebcCeDxlkux0q+C22CHkQuykOiiuIAmUspb0 5eWSznC4ynu4gWMFr+amfCcveFNAfFje1YYIMnY5Pki1Dpocia80pbM/G923+0m9tnyj 3+8IFc1soyVpgeE8m5//fcpRjWsAqSOgyVjoJQ5lTcotJFweKyyt4p6N5IvgevazNjrG MiVjuJJaafFLGwcZnT2TC8QqPClkCx47/w4OYWRjXmkiTRFmHFLoMo5J4XHpuBXSWAAr BzO+4w9iceENSWT9/GCZqarfz26V+u6SAcKUsngA4P/dwh0o3b7GFaZb+5wkFnzdqZLI KmjA== MIME-Version: 1.0 X-Received: by 10.182.138.99 with SMTP id qp3mr11009804obb.69.1402422582559; Tue, 10 Jun 2014 10:49:42 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Tue, 10 Jun 2014 10:49:42 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Tue, 10 Jun 2014 10:49:42 -0700 (PDT) In-Reply-To: References: <20140610135340.GA19601@pfrc> Date: Tue, 10 Jun 2014 10:49:42 -0700 Message-ID: Subject: Re: [OSPF] BFD re-charter complete From: Manav Bhatia To: Acee Lindem Content-Type: multipart/alternative; boundary=e89a8ff25450dbc7c204fb7ef333 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/FGs84b85SaZncADQimi3BhkshA0 Cc: OSPF - OSPF WG List , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 17:49:46 -0000 --e89a8ff25450dbc7c204fb7ef333 Content-Type: text/plain; charset=UTF-8 Hi Acee, You might also want to consider another draft submitted by Xu, Uma and yours truly which advertises a reachable ipv4/6 address in ospf te tlvs. That draft will be reqd by the sbfd to work. Thx, Manav -- Thumb typed by Manav On Jun 10, 2014 10:20 PM, "Acee Lindem" wrote: > From: Ericsson > Date: Tuesday, June 10, 2014 9:34 AM > To: Manav Bhatia , Jeffrey Haas , " > rtg-bfd@ietf.org" , OSPF - OSPF WG List > Subject: Re: [OSPF] BFD re-charter complete > > Hi Manav, > > From: Manav Bhatia > Date: Tuesday, June 10, 2014 7:40 AM > To: Jeffrey Haas , "rtg-bfd@ietf.org" , > OSPF - OSPF WG List > Subject: Re: [OSPF] BFD re-charter complete > > Hi Jeff, > > What about the ospf/isis extn drafts for distributing the sbfd > discriminators? I guess these would be owned by the respective IGP WGs. Is > this correct? > > Since the IGP drafts contain solely the TLV encoding and IGP flooding > specifications, there is reason for them to be homed anywhere else. > > > All, > I meant "no reason for them to be homed anywhere else". > Thanks, > Acee > > > > > > > Thanks, > Acee > > > > Cheers, Manav > > -- > Thumb typed by Manav > On Jun 10, 2014 7:23 PM, "Jeffrey Haas" wrote: > >> Working Group, >> >> Our updated charter was approved by the IESG. The S-BFD work is >> officially >> in scope now! >> >> Per our prior discussion, authors please submit the following documents as >> draft-ietf-bfd-*: >> >> draft-aldrin-bfd-seamless-use-case (Milestone: November 2014) >> draft-akiya-bfd-seamless-base (Milestone: March 2015) >> >> The following documents are known to be work of interest, but aren't quite >> ready for adoption. Please kick off additional discussions to drive that >> work forward: >> >> draft-akiya-bfd-seamless-ip >> draft-akiya-bfd-seamless-sr >> draft-akiya-bfd-seamless-alert-discrim >> >> My recommendation is to drive the IP case first. >> >> -- Jeff >> >> >> >> >> >> ----- Forwarded message from The IESG ----- >> >> Date: Thu, 05 Jun 2014 10:16:58 -0700 >> From: The IESG >> To: IETF-Announce >> Cc: bfd WG >> Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd) >> >> The Bidirectional Forwarding Detection (bfd) working group in the Routing >> Area of the IETF has been rechartered. For additional information please >> contact the Area Directors or the WG Chairs. >> >> Bidirectional Forwarding Detection (bfd) >> ------------------------------------------------ >> Current Status: Active WG >> >> Chairs: >> Nobo Akiya >> Jeffrey Haas >> >> Technical advisors: >> Dave Katz >> David Ward >> >> Assigned Area Director: >> Adrian Farrel >> >> Mailing list >> Address: rtg-bfd@ietf.org >> To Subscribe: rtg-bfd-request@ietf.org >> Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ >> >> Charter: >> >> The BFD Working Group is chartered to standardize and support the >> bidirectional forwarding detection protocol (BFD) and its extensions. A >> core goal of the working group is to standardize BFD in the context of >> IP routing, or protocols such as MPLS that are based on IP routing, in a >> way that will encourage multiple, inter-operable vendor implementations. >> >> The Working Group will also provide advice and guidance on BFD to other >> working groups or standards bodies as requested. >> >> BFD is a protocol intended to detect faults in the bidirectional path >> between two forwarding engines, including physical interfaces, >> subinterfaces, data link(s), and to the extent possible the forwarding >> engines themselves, with potentially very low latency. It operates >> independently of media, data protocols, and routing protocols. An >> additional goal is to provide a single mechanism that can be used for >> liveness detection over any media, at any protocol layer, with >> a wide range of detection times and overhead, to avoid a proliferation >> of different methods. >> >> Important characteristics of BFD include: >> >> - Simple, fixed-field encoding to facilitate implementations in >> hardware. >> >> - Independence of the data protocol being forwarded between two systems. >> BFD packets are carried as the payload of whatever encapsulating >> protocol is appropriate for the medium and network. >> >> - Path independence: 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). >> >> - Ability to be bootstrapped by any other protocol that automatically >> forms peer, neighbor or adjacency relationships to seed BFD endpoint >> discovery. >> >> The working group is currently chartered to complete the following work >> items: >> >> 1. Develop further MIB modules for BFD and submit them to the IESG for >> publication as Proposed Standards. >> >> 2a. Provide a generic keying-based cryptographic authentication >> mechanism for the BFD protocol developing the work of the KARP >> working group. This mechanism will support authentication through >> a key identifier for the BFD session's Security Association rather >> than specifying new authentication extensions. >> >> 2b. Provide extensions to the BFD MIB in support of the generic keying- >> based cryptographic authentication mechanism. >> >> 2c. Specify cryptographic authentication procedures for the BFD protocol >> using HMAC-SHA-256 (possibly truncated to a smaller integrity check >> value but not beyond commonly accepted lengths to ensure security) using >> the generic keying-based cryptographic authentication mechanism. >> >> 3. Provide an extension to the BFD core protocol in support of point-to- >> multipoint links and networks. >> >> 4. Provide an informational document to recommend standardized timers >> and timer operations for BFD when used in different applications. >> >> 5. Define a mechanism to perform single-ended path (i.e. continuity) >> verification based on the BFD specification. Allow such a mechanism to >> work both proactively and on-demand, without prominent initial delay. >> Allow the mechanism to maintain multiple sessions to a target entity and >> between the same pair of network entities. In doing this work, the WG >> will work closely with at least the following other WGs: ISIS, OSPF, >> SPRING. >> >> The working group will maintain a relationship with the MPLS working >> group. >> >> Milestones: >> Done - Submit the base protocol specification to the IESG to be >> considered as a Proposed Standard >> Done - Submit BFD encapsulation and usage profile for single-hop >> IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed >> Standard >> Done - Submit BFD encapsulation and usage profile for MPLS LSPs to >> the IESG to be considered as a Proposed Standard >> Done - Submit BFD encapsulation and usage profile for multi-hop >> IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed >> Standard >> Done - Submit the BFD MIB to the IESG to be considered as a >> Proposed Standard >> Done - Submit the BFD over LAG mechanism to the IESG to be >> considered as a Proposed Standard >> Jun 2014 - Submit the the document on BFD point-to-multipoint support >> to the IESG to be considered as a Proposed Standard >> Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be >> considered as a Proposed Standard >> Jan 2015 - Submit the generic keying based cryptographic authentication >> mechanism to the IESG to be considered as a Proposed Standard >> Jan 2015 - Submit a BFD MIB extension in support of the generic keying >> document to the IESG to be considered as a Proposed Standard >> Jan 2015 - Submit the cryptographic authentication procedures for BFD >> to the IESG to be considered as a Proposed Standard >> Jan 2015 - Submit the BFD Common Intervals document to the IESG to be >> considered as an Informational RFC >> >> >> ----- End forwarded message ----- >> >> --e89a8ff25450dbc7c204fb7ef333 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Acee,

You might also want to consider another draft submitted by Xu, Uma and y= ours truly which advertises a reachable ipv4/6 address in ospf te tlvs. Tha= t draft will be reqd by the sbfd to work.

Thx, Manav

--
Thumb typed by Manav

On Jun 10, 2014 10:20 PM, "Acee Lindem"= ; <acee.lindem@ericsson.com<= /a>> wrote:
Date: Tuesday, June 10, 2014 9:34 A= M
To: Manav Bhatia <manavbhatia@gmail.com>,= Jeffrey Haas <jhaas= @pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, OSPF - OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] BFD re-charter = complete

Hi Manav,=C2=A0

From: Manav Bhatia <manavbhatia@gmail.com>= ;
Date: Tuesday, June 10, 2014 7:40 A= M
To: Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf.org" &= lt;rtg-bfd@ietf.org>, OSPF - OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] BFD re-charter = complete

Hi Jeff,

What about the ospf/isis extn drafts for distributing the sbfd discrimin= ators? I guess these would be owned by the respective IGP WGs. Is this corr= ect?
Since the IGP drafts contain solely the TLV encoding and IGP flooding = specifications, there is reason for them to be homed anywhere else.=C2=A0

All,
I meant "no reason for them to be homed anywhere else".=C2= =A0
Thanks,
Acee=C2=A0






Thanks,
Acee=C2=A0



Cheers, Manav

--
Thumb typed by Manav

On Jun 10, 2014 7:23 PM, "Jeffrey Haas"= ; <jhaas@pfrc.org> wrote:
Working Group,

Our updated charter was approved by the IESG. =C2=A0The S-BFD work is offic= ially
in scope now!

Per our prior discussion, authors please submit the following documents as<= br> draft-ietf-bfd-*:

draft-aldrin-bfd-seamless-use-case (Milestone: November 2014)
draft-akiya-bfd-seamless-base (Milestone: March 2015)

The following documents are known to be work of interest, but aren't qu= ite
ready for adoption. =C2=A0Please kick off additional discussions to drive t= hat
work forward:

draft-akiya-bfd-seamless-ip
draft-akiya-bfd-seamless-sr
draft-akiya-bfd-seamless-alert-discrim

My recommendation is to drive the IP case first.

-- Jeff





----- Forwarded message from The IESG <iesg-secretary@ietf.org> -----

Date: Thu, 05 Jun 2014 10:16:58 -0700
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: bfd WG <rtg-bf= d@ietf.org>
Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd)
The Bidirectional Forwarding Detection (bfd) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs.

Bidirectional Forwarding Detection (bfd)
------------------------------------------------
Current Status: Active WG

Chairs:
=C2=A0 Nobo Akiya <n= obo@cisco.com>
=C2=A0 Jeffrey Haas <jhaas@pfrc.org>

Technical advisors:
=C2=A0 Dave Katz <dkatz@juniper.net>
=C2=A0 David Ward <= dward@cisco.com>

Assigned Area Director:
=C2=A0 Adrian Farrel <adrian@olddog.co.uk>

Mailing list
=C2=A0 Address: rtg-b= fd@ietf.org
=C2=A0 To Subscribe: rtg-bfd-request@ietf.org
=C2=A0 Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/

Charter:

The BFD Working Group is chartered to standardize and support the
bidirectional forwarding detection protocol (BFD) and its extensions. =C2= =A0A
core goal of the working group is to standardize BFD in the context of
IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations.
The Working Group will also provide advice and guidance on BFD to other
working groups or standards bodies as requested.

BFD is a protocol intended to detect faults in the bidirectional path
between two forwarding engines, including physical interfaces,
subinterfaces, data link(s), and to the extent possible the forwarding
engines themselves, with potentially very low latency. It operates
independently of media, data protocols, and routing protocols. An
additional goal is to provide a single mechanism that can be used for
liveness detection over any media, at any protocol layer, with
a wide range of detection times and overhead, to avoid a proliferation
of different methods.

Important characteristics of BFD include:

- Simple, fixed-field encoding to facilitate implementations in
=C2=A0 hardware.

- Independence of the data protocol being forwarded between two systems. =C2=A0 BFD packets are carried as the payload of whatever encapsulating
=C2=A0 protocol is appropriate for the medium and network.

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

- Ability to be bootstrapped by any other protocol that automatically
=C2=A0 forms peer, neighbor or adjacency relationships to seed BFD endpoint=
=C2=A0 discovery.

The working group is currently chartered to complete the following work
items:

1. Develop further MIB modules for BFD and submit them to the IESG for
publication as Proposed Standards.

2a. Provide a generic keying-based cryptographic authentication
mechanism for the BFD protocol developing the work of the KARP
working group. =C2=A0This mechanism =C2=A0will support authentication throu= gh
a key identifier for the BFD session's Security Association rather
than specifying new authentication extensions.

2b. Provide extensions to the BFD MIB in support of the generic keying-
based cryptographic authentication mechanism.

2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check
value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism.

3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks.

4. Provide an informational document to recommend standardized timers
and timer operations for BFD when used in different applications.

5. Define a mechanism to perform single-ended path (i.e. continuity)
verification based on the BFD specification. =C2=A0Allow such a mechanism t= o
work both proactively and on-demand, without prominent initial delay.
Allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG
will work closely with at least the following other WGs: ISIS, OSPF,
SPRING.

The working group will maintain a relationship with the MPLS working
group.

Milestones:
=C2=A0 Done =C2=A0 =C2=A0 - Submit the base protocol specification to the I= ESG to be
considered as a Proposed Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit BFD encapsulation and usage profile for = single-hop
IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed
Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit BFD encapsulation and usage profile for = MPLS LSPs to
the IESG to be considered as a Proposed Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit BFD encapsulation and usage profile for = multi-hop
IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed
Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit the BFD MIB to the IESG to be considered= as a
Proposed Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit the BFD over LAG mechanism to the IESG t= o be
considered as a Proposed Standard
=C2=A0 Jun 2014 - Submit the the document on BFD point-to-multipoint suppor= t
to the IESG to be considered as a Proposed Standard
=C2=A0 Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be
considered as a Proposed Standard
=C2=A0 Jan 2015 - Submit the generic keying based cryptographic authenticat= ion
mechanism to the IESG to be considered as a Proposed Standard
=C2=A0 Jan 2015 - Submit a BFD MIB extension in support of the generic keyi= ng
document to the IESG to be considered as a Proposed Standard
=C2=A0 Jan 2015 - Submit the cryptographic authentication procedures for BF= D
to the IESG to be considered as a Proposed Standard
=C2=A0 Jan 2015 - Submit the BFD Common Intervals document to the IESG to b= e
considered as an Informational RFC


----- End forwarded message -----
--e89a8ff25450dbc7c204fb7ef333-- From nobody Tue Jun 10 13:21:59 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A8F1A02A6 for ; Tue, 10 Jun 2014 13:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -117.151 X-Spam-Level: X-Spam-Status: No, score=-117.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzOngs-KI6t2 for ; Tue, 10 Jun 2014 13:21:36 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C4411A02D0 for ; Tue, 10 Jun 2014 13:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27374; q=dns/txt; s=iport; t=1402431696; x=1403641296; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=FNXLKtPhdHv1JmqFK2KwvPLrMIPahMoSQDXVw8rZ5JI=; b=jFowB0I8PFZIIBhlRK/zovAW/dEospfMb7Yw98M+UTD6CrTaD4tML31L jh2/SMher34CGWhsbu5KL9D0niLUUPkmHga32xjUmcmapc9UQ359Lf3of wD2ePC/BiNQtl8vPT+iuwSkaCebuUP2e58bXvWYUCdW+6N5+rHE814D6L 4=; X-Files: ATT00001.txt : 169 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFANJnl1OtJA2E/2dsb2JhbABYgkYjJFJZgmy4CIFRAYZqUQEZcRZ1hAMBAQEEAQEBIApBGwIBCBEEAQELHQMCAgIlCxQHAQEFAwIEEwgGDogmAQyuFZ8AF41mMjcBBoJvNoEWBJFugTuCK4YSkgODPGyBQw X-IronPort-AV: E=Sophos;i="4.98,1011,1392163200"; d="txt'?scan'208,217";a="51886496" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP; 10 Jun 2014 20:21:35 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5AKLZpI021314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Jun 2014 20:21:35 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Tue, 10 Jun 2014 15:21:35 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: FW: Improving and Restructuring the Routing Area Thread-Topic: Improving and Restructuring the Routing Area Thread-Index: AQHPhOZO5JEEQzlurUmV+y1ULT+bpptqx8Yg Date: Tue, 10 Jun 2014 20:21:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.71] Content-Type: multipart/mixed; boundary="_004_CECE764681BE964CBE1DFF78F3CDD3941E1DF930xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/UFWcQWYC11cVmageVuLpRyXIPKI X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 20:21:39 -0000 --_004_CECE764681BE964CBE1DFF78F3CDD3941E1DF930xmbalnx01ciscoc_ Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941E1DF930xmbalnx01ciscoc_" --_000_CECE764681BE964CBE1DFF78F3CDD3941E1DF930xmbalnx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQkZEZXJzLA0KDQpJbiBjYXNlIHNvbWUgb2YgeW91IGFyZSBub3Qgb24gdGhlIHJvdXRpbmct ZGlzY3Vzc2lvbiBtYWlsaW5nIGxpc3QsIGZvcndhcmRpbmcgYW4gaW1wb3J0YW50IG1lc3NhZ2Ug KGFuZCBpbnZpdGF0aW9uIGZvciBkaXNjdXNzaW9ucykgZnJvbSBvdXIgQURzIOKApg0KDQotTm9i bw0KDQpGcm9tOiByb3V0aW5nLWRpc2N1c3Npb24gW21haWx0bzpyb3V0aW5nLWRpc2N1c3Npb24t Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsaWEgQXRsYXMNClNlbnQ6IFR1ZXNkYXks IEp1bmUgMTAsIDIwMTQgMzo1OCBQTQ0KVG86IHJvdXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZw0K U3ViamVjdDogSW1wcm92aW5nIGFuZCBSZXN0cnVjdHVyaW5nIHRoZSBSb3V0aW5nIEFyZWENCg0K VG8gYWxsIHBhcnRpY2lwYW50cyBpbiB0aGUgUm91dGluZyBBcmVhLA0KDQpBZHJpYW4gYW5kIEkg YXJlIHdvcmtpbmcgb24gaW1wcm92aW5nIHRoZSBxdWFsaXR5LCBzcGVlZCwgYW5kDQpleHBlcmll bmNlIG9mIGdldHRpbmcgd29yayBkb25lIGluIHRoZSBJRVRGIFJvdXRpbmcgQXJlYS4gIFRoZXJl IGFyZQ0KdGhyZWUgaW5pdGlhdGl2ZXMgdGhhdCB3ZSBhcmUgd29ya2luZzogV0cgRHJhZnQgUUEs IFJvdXRpbmcgQXJlYQ0Kc3BlY2lmaWMgV0cgY2hhaXIgdHJhaW5pbmcsIGFuZCByZW9yZ2FuaXpp bmcgdGhlIHdvcmtpbmcgZ3JvdXBzIGluIHRoZQ0KYXJlYS4NCg0KRmlyc3QsIHdlIGludGVuZCB0 byB1c2Ugb3VyIFJvdXRpbmcgRGlyZWN0b3JhdGUgbW9yZSBwcm9hY3RpdmVseSBieQ0KaW50cm9k dWNpbmcgYSBXb3JraW5nIEdyb3VwIERyYWZ0IFF1YWxpdHkgQXNzdXJhbmNlIChXRyBEcmFmdCBR QSkNCnByb2Nlc3Mgd2hlcmUgdGhlIHNhbWUgc2VsZWN0ZWQgcm91dGluZyBkaXJlY3RvcmF0ZSBt ZW1iZXIgd2lsbCByZXZpZXcNCmEgZHJhZnQgZHVyaW5nIFdHIGRyYWZ0IGFkb3B0aW9uIGFuZCBk dXJpbmcgV0cgbGFzdCBjYWxsLiAgVGhlIHByb2Nlc3MNCndpbGwgYmUgZG9jdW1lbnRlZCBvbiB0 aGUgUm91dGluZyBBcmVhIHdpa2kNCihodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0 Zy90cmFjL3dpa2kpLiAgVGhpcyBzaG91bGQgYWxsb3cNCmRpcmVjdG9yYXRlIHJldmlld3MgdG8g cmVwb3J0IHRlY2huaWNhbCBpc3N1ZXMgdGhhdCBjYW4gYWN0dWFsbHkgZ2V0DQpmaXhlZCBlYXJs eSBpbiB0aGUgcHJvY2VzcyAoZXF1aXZhbGVudCBvZiBidWcgcmVwb3J0cykgYXMgb3Bwb3NlZCB0 bw0KanVzdCBub3RpbmcgdGhlIGNvbmNlcm5zIGluIHRoZSBkcmFmdHMgKGVxdWl2YWxlbnQgb2Yg cmVsZWFzZSBub3RlcykuDQoNClNlY29uZCwgYXMgd2FzIGRpc2N1c3NlZCBkdXJpbmcgdGhlIHJl Y2VudCBJRVNHIHJldHJlYXQsIGluIGFkZGl0aW9uDQp0byB0aGUgSUVURi13aWRlIFdHIGNoYWly IHRyYWluaW5nLCB3ZSBpbnRlbmQgdG8gaGF2ZSBhIHNlcmllcyBvZg0KdHJhaW5pbmcgc2Vzc2lv bnMgZm9yIFdHIENoYWlycyBpbiB0aGUgUm91dGluZyBBcmVhIGFkZHJlc3NpbmcgdG9waWNzDQpz dWNoIGFzIGp1ZGdpbmcgY29uc2Vuc3VzLCBwcm9qZWN0IG1hbmFnZW1lbnQsIG1vdGl2YXRpbmcg dm9sdW50ZWVycywNCnVzaW5nIHRoZSBkYXRhdHJhY2tlciAodmlhIGEgc2FuZGJveCB2ZXJzaW9u IHRoYXQgY2FuIGJlIHBsYXllZA0Kd2l0aCBzYWZlbHkpLCBhbmQgc2hhcmluZyBleHBlcmllbmNl cyBiZXR3ZWVuIFdHIGNoYWlycy4NCg0KVGhpcmQsIHdlIGludGVuZCB0byByZW9yZ2FuaXplIHRo ZSB3b3JraW5nIGdyb3VwcyBpbiB0aGUgUm91dGluZyBhcmVhLg0KV2UgZmVlbCB0aGF0IGl0IGlz IGltcG9ydGFudCB0byBmb2N1cyBvbiBhcmVhcyB3aGVyZSB0aGVyZSBpcyBhY3RpdmUNCmludGVy ZXN0IGluIHN0YW5kYXJkaXphdGlvbiBhbmQgdG8gYmUgb3BlbiBhbmQgYWJsZSB0byBhY2NlcHQg bmV3IHdvcmsNCmludG8gdGhlIGFyZWEuICBBcyB5b3Uga25vdywgd2UgaGF2ZSBoYWQgc2V2ZXJh bCBuZXcgd29ya2luZyBncm91cHMNCihudm8zLCBpMnJzLCBzZmMsIHNwcmluZykgY3JlYXRlZCBp biB0aGUgbGFzdCBmZXcgeWVhcnMgYW5kIHdlIG5lZWQgdG8NCmJlIG9wZW4gYW5kIGFibGUgdG8g aGFuZGxlIG1vcmUgbmV3IHdvcmsgYXMgaXQgY29tZXMgaW4uICBXZSB3b3VsZA0KYWxzbyBsaWtl IHRvIGltcHJvdmUgdGhlIHNpZ25hbC10by1ub2lzZSByYXRpbyBleHBlcmllbmNlZCBieQ0KcGFy dGljaXBhbnRzIGluIHRoZSBkaWZmZXJlbnQgd29ya2luZyBncm91cHMgYW5kIGltcHJvdmUgdGhl IHF1YW50aXR5DQphbmQgcXVhbGl0eSBvZiBkaXNjdXNzaW9uIGFuZCByZXZpZXdzLiAgSXQgaXMg bGlrZWx5IHRoYXQgbm90IGFsbCBXR3MNCmluIHRoZSBSb3V0aW5nIEFyZWEgd2lsbCBiZSBkaXJl Y3RseSBhZmZlY3RlZC4NCg0KSGVyZSBpcyB0aGUgdGltZS1saW5lIGZvciByZW9yZ2FuaXppbmcg dGhlIFdHcy4NCg0KICAgTk9XOiBwdWJsaWMgZGlzY3Vzc2lvbiBvbiByb3V0aW5nLWRpc2N1c3Np b25AaWV0Zi5vcmc8bWFpbHRvOnJvdXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZz4gYWJvdXQgaG93 IHRvDQogICByZW9yZ2FuaXplIHRoZSB3b3JraW5nIGdyb3VwcyB0byBiZXN0IG1lZXQgb3VyIG1v dGl2YXRpb25zLg0KICAgQWRkaXRpb25hbCBmb2N1c2VkIGRpc2N1c3Npb25zIGFyZSBleHBlY3Rl ZCBvbiB0aGUNCiAgIHJ0Zy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1jaGFpcnNAaWV0Zi5v cmc+IGFuZCBydGctZGlyQGlldGYub3JnPG1haWx0bzpydGctZGlyQGlldGYub3JnPiBtYWlsaW5n IGxpc3RzLg0KDQogICBJbiBUb3JvbnRvOiBUaGVyZSB3aWxsIGJlIG1lZXRpbmdzIHdpdGggdGhl IFdHIGNoYWlycyBhbmQgdGhlDQogICBSb3V0aW5nIERpcmVjdG9yYXRlIHRvIGdldCB0aGUgaWRl YXMgZGVzY3JpYmVkIGFuZCBhZ3JlZWQgdXBvbi4NCg0KICAgQXQgdGhlIFJvdXRpbmcgQXJlYSBN ZWV0aW5nIGluIFRvcm9udG86IERpc2N1c3MgdGhlIHNldCBvZg0KICAgcmVvcmdhbml6ZWQgV0dz IGFuZCBnZW5lcmFsIGNoYXJ0ZXIgY29udGVudCBpbiB0aGUgUm91dGluZyBBcmVhDQogICBtZWV0 aW5nLg0KDQogICBTZXB0ZW1iZXIgMjAxNDogQmFzZWQgdXBvbiB0aGUgZmVlZGJhY2ssIHN1Z2dl c3Rpb25zLCBhbmQNCiAgIGRpc2N1c3Npb24sIEFkcmlhbiBhbmQgSSBmaW5hbGl6ZSB0aGUgcmVv cmdhbml6ZWQgV0cgY2hhcnRlcnMuICBXZQ0KICAgc3RhcnQgdGhlIGludGVybmFsIElFU0cgZGlz Y3Vzc2lvbiBhbmQgcHVibGljIHJldmlld3MuDQoNCiAgIE9jdG9iZXIgMjAxNDogRm9ybWFsIHJl Y2hhcnRlcmluZyBwcm9jZXNzIGNvbXBsZXRlcy4NCg0KICAgSW4gSG9ub2x1bHU6IFRoZSBuZXcg c2V0IG9mIFdHcyBtZWV0Lg0KDQogICBBZnRlciBIb25vbHVsdTogQWRyaWFuIGFuZCBJIGRlYWwg d2l0aCBhbnkgaXNzdWVzIGFuZCBjaGFydGVyDQogICB1cGRhdGVzIGJhc2VkIHVwb24gYSBmZXcg bW9udGhzIG9mIGV4cGVyaWVuY2UuDQoNCkhlcmUgYXJlIHRoZSBtb3RpdmF0aW9ucyB0aGF0IEFk cmlhbiBhbmQgSSB3b3VsZCBsaWtlIHRvIGJlIGNvbnNpZGVyZWQNCndoZW4gY29taW5nIHVwIHdp dGggaWRlYXMgZm9yIGhvdyB0aGUgV0dzIHNob3VsZCBiZSByZW9yZ2FuaXplZC4NCg0KICAgMSkg TW92ZSB0b3dhcmRzIG9yZ2FuaXppbmcgd29ya2luZyBncm91cHMgb24gZnVuY3Rpb25hbA0KICAg cmVzcG9uc2liaWxpdGllcyByYXRoZXIgdGhhbiBzY29waW5nIHRoZW0gdG8gc3BlY2lmaWMgcHJv dG9jb2xzLg0KDQogICAyKSBTcGxpdCBnaWFudCB3b3JraW5nIGdyb3VwcyBzbyByZWxldmFudCB3 b3JrIGlzIGRvbmUgaW4gb25lIHBsYWNlDQogICBhbmQgdGhlcmUgaXMgYW4gaW1wcm92ZWQgc2ln bmFsLXRvLW5vaXNlIHJhdGlvIGZvciBwYXJ0aWNpcGFudHMgd2hvDQogICBhcmUgb25seSBpbnRl cmVzdGVkIGluIGEgc2xpY2Ugb2YgdGhlIGN1cnJlbnQgd29ya2luZyBncm91cCdzIHdvcmsuDQoN CiAgIDMpIENyZWF0ZSBzeW5lcmdpZXMgZm9yIHNjYXR0ZXJlZCBmdW5jdGlvbmFsaXR5IChleGFt cGxlIGlkZWFzOg0KICAgT0FNLCBGUlIsIHRyYWZmaWMtZW5naW5lZXJpbmcpDQoNCiAgIDQpIENy ZWF0ZSBhIERJU1BBVENIIHdvcmtpbmcgZ3JvdXAgZm9yIGNsZWFyIG5ldyBpZGVhIGRpc2N1c3Np b247DQogICBydGd3ZyBzZXJ2ZXMgc29tZSBvZiB0aGlzIHB1cnBvc2UgYnV0IGRvZXNuJ3QgaGF2 ZSBhIGNsZWFyIHByb2Nlc3MNCiAgIGFuZCBpc24ndCBkcmF3aW5nIGluIHRoZSBuZXcgaWRlYXMu DQoNCiAgIDUpIEZvY3VzIFJvdXRpbmcgQXJlYSB0aW1lIG9uIGRlc2lnbiBjZW50ZXJzIHJhdGhl ciB0aGFuIG9uIGZhcg0KICAgY29ybmVyIGNhc2VzLg0KDQogICA2KSBFYWNoIHdvcmtpbmcgZ3Jv dXAgc2hvdWxkIGhhdmUgY2xlYXIsIHdlbGwgZGVmaW5lZCwgYW5kIGFjaGlldmFibGUgZ29hbHMu DQoNCk5vdGluZyB0aGF0IHRoZSBSb3V0aW5nIEFyZWEgaGFzIGluaGVyaXRlZCBzb21lIG9mIGl0 cyBXRyBzdHJ1Y3R1cmUNCmZyb20gdGhlIHN1Yi1JUCBhcmVhLCBpdCBpcyBub3QgYSBnb2FsIHRv IGZvcmNlIElQIHJvdXRpbmcgYW5kIE1QTFMNCnJvdXRpbmcgdG8gcmVtYWluIHNlcGFyYXRlZC4N Cg0KVGhlIGdvYWwgb2YgdGhpcyByZW9yZ2FuaXphdGlvbiBpcyBub3QgY2xvc2luZyB3b3JraW5n IGdyb3Vwcy4gIEFkcmlhbg0KYW5kIEFsaWEgYXJlIHBlcmZlY3RseSBjYXBhYmxlIG9mIGNsb3Np bmcgd29ya2luZyBncm91cHMgd2l0aG91dCBnb2luZw0KdGhyb3VnaCByZXN0cnVjdHVyaW5nLg0K DQpGb3IgdGhvc2Ugb2YgeW91IHRoYXQgaGF2ZSByZWFkIHRoaXMgZmFyLCB0aGFuayB5b3UuICBH ZXR0aW5nIHRoaXMgODAlDQpyaWdodCBpcyBnb2luZyB0byB0YWtlIHNvbWUgc2VyaW91cyBkaXNj dXNzaW9uIGFuZCB0aG91Z2h0LiAgV2UgYWxsDQp3b3JrIGluIHRoZSBSb3V0aW5nIEFyZWEgdG9n ZXRoZXIgd2l0aCBkaWZmZXJlbnQgcGVyc3BlY3RpdmVzLiAgUGxlYXNlDQp0aGluayBjYXJlZnVs bHkgYW5kIGhlbHAgdXMgaGF2ZSBhIGhpZ2hseSBmb2N1c2VkIGRpc2N1c3Npb24uDQoNClRoYW5r cywNCkFsaWEgYW5kIEFkcmlhbg0KDQo= --_000_CECE764681BE964CBE1DFF78F3CDD3941E1DF930xmbalnx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQ0EiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBCRkRlcnMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J biBjYXNlIHNvbWUgb2YgeW91IGFyZSBub3Qgb24gdGhlIHJvdXRpbmctZGlzY3Vzc2lvbiBtYWls aW5nIGxpc3QsIGZvcndhcmRpbmcgYW4gaW1wb3J0YW50IG1lc3NhZ2UgKGFuZCBpbnZpdGF0aW9u IGZvciBkaXNjdXNzaW9ucykgZnJvbSBvdXIgQURzIOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LU5vYm88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiByb3V0aW5nLWRpc2N1c3Npb24gW21haWx0bzpyb3V0aW5nLWRpc2N1c3Npb24tYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWxpYSBBdGxhczxicj4NCjxiPlNl bnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDEwLCAyMDE0IDM6NTggUE08YnI+DQo8Yj5Ubzo8L2I+IHJv dXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBJbXByb3Zpbmcg YW5kIFJlc3RydWN0dXJpbmcgdGhlIFJvdXRpbmcgQXJlYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gYWxsIHBhcnRpY2lwYW50 cyBpbiB0aGUgUm91dGluZyBBcmVhLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BZHJpYW4gYW5kIEkgYXJlIHdvcmtpbmcgb24gaW1wcm92aW5n IHRoZSBxdWFsaXR5LCBzcGVlZCwgYW5kPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5leHBlcmllbmNlIG9mIGdldHRpbmcgd29yayBkb25lIGluIHRo ZSBJRVRGIFJvdXRpbmcgQXJlYS4gJm5ic3A7VGhlcmUgYXJlPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aHJlZSBpbml0aWF0aXZlcyB0aGF0IHdl IGFyZSB3b3JraW5nOiBXRyBEcmFmdCBRQSwgUm91dGluZyBBcmVhPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zcGVjaWZpYyBXRyBjaGFpciB0cmFp bmluZywgYW5kIHJlb3JnYW5pemluZyB0aGUgd29ya2luZyBncm91cHMgaW4gdGhlPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hcmVhLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GaXJzdCwgd2Ug aW50ZW5kIHRvIHVzZSBvdXIgUm91dGluZyBEaXJlY3RvcmF0ZSBtb3JlIHByb2FjdGl2ZWx5IGJ5 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pbnRy b2R1Y2luZyBhIFdvcmtpbmcgR3JvdXAgRHJhZnQgUXVhbGl0eSBBc3N1cmFuY2UgKFdHIERyYWZ0 IFFBKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ cHJvY2VzcyB3aGVyZSB0aGUgc2FtZSBzZWxlY3RlZCByb3V0aW5nIGRpcmVjdG9yYXRlIG1lbWJl ciB3aWxsIHJldmlldzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+YSBkcmFmdCBkdXJpbmcgV0cgZHJhZnQgYWRvcHRpb24gYW5kIGR1cmluZyBXRyBs YXN0IGNhbGwuICZuYnNwO1RoZSBwcm9jZXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53aWxsIGJlIGRvY3VtZW50ZWQgb24gdGhlIFJvdXRpbmcg QXJlYSB3aWtpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4oPGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93 aWtpIj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2k8L2E+KS4g Jm5ic3A7VGhpcyBzaG91bGQgYWxsb3c8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmRpcmVjdG9yYXRlIHJldmlld3MgdG8gcmVwb3J0IHRlY2huaWNh bCBpc3N1ZXMgdGhhdCBjYW4gYWN0dWFsbHkgZ2V0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5maXhlZCBlYXJseSBpbiB0aGUgcHJvY2VzcyAoZXF1 aXZhbGVudCBvZiBidWcgcmVwb3J0cykgYXMgb3Bwb3NlZCB0bzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+anVzdCBub3RpbmcgdGhlIGNvbmNlcm5z IGluIHRoZSBkcmFmdHMgKGVxdWl2YWxlbnQgb2YgcmVsZWFzZSBub3RlcykuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY29uZCwgYXMgd2Fz IGRpc2N1c3NlZCBkdXJpbmcgdGhlIHJlY2VudCBJRVNHIHJldHJlYXQsIGluIGFkZGl0aW9uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50byB0aGUg SUVURi13aWRlIFdHIGNoYWlyIHRyYWluaW5nLCB3ZSBpbnRlbmQgdG8gaGF2ZSBhIHNlcmllcyBv ZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dHJh aW5pbmcgc2Vzc2lvbnMgZm9yIFdHIENoYWlycyBpbiB0aGUgUm91dGluZyBBcmVhIGFkZHJlc3Np bmcgdG9waWNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5zdWNoIGFzIGp1ZGdpbmcgY29uc2Vuc3VzLCBwcm9qZWN0IG1hbmFnZW1lbnQsIG1vdGl2 YXRpbmcgdm9sdW50ZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPnVzaW5nIHRoZSBkYXRhdHJhY2tlciAodmlhIGEgc2FuZGJveCB2ZXJzaW9u IHRoYXQgY2FuIGJlIHBsYXllZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+d2l0aCBzYWZlbHkpLCBhbmQgc2hhcmluZyBleHBlcmllbmNlcyBiZXR3 ZWVuIFdHIGNoYWlycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhpcmQsIHdlIGludGVuZCB0byByZW9yZ2FuaXplIHRoZSB3b3JraW5nIGdy b3VwcyBpbiB0aGUgUm91dGluZyBhcmVhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgZmVlbCB0aGF0IGl0IGlzIGltcG9ydGFudCB0byBmb2N1 cyBvbiBhcmVhcyB3aGVyZSB0aGVyZSBpcyBhY3RpdmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmludGVyZXN0IGluIHN0YW5kYXJkaXphdGlvbiBh bmQgdG8gYmUgb3BlbiBhbmQgYWJsZSB0byBhY2NlcHQgbmV3IHdvcms8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmludG8gdGhlIGFyZWEuICZuYnNw O0FzIHlvdSBrbm93LCB3ZSBoYXZlIGhhZCBzZXZlcmFsIG5ldyB3b3JraW5nIGdyb3VwczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KG52bzMsIGky cnMsIHNmYywgc3ByaW5nKSBjcmVhdGVkIGluIHRoZSBsYXN0IGZldyB5ZWFycyBhbmQgd2UgbmVl ZCB0bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ YmUgb3BlbiBhbmQgYWJsZSB0byBoYW5kbGUgbW9yZSBuZXcgd29yayBhcyBpdCBjb21lcyBpbi4g Jm5ic3A7V2Ugd291bGQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPmFsc28gbGlrZSB0byBpbXByb3ZlIHRoZSBzaWduYWwtdG8tbm9pc2UgcmF0aW8g ZXhwZXJpZW5jZWQgYnk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnBhcnRpY2lwYW50cyBpbiB0aGUgZGlmZmVyZW50IHdvcmtpbmcgZ3JvdXBzIGFu ZCBpbXByb3ZlIHRoZSBxdWFudGl0eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+YW5kIHF1YWxpdHkgb2YgZGlzY3Vzc2lvbiBhbmQgcmV2aWV3cy4g Jm5ic3A7SXQgaXMgbGlrZWx5IHRoYXQgbm90IGFsbCBXR3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmluIHRoZSBSb3V0aW5nIEFyZWEgd2lsbCBi ZSBkaXJlY3RseSBhZmZlY3RlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGVyZSBpcyB0aGUgdGltZS1saW5lIGZvciByZW9yZ2FuaXppbmcg dGhlIFdHcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7ICZuYnNwO05PVzogcHVibGljIGRpc2N1c3Npb24gb24gPGEgaHJlZj0ibWFp bHRvOnJvdXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZyI+DQpyb3V0aW5nLWRpc2N1c3Npb25AaWV0 Zi5vcmc8L2E+IGFib3V0IGhvdyB0bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3Jlb3JnYW5pemUgdGhlIHdvcmtpbmcgZ3Jv dXBzIHRvIGJlc3QgbWVldCBvdXIgbW90aXZhdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7QWRkaXRpb25hbCBmb2N1 c2VkIGRpc2N1c3Npb25zIGFyZSBleHBlY3RlZCBvbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDs8YSBocmVmPSJtYWls dG86cnRnLWNoYWlyc0BpZXRmLm9yZyI+cnRnLWNoYWlyc0BpZXRmLm9yZzwvYT4gYW5kDQo8YSBo cmVmPSJtYWlsdG86cnRnLWRpckBpZXRmLm9yZyI+cnRnLWRpckBpZXRmLm9yZzwvYT4gbWFpbGlu ZyBsaXN0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7ICZuYnNwO0luIFRvcm9udG86IFRoZXJlIHdpbGwgYmUgbWVldGluZ3Mgd2l0 aCB0aGUgV0cgY2hhaXJzIGFuZCB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtSb3V0aW5nIERpcmVjdG9yYXRlIHRvIGdl dCB0aGUgaWRlYXMgZGVzY3JpYmVkIGFuZCBhZ3JlZWQgdXBvbi48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO0F0IHRoZSBS b3V0aW5nIEFyZWEgTWVldGluZyBpbiBUb3JvbnRvOiBEaXNjdXNzIHRoZSBzZXQgb2Y8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDtyZW9yZ2FuaXplZCBXR3MgYW5kIGdlbmVyYWwgY2hhcnRlciBjb250ZW50IGluIHRoZSBSb3V0 aW5nIEFyZWE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDttZWV0aW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7U2VwdGVtYmVyIDIwMTQ6IEJhc2Vk IHVwb24gdGhlIGZlZWRiYWNrLCBzdWdnZXN0aW9ucywgYW5kPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ZGlzY3Vzc2lvbiwg QWRyaWFuIGFuZCBJIGZpbmFsaXplIHRoZSByZW9yZ2FuaXplZCBXRyBjaGFydGVycy4gJm5ic3A7 V2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDtzdGFydCB0aGUgaW50ZXJuYWwgSUVTRyBkaXNjdXNzaW9uIGFuZCBwdWJsaWMg cmV2aWV3cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7ICZuYnNwO09jdG9iZXIgMjAxNDogRm9ybWFsIHJlY2hhcnRlcmluZyBwcm9j ZXNzIGNvbXBsZXRlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO0luIEhvbm9sdWx1OiBUaGUgbmV3IHNldCBvZiBXR3Mg bWVldC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwO0FmdGVyIEhvbm9sdWx1OiBBZHJpYW4gYW5kIEkgZGVhbCB3aXRoIGFu eSBpc3N1ZXMgYW5kIGNoYXJ0ZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt1cGRhdGVzIGJhc2VkIHVwb24gYSBmZXcgbW9u dGhzIG9mIGV4cGVyaWVuY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhlcmUgYXJlIHRoZSBtb3RpdmF0aW9ucyB0aGF0IEFkcmlhbiBhbmQg SSB3b3VsZCBsaWtlIHRvIGJlIGNvbnNpZGVyZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndoZW4gY29taW5nIHVwIHdpdGggaWRlYXMgZm9yIGhv dyB0aGUgV0dzIHNob3VsZCBiZSByZW9yZ2FuaXplZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzEpIE1vdmUgdG93YXJk cyBvcmdhbml6aW5nIHdvcmtpbmcgZ3JvdXBzIG9uIGZ1bmN0aW9uYWw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtyZXNwb25z aWJpbGl0aWVzIHJhdGhlciB0aGFuIHNjb3BpbmcgdGhlbSB0byBzcGVjaWZpYyBwcm90b2NvbHMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDsyKSBTcGxpdCBnaWFudCB3b3JraW5nIGdyb3VwcyBzbyByZWxldmFudCB3b3Jr IGlzIGRvbmUgaW4gb25lIHBsYWNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7YW5kIHRoZXJlIGlzIGFuIGltcHJvdmVkIHNp Z25hbC10by1ub2lzZSByYXRpbyBmb3IgcGFydGljaXBhbnRzIHdobzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2FyZSBvbmx5 IGludGVyZXN0ZWQgaW4gYSBzbGljZSBvZiB0aGUgY3VycmVudCB3b3JraW5nIGdyb3VwJ3Mgd29y ay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwOzMpIENyZWF0ZSBzeW5lcmdpZXMgZm9yIHNjYXR0ZXJlZCBmdW5jdGlvbmFs aXR5IChleGFtcGxlIGlkZWFzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO09BTSwgRlJSLCB0cmFmZmljLWVuZ2luZWVyaW5n KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7NCkgQ3JlYXRlIGEgRElTUEFUQ0ggd29ya2luZyBncm91cCBmb3IgY2xlYXIg bmV3IGlkZWEgZGlzY3Vzc2lvbjs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtydGd3ZyBzZXJ2ZXMgc29tZSBvZiB0aGlzIHB1 cnBvc2UgYnV0IGRvZXNuJ3QgaGF2ZSBhIGNsZWFyIHByb2Nlc3M8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDthbmQgaXNuJ3Qg ZHJhd2luZyBpbiB0aGUgbmV3IGlkZWFzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7NSkgRm9jdXMgUm91dGluZyBBcmVh IHRpbWUgb24gZGVzaWduIGNlbnRlcnMgcmF0aGVyIHRoYW4gb24gZmFyPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7Y29ybmVy IGNhc2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7NikgRWFjaCB3b3JraW5nIGdyb3VwIHNob3VsZCBoYXZlIGNsZWFy LCB3ZWxsIGRlZmluZWQsIGFuZCBhY2hpZXZhYmxlIGdvYWxzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3RpbmcgdGhhdCB0aGUgUm91dGlu ZyBBcmVhIGhhcyBpbmhlcml0ZWQgc29tZSBvZiBpdHMgV0cgc3RydWN0dXJlPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5mcm9tIHRoZSBzdWItSVAg YXJlYSwgaXQgaXMgbm90IGEgZ29hbCB0byBmb3JjZSBJUCByb3V0aW5nIGFuZCBNUExTPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yb3V0aW5nIHRv IHJlbWFpbiBzZXBhcmF0ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSBnb2FsIG9mIHRoaXMgcmVvcmdhbml6YXRpb24gaXMgbm90IGNs b3Npbmcgd29ya2luZyBncm91cHMuICZuYnNwO0FkcmlhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIEFsaWEgYXJlIHBlcmZlY3RseSBjYXBh YmxlIG9mIGNsb3Npbmcgd29ya2luZyBncm91cHMgd2l0aG91dCBnb2luZzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhyb3VnaCByZXN0cnVjdHVy aW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Gb3IgdGhvc2Ugb2YgeW91IHRoYXQgaGF2ZSByZWFkIHRoaXMgZmFyLCB0aGFuayB5b3UuICZu YnNwO0dldHRpbmcgdGhpcyA4MCU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnJpZ2h0IGlzIGdvaW5nIHRvIHRha2Ugc29tZSBzZXJpb3VzIGRpc2N1 c3Npb24gYW5kIHRob3VnaHQuICZuYnNwO1dlIGFsbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d29yayBpbiB0aGUgUm91dGluZyBBcmVhIHRvZ2V0 aGVyIHdpdGggZGlmZmVyZW50IHBlcnNwZWN0aXZlcy4gJm5ic3A7UGxlYXNlPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGluayBjYXJlZnVsbHkg YW5kIGhlbHAgdXMgaGF2ZSBhIGhpZ2hseSBmb2N1c2VkIGRpc2N1c3Npb24uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsaWEgYW5kIEFk cmlhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_CECE764681BE964CBE1DFF78F3CDD3941E1DF930xmbalnx01ciscoc_-- --_004_CECE764681BE964CBE1DFF78F3CDD3941E1DF930xmbalnx01ciscoc_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=169; creation-date="Tue, 10 Jun 2014 19:58:11 GMT"; modification-date="Tue, 10 Jun 2014 19:58:11 GMT" Content-ID: <3B1A797204D722488ABC38039AF99921@emea.cisco.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJvdXRpbmct ZGlzY3Vzc2lvbiBtYWlsaW5nIGxpc3QNCnJvdXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb3V0aW5nLWRpc2N1c3Npb24NCg== --_004_CECE764681BE964CBE1DFF78F3CDD3941E1DF930xmbalnx01ciscoc_-- From nobody Tue Jun 10 14:06:46 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C531A02EC for ; Tue, 10 Jun 2014 14:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -117.151 X-Spam-Level: X-Spam-Status: No, score=-117.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2hg4u3W6Jj2 for ; Tue, 10 Jun 2014 14:06:27 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68FDA1A02E3 for ; Tue, 10 Jun 2014 14:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29194; q=dns/txt; s=iport; t=1402434387; x=1403643987; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=/hsXwZGBgEsEBs0UbcIiKzPEr7bNJFSQPLFM8DSwgAg=; b=TnmAps+vM4FAXFhGdUDU7KbjAGgyEZ4yKRMVMM/1bLCp4u/5eY0dLI6/ h1mRteTmuDii+BGyoKHKZMENgnr1D2xk0LLXUvMTYKhmajz1Wyc7QHvHj eNYEXEQq+tyRUwxjuK0hsHewPr1lRAD1qmAr7Y+o/5lpSNQGf4r7yVpXx c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FACFyl1OtJA2L/2dsb2JhbABZgkYjJFJZgmy4CYkNARlxFnWEAwEBAQQjCkEbAgEIEQQBAQsWBwMCAgIwFAkIAgQTCBSIJgEMriWefxeNZjI3AQaCbzaBFgSVVIYSkgODPGyBQw X-IronPort-AV: E=Sophos;i="4.98,1011,1392163200"; d="scan'208,217";a="332108801" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP; 10 Jun 2014 21:06:26 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s5AL6QTg024396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Jun 2014 21:06:26 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 10 Jun 2014 16:06:26 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: RE: Improving and Restructuring the Routing Area Thread-Topic: Improving and Restructuring the Routing Area Thread-Index: AQHPhOZO5JEEQzlurUmV+y1ULT+bpptqx8YggAANtIA= Date: Tue, 10 Jun 2014 21:06:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.71] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941E1E0D68xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/kuS85MWPtO99GX6BXwmO8Odwggk X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 21:06:30 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941E1E0D68xmbalnx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90ZSB0aGF0IGRpc2N1c3Npb25zIHdpbGwgaGFwcGVuIG9uIHJvdXRpbmctZGlzY3Vzc2lvbkBp ZXRmLm9yZzxtYWlsdG86cm91dGluZy1kaXNjdXNzaW9uQGlldGYub3JnPiwgc28gZG8gam9pbiB0 aGUgbGlzdCBpZiB5b3Ugd2FudCB0byBwYXJ0aWNpcGF0ZS9tb25pdG9yIHRoZSBkaXNjdXNzaW9u cy4NCg0KLU5vYm8NCg0KRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIE5vYm8gQWtpeWEgKG5vYm8pDQpTZW50OiBUdWVzZGF5LCBKdW5l IDEwLCAyMDE0IDQ6MjIgUE0NClRvOiBydGctYmZkQGlldGYub3JnDQpTdWJqZWN0OiBGVzogSW1w cm92aW5nIGFuZCBSZXN0cnVjdHVyaW5nIHRoZSBSb3V0aW5nIEFyZWENCg0KSGkgQkZEZXJzLA0K DQpJbiBjYXNlIHNvbWUgb2YgeW91IGFyZSBub3Qgb24gdGhlIHJvdXRpbmctZGlzY3Vzc2lvbiBt YWlsaW5nIGxpc3QsIGZvcndhcmRpbmcgYW4gaW1wb3J0YW50IG1lc3NhZ2UgKGFuZCBpbnZpdGF0 aW9uIGZvciBkaXNjdXNzaW9ucykgZnJvbSBvdXIgQURzIOKApg0KDQotTm9ibw0KDQpGcm9tOiBy b3V0aW5nLWRpc2N1c3Npb24gW21haWx0bzpyb3V0aW5nLWRpc2N1c3Npb24tYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEFsaWEgQXRsYXMNClNlbnQ6IFR1ZXNkYXksIEp1bmUgMTAsIDIw MTQgMzo1OCBQTQ0KVG86IHJvdXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZw0KU3ViamVjdDogSW1w cm92aW5nIGFuZCBSZXN0cnVjdHVyaW5nIHRoZSBSb3V0aW5nIEFyZWENCg0KVG8gYWxsIHBhcnRp Y2lwYW50cyBpbiB0aGUgUm91dGluZyBBcmVhLA0KDQpBZHJpYW4gYW5kIEkgYXJlIHdvcmtpbmcg b24gaW1wcm92aW5nIHRoZSBxdWFsaXR5LCBzcGVlZCwgYW5kDQpleHBlcmllbmNlIG9mIGdldHRp bmcgd29yayBkb25lIGluIHRoZSBJRVRGIFJvdXRpbmcgQXJlYS4gIFRoZXJlIGFyZQ0KdGhyZWUg aW5pdGlhdGl2ZXMgdGhhdCB3ZSBhcmUgd29ya2luZzogV0cgRHJhZnQgUUEsIFJvdXRpbmcgQXJl YQ0Kc3BlY2lmaWMgV0cgY2hhaXIgdHJhaW5pbmcsIGFuZCByZW9yZ2FuaXppbmcgdGhlIHdvcmtp bmcgZ3JvdXBzIGluIHRoZQ0KYXJlYS4NCg0KRmlyc3QsIHdlIGludGVuZCB0byB1c2Ugb3VyIFJv dXRpbmcgRGlyZWN0b3JhdGUgbW9yZSBwcm9hY3RpdmVseSBieQ0KaW50cm9kdWNpbmcgYSBXb3Jr aW5nIEdyb3VwIERyYWZ0IFF1YWxpdHkgQXNzdXJhbmNlIChXRyBEcmFmdCBRQSkNCnByb2Nlc3Mg d2hlcmUgdGhlIHNhbWUgc2VsZWN0ZWQgcm91dGluZyBkaXJlY3RvcmF0ZSBtZW1iZXIgd2lsbCBy ZXZpZXcNCmEgZHJhZnQgZHVyaW5nIFdHIGRyYWZ0IGFkb3B0aW9uIGFuZCBkdXJpbmcgV0cgbGFz dCBjYWxsLiAgVGhlIHByb2Nlc3MNCndpbGwgYmUgZG9jdW1lbnRlZCBvbiB0aGUgUm91dGluZyBB cmVhIHdpa2kNCihodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kp LiAgVGhpcyBzaG91bGQgYWxsb3cNCmRpcmVjdG9yYXRlIHJldmlld3MgdG8gcmVwb3J0IHRlY2hu aWNhbCBpc3N1ZXMgdGhhdCBjYW4gYWN0dWFsbHkgZ2V0DQpmaXhlZCBlYXJseSBpbiB0aGUgcHJv Y2VzcyAoZXF1aXZhbGVudCBvZiBidWcgcmVwb3J0cykgYXMgb3Bwb3NlZCB0bw0KanVzdCBub3Rp bmcgdGhlIGNvbmNlcm5zIGluIHRoZSBkcmFmdHMgKGVxdWl2YWxlbnQgb2YgcmVsZWFzZSBub3Rl cykuDQoNClNlY29uZCwgYXMgd2FzIGRpc2N1c3NlZCBkdXJpbmcgdGhlIHJlY2VudCBJRVNHIHJl dHJlYXQsIGluIGFkZGl0aW9uDQp0byB0aGUgSUVURi13aWRlIFdHIGNoYWlyIHRyYWluaW5nLCB3 ZSBpbnRlbmQgdG8gaGF2ZSBhIHNlcmllcyBvZg0KdHJhaW5pbmcgc2Vzc2lvbnMgZm9yIFdHIENo YWlycyBpbiB0aGUgUm91dGluZyBBcmVhIGFkZHJlc3NpbmcgdG9waWNzDQpzdWNoIGFzIGp1ZGdp bmcgY29uc2Vuc3VzLCBwcm9qZWN0IG1hbmFnZW1lbnQsIG1vdGl2YXRpbmcgdm9sdW50ZWVycywN CnVzaW5nIHRoZSBkYXRhdHJhY2tlciAodmlhIGEgc2FuZGJveCB2ZXJzaW9uIHRoYXQgY2FuIGJl IHBsYXllZA0Kd2l0aCBzYWZlbHkpLCBhbmQgc2hhcmluZyBleHBlcmllbmNlcyBiZXR3ZWVuIFdH IGNoYWlycy4NCg0KVGhpcmQsIHdlIGludGVuZCB0byByZW9yZ2FuaXplIHRoZSB3b3JraW5nIGdy b3VwcyBpbiB0aGUgUm91dGluZyBhcmVhLg0KV2UgZmVlbCB0aGF0IGl0IGlzIGltcG9ydGFudCB0 byBmb2N1cyBvbiBhcmVhcyB3aGVyZSB0aGVyZSBpcyBhY3RpdmUNCmludGVyZXN0IGluIHN0YW5k YXJkaXphdGlvbiBhbmQgdG8gYmUgb3BlbiBhbmQgYWJsZSB0byBhY2NlcHQgbmV3IHdvcmsNCmlu dG8gdGhlIGFyZWEuICBBcyB5b3Uga25vdywgd2UgaGF2ZSBoYWQgc2V2ZXJhbCBuZXcgd29ya2lu ZyBncm91cHMNCihudm8zLCBpMnJzLCBzZmMsIHNwcmluZykgY3JlYXRlZCBpbiB0aGUgbGFzdCBm ZXcgeWVhcnMgYW5kIHdlIG5lZWQgdG8NCmJlIG9wZW4gYW5kIGFibGUgdG8gaGFuZGxlIG1vcmUg bmV3IHdvcmsgYXMgaXQgY29tZXMgaW4uICBXZSB3b3VsZA0KYWxzbyBsaWtlIHRvIGltcHJvdmUg dGhlIHNpZ25hbC10by1ub2lzZSByYXRpbyBleHBlcmllbmNlZCBieQ0KcGFydGljaXBhbnRzIGlu IHRoZSBkaWZmZXJlbnQgd29ya2luZyBncm91cHMgYW5kIGltcHJvdmUgdGhlIHF1YW50aXR5DQph bmQgcXVhbGl0eSBvZiBkaXNjdXNzaW9uIGFuZCByZXZpZXdzLiAgSXQgaXMgbGlrZWx5IHRoYXQg bm90IGFsbCBXR3MNCmluIHRoZSBSb3V0aW5nIEFyZWEgd2lsbCBiZSBkaXJlY3RseSBhZmZlY3Rl ZC4NCg0KSGVyZSBpcyB0aGUgdGltZS1saW5lIGZvciByZW9yZ2FuaXppbmcgdGhlIFdHcy4NCg0K ICAgTk9XOiBwdWJsaWMgZGlzY3Vzc2lvbiBvbiByb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmc8 bWFpbHRvOnJvdXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZz4gYWJvdXQgaG93IHRvDQogICByZW9y Z2FuaXplIHRoZSB3b3JraW5nIGdyb3VwcyB0byBiZXN0IG1lZXQgb3VyIG1vdGl2YXRpb25zLg0K ICAgQWRkaXRpb25hbCBmb2N1c2VkIGRpc2N1c3Npb25zIGFyZSBleHBlY3RlZCBvbiB0aGUNCiAg IHJ0Zy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1jaGFpcnNAaWV0Zi5vcmc+IGFuZCBydGct ZGlyQGlldGYub3JnPG1haWx0bzpydGctZGlyQGlldGYub3JnPiBtYWlsaW5nIGxpc3RzLg0KDQog ICBJbiBUb3JvbnRvOiBUaGVyZSB3aWxsIGJlIG1lZXRpbmdzIHdpdGggdGhlIFdHIGNoYWlycyBh bmQgdGhlDQogICBSb3V0aW5nIERpcmVjdG9yYXRlIHRvIGdldCB0aGUgaWRlYXMgZGVzY3JpYmVk IGFuZCBhZ3JlZWQgdXBvbi4NCg0KICAgQXQgdGhlIFJvdXRpbmcgQXJlYSBNZWV0aW5nIGluIFRv cm9udG86IERpc2N1c3MgdGhlIHNldCBvZg0KICAgcmVvcmdhbml6ZWQgV0dzIGFuZCBnZW5lcmFs IGNoYXJ0ZXIgY29udGVudCBpbiB0aGUgUm91dGluZyBBcmVhDQogICBtZWV0aW5nLg0KDQogICBT ZXB0ZW1iZXIgMjAxNDogQmFzZWQgdXBvbiB0aGUgZmVlZGJhY2ssIHN1Z2dlc3Rpb25zLCBhbmQN CiAgIGRpc2N1c3Npb24sIEFkcmlhbiBhbmQgSSBmaW5hbGl6ZSB0aGUgcmVvcmdhbml6ZWQgV0cg Y2hhcnRlcnMuICBXZQ0KICAgc3RhcnQgdGhlIGludGVybmFsIElFU0cgZGlzY3Vzc2lvbiBhbmQg cHVibGljIHJldmlld3MuDQoNCiAgIE9jdG9iZXIgMjAxNDogRm9ybWFsIHJlY2hhcnRlcmluZyBw cm9jZXNzIGNvbXBsZXRlcy4NCg0KICAgSW4gSG9ub2x1bHU6IFRoZSBuZXcgc2V0IG9mIFdHcyBt ZWV0Lg0KDQogICBBZnRlciBIb25vbHVsdTogQWRyaWFuIGFuZCBJIGRlYWwgd2l0aCBhbnkgaXNz dWVzIGFuZCBjaGFydGVyDQogICB1cGRhdGVzIGJhc2VkIHVwb24gYSBmZXcgbW9udGhzIG9mIGV4 cGVyaWVuY2UuDQoNCkhlcmUgYXJlIHRoZSBtb3RpdmF0aW9ucyB0aGF0IEFkcmlhbiBhbmQgSSB3 b3VsZCBsaWtlIHRvIGJlIGNvbnNpZGVyZWQNCndoZW4gY29taW5nIHVwIHdpdGggaWRlYXMgZm9y IGhvdyB0aGUgV0dzIHNob3VsZCBiZSByZW9yZ2FuaXplZC4NCg0KICAgMSkgTW92ZSB0b3dhcmRz IG9yZ2FuaXppbmcgd29ya2luZyBncm91cHMgb24gZnVuY3Rpb25hbA0KICAgcmVzcG9uc2liaWxp dGllcyByYXRoZXIgdGhhbiBzY29waW5nIHRoZW0gdG8gc3BlY2lmaWMgcHJvdG9jb2xzLg0KDQog ICAyKSBTcGxpdCBnaWFudCB3b3JraW5nIGdyb3VwcyBzbyByZWxldmFudCB3b3JrIGlzIGRvbmUg aW4gb25lIHBsYWNlDQogICBhbmQgdGhlcmUgaXMgYW4gaW1wcm92ZWQgc2lnbmFsLXRvLW5vaXNl IHJhdGlvIGZvciBwYXJ0aWNpcGFudHMgd2hvDQogICBhcmUgb25seSBpbnRlcmVzdGVkIGluIGEg c2xpY2Ugb2YgdGhlIGN1cnJlbnQgd29ya2luZyBncm91cCdzIHdvcmsuDQoNCiAgIDMpIENyZWF0 ZSBzeW5lcmdpZXMgZm9yIHNjYXR0ZXJlZCBmdW5jdGlvbmFsaXR5IChleGFtcGxlIGlkZWFzOg0K ICAgT0FNLCBGUlIsIHRyYWZmaWMtZW5naW5lZXJpbmcpDQoNCiAgIDQpIENyZWF0ZSBhIERJU1BB VENIIHdvcmtpbmcgZ3JvdXAgZm9yIGNsZWFyIG5ldyBpZGVhIGRpc2N1c3Npb247DQogICBydGd3 ZyBzZXJ2ZXMgc29tZSBvZiB0aGlzIHB1cnBvc2UgYnV0IGRvZXNuJ3QgaGF2ZSBhIGNsZWFyIHBy b2Nlc3MNCiAgIGFuZCBpc24ndCBkcmF3aW5nIGluIHRoZSBuZXcgaWRlYXMuDQoNCiAgIDUpIEZv Y3VzIFJvdXRpbmcgQXJlYSB0aW1lIG9uIGRlc2lnbiBjZW50ZXJzIHJhdGhlciB0aGFuIG9uIGZh cg0KICAgY29ybmVyIGNhc2VzLg0KDQogICA2KSBFYWNoIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGhh dmUgY2xlYXIsIHdlbGwgZGVmaW5lZCwgYW5kIGFjaGlldmFibGUgZ29hbHMuDQoNCk5vdGluZyB0 aGF0IHRoZSBSb3V0aW5nIEFyZWEgaGFzIGluaGVyaXRlZCBzb21lIG9mIGl0cyBXRyBzdHJ1Y3R1 cmUNCmZyb20gdGhlIHN1Yi1JUCBhcmVhLCBpdCBpcyBub3QgYSBnb2FsIHRvIGZvcmNlIElQIHJv dXRpbmcgYW5kIE1QTFMNCnJvdXRpbmcgdG8gcmVtYWluIHNlcGFyYXRlZC4NCg0KVGhlIGdvYWwg b2YgdGhpcyByZW9yZ2FuaXphdGlvbiBpcyBub3QgY2xvc2luZyB3b3JraW5nIGdyb3Vwcy4gIEFk cmlhbg0KYW5kIEFsaWEgYXJlIHBlcmZlY3RseSBjYXBhYmxlIG9mIGNsb3Npbmcgd29ya2luZyBn cm91cHMgd2l0aG91dCBnb2luZw0KdGhyb3VnaCByZXN0cnVjdHVyaW5nLg0KDQpGb3IgdGhvc2Ug b2YgeW91IHRoYXQgaGF2ZSByZWFkIHRoaXMgZmFyLCB0aGFuayB5b3UuICBHZXR0aW5nIHRoaXMg ODAlDQpyaWdodCBpcyBnb2luZyB0byB0YWtlIHNvbWUgc2VyaW91cyBkaXNjdXNzaW9uIGFuZCB0 aG91Z2h0LiAgV2UgYWxsDQp3b3JrIGluIHRoZSBSb3V0aW5nIEFyZWEgdG9nZXRoZXIgd2l0aCBk aWZmZXJlbnQgcGVyc3BlY3RpdmVzLiAgUGxlYXNlDQp0aGluayBjYXJlZnVsbHkgYW5kIGhlbHAg dXMgaGF2ZSBhIGhpZ2hseSBmb2N1c2VkIGRpc2N1c3Npb24uDQoNClRoYW5rcywNCkFsaWEgYW5k IEFkcmlhbg0KDQo= --_000_CECE764681BE964CBE1DFF78F3CDD3941E1E0D68xmbalnx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUNBIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Tm90ZSB0aGF0IGRpc2N1c3Npb25zIHdpbGwgaGFwcGVuIG9uDQo8YSBocmVmPSJtYWls dG86cm91dGluZy1kaXNjdXNzaW9uQGlldGYub3JnIj5yb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5v cmc8L2E+LCBzbyBkbyBqb2luIHRoZSBsaXN0IGlmIHlvdSB3YW50IHRvIHBhcnRpY2lwYXRlL21v bml0b3IgdGhlIGRpc2N1c3Npb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LU5vYm88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSdGct YmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5Ob2JvIEFraXlhIChub2JvKTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDEwLCAy MDE0IDQ6MjIgUE08YnI+DQo8Yj5Ubzo8L2I+IHJ0Zy1iZmRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gRlc6IEltcHJvdmluZyBhbmQgUmVzdHJ1Y3R1cmluZyB0aGUgUm91dGluZyBBcmVh PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEJGRGVycyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklu IGNhc2Ugc29tZSBvZiB5b3UgYXJlIG5vdCBvbiB0aGUgcm91dGluZy1kaXNjdXNzaW9uIG1haWxp bmcgbGlzdCwgZm9yd2FyZGluZyBhbiBpbXBvcnRhbnQgbWVzc2FnZSAoYW5kIGludml0YXRpb24g Zm9yIGRpc2N1c3Npb25zKSBmcm9tIG91ciBBRHMg4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tTm9ibzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IHJvdXRpbmctZGlzY3Vzc2lvbiBbbWFpbHRvOnJvdXRpbmctZGlzY3Vzc2lvbi1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbGlhIEF0bGFzPGJyPg0KPGI+U2Vu dDo8L2I+IFR1ZXNkYXksIEp1bmUgMTAsIDIwMTQgMzo1OCBQTTxicj4NCjxiPlRvOjwvYj4gcm91 dGluZy1kaXNjdXNzaW9uQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IEltcHJvdmluZyBh bmQgUmVzdHJ1Y3R1cmluZyB0aGUgUm91dGluZyBBcmVhPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBhbGwgcGFydGljaXBhbnRz IGluIHRoZSBSb3V0aW5nIEFyZWEsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFkcmlhbiBhbmQgSSBhcmUgd29ya2luZyBvbiBpbXByb3Zpbmcg dGhlIHF1YWxpdHksIHNwZWVkLCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmV4cGVyaWVuY2Ugb2YgZ2V0dGluZyB3b3JrIGRvbmUgaW4gdGhl IElFVEYgUm91dGluZyBBcmVhLiAmbmJzcDtUaGVyZSBhcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRocmVlIGluaXRpYXRpdmVzIHRoYXQgd2Ug YXJlIHdvcmtpbmc6IFdHIERyYWZ0IFFBLCBSb3V0aW5nIEFyZWE8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNwZWNpZmljIFdHIGNoYWlyIHRyYWlu aW5nLCBhbmQgcmVvcmdhbml6aW5nIHRoZSB3b3JraW5nIGdyb3VwcyBpbiB0aGU8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFyZWEuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZpcnN0LCB3ZSBp bnRlbmQgdG8gdXNlIG91ciBSb3V0aW5nIERpcmVjdG9yYXRlIG1vcmUgcHJvYWN0aXZlbHkgYnk8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmludHJv ZHVjaW5nIGEgV29ya2luZyBHcm91cCBEcmFmdCBRdWFsaXR5IEFzc3VyYW5jZSAoV0cgRHJhZnQg UUEpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5w cm9jZXNzIHdoZXJlIHRoZSBzYW1lIHNlbGVjdGVkIHJvdXRpbmcgZGlyZWN0b3JhdGUgbWVtYmVy IHdpbGwgcmV2aWV3PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5hIGRyYWZ0IGR1cmluZyBXRyBkcmFmdCBhZG9wdGlvbiBhbmQgZHVyaW5nIFdHIGxh c3QgY2FsbC4gJm5ic3A7VGhlIHByb2Nlc3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPndpbGwgYmUgZG9jdW1lbnRlZCBvbiB0aGUgUm91dGluZyBB cmVhIHdpa2k8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPig8YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dp a2kiPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraTwvYT4pLiAm bmJzcDtUaGlzIHNob3VsZCBhbGxvdzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+ZGlyZWN0b3JhdGUgcmV2aWV3cyB0byByZXBvcnQgdGVjaG5pY2Fs IGlzc3VlcyB0aGF0IGNhbiBhY3R1YWxseSBnZXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZpeGVkIGVhcmx5IGluIHRoZSBwcm9jZXNzIChlcXVp dmFsZW50IG9mIGJ1ZyByZXBvcnRzKSBhcyBvcHBvc2VkIHRvPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5qdXN0IG5vdGluZyB0aGUgY29uY2VybnMg aW4gdGhlIGRyYWZ0cyAoZXF1aXZhbGVudCBvZiByZWxlYXNlIG5vdGVzKS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2Vjb25kLCBhcyB3YXMg ZGlzY3Vzc2VkIGR1cmluZyB0aGUgcmVjZW50IElFU0cgcmV0cmVhdCwgaW4gYWRkaXRpb248bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvIHRoZSBJ RVRGLXdpZGUgV0cgY2hhaXIgdHJhaW5pbmcsIHdlIGludGVuZCB0byBoYXZlIGEgc2VyaWVzIG9m PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50cmFp bmluZyBzZXNzaW9ucyBmb3IgV0cgQ2hhaXJzIGluIHRoZSBSb3V0aW5nIEFyZWEgYWRkcmVzc2lu ZyB0b3BpY3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPnN1Y2ggYXMganVkZ2luZyBjb25zZW5zdXMsIHByb2plY3QgbWFuYWdlbWVudCwgbW90aXZh dGluZyB2b2x1bnRlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+dXNpbmcgdGhlIGRhdGF0cmFja2VyICh2aWEgYSBzYW5kYm94IHZlcnNpb24g dGhhdCBjYW4gYmUgcGxheWVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj53aXRoIHNhZmVseSksIGFuZCBzaGFyaW5nIGV4cGVyaWVuY2VzIGJldHdl ZW4gV0cgY2hhaXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGlyZCwgd2UgaW50ZW5kIHRvIHJlb3JnYW5pemUgdGhlIHdvcmtpbmcgZ3Jv dXBzIGluIHRoZSBSb3V0aW5nIGFyZWEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBmZWVsIHRoYXQgaXQgaXMgaW1wb3J0YW50IHRvIGZvY3Vz IG9uIGFyZWFzIHdoZXJlIHRoZXJlIGlzIGFjdGl2ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW50ZXJlc3QgaW4gc3RhbmRhcmRpemF0aW9uIGFu ZCB0byBiZSBvcGVuIGFuZCBhYmxlIHRvIGFjY2VwdCBuZXcgd29yazxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW50byB0aGUgYXJlYS4gJm5ic3A7 QXMgeW91IGtub3csIHdlIGhhdmUgaGFkIHNldmVyYWwgbmV3IHdvcmtpbmcgZ3JvdXBzPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4obnZvMywgaTJy cywgc2ZjLCBzcHJpbmcpIGNyZWF0ZWQgaW4gdGhlIGxhc3QgZmV3IHllYXJzIGFuZCB3ZSBuZWVk IHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5i ZSBvcGVuIGFuZCBhYmxlIHRvIGhhbmRsZSBtb3JlIG5ldyB3b3JrIGFzIGl0IGNvbWVzIGluLiAm bmJzcDtXZSB3b3VsZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+YWxzbyBsaWtlIHRvIGltcHJvdmUgdGhlIHNpZ25hbC10by1ub2lzZSByYXRpbyBl eHBlcmllbmNlZCBieTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+cGFydGljaXBhbnRzIGluIHRoZSBkaWZmZXJlbnQgd29ya2luZyBncm91cHMgYW5k IGltcHJvdmUgdGhlIHF1YW50aXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5hbmQgcXVhbGl0eSBvZiBkaXNjdXNzaW9uIGFuZCByZXZpZXdzLiAm bmJzcDtJdCBpcyBsaWtlbHkgdGhhdCBub3QgYWxsIFdHczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW4gdGhlIFJvdXRpbmcgQXJlYSB3aWxsIGJl IGRpcmVjdGx5IGFmZmVjdGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IZXJlIGlzIHRoZSB0aW1lLWxpbmUgZm9yIHJlb3JnYW5pemluZyB0 aGUgV0dzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7Tk9XOiBwdWJsaWMgZGlzY3Vzc2lvbiBvbiA8YSBocmVmPSJtYWls dG86cm91dGluZy1kaXNjdXNzaW9uQGlldGYub3JnIj4NCnJvdXRpbmctZGlzY3Vzc2lvbkBpZXRm Lm9yZzwvYT4gYWJvdXQgaG93IHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7cmVvcmdhbml6ZSB0aGUgd29ya2luZyBncm91 cHMgdG8gYmVzdCBtZWV0IG91ciBtb3RpdmF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtBZGRpdGlvbmFsIGZvY3Vz ZWQgZGlzY3Vzc2lvbnMgYXJlIGV4cGVjdGVkIG9uIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Im1haWx0 bzpydGctY2hhaXJzQGlldGYub3JnIj5ydGctY2hhaXJzQGlldGYub3JnPC9hPiBhbmQNCjxhIGhy ZWY9Im1haWx0bzpydGctZGlyQGlldGYub3JnIj5ydGctZGlyQGlldGYub3JnPC9hPiBtYWlsaW5n IGxpc3RzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7SW4gVG9yb250bzogVGhlcmUgd2lsbCBiZSBtZWV0aW5ncyB3aXRo IHRoZSBXRyBjaGFpcnMgYW5kIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO1JvdXRpbmcgRGlyZWN0b3JhdGUgdG8gZ2V0 IHRoZSBpZGVhcyBkZXNjcmliZWQgYW5kIGFncmVlZCB1cG9uLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7QXQgdGhlIFJv dXRpbmcgQXJlYSBNZWV0aW5nIGluIFRvcm9udG86IERpc2N1c3MgdGhlIHNldCBvZjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw O3Jlb3JnYW5pemVkIFdHcyBhbmQgZ2VuZXJhbCBjaGFydGVyIGNvbnRlbnQgaW4gdGhlIFJvdXRp bmcgQXJlYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwO21lZXRpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtTZXB0ZW1iZXIgMjAxNDogQmFzZWQg dXBvbiB0aGUgZmVlZGJhY2ssIHN1Z2dlc3Rpb25zLCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtkaXNjdXNzaW9uLCBB ZHJpYW4gYW5kIEkgZmluYWxpemUgdGhlIHJlb3JnYW5pemVkIFdHIGNoYXJ0ZXJzLiAmbmJzcDtX ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7ICZuYnNwO3N0YXJ0IHRoZSBpbnRlcm5hbCBJRVNHIGRpc2N1c3Npb24gYW5kIHB1YmxpYyBy ZXZpZXdzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7T2N0b2JlciAyMDE0OiBGb3JtYWwgcmVjaGFydGVyaW5nIHByb2Nl c3MgY29tcGxldGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7SW4gSG9ub2x1bHU6IFRoZSBuZXcgc2V0IG9mIFdHcyBt ZWV0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7QWZ0ZXIgSG9ub2x1bHU6IEFkcmlhbiBhbmQgSSBkZWFsIHdpdGggYW55 IGlzc3VlcyBhbmQgY2hhcnRlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3VwZGF0ZXMgYmFzZWQgdXBvbiBhIGZldyBtb250 aHMgb2YgZXhwZXJpZW5jZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SGVyZSBhcmUgdGhlIG1vdGl2YXRpb25zIHRoYXQgQWRyaWFuIGFuZCBJ IHdvdWxkIGxpa2UgdG8gYmUgY29uc2lkZXJlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hlbiBjb21pbmcgdXAgd2l0aCBpZGVhcyBmb3IgaG93 IHRoZSBXR3Mgc2hvdWxkIGJlIHJlb3JnYW5pemVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7MSkgTW92ZSB0b3dhcmRz IG9yZ2FuaXppbmcgd29ya2luZyBncm91cHMgb24gZnVuY3Rpb25hbDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3Jlc3BvbnNp YmlsaXRpZXMgcmF0aGVyIHRoYW4gc2NvcGluZyB0aGVtIHRvIHNwZWNpZmljIHByb3RvY29scy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7ICZuYnNwOzIpIFNwbGl0IGdpYW50IHdvcmtpbmcgZ3JvdXBzIHNvIHJlbGV2YW50IHdvcmsg aXMgZG9uZSBpbiBvbmUgcGxhY2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDthbmQgdGhlcmUgaXMgYW4gaW1wcm92ZWQgc2ln bmFsLXRvLW5vaXNlIHJhdGlvIGZvciBwYXJ0aWNpcGFudHMgd2hvPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7YXJlIG9ubHkg aW50ZXJlc3RlZCBpbiBhIHNsaWNlIG9mIHRoZSBjdXJyZW50IHdvcmtpbmcgZ3JvdXAncyB3b3Jr LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7MykgQ3JlYXRlIHN5bmVyZ2llcyBmb3Igc2NhdHRlcmVkIGZ1bmN0aW9uYWxp dHkgKGV4YW1wbGUgaWRlYXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7T0FNLCBGUlIsIHRyYWZmaWMtZW5naW5lZXJpbmcp PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDs0KSBDcmVhdGUgYSBESVNQQVRDSCB3b3JraW5nIGdyb3VwIGZvciBjbGVhciBu ZXcgaWRlYSBkaXNjdXNzaW9uOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3J0Z3dnIHNlcnZlcyBzb21lIG9mIHRoaXMgcHVy cG9zZSBidXQgZG9lc24ndCBoYXZlIGEgY2xlYXIgcHJvY2VzczxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2FuZCBpc24ndCBk cmF3aW5nIGluIHRoZSBuZXcgaWRlYXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDs1KSBGb2N1cyBSb3V0aW5nIEFyZWEg dGltZSBvbiBkZXNpZ24gY2VudGVycyByYXRoZXIgdGhhbiBvbiBmYXI8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtjb3JuZXIg Y2FzZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDs2KSBFYWNoIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGhhdmUgY2xlYXIs IHdlbGwgZGVmaW5lZCwgYW5kIGFjaGlldmFibGUgZ29hbHMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGluZyB0aGF0IHRoZSBSb3V0aW5n IEFyZWEgaGFzIGluaGVyaXRlZCBzb21lIG9mIGl0cyBXRyBzdHJ1Y3R1cmU8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZyb20gdGhlIHN1Yi1JUCBh cmVhLCBpdCBpcyBub3QgYSBnb2FsIHRvIGZvcmNlIElQIHJvdXRpbmcgYW5kIE1QTFM8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJvdXRpbmcgdG8g cmVtYWluIHNlcGFyYXRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIGdvYWwgb2YgdGhpcyByZW9yZ2FuaXphdGlvbiBpcyBub3QgY2xv c2luZyB3b3JraW5nIGdyb3Vwcy4gJm5ic3A7QWRyaWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQgQWxpYSBhcmUgcGVyZmVjdGx5IGNhcGFi bGUgb2YgY2xvc2luZyB3b3JraW5nIGdyb3VwcyB3aXRob3V0IGdvaW5nPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aHJvdWdoIHJlc3RydWN0dXJp bmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkZvciB0aG9zZSBvZiB5b3UgdGhhdCBoYXZlIHJlYWQgdGhpcyBmYXIsIHRoYW5rIHlvdS4gJm5i c3A7R2V0dGluZyB0aGlzIDgwJTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+cmlnaHQgaXMgZ29pbmcgdG8gdGFrZSBzb21lIHNlcmlvdXMgZGlzY3Vz c2lvbiBhbmQgdGhvdWdodC4gJm5ic3A7V2UgYWxsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53b3JrIGluIHRoZSBSb3V0aW5nIEFyZWEgdG9nZXRo ZXIgd2l0aCBkaWZmZXJlbnQgcGVyc3BlY3RpdmVzLiAmbmJzcDtQbGVhc2U8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoaW5rIGNhcmVmdWxseSBh bmQgaGVscCB1cyBoYXZlIGEgaGlnaGx5IGZvY3VzZWQgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxpYSBhbmQgQWRy aWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CECE764681BE964CBE1DFF78F3CDD3941E1E0D68xmbalnx01ciscoc_-- From nobody Wed Jun 11 08:47:46 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEC71A00E5; Wed, 11 Jun 2014 08:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwWqLkWG6ZLM; Wed, 11 Jun 2014 08:47:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E79EC1A0278; Wed, 11 Jun 2014 08:47:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-intervals-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140611154735.6320.33736.idtracker@ietfa.amsl.com> Date: Wed, 11 Jun 2014 08:47:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/D7BCei6y4e-qMsp5xtYsz0BOfYI Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 15:47:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Common Interval Support in BFD Authors : Nobo Akiya Marc Binderberger Greg Mirsky Filename : draft-ietf-bfd-intervals-01.txt Pages : 8 Date : 2014-06-11 Abstract: Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common interval value to run BFD sessions. This document defines a small set of interval values for BFD that we call "Common intervals", and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common intervals. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-intervals-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 11 09:10:15 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DC71A01AB for ; Wed, 11 Jun 2014 09:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zp0UEVQcuNCh for ; Wed, 11 Jun 2014 09:10:00 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9131A01A5 for ; Wed, 11 Jun 2014 09:09:59 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id F3DD02AA0F; Wed, 11 Jun 2014 16:09:56 +0000 (GMT) Date: Wed, 11 Jun 2014 09:09:56 -0700 From: Marc Binderberger To: "rtg-bfd@ietf.org" Message-ID: <20140611090956037602.d9c15051@sniff.de> In-Reply-To: <20140611154735.6320.33736.idtracker@ietfa.amsl.com> References: <20140611154735.6320.33736.idtracker@ietfa.amsl.com> Subject: New draft version (was: I-D Action: draft-ietf-bfd-intervals-01.txt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/gqX51hRB0g86ugmpOAAcx500-wk X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2014 16:10:03 -0000 Hello BFD experts, we have uploaded a new version of our draft draft-ietf-bfd-intervals-01. As you can see from the diff the changes are mainly a cleanup: * typo found/fixed * changed a MUST to SHOULD as this is an informal draft. * removed appendix C, which was kind of a to-do list. * realized in appendix B that in the last negotiation steps "B" does not need to send 1sec in the control packets. Instead 300msec is fine and also more aligned to the current behaviour described in RFC5880. In essence you don't start a new Poll sequence when the negotiated interval Max(remote, local) can be supported by your implementation. As usual: feedback is welcome! Thanks & Regards, Marc On Wed, 11 Jun 2014 08:47:35 -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Bidirectional Forwarding Detection > Working Group of the IETF. > > Title : Common Interval Support in BFD > Authors : Nobo Akiya > Marc Binderberger > Greg Mirsky > Filename : draft-ietf-bfd-intervals-01.txt > Pages : 8 > Date : 2014-06-11 > > Abstract: > Some BFD implementations may be restricted to only support several > interval values. When such BFD implementations speak to each other, > there is a possibility of two sides not being able to find a common > interval value to run BFD sessions. > > This document defines a small set of interval values for BFD that we > call "Common intervals", and recommends implementations to support > the defined intervals. This solves the problem of finding an > interval value that both BFD speakers can support while allowing a > simplified implementation as seen for hardware-based BFD. It does > not restrict an implementation from supporting more intervals in > addition to the Common intervals. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-intervals-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Wed Jun 11 09:40:45 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626A71A017F for ; Wed, 11 Jun 2014 09:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpAwdLCXsU9U for ; Wed, 11 Jun 2014 09:40:41 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 57B221A016C for ; Wed, 11 Jun 2014 09:40:41 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E4E6CC48F; Wed, 11 Jun 2014 12:40:40 -0400 (EDT) Date: Wed, 11 Jun 2014 12:40:40 -0400 From: Jeffrey Haas To: Marc Binderberger Subject: Re: New draft version (was: I-D Action: draft-ietf-bfd-intervals-01.txt) Message-ID: <20140611164040.GF6784@pfrc> References: <20140611154735.6320.33736.idtracker@ietfa.amsl.com> <20140611090956037602.d9c15051@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140611090956037602.d9c15051@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/CJtZ5-IXXUGQ6dMyWBekCcPHfhU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2014 16:40:42 -0000 Working Group, This document is relatively stable. At least a few vendors have reviewed it to find out whether their implementations currently support the suggested intervals. We're likely to want to last call this document in the near future. It would greatly help this effort if you have an implementation of BFD to review this document and see which of the intervals your implementation may cover. -- Jeff On Wed, Jun 11, 2014 at 09:09:56AM -0700, Marc Binderberger wrote: > Hello BFD experts, > > we have uploaded a new version of our draft draft-ietf-bfd-intervals-01. As > you can see from the diff the changes are mainly a cleanup: > > * typo found/fixed > > * changed a MUST to SHOULD as this is an informal draft. > > * removed appendix C, which was kind of a to-do list. > > * realized in appendix B that in the last negotiation steps "B" does not need > to send 1sec in the control packets. Instead 300msec is fine and also more > aligned to the current behaviour described in RFC5880. In essence you don't > start a new Poll sequence when the negotiated interval Max(remote, local) can > be supported by your implementation. > > > As usual: feedback is welcome! > > > Thanks & Regards, > Marc > > > > On Wed, 11 Jun 2014 08:47:35 -0700, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Bidirectional Forwarding Detection > > Working Group of the IETF. > > > > Title : Common Interval Support in BFD > > Authors : Nobo Akiya > > Marc Binderberger > > Greg Mirsky > > Filename : draft-ietf-bfd-intervals-01.txt > > Pages : 8 > > Date : 2014-06-11 > > > > Abstract: > > Some BFD implementations may be restricted to only support several > > interval values. When such BFD implementations speak to each other, > > there is a possibility of two sides not being able to find a common > > interval value to run BFD sessions. > > > > This document defines a small set of interval values for BFD that we > > call "Common intervals", and recommends implementations to support > > the defined intervals. This solves the problem of finding an > > interval value that both BFD speakers can support while allowing a > > simplified implementation as seen for hardware-based BFD. It does > > not restrict an implementation from supporting more intervals in > > addition to the Common intervals. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-intervals-01 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > From nobody Wed Jun 11 15:11:28 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F771A02F8; Wed, 11 Jun 2014 15:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnTqj2ANNLHT; Wed, 11 Jun 2014 15:11:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 724931B28B6; Wed, 11 Jun 2014 15:11:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-seamless-use-case-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140611221113.10826.66883.idtracker@ietfa.amsl.com> Date: Wed, 11 Jun 2014 15:11:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/DFs8ReM0jwtyfiExfxXk2JOiFUw Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 22:11:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Seamless Bidirectional Forwarding Detection (BFD) Use Case Authors : Sam Aldrin Manav Bhatia Greg Mirsky Nagendra Kumar Satoru Matsushima Filename : draft-ietf-bfd-seamless-use-case-00.txt Pages : 10 Date : 2014-06-11 Abstract: This document provides various use cases for Bidirectional Forwarding Detection (BFD) such that simplified solution and extensions could be developed for detecting forwarding failures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-use-case/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-seamless-use-case-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 12 09:15:16 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E131A0178; Thu, 12 Jun 2014 09:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYrCAjg_-xdk; Thu, 12 Jun 2014 09:15:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 232E01B2AAE; Thu, 12 Jun 2014 09:15:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-seamless-base-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140612161500.11498.95108.idtracker@ietfa.amsl.com> Date: Thu, 12 Jun 2014 09:15:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/IX-a7vZg0Q43L6Z4Ajf6lrIU_Io Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 16:15:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Seamless Bidirectional Forwarding Detection (S-BFD) Authors : Nobo Akiya Carlos Pignataro Dave Ward Manav Bhatia Juniper Networks Filename : draft-ietf-bfd-seamless-base-00.txt Pages : 20 Date : 2014-06-12 Abstract: This document defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-seamless-base-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 13 07:05:23 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1004F1B2936 for ; Fri, 13 Jun 2014 07:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tICA1gfe7stI for ; Fri, 13 Jun 2014 07:05:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 312BF1B292E for ; Fri, 13 Jun 2014 07:05:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: rtg-bfd@ietf.org Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140613140515.24397.61381.idtracker@ietfa.amsl.com> Date: Fri, 13 Jun 2014 07:05:15 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/xvUXnEQNwZ8TG5jDUK0usHFMhX8 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 14:05:18 -0000 URL: http://datatracker.ietf.org/wg/bfd/charter/ From nobody Fri Jun 13 07:11:59 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22D61B293D for ; Fri, 13 Jun 2014 07:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcTso6n6m0rI for ; Fri, 13 Jun 2014 07:11:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3B51B2940 for ; Fri, 13 Jun 2014 07:11:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: rtg-bfd@ietf.org Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140613141132.23861.84776.idtracker@ietfa.amsl.com> Date: Fri, 13 Jun 2014 07:11:32 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/y_0C-gSmJkE5f9WWu0HDpvgB_10 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 14:11:58 -0000 Changed milestone "Submit the BFD Seamless Use Case document to the IESG to be considered as a Proposed Standard", set state to active from review, accepting new milestone. Changed milestone "Submit the BFD Seamless Base draft to the IESG to be considered as a Proposed Standard", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/bfd/charter/ From nobody Mon Jun 16 05:06:53 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3A21B2C18 for ; Mon, 16 Jun 2014 05:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWKCechhzZJj for ; Mon, 16 Jun 2014 05:06:33 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4131B2C17 for ; Mon, 16 Jun 2014 05:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=693; q=dns/txt; s=iport; t=1402920393; x=1404129993; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=bLbwdNGG5X3cIK0Vc4zjlZn6tLo93exSWInwf9Re/Qw=; b=hScgI60iAzKQfFYE2f5wYvHQoO81rR9tR4nK0yVY8EN7fBw5f4GUE6BY On+jLXOF3F9cPMG/y8wu+jkK2CvHmLr9f82hfJkoZs9HmN2jhEJFfpfBo Ku2MxkxLd4uMeo4MyiNB1eWoiiJH9b4VqUyp9GOE4x2z7jbS+ruSeZsdD 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAHrdnlOtJA2F/2dsb2JhbABagmkkgSzDGQGBERZ1hAUBBDo/EgEqFEImAQQBDQUIiDoBzycXjkUxgzSBFgEDrhuDQIIw X-IronPort-AV: E=Sophos;i="5.01,486,1400025600"; d="scan'208";a="333398096" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP; 16 Jun 2014 12:06:28 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s5GC6SXX011322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Jun 2014 12:06:28 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Mon, 16 Jun 2014 07:06:28 -0500 From: "Nobo Akiya (nobo)" To: "Jeffrey Haas (jhaas@pfrc.org)" , "Jeff Haas (jhaas@juniper.net)" Subject: S-BFD UDP Port Early Allocation Request Thread-Topic: S-BFD UDP Port Early Allocation Request Thread-Index: Ac+JWnLSI0Mb+nKFSUSh/rVVlhnVIQ== Date: Mon, 16 Jun 2014 12:06:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/R9J1cs-r8NFl267bNoDOcGh1s_E Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2014 12:06:36 -0000 Hi Jeff, Authors/contributors of draft-ietf-bfd-seamless-base would like to request = early allocation of the S-BFD UDP port number. As per RFC7120, please consider this as the request to initiate the early a= llocation process. Code point: Service Name (REQUIRED) s-bfd Transport Protocol(s) (REQUIRED) udp Assignee (REQUIRED) IESG Contact (REQUIRED) BFD Chairs Description (REQUIRED) Seamless Bidirectional Forwarding Detection (S-BFD) Reference (REQUIRED) draft-ietf-bfd-seamless-base Port Number (OPTIONAL) 7784 Thanks! -Nobo, as author of draft-ietf-bfd-seamless-base From nobody Mon Jun 16 12:29:00 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA91B1A0166 for ; Mon, 16 Jun 2014 12:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJTOCElHLCf1 for ; Mon, 16 Jun 2014 12:28:57 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A00581A0154 for ; Mon, 16 Jun 2014 12:28:57 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 52259C406; Mon, 16 Jun 2014 15:28:57 -0400 (EDT) Date: Mon, 16 Jun 2014 15:28:57 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: S-BFD UDP Port Early Allocation Request Message-ID: <20140616192857.GE31387@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/6yaOuoavjBbiFTFTJJ42JVTtYBg Cc: "Jeff Haas \(jhaas@juniper.net\)" , "rtg-bfd@ietf.org" , Alia Atlas X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2014 19:28:59 -0000 +alia Nobo, A few comments: On Mon, Jun 16, 2014 at 12:06:27PM +0000, Nobo Akiya (nobo) wrote: > Authors/contributors of draft-ietf-bfd-seamless-base would like to request early allocation of the S-BFD UDP port number. > > As per RFC7120, please consider this as the request to initiate the early allocation process. Tentatively, I believe the constraints for RFC 7120 have been met and that the appropriate policy is covered for the requested service port. I do have a minor concern that, similar to other applications of BFD that there may be multiple ports required for the S-BFD application depending on transport. While the case in the base draft is reasonably clear, the various application drafts haven't yet reached maturity for us to be ready to consider adopting them. Do you believe the above is incorrect? Secondly, this is a reminder that such a request starts a timer: Upon assignment, the temporary reservation is good for one year with the possibility of a single one-year extension. Do you believe we're ready to start that timer? (I'd hope so, given the milestones we've set thus far, but my meta concern about the application documents is the driving factor.) -- Jeff > > Code point: > > Service Name (REQUIRED) > s-bfd > Transport Protocol(s) (REQUIRED) > udp > Assignee (REQUIRED) > IESG > Contact (REQUIRED) > BFD Chairs > Description (REQUIRED) > Seamless Bidirectional Forwarding Detection (S-BFD) > Reference (REQUIRED) > draft-ietf-bfd-seamless-base > Port Number (OPTIONAL) > 7784 > > Thanks! > > -Nobo, as author of draft-ietf-bfd-seamless-base From nobody Mon Jun 16 13:31:35 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FA01A01F9 for ; Mon, 16 Jun 2014 13:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VVRkXJ6oFtC for ; Mon, 16 Jun 2014 13:31:31 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D71D1A0203 for ; Mon, 16 Jun 2014 13:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3637; q=dns/txt; s=iport; t=1402950691; x=1404160291; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2SEAiNfu0OWbcyeCbWJBULR+hjhgJ0AsaEy/QYtqpPk=; b=Ap+BVUjqNL137r+0+CwyiuyT7yTzzk8kifN+iRJ4GAd7Z1kYy1IJgE8Q 4a3oKezYbKBxr0RtK56OX/g6EgqcyY2u6npY/r+pZhz6LT1CTMa40VDbF ttI+I8n9rL5mncF0HH/0CsK1cRrxiW744F5bm/X8GhmiCTJSP1fw9KGtg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAHASn1OtJV2c/2dsb2JhbABagmkkgSzDHwGBERZ1hAMBAQEDATo/DAQCAQgOAwQBAQEKFAkHMhQJCAEBBA4FCIgyCAHPLheORTEHBoMngRYErhuDQIFuJB4 X-IronPort-AV: E=Sophos;i="5.01,489,1400025600"; d="scan'208";a="53470674" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP; 16 Jun 2014 20:31:30 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5GKVUde023318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Jun 2014 20:31:30 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 16 Jun 2014 15:31:30 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas Subject: RE: S-BFD UDP Port Early Allocation Request Thread-Topic: S-BFD UDP Port Early Allocation Request Thread-Index: Ac+JWnLSI0Mb+nKFSUSh/rVVlhnVIQAaK1yAAApkkkA= Date: Mon, 16 Jun 2014 20:31:30 +0000 Message-ID: References: <20140616192857.GE31387@pfrc> In-Reply-To: <20140616192857.GE31387@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/zNGo1DdjlV7W21mhMsW5kl5zjVA Cc: "Jeff Haas \(jhaas@juniper.net\)" , "rtg-bfd@ietf.org" , Alia Atlas X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2014 20:31:33 -0000 Hi Jeff, > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Monday, June 16, 2014 3:29 PM > To: Nobo Akiya (nobo) > Cc: Jeffrey Haas (jhaas@pfrc.org); Jeff Haas (jhaas@juniper.net); rtg- > bfd@ietf.org; adrian@olddog.co.uk; Alia Atlas > Subject: Re: S-BFD UDP Port Early Allocation Request >=20 > +alia >=20 > Nobo, >=20 > A few comments: >=20 > On Mon, Jun 16, 2014 at 12:06:27PM +0000, Nobo Akiya (nobo) wrote: > > Authors/contributors of draft-ietf-bfd-seamless-base would like to > request early allocation of the S-BFD UDP port number. > > > > As per RFC7120, please consider this as the request to initiate the ear= ly > allocation process. >=20 > Tentatively, I believe the constraints for RFC 7120 have been met and tha= t > the appropriate policy is covered for the requested service port. >=20 > I do have a minor concern that, similar to other applications of BFD that > there may be multiple ports required for the S-BFD application depending > on transport. While the case in the base draft is reasonably clear, the > various application drafts haven't yet reached maturity for us to be read= y to > consider adopting them. >=20 > Do you believe the above is incorrect? That's a very fair question. It is my belief that one port will suffice for= S-BFD on all transports, rather I strongly believe this is preferred to ke= ep S-BFD transport agnostic. >=20 > Secondly, this is a reminder that such a request starts a timer: Upon > assignment, the temporary reservation is good for one year with the > possibility of a single one-year extension. Do you believe we're ready t= o > start that timer? Because folks are starting to implement this, we need a common port number.= Indeed this request will start the timer, but that's necessary at this poi= nt. Let us proceed to start the timer and aim to progress the draft before = the timer expiry. >=20 > (I'd hope so, given the milestones we've set thus far, but my meta concer= n > about the application documents is the driving factor.) Recently, I've re-published the s-bfd-ip/s-bfd-sr document with following n= ote in the abstract. Note: this document needs to be updated to align with changes in the S-BFD base document. If all goes well with S-BFD base document, the two documents can get conver= ted to short informational documents or something else. We need a bit more = time to sort this out. s-bfd-alert-discrim document, on the other hand, may get a bit more interes= ting. I've received some off-list comments about wanting something similar,= particularly to handle simple and/or control-plane-less environments. But = this has more to do with discriminators, not ports. I was planning to grab = some of you folks in Toronto or get folks to gather at your "bar office hou= r" to start some conversations on this topic :) All this to say, I hope above satisfies the requirements, and we can procee= d with early IANA allocation of the S-BFD port. Thanks! -Nobo >=20 > -- Jeff >=20 >=20 > > > > Code point: > > > > Service Name (REQUIRED) > > s-bfd > > Transport Protocol(s) (REQUIRED) > > udp > > Assignee (REQUIRED) > > IESG > > Contact (REQUIRED) > > BFD Chairs > > Description (REQUIRED) > > Seamless Bidirectional Forwarding Detection (S-BFD) > > Reference (REQUIRED) > > draft-ietf-bfd-seamless-base > > Port Number (OPTIONAL) > > 7784 > > > > Thanks! > > > > -Nobo, as author of draft-ietf-bfd-seamless-base From nobody Mon Jun 16 13:38:52 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0691A01EB for ; Mon, 16 Jun 2014 13:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQPg05n1uyAS for ; Mon, 16 Jun 2014 13:38:15 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 517B31A00DA for ; Mon, 16 Jun 2014 13:38:15 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E740CC406; Mon, 16 Jun 2014 16:38:14 -0400 (EDT) Date: Mon, 16 Jun 2014 16:38:14 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: S-BFD UDP Port Early Allocation Request Message-ID: <20140616203814.GH31387@pfrc> References: <20140616192857.GE31387@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/KK5K5mt8crTzoOubN25d18FtoW4 Cc: "Jeff Haas \(jhaas@juniper.net\)" , "rtg-bfd@ietf.org" , Alia Atlas X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2014 20:38:30 -0000 Nobo, On Mon, Jun 16, 2014 at 08:31:30PM +0000, Nobo Akiya (nobo) wrote: > > I do have a minor concern that, similar to other applications of BFD that > > there may be multiple ports required for the S-BFD application depending > > on transport. While the case in the base draft is reasonably clear, the > > various application drafts haven't yet reached maturity for us to be ready to > > consider adopting them. > > > > Do you believe the above is incorrect? > > That's a very fair question. It is my belief that one port will suffice for S-BFD on all transports, rather I strongly believe this is preferred to keep S-BFD transport agnostic. > > > > > Secondly, this is a reminder that such a request starts a timer: Upon > > assignment, the temporary reservation is good for one year with the > > possibility of a single one-year extension. Do you believe we're ready to > > start that timer? > > Because folks are starting to implement this, we need a common port number. Indeed this request will start the timer, but that's necessary at this point. Let us proceed to start the timer and aim to progress the draft before the timer expiry. I think given the above, we have sufficient cause to advance early allocation. It's now up to the ADs. -- Jeff From nobody Mon Jun 16 13:53:26 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFAB1A021C for ; Mon, 16 Jun 2014 13:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5kBRztHwQur for ; Mon, 16 Jun 2014 13:52:14 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2E531A021B for ; Mon, 16 Jun 2014 13:52:13 -0700 (PDT) Received: by mail-yk0-f178.google.com with SMTP id q9so4653643ykb.9 for ; Mon, 16 Jun 2014 13:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SkvqsqxPvbEb5GfBPoWN3JTteff+zHhKWi5SNI7OPuQ=; b=b5spvqlw8u1dfMdYbE+2lZ33TR333zewTL0HeWiK0H2RnaFjxkzChAdvDlUJWu7+Ls Edoy0fL/kr734X4LRspRqXzeekuGFw6/rFGRz325TlyqzAZ/6GaSu6M24A12Cr9pqh1B B6oKNQ6xU4JjwBWwaaZi4DjSsvAdX6mbmONA4NSnUId86prRDF2s/jCOdiQE6mRXRjTE bryQptTLGTL3H5X0d1Fnjvpwriix2M4yVD0wjqYNXmt7xyjA65xHdMPOKtnBEj8wkJCr t0bTOQ28W2ukNyNiL+ZkT+g+TVYVtnTM5zGSvfuZiAct/uylTNDhMMBvwqomd+lo3Nic 0xdg== MIME-Version: 1.0 X-Received: by 10.236.167.103 with SMTP id h67mr7539500yhl.141.1402951933263; Mon, 16 Jun 2014 13:52:13 -0700 (PDT) Received: by 10.170.52.75 with HTTP; Mon, 16 Jun 2014 13:52:13 -0700 (PDT) In-Reply-To: <20140616203814.GH31387@pfrc> References: <20140616192857.GE31387@pfrc> <20140616203814.GH31387@pfrc> Date: Mon, 16 Jun 2014 16:52:13 -0400 Message-ID: Subject: Re: S-BFD UDP Port Early Allocation Request From: Alia Atlas To: Jeffrey Haas , Adrian Farrel Content-Type: multipart/alternative; boundary=20cf30434c769e83cc04fbfa33cc Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/mbC8VkEgCaIZmjKSN63JS8qa9bs Cc: "Jeff Haas \(jhaas@juniper.net\)" , Alia Atlas , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2014 20:52:50 -0000 X-List-Received-Date: Mon, 16 Jun 2014 20:52:50 -0000 --20cf30434c769e83cc04fbfa33cc Content-Type: text/plain; charset=UTF-8 Since BFD is one of Adrian's WGs, I'm assuming that he'll handle it. If not, I can send email too :-) Alia On Mon, Jun 16, 2014 at 4:38 PM, Jeffrey Haas wrote: > Nobo, > > On Mon, Jun 16, 2014 at 08:31:30PM +0000, Nobo Akiya (nobo) wrote: > > > I do have a minor concern that, similar to other applications of BFD > that > > > there may be multiple ports required for the S-BFD application > depending > > > on transport. While the case in the base draft is reasonably clear, > the > > > various application drafts haven't yet reached maturity for us to be > ready to > > > consider adopting them. > > > > > > Do you believe the above is incorrect? > > > > That's a very fair question. It is my belief that one port will suffice > for S-BFD on all transports, rather I strongly believe this is preferred to > keep S-BFD transport agnostic. > > > > > > > > Secondly, this is a reminder that such a request starts a timer: Upon > > > assignment, the temporary reservation is good for one year with the > > > possibility of a single one-year extension. Do you believe we're > ready to > > > start that timer? > > > > Because folks are starting to implement this, we need a common port > number. Indeed this request will start the timer, but that's necessary at > this point. Let us proceed to start the timer and aim to progress the draft > before the timer expiry. > > I think given the above, we have sufficient cause to advance early > allocation. It's now up to the ADs. > > -- Jeff > > --20cf30434c769e83cc04fbfa33cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Since BFD is one of Adrian's WGs, I'm assuming tha= t he'll handle it.
If not, I can send email too :-)

<= /div>
Alia


On Mon, Jun 16, 2014 at 4:38 PM, Jeffrey Haas <jhaas@pfrc.org> = wrote:
Nobo,

On Mon, Jun 16, 2014 at 08:31:30PM +0000, Nobo Akiya (nobo) wrote:
> > I do have a minor concern that, similar to other applications of = BFD that
> > there may be multiple ports required for the S-BFD application de= pending
> > on transport. =C2=A0While the case in the base draft is reasonabl= y clear, the
> > various application drafts haven't yet reached maturity for u= s to be ready to
> > consider adopting them.
> >
> > Do you believe the above is incorrect?
>
> That's a very fair question. It is my belief that one port will su= ffice for S-BFD on all transports, rather I strongly believe this is prefer= red to keep S-BFD transport agnostic.
>
> >
> > Secondly, this is a reminder that such a request starts a timer: = Upon
> > assignment, the temporary reservation is good for one year with t= he
> > possibility of a single one-year extension. =C2=A0Do you believe = we're ready to
> > start that timer?
>
> Because folks are starting to implement this, we need a common port nu= mber. Indeed this request will start the timer, but that's necessary at= this point. Let us proceed to start the timer and aim to progress the draf= t before the timer expiry.

I think given the above, we have sufficient cause to advance early allocation. =C2=A0It's now up to the ADs.

-- Jeff


--20cf30434c769e83cc04fbfa33cc-- From nobody Wed Jun 18 12:40:40 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA8C1A02B6 for ; Wed, 18 Jun 2014 12:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmzUwQU2m9Yp for ; Wed, 18 Jun 2014 12:40:36 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4935E1A00E8 for ; Wed, 18 Jun 2014 12:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=783; q=dns/txt; s=iport; t=1403120436; x=1404330036; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=XYXiNjtrpk3SmPbmFKF3bf4FO37pBwNKX5n0Nxko35A=; b=FICc2XQLC0tY41potuQK+DHcWFeeesrXelLTfjq3yYeEUynZ58XcBHn0 LT3g9STACWyR/DuMcMn5WK/GNRHm535EfUDTSrxMld8YgkZSmRIt35dgl H3lcalrr4ENL5J6+DMYgG/xqYMBCFTQmCAMqPNWF+AdqFPyDM2i6l2/yd w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEFANzqoVOtJV2R/2dsb2JhbABagmkkgSzDRwGBCxZ1hAUBBB0dNAsSASoUQiYBBA4NiDoBzVMXjhMRAR8xgzSBFgEDrhuDQoF3OQ X-IronPort-AV: E=Sophos;i="5.01,501,1400025600"; d="scan'208";a="333881656" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-1.cisco.com with ESMTP; 18 Jun 2014 19:40:16 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s5IJeGDv008507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jun 2014 19:40:16 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 18 Jun 2014 14:40:15 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: Meeting in Toronto for IETF 90 - Call for Presentations Thread-Topic: Meeting in Toronto for IETF 90 - Call for Presentations Thread-Index: Ac+LK7i/uyhjfAOdTtyStUlqE3TE6g== Date: Wed, 18 Jun 2014 19:40:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/VzXOQoylh-NHY7Dyo6imgYpEI-4 Cc: "Jeff Haas \(jhaas@juniper.net\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jun 2014 19:40:37 -0000 Hi BFD WG, The WG chairs have determined we have enough items to warrant a meeting at = the upcoming IETF in Toronto. Some possible items targeted for the agenda: - Usual updates - S-BFD - BFD performance - BFD multipoint - BFD proxy - ??? If you have a topic you'd like to discuss at the meeting, please email the = chairs along with following information. 1) Draft title 2) Presenter name 3) Requested duration Note: we require an email for those possible items listed above. As always, we're looking to keep the sessions short and focused on discussi= on rather than reading from slides. New proposals should be backed by Inter= net-Drafts and discussion ideally should be initiated on the mailing list f= irst. Thanks! - Nobo and Jeff From nobody Thu Jun 26 11:46:10 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB711B2CFF; Thu, 26 Jun 2014 11:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puQVZqXd14JA; Thu, 26 Jun 2014 11:46:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6141B3103; Thu, 26 Jun 2014 11:25:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-seamless-base-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140626182533.30391.72279.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 11:25:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/z3bdLOB3nXCUyPPzX8VLUyg-WYA Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 18:46:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Seamless Bidirectional Forwarding Detection (S-BFD) Authors : Nobo Akiya Carlos Pignataro Dave Ward Manav Bhatia Juniper Networks Filename : draft-ietf-bfd-seamless-base-01.txt Pages : 17 Date : 2014-06-26 Abstract: This document defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. This document updates RFC5880. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-seamless-base-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-base-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 26 12:02:42 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9723A1B2C52 for ; Thu, 26 Jun 2014 12:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAXdWR0WBHaW for ; Thu, 26 Jun 2014 12:02:38 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8AA1B2C3C for ; Thu, 26 Jun 2014 12:02:37 -0700 (PDT) Received: from BLUPR05MB755.namprd05.prod.outlook.com (10.141.208.145) by BLUPR05MB756.namprd05.prod.outlook.com (10.141.208.151) with Microsoft SMTP Server (TLS) id 15.0.959.24; Thu, 26 Jun 2014 19:02:34 +0000 Received: from BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) by BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) with mapi id 15.00.0959.000; Thu, 26 Jun 2014 19:02:35 +0000 From: Santosh P K To: "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt Thread-Topic: I-D Action: draft-ietf-bfd-seamless-base-01.txt Thread-Index: AQHPkW7orvtsYoUzjEGDExMAHUZZH5uDu21A Date: Thu, 26 Jun 2014 19:02:34 +0000 Message-ID: <8fe58c80d3ba4e0da4da3e82cf7677dc@BLUPR05MB755.namprd05.prod.outlook.com> References: <20140626182533.30391.72279.idtracker@ietfa.amsl.com> In-Reply-To: <20140626182533.30391.72279.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.17] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02543CD7CD x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(13464003)(377424004)(53754006)(377454003)(21056001)(101416001)(92566001)(15202345003)(81542001)(19580405001)(86362001)(19580395003)(54356999)(50986999)(2656002)(76176999)(83322001)(81342001)(15975445006)(76482001)(79102001)(87936001)(74502001)(85852003)(31966008)(74662001)(77982001)(33646001)(107046002)(46102001)(85306003)(80022001)(4396001)(99396002)(66066001)(64706001)(74316001)(76576001)(19625215002)(19300405004)(106356001)(105586002)(16236675004)(106116001)(83072002)(95666004)(20776003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB756; H:BLUPR05MB755.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_8fe58c80d3ba4e0da4da3e82cf7677dcBLUPR05MB755namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/jY4e44jGwHOqerqhW-9AZ6LOAM4 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 19:02:40 -0000 --_000_8fe58c80d3ba4e0da4da3e82cf7677dcBLUPR05MB755namprd05pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQWxsLA0KDQogICAgUy1CRkQgdmVyc2lvbiAxIGlzIHB1Ymxpc2hlZC4gVGhhbmtzIHRv IGFsbCB3aG8gaGFkIHByb3ZpZGVkIGNvbW1lbnRzLiAgRGlmZiBiZXR3ZWVuIHZlcnNpb24gMCBh bmQgMSBpcyBzaWduaWZpY2FudCBidXQgdGhlcmUgYXJlIG5vIHRlY2huaWNhbCBjaGFuZ2VzLiBC ZWxvdyBhcmUgdGhlIGNoYW5nZXMuDQoNCg0KDQoxLiAgICAgICBUYWtlbiBjYXJlIG9mIGFsbCBy ZXZpZXcgY29tbWVudHMuDQoNCjIuICAgICAgIOKAnEZ1bGwvcGFydGlhbCByZWFjaGFiaWxpdHni gJ0gaXMgcmVtb3ZlZCBhbmQgZm9jdXMgaXMgb24gdGhlIHJlYWNoYWJpbGl0eS4NCg0KMy4gICAg ICAgU1BSSU5HIGRlcGVuZGVuY3kgaXMgcmVtb3ZlZC4NCg0KNC4gICAgICAgSVAgc3BlY2lmaWMg ZGV0YWlscyBoYXMgYmVlbiBtb3ZlZCB0byAiZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLSBpcCIu DQoNCjUuICAgICAgIENvbnNpc3RlbnQgdGVybWlub2xvZ3kuDQoNCjYuICAgICAgIExvdHMgb2Yg cmVwaHJhc2luZyBmb3IgYmV0dGVyIHJlYWRhYmlsaXR5Lg0KDQoNCg0KVGhhbmtzDQoNClNhbnRv c2ggUCBLDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUnRnLWJmZCBb bWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZw0KU2VudDogVGh1cnNkYXksIEp1bmUgMjYsIDIwMTQgMTE6NTYgUE0NClRv OiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCkNjOiBydGctYmZkQGlldGYub3JnDQpTdWJqZWN0OiBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWJmZC1zZWFtbGVzcy1iYXNlLTAxLnR4dA0KDQoNCg0KDQoN CkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiBXb3JraW5nIEdyb3VwIG9mIHRo ZSBJRVRGLg0KDQoNCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBTZWFtbGVzcyBCaWRpcmVj dGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChTLUJGRCkNCg0KICAgICAgICBBdXRob3JzICAg ICAgICAgOiBOb2JvIEFraXlhDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgQ2FybG9zIFBp Z25hdGFybw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgIERhdmUgV2FyZA0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgIE1hbmF2IEJoYXRpYQ0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgIEp1bmlwZXIgTmV0d29ya3MNCg0KICAgICAgICAgICAgICAgIEZpbGVuYW1lICAgICAgICA6 IGRyYWZ0LWlldGYtYmZkLXNlYW1sZXNzLWJhc2UtMDEudHh0DQoNCiAgICAgICAgICAgICAgICBQ YWdlcyAgICAgICAgICAgOiAxNw0KDQogICAgICAgICAgICAgICAgRGF0ZSAgICAgICAgICAgIDog MjAxNC0wNi0yNg0KDQoNCg0KQWJzdHJhY3Q6DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBh IHNpbXBsaWZpZWQgbWVjaGFuaXNtIHRvIHVzZSBCaWRpcmVjdGlvbmFsDQoNCiAgIEZvcndhcmRp bmcgRGV0ZWN0aW9uIChCRkQpIHdpdGggbGFyZ2UgcG9ydGlvbnMgb2YgbmVnb3RpYXRpb24gYXNw ZWN0cw0KDQogICBlbGltaW5hdGVkLCB0aHVzIHByb3ZpZGluZyBiZW5lZml0cyBzdWNoIGFzIHF1 aWNrIHByb3Zpc2lvbmluZyBhcw0KDQogICB3ZWxsIGFzIGltcHJvdmVkIGNvbnRyb2wgYW5kIGZs ZXhpYmlsaXR5IHRvIG5ldHdvcmsgbm9kZXMgaW5pdGlhdGluZw0KDQogICB0aGUgcGF0aCBtb25p dG9yaW5nLg0KDQoNCg0KICAgVGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQzU4ODAuDQoNCg0KDQoN Cg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlz Og0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWJmZC1zZWFt bGVzcy1iYXNlLw0KDQoNCg0KVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFi bGUgYXQ6DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLXNlYW1s ZXNzLWJhc2UtMDENCg0KDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2 YWlsYWJsZSBhdDoNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0 Zi1iZmQtc2VhbWxlc3MtYmFzZS0wMQ0KDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCg0KDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5v bnltb3VzIEZUUCBhdDoNCg0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0K DQo= --_000_8fe58c80d3ba4e0da4da3e82cf7677dcBLUPR05MB755namprd05pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwg bGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NzE0MjgwMjU5 Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotOTY5NDA2 MTc0IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1 IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQt aW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SGVsbG8gQWxsLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFMtQkZEIHZlcnNpb24gMSBpcyBwdWJsaXNoZWQuIFRoYW5rcyB0byBhbGwgd2hvIGhhZCBwcm92 aWRlZCBjb21tZW50cy4gJm5ic3A7RGlmZiBiZXR3ZWVuIHZlcnNpb24gMCBhbmQgMSBpcyBzaWdu aWZpY2FudCBidXQgdGhlcmUgYXJlIG5vIHRlY2huaWNhbCBjaGFuZ2VzLiBCZWxvdyBhcmUgdGhl IGNoYW5nZXMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRha2Vu IGNhcmUgb2YgYWxsIHJldmlldyBjb21tZW50cy4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+4oCcRnVsbC9wYXJ0aWFsIHJlYWNoYWJpbGl0eeKAnSBp cyByZW1vdmVkIGFuZCBmb2N1cyBpcyBvbiB0aGUgcmVhY2hhYmlsaXR5LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlNQUklORyBkZXBlbmRlbmN5IGlz IHJlbW92ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ NC48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+SVAgc3BlY2lmaWMgZGV0YWlscyBoYXMgYmVlbiBtb3ZlZCB0byAmcXVvdDtkcmFmdC1ha2l5 YS1iZmQtc2VhbWxlc3MtIGlwJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPjUuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPkNvbnNpc3RlbnQgdGVybWlub2xvZ3kuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Ni48c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+TG90cyBvZiByZXBocmFzaW5nIGZv ciBiZXR0ZXIgcmVhZGFiaWxpdHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYW5rczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U2FudG9zaCBQIEs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCkZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8YnI+DQpTZW50OiBU aHVyc2RheSwgSnVuZSAyNiwgMjAxNCAxMTo1NiBQTTxicj4NClRvOiBpLWQtYW5ub3VuY2VAaWV0 Zi5vcmc8YnI+DQpDYzogcnRnLWJmZEBpZXRmLm9yZzxicj4NClN1YmplY3Q6IEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtYmZkLXNlYW1sZXNzLWJhc2UtMDEudHh0PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBk aXJlY3Rvcmllcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRl Y3Rpb24gV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRpdGxlJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDogU2VhbWxlc3MgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoUy1CRkQpPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXV0aG9ycyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IE5vYm8gQWtpeWE8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBD YXJsb3MgUGlnbmF0YXJvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGF2ZSBXYXJkPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgTWFuYXYgQmhhdGlhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSnVuaXBlciBOZXR3b3Jr czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpbGVuYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDogZHJhZnQtaWV0Zi1iZmQtc2VhbWxlc3MtYmFzZS0wMS50eHQ8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBQYWdlcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA6IDE3PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGF0ZSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6 IDIwMTQtMDYtMjY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QWJzdHJhY3Q6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1 bWVudCBkZWZpbmVzIGEgc2ltcGxpZmllZCBtZWNoYW5pc20gdG8gdXNlIEJpZGlyZWN0aW9uYWw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBGb3J3 YXJkaW5nIERldGVjdGlvbiAoQkZEKSB3aXRoIGxhcmdlIHBvcnRpb25zIG9mIG5lZ290aWF0aW9u IGFzcGVjdHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyBlbGltaW5hdGVkLCB0aHVzIHByb3ZpZGluZyBiZW5lZml0cyBzdWNoIGFzIHF1aWNrIHBy b3Zpc2lvbmluZyBhczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7IHdlbGwgYXMgaW1wcm92ZWQgY29udHJvbCBhbmQgZmxleGliaWxpdHkgdG8gbmV0 d29yayBub2RlcyBpbml0aWF0aW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsgdGhlIHBhdGggbW9uaXRvcmluZy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkM1ODgwLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQg aXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWJmZC1zZWFtbGVzcy1iYXNl LyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYmZkLXNlYW1sZXNzLWJh c2UvPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlcmUncyBhbHNv IGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWJmZC1zZWFtbGVzcy1iYXNlLTAxIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1iZmQtc2VhbWxlc3MtYmFzZS0wMTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBh dDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9Imh0dHA6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYmZkLXNlYW1sZXNzLWJhc2Ut MDEiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5o dHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWJmZC1zZWFtbGVzcy1i YXNlLTAxPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v bHMuaWV0Zi5vcmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkludGVybmV0LURyYWZ0 cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRp b246bm9uZSI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8fe58c80d3ba4e0da4da3e82cf7677dcBLUPR05MB755namprd05pro_-- From nobody Thu Jun 26 16:32:12 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36191B3001 for ; Thu, 26 Jun 2014 16:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.151 X-Spam-Level: X-Spam-Status: No, score=-115.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zc5qi0W63Fzp for ; Thu, 26 Jun 2014 16:32:06 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D9B1B2828 for ; Thu, 26 Jun 2014 16:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36980; q=dns/txt; s=iport; t=1403825525; x=1405035125; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=MjdadN42o9hAxQ8c6FfOMNmV4U/p3uCI7aKzalrz0xY=; b=RPXZDWaB2+TpspDx0RJSNfQHyzAzHayhNhDmnGBkduO3AJCKjY58DYF8 CuICQATP64Ti8LtGeE3dRb8H5FWwQatTL3qVHF+vi/nmVDuU8EDv+ddlU qdnbnxJ5Bau581VRcc2lU7birH6lps+zUvF9lApWZJPbtSG/NbsCZJHr3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8KABOsrFOtJV2d/2dsb2JhbABagkYjJFJTB4JuuB+JFQEZcRZ1hAMBAQEEIwpYBAIBCBEEAQELFgEGAwICAjAUCQgCBAESCAGIOQEHBaRgnTwXjk8WFwoBBoJxNoEWBZwfki+DQmyBRA X-IronPort-AV: E=Sophos; i="5.01,556,1400025600"; d="scan'208,217"; a="56322178" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 26 Jun 2014 23:32:04 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s5QNW4mu027036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Jun 2014 23:32:04 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Thu, 26 Jun 2014 18:32:04 -0500 From: "Nobo Akiya (nobo)" To: Santosh P K , "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt Thread-Topic: I-D Action: draft-ietf-bfd-seamless-base-01.txt Thread-Index: AQHPkW78JeCHvpBJ/EuFcrJj+qOrd5uEE1MA///0AsA= Date: Thu, 26 Jun 2014 23:32:03 +0000 Message-ID: References: <20140626182533.30391.72279.idtracker@ietfa.amsl.com> <8fe58c80d3ba4e0da4da3e82cf7677dc@BLUPR05MB755.namprd05.prod.outlook.com> In-Reply-To: <8fe58c80d3ba4e0da4da3e82cf7677dc@BLUPR05MB755.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941E251864xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/_ML_6dd9wHXZGKo29PLiwQR0yYM X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 23:32:09 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941E251864xmbalnx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQkZEZXJzLA0KDQpZZXMsIG1hbnkgdGhhbmtzIHRvIHRob3NlIHByb3ZpZGVkIGNvbW1l bnRzIG9uIFMtQkZELg0KDQpDb3VwbGUgb2YgYWRkaXRpb25hbCB0aGluZ3M6DQoNCmRyYWZ0LWll dGYtYmZkLXNlYW1sZXNzLWJhc2UtMDENCg0KLSAgICAgICAgQ29udGFpbnMgc2lnbmlmaWNhbnQg Y2hhbmdlcyBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uLg0KDQotICAgICAgICBUaGVyZSBzaG91 bGQgbm90IGJlIGFueSB0ZWNobmljYWwgY2hhbmdlcy4NCg0KLSAgICAgICAgR3JlYXRseSBzZWVr aW5nIGNvbW1lbnRzIG9uIGhvdyB3ZSBtb3ZlIGZvcndhcmQgd2l0aCBTLUJGRCBkaXNjcmltaW5h dG9yIHVuaXF1ZW5lc3MgcmVxdWlyZW1lbnRzLg0KDQpkcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3Mt aXAtMDMNCg0KLSAgICAgICAgSnVzdCBwdWJsaXNoZWQsIGxpbmtzIGJlbG93Lg0KDQotICAgICAg ICBTZWVraW5nIGNvbW1lbnRzIG9uIHdoZXRoZXIgd2Ugd2FudCB0byBkZWZpbmUgYSBuZXcgYXNz b2NpYXRlZCBjaGFubmVsIHR5cGUgZm9yIFMtQkZELg0KDQoNClVSTDogICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3Mt aXAtMDMudHh0DQoNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtaXAvDQoNCkh0bWxpemVkOiAgICAgICBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtaXAtMDMNCg0K RGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWFr aXlhLWJmZC1zZWFtbGVzcy1pcC0wMw0KDQpUaGFua3MhDQoNCi1Ob2JvDQoNCkZyb206IFJ0Zy1i ZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTYW50b3No IFAgSw0KU2VudDogVGh1cnNkYXksIEp1bmUgMjYsIDIwMTQgMzowMyBQTQ0KVG86IHJ0Zy1iZmRA aWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWJmZC1zZWFtbGVz cy1iYXNlLTAxLnR4dA0KDQoNCkhlbGxvIEFsbCwNCg0KICAgIFMtQkZEIHZlcnNpb24gMSBpcyBw dWJsaXNoZWQuIFRoYW5rcyB0byBhbGwgd2hvIGhhZCBwcm92aWRlZCBjb21tZW50cy4gIERpZmYg YmV0d2VlbiB2ZXJzaW9uIDAgYW5kIDEgaXMgc2lnbmlmaWNhbnQgYnV0IHRoZXJlIGFyZSBubyB0 ZWNobmljYWwgY2hhbmdlcy4gQmVsb3cgYXJlIHRoZSBjaGFuZ2VzLg0KDQoNCg0KMS4gICAgICAg VGFrZW4gY2FyZSBvZiBhbGwgcmV2aWV3IGNvbW1lbnRzLg0KDQoyLiAgICAgICDigJxGdWxsL3Bh cnRpYWwgcmVhY2hhYmlsaXR54oCdIGlzIHJlbW92ZWQgYW5kIGZvY3VzIGlzIG9uIHRoZSByZWFj aGFiaWxpdHkuDQoNCjMuICAgICAgIFNQUklORyBkZXBlbmRlbmN5IGlzIHJlbW92ZWQuDQoNCjQu ICAgICAgIElQIHNwZWNpZmljIGRldGFpbHMgaGFzIGJlZW4gbW92ZWQgdG8gImRyYWZ0LWFraXlh LWJmZC1zZWFtbGVzcy0gaXAiLg0KDQo1LiAgICAgICBDb25zaXN0ZW50IHRlcm1pbm9sb2d5Lg0K DQo2LiAgICAgICBMb3RzIG9mIHJlcGhyYXNpbmcgZm9yIGJldHRlciByZWFkYWJpbGl0eS4NCg0K DQoNClRoYW5rcw0KDQpTYW50b3NoIFAgSw0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgSnVuZSAyNiwgMjAxNCAxMTo1NiBQTQ0KVG86 IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnPg0KQ2M6 IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWJmZC1zZWFtbGVzcy1iYXNlLTAxLnR4dA0KDQoNCg0KDQoNCkEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0 LURyYWZ0cyBkaXJlY3Rvcmllcy4NCg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUg QmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiBXb3JraW5nIEdyb3VwIG9mIHRoZSBJ RVRGLg0KDQoNCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBTZWFtbGVzcyBCaWRpcmVjdGlv bmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChTLUJGRCkNCg0KICAgICAgICBBdXRob3JzICAgICAg ICAgOiBOb2JvIEFraXlhDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgQ2FybG9zIFBpZ25h dGFybw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgIERhdmUgV2FyZA0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgIE1hbmF2IEJoYXRpYQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAg IEp1bmlwZXIgTmV0d29ya3MNCg0KICAgICAgICAgICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRy YWZ0LWlldGYtYmZkLXNlYW1sZXNzLWJhc2UtMDEudHh0DQoNCiAgICAgICAgICAgICAgICBQYWdl cyAgICAgICAgICAgOiAxNw0KDQogICAgICAgICAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAx NC0wNi0yNg0KDQoNCg0KQWJzdHJhY3Q6DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIHNp bXBsaWZpZWQgbWVjaGFuaXNtIHRvIHVzZSBCaWRpcmVjdGlvbmFsDQoNCiAgIEZvcndhcmRpbmcg RGV0ZWN0aW9uIChCRkQpIHdpdGggbGFyZ2UgcG9ydGlvbnMgb2YgbmVnb3RpYXRpb24gYXNwZWN0 cw0KDQogICBlbGltaW5hdGVkLCB0aHVzIHByb3ZpZGluZyBiZW5lZml0cyBzdWNoIGFzIHF1aWNr IHByb3Zpc2lvbmluZyBhcw0KDQogICB3ZWxsIGFzIGltcHJvdmVkIGNvbnRyb2wgYW5kIGZsZXhp YmlsaXR5IHRvIG5ldHdvcmsgbm9kZXMgaW5pdGlhdGluZw0KDQogICB0aGUgcGF0aCBtb25pdG9y aW5nLg0KDQoNCg0KICAgVGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQzU4ODAuDQoNCg0KDQoNCg0K DQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0K DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWJmZC1zZWFtbGVz cy1iYXNlLw0KDQoNCg0KVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUg YXQ6DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLXNlYW1sZXNz LWJhc2UtMDENCg0KDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWls YWJsZSBhdDoNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1i ZmQtc2VhbWxlc3MtYmFzZS0wMQ0KDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCg0KDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnlt b3VzIEZUUCBhdDoNCg0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KDQo= --_000_CECE764681BE964CBE1DFF78F3CDD3941E251864xmbalnx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAy IDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwg bGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYu TXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJh bGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2MTUzMjc5 NTk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjgxNDM4 Mjk1NiAyNzIyODcxOTYgMjY5MDI1MjgzIDI2OTAyNTI4NSAyNjkwMjUyODEgMjY5MDI1MjgzIDI2 OTAyNTI4NSAyNjkwMjUyODEgMjY5MDI1MjgzIDI2OTAyNTI4NTt9DQpAbGlzdCBsMDpsZXZlbDEN Cgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJN UyBNaW5jaG8iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0 LWlkOjkzMjA1NzE1MDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6ODgxODU0NDI0IDEzMjQ5Mzc2MjYgMjY5MDI1MjgzIDI2OTAyNTI4NSAyNjkwMjUyODEg MjY5MDI1MjgzIDI2OTAyNTI4NSAyNjkwMjUyODEgMjY5MDI1MjgzIDI2OTAyNTI4NTt9DQpAbGlz dCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwy DQoJe21zby1saXN0LWlkOjEyMjcxODYwNTE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjUzNjkzMjk3NiAtMTIyOTQzMjUwOCAyNjkwMjUyODMgMjY5MDI1 Mjg1IDI2OTAyNTI4MSAyNjkwMjUyODMgMjY5MDI1Mjg1IDI2OTAyNTI4MSAyNjkwMjUyODMgMjY5 MDI1Mjg1O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQ0EiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIj OTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGVsbG8gQkZEZXJzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WWVzLCBtYW55IHRoYW5rcyB0byB0aG9zZSBwcm92aWRl ZCBjb21tZW50cyBvbiBTLUJGRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PkNvdXBsZSBvZiBhZGRpdGlvbmFsIHRoaW5nczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPmRyYWZ0LWlldGYtYmZkLXNlYW1sZXNzLWJhc2UtMDE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvMyI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Db250YWlucyBzaWduaWZpY2Fu dCBjaGFuZ2VzIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzMiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlcmUgc2hvdWxkIG5vdCBiZSBhbnkg dGVjaG5pY2FsIGNoYW5nZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2ZWwx IGxmbzMiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+R3JlYXRseSBzZWVraW5nIGNvbW1lbnRzIG9uIGhvdyB3ZSBtb3ZlIGZv cndhcmQgd2l0aCBTLUJGRCBkaXNjcmltaW5hdG9yIHVuaXF1ZW5lc3MgcmVxdWlyZW1lbnRzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ZHJhZnQtYWtpeWEtYmZkLXNlYW1s ZXNzLWlwLTAzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzMiPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+SnVzdCBwdWJsaXNoZWQsIGxpbmtzIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwyIGxldmVsMSBsZm8zIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNlZWtpbmcgY29tbWVudHMgb24gd2hldGhl ciB3ZSB3YW50IHRvIGRlZmluZSBhIG5ldyBhc3NvY2lhdGVkIGNoYW5uZWwgdHlwZSBmb3IgUy1C RkQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPlVSTDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWlwLTAzLnR4dCI+DQpo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ha2l5YS1iZmQtc2VhbWxl c3MtaXAtMDMudHh0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ha2l5YS1iZmQt c2VhbWxlc3MtaXAvIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFr aXlhLWJmZC1zZWFtbGVzcy1pcC88L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5IdG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNz LWlwLTAzIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFraXlhLWJmZC1zZWFt bGVzcy1pcC0wMzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkRp ZmY6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWFr aXlhLWJmZC1zZWFtbGVzcy1pcC0wMyI+DQpodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtaXAtMDM8L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPi1O b2JvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+U2FudG9zaCBQIEs8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bmUgMjYs IDIwMTQgMzowMyBQTTxicj4NCjxiPlRvOjwvYj4gcnRnLWJmZEBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSRTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1iZmQtc2VhbWxlc3MtYmFzZS0w MS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+SGVsbG8gQWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsg Uy1CRkQgdmVyc2lvbiAxIGlzIHB1Ymxpc2hlZC4gVGhhbmtzIHRvIGFsbCB3aG8gaGFkIHByb3Zp ZGVkIGNvbW1lbnRzLiAmbmJzcDtEaWZmIGJldHdlZW4gdmVyc2lvbiAwIGFuZCAxIGlzIHNpZ25p ZmljYW50IGJ1dCB0aGVyZSBhcmUgbm8gdGVjaG5pY2FsIGNoYW5nZXMuIEJlbG93IGFyZSB0aGUg Y2hhbmdlcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1 aW4iPjxzcGFuIGxhbmc9IkVOLVVTIj4xLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5UYWtlbiBjYXJlIG9mIGFsbCByZXZpZXcgY29tbWVu dHMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gbGFuZz0iRU4tVVMi PjIuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPuKAnEZ1bGwvcGFydGlhbCByZWFjaGFiaWxpdHnigJ0gaXMgcmVtb3ZlZCBhbmQgZm9jdXMg aXMgb24gdGhlIHJlYWNoYWJpbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW4i PjxzcGFuIGxhbmc9IkVOLVVTIj4zLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5TUFJJTkcgZGVwZW5kZW5jeSBpcyByZW1vdmVkLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gbGFuZz0iRU4tVVMiPjQuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPklQIHNw ZWNpZmljIGRldGFpbHMgaGFzIGJlZW4gbW92ZWQgdG8gJnF1b3Q7ZHJhZnQtYWtpeWEtYmZkLXNl YW1sZXNzLSBpcCZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFu IGxhbmc9IkVOLVVTIj41Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj5Db25zaXN0ZW50IHRlcm1pbm9sb2d5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3Rl eHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gbGFuZz0iRU4tVVMiPjYuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPkxvdHMgb2YgcmVwaHJhc2lu ZyBmb3IgYmV0dGVyIHJlYWRhYmlsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlNhbnRvc2ggUCBLPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpG cm9tOiBSdGctYmZkIFs8YSBocmVmPSJtYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIj5t YWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mDQo8YSBocmVm PSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc8L2E+PGJyPg0KU2VudDogVGh1cnNkYXksIEp1bmUgMjYsIDIwMTQgMTE6NTYgUE08YnI+DQpU bzogPGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyI+aS1kLWFubm91bmNlQGll dGYub3JnPC9hPjxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyI+cnRn LWJmZEBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWJm ZC1zZWFtbGVzcy1iYXNlLTAxLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5l IEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBkcmFmdCBpcyBhIHdv cmsgaXRlbSBvZiB0aGUgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiBXb3JraW5n IEdyb3VwIG9mIHRoZSBJRVRGLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRpdGxlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogU2VhbWxlc3MgQmlkaXJl Y3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoUy1CRkQpPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBdXRob3JzJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogTm9ibyBBa2l5YTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2FybG9zIFBpZ25hdGFybzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGF2ZSBXYXJkPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNYW5hdiBCaGF0aWE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEp1bmlwZXIgTmV0d29ya3M8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpbGVuYW1lJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogZHJhZnQtaWV0Zi1iZmQtc2Vh bWxlc3MtYmFzZS0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFBhZ2VzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDogMTc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IERhdGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgOiAyMDE0LTA2LTI2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5B YnN0cmFjdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIHNp bXBsaWZpZWQgbWVjaGFuaXNtIHRvIHVzZSBCaWRpcmVjdGlvbmFsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZu YnNwOyBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSB3aXRoIGxhcmdlIHBvcnRpb25zIG9mIG5l Z290aWF0aW9uIGFzcGVjdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGVsaW1pbmF0ZWQsIHRodXMg cHJvdmlkaW5nIGJlbmVmaXRzIHN1Y2ggYXMgcXVpY2sgcHJvdmlzaW9uaW5nIGFzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyZuYnNwOyB3ZWxsIGFzIGltcHJvdmVkIGNvbnRyb2wgYW5kIGZsZXhpYmlsaXR5IHRv IG5ldHdvcmsgbm9kZXMgaW5pdGlhdGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgdGhlIHBhdGgg bW9uaXRvcmluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBUaGlzIGRv Y3VtZW50IHVwZGF0ZXMgUkZDNTg4MC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug Zm9yIHRoaXMgZHJhZnQgaXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYmZkLXNlYW1sZXNzLWJhc2UvIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1iZmQtc2VhbWxlc3MtYmFzZS88L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBh dmFpbGFibGUgYXQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtYmZkLXNlYW1sZXNzLWJhc2UtMDEiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWJmZC1zZWFtbGVzcy1iYXNlLTAxPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBh dDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtaWV0Zi1iZmQtc2VhbWxlc3MtYmFzZS0wMSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWlldGYtYmZkLXNlYW1sZXNzLWJhc2UtMDE8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFp bGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iZnRwOi8vZnRwLmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy8iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3Rl eHQtZGVjb3JhdGlvbjpub25lIj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwv c3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CECE764681BE964CBE1DFF78F3CDD3941E251864xmbalnx01ciscoc_-- From nobody Thu Jun 26 23:32:52 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F89F1B2A92; Thu, 26 Jun 2014 23:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr9c4K6L89h2; Thu, 26 Jun 2014 23:32:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 964511B315F; Thu, 26 Jun 2014 23:32:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-mpls-mib-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140627063246.21220.44777.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 23:32:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Bc9w3tx7SADmemeXmCuSl7ZNlGA Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 06:32:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD Management Information Base (MIB) extensions for MPLS and MPLS-TP Networks Authors : Sam Aldrin Venkatesan Mahalingam Kannan KV Sampath Thomas D. Nadeau Filename : draft-ietf-bfd-mpls-mib-04.txt Pages : 22 Date : 2014-06-26 Abstract: This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it extends the BFD Management Information Base BFD- STD-MIB and describes the managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol for MPLS and MPLS-TP networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-mpls-mib-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-mpls-mib-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jun 29 15:24:58 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B0A1A0032 for ; Sun, 29 Jun 2014 15:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUFvfK4pu8Ot for ; Sun, 29 Jun 2014 15:24:55 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4261A0031 for ; Sun, 29 Jun 2014 15:24:54 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 7948F2AA0F; Sun, 29 Jun 2014 22:24:51 +0000 (GMT) Date: Sun, 29 Jun 2014 15:24:50 -0700 From: Marc Binderberger To: Nobo Akiya (nobo) , Santosh P K Message-ID: <20140629152450732481.c07ee0d4@sniff.de> In-Reply-To: References: <20140626182533.30391.72279.idtracker@ietfa.amsl.com> <8fe58c80d3ba4e0da4da3e82cf7677dc@BLUPR05MB755.namprd05.prod.outlook.com> Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-13 Content-Transfer-Encoding: quoted-printable X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/8opnUqR5sUFt99cmvCDFeyC7ur0 Cc: "rtg-bfd@ietf.org" , "Marc Binderberger \(mbinderb\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 22:24:57 -0000 Hello Santosh and Nobo, good stuff. Every time I read it I find something new to learn :-) Re-reading the draft I had a few thoughts: 1) the draft is a "base" but it actually defines some details I would have= =20 expected in other drafts. One example is the IP/UDP header. Yes, IP is=20 everywhere but what about applications where you don't require IP ? Or the= =20 other way around: why having an extra "bfd-seamless-ip" draft when IP/UDP i= s=20 an essential part of the base draft?=20 2) similar the details of the state machine is something I think you do not= =20 really need in the base draft (!). Just define the reflector as truly=20 reflecting the state from the incoming packet (plus overwrite with AdminDow= n)=20 and you then leave it to the initiator if it uses a new state machine or th= e=20 5880 Down-Init-Up sequence or something completely different. S-BFD is largely about the reflector, I would say. Your draft brings up a= =20 good point: the state machine details are not relevant for interop as long = as=20 it stays within the definition of the reflector. 3) Actually I do not agree with statements in the draft about the 5880 stat= e=20 machine "may not be applicable" or that your proposal is better suited for= =20 the initial delay to bring BFD sessions up. Your state machine requires=20 RTT + Tr=20 the original 5880 takes 2 * (RTT + Tr). (RTT: Round Trip Time, Tr: the processing time of the reflector) True, that is faster ;-) but I'm not sure you had this in mind. And if=20 O(RTT+Tr) is relevant then you _do_ have a "considerable" delay too and are= =20 not "seamless" anymore :-) 4) The D-Flag ... forgot what I wanted to say :-) Mainly, if you define th= e=20 behaviour you expect on the reflector then you don't need to make any=20 statements or attempts to be "5880 compliant". > - Greatly seeking comments on how we move forward with S-BFD=20 > discriminator uniqueness requirements. You mean how to be unique? Or if uniqueness is necessary? For the "how", I propose that a manual option to set a "unique discriminato= r"=20 is a requirement. Does not exclude smarter, automatic methods but it gets y= ou=20 started. Every implementation must allow to configure a unique value within the leas= t=20 significant M bits of the discriminator. M is implementation specific,=20 recommendation is M >=3D 16. So yes, this wouldn't be the router-id then bu= t a=20 bfd-id. Pardon, sbfd_id ;-) Regards, Marc On Thu, 26 Jun 2014 23:32:03 +0000, Nobo Akiya (nobo) wrote: > Hello BFDers, > =20 > Yes, many thanks to those provided comments on S-BFD. > =20 > Couple of additional things: > =20 > draft-ietf-bfd-seamless-base-01 > - Contains significant changes from the previous version. > - There should not be any technical changes. > - Greatly seeking comments on how we move forward with S-BFD=20 > discriminator uniqueness requirements. > =20 > draft-akiya-bfd-seamless-ip-03 > - Just published, links below. > - Seeking comments on whether we want to define a new associated= =20 > channel type for S-BFD. > =20 > URL: =20 > http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamless-ip-03.txt > Status: =20 > https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ > Htmlized: http://tools.ietf.org/html/draft-akiya-bfd-seamless-ip-03 > Diff: =20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-bfd-seamless-ip-03 > =20 > Thanks! > =20 > -Nobo > =20 > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K > Sent: Thursday, June 26, 2014 3:03 PM > To: rtg-bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt > =20 > Hello All, > S-BFD version 1 is published. Thanks to all who had provided comments= . =20 > Diff between version 0 and 1 is significant but there are no technical=20 > changes. Below are the changes. > =20 > 1. Taken care of all review comments. > 2. =B4Full/partial reachability=A1 is removed and focus is on the= =20 > reachability. > 3. SPRING dependency is removed. > 4. IP specific details has been moved to "draft-akiya-bfd-seamless-= =20 > ip". > 5. Consistent terminology. > 6. Lots of rephrasing for better readability. > =20 > Thanks > Santosh P K > =20 > =20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 > internet-drafts@ietf.org > Sent: Thursday, June 26, 2014 11:56 PM > To: i-d-announce@ietf.org > Cc: rtg-bfd@ietf.org > Subject: I-D Action: draft-ietf-bfd-seamless-base-01.txt > =20 > =20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Bidirectional Forwarding Detection Worki= ng=20 > Group of the IETF. > =20 > Title : Seamless Bidirectional Forwarding Detection=20 > (S-BFD) > Authors : Nobo Akiya > Carlos Pignataro > Dave Ward > Manav Bhatia > Juniper Networks > Filename : draft-ietf-bfd-seamless-base-01.txt > Pages : 17 > Date : 2014-06-26 > =20 > Abstract: > This document defines a simplified mechanism to use Bidirectional > Forwarding Detection (BFD) with large portions of negotiation aspects > eliminated, thus providing benefits such as quick provisioning as > well as improved control and flexibility to network nodes initiating > the path monitoring. > =20 > This document updates RFC5880. > =20 > =20 > =20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ > =20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-bfd-seamless-base-01 > =20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-seamless-base-01 > =20 > =20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. > =20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > =20 From nobody Mon Jun 30 08:57:38 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2343A1A0389 for ; Mon, 30 Jun 2014 08:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.32 X-Spam-Level: X-Spam-Status: No, score=-0.32 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLXgooCCY37O for ; Mon, 30 Jun 2014 08:57:34 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0241A035C for ; Mon, 30 Jun 2014 08:57:34 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id F223AC1F9; Mon, 30 Jun 2014 11:57:33 -0400 (EDT) Date: Mon, 30 Jun 2014 11:57:33 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Reminder: IETF 90 important dates Message-ID: <20140630155733.GW11842@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/CERMh6hOxPEvAtN2tvWYhHq-TY0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2014 15:57:35 -0000 2014-07-04 (Friday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool. If you're presenting, you're expected to have a draft posted. :-) -- Jeff From nobody Mon Jun 30 09:38:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFDA1A03BB for ; Mon, 30 Jun 2014 09:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbIFieJgz_X3 for ; Mon, 30 Jun 2014 09:38:46 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CDCAB1A03AD for ; Mon, 30 Jun 2014 09:38:46 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 76C27C1F9; Mon, 30 Jun 2014 12:38:46 -0400 (EDT) Date: Mon, 30 Jun 2014 12:38:46 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Working Group Last Call for draft-ietf-bfd-intervals (ending July 15) Message-ID: <20140630163846.GA11842@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/_5IMu8tZjGv9SJwdH-_sRlBayLA X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2014 16:38:48 -0000 Working Group, We would like to initiate the start of Working Group Last Call for Common Interval Support in BFD: http://tools.ietf.org/html/draft-ietf-bfd-intervals-01 Note that the intended status of this document is INFORMATIONAL. Please send your comments, including whether you think the draft is ready for publication or not, to the list no later than July 15. -- Jeff and Nobo From nobody Mon Jun 30 10:44:08 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D91C1A03E5 for ; Mon, 30 Jun 2014 10:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3i49OvWeTAW for ; Mon, 30 Jun 2014 10:44:02 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B091A03C9 for ; Mon, 30 Jun 2014 10:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1863; q=dns/txt; s=iport; t=1404150242; x=1405359842; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=OrSNtjNOYCC4xYlxLG5uFT64DQz+Z/zMBZSJmjEnODQ=; b=EB7Uo2Im32YXO1bdOvd7HtCqy51X37Mz38BAPNx6//1pfiEsOtCQ0cMo zeBkW0SFmWVZnaRnb6ESbTPU0lAxo2FinkEv12f+hTf/DuGMPCYy85sBW NQcpvRNprwVKpK12svO5Aswni237LuLWqJ/2ZK7m4d5EWgLTeq+wkKFBf w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAAShsVOtJA2J/2dsb2JhbABagmkkUlrFWwGBERZ1hAUBBDo/EgEqFEImAQQOBQgBiDkBDMgeF44lEQEfMYM0gRYFrluDQoF3OQ X-IronPort-AV: E=Sophos;i="5.01,576,1400025600"; d="scan'208";a="336767550" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP; 30 Jun 2014 17:44:01 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5UHi08r009745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 17:44:00 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 12:44:00 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: [Tentative] BFD WG Agenda for IETF90 Thread-Topic: [Tentative] BFD WG Agenda for IETF90 Thread-Index: Ac+UiZAWL5Mu2kjMROSJ/nHy59ZzAw== Date: Mon, 30 Jun 2014 17:44:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/X1IX57qFgu_PM--ABopWMvcHzwM Cc: "Jeff Haas \(jhaas@juniper.net\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2014 17:44:04 -0000 Hello BFDers, Tentative BFD WG Agenda for IETF90 has been posted. http://www.ietf.org/proceedings/90/agenda/agenda-90-bfd (tentative agenda also pasted below for easier reference) If: - Your presentation information is not accurate; - Your presentation information is missing; - You do not agree with the agenda or a specific presentation listed; please provide your comment via replying to this thread (with WG list inclu= ded or just the chairs). Reminder to presenters: Please email your slides to the chairs no later than 2014-07-14 (Monday). Thanks! -Nobo and Jeff IETF 90 - BFD WG Meeting Session Agenda MONDAY, July 21, 2014 1520-1650 Afternoon Session II Salon B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D CHAIR(s): Jeffrey Haas Nobo Akiya - WG Statuses and Administrivia 15 minutes Presenter Co-chairs - BFD Proxy for Connections over Monitored Links 10 minutes Draft draft-snyder-bfd-proxy-connections-monitored-links-00 Presenter Brian Snyder - BFD Stability 10 minutes Draft draft-ashesh-bfd-stability-00 Presenter Ashesh Mishra - Seamless BFD Use-Case 10 minutes Draft draft-ietf-bfd-seamless-use-case-00 Presenter Sam K. Aldrin - Seamless BFD Base/IP 10 minutes Draft draft-ietf-bfd-seamless-base-01 draft-akiya-bfd-seamless-ip-03 Presenter Nobo Akiya - L2VPN EVPN BFD 10 minutes Draft draft-vgovindan-l2vpn-evpn-bfd-02 Presenter Vengada Prasad Govindan From nobody Mon Jun 30 16:18:06 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE421B279D for ; Mon, 30 Jun 2014 16:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPZmeJVgq9Qe for ; Mon, 30 Jun 2014 16:18:02 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2771B2789 for ; Mon, 30 Jun 2014 16:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10413; q=dns/txt; s=iport; t=1404170282; x=1405379882; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+wdtfrF6Hg5QbR4/v18nXc5jrPh1C7Eu8LlavnGiDek=; b=YVGiOKw5+i9TW1kZ8IyN3iWLZUCwRTVDOVIyWCrX7RIDOtFKiOEbz9F+ j6IHH8nvhCS7ddbHqeGr1vZ816FWp6NqXXCc0UwWv36tlx+irppgIvmlw znZbyb5qu0wdESfD2uM7HYy+w3u3O+NNVYavLBLd0Iwk+HgRsf/OTjRp/ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQHAAbvsVOtJV2T/2dsb2JhbABagmkkUlMHxWEBgRAWdYQDAQEBAwE6PwUHBAIBCBEEAQEBChQJBzIUCQgCBAENBQgBiDEIAQcFyBIXjlYxBwaDJ4EWBZwkkjeDQmyBRA X-IronPort-AV: E=Sophos;i="5.01,578,1400025600"; d="scan'208";a="57274298" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP; 30 Jun 2014 23:18:01 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s5UNI157021862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 23:18:01 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 18:18:01 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger , Santosh P K Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt Thread-Topic: I-D Action: draft-ietf-bfd-seamless-base-01.txt Thread-Index: AQHPkW78JeCHvpBJ/EuFcrJj+qOrd5uEE1MA///0AsCABPuAAIABQrxw Date: Mon, 30 Jun 2014 23:18:00 +0000 Message-ID: References: <20140626182533.30391.72279.idtracker@ietfa.amsl.com> <8fe58c80d3ba4e0da4da3e82cf7677dc@BLUPR05MB755.namprd05.prod.outlook.com> <20140629152450732481.c07ee0d4@sniff.de> In-Reply-To: <20140629152450732481.c07ee0d4@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/WfgObOpg9r0UzHvivwz5D2iCEf8 Cc: "rtg-bfd@ietf.org" , "Marc Binderberger \(mbinderb\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2014 23:18:04 -0000 Hi Marc, > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Sunday, June 29, 2014 6:25 PM > To: Nobo Akiya (nobo); Santosh P K > Cc: rtg-bfd@ietf.org; Marc Binderberger (mbinderb) > Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt >=20 > Hello Santosh and Nobo, >=20 > good stuff. Every time I read it I find something new to learn :-) As always, thanks for comments! >=20 > Re-reading the draft I had a few thoughts: >=20 > 1) the draft is a "base" but it actually defines some details I would hav= e > expected in other drafts. One example is the IP/UDP header. Yes, IP is > everywhere but what about applications where you don't require IP ? Or > the other way around: why having an extra "bfd-seamless-ip" draft when > IP/UDP is an essential part of the base draft? One of the changes from draft-ietf-bfd-seamless-base-00 to draft-ietf-bfd-s= eamless-base-01 to take out all IP related procedures and move it over to d= raft-akiya-bfd-seamless-base-ip-03. Intent of the authors is to: 1) Focus s-bfd-base on the procedures for UDP header and BFD header. 2) Focus s-bfd-ip on the procedures for IP header and MPLS. 3) Add ip-less procedures (i.e. associated channel) in either s-bfd-ip or c= reate a separate draft (i.e. s-bfd-ip-less). 4) s-bfd-sr to be worked on at a later time. Since we are only defining one port for S-BFD, this made sense to those who= worked on the recent changes to the S-BFD documents. Yes there are alternative ways to structure the documents. That being said,= it would be helpful to hear "yeah above is reasonable" or "let's structure= it this way" from you and the WG. >=20 >=20 > 2) similar the details of the state machine is something I think you do n= ot > really need in the base draft (!). Just define the reflector as truly ref= lecting > the state from the incoming packet (plus overwrite with AdminDown) and > you then leave it to the initiator if it uses a new state machine or the > 5880 Down-Init-Up sequence or something completely different. This comment looks familiar :) Texts above the state machine now says: For persistent SBFDInitiators, the states and the state machine described in [RFC5880] will function but are more than necessary. The following diagram provides an optimized state machine for persistent SBFDInitiators. And after the diagram: Note that the above state machine is different from the base BFD specification[RFC5880]. This is because the Init state is no longer applicable for the SBFDInitiator. Another important difference is the transition of the state machine from the Down state to the Up state when a packet with State Up is received by the initiator. =20 I think the texts and the described state machine is helpful for reader to = better understand how S-BFD operates. So I prefer that this section remains= somewhere to give better ideas to readers on how SBFDInitiators can be imp= lemented. So, I think we have few options. - Texts in the s-bfd-base-01 is sufficiently reasonable. - Further texts should be added to make it more obvious that describe state= machine is not mandatory. - Move the SBFDInitiator State Machine section to appendix. Thoughts? >=20 > S-BFD is largely about the reflector, I would say. Your draft brings up a= good > point: the state machine details are not relevant for interop as long as = it > stays within the definition of the reflector. Yes I agree. >=20 >=20 > 3) Actually I do not agree with statements in the draft about the 5880 st= ate > machine "may not be applicable" or that your proposal is better suited fo= r > the initial delay to bring BFD sessions up. Your state machine requires >=20 > RTT + Tr >=20 > the original 5880 takes >=20 > 2 * (RTT + Tr). >=20 > (RTT: Round Trip Time, Tr: the processing time of the reflector) >=20 > True, that is faster ;-) but I'm not sure you had this in mind. And if > O(RTT+Tr) is relevant then you _do_ have a "considerable" delay too and a= re > not "seamless" anymore :-) True, but you forgot the aspect of: BFD: - in case of MPLS, LSP ping bootstraps the session on egress - session is created - tx timer is started at no faster than 1 second S-BFD: - no LSP ping bootstrapping - session is created - packet can get tx'ed right away >From above aspect, "considerable" delay (i.e. couple of seconds) is shaved = off :) >=20 >=20 > 4) The D-Flag ... forgot what I wanted to say :-) LOL, I do that often too. > 4) The D-Flag ... forgot what I wanted to say :-) LOL, I do that often too. > 4) The D-Flag ... forgot what I wanted to say :-) Wait, didn't I reply to this already? :) > Mainly, if you define the > behaviour you expect on the reflector then you don't need to make any > statements or attempts to be "5880 compliant". Agree, I don't think S-BFD is trying to be compliant with RFC5880, but S-BF= D is trying to keep as much the same semantics possible with BFD so that we= are not re-inventing everything. >=20 >=20 > > - Greatly seeking comments on how we move forward with S-BFD > > discriminator uniqueness requirements. >=20 > You mean how to be unique? Or if uniqueness is necessary? > For the "how", I propose that a manual option to set a "unique > discriminator" > is a requirement. Does not exclude smarter, automatic methods but it gets > you started. Agree, this seems to be the direction we are heading, and I think it is rea= sonable. However, I (we?) do see a need for auto-foo, where foo may be "S-B= FD discriminator allocation", "collision detection", "collision correction"= or combination of them. >=20 > Every implementation must allow to configure a unique value within the > least significant M bits of the discriminator. M is implementation specif= ic, > recommendation is M >=3D 16. So yes, this wouldn't be the router-id then = but > a bfd-id. Pardon, sbfd_id ;-) For connectivity (i.e. reachability) test purpose, a system will need one s= bfd-id [or more]. For other applications of S-BFD, there may be a need for = a system to allocate few tens of S-BFD discriminators. So, this really plac= es more weight on the "uniqueness" requirement and the need for auto-foo. Thanks! -Nobo >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On Thu, 26 Jun 2014 23:32:03 +0000, Nobo Akiya (nobo) wrote: > > Hello BFDers, > > > > Yes, many thanks to those provided comments on S-BFD. > > > > Couple of additional things: > > > > draft-ietf-bfd-seamless-base-01 > > - Contains significant changes from the previous version. > > - There should not be any technical changes. > > - Greatly seeking comments on how we move forward with S-BFD > > discriminator uniqueness requirements. > > > > draft-akiya-bfd-seamless-ip-03 > > - Just published, links below. > > - Seeking comments on whether we want to define a new associated > > channel type for S-BFD. > > > > URL: > > http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamless-ip-03.txt > > Status: > > https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ > > Htmlized: http://tools.ietf.org/html/draft-akiya-bfd-seamless-ip-= 03 > > Diff: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-bfd-seamless-ip-03 > > > > Thanks! > > > > -Nobo > > > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P > > K > > Sent: Thursday, June 26, 2014 3:03 PM > > To: rtg-bfd@ietf.org > > Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt > > > > Hello All, > > S-BFD version 1 is published. Thanks to all who had provided commen= ts. > > Diff between version 0 and 1 is significant but there are no technical > > changes. Below are the changes. > > > > 1. Taken care of all review comments. > > 2. "Full/partial reachability" is removed and focus is on the > > reachability. > > 3. SPRING dependency is removed. > > 4. IP specific details has been moved to "draft-akiya-bfd-seamles= s- > > ip". > > 5. Consistent terminology. > > 6. Lots of rephrasing for better readability. > > > > Thanks > > Santosh P K > > > > > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: Thursday, June 26, 2014 11:56 PM > > To: i-d-announce@ietf.org > > Cc: rtg-bfd@ietf.org > > Subject: I-D Action: draft-ietf-bfd-seamless-base-01.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Bidirectional Forwarding Detection > > Working Group of the IETF. > > > > Title : Seamless Bidirectional Forwarding Detection > > (S-BFD) > > Authors : Nobo Akiya > > Carlos Pignataro > > Dave Ward > > Manav Bhatia > > Juniper Networks > > Filename : draft-ietf-bfd-seamless-base-01.txt > > Pages : 17 > > Date : 2014-06-26 > > > > Abstract: > > This document defines a simplified mechanism to use Bidirectional > > Forwarding Detection (BFD) with large portions of negotiation aspect= s > > eliminated, thus providing benefits such as quick provisioning as > > well as improved control and flexibility to network nodes initiating > > the path monitoring. > > > > This document updates RFC5880. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-bfd-seamless-base-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-seamless-base-01 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > From nobody Mon Jun 30 17:14:57 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB561A040F for ; Mon, 30 Jun 2014 17:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlXV1eIliWuX for ; Mon, 30 Jun 2014 17:14:54 -0700 (PDT) Received: from BAY004-OMC4S11.hotmail.com (bay004-omc4s11.hotmail.com [65.54.190.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883701A0149 for ; Mon, 30 Jun 2014 17:14:54 -0700 (PDT) Received: from BAY176-W40 ([65.54.190.199]) by BAY004-OMC4S11.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Mon, 30 Jun 2014 17:14:54 -0700 X-TMN: [04QTP7vG8Ds+PsGwfuNNQ6owsHdOh6o+] X-Originating-Email: [mishra.ashesh@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_71314819-5e8e-4c60-a066-f47764e1f380_" From: Ashesh Mishra To: "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-ashesh-bfd-stability-00.txt Date: Mon, 30 Jun 2014 17:14:54 -0700 Importance: Normal In-Reply-To: References: <20140630233047.16868.79679.idtracker@ietfa.amsl.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 01 Jul 2014 00:14:54.0480 (UTC) FILETIME=[7BDE5100:01CF94C1] Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/HiGXEv2-zGOQBt0UzD5TIUvvkhQ X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 00:14:56 -0000 --_71314819-5e8e-4c60-a066-f47764e1f380_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone. The first version of the BFD-Stability draft has been posted. Thanks to eve= ryone who contributed to the creation of this document.=20 There are still two issues that are being discussed and are yet to be resol= ved: - Sequence Number Handling: What's mentioned in the document made sense for= one =0A= particular implementation. However=2C that mechanism can be refined further= and needs more discussion on what the behavior=0A= should be. I encourage you to continue the =0A= discussion on this issue. We should have enough time before the Toronto =0A= meeting to update the section. =0A= - TLV-Type Identification: This issue revolves around how to distinguish = =0A= the three types of TLVs described in this draft (using length=2C auth-key-i= d=2C reserved bits=2C or =0A= some other identifier). The logic for using length was that it can be =0A= interpreted in different ways to maintain compatibility with different impl= ementations. If one node is transmitting a =0A= fully-loaded TLV (seqNum and two timestamps) and the peer is not capable=0A= of handling some parts of that TLV=2C it can choose to process the TLV in= =0A= only IFG mode. That said=2C we can discuss this over time and update the = =0A= document before the meeting.=20 Looking forward to your comments and suggestions. Thanks=2C Ashesh Mishra From: =0A= =0A= Date: Mon=2C Jun 30=2C 2014 at 4:30 PM Subject: New Version Notification for draft-ashesh-bfd-stability-00.txt To: Mach Chen =2C Ankur Saxena =2C Mahesh Jethanandani =2C Santosh Pallagatti <= santoshpk@juniper.net>=2C Ashesh Mishra =0A= =0A= =0A= A new version of I-D=2C draft-ashesh-bfd-stability-00.txt =0A= has been successfully submitted by Ashesh Mishra and posted to the =0A= IETF repository. =0A= =0A= Name: draft-ashesh-bfd-stability =0A= Revision: 00 =0A= Title: BFD Stability =0A= Document date: 2014-06-30 =0A= Group: Individual Submission =0A= Pages: 7 =0A= URL: http://www.ietf.org/internet-drafts/draft-ashesh-bfd-stabil= ity-00.txt =0A= Status: https://datatracker.ietf.org/doc/draft-ashesh-bfd-stability= / =0A= Htmlized: http://tools.ietf.org/html/draft-ashesh-bfd-stability-00 =0A= =0A= =0A= Abstract: =0A= This document describes extensions to the Bidirectional Forwarding =0A= Detection (BFD) protocol to measure BFD stability. Specifically=2C it =0A= describes a mechanism for detection of BFD frame loss=2C of delays in =0A= frame transmitter and receiver engines=2C and of inter-frame delays =0A= that might explain issues with a BFD session. =0A= =0A= =0A= =0A= =0A= =0A= Please note that it may take a couple of minutes from the time of submissio= n =0A= until the htmlized version and diff are available at tools.ietf.org. =0A= =0A= The IETF Secretariat =0A= =0A= = --_71314819-5e8e-4c60-a066-f47764e1f380_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi everyone.

The first ve= rsion of the BFD-Stability draft has been posted. Thanks to everyone who co= ntributed to the creation of this document.

There are still two iss= ues that are being discussed and are yet to be resolved:

- Sequence = Number Handling: What's mentioned in the document made sense for one =0A= particular implementation. However=2C that mechanism can be refined further= and needs more discussion on what the behavior=0A= should be. I encourage you to continue the =0A= discussion on this issue. We should have enough time before the Toronto =0A= meeting to update the section.
=0A=
- TLV-Type Identification: This issue revolves around how to distinguis= h =0A= the three types of TLVs described in this draft (using length=2C auth-key-i= d=2C reserved bits=2C or =0A= some other identifier). The logic for using length was that it can be =0A= interpreted in different ways to maintain compatibility with different impl= ementations. If one node is transmitting a =0A= fully-loaded TLV (seqNum and two timestamps) and the peer is not capable=0A= of handling some parts of that TLV=2C it can choose to process the TLV in= =0A= only IFG mode. That said=2C we can discuss this over time and update the = =0A= document before the meeting.

Looking forward to your comments and s= uggestions.

Thanks=2C
Ashesh =3B Mishra

From: <=3Binternet-drafts@ietf.org>=3B
=0A= =0A= Date: Mon=2C Jun 30=2C 2014 at 4:30 PM
Subject: New Version Notification= for draft-ashesh-bfd-stability-00.txt
To: Mach Chen <=3Bmach.chen@huawei.com>=3B=2C Ankur Saxena &= lt=3Bankurpsaxena@gmail.com&g= t=3B=2C Mahesh Jethanandani <=3Bmjethanandani@gmail.com>=3B=2C Santosh Pallagatti <=3Bsantoshpk@juniper.net>=3B=2C Ashesh Mis= hra <=3Bmishra.ashesh@gmail.co= m>=3B
=0A= =0A=


=0A= A new version of I-D=2C draft-ashesh-bfd-stability-00.txt
=0A= has been successfully submitted by Ashesh Mishra and posted to the
=0A= IETF repository.
=0A=
=0A= Name:  =3B  =3B  =3B  =3B  =3B draft-ashesh-bfd-stabili= ty
=0A= Revision:  =3B  =3B  =3B 00
=0A= Title:  =3B  =3B  =3B  =3B  =3BBFD Stability
=0A= Document date:  =3B2014-06-30
=0A= Group:  =3B  =3B  =3B  =3B  =3BIndividual Submission=0A= Pages:  =3B  =3B  =3B  =3B  =3B7
=0A= URL:  =3B  =3B  =3B  =3B  =3B  =3Bhttp://www.ietf.org/internet-drafts/draft-ashesh-bfd-stability-00.t= xt
=0A= Status:  =3B  =3B  =3B  =3B https://datatra= cker.ietf.org/doc/draft-ashesh-bfd-stability/
=0A= Htmlized:  =3B  =3B  =3B http://tools.ietf.org/html= /draft-ashesh-bfd-stability-00
=0A=
=0A=
=0A= Abstract:
=0A=  =3B  =3BThis document describes extensions to the Bidirectional Fo= rwarding
=0A=  =3B  =3BDetection (BFD) protocol to measure BFD stability.  = =3BSpecifically=2C it
=0A=  =3B  =3Bdescribes a mechanism for detection of BFD frame loss=2C o= f delays in
=0A=  =3B  =3Bframe transmitter and receiver engines=2C and of inter-fra= me delays
=0A=  =3B  =3Bthat might explain issues with a BFD session.
=0A=
=0A=
=0A=
=0A=
=0A=
=0A= Please note that it may take a couple of minutes from the time of submissio= n
=0A= until the htmlized version and diff are available at tools.ietf.org.
=0A=
=0A= The IETF Secretariat
=0A=
=0A=

= --_71314819-5e8e-4c60-a066-f47764e1f380_-- From nobody Mon Jun 30 17:42:48 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A211A0058 for ; Mon, 30 Jun 2014 17:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XS7aRSLaqhf3 for ; Mon, 30 Jun 2014 17:42:44 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 211711A004A for ; Mon, 30 Jun 2014 17:42:44 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id j17so9629622oag.39 for ; Mon, 30 Jun 2014 17:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Sk2tNykRb7F0RPkCDiPj+noU9Q9Gi/J+EE2nD251SE0=; b=D8ebdt9uNLxhCvpefebQmONhdDmxZgUO48OhaD9kTcAshOamc4vZJnsky8XI4j3G0p BrQwDNkXEM1tB5vfxk9+d6GR2PEZmQgXno7qU9/tATLbnfEmS9j+qIdBoTiYwfOKITjP 8rEbDsaMTn6tlwzvluYazrOnSr625dlm/e0d6beAMRn9XkbjOHhQEEto9/txegzu9YZx XKDc9bm8x08szmuhGvSscmbUl9srz1vnojcCDS55WjuVHvqd4MPQJ2YEQ0+UtI+BrNq6 zSddoK32FAFWKosmLIggywOOgt0d5j5T3orP6RHJx11KiYkYDxDOOTryLuchGfPxP0uC venw== MIME-Version: 1.0 X-Received: by 10.182.65.167 with SMTP id y7mr46254706obs.29.1404175361952; Mon, 30 Jun 2014 17:42:41 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Mon, 30 Jun 2014 17:42:41 -0700 (PDT) In-Reply-To: References: <20140630233047.16868.79679.idtracker@ietfa.amsl.com> Date: Tue, 1 Jul 2014 06:12:41 +0530 Message-ID: Subject: Re: New Version Notification for draft-ashesh-bfd-stability-00.txt From: Manav Bhatia To: Ashesh Mishra Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/D_39tIhF69m-4YG_JhljjrU6JvU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 00:42:46 -0000 Hi Ashesh, Security Considerations says: Since this method uses an authentication TLV to achive the functionality, usage of this TLV will prevent the use of other authentication TLVs. This is not acceptable. I would not like to see any proposal that precludes the possibility of adding authentication later -- your design stands on tenuous grounds as soon as you say this. I think it'll be much smarter to say that an implementation MAY carry multiple authentication TLVs, in which case, the outer one MUST carry the real authentication information. BTW, i dont feel great about overloading the authentication TLV with information thats completely unrelated to authentication. This breaks all HW that looks at this TLV and sends it for some special processing. You now require HW to peek deeper inside the TLV to know if its something that this would interest it or not. More comments once i go through the draft .. Cheers, Manav On Tue, Jul 1, 2014 at 5:44 AM, Ashesh Mishra wrote: > Hi everyone. > > The first version of the BFD-Stability draft has been posted. Thanks to > everyone who contributed to the creation of this document. > > There are still two issues that are being discussed and are yet to be > resolved: > > - Sequence Number Handling: What's mentioned in the document made sense for > one particular implementation. However, that mechanism can be refined > further and needs more discussion on what the behavior should be. I > encourage you to continue the discussion on this issue. We should have > enough time before the Toronto meeting to update the section. > > - TLV-Type Identification: This issue revolves around how to distinguish the > three types of TLVs described in this draft (using length, auth-key-id, > reserved bits, or some other identifier). The logic for using length was > that it can be interpreted in different ways to maintain compatibility with > different implementations. If one node is transmitting a fully-loaded TLV > (seqNum and two timestamps) and the peer is not capable of handling some > parts of that TLV, it can choose to process the TLV in only IFG mode. That > said, we can discuss this over time and update the document before the > meeting. > > Looking forward to your comments and suggestions. > > Thanks, > Ashesh Mishra > > ________________________________ > From: > Date: Mon, Jun 30, 2014 at 4:30 PM > Subject: New Version Notification for draft-ashesh-bfd-stability-00.txt > To: Mach Chen , Ankur Saxena , > Mahesh Jethanandani , Santosh Pallagatti > , Ashesh Mishra > > > > A new version of I-D, draft-ashesh-bfd-stability-00.txt > has been successfully submitted by Ashesh Mishra and posted to the > IETF repository. > > Name: draft-ashesh-bfd-stability > Revision: 00 > Title: BFD Stability > Document date: 2014-06-30 > Group: Individual Submission > Pages: 7 > URL: > http://www.ietf.org/internet-drafts/draft-ashesh-bfd-stability-00.txt > Status: https://datatracker.ietf.org/doc/draft-ashesh-bfd-stability/ > Htmlized: http://tools.ietf.org/html/draft-ashesh-bfd-stability-00 > > > Abstract: > This document describes extensions to the Bidirectional Forwarding > Detection (BFD) protocol to measure BFD stability. Specifically, it > describes a mechanism for detection of BFD frame loss, of delays in > frame transmitter and receiver engines, and of inter-frame delays > that might explain issues with a BFD session. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > From nobody Mon Jun 30 18:09:19 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4661A0078 for ; Mon, 30 Jun 2014 18:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rv0Dd-rN7-k5 for ; Mon, 30 Jun 2014 18:09:14 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332141A0064 for ; Mon, 30 Jun 2014 18:09:14 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-1c-53b1b5fc08b5 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8F.2B.25146.CF5B1B35; Mon, 30 Jun 2014 21:09:49 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Mon, 30 Jun 2014 21:09:12 -0400 From: Gregory Mirsky To: Ashesh Mishra , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-ashesh-bfd-stability-00.txt Thread-Topic: New Version Notification for draft-ashesh-bfd-stability-00.txt Thread-Index: AQHPlMGByMDiCCAb4ku6kaYC2EX7mpuKZhIA Date: Tue, 1 Jul 2014 01:09:12 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7E4A81@eusaamb103.ericsson.se> References: <20140630233047.16868.79679.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7E4A81eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXRPuO7frRuDDbbdYrKY1TaF1eLzn22M DkweS5b8ZPLY/PoFcwBTFJdNSmpOZllqkb5dAlfG+8tnmAraCyqOP7nO1sC4PrGLkZNDQsBE 4uayJjYIW0ziwr31QDYXh5DAUUaJ9hsNzBDOckaJ32+XM4FUsQkYSbzY2MMOYosIhEnsXr+D FcQWFvCWaD+6kwUi7iPx/u0WJgjbSGL50hNgcRYBFYmGjgdgcV4BX4kX+76xQyzYySixduJt ZpAEp4CVxK9/n8AaGIFO+n5qDVgDs4C4xK0n85kgThWQWLLnPDOELSrx8vE/VghbUWJf/3R2 iPp8iUtP1kItE5Q4OfMJywRGkVlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsv YGRfxchRWpxalptuZLiJERhBxyTYHHcwLvhkeYhRgINRiYdXwXRjsBBrYllxZe4hRmkOFiVx Xs3qecFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGAWiGWysLjj239BJf7vmh7Da4QunC5bs y+rUWfb/35EOrZp7BX+q+Q/Oj9uX97kjrjvUsvgly+5HG/rEa+OFnt1uexrDolO7KLOkLPba p9SP69cffmsjfcpHSemesLT23ceTVNNcbTkNXkYp2Z2N7fh28bV/WdnrDUs3vnqv+rgk7uBT Hl+ZU0osxRmJhlrMRcWJAFubHR2BAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/e1ckqV06r1XlGAQ5EjzlJ0zzWOA X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 01:09:17 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7E4A81eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ashesh, I'm not convinced that the goal stated in the document as quantify instabil= ity of the BFD control messages through measurement of inter-packet, a.k.a.= inter-frame gap is relevant to BFD. Note, that interval between BFD contro= l messages, according to RFC 5880 is jittered, i.e. randomized, as describe= d in Section 6.8.7 RFC 5880. Though it may be tempting to add performance measurements on top of BFD the= re are already OWAMP/TWAMP for IP PM and MPLS Packet Loss and Packet Delay = Measurement RFCs to use for measuring performance metrics. Regards, Greg From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Ashesh Mishra Sent: Monday, June 30, 2014 5:15 PM To: rtg-bfd@ietf.org Subject: RE: New Version Notification for draft-ashesh-bfd-stability-00.txt Hi everyone. The first version of the BFD-Stability draft has been posted. Thanks to eve= ryone who contributed to the creation of this document. There are still two issues that are being discussed and are yet to be resol= ved: - Sequence Number Handling: What's mentioned in the document made sense for= one particular implementation. However, that mechanism can be refined furt= her and needs more discussion on what the behavior should be. I encourage y= ou to continue the discussion on this issue. We should have enough time bef= ore the Toronto meeting to update the section. - TLV-Type Identification: This issue revolves around how to distinguish th= e three types of TLVs described in this draft (using length, auth-key-id, r= eserved bits, or some other identifier). The logic for using length was tha= t it can be interpreted in different ways to maintain compatibility with di= fferent implementations. If one node is transmitting a fully-loaded TLV (se= qNum and two timestamps) and the peer is not capable of handling some parts= of that TLV, it can choose to process the TLV in only IFG mode. That said,= we can discuss this over time and update the document before the meeting. Looking forward to your comments and suggestions. Thanks, Ashesh Mishra ________________________________ From: > Date: Mon, Jun 30, 2014 at 4:30 PM Subject: New Version Notification for draft-ashesh-bfd-stability-00.txt To: Mach Chen >, Ankur Sa= xena >, Mahesh Jethan= andani >, Santosh P= allagatti >, Ashesh Mis= hra > A new version of I-D, draft-ashesh-bfd-stability-00.txt has been successfully submitted by Ashesh Mishra and posted to the IETF repository. Name: draft-ashesh-bfd-stability Revision: 00 Title: BFD Stability Document date: 2014-06-30 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-ashesh-bfd-stabil= ity-00.txt Status: https://datatracker.ietf.org/doc/draft-ashesh-bfd-stability= / Htmlized: http://tools.ietf.org/html/draft-ashesh-bfd-stability-00 Abstract: This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD stability. Specifically, it describes a mechanism for detection of BFD frame loss, of delays in frame transmitter and receiver engines, and of inter-frame delays that might explain issues with a BFD session. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_7347100B5761DC41A166AC17F22DF1121B7E4A81eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ashesh,

I’m not convinced t= hat the goal stated in the document as quantify instability of the BFD cont= rol messages through measurement of inter-packet, a.k.a. inter-frame gap is relevant to BFD. Note, that interval between BFD control messages, = according to RFC 5880 is jittered, i.e. randomized, as described in Section= 6.8.7 RFC 5880.

 <= /p>

Though it may be tempting= to add performance measurements on top of BFD there are already OWAMP/TWAM= P for IP PM and MPLS Packet Loss and Packet Delay Measurement RFCs to use for measuring performance metrics.

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

 <= /p>

From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Ashesh Mishra
Sent: Monday, June 30, 2014 5:15 PM
To: rtg-bfd@ietf.org
Subject: RE: New Version Notification for draft-ashesh-bfd-stability= -00.txt

 

Hi everyone.

The first version of the BFD-Stability draft has been posted. Thanks to eve= ryone who contributed to the creation of this document.

There are still two issues that are being discussed and are yet to be resol= ved:

- Sequence Number Handling: What's mentioned in the document made sense for= one particular implementation. However, that mechanism can be refined furt= her and needs more discussion on what the behavior should be. I encourage y= ou to continue the discussion on this issue. We should have enough time before the Toronto meeting to updat= e the section.

- TLV-Type Identification: This issue revolves around how to distinguish th= e three types of TLVs described in this draft (using length, auth-key-id, r= eserved bits, or some other identifier). The logic for using length was tha= t it can be interpreted in different ways to maintain compatibility with different implementations. If one node= is transmitting a fully-loaded TLV (seqNum and two timestamps) and the pee= r is not capable of handling some parts of that TLV, it can choose to proce= ss the TLV in only IFG mode. That said, we can discuss this over time and update the document before the mee= ting.

Looking forward to your comments and suggestions.

Thanks,
Ashesh  Mishra

From: <in= ternet-drafts@ietf.org>

Date: Mon, Jun 30, 2014 a= t 4:30 PM
Subject: New Version Notification for draft-ashesh-bfd-stability-00.txt
To: Mach Chen <mach.chen@huawei.= com>, Ankur Saxena <ank= urpsaxena@gmail.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, Santosh Pallagatti <santoshpk@juniper.= net>, Ashesh Mishra <m= ishra.ashesh@gmail.com>



A new version of I-D, draft-ashesh-bfd-stability-00.txt
has been successfully submitted by Ashesh Mishra and posted to the
IETF repository.

Name:           draft-ashesh-bfd-stability
Revision:       00
Title:          BFD Stability
Document date:  2014-06-30
Group:          Individual Submission
Pages:          7
URL:            http= ://www.ietf.org/internet-drafts/draft-ashesh-bfd-stability-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ashesh-bfd-stability/
Htmlized:       http://tools.ietf.org/html/draft-ashesh-bfd-stability-00


Abstract:
   This document describes extensions to the Bidirectional Forwar= ding
   Detection (BFD) protocol to measure BFD stability.  Speci= fically, it
   describes a mechanism for detection of BFD frame loss, of dela= ys in
   frame transmitter and receiver engines, and of inter-frame del= ays
   that might explain issues with a BFD session.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

 

--_000_7347100B5761DC41A166AC17F22DF1121B7E4A81eusaamb103erics_-- From nobody Mon Jun 30 20:01:04 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA441A00DE for ; Mon, 30 Jun 2014 20:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANckoQDVqoBc for ; Mon, 30 Jun 2014 20:00:55 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6D11A00D1 for ; Mon, 30 Jun 2014 20:00:55 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CAC81C3F4; Mon, 30 Jun 2014 23:00:54 -0400 (EDT) Date: Mon, 30 Jun 2014 23:00:54 -0400 From: Jeffrey Haas To: Gregory Mirsky Subject: Re: New Version Notification for draft-ashesh-bfd-stability-00.txt Message-ID: <20140701030054.GA23688@pfrc> References: <20140630233047.16868.79679.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B7E4A81@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7E4A81@eusaamb103.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2Q2wz1woEz6hiFUjedwGoLJmT7A Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 03:01:00 -0000 Greg, On Tue, Jul 01, 2014 at 01:09:12AM +0000, Gregory Mirsky wrote: > Hi Ashesh, > I'm not convinced that the goal stated in the document as quantify instability of the BFD control messages through measurement of inter-packet, a.k.a. inter-frame gap is relevant to BFD. Note, that interval between BFD control messages, according to RFC 5880 is jittered, i.e. randomized, as described in Section 6.8.7 RFC 5880. > > Though it may be tempting to add performance measurements on top of BFD there are already OWAMP/TWAMP for IP PM and MPLS Packet Loss and Packet Delay Measurement RFCs to use for measuring performance metrics. The guidance given to the various authors of this effort was firmly to avoid trying to replace existing L2 OAM technologies. I suspect that their success in doing so will show itself over the coming days. This said, the mechanism described does have enough information given the expected jitter to help determine some amount of the packet timing. -- Jeff From nobody Mon Jun 30 20:08:55 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B781A00D7 for ; Mon, 30 Jun 2014 20:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7FcNhfSkYnc for ; Mon, 30 Jun 2014 20:08:51 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D4B751A00D1 for ; Mon, 30 Jun 2014 20:08:51 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 96B62C3F4; Mon, 30 Jun 2014 23:08:51 -0400 (EDT) Date: Mon, 30 Jun 2014 23:08:51 -0400 From: Jeffrey Haas To: Manav Bhatia Subject: Re: New Version Notification for draft-ashesh-bfd-stability-00.txt Message-ID: <20140701030851.GB23688@pfrc> References: <20140630233047.16868.79679.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/kGMpj6N_2tdWxpw4To-3ycY7MM0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 03:08:53 -0000 Manav, On Tue, Jul 01, 2014 at 06:12:41AM +0530, Manav Bhatia wrote: > Security Considerations says: > > Since this method uses an authentication TLV to achive the > functionality, usage of this TLV will prevent the use of other > authentication TLVs. > > This is not acceptable. I would not like to see any proposal that > precludes the possibility of adding authentication later -- your > design stands on tenuous grounds as soon as you say this. Exactly how well that survives the sieve of real-world deployment of authentication is itself somewhat tenuous grounds. :-) But your point about making this feature work with actual authentication is work they've identified needing help. I suspect you'll have opinions on that. > BTW, i dont feel great about overloading the authentication TLV with > information thats completely unrelated to authentication. This breaks > all HW that looks at this TLV and sends it for some special > processing. You now require HW to peek deeper inside the TLV to know > if its something that this would interest it or not. The authors of this draft were suggested to come together to work on this since they all had very similar ideas for the feature. The observation that has lead to part of the current design is that the sequence number semantics needed for the feature are largely carried already through meticulous authentiction sequence numbering. At the end of the day, if we eliminated the additional fields, kept some well known but inexpensive authentication (such as null or password) and simply collected statistics related to expected packet presence based on rates and jitter it woudl be possible to derive some amount of loss and lantency statistics. The addition of time stamping for additional work seemed to be another common factor in each of the suggested designs. Keeping with BFDv1 problematically means one of three likely designs for such a feature: - Overload something like authentication. - Packing the additional data after the BFD packet. (There is room in the spec for this, but depending on how pedantically someone implements it or not may result in the additional data not getting through.) - Declaring defeat and creating BFDv2. My push, as is well known on the list, is "can we do this without becoming backwardly incompatible". Some day we will. Is that today? Let's find out! -- Jeff From nobody Mon Jun 30 23:06:20 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCC61A0AA8 for ; Mon, 30 Jun 2014 23:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RZ4Kik5uJ4q for ; Mon, 30 Jun 2014 23:06:03 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 346CC1A0A9C for ; Mon, 30 Jun 2014 23:06:02 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 476812AA0F; Tue, 1 Jul 2014 06:05:55 +0000 (GMT) Date: Mon, 30 Jun 2014 23:05:55 -0700 From: Marc Binderberger To: Nobo Akiya (nobo) Message-ID: <20140630230555087199.19db4b6d@sniff.de> In-Reply-To: References: <20140626182533.30391.72279.idtracker@ietfa.amsl.com> <8fe58c80d3ba4e0da4da3e82cf7677dc@BLUPR05MB755.namprd05.prod.outlook.com> <20140629152450732481.c07ee0d4@sniff.de> Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/RQMI4ZD068AjL6uOMP3JzUQQhJM Cc: "rtg-bfd@ietf.org" , "Marc Binderberger \(mbinderb\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 06:06:12 -0000 Hello Nobo, > One of the changes from draft-ietf-bfd-seamless-base-00 to=20 > draft-ietf-bfd-seamless-base-01 to take out all IP related procedures and= =20 > move it over to draft-akiya-bfd-seamless-base-ip-03. Intent of the author= s=20 > is to: okay, so having an IP/UDP header is a fixed part of S-BFD then? It's not a= s=20 agnostic as RFC5880 is regarding the frame around the BFD packets? I wasn't sure about this, thus my comment. If IP/UDP is an inherent part of= =20 S-BFD then ... > it would be helpful to hear "yeah above is reasonable" or "let's structur= e=20 > it this way" from you and the WG. yeah I think it's reasonable :-) About the state machine=20 > This comment looks familiar :) I think I repeat myself ;-) but there is a reason. Nothing wrong with the= =20 state machine you propose but I do not see this must be part of the=20 definition. As an appendix, to show S-BFD allows for other state machines= =20 than 5880, that would be educational. As explained I prefer a more open approach, the reflector truly reflecting= =20 the state as well. Your state engine is then solely driven by the initiator= .=20 Just setting the state to Up on the reflector is removing this degree of=20 freedom, unnecessary IMHO and reducing the ability to "play" with the S-BFD= =20 definition. > - Move the SBFDInitiator State Machine section to appendix. I would like that! =46rom your reply > True, but you forgot the aspect of: >=20 > BFD: > - in case of MPLS, LSP ping bootstraps the session on egress > - session is created > - tx timer is started at no faster than 1 second >=20 > S-BFD: > - no LSP ping bootstrapping > - session is created > - packet can get tx'ed right away >=20 >> From above aspect, "considerable" delay (i.e. couple of seconds) is shav= ed=20 >> off :) What I like from your reply and what maybe should be more pointed in the=20 draft are exactly the aspects that make S-BFD fast. Yes, you do say it=20 somehow in section 3 and section 1, 2nd paragraph. Maybe a nitpick but you= =20 could talk about your design principles more explicitly. Example from secti= on=20 3: Required result is that applications, on other network nodes, possess the knowledge of the mapping from remote entities to S-BFD discriminators. What you probably want to say is that S-BFD is requiring the distribution o= f=20 the mapping before a session is even requested (principle: fast setup). The= n=20 logically discriminators are allocated per (system, entity) and not per=20 session. Again, you say it somehow in the text but you actually do not dema= nd=20 this principle. > Agree, this seems to be the direction we are heading, and I think it is= =20 > reasonable. However, I (we?) do see a need for auto-foo, where foo may be= =20 > "S-BFD discriminator allocation", "collision detection", "collision=20 > correction" or combination of them. no doubt about the auto-foo but I assume this is topic for another draft? = If=20 so, then how can you make your S-BFD base draft working interoperable? Thus= =20 my comment to define something very basic (manual) to have a starting point= .=20 Not because manual configs are so great. (although: in these days of central controllers and software-defined networ= ks=20 maybe "manual" or it's API equivalent is all that is needed :-) Regards, Marc On Mon, 30 Jun 2014 23:18:00 +0000, Nobo Akiya (nobo) wrote: > Hi Marc, >=20 >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Sunday, June 29, 2014 6:25 PM >> To: Nobo Akiya (nobo); Santosh P K >> Cc: rtg-bfd@ietf.org; Marc Binderberger (mbinderb) >> Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt >>=20 >> Hello Santosh and Nobo, >>=20 >> good stuff. Every time I read it I find something new to learn :-) >=20 > As always, thanks for comments! >=20 >>=20 >> Re-reading the draft I had a few thoughts: >>=20 >> 1) the draft is a "base" but it actually defines some details I would ha= ve >> expected in other drafts. One example is the IP/UDP header. Yes, IP is >> everywhere but what about applications where you don't require IP ? Or >> the other way around: why having an extra "bfd-seamless-ip" draft when >> IP/UDP is an essential part of the base draft? >=20 > One of the changes from draft-ietf-bfd-seamless-base-00 to=20 > draft-ietf-bfd-seamless-base-01 to take out all IP related procedures and= =20 > move it over to draft-akiya-bfd-seamless-base-ip-03. Intent of the author= s=20 > is to: >=20 > 1) Focus s-bfd-base on the procedures for UDP header and BFD header. > 2) Focus s-bfd-ip on the procedures for IP header and MPLS. > 3) Add ip-less procedures (i.e. associated channel) in either s-bfd-ip or= =20 > create a separate draft (i.e. s-bfd-ip-less). > 4) s-bfd-sr to be worked on at a later time. >=20 > Since we are only defining one port for S-BFD, this made sense to those w= ho=20 > worked on the recent changes to the S-BFD documents. >=20 > Yes there are alternative ways to structure the documents. That being sai= d,=20 > it would be helpful to hear "yeah above is reasonable" or "let's structur= e=20 > it this way" from you and the WG. >=20 >>=20 >>=20 >> 2) similar the details of the state machine is something I think you do = not >> really need in the base draft (!). Just define the reflector as truly=20 >> reflecting >> the state from the incoming packet (plus overwrite with AdminDown) and >> you then leave it to the initiator if it uses a new state machine or the >> 5880 Down-Init-Up sequence or something completely different. >=20 > This comment looks familiar :) >=20 > Texts above the state machine now says: >=20 > For > persistent SBFDInitiators, the states and the state machine described > in [RFC5880] will function but are more than necessary. The > following diagram provides an optimized state machine for persistent > SBFDInitiators. >=20 > And after the diagram: >=20 > Note that the above state machine is different from the base BFD > specification[RFC5880]. This is because the Init state is no longer > applicable for the SBFDInitiator. Another important difference is > the transition of the state machine from the Down state to the Up > state when a packet with State Up is received by the initiator. =20 >=20 > I think the texts and the described state machine is helpful for reader t= o=20 > better understand how S-BFD operates. So I prefer that this section remai= ns=20 > somewhere to give better ideas to readers on how SBFDInitiators can be=20 > implemented. So, I think we have few options. >=20 > - Texts in the s-bfd-base-01 is sufficiently reasonable. > - Further texts should be added to make it more obvious that describe sta= te=20 > machine is not mandatory. > - Move the SBFDInitiator State Machine section to appendix. >=20 > Thoughts? >=20 >>=20 >> S-BFD is largely about the reflector, I would say. Your draft brings up = a=20 >> good >> point: the state machine details are not relevant for interop as long as= it >> stays within the definition of the reflector. >=20 > Yes I agree. >=20 >>=20 >>=20 >> 3) Actually I do not agree with statements in the draft about the 5880= =20 >> state >> machine "may not be applicable" or that your proposal is better suited f= or >> the initial delay to bring BFD sessions up. Your state machine requires >>=20 >> RTT + Tr >>=20 >> the original 5880 takes >>=20 >> 2 * (RTT + Tr). >>=20 >> (RTT: Round Trip Time, Tr: the processing time of the reflector) >>=20 >> True, that is faster ;-) but I'm not sure you had this in mind. And if >> O(RTT+Tr) is relevant then you _do_ have a "considerable" delay too and = are >> not "seamless" anymore :-) >=20 > True, but you forgot the aspect of: >=20 > BFD: > - in case of MPLS, LSP ping bootstraps the session on egress > - session is created > - tx timer is started at no faster than 1 second >=20 > S-BFD: > - no LSP ping bootstrapping > - session is created > - packet can get tx'ed right away >=20 >> From above aspect, "considerable" delay (i.e. couple of seconds) is shav= ed=20 >> off :) >=20 >>=20 >>=20 >> 4) The D-Flag ... forgot what I wanted to say :-) >=20 > LOL, I do that often too. >=20 >> 4) The D-Flag ... forgot what I wanted to say :-) >=20 > LOL, I do that often too. >=20 >> 4) The D-Flag ... forgot what I wanted to say :-) >=20 > Wait, didn't I reply to this already? :) >=20 >> Mainly, if you define the >> behaviour you expect on the reflector then you don't need to make any >> statements or attempts to be "5880 compliant". >=20 > Agree, I don't think S-BFD is trying to be compliant with RFC5880, but=20 > S-BFD is trying to keep as much the same semantics possible with BFD so= =20 > that we are not re-inventing everything. >=20 >>=20 >>=20 >>> - Greatly seeking comments on how we move forward with S-BFD >>> discriminator uniqueness requirements. >>=20 >> You mean how to be unique? Or if uniqueness is necessary? >> For the "how", I propose that a manual option to set a "unique >> discriminator" >> is a requirement. Does not exclude smarter, automatic methods but it get= s >> you started. >=20 > Agree, this seems to be the direction we are heading, and I think it is= =20 > reasonable. However, I (we?) do see a need for auto-foo, where foo may be= =20 > "S-BFD discriminator allocation", "collision detection", "collision=20 > correction" or combination of them. >=20 >>=20 >> Every implementation must allow to configure a unique value within the >> least significant M bits of the discriminator. M is implementation=20 >> specific, >> recommendation is M >=3D 16. So yes, this wouldn't be the router-id then= but >> a bfd-id. Pardon, sbfd_id ;-) >=20 > For connectivity (i.e. reachability) test purpose, a system will need one= =20 > sbfd-id [or more]. For other applications of S-BFD, there may be a need f= or=20 > a system to allocate few tens of S-BFD discriminators. So, this really=20 > places more weight on the "uniqueness" requirement and the need for=20 > auto-foo. >=20 > Thanks! >=20 > -Nobo >=20 >>=20 >>=20 >> Regards, Marc >>=20 >>=20 >>=20 >> On Thu, 26 Jun 2014 23:32:03 +0000, Nobo Akiya (nobo) wrote: >>> Hello BFDers, >>>=20 >>> Yes, many thanks to those provided comments on S-BFD. >>>=20 >>> Couple of additional things: >>>=20 >>> draft-ietf-bfd-seamless-base-01 >>> - Contains significant changes from the previous version. >>> - There should not be any technical changes. >>> - Greatly seeking comments on how we move forward with S-BFD >>> discriminator uniqueness requirements. >>>=20 >>> draft-akiya-bfd-seamless-ip-03 >>> - Just published, links below. >>> - Seeking comments on whether we want to define a new associated >>> channel type for S-BFD. >>>=20 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamless-ip-03.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ >>> Htmlized: http://tools.ietf.org/html/draft-akiya-bfd-seamless-ip-= 03 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-bfd-seamless-ip-03 >>>=20 >>> Thanks! >>>=20 >>> -Nobo >>>=20 >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P >>> K >>> Sent: Thursday, June 26, 2014 3:03 PM >>> To: rtg-bfd@ietf.org >>> Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-01.txt >>>=20 >>> Hello All, >>> S-BFD version 1 is published. Thanks to all who had provided commen= ts. >>> Diff between version 0 and 1 is significant but there are no technical >>> changes. Below are the changes. >>>=20 >>> 1. Taken care of all review comments. >>> 2. "Full/partial reachability" is removed and focus is on the >>> reachability. >>> 3. SPRING dependency is removed. >>> 4. IP specific details has been moved to "draft-akiya-bfd-seamles= s- >>> ip". >>> 5. Consistent terminology. >>> 6. Lots of rephrasing for better readability. >>>=20 >>> Thanks >>> Santosh P K >>>=20 >>>=20 >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of >>> internet-drafts@ietf.org >>> Sent: Thursday, June 26, 2014 11:56 PM >>> To: i-d-announce@ietf.org >>> Cc: rtg-bfd@ietf.org >>> Subject: I-D Action: draft-ietf-bfd-seamless-base-01.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Bidirectional Forwarding Detection >>> Working Group of the IETF. >>>=20 >>> Title : Seamless Bidirectional Forwarding Detection >>> (S-BFD) >>> Authors : Nobo Akiya >>> Carlos Pignataro >>> Dave Ward >>> Manav Bhatia >>> Juniper Networks >>> Filename : draft-ietf-bfd-seamless-base-01.txt >>> Pages : 17 >>> Date : 2014-06-26 >>>=20 >>> Abstract: >>> This document defines a simplified mechanism to use Bidirectional >>> Forwarding Detection (BFD) with large portions of negotiation aspect= s >>> eliminated, thus providing benefits such as quick provisioning as >>> well as improved control and flexibility to network nodes initiating >>> the path monitoring. >>>=20 >>> This document updates RFC5880. >>>=20 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-bfd-seamless-base-01 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-seamless-base-01 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at >>> tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >=20