From nobody Sun Aug 1 13:46:33 2021 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5563A0EF4; Sun, 1 Aug 2021 13:46:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-optimizing-authentication-13.txt X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtg-bfd@ietf.org Message-ID: <162785079172.17041.16738231441073627175@ietfa.amsl.com> Date: Sun, 01 Aug 2021 13:46:31 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2021 20:46:32 -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 WG of the IETF. Title : Optimizing BFD Authentication Authors : Mahesh Jethanandani Ashesh Mishra Ankur Saxena Manav Bhatia Filename : draft-ietf-bfd-optimizing-authentication-13.txt Pages : 9 Date : 2021-08-01 Abstract: This document describes an optimization to BFD Authentication as described in Section 6.7 of BFD RFC 5880. This document updates RFC 5880. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-optimizing-authentication-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 2 14:47:22 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B40B3A1DE9; Mon, 2 Aug 2021 14:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 GzjH21Q4-zRT; Mon, 2 Aug 2021 14:47:07 -0700 (PDT) Received: from mxus.zteusa.com (mxus.zteusa.com [4.14.134.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B997F3A1E14; Mon, 2 Aug 2021 14:47:05 -0700 (PDT) Received: from mse-us.zte.com.cn (unknown [10.36.11.29]) by Forcepoint Email with ESMTPS id 882AAB34C28A5F10CDF8; Tue, 3 Aug 2021 05:47:04 +0800 (CST) Received: from mgapp01.zte.com.cn ([10.36.9.142]) by mse-us.zte.com.cn with SMTP id 172Ll03P027907; Tue, 3 Aug 2021 05:47:00 +0800 (GMT-8) (envelope-from gregory.mirsky@ztetx.com) Received: from mapi (mgapp02[null]) by mapi (Zmail) with MAPI id mid81; Tue, 3 Aug 2021 05:47:00 +0800 (CST) Date: Tue, 3 Aug 2021 05:47:00 +0800 (CST) X-Zmail-TransId: 2afa610867d49570b550 X-Mailer: Zmail v1.0 Message-ID: <202108030547004200180@zte.com.cn> Mime-Version: 1.0 From: To: , Cc: , Subject: =?UTF-8?B?U2Vla2luZyBzdWdnZXN0aW9ucyBvbiB0aGUgbmV4dCBzdGVwcyB0byBwcm9ncmVzcyBkcmFmdC1pZXRmLW1wbHMtYmZkLWRpcmVjdGVk?= Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-us.zte.com.cn 172Ll03P027907 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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, 02 Aug 2021 21:47:14 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBNUExTIFdHIENoYWlycyBldCBhbC4sDQoNCldlIGFkZHJlc3NlZCBhbGwgdGhlIHRlY2hu aWNhbCBjb21tZW50cyBmcm9tIHRoZSBlYXJseSBSdGdEaXIgcmV2aWV3LCBjb21tZW50cyBmcm9t IEplZmYgSGFhcywgYWRkZWQgdGhlIEltcGxlbWVudGF0aW9uIFN0YXR1cyBzZWN0aW9uLiBUaGUg YXV0aG9ycyBvZiBkcmFmdC1pZXRmLW1wbHMtYmZkLWRpcmVjdGVkIGFyZSBzZWVraW5nIHlvdXIg c3VnZ2VzdGlvbnMsIGFkdmljZSBvbiB0aGUgbmV4dCBzdGVwcyB0aGF0IHdvdWxkIGxlYWQgdG8g dGhlIFdHIExDIG9uIHRoZSBkcmFmdC4gVGhlIGRvY3VtZW50IGlzIHN0YWJsZSBhbmQsIGluIHRo ZSBhdXRob3JzJyBvcGluaW9uLCBpcyByZWFkeSBmb3IgdGhlIFdHIExDLg0KDQoNCg0KDQoNCg0K DQoNClJlZ2FyZHMsDQoNCg0KR3JlZyBNaXJza3kNCg0KDQoNCg0KDQoNClNyLiBTdGFuZGFyZGl6 YXRpb24gRXhwZXJ0DQrpooTnoJTmoIflh4bpg6gv5pyJ57q/56CU56m26ZmiL+aciee6v+S6p+WT gee7j+iQpemDqCBTdGFuZGFyZCBQcmVyZXNlYXJjaCBEZXB0Li9XaXJlbGluZSBQcm9kdWN0IFIm RCBJbnN0aXR1dGUvV2lyZWxpbmUgUHJvZHVjdCBPcGVyYXRpb24gRGl2aXNpb24NCg0KDQoNCg0K DQoNCg0KDQoNCkU6IGdyZWdvcnkubWlyc2t5QHp0ZXR4LmNvbSANCnd3dy56dGUuY29tLmNu --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwPkRlYXIgTVBMUyBXRyBDaGFpcnMgZXQgYWwuLDwv cD48cD5XZSBhZGRyZXNzZWQgYWxsIHRoZSB0ZWNobmljYWwgY29tbWVudHMgZnJvbSB0aGUgZWFy bHkgUnRnRGlyIHJldmlldywgY29tbWVudHMgZnJvbSBKZWZmIEhhYXMsIGFkZGVkIHRoZSBJbXBs ZW1lbnRhdGlvbiBTdGF0dXMgc2VjdGlvbi4gVGhlIGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1tcGxz LWJmZC1kaXJlY3RlZCBhcmUgc2Vla2luZyB5b3VyIHN1Z2dlc3Rpb25zLCBhZHZpY2Ugb24gdGhl IG5leHQgc3RlcHMgdGhhdCB3b3VsZCBsZWFkIHRvIHRoZSBXRyBMQyBvbiB0aGUgZHJhZnQuIFRo ZSBkb2N1bWVudCBpcyBzdGFibGUgYW5kLCBpbiB0aGUgYXV0aG9ycycgb3BpbmlvbiwgaXMgcmVh ZHkgZm9yIHRoZSBXRyBMQy48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxMnB4O2ZvbnQtZmFtaWx5 OnNhbnMtc2VyaWY7Ij48YnI+PC9wPjxkaXYgY2xhc3M9InpNYWlsU2lnbiIgdW5vbmFtZWNoPSJH cmVnb3J5MTAyMTE5MTUiIHVub25hbWVlbj0iZ3JlZ29yeSBtaXJza3kxMDIxMTkxNSI+PGRpdiBj bGFzcz0iek1haWxTaWduQ29udGVudCI+PGRpdj48ZGl2PjxkaXY+PHAgc3R5bGU9ImZvbnQtZmFt aWx5OiDlrovkvZM7IGZvbnQtc2l6ZToxNHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyB3aWRvd3M6 IDE7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0cHg7Y29sb3I6IzU4NTk1Qjtmb250LWZhbWls eTrlvq7ova/pm4Xpu5E7Zm9udC1zaXplOjE0cHg7Ij48c3BhbiBjbGFzcz0ic2lnbmVkaXQiPlJl Z2FyZHMsPC9zcGFuPjwvc3Bhbj48L3A+PHAgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZM7IGZv bnQtc2l6ZToxNHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyB3aWRvd3M6IDE7Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE0cHg7Y29sb3I6IzU4NTk1Qjtmb250LWZhbWlseTrlvq7ova/pm4Xpu5Ei PjxzcGFuIGNsYXNzPSJzaWduZWRpdCIgaWQ9InNpZ25fbmFtZSI+R3JlZyBNaXJza3k8L3NwYW4+ PC9zcGFuPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IHdpZG93czogMTsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRweDtjb2xvcjojNTg1OTVCO2Zv bnQtZmFtaWx5OuW+rui9r+mbhem7kTtmb250LXNpemU6MTRweDsiPjxzcGFuIHN0eWxlPSIiPjxz cGFuIGNsYXNzPSJzaWduZWRpdCI+PGJyPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvcD48cCBzdHls ZT0id2lkb3dzOiAxOyI+PGZvbnQgY29sb3I9IiM1ODU5NWIiIGZhY2U9IuW+rui9r+mbhem7kSI+ U3IuIFN0YW5kYXJkaXphdGlvbiBFeHBlcnQ8L2ZvbnQ+PGJyPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTog5b6u6L2v6ZuF6buROyBmb250LXNpemU6IDEwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IGNvbG9yOiByZ2IoODgsIDg5LCA5MSk7Ij48c3BhbiBjbGFzcz0ic2lnbmVkaXQiIGlkPSJzaWdu X2RlcHQiPumihOeglOagh+WHhumDqC/mnInnur/noJTnqbbpmaIv5pyJ57q/5Lqn5ZOB57uP6JCl 6YOoPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWwiPiA8c3BhbiBjbGFzcz0i c2lnbmVkaXQiIGlkPSJzaWduX2RlcHRfZW5nIj5TdGFuZGFyZCBQcmVyZXNlYXJjaCBEZXB0Li9X aXJlbGluZSBQcm9kdWN0IFImYW1wO0QgSW5zdGl0dXRlL1dpcmVsaW5lIFByb2R1Y3QgT3BlcmF0 aW9uIERpdmlzaW9uPC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6 MTRweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgd2lkb3dzOiAxOyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxNHB4O2NvbG9yOiM1ODU5NUI7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRO2ZvbnQtc2l6 ZToxNHB4OyI+PHNwYW4gc3R5bGU9IiI+PHNwYW4gY2xhc3M9InNpZ25lZGl0Ij48YnI+PC9zcGFu Pjwvc3Bhbj48L3NwYW4+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgd2lkb3dzOiAxOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2NvbG9yOiM1 ODU5NUI7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRO2ZvbnQtc2l6ZToxNHB4OyI+PC9zcGFuPjwv cD48dGFibGUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiDlrovkvZM7 IHdpZG93czogMTsiPjx0Ym9keT48dHIgY2xhc3M9ImZpcnN0Um93Ij48dGQgdmFsaWduPSJ0b3Ai IHdpZHRoPSIxMDAiPjxpbWcgaWQ9InNpZ24taWNvbiIgd2lkdGg9IjEzMCIgaGVpZ2h0PSIxMjAi IHNpZ249InNpZ246OWFlM2UyMTRjMTdkNDllZDkzNWQ4N2M2NzRiYTNlZTIiIHNyYz0iY2lkOjlh ZTNlMjE0YzE3ZDQ5ZWQ5MzVkODdjNjc0YmEzZWUyIj48L3RkPjx0ZCB2YWxpZ249InRvcCIgd2lk dGg9IjUwMCIgc3R5bGU9IndvcmQtYnJlYWs6IGJyZWFrLWFsbDsiPjxpbWcgaWQ9InNpZ24tbG9n byIgd2lkdGg9IjExNSIgaGVpZ2h0PSIzOCIgc2lnbj0ic2lnbjoyNDI0MmU1NjM3YWY0Mjg4OTFj NGRiNzMxZTc3NjVhZCIgc3JjPSJjaWQ6MjQyNDJlNTYzN2FmNDI4ODkxYzRkYjczMWU3NzY1YWQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRweDtjb2xvcjojNTg1OTVCO2ZvbnQtZmFtaWx5OuW+ rui9r+mbhem7kSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFsIj48YnI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDhGRDQiPkU8L3NwYW4+OiA8c3BhbiBjbGFzcz0ic2lnbmVkaXQiIGlkPSJz aWduX2VtYWlsIj48YSBocmVmPSJtYWlsdG86Z3JlZ29yeS5taXJza3lAenRldHguY29tIj5ncmVn b3J5Lm1pcnNreUB6dGV0eC5jb208L2E+PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDhGRDQiPjxhIGhyZWY9Imh0dHA6Ly93d3cuenRlLmNvbS5jbi8iIHRhcmdldD0iX2JsYW5rIj53 d3cuenRlLmNvbS5jbjwvYT48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3RkPjwvdHI+PC90Ym9keT48 L3RhYmxlPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogbm9ybWFsOyB3aWRvd3M6IDE7IGZvbnQt c2l6ZToxNHB4Oztjb2xvcjojNTg1OTViO2ZvbnQtc2l6ZToxMHB4Ij48L3NwYW4+PC9kaXY+PC9k aXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+ --=====_003_next=====-- --=====_002_next===== Content-Type: image/jpeg; name="=?UTF-8?B?MjQyNDJlNTYzN2FmNDI4ODkxYzRkYjczMWU3NzY1YWQuanBn?=" Content-Disposition: inline; filename="=?UTF-8?B?MjQyNDJlNTYzN2FmNDI4ODkxYzRkYjczMWU3NzY1YWQuanBn?=" Content-Transfer-Encoding: base64 Content-ID: <24242e5637af428891c4db731e7765ad> R0lGODlhcwAmAPcAAAAAAP///wCP1QCP1Pf7/vL5/QCP1gWR1gqT1gyU2AyU1w6V1xWY2BeZ2R6c 2iGd2iyi3C6j3TOl3Tqo3kWt4Emv4Uyw4U2x4lOz4ly35F645GO65WW75me85m6/53XC6IHH64XJ 64bK7IzM7I/N7JXQ7ZfR7pnS7pzT7p3U76PW8KPW76XX8K7b8bDc8rff87vh9Lzh9L7i9cnn9tLr +Nnu+eDx+uf0++n1++33/PD4/PT6/fj8/gKQ1AWR1QeS1QiT1QmT1g+W1xCW1xOX1xia2Bub2Ryb 2R+d2SCd2SKe2iSf2iag2ymh2yqh2yui3DSm3Tio3Typ3j2q3j6q3kCr30Os30eu4Euw4U6x4U+y 4k+y4VGz4lCy4Va141W04li241q341245F+55GW75Ga85Wm95mi95Gq+5Wu+5m2/5m/A53HB6HDA 53HB5nLB53PC53XC53bD53nE6HvF6X3G6X/H6YHI6oHI6YLI6oLI6YbK64TJ6YnL64rM64zM65HP 7JPQ7ZbR7ZrT7qXX76bY8KfY76jZ8Kra8azb8a/c8bDc8bHd8rLd8rXe8rXe8bjg87zi9Lzh873i 88Dj9MPl9cXm9cfm9cnn9c3p9s/q987p9tHr99Lr99Xt+Nbt+Nrv+d/x+eDx+eX0++Tz+u/4/OHy +ePz+ur2+/b7/fr9/vz+/v7//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAK0ALAAAAABzACYA Rwj/AAMIHEiwoMGDCBMqXMiwoUOGiti0mUhxopcBAgZoHKAglcATFaVg3DgAC0U2hgKsKkJyiZqK FUV4bHijx4AHDFmN0BiJ4A2NRFYRJKAAo6WFKzJibOCQEclMB1WxxOgDUQEeqbKm2sEDoQaMhAqS sonE4B2MeQ7WmGlwj0YKCv0oHeDkIUGnAvJCNShVowA7dgXyyXKhsGEJG6kYNqxFUEImGSsQDJFR gOSClUj61cx5wAmEBKJk9JIwTefTaxzaGNnQxhIBex0WAUPwRZoOZnLr3q27Q6CBKXgL742mhUBW e3AP771HlcNSaDjQCVwwByQc1A2+9vtbodONsQn2/8UI2O6F03lP+/1QcEpeJgMbabwyMEzeOQuJ bBSAyC5ejeENNN5GQzBAxIEHNgAGAQZ9JQAlBvUggBIGlYDWQBtYoKGGW1yw4YZacPGhBVjsIRAB B4xEV3YCfZdRgAKNJ0ATLBo01gBlOXSIARgpohAEeQkgSo1EFmnkkUgmqeSSCKkxl3qaMRUBZ5V1 llcHAaQ40lxP+uXQWALkmB0HGplhECYHWADDQ24oJYAVClHilwCgRMVSXiYGhgIZG/TZZxlXaNTD F2X4+adxA+Fg0wBkEGTfACkQhNgAKzR0iop0MvQdgHZu5EdgXw0AYUE2UViQhQKkVdAcQZYSAA9D GP/xxQ4B1KHRFg1h4OYYDzHiJowBDKgiSZXlSZAGeYVFEJhiDnRHXnoM5EOXxO7HmQMGdRJkRtj5 txmwMqoRWBZPplftuXEkxIUJBj2CxUJSVPkGi5sOAO5UA6hqJCql2sVKEBilcRCyAxhQB0GFqEet X3IglAhJlxzEAwPoaSaABV+S1VAmQ+RlREOTBHkGkySXbPLJKKes8sosC6TJllCS9JshC8NsbSUB eFAzZ244FIpSNfrRxADsGoRKQS/ETCWWIShspSMBUGyteu82dGOzCr3AR0EyaESFQU4OAJdDcBC7 SEJjuJmuQTzg+0SSNmG7ECuQDZBAQUlo9AlBg2D/BMVDm2wpQA4KOUISJ53mpa9DJVRmLkZcUgv1 QDRjRMNAI2SUmkAzYDSEcw3xMVcEmj7VqUblPSRGRl2ooMIKK6hAh0Y/kMBC7K9PkBceBeGwUaUB gLKRc/xqZIpD7vkFR0Obwna6AGiAqlEhBY1iUxIG5YFRtAZh1IYOAh090AIY9cRQAUBALsBRzM91 734CICDEAvQvoMAQGNBaELICKDvQ1Wa5kEBi4IJGNMITmTCgAhvhgg8o5QsvMKALcHaQSKRHAAro SlO+ZafHQQ5mAuhDg8AiFo0VBAQCDAAIMWWuKlWGKQZJg5vg5C2/vI92LujKKna4CtAdRAwa8QIL 7YY4xLPErwREHGIVMMI7km0nL4CgjovsdboBiNAumbPYsKpkLUQZRAZ5+dtAOrEAAXwtITjgkiey U68bDiB1RSKARo4QmEOkR3wDOUNlMnCQQrgJPvQyHV+KUCwkAfAhYMjLD4RyECxUJhEESeRmBCAB mMCkBAlpnhsHwAQPWHIifWCQ1UzIEFAEqQsLwQEQ8gIBgWiBS0qbI0JeMJcaHGQV04plXr6kEbkp hBVTEkAPjtcQOWSEVwGQxBw+wMxmOvOZHxiEQnIAgj1o8JZ/gKY2SeDDhejgDW1YnEI+AUm7fIKR LUunOtfJThYFBAA7 --=====_002_next===== Content-Type: image/jpeg; name="=?UTF-8?B?OWFlM2UyMTRjMTdkNDllZDkzNWQ4N2M2NzRiYTNlZTIuanBn?=" Content-Disposition: inline; filename="=?UTF-8?B?OWFlM2UyMTRjMTdkNDllZDkzNWQ4N2M2NzRiYTNlZTIuanBn?=" Content-Transfer-Encoding: base64 Content-ID: <9ae3e214c17d49ed935d87c674ba3ee2> R0lGODlhggB4AHcAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQICgAAACwAAAAAggB4AIcATr79vg2j x+twuSDo8tdNjNSk0mTQ57AojVB4uI7+1GPI3/P+6rKPxan9yjsBes4/gtD+34y61u9jm9rr9vva 7Pek0aolccv///8Baccki9Sj0FwSfM6DtOOAv2Wy1e9Mo92axurf78n9xisLacf+2XNwpN33+vE7 m9r9zkv+89Q0jNWMvebh7/nL5KPR5vbC3vP+5Jxks+NbpN10u+UDg9Gqzuyi0YLx9+aTvuYkhNF/ wDbZ7L0cjNQAdccAZMUlkta73Y0Ybsn+z1CUyk5LnNpiqd88k9f9whz+3YNNqt9EnNr0+/18vOaF weczm9oBjNQae879xzK426PV7fjc8vqIxCek0u79zEP+5qR8r+Cd0u5ss+O84vT+8Mlbqd8Le87M 6fdTnNrl8dMrg9G22e8BXcMKdMsrdcyUyuuMy+xtqd+s1vAsktb+9t3+1muy2Hqs1XTt+f1xsdvE 4/X9012BwQ3u9uIwjelDkteKxTTW6rr+23tTo939xCNEo91ro92DvPd7wOcchNKEwoQ8jNRtvOZN ltg8o90sm9qIvui02YOm0/kri9QLgM/m+f1dseIUg9EMjNQOZsZUqd8NW8I0k9cSdMv+4ZObzOwk fM/H6ff+6Ku24PN1wunV8frz+esyhNHN5quDvOZcnNrU6vczeM2bzVpxr+y/35R7viO73PLb7cOn 0mz++OTE4Z2s2vHj8/oSbsphpN6TyTwAbMmU0O6r05rb7vn9wRTN7PlDi9Ti8M1Dltj+7LvT6LRK ktaTxene+Pw3od2EyetbrOHL5fV0reAse86d2PF6vSlzteMCk9am2PEtldigz/Eckdaz1/Gt1IW6 3IRjreGz3PkBVMBNseEzltg8mOH9yC9sreFVrOBSltgcdMs9ltgkldmKwOdhueUeftAAddCMw+mB v+kNbcnn89ir0+6jzex6tOP90E/q9NyVyPBEqd7R56+k0nH9yTSz2/ILftB8w+mAvyP92G390VQK hNEBdMuEw+kAfdARftD+/v7///8I/wAxCBxIsKDBgwgTKlzIsKHDhxAJMimHAgaGckvoYNgHgg6T JktKMaFRpBSGZSBKyeECogIFLn1iYeDyxSW1LxRiFeMmh8kXarGq9KHGBNdPDLH6cImFC8QyDC9A 0MBABUQTJsaWNMFAZ8koDFn3MemyJBiGVX/SYJiHItNaFFsiLkwH4goTarXSYZihjw2GPvrSyQFx xiMKfRaPgFkV69slY7Es0aOCoVEkY1UaaYpValAkCnIG6SjVeQUFY5E0FAXTBtcmDnmYrHrwhKu+ IhTmnenDJJ0+EBg+1OJ9pdY2DMH0ycCQptayibW+ZvozT67BJrW4gFXXgusVmXS+c/9NR+HslfKr 0slMT0E2GyZr2bRf9YEJkw/RBKaLZj/aKgwUpFNdb/MwIUc6FgX4HwVX/BcLgkhd0QVS6mgUiw3G YICLOhnickWGpahTwUw1uGXdWcGU8kIaGp3o4oswMsSEEpKsUkoT1UVUzAMmxujjjz5SoUMtsFzx ADVyZfLFf0A26eRDxswTxhrArGJME/lBSUd5T3YZC3xdFtSUDuowBSYT8zC5EBMgaGBRmE3OM0sw XMKJQRP6RAemQKvkg8KeCTExgyUt2hkjE1xY0wguhlLRiD5PbFJQVto1xMSXhv54BQo01NnlRA/w eJB9Db3gUaY/XiqHobGAoI8zlBn/REEzOSokxiVZogrjKtzs4+mTqP0gw6oGrXJJHgzRgEKhup6I aAYrjAhnUhr4dVApXJi1UE6ANisXBcXU0kascFYhUqDdHmTMKr96CxEFkOiTCLldzgPJFQnFkkmu CYnhDb+6VlFPPYw6RMEXPzRi0kNXGMKsQhQYYY0l7fKpzxEMdSDGw6iyUUsGejnERDBkzCKTQ1UU Ys1xlqpDilgIlbJNOO5CtMouBXQRS8UHUdAJvQvF8skxppQD0SbEvkhHNDzbyUQYYawyAw0nF8QE FfPYUh0uIaRT1BZX0FF1QVfMEIwuW4q8yhqZpCtQLGlYq9Af+nxQ80Cj/KAP1QRV/wELSJHoA4S+ ZuiAyyj6PIANNVvoAmgzGphxBNBBI+zM2AStoo8lDIHEcbPzAFHLA50KVMoMD+SpzyW94ALDEUux EMUZqrehzkDz9FALGII0fVAslECK+UAVcGH03RGFro8+acQixxWa/NDDH4bYIilSq8YCSz3XgHPG D7MwQUEYooPBN0SxcKMPIr43tG77mc7TRiQg9EJDGKNQM0/SCDGhiyfcSFMf3gGNSPROLunTxzCG 97Z9MaQIl5Ab8qgShmVUQgfGIJVAVBCDJCShBAp4Ax8w4QWB2IcC67CGBmBxLgSqLxEMxEAZZIGs hYyiDxmaoOmoYIxllKNOWVCAA//8II8I4CMXSPADEkZQB04MZBViaB4V3MYQnfzAEjGsQBN6FCj4 xa8NjdgfmHyhgBH4YQQjkEcS+CCPETjAAW1EAj5KiJRYUIMM++DfQ9jQh2BQEQN/JAgd2BDDgP1h dLDYIB+kQEQ4ysMBUsBHDCJQhwjEoAR1SGMWTHiEH0Qikdapgh77tg98LaQIZ7Ab8iayPBnIxBUx wAIS5IEFB9QhCW9QQAmScA985DIFSYhAEmMgEHVEIgMgqEJEmHCFOVFRc5xbCAtmkcO7GaMNtYCV QDiByzfIEguYiEEddukANyoRCxHIAj4CMIJNMgESZwCDWt7VB2tgg2e4WAcXdZj/EDnsI3H7EIg6 bRmDN+AjAkI8IxbQSMs68OGhJXBAABzgBq4AIQN/oJxCZKPPQDZkFeK5G/B+0BoMeCEFSpRHCdLJ h1yMAB/4wEIJMBnOOsgDH5gogTxu6YqZZOCTEYmFRgcSi2CETCGHAeXd2ACCeSbBD1gYgjzkoYAy yuMenKCkF2KQgqrKAwkO4IMHIzACJ9JBDFxQ5kN00gs1GWQetYimQpoAgmq6KxZhUCsGFIAEEQ7x jG/AxBvekAIHYKKMSXRAYV+ahSTkogRvo0IVPEoQWOgjAzA7SPGOx0+FLIMDAcWAG/CBBD5koQ4p wIcCJimPRmKBD5eEIxZSIA8p/2BCmCmoaFZK4hCd1CISbjUIZcEyDy++qCcCkQMFllsFQFSCNwLh KxYGiwlOvAGODsBCLUeggDXyAR+0dAA7kmDVEqphEqaIhnJBAx8DYaAKm5AJBfZRA31Q4o8tCIYp bSWL2xlDHYxhQgX2EwtMuYgOf5ABBeighCcg4gnFUMcHCoWJJNIyBQ+VrXa164BcpCALb3CjTOvw RnkwAAO6SEMImoCIPyBiGGlgQibqwgXQrmR5PajVQVZBQ48GgxppuFIPuNEJY2QCGyCYxxWkdaIQ mOEMpQiBLDKgD73JQBgFeQMStjzR645gwxzuawzwoQ3tFvaN2tgkIGFBBr3V4v8HRfgEKczQhyWY YRmxEIMZejDPhFRgFLdb03rDAIstUQAX89CZgU9kjBlw4TTUWEIfvoCCfPRCx67IAghDSFgzErG1 KvUFJ1Lw5Vpmt5ybjMUyNJCIGdS5CJmQgzrEIKFyZGgV4VjFcD+aCeO6aGeRxUUskuGIWoSWIK5I thtU4AVu4mMEKSjBG9aYhDoQccMOWKIvuDIkQzCFCrho72QBOZDhtqAc+03IEs4QXF3RQQP6qIdD VJBV8mIBqhHgQznTmIKuVnQVjyJGkzSHAob82CP20WCmuqCBB8j7ISpAqRTayAdOhLAE+BArJgQC i4YLHEi42GJvq0ByybrbEvr/EEdEMHHGwmJBtZY0aApOjAE15AMMcanZKtJQigL7XFe4KMIPnlBI hPAhsQ7QhmIXGgAFDEQGP9CBjmN0uEAjVR/tRhUT1iGLPvhaIK7ggxmnasYA5KIOPRXIMkhQBL36 aB76+AZDylGMFyAvDPuYkHWCiIWpyoMdmEi7QIxhiHT7CBfm2Gf/9rRrH9knFlfw2omanQUGVLTc Si66ixSeEBikQWck/8S4DRXyfYTjHOMIg5OoEApjN94hVWeIGM7RNjkERfM+ioUMaqGDYjQCBbgP KggeIIkkD/xYDEkDFxamq1hA4gG1QAFkwkCHguXeGB7SQcIM/6JYqOGo6HLX/zpqUYsn6F0dOgBB 8BlysEbgKxxgEJdSdcWGclgfVZCoBTb0zoRRUPkqMbIPD/ADT0EBTQAGP3AEqhcjpbAMfZYQvVAL bRMUogcjuJAGnrAP+1APnjCBTfB5W6B3g4cNv5UGo2cdbDAI4sIkBsgBS+B2LgJXbcAQmXAMdGB7 VVCBCNQE1OAh8RcqeRIFXZAJP8ABzEcQufMAPQAC+mMdq+AM+pAP6TYrSrYN3BcR52Z1mRIGZ2AG mUAHRxAFGjCGUZAHhIYMCogQ9SAJoVJ+n6MQuLAEP0A66SIHS2ANS/B6LhINmbB+MTMPxrANVYIB m5AMsDAPsNAMGcIEzdAFVP/UBT1QA8xQAw/AWQ5RAUPiSj0zCrvAAnooJoDGECiQFy7SFP2QBnLw CJ84EMbQcFBQAzWgLQ0RC11AB2lwPqPyCauYObWAMQuRBpSwP0FRBX7IBP+UAQD4IojCAanTB0e4 EOWwG7sYERWwDzm3EDhIcroAg3B4GM6wgDAyXwn2jBs1CpWwAn4II5yHEPPQhyfSJw43jcJFVJgi B2pFASRXBbhAB13QBegGdB/IEIcgCwDzEFvwADUwfz8SC/vwBG3QNk0ABAXCBeCQCE/wBIPAAU4g j8lzDrGxEJmwDCZhe6vyeO1BRSMzOlMXI1XADWCQAT9ADVUADNZQDrHQCHr/szx6Yw7eoi+qtCZ0 0AlNYAlcUItXUARfMA/NwI0CMQ+RoE1N0gSpowFGoGuZAAgekQkz8AWGQAM04I6dZRDpsA/zUAXp sAyZIFl0MAq2ljajQgfkCCMVMIpPAAsncykmVGCgMUqZggvLIIvq1hcmxHgeFQtbIBhNEgYaQIDu sgevMAagwAup8As4gAOvkApjcAJj4AINQA7ZQINNEJcNoQ4/cAlZ5yIvcWnNcgKsEAcGIAKgsAdx 8Art0A5BAAesAAqsMA23EAwF6SSrUADdYHdNUgVhEAxr8B7pQAMDUw800AQZpA7Q+SKg8Au/wAt7 wAongAGg0A53IBB30A6g/8Cd7YADDpEOihAGBqJcfJkQxNglcpAHACADVXAEZrA8efIDo1AKoWAG AbWLr0AEogARVPCXDLEEtYCKOagLuthbadBrT9J/efAd20AGbXChjRAK6oALgFAIWzAPowCOEJEK qTCeD6EbNaQQ6nA/gMSeD5EJu3Oa6khUdFCj/Kie7yVUnTQVETEGvIBAaQB+geIsaaAPNSBBubcF LEJZYYBNxRARd+ACY2AdyDUX4XB/EJEJD5APK3lcMpAP+jAIlsiOPaAPlfIQonAKIiAXFbANY3oQ h3AOppRwL7qlXeoiVzAI/AAFm2NXBoEL8RIJircQe5AK7SAXq+CRDPEBNP9Qlgt6giCJkHd6IvtA D5L4AGE0V3lCCV+HAeFpHQ8ioxKxni7qEM2hDwoJI/PgijXQAzKQCUwpKGagASL4EHeQmXCSCTTA ZBFBB70gBrx6KGkwCOujBBwQBYjgCVtglzUHAgA2CqnaEL+wCFMaEaXwBV+xECQopBChC0OljDRg CQ3SCBlQC/oQCZqwDlWAAgAwA+3ZEC4QB9UKEXAnVwlxBSyApQ9BBTRgk0+CV/DRBSShA9DXdplA CuowjWPAAyaKPg7UEPZIjEHxrgWRCWZQC2/SJPi4J1ijBp6QI6pInQ3bJekwCl2Qg6JHBesHA2Iw A6L5IqNQCFr4JLzwCyP/6xAywwIMEYES9HrC8Ahdsg7IEAJ28gqtMK8PsQpnkKL3SjAncjh08q9U 0KkRcQBBcKhBdQWTKhEuAqOL8SSHxpEL0Q5I+y6UdQU0cIPD6IdFWgNbS6ng8Ax2wgoEYB3Xmq0K cQgkUHsk54dayqVPQgP54A5wkgpxgLXJcwa94FHpEAz66hB/+7Zy0Q434AFTcLM/0g6t8AonQgET 5jRpsKXV0CRjcApWYAWqEAeYS53YqZ2Gonzf+ou14AMWwAPfiQ6ikJu6eQDtcAJ3cAC5yZoHMKV3 8At7gAOgMAa/YAD2oAdEMAA7AA/tIAqQ+bt7MJ4iMLyeygPHiwFjIAo//xqblIkBv7ABQfCdLlIK lLAVC4GgtXd7+4oKcyANuBmbrXC17ZAKrZCbrHC/Y3AHrxAHooADrAAH1Dq9cKAHVkALp7ADypAK PNAKv9AOBTwNvADAAnwHIrAIi3DBomAALnCrixAHF2y1ZYuoDyB3CzEP5aC2OciU/RQLY8AK33kH PMALJxCZNOyprMALoJC8rHCod8AKsHkC7SACcKAMqkALqrADv2DDvYsDIsALOKCZQXwCBFzE7cAD vQsKIsAKVby635IOomo1dPoQL3AM65CODNEO8aAKdmAFiyDGYfmLInkiFlsLZTy5hIAACUDHE/QC s4C3gfmb7sMNS/EkjP+AB4FQxwVhLMDAEPUnEnJAkhDxCWxsMLhAsRNEAYUmIxT4CZ+wjVAyFJns EDDwAVSbKcvFECGwfIPZeGmQAWcguaG0C8jwhhNkDH9wpgkRp4acfEZqy9+yDD3oyHyytAyxCltw yhgQuWGyXLiQDi9bMwtGnOznOplQlhRABftBclQEzXASDEJwDMjsEOUAZHRgCJJwDfNgi+CACGyw BY/LBG0brUASDWLgFsLWWcZQBE+xEIeRBgumNcRYCsuKC6XAM5lAZXusjF9iDIVgBKu8wpAgA7Y8 G9jAENEQDM6saniGKsYQCjixClzgIGLzXl1QHlVwgxqSNvsIHzGNFFv/gA2hsgLVwUOmcyphkEEU wAYP/Wtd4Di6wgRwiQE0kAFfwQJkcDssgAx20QRkIAEnQQZ2sw6hoGt3lCGjwIyvaKYUsA2FMCJ9 UAjGIAeksAt2N1zBsA3YDBHBEAUzUNEvYtIawQIaigE5AAFeMwpTjQFYbTcdAAGrIAfbEApcHQUP 8IoPsAxhPdZ7kQcvIAcTAAyk0QfrIJDnQNUQYSAsMAmNELuZEgu6UB4UcC54lT1ThBRELVTtVdPL YwnVQdoCUQWrLcoYsAChMAMM0Y4Su1zOY0LEcik5QQflUCFq0AznfCLzQAkB1BC5ocsEoS/FUAwy IAPFwAVhQAHlwAUt/zARXyAD3AAEPxAFxLzcDNgH7KsQbPAH8bc80HcOTaALmmAG6RAGoZCT+nAG 0ofeqAIDUVAEDFEMZ9AGKJAIFgkNzqAebbIl3KDgT0AJmfC4/h2hdCCiCAFSKpuPuDBuTPE2uCBs dF3hEVGlMiK2JO4kuDALBVDNAxEMRzCzKa5DcTgIfooQTcABDzjj/LQuw1UBZWniPF4zsVAOo9Cp HOqJQ343jgIG0r1jF9ANJbnkWkcHkJEGTsDG+lJcmTAKMlFgtX0y75mjYS4Q/cwEY37mai4TRVEe V1MecoALbj61gLTah2badm7n4QYg49bN8BG2SLHnHx7oGFABK/CCMP9CBYWABmEQCzMw14JiBAU2 C8eBC0rBBC3QB45dCkWQ2f+c2Zx+Ff/8FavgFVyxBOUgG73gFmywBEQ7D9/QNumQB3qRCb1wO+rw Dfhi6/8RDL2QH8GwBAVSDr3A1d9gEaOwBDDQf0UQbtvwDS/QAt0wAxT+EBSQCUaDC2QQCrHwCBBQ CKWACxBQAFgxCLFRCqZwCLFAB8gwAWfhDWLAFWgw16uABoCAAVfgDfcuARewDc9zAR2AASHgDZmt Dt5wFSFwAWYxCt6gszngDak+ChcgABhwDN5wO1pw8UxwDGjwHzPgDVRtAt7gNYBgCgvABGIwDv9h e00yFqdSo/ZRo4BJVIsC0QUZNBaqRwFdoHo4DyCdYBKxYCM+Txk+A/TzQBmxMA+MkvQyUQVKjxTz 0PRRTxU6oyGdIBNYsyphUFxUXx6lwPWusYsBAQA7 --=====_002_next=====-- --=====_001_next=====-- From nobody Sun Aug 8 01:08:16 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258C13A2094; Sun, 8 Aug 2021 01:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DEM7nN1YdGeO; Sun, 8 Aug 2021 01:08:06 -0700 (PDT) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3DC33A2092; Sun, 8 Aug 2021 01:08:05 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id w13-20020a17090aea0db029017897a5f7bcso1039963pjy.5; Sun, 08 Aug 2021 01:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J0EuWEkgxD3GuGoeOUgCJXJkBy/hrho4C0k3mBtWDFQ=; b=PzHwfpQLjmTcETmDRGr6WZRZeen6fL8lNZ7qio/IqfyXgdc/Wc0abWxvmQddlFrBeR fL2ikQTFcPkRlu10BDGjxqb+NxyQDMcvOnfd/wLcO1tCMEhvudzXxxNNjBl4zVZGIeGq 0WrMdqJ8DN2ley7ZjHp778wC/J5yawdvEP6rZ8Uf+HDfJrt+vYvxEMA7Ro7pjURtwlo1 nN4Sdp8li6dz1h5vSjWz2uUU0POh5zm3yDbWwVQ7UZdJ9kxh2dWWClTpikSILsJrOfq9 mPoo+DSpMqZqFL04AQAnRcmiUt3JJ//Cd/k6xGbTKPLQSxx1f6Ryn/A3sg2dTE6crrGu 2S1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J0EuWEkgxD3GuGoeOUgCJXJkBy/hrho4C0k3mBtWDFQ=; b=E357SbddnkHqZVZ/qYcZfDbRn+heGr0ERnwnJ+HpMm8bTuJq8hDUmKa5utK/gTIigz MQo9uI/tazpt4W+K1HYzNkW4Nhbb2lYAK36WLVhWolbilhzMG/TvuZssTfKaQW01Ve8w qMU7lGW0LwD/o1jUPHQp2c+5oAPJ8o2nQS0VHBm5ZK4vacfnMaPDu70Gz3/B7uNFFAS+ q+D9wDf8CeclfChFykoUa/4WNHyJl4ybl15cThJyvOVu2ON9Zh82UMKg1KUg+FYm6Nhp KQdmguSaVjV0s6BI8hQUyO55dWMf4LqU9PrI4W3Of+fZQ83oHC/PdnUxoxmavAbD6gMv 9JlQ== X-Gm-Message-State: AOAM531vN9o+tTNV8D+gvnmpXBS4Zern/82mXoXeX/HVHmD3O4kB/5HQ sQ16eJxTLREfe1fqjI14zpHAmLLBH5GCvXBqQWHgX7iEV2o= X-Google-Smtp-Source: ABdhPJy2SnzDUK1YFXmrkwxewLbsJxkIsESh4QEcH9oUleHbWcCyVimiFlc+K2X5nfshK0ZuXOxoAAyhekiqDV+1rDc= X-Received: by 2002:a17:90b:3547:: with SMTP id lt7mr5067200pjb.215.1628410084146; Sun, 08 Aug 2021 01:08:04 -0700 (PDT) MIME-Version: 1.0 References: <202108030547004200180@zte.com.cn> In-Reply-To: <202108030547004200180@zte.com.cn> From: Gyan Mishra Date: Sun, 8 Aug 2021 04:07:53 -0400 Message-ID: Subject: Re: [mpls] Seeking suggestions on the next steps to progress draft-ietf-mpls-bfd-directed To: gregory.mirsky@ztetx.com Cc: draft-ietf-mpls-bfd-directed@ietf.org, mpls@ietf.org, mpls-chairs@ietf.org, rtg-bfd@ietf.org Content-Type: multipart/related; boundary="0000000000009dbeb305c907c4de" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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, 08 Aug 2021 08:08:11 -0000 --0000000000009dbeb305c907c4de Content-Type: multipart/alternative; boundary="0000000000009dbeb205c907c4dd" --0000000000009dbeb205c907c4dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear MPLS WG chairs, I believe this draft has matured and is clearly written and coherent and a very helpful for operators to have this bidirectional return path feature to enable BFD co-routed paths for deterministic failure detection on localized paths for facilitate integrity testing. This feature is highly valuable to operators for in band facility integrity validation with BFD session using a bi-directional co-routed path. All technical comments have been addressed in the early RTGDIR review and the draft has been updated to reflect the comments. I believe this draft is now ready to progress to WGLC. Kind Regards Gyan On Mon, Aug 2, 2021 at 5:47 PM wrote: > Dear MPLS WG Chairs et al., > > We addressed all the technical comments from the early RtgDir review, > comments from Jeff Haas, added the Implementation Status section. The > authors of draft-ietf-mpls-bfd-directed are seeking your suggestions, > advice on the next steps that would lead to the WG LC on the draft. The > document is stable and, in the authors' opinion, is ready for the WG LC. > > > Regards, > > Greg Mirsky > > > Sr. Standardization Expert > =E9=A2=84=E7=A0=94=E6=A0=87=E5=87=86=E9=83=A8/=E6=9C=89=E7=BA=BF=E7=A0=94= =E7=A9=B6=E9=99=A2/=E6=9C=89=E7=BA=BF=E4=BA=A7=E5=93=81=E7=BB=8F=E8=90=A5= =E9=83=A8 Standard Preresearch Dept./Wireline Product R&D > Institute/Wireline Product Operation Division > > > > E: gregory.mirsky@ztetx.com > www.zte.com.cn > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --0000000000009dbeb205c907c4dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear MPLS WG chairs,

I believe this draft has matured and is clearly written and = coherent and a very helpful for operators to have this bidirectional return= path feature to enable BFD =C2=A0co-routed paths for deterministic failure= detection on localized paths for facilitate integrity testing.

This feature is highly valuable to = operators for in band facility integrity validation with BFD session using = a bi-directional co-routed path.

All technical comments have been addressed in the early RTGDIR= review and the draft has been updated to reflect the comments.

I believe =C2=A0this draft is now r= eady to progress to WGLC.

Kind Regards=C2=A0

Gya= n=C2=A0

=
On Mon, Aug 2, 2021 at 5:47 PM <gregory.mirsky@ztetx.com> = wrote:

Dear MPLS WG Chairs et al.,

= We addressed all the technical comments from the early RtgDir review, comme= nts from Jeff Haas, added the Implementation Status section. The authors of= draft-ietf-mpls-bfd-directed are seeking your suggestions, advice on the n= ext steps that would lead to the WG LC on the draft. The document is stable= and, in the authors' opinion, is ready for the WG LC.


<= span style=3D"font-family:=E5=BE=AE=E8=BD=AF=E9=9B=85=E9=BB=91;font-size:14= px;color:rgb(88,89,91)">Regards,

Greg Mirsky


Sr. Standardization Expert
=E9=A2=84=E7=A0=94=E6=A0=87=E5=87=86=E9=83=A8/=E6=9C=89=E7=BA=BF=E7=A0=94= =E7=A9=B6=E9=99=A2/=E6=9C=89=E7=BA=BF=E4=BA=A7=E5=93=81=E7=BB=8F=E8=90=A5= =E9=83=A8 Standard Preresearch D= ept./Wireline Product R&D Institute/Wireline Product Operation Division=



E: gregor= y.mirsky@ztetx.com
www.zte.com.cn
___________________________= ____________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--
--0000000000009dbeb205c907c4dd-- --0000000000009dbeb305c907c4de Content-Type: image/jpeg; name="9ae3e214c17d49ed935d87c674ba3ee2.jpg" Content-Disposition: inline; filename="9ae3e214c17d49ed935d87c674ba3ee2.jpg" Content-Transfer-Encoding: base64 Content-ID: <17b24bc4e23d7624e902> X-Attachment-Id: 17b24bc4e23d7624e902 R0lGODlhggB4AHcAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQICgAAACwAAAAAggB4AIcATr79vg2j x+twuSDo8tdNjNSk0mTQ57AojVB4uI7+1GPI3/P+6rKPxan9yjsBes4/gtD+34y61u9jm9rr9vva 7Pek0aolccv///8Baccki9Sj0FwSfM6DtOOAv2Wy1e9Mo92axurf78n9xisLacf+2XNwpN33+vE7 m9r9zkv+89Q0jNWMvebh7/nL5KPR5vbC3vP+5Jxks+NbpN10u+UDg9Gqzuyi0YLx9+aTvuYkhNF/ wDbZ7L0cjNQAdccAZMUlkta73Y0Ybsn+z1CUyk5LnNpiqd88k9f9whz+3YNNqt9EnNr0+/18vOaF weczm9oBjNQae879xzK426PV7fjc8vqIxCek0u79zEP+5qR8r+Cd0u5ss+O84vT+8Mlbqd8Le87M 6fdTnNrl8dMrg9G22e8BXcMKdMsrdcyUyuuMy+xtqd+s1vAsktb+9t3+1muy2Hqs1XTt+f1xsdvE 4/X9012BwQ3u9uIwjelDkteKxTTW6rr+23tTo939xCNEo91ro92DvPd7wOcchNKEwoQ8jNRtvOZN ltg8o90sm9qIvui02YOm0/kri9QLgM/m+f1dseIUg9EMjNQOZsZUqd8NW8I0k9cSdMv+4ZObzOwk fM/H6ff+6Ku24PN1wunV8frz+esyhNHN5quDvOZcnNrU6vczeM2bzVpxr+y/35R7viO73PLb7cOn 0mz++OTE4Z2s2vHj8/oSbsphpN6TyTwAbMmU0O6r05rb7vn9wRTN7PlDi9Ti8M1Dltj+7LvT6LRK ktaTxene+Pw3od2EyetbrOHL5fV0reAse86d2PF6vSlzteMCk9am2PEtldigz/Eckdaz1/Gt1IW6 3IRjreGz3PkBVMBNseEzltg8mOH9yC9sreFVrOBSltgcdMs9ltgkldmKwOdhueUeftAAddCMw+mB v+kNbcnn89ir0+6jzex6tOP90E/q9NyVyPBEqd7R56+k0nH9yTSz2/ILftB8w+mAvyP92G390VQK hNEBdMuEw+kAfdARftD+/v7///8I/wAxCBxIsKDBgwgTKlzIsKHDhxAJMimHAgaGckvoYNgHgg6T JktKMaFRpBSGZSBKyeECogIFLn1iYeDyxSW1LxRiFeMmh8kXarGq9KHGBNdPDLH6cImFC8QyDC9A 0MBABUQTJsaWNMFAZ8koDFn3MemyJBiGVX/SYJiHItNaFFsiLkwH4goTarXSYZihjw2GPvrSyQFx xiMKfRaPgFkV69slY7Es0aOCoVEkY1UaaYpValAkCnIG6SjVeQUFY5E0FAXTBtcmDnmYrHrwhKu+ IhTmnenDJJ0+EBg+1OJ9pdY2DMH0ycCQptayibW+ZvozT67BJrW4gFXXgusVmXS+c/9NR+HslfKr 0slMT0E2GyZr2bRf9YEJkw/RBKaLZj/aKgwUpFNdb/MwIUc6FgX4HwVX/BcLgkhd0QVS6mgUiw3G YICLOhnickWGpahTwUw1uGXdWcGU8kIaGp3o4oswMsSEEpKsUkoT1UVUzAMmxujjjz5SoUMtsFzx ADVyZfLFf0A26eRDxswTxhrArGJME/lBSUd5T3YZC3xdFtSUDuowBSYT8zC5EBMgaGBRmE3OM0sw XMKJQRP6RAemQKvkg8KeCTExgyUt2hkjE1xY0wguhlLRiD5PbFJQVto1xMSXhv54BQo01NnlRA/w eJB9Db3gUaY/XiqHobGAoI8zlBn/REEzOSokxiVZogrjKtzs4+mTqP0gw6oGrXJJHgzRgEKhup6I aAYrjAhnUhr4dVApXJi1UE6ANisXBcXU0kascFYhUqDdHmTMKr96CxEFkOiTCLldzgPJFQnFkkmu CYnhDb+6VlFPPYw6RMEXPzRi0kNXGMKsQhQYYY0l7fKpzxEMdSDGw6iyUUsGejnERDBkzCKTQ1UU Ys1xlqpDilgIlbJNOO5CtMouBXQRS8UHUdAJvQvF8skxppQD0SbEvkhHNDzbyUQYYawyAw0nF8QE FfPYUh0uIaRT1BZX0FF1QVfMEIwuW4q8yhqZpCtQLGlYq9Af+nxQ80Cj/KAP1QRV/wELSJHoA4S+ ZuiAyyj6PIANNVvoAmgzGphxBNBBI+zM2AStoo8lDIHEcbPzAFHLA50KVMoMD+SpzyW94ALDEUux EMUZqrehzkDz9FALGII0fVAslECK+UAVcGH03RGFro8+acQixxWa/NDDH4bYIilSq8YCSz3XgHPG D7MwQUEYooPBN0SxcKMPIr43tG77mc7TRiQg9EJDGKNQM0/SCDGhiyfcSFMf3gGNSPROLunTxzCG 97Z9MaQIl5Ab8qgShmVUQgfGIJVAVBCDJCShBAp4Ax8w4QWB2IcC67CGBmBxLgSqLxEMxEAZZIGs hYyiDxmaoOmoYIxllKNOWVCAA//8II8I4CMXSPADEkZQB04MZBViaB4V3MYQnfzAEjGsQBN6FCj4 xa8NjdgfmHyhgBH4YQQjkEcS+CCPETjAAW1EAj5KiJRYUIMM++DfQ9jQh2BQEQN/JAgd2BDDgP1h dLDYIB+kQEQ4ysMBUsBHDCJQhwjEoAR1SGMWTHiEH0Qikdapgh77tg98LaQIZ7Ab8iayPBnIxBUx wAIS5IEFB9QhCW9QQAmScA985DIFSYhAEmMgEHVEIgMgqEJEmHCFOVFRc5xbCAtmkcO7GaMNtYCV QDiByzfIEguYiEEddukANyoRCxHIAj4CMIJNMgESZwCDWt7VB2tgg2e4WAcXdZj/EDnsI3H7EIg6 bRmDN+AjAkI8IxbQSMs68OGhJXBAABzgBq4AIQN/oJxCZKPPQDZkFeK5G/B+0BoMeCEFSpRHCdLJ h1yMAB/4wEIJMBnOOsgDH5gogTxu6YqZZOCTEYmFRgcSi2CETCGHAeXd2ACCeSbBD1gYgjzkoYAy yuMenKCkF2KQgqrKAwkO4IMHIzACJ9JBDFxQ5kN00gs1GWQetYimQpoAgmq6KxZhUCsGFIAEEQ7x jG/AxBvekAIHYKKMSXRAYV+ahSTkogRvo0IVPEoQWOgjAzA7SPGOx0+FLIMDAcWAG/CBBD5koQ4p wIcCJimPRmKBD5eEIxZSIA8p/2BCmCmoaFZK4hCd1CISbjUIZcEyDy++qCcCkQMFllsFQFSCNwLh KxYGiwlOvAGODsBCLUeggDXyAR+0dAA7kmDVEqphEqaIhnJBAx8DYaAKm5AJBfZRA31Q4o8tCIYp bSWL2xlDHYxhQgX2EwtMuYgOf5ABBeighCcg4gnFUMcHCoWJJNIyBQ+VrXa164BcpCALb3CjTOvw RnkwAAO6SEMImoCIPyBiGGlgQibqwgXQrmR5PajVQVZBQ48GgxppuFIPuNEJY2QCGyCYxxWkdaIQ mOEMpQiBLDKgD73JQBgFeQMStjzR645gwxzuawzwoQ3tFvaN2tgkIGFBBr3V4v8HRfgEKczQhyWY YRmxEIMZejDPhFRgFLdb03rDAIstUQAX89CZgU9kjBlw4TTUWEIfvoCCfPRCx67IAghDSFgzErG1 KvUFJ1Lw5Vpmt5ybjMUyNJCIGdS5CJmQgzrEIKFyZGgV4VjFcD+aCeO6aGeRxUUskuGIWoSWIK5I thtU4AVu4mMEKSjBG9aYhDoQccMOWKIvuDIkQzCFCrho72QBOZDhtqAc+03IEs4QXF3RQQP6qIdD VJBV8mIBqhHgQznTmIKuVnQVjyJGkzSHAob82CP20WCmuqCBB8j7ISpAqRTayAdOhLAE+BArJgQC i4YLHEi42GJvq0ByybrbEvr/EEdEMHHGwmJBtZY0aApOjAE15AMMcanZKtJQigL7XFe4KMIPnlBI hPAhsQ7QhmIXGgAFDEQGP9CBjmN0uEAjVR/tRhUT1iGLPvhaIK7ggxmnasYA5KIOPRXIMkhQBL36 aB76+AZDylGMFyAvDPuYkHWCiIWpyoMdmEi7QIxhiHT7CBfm2Gf/9rRrH9knFlfw2omanQUGVLTc Si66ixSeEBikQWck/8S4DRXyfYTjHOMIg5OoEApjN94hVWeIGM7RNjkERfM+ioUMaqGDYjQCBbgP KggeIIkkD/xYDEkDFxamq1hA4gG1QAFkwkCHguXeGB7SQcIM/6JYqOGo6HLX/zpqUYsn6F0dOgBB 8BlysEbgKxxgEJdSdcWGclgfVZCoBTb0zoRRUPkqMbIPD/ADT0EBTQAGP3AEqhcjpbAMfZYQvVAL bRMUogcjuJAGnrAP+1APnjCBTfB5W6B3g4cNv5UGo2cdbDAI4sIkBsgBS+B2LgJXbcAQmXAMdGB7 VVCBCNQE1OAh8RcqeRIFXZAJP8ABzEcQufMAPQAC+mMdq+AM+pAP6TYrSrYN3BcR52Z1mRIGZ2AG mUAHRxAFGjCGUZAHhIYMCogQ9SAJoVJ+n6MQuLAEP0A66SIHS2ANS/B6LhINmbB+MTMPxrANVYIB m5AMsDAPsNAMGcIEzdAFVP/UBT1QA8xQAw/AWQ5RAUPiSj0zCrvAAnooJoDGECiQFy7SFP2QBnLw CJ84EMbQcFBQAzWgLQ0RC11AB2lwPqPyCauYObWAMQuRBpSwP0FRBX7IBP+UAQD4IojCAanTB0e4 EOWwG7sYERWwDzm3EDhIcroAg3B4GM6wgDAyXwn2jBs1CpWwAn4II5yHEPPQhyfSJw43jcJFVJgi B2pFASRXBbhAB13QBegGdB/IEIcgCwDzEFvwADUwfz8SC/vwBG3QNk0ABAXCBeCQCE/wBIPAAU4g j8lzDrGxEJmwDCZhe6vyeO1BRSMzOlMXI1XADWCQAT9ADVUADNZQDrHQCHr/szx6Yw7eoi+qtCZ0 0AlNYAlcUItXUARfMA/NwI0CMQ+RoE1N0gSpowFGoGuZAAgekQkz8AWGQAM04I6dZRDpsA/zUAXp sAyZIFl0MAq2ljajQgfkCCMVMIpPAAsncykmVGCgMUqZggvLIIvq1hcmxHgeFQtbIBhNEgYaQIDu sgevMAagwAup8As4gAOvkApjcAJj4AINQA7ZQINNEJcNoQ4/cAlZ5yIvcWnNcgKsEAcGIAKgsAdx 8Art0A5BAAesAAqsMA23EAwF6SSrUADdYHdNUgVhEAxr8B7pQAMDUw800AQZpA7Q+SKg8Au/wAt7 wAongAGg0A53IBB30A6g/8Cd7YADDpEOihAGBqJcfJkQxNglcpAHACADVXAEZrA8efIDo1AKoWAG AbWLr0AEogARVPCXDLEEtYCKOagLuthbadBrT9J/efAd20AGbXChjRAK6oALgFAIWzAPowCOEJEK qTCeD6EbNaQQ6nA/gMSeD5EJu3Oa6khUdFCj/Kie7yVUnTQVETEGvIBAaQB+geIsaaAPNSBBubcF LEJZYYBNxRARd+ACY2AdyDUX4XB/EJEJD5APK3lcMpAP+jAIlsiOPaAPlfIQonAKIiAXFbANY3oQ h3AOppRwL7qlXeoiVzAI/AAFm2NXBoEL8RIJircQe5AK7SAXq+CRDPEBNP9Qlgt6giCJkHd6IvtA D5L4AGE0V3lCCV+HAeFpHQ8ioxKxni7qEM2hDwoJI/PgijXQAzKQCUwpKGagASL4EHeQmXCSCTTA ZBFBB70gBrx6KGkwCOujBBwQBYjgCVtglzUHAgA2CqnaEL+wCFMaEaXwBV+xECQopBChC0OljDRg CQ3SCBlQC/oQCZqwDlWAAgAwA+3ZEC4QB9UKEXAnVwlxBSyApQ9BBTRgk0+CV/DRBSShA9DXdplA CuowjWPAAyaKPg7UEPZIjEHxrgWRCWZQC2/SJPi4J1ijBp6QI6pInQ3bJekwCl2Qg6JHBesHA2Iw A6L5IqNQCFr4JLzwCyP/6xAywwIMEYES9HrC8Ahdsg7IEAJ28gqtMK8PsQpnkKL3SjAncjh08q9U 0KkRcQBBcKhBdQWTKhEuAqOL8SSHxpEL0Q5I+y6UdQU0cIPD6IdFWgNbS6ng8Ax2wgoEYB3Xmq0K cQgkUHsk54dayqVPQgP54A5wkgpxgLXJcwa94FHpEAz66hB/+7Zy0Q434AFTcLM/0g6t8AonQgET 5jRpsKXV0CRjcApWYAWqEAeYS53YqZ2Gonzf+ou14AMWwAPfiQ6ikJu6eQDtcAJ3cAC5yZoHMKV3 8At7gAOgMAa/YAD2oAdEMAA7AA/tIAqQ+bt7MJ4iMLyeygPHiwFjIAo//xqblIkBv7ABQfCdLlIK lLAVC4GgtXd7+4oKcyANuBmbrXC17ZAKrZCbrHC/Y3AHrxAHooADrAAH1Dq9cKAHVkALp7ADypAK PNAKv9AOBTwNvADAAnwHIrAIi3DBomAALnCrixAHF2y1ZYuoDyB3CzEP5aC2OciU/RQLY8AK33kH PMALJxCZNOyprMALoJC8rHCod8AKsHkC7SACcKAMqkALqrADv2DDvYsDIsALOKCZQXwCBFzE7cAD vQsKIsAKVby635IOomo1dPoQL3AM65CODNEO8aAKdmAFiyDGYfmLInkiFlsLZTy5hIAACUDHE/QC s4C3gfmb7sMNS/EkjP+AB4FQxwVhLMDAEPUnEnJAkhDxCWxsMLhAsRNEAYUmIxT4CZ+wjVAyFJns EDDwAVSbKcvFECGwfIPZeGmQAWcguaG0C8jwhhNkDH9wpgkRp4acfEZqy9+yDD3oyHyytAyxCltw yhgQuWGyXLiQDi9bMwtGnOznOplQlhRABftBclQEzXASDEJwDMjsEOUAZHRgCJJwDfNgi+CACGyw BY/LBG0brUASDWLgFsLWWcZQBE+xEIeRBgumNcRYCsuKC6XAM5lAZXusjF9iDIVgBKu8wpAgA7Y8 G9jAENEQDM6saniGKsYQCjixClzgIGLzXl1QHlVwgxqSNvsIHzGNFFv/gA2hsgLVwUOmcyphkEEU wAYP/Wtd4Di6wgRwiQE0kAFfwQJkcDssgAx20QRkIAEnQQZ2sw6hoGt3lCGjwIyvaKYUsA2FMCJ9 UAjGIAeksAt2N1zBsA3YDBHBEAUzUNEvYtIawQIaigE5AAFeMwpTjQFYbTcdAAGrIAfbEApcHQUP 8IoPsAxhPdZ7kQcvIAcTAAyk0QfrIJDnQNUQYSAsMAmNELuZEgu6UB4UcC54lT1ThBRELVTtVdPL YwnVQdoCUQWrLcoYsAChMAMM0Y4Su1zOY0LEcik5QQflUCFq0AznfCLzQAkB1BC5ocsEoS/FUAwy IAPFwAVhQAHlwAUt/zARXyAD3AAEPxAFxLzcDNgH7KsQbPAH8bc80HcOTaALmmAG6RAGoZCT+nAG 0ofeqAIDUVAEDFEMZ9AGKJAIFgkNzqAebbIl3KDgT0AJmfC4/h2hdCCiCAFSKpuPuDBuTPE2uCBs dF3hEVGlMiK2JO4kuDALBVDNAxEMRzCzKa5DcTgIfooQTcABDzjj/LQuw1UBZWniPF4zsVAOo9Cp HOqJQ343jgIG0r1jF9ANJbnkWkcHkJEGTsDG+lJcmTAKMlFgtX0y75mjYS4Q/cwEY37mai4TRVEe V1MecoALbj61gLTah2badm7n4QYg49bN8BG2SLHnHx7oGFABK/CCMP9CBYWABmEQCzMw14JiBAU2 C8eBC0rBBC3QB45dCkWQ2f+c2Zx+Ff/8FavgFVyxBOUgG73gFmywBEQ7D9/QNumQB3qRCb1wO+rw Dfhi6/8RDL2QH8GwBAVSDr3A1d9gEaOwBDDQf0UQbtvwDS/QAt0wAxT+EBSQCUaDC2QQCrHwCBBQ CKWACxBQAFgxCLFRCqZwCLFAB8gwAWfhDWLAFWgw16uABoCAAVfgDfcuARewDc9zAR2AASHgDZmt Dt5wFSFwAWYxCt6gszngDak+ChcgABhwDN5wO1pw8UxwDGjwHzPgDVRtAt7gNYBgCgvABGIwDv9h e00yFqdSo/ZRo4BJVIsC0QUZNBaqRwFdoHo4DyCdYBKxYCM+Txk+A/TzQBmxMA+MkvQyUQVKjxTz 0PRRTxU6oyGdIBNYsyphUFxUXx6lwPWusYsBAQA7 --0000000000009dbeb305c907c4de Content-Type: image/jpeg; name="24242e5637af428891c4db731e7765ad.jpg" Content-Disposition: inline; filename="24242e5637af428891c4db731e7765ad.jpg" Content-Transfer-Encoding: base64 Content-ID: <17b24bc4e2258b2e99d1> X-Attachment-Id: 17b24bc4e2258b2e99d1 R0lGODlhcwAmAPcAAAAAAP///wCP1QCP1Pf7/vL5/QCP1gWR1gqT1gyU2AyU1w6V1xWY2BeZ2R6c 2iGd2iyi3C6j3TOl3Tqo3kWt4Emv4Uyw4U2x4lOz4ly35F645GO65WW75me85m6/53XC6IHH64XJ 64bK7IzM7I/N7JXQ7ZfR7pnS7pzT7p3U76PW8KPW76XX8K7b8bDc8rff87vh9Lzh9L7i9cnn9tLr +Nnu+eDx+uf0++n1++33/PD4/PT6/fj8/gKQ1AWR1QeS1QiT1QmT1g+W1xCW1xOX1xia2Bub2Ryb 2R+d2SCd2SKe2iSf2iag2ymh2yqh2yui3DSm3Tio3Typ3j2q3j6q3kCr30Os30eu4Euw4U6x4U+y 4k+y4VGz4lCy4Va141W04li241q341245F+55GW75Ga85Wm95mi95Gq+5Wu+5m2/5m/A53HB6HDA 53HB5nLB53PC53XC53bD53nE6HvF6X3G6X/H6YHI6oHI6YLI6oLI6YbK64TJ6YnL64rM64zM65HP 7JPQ7ZbR7ZrT7qXX76bY8KfY76jZ8Kra8azb8a/c8bDc8bHd8rLd8rXe8rXe8bjg87zi9Lzh873i 88Dj9MPl9cXm9cfm9cnn9c3p9s/q987p9tHr99Lr99Xt+Nbt+Nrv+d/x+eDx+eX0++Tz+u/4/OHy +ePz+ur2+/b7/fr9/vz+/v7//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAK0ALAAAAABzACYA Rwj/AAMIHEiwoMGDCBMqXMiwoUOGiti0mUhxopcBAgZoHKAglcATFaVg3DgAC0U2hgKsKkJyiZqK FUV4bHijx4AHDFmN0BiJ4A2NRFYRJKAAo6WFKzJibOCQEclMB1WxxOgDUQEeqbKm2sEDoQaMhAqS sonE4B2MeQ7WmGlwj0YKCv0oHeDkIUGnAvJCNShVowA7dgXyyXKhsGEJG6kYNqxFUEImGSsQDJFR gOSClUj61cx5wAmEBKJk9JIwTefTaxzaGNnQxhIBex0WAUPwRZoOZnLr3q27Q6CBKXgL742mhUBW e3AP771HlcNSaDjQCVwwByQc1A2+9vtbodONsQn2/8UI2O6F03lP+/1QcEpeJgMbabwyMEzeOQuJ bBSAyC5ejeENNN5GQzBAxIEHNgAGAQZ9JQAlBvUggBIGlYDWQBtYoKGGW1yw4YZacPGhBVjsIRAB B4xEV3YCfZdRgAKNJ0ATLBo01gBlOXSIARgpohAEeQkgSo1EFmnkkUgmqeSSCKkxl3qaMRUBZ5V1 llcHAaQ40lxP+uXQWALkmB0HGplhECYHWADDQ24oJYAVClHilwCgRMVSXiYGhgIZG/TZZxlXaNTD F2X4+adxA+Fg0wBkEGTfACkQhNgAKzR0iop0MvQdgHZu5EdgXw0AYUE2UViQhQKkVdAcQZYSAA9D GP/xxQ4B1KHRFg1h4OYYDzHiJowBDKgiSZXlSZAGeYVFEJhiDnRHXnoM5EOXxO7HmQMGdRJkRtj5 txmwMqoRWBZPplftuXEkxIUJBj2CxUJSVPkGi5sOAO5UA6hqJCql2sVKEBilcRCyAxhQB0GFqEet X3IglAhJlxzEAwPoaSaABV+S1VAmQ+RlREOTBHkGkySXbPLJKKes8sosC6TJllCS9JshC8NsbSUB eFAzZ244FIpSNfrRxADsGoRKQS/ETCWWIShspSMBUGyteu82dGOzCr3AR0EyaESFQU4OAJdDcBC7 SEJjuJmuQTzg+0SSNmG7ECuQDZBAQUlo9AlBg2D/BMVDm2wpQA4KOUISJ53mpa9DJVRmLkZcUgv1 QDRjRMNAI2SUmkAzYDSEcw3xMVcEmj7VqUblPSRGRl2ooMIKK6hAh0Y/kMBC7K9PkBceBeGwUaUB gLKRc/xqZIpD7vkFR0Obwna6AGiAqlEhBY1iUxIG5YFRtAZh1IYOAh090AIY9cRQAUBALsBRzM91 734CICDEAvQvoMAQGNBaELICKDvQ1Wa5kEBi4IJGNMITmTCgAhvhgg8o5QsvMKALcHaQSKRHAAro SlO+ZafHQQ5mAuhDg8AiFo0VBAQCDAAIMWWuKlWGKQZJg5vg5C2/vI92LujKKna4CtAdRAwa8QIL 7YY4xLPErwREHGIVMMI7km0nL4CgjovsdboBiNAumbPYsKpkLUQZRAZ5+dtAOrEAAXwtITjgkiey U68bDiB1RSKARo4QmEOkR3wDOUNlMnCQQrgJPvQyHV+KUCwkAfAhYMjLD4RyECxUJhEESeRmBCAB mMCkBAlpnhsHwAQPWHIifWCQ1UzIEFAEqQsLwQEQ8gIBgWiBS0qbI0JeMJcaHGQV04plXr6kEbkp hBVTEkAPjtcQOWSEVwGQxBw+wMxmOvOZHxiEQnIAgj1o8JZ/gKY2SeDDhejgDW1YnEI+AUm7fIKR LUunOtfJThYFBAA7 --0000000000009dbeb305c907c4de-- From nobody Tue Aug 10 20:52:24 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2091A3A103E; Tue, 10 Aug 2021 20:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 sjALbPmkPB9Y; Tue, 10 Aug 2021 20:52:16 -0700 (PDT) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 784DB3A103A; Tue, 10 Aug 2021 20:52:16 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id u13-20020a17090abb0db0290177e1d9b3f7so7557384pjr.1; Tue, 10 Aug 2021 20:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=tcJrSvmO0i8RV1DdlMN9bAkrOY4aLxP1uxf2vh6lUW0=; b=DIxjRIq+kKL0MsBqB0LMm8+u9pmWxGGuR9YiOHzWljVNcT1FLtH/Wr51tPg3UIeSA2 0hy0FA6jJ7Muzpc/cSraut2YTnbLAqzdRxwv5RoCW0EX7wl6Som3DhK86ba8smMlDgsl mCZTmiAx9jD4qcEpSwnvlOODMqYhE63Y5nY0k0kChnhgEG61rRddqidSVRy/3Rov4lc0 zvBODmu1mQYUIW9LL6s1neSp0NMAkfctgZDpXkN3QJfuzWcKrzCzdpI0dLBmbEknyDrq 5XU4waUMhmNfBKh1q0RFuupDu1U5XIDtYnpfgk82jK8tjcRoh2yR50vhjYJ2VdsrhoGq 6wZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=tcJrSvmO0i8RV1DdlMN9bAkrOY4aLxP1uxf2vh6lUW0=; b=YKQq8uT8csYjEjoZRyRSqGphGB2a1dwV61kaS7Mp1+4Qc2xsSHzNPe4HNbYKG4F5FW 9giAj0ryN8I17o67rqvpPxpRW7m3HcDooTJal/NCGOsM3E6jvUA9vygKQxWPQ90IXCK+ yn4PaC0Jw9WDanRYWk2EzOhQ3j9hr5kcdxYPmlJHVA/OAr2opjR3He0BWC0DbANkc9Jf sPFNXAfuleMml03nA+Zfbv2PFUXVEcPL8sewMjTkxyx8/DKBhqo6mBk6+AogoyRASMcB KSJwzxpubq2+CI8G1fIRnfaLhHjwbXKoTeHByY3nNXFnUChpo/Vn1C1bh2xFQuAb9ItE y3Yg== X-Gm-Message-State: AOAM531yF8O2AHvpmK5arhvQzIYKlt4QwVetPuOHAhrODcLtJ7B/ugRh 7dWX3uWmPrJAJ7yaWwxmnCNEKo4LqRzTng== X-Google-Smtp-Source: ABdhPJzm1mdJziOOwWgu7QYc8dNaBgz2b5j6LlDDEaj82x2N29+sM4/5Tk+UoiHvr7poVB0GmWCTAQ== X-Received: by 2002:a62:dd83:0:b029:30f:d69:895f with SMTP id w125-20020a62dd830000b029030f0d69895fmr26481985pff.17.1628653934288; Tue, 10 Aug 2021 20:52:14 -0700 (PDT) Received: from smtpclient.apple (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id c2sm30768463pgh.82.2021.08.10.20.52.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Aug 2021 20:52:13 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B15A27AD-7C63-4F35-BD2C-1DA9A1BF226A Content-Transfer-Encoding: 7bit From: Jeff Tantsura Mime-Version: 1.0 (1.0) Subject: Re: [mpls] Seeking suggestions on the next steps to progress draft-ietf-mpls-bfd-directed Date: Tue, 10 Aug 2021 20:52:12 -0700 Message-Id: <11D67500-D33A-40B7-9F09-E4997C5A62D8@gmail.com> References: Cc: gregory.mirsky@ztetx.com, draft-ietf-mpls-bfd-directed@ietf.org, mpls@ietf.org, mpls-chairs@ietf.org, rtg-bfd@ietf.org In-Reply-To: To: Gyan Mishra X-Mailer: iPhone Mail (18G82) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 03:52:22 -0000 --Apple-Mail-B15A27AD-7C63-4F35-BD2C-1DA9A1BF226A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Same view here, I believe the draft is ready to progress.=20 Thanks! Cheers, Jeff > On Aug 8, 2021, at 01:08, Gyan Mishra wrote: >=20 > =EF=BB=BF > Dear MPLS WG chairs, >=20 > I believe this draft has matured and is clearly written and coherent and a= very helpful for operators to have this bidirectional return path feature t= o enable BFD co-routed paths for deterministic failure detection on localiz= ed paths for facilitate integrity testing. >=20 > This feature is highly valuable to operators for in band facility integrit= y validation with BFD session using a bi-directional co-routed path. >=20 > All technical comments have been addressed in the early RTGDIR review and t= he draft has been updated to reflect the comments. >=20 > I believe this draft is now ready to progress to WGLC. >=20 > Kind Regards=20 >=20 > Gyan=20 >=20 >> On Mon, Aug 2, 2021 at 5:47 PM wrote: >> Dear MPLS WG Chairs et al., >>=20 >> We addressed all the technical comments from the early RtgDir review, com= ments from Jeff Haas, added the Implementation Status section. The authors o= f draft-ietf-mpls-bfd-directed are seeking your suggestions, advice on the n= ext steps that would lead to the WG LC on the draft. The document is stable a= nd, in the authors' opinion, is ready for the WG LC. >>=20 >>=20 >>=20 >> Regards, >>=20 >> Greg Mirsky >>=20 >>=20 >>=20 >> Sr. Standardization Expert >> =E9=A2=84=E7=A0=94=E6=A0=87=E5=87=86=E9=83=A8/=E6=9C=89=E7=BA=BF=E7=A0=94= =E7=A9=B6=E9=99=A2/=E6=9C=89=E7=BA=BF=E4=BA=A7=E5=93=81=E7=BB=8F=E8=90=A5=E9= =83=A8 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Pr= oduct Operation Division >>=20 >>=20 >>=20 >> <9ae3e214c17d49ed935d87c674ba3ee2.jpg> >> <24242e5637af428891c4db731e7765ad.jpg> >>=20 >> E: gregory.mirsky@ztetx.com=20 >> www.zte.com.cn >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > --=20 >=20 >=20 > Gyan Mishra > Network Solutions Architect=20 > Email gyan.s.mishra@verizon.com > M 301 502-1347 >=20 >=20 --Apple-Mail-B15A27AD-7C63-4F35-BD2C-1DA9A1BF226A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Same view here, I believe the draft is read= y to progress. 
Thanks!

Cheers,
Jeff

On Aug 8, 2= 021, at 01:08, Gyan Mishra <hayabusagsm@gmail.com> wrote:

=EF=BB=BF
Dear MPLS WG chairs,

I believe this draft has matured and is clearly written and coherent and a= very helpful for operators to have this bidirectional return path feature t= o enable BFD  co-routed paths for deterministic failure detection on lo= calized paths for facilitate integrity testing.

<= /div>
This feature is highly valuable to operators for in b= and facility integrity validation with BFD session using a bi-directional co= -routed path.

All tec= hnical comments have been addressed in the early RTGDIR review and the draft= has been updated to reflect the comments.

=
I believe  this draft is now ready to progress to WGL= C.

Kind Regards 

Gyan 

On Mon, Aug 2, 2021 at 5:47 PM <gregory.mirsky@ztetx.com> wrote:

Dear MPLS WG Chairs et al.,

We addressed all the technical c= omments from the early RtgDir review, comments from Jeff Haas, added the Imp= lementation Status section. The authors of draft-ietf-mpls-bfd-directed are s= eeking your suggestions, advice on the next steps that would lead to the WG L= C on the draft. The document is stable and, in the authors' opinion, is read= y for the WG LC.


<= /p>

Regards,

Greg Mirsky


Sr. Standardization Expert<= /font>
=E9=A2=84=E7=A0=94=E6=A0=87=E5=87=86=E9=83=A8/=E6=9C=89=E7=BA=BF=E7=A0=94=E7= =A9=B6=E9=99=A2/=E6=9C=89=E7=BA=BF=E4=BA=A7=E5=93=81=E7=BB=8F=E8=90=A5=E9=83= =A8 Standard Preresearch Dept./Wir= eline Product R&D Institute/Wireline Product Operation Division

<= span style=3D"font-family:=E5=BE=AE=E8=BD=AF=E9=9B=85=E9=BB=91">
<= /span>

= _________________________________= ______________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--


<= i>Network Solutions Architect 

Email gyan.s.mishra@verizon.com

M 301= 502-1347


= --Apple-Mail-B15A27AD-7C63-4F35-BD2C-1DA9A1BF226A-- From nobody Tue Aug 10 21:10:21 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68273A114E; Tue, 10 Aug 2021 21:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 fR_hX5ABY5w1; Tue, 10 Aug 2021 21:10:09 -0700 (PDT) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 24C163A1148; Tue, 10 Aug 2021 21:10:07 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.5]) by rmmx-syy-dmz-app06-12006 (RichMail) with SMTP id 2ee661134d93a36-5ea37; Wed, 11 Aug 2021 12:09:55 +0800 (CST) X-RM-TRANSID: 2ee661134d93a36-5ea37 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[10.2.55.93]) by rmsmtp-syy-appsvr03-12003 (RichMail) with SMTP id 2ee361134d90fdb-1fc8a; Wed, 11 Aug 2021 12:09:55 +0800 (CST) X-RM-TRANSID: 2ee361134d90fdb-1fc8a From: "Weiqiang Cheng" To: , , Cc: , References: <202108030547004200180@zte.com.cn> In-Reply-To: <202108030547004200180@zte.com.cn> Subject: Re: [mpls] Seeking suggestions on the next steps to progress draft-ietf-mpls-bfd-directed Date: Wed, 11 Aug 2021 12:09:54 +0800 Message-ID: <01ed01d78e66$bd9620e0$38c262a0$@com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_01EE_01D78EA9.CBB960E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdeH6PTN0chn1wtASmmmrgOBQDTHVwGfXC4w Content-Language: zh-cn Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 04:10:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01EE_01D78EA9.CBB960E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01EF_01D78EA9.CBB960E0" ------=_NextPart_001_01EF_01D78EA9.CBB960E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, The draft is valuable to operators. I believe that the draft is now ready to progress to WGLC. =20 B.R. Weiqiang Cheng =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: mpls [mailto:mpls-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 gregory.mirsky@ztetx.com =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2021=E5=B9=B48=E6=9C=883=E6=97=A5 = 05:47 =E6=94=B6=E4=BB=B6=E4=BA=BA: mpls-chairs@ietf.org; mpls@ietf.org =E6=8A=84=E9=80=81: draft-ietf-mpls-bfd-directed@ietf.org; = rtg-bfd@ietf.org =E4=B8=BB=E9=A2=98: [mpls] Seeking suggestions on the next steps to = progress draft-ietf-mpls-bfd-directed =20 Dear MPLS WG Chairs et al., We addressed all the technical comments from the early RtgDir review, = comments from Jeff Haas, added the Implementation Status section. The = authors of draft-ietf-mpls-bfd-directed are seeking your suggestions, = advice on the next steps that would lead to the WG LC on the draft. The = document is stable and, in the authors' opinion, is ready for the WG LC. =20 Regards, Greg Mirsky =20 Sr. Standardization Expert =E9=A2=84=E7=A0=94=E6=A0=87=E5=87=86=E9=83=A8/=E6=9C=89=E7=BA=BF=E7=A0=94= =E7=A9=B6=E9=99=A2/=E6=9C=89=E7=BA=BF=E4=BA=A7=E5=93=81=E7=BB=8F=E8=90=A5= =E9=83=A8 Standard Preresearch Dept./Wireline Product R&D = Institute/Wireline Product Operation Division =20 E: gregory.mirsky@ztetx.com=20 www.zte.com.cn =20 =20 ------=_NextPart_001_01EF_01D78EA9.CBB960E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

The draft is valuable to operators.

I believe that the draft is now ready to progress to = WGLC.

 

B.R.

Weiqiang Cheng

 

=E5=8F=91=E4=BB=B6=E4=BA=BA: mpls [mailto:mpls-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 = gregory.mirsky@ztetx.com
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2021=E5=B9=B48=E6=9C=883=E6=97=A5 05:47
=E6=94=B6=E4=BB=B6=E4=BA=BA: mpls-chairs@ietf.org; = mpls@ietf.org
=E6=8A=84=E9=80=81: = draft-ietf-mpls-bfd-directed@ietf.org; = rtg-bfd@ietf.org
=E4=B8=BB=E9=A2=98: [mpls] Seeking suggestions = on the next steps to progress = draft-ietf-mpls-bfd-directed

 

Dear = MPLS WG Chairs et al.,

We = addressed all the technical comments from the early RtgDir review, = comments from Jeff Haas, added the Implementation Status section. The = authors of draft-ietf-mpls-bfd-directed are seeking your suggestions, = advice on the next steps that would lead to the WG LC on the draft. The = document is stable and, in the authors' opinion, is ready for the WG = LC.

 

Regards,

Greg Mirsky

 

Sr. Standardization Expert
=E9=A2=84=E7=A0=94=E6=A0=87=E5=87=86=E9=83=A8= /=E6=9C=89=E7=BA=BF=E7=A0=94=E7=A9=B6=E9=99=A2/=E6=9C=89=E7=BA=BF=E4=BA=A7=E5=93=81=E7=BB=8F=E8=90=A5= =E9=83=A8 = Standard Preresearch Dept./Wireline Product R&D Institute/Wireline = Product Operation Division

 

<9ae3e214c17d49ed935d87c674ba3ee2.jpg>
<24242e5637af428891c4db731e7765ad.jpg>= ;

E: gregory= .mirsky@ztetx.com
www.zte.com.cn


E: gregory.mirsky@ztetx.com
www.zte.com.cn

 

------=_NextPart_001_01EF_01D78EA9.CBB960E0-- ------=_NextPart_000_01EE_01D78EA9.CBB960E0 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhggB4AHcAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQICgAAACwAAAAAggB4AIcATr79vg2j x+twuSDo8tdNjNSk0mTQ57AojVB4uI7+1GPI3/P+6rKPxan9yjsBes4/gtD+34y61u9jm9rr9vva 7Pek0aolccv///8Baccki9Sj0FwSfM6DtOOAv2Wy1e9Mo92axurf78n9xisLacf+2XNwpN33+vE7 m9r9zkv+89Q0jNWMvebh7/nL5KPR5vbC3vP+5Jxks+NbpN10u+UDg9Gqzuyi0YLx9+aTvuYkhNF/ wDbZ7L0cjNQAdccAZMUlkta73Y0Ybsn+z1CUyk5LnNpiqd88k9f9whz+3YNNqt9EnNr0+/18vOaF weczm9oBjNQae879xzK426PV7fjc8vqIxCek0u79zEP+5qR8r+Cd0u5ss+O84vT+8Mlbqd8Le87M 6fdTnNrl8dMrg9G22e8BXcMKdMsrdcyUyuuMy+xtqd+s1vAsktb+9t3+1muy2Hqs1XTt+f1xsdvE 4/X9012BwQ3u9uIwjelDkteKxTTW6rr+23tTo939xCNEo91ro92DvPd7wOcchNKEwoQ8jNRtvOZN ltg8o90sm9qIvui02YOm0/kri9QLgM/m+f1dseIUg9EMjNQOZsZUqd8NW8I0k9cSdMv+4ZObzOwk fM/H6ff+6Ku24PN1wunV8frz+esyhNHN5quDvOZcnNrU6vczeM2bzVpxr+y/35R7viO73PLb7cOn 0mz++OTE4Z2s2vHj8/oSbsphpN6TyTwAbMmU0O6r05rb7vn9wRTN7PlDi9Ti8M1Dltj+7LvT6LRK ktaTxene+Pw3od2EyetbrOHL5fV0reAse86d2PF6vSlzteMCk9am2PEtldigz/Eckdaz1/Gt1IW6 3IRjreGz3PkBVMBNseEzltg8mOH9yC9sreFVrOBSltgcdMs9ltgkldmKwOdhueUeftAAddCMw+mB v+kNbcnn89ir0+6jzex6tOP90E/q9NyVyPBEqd7R56+k0nH9yTSz2/ILftB8w+mAvyP92G390VQK hNEBdMuEw+kAfdARftD+/v7///8I/wAxCBxIsKDBgwgTKlzIsKHDhxAJMimHAgaGckvoYNgHgg6T JktKMaFRpBSGZSBKyeECogIFLn1iYeDyxSW1LxRiFeMmh8kXarGq9KHGBNdPDLH6cImFC8QyDC9A 0MBABUQTJsaWNMFAZ8koDFn3MemyJBiGVX/SYJiHItNaFFsiLkwH4goTarXSYZihjw2GPvrSyQFx xiMKfRaPgFkV69slY7Es0aOCoVEkY1UaaYpValAkCnIG6SjVeQUFY5E0FAXTBtcmDnmYrHrwhKu+ IhTmnenDJJ0+EBg+1OJ9pdY2DMH0ycCQptayibW+ZvozT67BJrW4gFXXgusVmXS+c/9NR+HslfKr 0slMT0E2GyZr2bRf9YEJkw/RBKaLZj/aKgwUpFNdb/MwIUc6FgX4HwVX/BcLgkhd0QVS6mgUiw3G YICLOhnickWGpahTwUw1uGXdWcGU8kIaGp3o4oswMsSEEpKsUkoT1UVUzAMmxujjjz5SoUMtsFzx ADVyZfLFf0A26eRDxswTxhrArGJME/lBSUd5T3YZC3xdFtSUDuowBSYT8zC5EBMgaGBRmE3OM0sw XMKJQRP6RAemQKvkg8KeCTExgyUt2hkjE1xY0wguhlLRiD5PbFJQVto1xMSXhv54BQo01NnlRA/w eJB9Db3gUaY/XiqHobGAoI8zlBn/REEzOSokxiVZogrjKtzs4+mTqP0gw6oGrXJJHgzRgEKhup6I aAYrjAhnUhr4dVApXJi1UE6ANisXBcXU0kascFYhUqDdHmTMKr96CxEFkOiTCLldzgPJFQnFkkmu CYnhDb+6VlFPPYw6RMEXPzRi0kNXGMKsQhQYYY0l7fKpzxEMdSDGw6iyUUsGejnERDBkzCKTQ1UU Ys1xlqpDilgIlbJNOO5CtMouBXQRS8UHUdAJvQvF8skxppQD0SbEvkhHNDzbyUQYYawyAw0nF8QE FfPYUh0uIaRT1BZX0FF1QVfMEIwuW4q8yhqZpCtQLGlYq9Af+nxQ80Cj/KAP1QRV/wELSJHoA4S+ ZuiAyyj6PIANNVvoAmgzGphxBNBBI+zM2AStoo8lDIHEcbPzAFHLA50KVMoMD+SpzyW94ALDEUux EMUZqrehzkDz9FALGII0fVAslECK+UAVcGH03RGFro8+acQixxWa/NDDH4bYIilSq8YCSz3XgHPG D7MwQUEYooPBN0SxcKMPIr43tG77mc7TRiQg9EJDGKNQM0/SCDGhiyfcSFMf3gGNSPROLunTxzCG 97Z9MaQIl5Ab8qgShmVUQgfGIJVAVBCDJCShBAp4Ax8w4QWB2IcC67CGBmBxLgSqLxEMxEAZZIGs hYyiDxmaoOmoYIxllKNOWVCAA//8II8I4CMXSPADEkZQB04MZBViaB4V3MYQnfzAEjGsQBN6FCj4 xa8NjdgfmHyhgBH4YQQjkEcS+CCPETjAAW1EAj5KiJRYUIMM++DfQ9jQh2BQEQN/JAgd2BDDgP1h dLDYIB+kQEQ4ysMBUsBHDCJQhwjEoAR1SGMWTHiEH0Qikdapgh77tg98LaQIZ7Ab8iayPBnIxBUx wAIS5IEFB9QhCW9QQAmScA985DIFSYhAEmMgEHVEIgMgqEJEmHCFOVFRc5xbCAtmkcO7GaMNtYCV QDiByzfIEguYiEEddukANyoRCxHIAj4CMIJNMgESZwCDWt7VB2tgg2e4WAcXdZj/EDnsI3H7EIg6 bRmDN+AjAkI8IxbQSMs68OGhJXBAABzgBq4AIQN/oJxCZKPPQDZkFeK5G/B+0BoMeCEFSpRHCdLJ h1yMAB/4wEIJMBnOOsgDH5gogTxu6YqZZOCTEYmFRgcSi2CETCGHAeXd2ACCeSbBD1gYgjzkoYAy yuMenKCkF2KQgqrKAwkO4IMHIzACJ9JBDFxQ5kN00gs1GWQetYimQpoAgmq6KxZhUCsGFIAEEQ7x jG/AxBvekAIHYKKMSXRAYV+ahSTkogRvo0IVPEoQWOgjAzA7SPGOx0+FLIMDAcWAG/CBBD5koQ4p wIcCJimPRmKBD5eEIxZSIA8p/2BCmCmoaFZK4hCd1CISbjUIZcEyDy++qCcCkQMFllsFQFSCNwLh KxYGiwlOvAGODsBCLUeggDXyAR+0dAA7kmDVEqphEqaIhnJBAx8DYaAKm5AJBfZRA31Q4o8tCIYp bSWL2xlDHYxhQgX2EwtMuYgOf5ABBeighCcg4gnFUMcHCoWJJNIyBQ+VrXa164BcpCALb3CjTOvw RnkwAAO6SEMImoCIPyBiGGlgQibqwgXQrmR5PajVQVZBQ48GgxppuFIPuNEJY2QCGyCYxxWkdaIQ mOEMpQiBLDKgD73JQBgFeQMStjzR645gwxzuawzwoQ3tFvaN2tgkIGFBBr3V4v8HRfgEKczQhyWY YRmxEIMZejDPhFRgFLdb03rDAIstUQAX89CZgU9kjBlw4TTUWEIfvoCCfPRCx67IAghDSFgzErG1 KvUFJ1Lw5Vpmt5ybjMUyNJCIGdS5CJmQgzrEIKFyZGgV4VjFcD+aCeO6aGeRxUUskuGIWoSWIK5I thtU4AVu4mMEKSjBG9aYhDoQccMOWKIvuDIkQzCFCrho72QBOZDhtqAc+03IEs4QXF3RQQP6qIdD VJBV8mIBqhHgQznTmIKuVnQVjyJGkzSHAob82CP20WCmuqCBB8j7ISpAqRTayAdOhLAE+BArJgQC i4YLHEi42GJvq0ByybrbEvr/EEdEMHHGwmJBtZY0aApOjAE15AMMcanZKtJQigL7XFe4KMIPnlBI hPAhsQ7QhmIXGgAFDEQGP9CBjmN0uEAjVR/tRhUT1iGLPvhaIK7ggxmnasYA5KIOPRXIMkhQBL36 aB76+AZDylGMFyAvDPuYkHWCiIWpyoMdmEi7QIxhiHT7CBfm2Gf/9rRrH9knFlfw2omanQUGVLTc Si66ixSeEBikQWck/8S4DRXyfYTjHOMIg5OoEApjN94hVWeIGM7RNjkERfM+ioUMaqGDYjQCBbgP KggeIIkkD/xYDEkDFxamq1hA4gG1QAFkwkCHguXeGB7SQcIM/6JYqOGo6HLX/zpqUYsn6F0dOgBB 8BlysEbgKxxgEJdSdcWGclgfVZCoBTb0zoRRUPkqMbIPD/ADT0EBTQAGP3AEqhcjpbAMfZYQvVAL bRMUogcjuJAGnrAP+1APnjCBTfB5W6B3g4cNv5UGo2cdbDAI4sIkBsgBS+B2LgJXbcAQmXAMdGB7 VVCBCNQE1OAh8RcqeRIFXZAJP8ABzEcQufMAPQAC+mMdq+AM+pAP6TYrSrYN3BcR52Z1mRIGZ2AG mUAHRxAFGjCGUZAHhIYMCogQ9SAJoVJ+n6MQuLAEP0A66SIHS2ANS/B6LhINmbB+MTMPxrANVYIB m5AMsDAPsNAMGcIEzdAFVP/UBT1QA8xQAw/AWQ5RAUPiSj0zCrvAAnooJoDGECiQFy7SFP2QBnLw CJ84EMbQcFBQAzWgLQ0RC11AB2lwPqPyCauYObWAMQuRBpSwP0FRBX7IBP+UAQD4IojCAanTB0e4 EOWwG7sYERWwDzm3EDhIcroAg3B4GM6wgDAyXwn2jBs1CpWwAn4II5yHEPPQhyfSJw43jcJFVJgi B2pFASRXBbhAB13QBegGdB/IEIcgCwDzEFvwADUwfz8SC/vwBG3QNk0ABAXCBeCQCE/wBIPAAU4g j8lzDrGxEJmwDCZhe6vyeO1BRSMzOlMXI1XADWCQAT9ADVUADNZQDrHQCHr/szx6Yw7eoi+qtCZ0 0AlNYAlcUItXUARfMA/NwI0CMQ+RoE1N0gSpowFGoGuZAAgekQkz8AWGQAM04I6dZRDpsA/zUAXp sAyZIFl0MAq2ljajQgfkCCMVMIpPAAsncykmVGCgMUqZggvLIIvq1hcmxHgeFQtbIBhNEgYaQIDu sgevMAagwAup8As4gAOvkApjcAJj4AINQA7ZQINNEJcNoQ4/cAlZ5yIvcWnNcgKsEAcGIAKgsAdx 8Art0A5BAAesAAqsMA23EAwF6SSrUADdYHdNUgVhEAxr8B7pQAMDUw800AQZpA7Q+SKg8Au/wAt7 wAongAGg0A53IBB30A6g/8Cd7YADDpEOihAGBqJcfJkQxNglcpAHACADVXAEZrA8efIDo1AKoWAG AbWLr0AEogARVPCXDLEEtYCKOagLuthbadBrT9J/efAd20AGbXChjRAK6oALgFAIWzAPowCOEJEK qTCeD6EbNaQQ6nA/gMSeD5EJu3Oa6khUdFCj/Kie7yVUnTQVETEGvIBAaQB+geIsaaAPNSBBubcF LEJZYYBNxRARd+ACY2AdyDUX4XB/EJEJD5APK3lcMpAP+jAIlsiOPaAPlfIQonAKIiAXFbANY3oQ h3AOppRwL7qlXeoiVzAI/AAFm2NXBoEL8RIJircQe5AK7SAXq+CRDPEBNP9Qlgt6giCJkHd6IvtA D5L4AGE0V3lCCV+HAeFpHQ8ioxKxni7qEM2hDwoJI/PgijXQAzKQCUwpKGagASL4EHeQmXCSCTTA ZBFBB70gBrx6KGkwCOujBBwQBYjgCVtglzUHAgA2CqnaEL+wCFMaEaXwBV+xECQopBChC0OljDRg CQ3SCBlQC/oQCZqwDlWAAgAwA+3ZEC4QB9UKEXAnVwlxBSyApQ9BBTRgk0+CV/DRBSShA9DXdplA CuowjWPAAyaKPg7UEPZIjEHxrgWRCWZQC2/SJPi4J1ijBp6QI6pInQ3bJekwCl2Qg6JHBesHA2Iw A6L5IqNQCFr4JLzwCyP/6xAywwIMEYES9HrC8Ahdsg7IEAJ28gqtMK8PsQpnkKL3SjAncjh08q9U 0KkRcQBBcKhBdQWTKhEuAqOL8SSHxpEL0Q5I+y6UdQU0cIPD6IdFWgNbS6ng8Ax2wgoEYB3Xmq0K cQgkUHsk54dayqVPQgP54A5wkgpxgLXJcwa94FHpEAz66hB/+7Zy0Q434AFTcLM/0g6t8AonQgET 5jRpsKXV0CRjcApWYAWqEAeYS53YqZ2Gonzf+ou14AMWwAPfiQ6ikJu6eQDtcAJ3cAC5yZoHMKV3 8At7gAOgMAa/YAD2oAdEMAA7AA/tIAqQ+bt7MJ4iMLyeygPHiwFjIAo//xqblIkBv7ABQfCdLlIK lLAVC4GgtXd7+4oKcyANuBmbrXC17ZAKrZCbrHC/Y3AHrxAHooADrAAH1Dq9cKAHVkALp7ADypAK PNAKv9AOBTwNvADAAnwHIrAIi3DBomAALnCrixAHF2y1ZYuoDyB3CzEP5aC2OciU/RQLY8AK33kH PMALJxCZNOyprMALoJC8rHCod8AKsHkC7SACcKAMqkALqrADv2DDvYsDIsALOKCZQXwCBFzE7cAD vQsKIsAKVby635IOomo1dPoQL3AM65CODNEO8aAKdmAFiyDGYfmLInkiFlsLZTy5hIAACUDHE/QC s4C3gfmb7sMNS/EkjP+AB4FQxwVhLMDAEPUnEnJAkhDxCWxsMLhAsRNEAYUmIxT4CZ+wjVAyFJns EDDwAVSbKcvFECGwfIPZeGmQAWcguaG0C8jwhhNkDH9wpgkRp4acfEZqy9+yDD3oyHyytAyxCltw yhgQuWGyXLiQDi9bMwtGnOznOplQlhRABftBclQEzXASDEJwDMjsEOUAZHRgCJJwDfNgi+CACGyw BY/LBG0brUASDWLgFsLWWcZQBE+xEIeRBgumNcRYCsuKC6XAM5lAZXusjF9iDIVgBKu8wpAgA7Y8 G9jAENEQDM6saniGKsYQCjixClzgIGLzXl1QHlVwgxqSNvsIHzGNFFv/gA2hsgLVwUOmcyphkEEU wAYP/Wtd4Di6wgRwiQE0kAFfwQJkcDssgAx20QRkIAEnQQZ2sw6hoGt3lCGjwIyvaKYUsA2FMCJ9 UAjGIAeksAt2N1zBsA3YDBHBEAUzUNEvYtIawQIaigE5AAFeMwpTjQFYbTcdAAGrIAfbEApcHQUP 8IoPsAxhPdZ7kQcvIAcTAAyk0QfrIJDnQNUQYSAsMAmNELuZEgu6UB4UcC54lT1ThBRELVTtVdPL YwnVQdoCUQWrLcoYsAChMAMM0Y4Su1zOY0LEcik5QQflUCFq0AznfCLzQAkB1BC5ocsEoS/FUAwy IAPFwAVhQAHlwAUt/zARXyAD3AAEPxAFxLzcDNgH7KsQbPAH8bc80HcOTaALmmAG6RAGoZCT+nAG 0ofeqAIDUVAEDFEMZ9AGKJAIFgkNzqAebbIl3KDgT0AJmfC4/h2hdCCiCAFSKpuPuDBuTPE2uCBs dF3hEVGlMiK2JO4kuDALBVDNAxEMRzCzKa5DcTgIfooQTcABDzjj/LQuw1UBZWniPF4zsVAOo9Cp HOqJQ343jgIG0r1jF9ANJbnkWkcHkJEGTsDG+lJcmTAKMlFgtX0y75mjYS4Q/cwEY37mai4TRVEe V1MecoALbj61gLTah2badm7n4QYg49bN8BG2SLHnHx7oGFABK/CCMP9CBYWABmEQCzMw14JiBAU2 C8eBC0rBBC3QB45dCkWQ2f+c2Zx+Ff/8FavgFVyxBOUgG73gFmywBEQ7D9/QNumQB3qRCb1wO+rw Dfhi6/8RDL2QH8GwBAVSDr3A1d9gEaOwBDDQf0UQbtvwDS/QAt0wAxT+EBSQCUaDC2QQCrHwCBBQ CKWACxBQAFgxCLFRCqZwCLFAB8gwAWfhDWLAFWgw16uABoCAAVfgDfcuARewDc9zAR2AASHgDZmt Dt5wFSFwAWYxCt6gszngDak+ChcgABhwDN5wO1pw8UxwDGjwHzPgDVRtAt7gNYBgCgvABGIwDv9h e00yFqdSo/ZRo4BJVIsC0QUZNBaqRwFdoHo4DyCdYBKxYCM+Txk+A/TzQBmxMA+MkvQyUQVKjxTz 0PRRTxU6oyGdIBNYsyphUFxUXx6lwPWusYsBAQA7 ------=_NextPart_000_01EE_01D78EA9.CBB960E0 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhcwAmAPcAAAAAAP///wCP1QCP1Pf7/vL5/QCP1gWR1gqT1gyU2AyU1w6V1xWY2BeZ2R6c 2iGd2iyi3C6j3TOl3Tqo3kWt4Emv4Uyw4U2x4lOz4ly35F645GO65WW75me85m6/53XC6IHH64XJ 64bK7IzM7I/N7JXQ7ZfR7pnS7pzT7p3U76PW8KPW76XX8K7b8bDc8rff87vh9Lzh9L7i9cnn9tLr +Nnu+eDx+uf0++n1++33/PD4/PT6/fj8/gKQ1AWR1QeS1QiT1QmT1g+W1xCW1xOX1xia2Bub2Ryb 2R+d2SCd2SKe2iSf2iag2ymh2yqh2yui3DSm3Tio3Typ3j2q3j6q3kCr30Os30eu4Euw4U6x4U+y 4k+y4VGz4lCy4Va141W04li241q341245F+55GW75Ga85Wm95mi95Gq+5Wu+5m2/5m/A53HB6HDA 53HB5nLB53PC53XC53bD53nE6HvF6X3G6X/H6YHI6oHI6YLI6oLI6YbK64TJ6YnL64rM64zM65HP 7JPQ7ZbR7ZrT7qXX76bY8KfY76jZ8Kra8azb8a/c8bDc8bHd8rLd8rXe8rXe8bjg87zi9Lzh873i 88Dj9MPl9cXm9cfm9cnn9c3p9s/q987p9tHr99Lr99Xt+Nbt+Nrv+d/x+eDx+eX0++Tz+u/4/OHy +ePz+ur2+/b7/fr9/vz+/v7//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAK0ALAAAAABzACYA Rwj/AAMIHEiwoMGDCBMqXMiwoUOGiti0mUhxopcBAgZoHKAglcATFaVg3DgAC0U2hgKsKkJyiZqK FUV4bHijx4AHDFmN0BiJ4A2NRFYRJKAAo6WFKzJibOCQEclMB1WxxOgDUQEeqbKm2sEDoQaMhAqS sonE4B2MeQ7WmGlwj0YKCv0oHeDkIUGnAvJCNShVowA7dgXyyXKhsGEJG6kYNqxFUEImGSsQDJFR gOSClUj61cx5wAmEBKJk9JIwTefTaxzaGNnQxhIBex0WAUPwRZoOZnLr3q27Q6CBKXgL742mhUBW e3AP771HlcNSaDjQCVwwByQc1A2+9vtbodONsQn2/8UI2O6F03lP+/1QcEpeJgMbabwyMEzeOQuJ bBSAyC5ejeENNN5GQzBAxIEHNgAGAQZ9JQAlBvUggBIGlYDWQBtYoKGGW1yw4YZacPGhBVjsIRAB B4xEV3YCfZdRgAKNJ0ATLBo01gBlOXSIARgpohAEeQkgSo1EFmnkkUgmqeSSCKkxl3qaMRUBZ5V1 llcHAaQ40lxP+uXQWALkmB0HGplhECYHWADDQ24oJYAVClHilwCgRMVSXiYGhgIZG/TZZxlXaNTD F2X4+adxA+Fg0wBkEGTfACkQhNgAKzR0iop0MvQdgHZu5EdgXw0AYUE2UViQhQKkVdAcQZYSAA9D GP/xxQ4B1KHRFg1h4OYYDzHiJowBDKgiSZXlSZAGeYVFEJhiDnRHXnoM5EOXxO7HmQMGdRJkRtj5 txmwMqoRWBZPplftuXEkxIUJBj2CxUJSVPkGi5sOAO5UA6hqJCql2sVKEBilcRCyAxhQB0GFqEet X3IglAhJlxzEAwPoaSaABV+S1VAmQ+RlREOTBHkGkySXbPLJKKes8sosC6TJllCS9JshC8NsbSUB eFAzZ244FIpSNfrRxADsGoRKQS/ETCWWIShspSMBUGyteu82dGOzCr3AR0EyaESFQU4OAJdDcBC7 SEJjuJmuQTzg+0SSNmG7ECuQDZBAQUlo9AlBg2D/BMVDm2wpQA4KOUISJ53mpa9DJVRmLkZcUgv1 QDRjRMNAI2SUmkAzYDSEcw3xMVcEmj7VqUblPSRGRl2ooMIKK6hAh0Y/kMBC7K9PkBceBeGwUaUB gLKRc/xqZIpD7vkFR0Obwna6AGiAqlEhBY1iUxIG5YFRtAZh1IYOAh090AIY9cRQAUBALsBRzM91 734CICDEAvQvoMAQGNBaELICKDvQ1Wa5kEBi4IJGNMITmTCgAhvhgg8o5QsvMKALcHaQSKRHAAro SlO+ZafHQQ5mAuhDg8AiFo0VBAQCDAAIMWWuKlWGKQZJg5vg5C2/vI92LujKKna4CtAdRAwa8QIL 7YY4xLPErwREHGIVMMI7km0nL4CgjovsdboBiNAumbPYsKpkLUQZRAZ5+dtAOrEAAXwtITjgkiey U68bDiB1RSKARo4QmEOkR3wDOUNlMnCQQrgJPvQyHV+KUCwkAfAhYMjLD4RyECxUJhEESeRmBCAB mMCkBAlpnhsHwAQPWHIifWCQ1UzIEFAEqQsLwQEQ8gIBgWiBS0qbI0JeMJcaHGQV04plXr6kEbkp hBVTEkAPjtcQOWSEVwGQxBw+wMxmOvOZHxiEQnIAgj1o8JZ/gKY2SeDDhejgDW1YnEI+AUm7fIKR LUunOtfJThYFBAA7 ------=_NextPart_000_01EE_01D78EA9.CBB960E0-- From nobody Mon Aug 16 17:50:19 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E683A0743; Mon, 16 Aug 2021 17:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6npsDl3rG6rm; Mon, 16 Aug 2021 17:50:10 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66FBD3A0688; Mon, 16 Aug 2021 17:50:10 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id e15so22717689plh.8; Mon, 16 Aug 2021 17:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JvPlAdjM1zCFp0K6SEKREjUE6o2HiLXiQXeq7wYQ/XM=; b=W9loyJ2LhWa/YFaZZo/4i0VqCHGmVp5bgu2SloQ+B70YbLVxyQzUTOxoBuXxPzLJkc UkuFO3fZHDidyPMMNyLGAf3fbJPw13WbKGd6ohI+15HtEbrEtow2wWLvuXzB+9NmYJTs ejF38/tpOkE+BoLENCMabt7KKr+nDx6I76+nzNmzGgBCxn1nYD5xs+JtpzByFlPgQH1E UQtCoNcEZ20gznKPvQf+CjOOUWmqeefOP4u5jOwe5F/ZBiTiM2aWIka2oSEgMIP2q2W/ Zgc9YTvhpecH8+OjjG6yzUqq7R5xDNVg0REQa5Am/gVLj6K9/PkEQOthSyX5G1zB8OQn rnJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JvPlAdjM1zCFp0K6SEKREjUE6o2HiLXiQXeq7wYQ/XM=; b=uZvA/rlJQKy7ICGjt+bXiwMgECdn+HmeYhUmQHFN66GmXbHshEm5z7tUto8yaKidYZ OFZGFjVWtebePpYHJ24FB4D9vcc/WeSbb8Ztb7LQTvM5znU8Qdf33Qmk+tG6ZG0A2ncW WW096+60ddsy7h5XB012mkMBi5Lydy+GH8Ph5mXpTTyeNbDr7q8s2NgFed3J76qT4CX1 HRiSuqSIpMmok26PnxM9UTKn4lP1JQHJdHWDOEtyAg+7O3BRSbvmbZ7NfHZhG8KmuhbG xyj98RdH3zCBUU9gR+4R9TCm6BVh7FJ7MxzROgm6r8sRi7Tnoi1v/EYG8qdSSw32tcK/ UXBg== X-Gm-Message-State: AOAM530nKd5O9XviD3Oz8gQWkw+O1w/mcLuUooG+p7F0yCruf9w70v2U b+96xFwlTtNKJ5wg4utU7GA= X-Google-Smtp-Source: ABdhPJzHHD+6LZbu6GVsaPLUwDjKGQD7YJsZr+IlGCznWmV2D5lQ88sY8g89OSnjAeFF2CCvQgQdGw== X-Received: by 2002:a63:1e5c:: with SMTP id p28mr796559pgm.89.1629161408146; Mon, 16 Aug 2021 17:50:08 -0700 (PDT) Received: from [192.168.1.133] (c-69-181-169-15.hsd1.ca.comcast.net. [69.181.169.15]) by smtp.gmail.com with ESMTPSA id g19sm322025pfc.168.2021.08.16.17.50.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Aug 2021 17:50:07 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <38CAE1C7-7977-46F9-AD0D-E3707E25E316@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_13610F46-337C-4105-84DB-58BB5D9DD7F1" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: I-D Action: draft-ietf-bfd-secure-sequence-numbers-08.txt Date: Mon, 16 Aug 2021 17:50:05 -0700 In-Reply-To: <173DA06B-21E7-42A4-8EFF-82AA3D84B338@gmail.com> Cc: Alan DeKok , "rtg-bfd@ietf. org" , Reshad Rehman , draft-ietf-bfd-secure-sequence-numbers@ietf.org To: Jeffrey Haas References: <20210405171412.GB12257@pfrc.org> <4831ADD8-6E8D-4CDD-966F-B273A3AF45C5@freeradius.org> <20210405184656.GE12257@pfrc.org> <468C7D1D-7BE2-4759-9D81-0E18725FCA90@freeradius.org> <20210405190821.GF12257@pfrc.org> <14A4DD6D-7002-45A9-8FE4-42B512E97318@freeradius.org> <096BC9E7-8877-4EF3-A94B-394AFE0E76E7@freeradius.org> <20210726141455.GA32584@pfrc.org> <211EC22C-F4AB-4FE6-98AB-511C5CE4EB8B@freeradius.org> <20210726144826.GB32584@pfrc.org> <173DA06B-21E7-42A4-8EFF-82AA3D84B338@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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, 17 Aug 2021 00:50:16 -0000 --Apple-Mail=_13610F46-337C-4105-84DB-58BB5D9DD7F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jeff, Ping! > On Jul 26, 2021, at 4:25 PM, Mahesh Jethanandani = wrote: >=20 > Hi Jeff, >=20 >=20 >> On Jul 26, 2021, at 7:48 AM, Jeffrey Haas > wrote: >>=20 >> What's being requested is that our specifications have some = specificity and >> a proposal be made for a suitable mechanism and how it integrates = into BFD. >> :-) >=20 > Here are the set of changes that I propose we make to the draft to = bring the specificity that you are requesting. For the introductory part = of the document there is no reference to the method being applied to = come up with a sequence number. It just states that the sequence number = inserted is not the monotonically increasing sequence number. As such no = changes are needed there. >=20 > The change therefore starts in Section 3 - Theory of operation. There = are two changes that I see. One has to do with carrying of nonce in the = first packet, and the other has to do with existing text in the section. >=20 > For the carrying of nonce in the first packet, Alan has already = suggested adding the authentication section in the first packet. We will = add text to that effect. >=20 > As far as the existing text in the section is concerned, we will = replace reference to =E2=80=9Csymmetric key algorithm=E2=80=9D and = =E2=80=9Csymmetric algorithm=E2=80=9D with =E2=80=9Chash=E2=80=9D. As a = result, the sender will include a ciphertext that is a 32-bit hash = computed using one of the algorithms Alan has suggested using a shared = key (that is not necessarily symmetric) and inserted in-lieu of the = sequence number of the packet. Yes, this draft is about obfuscation of = the sequence number field of the packet, not the entire packet. On = reception of the BFD Control packet, the receiver instead of decrypting = the ciphertext inserted in-place of the sequence number, will instead = compare the ciphertext to pre-computed set of hashes using the same = shared key, on the next k expected sequence numbers that are within the = BFD Detect Multiplier range. If there is a match, the receiver will = replace the ciphertext in the packet with the expected sequence number = and pass the frame for further processing. In the case there is no = match, it will drop the packet. >=20 > There are some similar updates to the Security Considerations section = to replace =E2=80=9Csymmetric algorithm=E2=80=9D with =E2=80=9Chash=E2=80=9D= . >=20 > Are these set of changes enough to bring the specificity that you are = looking for? >=20 > Thanks. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_13610F46-337C-4105-84DB-58BB5D9DD7F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Jeff,

Ping!

On Jul 26, 2021, at 4:25 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

Hi Jeff,


On Jul = 26, 2021, at 7:48 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:

What's being requested is that = our specifications have some specificity and
a proposal be made for a = suitable mechanism and how it integrates into BFD.
:-)

Here are the set of changes that I = propose we make to the draft to bring the specificity that you are = requesting. For the introductory part of the document there is no = reference to the method being applied to come up with a sequence number. = It just states that the sequence number inserted is not the = monotonically increasing sequence number. As such no changes are needed = there.

The = change therefore starts in Section 3 - Theory of operation. There are = two changes that I see. One has to do with carrying of nonce in the = first packet, and the other has to do with existing text in the = section.

For = the carrying of nonce in the first packet, Alan has already suggested = adding the authentication section in the first packet. We will add text = to that effect.

As far as the existing text in the section is concerned, we = will replace reference to =E2=80=9Csymmetric key algorithm=E2=80=9D and = =E2=80=9Csymmetric algorithm=E2=80=9D with =E2=80=9Chash=E2=80=9D. As a = result, the sender will include a ciphertext that is a 32-bit hash = computed using one of the algorithms Alan has suggested using a shared = key (that is not necessarily symmetric) and inserted in-lieu of the = sequence number of the packet. Yes, this draft is about obfuscation of = the sequence number field of the packet, not the entire packet.  On = reception of the BFD Control packet, the receiver instead of decrypting = the ciphertext inserted in-place of the sequence number, will instead = compare the ciphertext to pre-computed set of hashes using the same = shared key, on the next k expected sequence numbers that are within the = BFD Detect Multiplier range. If there is a match, the receiver will = replace the ciphertext in the packet with the expected sequence number = and pass the frame for further processing. In the case there is no = match, it will drop the packet.

There are some similar updates to the = Security Considerations section to replace =E2=80=9Csymmetric = algorithm=E2=80=9D with =E2=80=9Chash=E2=80=9D.

Are these set of changes enough to = bring the specificity that you are looking for?

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_13610F46-337C-4105-84DB-58BB5D9DD7F1-- From nobody Fri Aug 20 13:13:34 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E623A0AD4 for ; Fri, 20 Aug 2021 13:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 Znx7BONr8tsD for ; Fri, 20 Aug 2021 13:05:16 -0700 (PDT) Received: from sonic303-3.consmr.mail.bf2.yahoo.com (sonic303-3.consmr.mail.bf2.yahoo.com [74.6.131.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E7623A0ACE for ; Fri, 20 Aug 2021 13:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1629489915; bh=7ecHd5VERPpGUJN50Fc+QprdrqxZxZa30XNxEl9o2bk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=hGtVj4R3eQfEiudzPVNIK8G0rmXMbP5JYzPsNbOVcqejnRvLGzfjlWnS+5vfepm90G3IC2D8gtz7reOKanswDDrZaS/5LwpNjwbm/j4yT7UucACfxVpIhHE6nE81D1Io2jFjMQT1A98kjvnBDHVV9H8/e3RtTl4aRm3dRnKSKTtDJEOSzZtXgHxeQSXTM6WhJpL25v/SGMI/VJPjvAz1yYA7DAhViZvAHsjG6bCGv3tdZHdlEGj68uvztCgZn8N6VIxVKsVUwuFOxTKVti2misllA9TEaGo+MjIdbtB80Fk/yGyiqJanKF4+hSacQo0V0IwkxqkNiOYdzxRJLCKlDw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1629489915; bh=l9H2EGHkK9gH6Pi3zlrZAkL41ElVydLGKDggJNONl7R=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=fnkaIM7g7/V9mWyK7/ILqsao6Dx9PvyF1vZvv/tf8nVUWwXmdrqQzWzVHeorUU8rvoekodbRrF3bMV8DT3/n1b5wOUtUEFlXOMF3IKr02IfmWSv+U6yZ9j7UStol8KttaWTVdddgIUNDf42/aDGCELdUq/Wnd9UM7oCPNfEWiG/ECU1KRlSawC3a9wT/AsDZjUALGxI2vzonVDLI/vp6UiRFkgHXMoC0WmgYHv3rgbooyg0Eij6qIyHZU82VJ+TjA5a3LWcc7a+NQEUUy78J8y5huOYmqWelYr8hrbea2VZpLYo18abCXwQdk2ntzDVEVcAyJWVJphRM6NxEqSxwMw== X-YMail-OSG: O0jSX5QVM1nDFKlZJsFQwCScwr4dZgGQ44EJtBBMAAn_iXvo2zbWV72y.JxZ.f6 lHcDl6qhsKxZIqOf9D67TqbgPmlrr7DIUm4Qq0FnYhIdPzaEsWmeG5tMA8t9CcLSzfjFV5Njg2vi sjruh14NyLOLFc7GVMXelNlQCEoboCCf7vhuF.479e1u2C8qlATaZ8J9NH0MyeUTri9Q3QJPI6FC qb.L2njXOmmMZouLoNojDpTxFL9PrAerdVwFVXWwTQ2wpYXERqct6oNNX74vNBgsGG70c.Hi.dEL s5wFwz44988G5Jfe387aeU7VhTbDF_Xu77UsRhbDL4gbh9zqYvN.Vl0EdGb1DjppUKzAIzO6l8QI JWgudBWLcbBKKz6eOtUjqhH0GHEly.egTerN7DadMX.ekgkJVMldkfXnY9c4lNhGigAotdV6EJpu n9iBCHZ5bJeK1NLYfdXJRQeJHk9hxgVP4XPiHiVcrBq669a2srepW7nAbxzR01wZ02wQF.L1xtIv BQ1lIdnCy05GhVyu2zy7VzQImxlgmqf5dNXKeF5iQSiJ7S2RBU_w1F2Q1vrohVTziGrC9NzojugJ yU4r7DmdGi17_EB9Fu7euL1.WcfHAxQaKzLrVBGHiy3VuyKvzGCb6uYzCtCxfw4o69hILMGO73MU r5nP7jpHBDZhfAfShvIBPoM2WXXXWlzHIz6QIdvPYjleFDtqhUgQcMbtrR1c32B07h5SZh4HpHkV y4hBzie_3fei42M0nXciD7uPozE6BMQAArzeX_TFkuO4vNUPGHkNNlyqGX5GoXvAqxMR_JenmidV W2Vn97eA1hX__rZ7k_OvTeNHOCUTmEGijJym9GHc8WbbSCHbRk8gWMvvuxeNhPjHduxo7891xHsk Ec1x3ZAZE0K1s4E0Fn93v9p5cdnsk38MMmTnvcLSKWm8DR9C_3dQe1U9tvhzrBbW5n7rF2KXhjFb iE1.liuyVcxhu2IWUCexyj3SoNRFwftM4cHXRh3Ua36QVkj3lemgdzWRnOsyxF4EaLzsN_TmCDr2 73TBV.41wEV3pYklDSfq_m9DkRDXYGvcaJ.AgSfeCpqgEWv2SEEwazg_3x2KhYwZApRXIbOl3_40 .8KYE4ZpgkLHoNxEX5a0Lud6uqkex1UeJHgMDRC7OI0xC1OYl4CcG3JbS9ekq5_WQnd9sahwx7Mq GN3otxN1LOmmsaTFw_UHnQr2BQbLQ7N1kxxCM9qykj.qplW443cvW3ITBqW5TJlayFq3ePmP3m_a YdH_sWqn1Pt5_XF.BT30Na3RpdlvIv3uOuVDLX_JIs58vtsMqta0V9ohAz7jQZ5iZnDvFOGV.BvM 4uaMwNIFWcyfFBxcsxE7tNSUBSEKnXcSxyxPlTVHkhyVbgmQcQTY_UFrTKz14hyMDl7f1trzLeVZ pHinUMFtRFBQXwlIERh0LWI72J1c2ZEzheOBslNbtUCiIdTmISvZkVCJfWoMiKvM43hni0.1rjOV LO0CJ5hZTczydtU4v9MdJQzQdz_lClNKXIWAxNScMAYaTXbrFiBfbGXhri5a5vIeUCy0NBX65w5V BleASOLo1zgcIDnvLsjrGje0LJhF39dH8zpjXzESrLdkmeQ5b8lLFvnmyBIEmeKW2kbX7oj6qcdw 3wwACtEhB3gDmuYmqtT0R69CZlkNuPVGhdwGlnjowcqTgszfb.P5Q8tkwNLTuk_qasSbOeOYrche guFwtbUH3MpSmfYytir6BbDjuwhjnXFuBVoCn_tow9qycLogm9i.EKp_SESHJH9.PpP10R348ThU X1omlOh.MOKpsCGimxn1LFmg1qBjM20pYh662OFgZJMw8LoTZVZ64CVGCk28TvxR4Ab72iL5Ng1V zmfAz5A6_zZVp8Szw1rqaLiRpxP3dNHW4gei.0ljWi._MsYmsYXJxe.YTYoLZh6xvaArPrPdPjpb 5Ikfcl6kBu9TE4ImtgVdQO1iXEexVrG4ZjGu3thykm5nq09tsKjMTRgUKaapfcyVwTh41Atau9X2 eBWL4XWlQvEiS.ftmrzFhfchVeguSBx_Kjgul_hA5IZV9PV28BznfaILzWfcRfITBJybHix2shfo m2431siEDHzsSyNpuAfFh88N1nY.jV59Mi0ttI5q66aJCI0OHDLBCdeZjHHd2EEZTC_6no3WH66G ludpb17MCLMA_DsjxKXwkfTPUikM0QpqRknvsoh48DMQzr3OX6knjE8SXeE6_sjaFyCPAHZz8THc 0ePCTkabk6Xo4_wRVEeh4GKd5J7NKP6hoxbzaxNCjnVGopWFSMcdvySMFmmNMomSCIxU4SH3iChd ys_IWyYeKryJnwLR96vDG7BhfZMImBqU- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Fri, 20 Aug 2021 20:05:15 +0000 Date: Fri, 20 Aug 2021 20:05:10 +0000 (UTC) From: Reshad Rahman Reply-To: Reshad Rahman To: Michael McBride , Rtg-bfd WG Cc: Greg Mirsky , "aretana.ietf@gmail.com" , "pim-chairs@ietf.org" Message-ID: <1867869445.417157.1629489910471@mail.yahoo.com> In-Reply-To: References: <202107220742327030208@zte.com.cn> Subject: Re: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_417156_1899740743.1629489910464" X-Mailer: WebService/1.1.18850 YMailNorrin Archived-At: X-Mailman-Approved-At: Fri, 20 Aug 2021 13:13:32 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2021 20:05:24 -0000 ------=_Part_417156_1899740743.1629489910464 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Michael. =C2=A0Adding BFD WG. Regards,Reshad. -----Original Message----- From: pim On Behalf Of Michael McBride Sent: Tuesday, August 17, 2021 10:53 PM To: Alvaro Retana ; gregory.mirsky@ztetx.com Cc: draft-ietf-pim-bfd-p2mp-use-case@ietf.org; mmcbride7@gmail.com; pim-cha= irs@ietf.org; pim@ietf.org Subject: Re: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05 Hi Greg, Please consider either 1) dropping the "use-case" from the draft name and k= eep it a specific pim-bfd-p2mp solution and less generalized or 2) keeping = the existing name and make it more generalized with more use cases as Alvar= o suggests.=20 I'll ping the bfd chairs and cc you to ensure they are in the loop. Thanks, mike -----Original Message-----2021-02-04-Network TMT Meetings : https://nam11.s= afelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fefutureway.sharepoint.= com%2Fteams%2FNetworkLabTMT%2FShared&data=3D04%7C01%7Cmichael.mcbride%40fut= urewei.com%7C58e9d5e586be49da514708d9620c8c21%7C0fee8ff2a3b240189c753a1d559= 1fedc%7C1%7C1%7C637648628320865112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw= MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DAlTELyg1E= qhpLnl8aYSCv9YKEH6zldm46UVAx8MZaus%3D&reserved=3D0 Documents/General/Networ= k Lab TMT Meeting/February 4 2021 Meeting/2021-02-04-Network TMT Meetings.p= ptx?web=3D1G From: pim On Behalf Of Alvaro Retana Sent: Tuesday, August 17, 2021 8:19 AM To: gregory.mirsky@ztetx.com Cc: draft-ietf-pim-bfd-p2mp-use-case@ietf.org; mmcbride7@gmail.com; pim-cha= irs@ietf.org; pim@ietf.org Subject: Re: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05 On July 21, 2021 at 7:42:42 PM, gregory.mirsky@ztetx.com wrote: Greg: Hi! Thanks for the update!! I have some comments in-line. =C2=A0I am also attaching (below) a review of= -06, which mostly contains minor issues and nits related to new/updated te= xt. The main item I would like WG input on is the generalization of the mechani= sm. =C2=A0In short, bootstrapping the BFD session is the main focus of this= document; I don't see a reason to avoid generalizing its use to other scen= arios. =C2=A0We already agree on the wider applicability -- the incremental= changes needed to generalize the text is far less than the process it will= take to do it later. Mike: as Shepherd/Chair, please start a conversation in the WG as needed. = =C2=A0Please take a look at the discussion below. Thanks! Alvaro. ... > Sender: AlvaroRetana ... > This document specifies two things: (1) a Hello option to help the=20 > tail bootstrap the BFD session, and, (2) the actions that the tail=20 > takes when a failure is detected. The former is common to all cases,=20 > while the latter depends on the role of the head with respect to the=20 > tail. The actions are basically an acceleration of what would=20 > naturally happen (if BFD was not used and the failure detection was=20 > "slow"). Is this a fair characterization of the document? GIM>> Yes, absolutely correct. ... > Are there other cases that could use this mechanism to track? I can=20 > think of a couple of cases: monitor PIM neighbors that send Joins, RPF=20 > neighbors, Assert winners... As with the DR case, for example, these=20 > cases don't require actions beyond an acceleration. It would be ideal=20 > if the document could cover these cases, and possibly others, in a=20 > generic way -- I can't think of good phrasing with now, but I'm sure=20 > you can. ;-) GIM>> I agree that the defined PIM Hello BFD Discriminator option can be=20 GIM>> used by not only PIM DR/BDR nodes. Indeed, there are other use=20 GIM>> cases where a faster detection will improve the convergence in the=20 GIM>> control plane and minimize the negative impact on the multicast=20 GIM>> data plane. These use cases may be covered in the future. Maybe I'm missing something obvious, and would like to understand what. :-) The Hello option helps the tail bootstrap a BFD session, correct? =C2=A0If = so, there's nothing in that description about the function of the tail (or = the head). =C2=A0The point that I'm trying to make above is that the only t= hing that BFD is providing any use case is faster detection of a failure (w= hich is very significant, of course!), so regardless of the application or = function of the tail/head, the operation can be generalized. =C2=A0Is this = not true? =C2=A0What am I missing? To be more specific, the description in =C2=A72.1 (Using P2MP BFD in PIM DR= /BDR Monitoring) is a generic description, and not one that only applies to= a DR/BDR. =C2=A0In fact, the text says that any node "regardless of its ro= le, MAY become a head of a p2mp BFD session" -- which means that it is up t= o the tail to monitor it or not. The last two paragraphs in =C2=A72.1 do mention the DR/BDR function, but th= ey could easily be generalized: OLD> =C2=A0 =C2=A0If the tail detects a MultipointHead failure [RFC8562], it MUS= T =C2=A0 =C2=A0delete the corresponding neighbor state. =C2=A0If the failed h= ead was the =C2=A0 =C2=A0DR (or BDR), the DR (or BDR) election mechanism in [RFC7761] o= r =C2=A0 =C2=A0[I-D.ietf-pim-dr-improvement] is followed. =C2=A0 =C2=A0If the head ceases to include the BFD Discriminator PIM Hello = option =C2=A0 =C2=A0in its PIM-Hello message, tails MUST close the corresponding =C2=A0 =C2=A0MultipointTail BFD session. =C2=A0Thus the tail stops using BF= D to monitor =C2=A0 =C2=A0the head and reverts to the procedures defined in [RFC7761] an= d =C2=A0 =C2=A0[I-D.ietf-pim-dr-improvement]. NEW> =C2=A0 =C2=A0If the tail detects a MultipointHead failure [RFC8562], it MUS= T =C2=A0 =C2=A0delete the corresponding neighbor state. =C2=A0If the head cea= ses to =C2=A0 =C2=A0include the BFD Discriminator PIM Hello option in its PIM-Hell= o =C2=A0 =C2=A0message, tails MUST close the corresponding MultipointTail BFD =C2=A0 =C2=A0session. =C2=A0In both cases, the tail continues to follow the =C2=A0 =C2=A0specification related to the function of the head. GIM>> As I think of it, one aspect would be homogeneity of p2mp BFD=20 GIM>> capability throughout the domain. In other words, what happens if=20 GIM>> some PIM nodes don't support the BFD Discriminator option and do=20 GIM>> not use p2mp BFD? What their slow (regular) convergence impact=20 GIM>> other nodes? But that, I think, is for further discussion, work. Woul= d you agree? I don't. In fact, this is a very important deployment point that I had overlooked. = =C2=A0If the support is not homogeneous, then some parts of the network wil= l converge (to the new state) faster than others. As with unicast routing I= think the main effect may be longer than expected inconsistency, but not w= orst than without BFD. =C2=A0The specific effect relates to the use case...= but because the deployment would be localized (the DR and other routers on = the LAN, for example), then any negative effect of not supporting BFD (i.e.= behaving as today) would be localized. Thank you for bringing this up. =C2=A0If you consider the effect significan= t for a specific case then please add a couple of sentences. ... > 183 3.1. Using P2MP BFD in PIM DR/BDR Monitoring ... > 229 If the head ceased to include BFD TLV in its PIM-Hello message,=20 > tails > 230 MUST close the corresponding MultipointTail BFD session. Thus the > 231 tail stops using BFD to monitor the head and reverts to the > 232 procedures defined in [RFC7761] and [I-D.ietf-pim-dr-improvement]. ... > [major] Let me see if I understand: if the head doesn't use the BFD=20 > hello option anymore then the tail can gracefully stop using BFD. > IOW, this way the BFD session does not expire and result in the DR=20 > being declared dead. Is that it? GIM>> Yes, that is what we've intended - revert to "slow" detection. > Given that the BFD session can be bootstrapped at the tail by manually=20 > configuring the corresponding discriminator, it seems that stopping=20 > the use of the BFD hello option may not result in the expected=20 > outcome. ??? GIM>> Yes, the head's My Discriminator value can be provisioned using=20 GIM>> the management plane. If that is the case, then I think this=20 GIM>> document is not applicable as the head and leaves use RFC 8562 withou= t any additions. The problem is that the text now says this: =C2=A0 =C2=A0If the head ceases to include the BFD Discriminator PIM Hello = option =C2=A0 =C2=A0in its PIM-Hello message, tails MUST close the corresponding =C2=A0 =C2=A0MultipointTail BFD session. =C2=A0Thus the tail stops using BF= D to monitor =C2=A0 =C2=A0the head... s/MUST/SHOULD =C2=A0 Provisioning the node is the exception, so the action = should be recommended and not required. ... > 288 5. Security Considerations ... > 299 An implementation that supports this specification SHOULD use a > 300 mechanism to control the maximum number of BFD sessions that can=20 > be > 301 active at the same time. > > [major] rfc8562 already requires "protective measures to prevent an=20 > infinite number of MultipointTail sessions from being created". It is=20 > then not needed for this document to recommend anything that is=20 > required elsewhere. GIM>> Done. ?? =C2=A0You left the paragraph in. > [major] What new security risks are introduced by the mechanism in=20 > this draft? In general, a rogue node can stop sending or delay BFD=20 > packets causing the tail to conclude that the head is down: the DR/BDR=20 > may change causing instability. I was surprised that rfc8562 did not=20 > mention the interaction risk, but rfc5880 already does. I feel that=20 > something needs to be mentioned specific to this document, even if it=20 > is highlighted that the risk is not new. GIM>> Then that "rogue" node is the PIM DR/BDR, not a man-in-the-middle.=20 GIM>> And the attack is by making the p2mp BFD session expire on leaves=20 GIM>> while still periodically sending PIM Hello. AFAIK, since PIM=20 GIM>> DR/BDR election takes several Hello cycles, I don't think that=20 GIM>> that behavior will affect the multicast service. Perhaps I'm missing = something, please advise. Yes, the problem is that =C2=A72.1 says that the tail "MUST delete the corr= esponding neighbor state". =C2=A0This results in the DR not being elected f= or a while. I see what you mean: if the DR is still there then the election will probab= ly elect it again. =C2=A0However, in the meantime the DR may not think it i= s the DR anymore if the other routers in the LAN start a new DR election. (= ??) =C2=A0 Please add the explanation (or something like it) to make it cle= ar that the risk is mitigated by the "double set of hellos". In the general case... =C2=A0If tracking the sender of a Join, for example,= the effect would be more significant: an outage would exist until the next= Join is received. ... > 310 7.1. Normative References > .. > 327 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding=20 > Detection > 328 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, > 329 DOI 10.17487/RFC5881, June 2010, > 330 . > > [minor] This reference can be Informative. I know you moved it...but now that you added a reference to it in =C2=A72.3= then we need it to be Normative. =C2=A0Sorry. ... > [End of review -05.] [Start -06] [Line numbers from idnits.] ... 129=C2=A0=C2=A0=C2=A0 2. =C2=A0BFD Discriminator PIM Hello Option ... 153=C2=A0=C2=A0=C2=A0 =C2=A0 If the value of the OptionLength field is not = equal to 4, the BFD 154=C2=A0=C2=A0=C2=A0 =C2=A0 Discriminator PIM Hello option is considered m= alformed, and the 155=C2=A0=C2=A0=C2=A0 =C2=A0 receiver MUST stop processing PIM Hello option= s. =C2=A0If the value of the 156=C2=A0=C2=A0=C2=A0 =C2=A0 My Discriminator field equals zero, then the B= FD Discriminator PIM 157=C2=A0=C2=A0=C2=A0 =C2=A0 Hello option MUST be considered invalid, and t= he receiver MUST ignore 158=C2=A0=C2=A0=C2=A0 =C2=A0 it. =C2=A0The receiver SHOULD log the notifica= tion regarding the malformed 159=C2=A0=C2=A0=C2=A0 =C2=A0 or invalid BFD Discriminator Hello option unde= r the control of a 160=C2=A0=C2=A0=C2=A0 =C2=A0 throttling logging mechanism. [major] "MUST stop processing PIM Hello options" Stop in the current Hello message? =C2=A0Should it ignore all the options o= r just the ones after this one? =C2=A0In all future Hello messages? I haven't thought about this enough, but there could be an effect on other = functionality. =C2=A0What is that effect? =C2=A0I couldn't find anywhere a = general way to handle malformed Hello options -- did I miss it? [nit] s/log the notification/log a notification 162=C2=A0=C2=A0=C2=A0 2.1. =C2=A0Using P2MP BFD in PIM DR/BDR Monitoring ... 169=C2=A0=C2=A0=C2=A0 =C2=A0 If a PIM-SM router is configured to monitor th= e head by using p2mp 170=C2=A0=C2=A0=C2=A0 =C2=A0 BFD, referred to through this document as 'tai= l', receives PIM-Hello 171=C2=A0=C2=A0=C2=A0 =C2=A0 packet with BFD Discriminator PIM Hello option= , the tail MAY create a 172=C2=A0=C2=A0=C2=A0 =C2=A0 p2mp BFD session of type MultipointTail, as de= fined in [RFC8562]. [minor] s/router is configured/router that is configured [nit] s/receives PIM-Hello packet with BFD Discriminator/receives a PIM-Hel= lo packet with the BFD Discriminator ... 188=C2=A0=C2=A0=C2=A0 =C2=A0 If the head ceases to include the BFD Discrimi= nator PIM Hello option 189=C2=A0=C2=A0=C2=A0 =C2=A0 in its PIM-Hello message, tails MUST close the= corresponding 190=C2=A0=C2=A0=C2=A0 =C2=A0 MultipointTail BFD session. =C2=A0Thus the tai= l stops using BFD to monitor 191=C2=A0=C2=A0=C2=A0 =C2=A0 the head and reverts to the procedures defined= in [RFC7761] and 192=C2=A0=C2=A0=C2=A0 =C2=A0 [I-D.ietf-pim-dr-improvement]. [minor] "...MUST close the corresponding MultipointTail BFD session" It might be a good thing adding that the PIM state is not affected by this = action. 194=C2=A0=C2=A0=C2=A0 2.2. =C2=A0P2MP BFD in PIM DR Load Balancing 196=C2=A0=C2=A0=C2=A0 =C2=A0 [RFC8775] specifies the PIM Designated Router = Load Balancing (DRLB) 197=C2=A0=C2=A0=C2=A0 =C2=A0 functionality. =C2=A0Any PIM router that adver= tises the DRLB-Cap Hello 198=C2=A0=C2=A0=C2=A0 =C2=A0 Option can become the head of a p2mp BFD sessi= on, as specified in 199=C2=A0=C2=A0=C2=A0 =C2=A0 Section 2.1. =C2=A0The head router administrat= ively sets the 200=C2=A0=C2=A0=C2=A0 =C2=A0 bfd.SessionState to Up in the MultipointHead s= ession [RFC8562] only 201=C2=A0=C2=A0=C2=A0 =C2=A0 if it is a Group Designated Router (GDR) Candi= date, as specified in 202=C2=A0=C2=A0=C2=A0 =C2=A0 Sections 5.5 and 5.6 of [RFC8775]. =C2=A0If th= e router is no longer the 203=C2=A0=C2=A0=C2=A0 =C2=A0 GDR, then it MUST shut down following the proc= edures described in 204=C2=A0=C2=A0=C2=A0 =C2=A0 Section 5.9 [RFC8562]. =C2=A0For each GDR Cand= idate that includes BFD 205=C2=A0=C2=A0=C2=A0 =C2=A0 Discriminator option in its PIM Hello, the PIM= DR creates a 206=C2=A0=C2=A0=C2=A0 =C2=A0 MultipointTail session [RFC8562]. =C2=A0PIM DR= demultiplexes BFD sessions 207=C2=A0=C2=A0=C2=A0 =C2=A0 based on the value of the My Discriminator fie= ld and the source IP 208=C2=A0=C2=A0=C2=A0 =C2=A0 address. =C2=A0If PIM DR detects a failure of = one of the sessions, it MUST 209=C2=A0=C2=A0=C2=A0 =C2=A0 remove that router from the GDR Candidate list= and immediately 210=C2=A0=C2=A0=C2=A0 =C2=A0 transmit a new DRLB-List option. [] Continuing with my theme of generalizing this specification... This section says everything that the last section already specified in a g= eneric way. =C2=A0IOW, it is not really needed. There is one thing that this paragraph adds: "If the router is no longer th= e GDR, then it MUST shut down following the procedures described in Section= 5.9 [RFC8562]." =C2=A0 Yes, shutting down the BFD session is important, bu= t so is not including the BFD Discriminator option in the Hello anymore. = =C2=A0As with everything else, this part can also be generalized: =C2=A0 =C2=A0If the head is no longer serving the function that prompted it =C2=A0 =C2=A0to be monitored, then it MUST cease including the BFD Discrimi= nator =C2=A0 =C2=A0PIM Hello option in its PIM-Hello message, and it MUST shut do= wn =C2=A0 =C2=A0the BFD session following the procedures described in Section = 5.9 =C2=A0 =C2=A0[RFC8562]. 212=C2=A0=C2=A0=C2=A0 2.3. =C2=A0Multipoint BFD Encapsulation 214=C2=A0=C2=A0=C2=A0 =C2=A0 The MultipointHead of a p2mp BFD session when = transmitting BFD 215=C2=A0=C2=A0=C2=A0 =C2=A0 Control packet: [nit] s/packet/packets 217=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST set TTL or Hop Limit value t= o 255 (Section 5 [RFC5881]); [major] "MUST set...RFC5881" =C2=A0 This action is already required in an R= FC that this document depends on, please don't specify the behavior again. = =C2=A0I understand that rfc5682 can be used in multi-hop scenarios, but rfc= 5881 is the source here. =C2=A0 =C2=A0s/MUST/must ... 222=C2=A0=C2=A0=C2=A0 3. =C2=A0IANA Considerations ... 227=C2=A0=C2=A0=C2=A0 =C2=A0 +=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D+ 228=C2=A0=C2=A0=C2=A0 =C2=A0 | Value Name =C2=A0| Length Number =C2=A0| Nam= e Protocol =C2=A0 =C2=A0 | Reference =C2=A0 =C2=A0 | 229=C2=A0=C2=A0=C2=A0 =C2=A0 +=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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D+ 230=C2=A0=C2=A0=C2=A0 =C2=A0 | TBA =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 4 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| BFD Discriminator | This documen= t | 231=C2=A0=C2=A0=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Option =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | 232=C2=A0=C2=A0=C2=A0 =C2=A0 +-------------+----------------+--------------= -----+---------------+ [major] Please use the same field names as in the registry: Value, Length, = Name, Reference [EoR -06] _______________________________________________ pim mailing list pim@ietf.org https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fpim&data=3D04%7C01%7Cmichael.mcbride%40futurew= ei.com%7C58e9d5e586be49da514708d9620c8c21%7C0fee8ff2a3b240189c753a1d5591fed= c%7C1%7C1%7C637648628320865112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi= LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DzhFkLPkgOJ9Ee= uloewKnNDe75JqgzbOWdfV3%2Bd5EBRk%3D&reserved=3D0 _______________________________________________ pim mailing list pim@ietf.org https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fpim&data=3D04%7C01%7Cmichael.mcbride%40futurew= ei.com%7C58e9d5e586be49da514708d9620c8c21%7C0fee8ff2a3b240189c753a1d5591fed= c%7C1%7C1%7C637648628320875108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi= LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D4SrgiS9qdwYsw= CMitpP4Qf1iWZ4zJkVauDz%2B4%2BKyvyA%3D&reserved=3D0 =20 ------=_Part_417156_1899740743.1629489910464 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Michael.  Adding BFD WG.

Regards,
Reshad.

-----Original Message-----
From: pim <pim-bounces@ietf.org> On Behalf Of Michael Mc= Bride
Sent: Tuesday, August 17, 2021 10:53 PM
=
Subjec= t: Re: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05

Hi Greg,
=
Please consider either 1) dropping the "use-case= " from the draft name and keep it a specific pim-bfd-p2mp solution and less= generalized or 2) keeping the existing name and make it more generalized w= ith more use cases as Alvaro suggests.

I'll ping the bfd chairs and cc you to ensure they are in= the loop.

Thanks,
=
mike

Subject: Re: [pim] AD Review of = draft-ietf-pim-bfd-p2mp-use-case-05

On July 21, 2021 at 7:42:42 PM, gregory.mirsky@ztetx.com<= /a> wrote:


<= div dir=3D"ltr">Greg:








Thanks!

Alvaro.



..= .
> Sender: AlvaroRetana
...
> This document specifies two things:= (1) a Hello option to help the
> tail bootst= rap the BFD session, and, (2) the actions that the tail
> takes when a failure is detected. The former is common to all= cases,
> while the latter depends on the rol= e of the head with respect to the
> tail. The= actions are basically an acceleration of what would
> naturally happen (if BFD was not used and the failure detection w= as
> "slow"). Is this a fair characterization= of the document?

GIM&= gt;> Yes, absolutely correct.

...
> Are there other cases that co= uld use this mechanism to track? I can
> thin= k of a couple of cases: monitor PIM neighbors that send Joins, RPF
> neighbors, Assert winners... As with the DR case, f= or example, these
> cases don't require actio= ns beyond an acceleration. It would be ideal
>= ; if the document could cover these cases, and possibly others, in a
> generic way -- I can't think of good phrasing wit= h now, but I'm sure
> you can. ;-)
<= div dir=3D"ltr">
GIM>> I agree that the def= ined PIM Hello BFD Discriminator option can be
G= IM>> used by not only PIM DR/BDR nodes. Indeed, there are other use <= br>
GIM>> cases where a faster detection will i= mprove the convergence in the
GIM>> contro= l plane and minimize the negative impact on the multicast
GIM>> data plane. These use cases may be covered in the fut= ure.

Maybe I'm missing= something obvious, and would like to understand what. :-)

The Hello option helps the tail bootst= rap a BFD session, correct?  If so, there's nothing in that descriptio= n about the function of the tail (or the head).  The point that I'm tr= ying to make above is that the only thing that BFD is providing any use cas= e is faster detection of a failure (which is very significant, of course!),= so regardless of the application or function of the tail/head, the operati= on can be generalized.  Is this not true?  What am I missing?
=

To be more specific, the = description in =C2=A72.1 (Using P2MP BFD in PIM DR/BDR Monitoring) is a gen= eric description, and not one that only applies to a DR/BDR.  In fact,= the text says that any node "regardless of its role, MAY become a head of = a p2mp BFD session" -- which means that it is up to the tail to monitor it = or not.

The last two p= aragraphs in =C2=A72.1 do mention the DR/BDR function, but they could easil= y be generalized:

OLD&= gt;
   If the tail detects a Multipoint= Head failure [RFC8562], it MUST
   dele= te the corresponding neighbor state.  If the failed head was the
   DR (or BDR), the DR (or BDR) election mec= hanism in [RFC7761] or
   [I-D.ietf-pim= -dr-improvement] is followed.

   If the head ceases to include the BFD Discriminator P= IM Hello option
   in its PIM-Hello mes= sage, tails MUST close the corresponding
  &= nbsp;MultipointTail BFD session.  Thus the tail stops using BFD to mon= itor
   the head and reverts to the pro= cedures defined in [RFC7761] and
   [I-= D.ietf-pim-dr-improvement].


NEW>
  &= nbsp;If the tail detects a MultipointHead failure [RFC8562], it MUST
   delete the corresponding neighbor state. &= nbsp;If the head ceases to
   include t= he BFD Discriminator PIM Hello option in its PIM-Hello
   message, tails MUST close the corresponding MultipointTa= il BFD
   session.  In both cases,= the tail continues to follow the
   sp= ecification related to the function of the head.
=


GIM>> As I think of it, one aspect would be homogeneity of p2mp= BFD
GIM>> capability throughout the domai= n. In other words, what happens if
GIM>> s= ome PIM nodes don't support the BFD Discriminator option and do
<= div dir=3D"ltr">GIM>> not use p2mp BFD? What their slow (regular) con= vergence impact
GIM>> other nodes? But tha= t, I think, is for further discussion, work. Would you agree?

I don't.
=
In fact, this is a very important deployment poi= nt that I had overlooked.  If the support is not homogeneous, then som= e parts of the network will converge (to the new state) faster than others.= As with unicast routing I think the main effect may be longer than expecte= d inconsistency, but not worst than without BFD.  The specific effect = relates to the use case...but because the deployment would be localized (th= e DR and other routers on the LAN, for example), then any negative effect o= f not supporting BFD (i.e. behaving as today) would be localized.
=

Thank you for bringing this up.=  If you consider the effect significant for a specific case then plea= se add a couple of sentences.


...
> 183 = 3.1. Using P2MP BFD in PIM DR/BDR Monitoring
...<= br>
> 229 If the head ceased to include BFD TLV in= its PIM-Hello message,
> tails
> 230 MUST close the corresponding MultipointTail BFD sessi= on. Thus the
> 231 tail stops using BFD to mon= itor the head and reverts to the
> 232 procedu= res defined in [RFC7761] and [I-D.ietf-pim-dr-improvement].
...
> [major] Let me see if I under= stand: if the head doesn't use the BFD
> hell= o option anymore then the tail can gracefully stop using BFD.
> IOW, this way the BFD session does not expire and result = in the DR
> being declared dead. Is that it?<= br>

GIM>> Yes, that = is what we've intended - revert to "slow" detection.

> Given that the BFD session can be boots= trapped at the tail by manually
> configuring= the corresponding discriminator, it seems that stopping
> the use of the BFD hello option may not result in the expecte= d
> outcome. ???
GIM>> Yes, the head's My Discriminator value= can be provisioned using
GIM>> the manage= ment plane. If that is the case, then I think this
GIM>> document is not applicable as the head and leaves use RFC 85= 62 without any additions.

The problem is that the text now says this:
<= br>
   If the head ceases to include the BF= D Discriminator PIM Hello option
   in = its PIM-Hello message, tails MUST close the corresponding
   MultipointTail BFD session.  Thus the tail stops= using BFD to monitor
   the head...

s/MUST/SHOULD   Pro= visioning the node is the exception, so the action should be recommended an= d not required.


...
> 288 5. Security Con= siderations
...
> 29= 9 An implementation that supports this specification SHOULD use a
=
> 300 mechanism to control the maximum number of BFD se= ssions that can
> be
> 301 active at the same time.
>
> [major] rfc8562 already requires "protective measure= s to prevent an
> infinite number of Multipoi= ntTail sessions from being created". It is
> = then not needed for this document to recommend anything that is
<= div dir=3D"ltr">> required elsewhere.

GIM>> Done.

??  You left the paragraph in.


> [major] What n= ew security risks are introduced by the mechanism in
> this draft? In general, a rogue node can stop sending or delay BF= D
> packets causing the tail to conclude that= the head is down: the DR/BDR
> may change ca= using instability. I was surprised that rfc8562 did not
> mention the interaction risk, but rfc5880 already does. I fee= l that
> something needs to be mentioned spec= ific to this document, even if it
> is highli= ghted that the risk is not new.

GIM>> Then that "rogue" node is the PIM DR/BDR, not a man-i= n-the-middle.
GIM>> And the attack is by m= aking the p2mp BFD session expire on leaves
GIM&= gt;> while still periodically sending PIM Hello. AFAIK, since PIM
GIM>> DR/BDR election takes several Hello cycles= , I don't think that
GIM>> that behavior w= ill affect the multicast service. Perhaps I'm missing something, please adv= ise.

Yes, the problem = is that =C2=A72.1 says that the tail "MUST delete the corresponding neighbo= r state".  This results in the DR not being elected for a while.

I see what you mean: if the= DR is still there then the election will probably elect it again.  Ho= wever, in the meantime the DR may not think it is the DR anymore if the oth= er routers in the LAN start a new DR election. (??)   Please add the e= xplanation (or something like it) to make it clear that the risk is mitigat= ed by the "double set of hellos".

In the general case...  If tracking the sender of a Join, = for example, the effect would be more significant: an outage would exist un= til the next Join is received.


...
> 310 = 7.1. Normative References
> ..
> 327 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwardi= ng
> Detection
>= 328 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
> 329 DOI 10.17487/RFC5881, June 2010,
&g= t; 330 .
>
> [min= or] This reference can be Informative.

=
I know you moved it...but now that you added a reference t= o it in =C2=A72.3 then we need it to be Normative.  Sorry.


...
> [End of review -05.]



[Start -06]
[Line numbers from idnits.]<= br>

...
129    2.  BFD Discriminator PIM Hello Option<= br>
...
153  &nbs= p;   If the value of the OptionLength field is not equal to 4, the BF= D
154      Discriminator PIM= Hello option is considered malformed, and the
15= 5      receiver MUST stop processing PIM Hello options= .  If the value of the
156   =   My Discriminator field equals zero, then the BFD Discriminator PIM=
157      Hello option MUST = be considered invalid, and the receiver MUST ignore
158      it.  The receiver SHOULD log the noti= fication regarding the malformed
159  &= nbsp;   or invalid BFD Discriminator Hello option under the control o= f a
160      throttling logg= ing mechanism.

[major]= "MUST stop processing PIM Hello options"

Stop in the current Hello message?  Should it igno= re all the options or just the ones after this one?  In all future Hel= lo messages?

I haven't= thought about this enough, but there could be an effect on other functiona= lity.  What is that effect?  I couldn't find anywhere a general w= ay to handle malformed Hello options -- did I miss it?


[nit] s/log the= notification/log a notification


162    2.1.  Usin= g P2MP BFD in PIM DR/BDR Monitoring
...
=
169      If a PIM-SM router is config= ured to monitor the head by using p2mp
170 &= nbsp;    BFD, referred to through this document as 'tail', recei= ves PIM-Hello
171      packe= t with BFD Discriminator PIM Hello option, the tail MAY create a
<= div dir=3D"ltr">172      p2mp BFD session of type Mult= ipointTail, as defined in [RFC8562].

[minor] s/router is configured/router that is configured
=

[nit] s/receives PIM-Hell= o packet with BFD Discriminator/receives a PIM-Hello packet with the BFD Di= scriminator


=
...
188     = ; If the head ceases to include the BFD Discriminator PIM Hello option
<= /div>
189      in its PIM-Hello messag= e, tails MUST close the corresponding
190 &n= bsp;    MultipointTail BFD session.  Thus the tail stops us= ing BFD to monitor
191      = the head and reverts to the procedures defined in [RFC7761] and
192      [I-D.ietf-pim-dr-improvement].=

[minor] "...MUST clos= e the corresponding MultipointTail BFD session"
<= br>
It might be a good thing adding that the PIM stat= e is not affected by this action.


194    2.2.  P2M= P BFD in PIM DR Load Balancing

196      [RFC8775] specifies the PIM Designat= ed Router Load Balancing (DRLB)
197  &n= bsp;   functionality.  Any PIM router that advertises the DRLB-C= ap Hello
198      Option can= become the head of a p2mp BFD session, as specified in
199      Section 2.1.  The head router a= dministratively sets the
200    &= nbsp; bfd.SessionState to Up in the MultipointHead session [RFC8562] only
201      if it is a Group Des= ignated Router (GDR) Candidate, as specified in
2= 02      Sections 5.5 and 5.6 of [RFC8775].  If th= e router is no longer the
203    =   GDR, then it MUST shut down following the procedures described in
204      Section 5.9 [RFC8562]= .  For each GDR Candidate that includes BFD
= 205      Discriminator option in its PIM Hello, the PI= M DR creates a
206      Mult= ipointTail session [RFC8562].  PIM DR demultiplexes BFD sessions
207      based on the value of th= e My Discriminator field and the source IP
208&nb= sp;     address.  If PIM DR detects a failure of one o= f the sessions, it MUST
209    &n= bsp; remove that router from the GDR Candidate list and immediately
210      transmit a new DRLB-List o= ption.

[] Continuing w= ith my theme of generalizing this specification...
This section says everything that the last section already specified in a= generic way.  IOW, it is not really needed.

There is one thing that this paragraph adds: "I= f the router is no longer the GDR, then it MUST shut down following the pro= cedures described in Section 5.9 [RFC8562]."   Yes, shutting down the = BFD session is important, but so is not including the BFD Discriminator opt= ion in the Hello anymore.  As with everything else, this part can also= be generalized:

 = ;  If the head is no longer serving the function that prompted it
<= /div>
   to be monitored, then it MUST cease incl= uding the BFD Discriminator
   PIM Hell= o option in its PIM-Hello message, and it MUST shut down
   the BFD session following the procedures described in= Section 5.9
   [RFC8562].


212&nbs= p;   2.3.  Multipoint BFD Encapsulation

214      The Multipoi= ntHead of a p2mp BFD session when transmitting BFD
215      Control packet:
<= br>
[nit] s/packet/packets
=

217   =      MUST set TTL or Hop Limit value to 255 (Section 5 [RF= C5881]);

[major] "MUST= set...RFC5881"   This action is already required in an RFC that this = document depends on, please don't specify the behavior again.  I under= stand that rfc5682 can be used in multi-hop scenarios, but rfc5881 is the s= ource here.    s/MUST/must


...
222=     3.  IANA Considerations
.= ..
227      +=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= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
228  &n= bsp;   | Value Name  | Length Number  | Name Protocol  = ;   | Reference     |
229 &nb= sp;    +=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
=
230      | TBA       &= nbsp; | 4              | BFD Discriminat= or | This document |
231     = ; |             |        =        | Option           &nb= sp;|               |
232      +-------------+----------------+----= ---------------+---------------+

[major] Please use the same field names as in the registry: Valu= e, Length, Name, Reference

[EoR -06]

_______= ________________________________________
pim mail= ing list

_______________________________________________
pim mailing list
------=_Part_417156_1899740743.1629489910464-- From nobody Sun Aug 22 08:18:36 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315063A0F3A; Fri, 20 Aug 2021 19:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZNd7CqDnmnzn; Fri, 20 Aug 2021 19:18:50 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967583A0F2F; Fri, 20 Aug 2021 19:18:50 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id x16so10183950pfh.2; Fri, 20 Aug 2021 19:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8gybUwlaayqTMWdVgg+C1f+mWKXLv7n2ihbbjqdPvr4=; b=gez5UvmR1SzAvjFSgxb3ZkVuuz3FYpQOm4Tlq6qBCoHfmbmiCLtPFUnudjCcadeI4u PSIDnVuNju8rQZgFNaNaxTeq6XM5nxBOGNtk2kcDfhF824keXb7KutMkH33XGGGJvOJJ Iy4v6qZywRRMPdJOSXYGP6cp+IJBL93dvDNIkkPwgnS63pNiIyiwcqYP5vmL7Ncnh70z z29E3v8pf0xEeqs2caWRrul7AB2jvXm2+p1rppykSug27VYmzJ6meDfAmPjqME9c3K4P YP4OrKupEeNyctmiIIRs/MrdcpL7YaRxk85cMHN67AifT2I/LlodoMvCMb3aoNEhQB7W 8Q+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8gybUwlaayqTMWdVgg+C1f+mWKXLv7n2ihbbjqdPvr4=; b=SEB5tjrVZbGcNtPsU3HfruZaWWTmuXa23Sib4tiD65vti988QDhVAA0gPvWxCBF7Jg 1Z30qmp39pPAboFc3YAtZNK7g49E+h0xCuVQshccSpviUVcbwwzh6+BrKbFwKMjwk+AO 7eF1MyDlsWq/GZUPnbDdz6p+wYsyK9thTMQkCYJak5R1PBQ3vX4edqAnANGR5PFjOPEj lJt7y5k+tPM6WxFcsXKOuw4xlg1ydBgVU64BBnvluDp9p9ncRmSjJIXqPmBlqETYAl2M gdGobHRMHnkwYp5BNh6X8zJG7GksmIocZSSmCPqRe+SAxxvMjeXfrIq5toSoFY1WWET9 6E+w== X-Gm-Message-State: AOAM532QrxpkWL7Lj2v7HjP0fG1OAL/e1uBOBH/zbc2ingcreITzNhUR C5ZHp6HZxlVqhJ/03L/rEH4ycN77R4Gy2vl41Pg= X-Google-Smtp-Source: ABdhPJxeaEGH0lAwFk09lG06TEESfg6CTAxlq6OnD7lI+YsiZpONvcQzR6bRRVr3AAALv+JIL61L5NOdo0JcC7tP12o= X-Received: by 2002:a63:504a:: with SMTP id q10mr21329117pgl.383.1629512328789; Fri, 20 Aug 2021 19:18:48 -0700 (PDT) MIME-Version: 1.0 References: <202107220742327030208@zte.com.cn> <1867869445.417157.1629489910471@mail.yahoo.com> In-Reply-To: <1867869445.417157.1629489910471@mail.yahoo.com> From: Gyan Mishra Date: Fri, 20 Aug 2021 22:18:37 -0400 Message-ID: Subject: Re: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05 To: Reshad Rahman Cc: Michael McBride , Rtg-bfd WG , "pim-chairs@ietf.org" Content-Type: multipart/alternative; boundary="00000000000083c29f05ca08671b" Archived-At: X-Mailman-Approved-At: Sun, 22 Aug 2021 08:18:24 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2021 02:18:58 -0000 --00000000000083c29f05ca08671b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Authors I agree with Alvaro that this draft has many use cases for future work using RFC 8562 P2MP BFD to bootstrap the BFD season for sub second convergence and action tale takes after detecting the failure. My thoughts regarding this draft as the key focus is on PIM-SM DR/BDR convergence. I think normative language to touch on PIM WG related use cases makes sense. As for the generalization use case, I think that could be a separate draft that talks about a variety of use cases which helps open the door for future work across the board. As this draft had =E2=80=9Cuse case=E2=80=9D in the name, I believe the au= thors intention was to provide generalizations of use cases. Since the use cases have very broad applicability my thoughts are for RTGWG for a generalized draft documenting use cases and I would be happy to contribute to ideas of use case across all Routing area WG=E2=80=99s. Kind Regards Gyan On Fri, Aug 20, 2021 at 4:14 PM Reshad Rahman wrote: > Thanks Michael. Adding BFD WG. > > Regards, > Reshad. > > -----Original Message----- > From: pim On Behalf Of Michael McBride > Sent: Tuesday, August 17, 2021 10:53 PM > To: Alvaro Retana ; gregory.mirsky@ztetx.com > Cc: draft-ietf-pim-bfd-p2mp-use-case@ietf.org; mmcbride7@gmail.com; > pim-chairs@ietf.org; pim@ietf.org > Subject: Re: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05 > > Hi Greg, > > Please consider either 1) dropping the "use-case" from the draft name and > keep it a specific pim-bfd-p2mp solution and less generalized or 2) keepi= ng > the existing name and make it more generalized with more use cases as > Alvaro suggests. > > I'll ping the bfd chairs and cc you to ensure they are in the loop. > > Thanks, > mike > > -----Original Message-----2021-02-04-Network TMT Meetings : https://nam11= .safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fefutureway.sharepoin= t.com%2Fteams%2FNetworkLabTMT%2FShared&data=3D04%7C01%7Cmichael.mcbride%40f= uturewei.com%7C58e9d5e586be49da514708d9620c8c21%7C0fee8ff2a3b240189c753a1d5= 591fedc%7C1%7C1%7C637648628320865112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj= AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DAlTELyg= 1EqhpLnl8aYSCv9YKEH6zldm46UVAx8MZaus%3D&reserved=3D0 > Documents/General/Network Lab TMT Meeting/February 4 2021 > Meeting/2021-02-04-Network TMT Meetings.pptx?web=3D1G > From: pim On Behalf Of Alvaro Retana > Sent: Tuesday, August 17, 2021 8:19 AM > To: gregory.mirsky@ztetx.com > Cc: draft-ietf-pim-bfd-p2mp-use-case@ietf.org; mmcbride7@gmail.com; > pim-chairs@ietf.org; pim@ietf.org > Subject: Re: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05 > > On July 21, 2021 at 7:42:42 PM, gregory.mirsky@ztetx.com wrote: > > > Greg: > > Hi! > > Thanks for the update!! > > I have some comments in-line. I am also attaching (below) a review of > -06, which mostly contains minor issues and nits related to new/updated > text. > > > The main item I would like WG input on is the generalization of the > mechanism. In short, bootstrapping the BFD session is the main focus of > this document; I don't see a reason to avoid generalizing its use to othe= r > scenarios. We already agree on the wider applicability -- the incrementa= l > changes needed to generalize the text is far less than the process it wil= l > take to do it later. > > Mike: as Shepherd/Chair, please start a conversation in the WG as needed. > Please take a look at the discussion below. > > > Thanks! > > Alvaro. > > > > ... > > Sender: AlvaroRetana > ... > > This document specifies two things: (1) a Hello option to help the > > tail bootstrap the BFD session, and, (2) the actions that the tail > > takes when a failure is detected. The former is common to all cases, > > while the latter depends on the role of the head with respect to the > > tail. The actions are basically an acceleration of what would > > naturally happen (if BFD was not used and the failure detection was > > "slow"). Is this a fair characterization of the document? > > GIM>> Yes, absolutely correct. > > ... > > Are there other cases that could use this mechanism to track? I can > > think of a couple of cases: monitor PIM neighbors that send Joins, RPF > > neighbors, Assert winners... As with the DR case, for example, these > > cases don't require actions beyond an acceleration. It would be ideal > > if the document could cover these cases, and possibly others, in a > > generic way -- I can't think of good phrasing with now, but I'm sure > > you can. ;-) > > GIM>> I agree that the defined PIM Hello BFD Discriminator option can be > GIM>> used by not only PIM DR/BDR nodes. Indeed, there are other use > GIM>> cases where a faster detection will improve the convergence in the > GIM>> control plane and minimize the negative impact on the multicast > GIM>> data plane. These use cases may be covered in the future. > > Maybe I'm missing something obvious, and would like to understand what. := -) > > The Hello option helps the tail bootstrap a BFD session, correct? If so, > there's nothing in that description about the function of the tail (or th= e > head). The point that I'm trying to make above is that the only thing th= at > BFD is providing any use case is faster detection of a failure (which is > very significant, of course!), so regardless of the application or functi= on > of the tail/head, the operation can be generalized. Is this not true? > What am I missing? > > To be more specific, the description in =C2=A72.1 (Using P2MP BFD in PIM = DR/BDR > Monitoring) is a generic description, and not one that only applies to a > DR/BDR. In fact, the text says that any node "regardless of its role, MA= Y > become a head of a p2mp BFD session" -- which means that it is up to the > tail to monitor it or not. > > The last two paragraphs in =C2=A72.1 do mention the DR/BDR function, but = they > could easily be generalized: > > OLD> > If the tail detects a MultipointHead failure [RFC8562], it MUST > delete the corresponding neighbor state. If the failed head was the > DR (or BDR), the DR (or BDR) election mechanism in [RFC7761] or > [I-D.ietf-pim-dr-improvement] is followed. > > If the head ceases to include the BFD Discriminator PIM Hello option > in its PIM-Hello message, tails MUST close the corresponding > MultipointTail BFD session. Thus the tail stops using BFD to monitor > the head and reverts to the procedures defined in [RFC7761] and > [I-D.ietf-pim-dr-improvement]. > > > NEW> > If the tail detects a MultipointHead failure [RFC8562], it MUST > delete the corresponding neighbor state. If the head ceases to > include the BFD Discriminator PIM Hello option in its PIM-Hello > message, tails MUST close the corresponding MultipointTail BFD > session. In both cases, the tail continues to follow the > specification related to the function of the head. > > > > GIM>> As I think of it, one aspect would be homogeneity of p2mp BFD > GIM>> capability throughout the domain. In other words, what happens if > GIM>> some PIM nodes don't support the BFD Discriminator option and do > GIM>> not use p2mp BFD? What their slow (regular) convergence impact > GIM>> other nodes? But that, I think, is for further discussion, work. > Would you agree? > > I don't. > > In fact, this is a very important deployment point that I had overlooked. > If the support is not homogeneous, then some parts of the network will > converge (to the new state) faster than others. As with unicast routing I > think the main effect may be longer than expected inconsistency, but not > worst than without BFD. The specific effect relates to the use case...bu= t > because the deployment would be localized (the DR and other routers on th= e > LAN, for example), then any negative effect of not supporting BFD (i.e. > behaving as today) would be localized. > > Thank you for bringing this up. If you consider the effect significant > for a specific case then please add a couple of sentences. > > > ... > > 183 3.1. Using P2MP BFD in PIM DR/BDR Monitoring > ... > > 229 If the head ceased to include BFD TLV in its PIM-Hello message, > > tails > > 230 MUST close the corresponding MultipointTail BFD session. Thus the > > 231 tail stops using BFD to monitor the head and reverts to the > > 232 procedures defined in [RFC7761] and [I-D.ietf-pim-dr-improvement]. > ... > > [major] Let me see if I understand: if the head doesn't use the BFD > > hello option anymore then the tail can gracefully stop using BFD. > > IOW, this way the BFD session does not expire and result in the DR > > being declared dead. Is that it? > > GIM>> Yes, that is what we've intended - revert to "slow" detection. > > > Given that the BFD session can be bootstrapped at the tail by manually > > configuring the corresponding discriminator, it seems that stopping > > the use of the BFD hello option may not result in the expected > > outcome. ??? > > GIM>> Yes, the head's My Discriminator value can be provisioned using > GIM>> the management plane. If that is the case, then I think this > GIM>> document is not applicable as the head and leaves use RFC 8562 > without any additions. > > The problem is that the text now says this: > > If the head ceases to include the BFD Discriminator PIM Hello option > in its PIM-Hello message, tails MUST close the corresponding > MultipointTail BFD session. Thus the tail stops using BFD to monitor > the head... > > s/MUST/SHOULD Provisioning the node is the exception, so the action > should be recommended and not required. > > > ... > > 288 5. Security Considerations > ... > > 299 An implementation that supports this specification SHOULD use a > > 300 mechanism to control the maximum number of BFD sessions that can > > be > > 301 active at the same time. > > > > [major] rfc8562 already requires "protective measures to prevent an > > infinite number of MultipointTail sessions from being created". It is > > then not needed for this document to recommend anything that is > > required elsewhere. > > GIM>> Done. > > ?? You left the paragraph in. > > > > [major] What new security risks are introduced by the mechanism in > > this draft? In general, a rogue node can stop sending or delay BFD > > packets causing the tail to conclude that the head is down: the DR/BDR > > may change causing instability. I was surprised that rfc8562 did not > > mention the interaction risk, but rfc5880 already does. I feel that > > something needs to be mentioned specific to this document, even if it > > is highlighted that the risk is not new. > > GIM>> Then that "rogue" node is the PIM DR/BDR, not a man-in-the-middle. > GIM>> And the attack is by making the p2mp BFD session expire on leaves > GIM>> while still periodically sending PIM Hello. AFAIK, since PIM > GIM>> DR/BDR election takes several Hello cycles, I don't think that > GIM>> that behavior will affect the multicast service. Perhaps I'm missin= g > something, please advise. > > Yes, the problem is that =C2=A72.1 says that the tail "MUST delete the > corresponding neighbor state". This results in the DR not being elected > for a while. > > I see what you mean: if the DR is still there then the election will > probably elect it again. However, in the meantime the DR may not think i= t > is the DR anymore if the other routers in the LAN start a new DR election= . > (??) Please add the explanation (or something like it) to make it clear > that the risk is mitigated by the "double set of hellos". > > In the general case... If tracking the sender of a Join, for example, th= e > effect would be more significant: an outage would exist until the next Jo= in > is received. > > > ... > > 310 7.1. Normative References > > .. > > 327 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding > > Detection > > 328 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, > > 329 DOI 10.17487/RFC5881, June 2010, > > 330 . > > > > [minor] This reference can be Informative. > > I know you moved it...but now that you added a reference to it in =C2=A72= .3 > then we need it to be Normative. Sorry. > > > ... > > [End of review -05.] > > > > [Start -06] > [Line numbers from idnits.] > > ... > 129 2. BFD Discriminator PIM Hello Option > ... > 153 If the value of the OptionLength field is not equal to 4, the BF= D > 154 Discriminator PIM Hello option is considered malformed, and the > 155 receiver MUST stop processing PIM Hello options. If the value o= f > the > 156 My Discriminator field equals zero, then the BFD Discriminator P= IM > 157 Hello option MUST be considered invalid, and the receiver MUST > ignore > 158 it. The receiver SHOULD log the notification regarding the > malformed > 159 or invalid BFD Discriminator Hello option under the control of a > 160 throttling logging mechanism. > > [major] "MUST stop processing PIM Hello options" > > Stop in the current Hello message? Should it ignore all the options or > just the ones after this one? In all future Hello messages? > > I haven't thought about this enough, but there could be an effect on othe= r > functionality. What is that effect? I couldn't find anywhere a general > way to handle malformed Hello options -- did I miss it? > > > [nit] s/log the notification/log a notification > > > 162 2.1. Using P2MP BFD in PIM DR/BDR Monitoring > ... > 169 If a PIM-SM router is configured to monitor the head by using p2= mp > 170 BFD, referred to through this document as 'tail', receives > PIM-Hello > 171 packet with BFD Discriminator PIM Hello option, the tail MAY > create a > 172 p2mp BFD session of type MultipointTail, as defined in [RFC8562]= . > > [minor] s/router is configured/router that is configured > > [nit] s/receives PIM-Hello packet with BFD Discriminator/receives a > PIM-Hello packet with the BFD Discriminator > > > ... > 188 If the head ceases to include the BFD Discriminator PIM Hello > option > 189 in its PIM-Hello message, tails MUST close the corresponding > 190 MultipointTail BFD session. Thus the tail stops using BFD to > monitor > 191 the head and reverts to the procedures defined in [RFC7761] and > 192 [I-D.ietf-pim-dr-improvement]. > > [minor] "...MUST close the corresponding MultipointTail BFD session" > > It might be a good thing adding that the PIM state is not affected by thi= s > action. > > > 194 2.2. P2MP BFD in PIM DR Load Balancing > > 196 [RFC8775] specifies the PIM Designated Router Load Balancing > (DRLB) > 197 functionality. Any PIM router that advertises the DRLB-Cap Hell= o > 198 Option can become the head of a p2mp BFD session, as specified i= n > 199 Section 2.1. The head router administratively sets the > 200 bfd.SessionState to Up in the MultipointHead session [RFC8562] > only > 201 if it is a Group Designated Router (GDR) Candidate, as specified > in > 202 Sections 5.5 and 5.6 of [RFC8775]. If the router is no longer t= he > 203 GDR, then it MUST shut down following the procedures described i= n > 204 Section 5.9 [RFC8562]. For each GDR Candidate that includes BFD > 205 Discriminator option in its PIM Hello, the PIM DR creates a > 206 MultipointTail session [RFC8562]. PIM DR demultiplexes BFD > sessions > 207 based on the value of the My Discriminator field and the source = IP > 208 address. If PIM DR detects a failure of one of the sessions, it > MUST > 209 remove that router from the GDR Candidate list and immediately > 210 transmit a new DRLB-List option. > > [] Continuing with my theme of generalizing this specification... > This section says everything that the last section already specified in a > generic way. IOW, it is not really needed. > > There is one thing that this paragraph adds: "If the router is no longer > the GDR, then it MUST shut down following the procedures described in > Section 5.9 [RFC8562]." Yes, shutting down the BFD session is important= , > but so is not including the BFD Discriminator option in the Hello anymore= . > As with everything else, this part can also be generalized: > > If the head is no longer serving the function that prompted it > to be monitored, then it MUST cease including the BFD Discriminator > PIM Hello option in its PIM-Hello message, and it MUST shut down > the BFD session following the procedures described in Section 5.9 > [RFC8562]. > > > 212 2.3. Multipoint BFD Encapsulation > > 214 The MultipointHead of a p2mp BFD session when transmitting BFD > 215 Control packet: > > [nit] s/packet/packets > > > 217 MUST set TTL or Hop Limit value to 255 (Section 5 [RFC5881]); > > [major] "MUST set...RFC5881" This action is already required in an RFC > that this document depends on, please don't specify the behavior again. = I > understand that rfc5682 can be used in multi-hop scenarios, but rfc5881 i= s > the source here. s/MUST/must > > > ... > 222 3. IANA Considerations > ... > 227 > +=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > 228 | Value Name | Length Number | Name Protocol | Reference > | > 229 > +=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > 230 | TBA | 4 | BFD Discriminator | This > document | > 231 | | | Option | > | > 232 > +-------------+----------------+-------------------+---------------+ > > [major] Please use the same field names as in the registry: Value, Length= , > Name, Reference > > [EoR -06] > > _______________________________________________ > pim mailing list > pim@ietf.org > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fpim&data=3D04%7C01%7Cmichael.mcbride%40futur= ewei.com%7C58e9d5e586be49da514708d9620c8c21%7C0fee8ff2a3b240189c753a1d5591f= edc%7C1%7C1%7C637648628320865112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD= AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DzhFkLPkgOJ9= EeuloewKnNDe75JqgzbOWdfV3%2Bd5EBRk%3D&reserved=3D0 > > _______________________________________________ > pim mailing list > pim@ietf.org > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fpim&data=3D04%7C01%7Cmichael.mcbride%40futur= ewei.com%7C58e9d5e586be49da514708d9620c8c21%7C0fee8ff2a3b240189c753a1d5591f= edc%7C1%7C1%7C637648628320875108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD= AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D4SrgiS9qdwY= swCMitpP4Qf1iWZ4zJkVauDz%2B4%2BKyvyA%3D&reserved=3D0 > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --00000000000083c29f05ca08671b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Authors=C2=A0

I agree with Alvaro that this draft has many use cases for fut= ure work using RFC 8562 P2MP BFD to bootstrap the BFD season for sub second= convergence and action tale takes after detecting the failure. =C2=A0

My thoughts regarding this d= raft as the key focus is on PIM-SM DR/BDR convergence.=C2=A0 I think normat= ive language to touch on PIM WG related use cases makes sense.

As for the generalization use case, = I think that could be a separate draft that talks about a variety of use ca= ses which helps open the door for future work across the board.

As this draft had =E2=80=9Cuse case= =E2=80=9D in the =C2=A0name, I believe the authors intention was to provide= generalizations of use cases.

Since the use cases have very broad applicability my thoughts are fo= r RTGWG for a generalized draft documenting use cases =C2=A0and I would be = happy to contribute to ideas of use case across all Routing area WG=E2=80= =99s.


Kind Regards=C2=A0

Gyan


On Fri, Aug 20, 2021 at 4:14 PM R= eshad Rahman <reshad=3D40y= ahoo.com@dmarc.ietf.org> wrote:
Thanks Michael.=C2=A0 Adding= BFD WG.

Regards,
Reshad.<= /div>

-----Original Mess= age-----
From: pim <pim-bounces@ietf.org= > On Behalf Of Michael McBride
Sent: Tuesday,= August 17, 2021 10:53 PM
To: Alvaro Retana <= aretana.ietf@gmail.com>; gregory.mirsky@ztetx.com



From: pim <pim-bounces@ietf.org> On Behalf= Of Alvaro Retana
Sent: Tuesday, August 17, 2021= 8:19 AM
Cc: draft-ietf-pim-bfd-p2mp= -use-case@ietf.org; mmcbride7@gmail.com; pim-chairs@ietf.org; <= a href=3D"mailto:pim@ietf.org" rel=3D"nofollow" target=3D"_blank" style=3D"= font-family:"Helvetica Neue",Helvetica,Arial,sans-serif">pim@ietf= .org
Subject: Re: [pim] AD Review of draft-i= etf-pim-bfd-p2mp-use-case-05

On July 21, 2021 at 7:42:42 PM, gregory.mirsky@ztetx.com= wrote:


Greg:


Thanks for the= update!!

I have som= e comments in-line.=C2=A0 I am also attaching (below) a review of -06, whic= h mostly contains minor issues and nits related to new/updated text.



Mike: as Shepherd/Chair, please start a conversation in the WG as= needed.=C2=A0 Please take a look at the discussion below.


Thanks!<= br>

Alvaro.



=
...
> Sender: AlvaroR= etana
...
> This d= ocument specifies two things: (1) a Hello option to help the
> tail bootstrap the BFD session, and, (2) the actions tha= t the tail
> takes when a failure is detecte= d. The former is common to all cases,
> whil= e the latter depends on the role of the head with respect to the
=
> tail. The actions are basically an acceleration of w= hat would
> naturally happen (if BFD was not= used and the failure detection was
> "= slow"). Is this a fair characterization of the document?

GIM>> Yes, absolutely corre= ct.

...
> Are there other cases that could use this mechanism to = track? I can
> think of a couple of cases: m= onitor PIM neighbors that send Joins, RPF
>= neighbors, Assert winners... As with the DR case, for example, these
<= /div>
> cases don't require actions beyond an accel= eration. It would be ideal
> if the document= could cover these cases, and possibly others, in a
> generic way -- I can't think of good phrasing with now, but I= 'm sure
> you can. ;-)

GIM>> I agree that the defined = PIM Hello BFD Discriminator option can be
GIM&= gt;> used by not only PIM DR/BDR nodes. Indeed, there are other use
=
GIM>> cases where a faster detection will imp= rove the convergence in the
GIM>> control= plane and minimize the negative impact on the multicast
GIM>> data plane. These use cases may be covered in the fut= ure.

Maybe I'm m= issing something obvious, and would like to understand what. :-)
<= div dir=3D"ltr" style=3D"font-family:"Helvetica Neue",Helvetica,A= rial,sans-serif">
The Hello option helps the tai= l bootstrap a BFD session, correct?=C2=A0 If so, there's nothing in tha= t description about the function of the tail (or the head).=C2=A0 The point= that I'm trying to make above is that the only thing that BFD is provi= ding any use case is faster detection of a failure (which is very significa= nt, of course!), so regardless of the application or function of the tail/h= ead, the operation can be generalized.=C2=A0 Is this not true?=C2=A0 What a= m I missing?

To be m= ore specific, the description in =C2=A72.1 (Using P2MP BFD in PIM DR/BDR Mo= nitoring) is a generic description, and not one that only applies to a DR/B= DR.=C2=A0 In fact, the text says that any node "regardless of its role= , MAY become a head of a p2mp BFD session" -- which means that it is u= p to the tail to monitor it or not.

The last two paragraphs in =C2=A72.1 do mention the DR/BDR = function, but they could easily be generalized:
=
OLD>
=C2=A0 =C2= =A0If the tail detects a MultipointHead failure [RFC8562], it MUST
=C2=A0 =C2=A0delete the corresponding neighbor state.=C2= =A0 If the failed head was the
=C2=A0 =C2=A0DR (= or BDR), the DR (or BDR) election mechanism in [RFC7761] or
=C2=A0 =C2=A0[I-D.ietf-pim-dr-improvement] is followed.

=C2=A0 =C2=A0If the head ce= ases to include the BFD Discriminator PIM Hello option
=C2=A0 =C2=A0in its PIM-Hello message, tails MUST close the correspo= nding
=C2=A0 =C2=A0MultipointTail BFD session.= =C2=A0 Thus the tail stops using BFD to monitor
= =C2=A0 =C2=A0the head and reverts to the procedures defined in [RFC7761] an= d
=C2=A0 =C2=A0[I-D.ietf-pim-dr-improvement].


NEW>
=C2=A0 =C2=A0If the tail detects a= MultipointHead failure [RFC8562], it MUST
=C2= =A0 =C2=A0delete the corresponding neighbor state.=C2=A0 If the head ceases= to
=C2=A0 =C2=A0include the BFD Discriminator P= IM Hello option in its PIM-Hello
=C2=A0 =C2=A0me= ssage, tails MUST close the corresponding MultipointTail BFD
=C2=A0 =C2=A0session.=C2=A0 In both cases, the tail continues = to follow the
=C2=A0 =C2=A0specification related= to the function of the head.



GIM>&g= t; As I think of it, one aspect would be homogeneity of p2mp BFD
=
GIM>> capability throughout the domain. In other wo= rds, what happens if
GIM>> some PIM nodes= don't support the BFD Discriminator option and do
GIM>> not use p2mp BFD? What their slow (regular) convergen= ce impact
GIM>> other nodes? But that, I = think, is for further discussion, work. Would you agree?

I don't.

In fact, this is a very important deployment= point that I had overlooked.=C2=A0 If the support is not homogeneous, then= some parts of the network will converge (to the new state) faster than oth= ers. As with unicast routing I think the main effect may be longer than exp= ected inconsistency, but not worst than without BFD.=C2=A0 The specific eff= ect relates to the use case...but because the deployment would be localized= (the DR and other routers on the LAN, for example), then any negative effe= ct of not supporting BFD (i.e. behaving as today) would be localized.

Thank you for bringing th= is up.=C2=A0 If you consider the effect significant for a specific case the= n please add a couple of sentences.


...
= > 183 3.1. Using P2MP BFD in PIM DR/BDR Monitoring
...
> 229 If the head ceased to include= BFD TLV in its PIM-Hello message,
> tails
> 230 MUST close the corresponding MultipointT= ail BFD session. Thus the
> 231 tail stops us= ing BFD to monitor the head and reverts to the
&= gt; 232 procedures defined in [RFC7761] and [I-D.ietf-pim-dr-improvement].<= br>
...
> [major] Let = me see if I understand: if the head doesn't use the BFD
> hello option anymore then the tail can gracefully stop us= ing BFD.
> IOW, this way the BFD session does= not expire and result in the DR
> being dec= lared dead. Is that it?

GIM>> Yes, that is what we've intended - revert to "slow= " detection.

&g= t; Given that the BFD session can be bootstrapped at the tail by manually <= br>
> configuring the corresponding discriminator= , it seems that stopping
> the use of the BF= D hello option may not result in the expected
&= gt; outcome. ???

GIM= >> Yes, the head's My Discriminator value can be provisioned usin= g
GIM>> the management plane. If that is = the case, then I think this
GIM>> documen= t is not applicable as the head and leaves use RFC 8562 without any additio= ns.

The problem is t= hat the text now says this:

=C2=A0 =C2=A0If the head ceases to include the BFD Discriminator = PIM Hello option
=C2=A0 =C2=A0in its PIM-Hello m= essage, tails MUST close the corresponding
=C2= =A0 =C2=A0MultipointTail BFD session.=C2=A0 Thus the tail stops using BFD t= o monitor
=C2=A0 =C2=A0the head...

s/MUST/SHOULD =C2=A0 Provisioning= the node is the exception, so the action should be recommended and not req= uired.


...
> 288 5. Security Consider= ations
...
> 299 A= n implementation that supports this specification SHOULD use a
> 300 mechanism to control the maximum number of BFD sess= ions that can
> be
>
> [major] rfc8562 already requires "protective = measures to prevent an
> infinite number of = MultipointTail sessions from being created". It is
> then not needed for this document to recommend anything that= is
> required elsewhere.

GIM>> Done.

??=C2=A0 You left the paragraph in.


> [major] What new security risks are introduced by the mechanism= in
> this draft? In general, a rogue node c= an stop sending or delay BFD
> packets causi= ng the tail to conclude that the head is down: the DR/BDR
> may change causing instability. I was surprised that rfc856= 2 did not
> mention the interaction risk, bu= t rfc5880 already does. I feel that
> someth= ing needs to be mentioned specific to this document, even if it
<= div dir=3D"ltr" style=3D"font-family:"Helvetica Neue",Helvetica,A= rial,sans-serif">> is highlighted that the risk is not new.

GIM>> Then that "rogu= e" node is the PIM DR/BDR, not a man-in-the-middle.
GIM>> And the attack is by making the p2mp BFD session expi= re on leaves
GIM>> while still periodical= ly sending PIM Hello. AFAIK, since PIM
GIM>&= gt; DR/BDR election takes several Hello cycles, I don't think that
=
GIM>> that behavior will affect the multicast= service. Perhaps I'm missing something, please advise.

Yes, the problem is that =C2=A72.1 = says that the tail "MUST delete the corresponding neighbor state"= .=C2=A0 This results in the DR not being elected for a while.

I see what you mean: if the DR is= still there then the election will probably elect it again.=C2=A0 However,= in the meantime the DR may not think it is the DR anymore if the other rou= ters in the LAN start a new DR election. (??) =C2=A0 Please add the explana= tion (or something like it) to make it clear that the risk is mitigated by = the "double set of hellos".

=
In the general case...=C2=A0 If tracking the sender of a = Join, for example, the effect would be more significant: an outage would ex= ist until the next Join is received.

<= div dir=3D"ltr" style=3D"font-family:"Helvetica Neue",Helvetica,A= rial,sans-serif">
...
> 310 7.1. Normative References
> ..
<= /div>
> 327 [RFC5881] Katz, D. and D. Ward, "Bidir= ectional Forwarding
> Detection
> 328 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 588= 1,
> 329 DOI 10.17487/RFC5881, June 2010,
=
> 330 .
>
> [minor] This reference can be Informative.

I know you moved it...but no= w that you added a reference to it in =C2=A72.3 then we need it to be Norma= tive.=C2=A0 Sorry.

<= br>
...
> [End of revi= ew -05.]


<= div dir=3D"ltr" style=3D"font-family:"Helvetica Neue",Helvetica,A= rial,sans-serif">
[Start -06]
[Line numbers from idnits.]

=
...
129=C2=A0=C2=A0=C2=A0 2.= =C2=A0 BFD Discriminator PIM Hello Option
...<= br>
153=C2=A0=C2=A0=C2=A0 =C2=A0 If the value of th= e OptionLength field is not equal to 4, the BFD
= 154=C2=A0=C2=A0=C2=A0 =C2=A0 Discriminator PIM Hello option is considered = malformed, and the
155=C2=A0=C2=A0=C2=A0 =C2=A0= receiver MUST stop processing PIM Hello options.=C2=A0 If the value of the=
156=C2=A0=C2=A0=C2=A0 =C2=A0 My Discriminator = field equals zero, then the BFD Discriminator PIM
158=C2=A0=C2=A0=C2=A0= =C2=A0 it.=C2=A0 The receiver SHOULD log the notification regarding the m= alformed
159=C2=A0=C2=A0=C2=A0 =C2=A0 or invali= d BFD Discriminator Hello option under the control of a
160=C2=A0=C2=A0=C2=A0 =C2=A0 throttling logging mechanism.

[major] "MUST stop p= rocessing PIM Hello options"

Stop in the current Hello message?=C2=A0 Should it ignore all= the options or just the ones after this one?=C2=A0 In all future Hello mes= sages?

I haven't= thought about this enough, but there could be an effect on other functiona= lity.=C2=A0 What is that effect?=C2=A0 I couldn't find anywhere a gener= al way to handle malformed Hello options -- did I miss it?


[nit] s/= log the notification/log a notification


162=C2=A0=C2=A0=C2=A0 2.1.= =C2=A0 Using P2MP BFD in PIM DR/BDR Monitoring
.= ..
169=C2=A0=C2=A0=C2=A0 =C2=A0 If a PIM-SM rou= ter is configured to monitor the head by using p2mp
170=C2=A0=C2=A0=C2=A0 =C2=A0 BFD, referred to through this document as= 'tail', receives PIM-Hello
171=C2=A0=C2= =A0=C2=A0 =C2=A0 packet with BFD Discriminator PIM Hello option, the tail = MAY create a
172=C2=A0=C2=A0=C2=A0 =C2=A0 p2mp = BFD session of type MultipointTail, as defined in [RFC8562].

[minor] s/router is configured/rou= ter that is configured

[nit] s/receives PIM-Hello packet with BFD Discriminator/receives a PIM-= Hello packet with the BFD Discriminator


...
188=C2=A0=C2=A0=C2=A0 =C2=A0 If the head ceases to include the BFD Dis= criminator PIM Hello option
189=C2=A0=C2=A0=C2= =A0 =C2=A0 in its PIM-Hello message, tails MUST close the corresponding
190=C2=A0=C2=A0=C2=A0 =C2=A0 MultipointTail BFD s= ession.=C2=A0 Thus the tail stops using BFD to monitor
191=C2=A0=C2=A0=C2=A0 =C2=A0 the head and reverts to the procedures= defined in [RFC7761] and
192=C2=A0=C2=A0=C2=A0 = =C2=A0 [I-D.ietf-pim-dr-improvement].

[minor] "...MUST close the corresponding Multipoint= Tail BFD session"

It might be a good thing adding that the PIM state is not affected by th= is action.


194=C2=A0=C2=A0=C2=A0 2.2.=C2=A0 P2MP BFD in PIM DR Load= Balancing

196=C2=A0= =C2=A0=C2=A0 =C2=A0 [RFC8775] specifies the PIM Designated Router Load Bal= ancing (DRLB)
197=C2=A0=C2=A0=C2=A0 =C2=A0 func= tionality.=C2=A0 Any PIM router that advertises the DRLB-Cap Hello
198=C2=A0=C2=A0=C2=A0 =C2=A0 Option can become the head= of a p2mp BFD session, as specified in
199=C2= =A0=C2=A0=C2=A0 =C2=A0 Section 2.1.=C2=A0 The head router administratively= sets the
200=C2=A0=C2=A0=C2=A0 =C2=A0 bfd.Sess= ionState to Up in the MultipointHead session [RFC8562] only
201=C2=A0=C2=A0=C2=A0 =C2=A0 if it is a Group Designated Route= r (GDR) Candidate, as specified in
202=C2=A0=C2= =A0=C2=A0 =C2=A0 Sections 5.5 and 5.6 of [RFC8775].=C2=A0 If the router is= no longer the
203=C2=A0=C2=A0=C2=A0 =C2=A0 GDR= , then it MUST shut down following the procedures described in
204=C2=A0=C2=A0=C2=A0 =C2=A0 Section 5.9 [RFC8562].=C2=A0 F= or each GDR Candidate that includes BFD
205=C2= =A0=C2=A0=C2=A0 =C2=A0 Discriminator option in its PIM Hello, the PIM DR c= reates a
206=C2=A0=C2=A0=C2=A0 =C2=A0 Multipoin= tTail session [RFC8562].=C2=A0 PIM DR demultiplexes BFD sessions
<= div dir=3D"ltr" style=3D"font-family:"Helvetica Neue",Helvetica,A= rial,sans-serif">207=C2=A0=C2=A0=C2=A0 =C2=A0 based on the value of the My= Discriminator field and the source IP
208=C2=A0= =C2=A0=C2=A0 =C2=A0 address.=C2=A0 If PIM DR detects a failure of one of t= he sessions, it MUST
209=C2=A0=C2=A0=C2=A0 =C2= =A0 remove that router from the GDR Candidate list and immediately
210=C2=A0=C2=A0=C2=A0 =C2=A0 transmit a new DRLB-List o= ption.

[] Continuing= with my theme of generalizing this specification...
This section says everything that the last section already specified i= n a generic way.=C2=A0 IOW, it is not really needed.

There is one thing that this paragraph add= s: "If the router is no longer the GDR, then it MUST shut down followi= ng the procedures described in Section 5.9 [RFC8562]." =C2=A0 Yes, shu= tting down the BFD session is important, but so is not including the BFD Di= scriminator option in the Hello anymore.=C2=A0 As with everything else, thi= s part can also be generalized:

=C2=A0 =C2=A0If the head is no longer serving the function that= prompted it
=C2=A0 =C2=A0to be monitored, then = it MUST cease including the BFD Discriminator
= =C2=A0 =C2=A0PIM Hello option in its PIM-Hello message, and it MUST shut do= wn
=C2=A0 =C2=A0the BFD session following the pr= ocedures described in Section 5.9
=C2=A0 =C2=A0[= RFC8562].


=
212=C2=A0=C2=A0=C2=A0 2.3.=C2=A0 Multipoint BFD Encapsula= tion

214=C2=A0=C2=A0= =C2=A0 =C2=A0 The MultipointHead of a p2mp BFD session when transmitting B= FD
215=C2=A0=C2=A0=C2=A0 =C2=A0 Control packet:=

[nit] s/packet/pack= ets


217=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST set TTL or Hop = Limit value to 255 (Section 5 [RFC5881]);

=
[major] "MUST set...RFC5881" =C2=A0 This = action is already required in an RFC that this document depends on, please = don't specify the behavior again.=C2=A0 I understand that rfc5682 can b= e used in multi-hop scenarios, but rfc5881 is the source here. =C2=A0 =C2= =A0s/MUST/must


=
...
222=C2=A0=C2=A0=C2= =A0 3.=C2=A0 IANA Considerations
...
227=C2=A0=C2=A0=C2=A0 =C2=A0 +=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=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+
228=C2=A0=C2=A0=C2=A0 =C2= =A0 | Value Name =C2=A0| Length Number =C2=A0| Name Protocol =C2=A0 =C2=A0 = | Reference =C2=A0 =C2=A0 |
229=C2=A0=C2=A0=C2= =A0 =C2=A0 +=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
230=C2=A0=C2=A0=C2=A0 =C2=A0 | TBA =C2=A0 =C2=A0 =C2=A0 =C2=A0= | 4 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| BFD Discriminator | = This document |
231=C2=A0=C2=A0=C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| Option =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
232=C2=A0=C2=A0=C2=A0 =C2=A0 +-------------+----------------+---------= ----------+---------------+

[major] Please use the same field names as in the registry: Value= , Length, Name, Reference

[EoR -06]

____= ___________________________________________
pim = mailing list

_______________________________________________
pim mailing list
--


Gyan Mishra

Network Solutions Architect=C2=A0

Email gyan.s.mishra@verizon.com

M 301 502-1347


--00000000000083c29f05ca08671b-- From nobody Wed Aug 25 13:55:24 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD7A3A0C5C; Wed, 25 Aug 2021 13:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ly61j_3EFSCh; Wed, 25 Aug 2021 13:55:19 -0700 (PDT) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 191F93A0C61; Wed, 25 Aug 2021 13:55:19 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id u3so1105094ejz.1; Wed, 25 Aug 2021 13:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=SkPn3fuqdBEiPx1ibhiW7gP+ha9Gg48C/XOlRi3xyYo=; b=gAUZbpNSKggBeMRIBluJtwN5qEY2KHs59K7MyP3vTlmb1OmbnaNlxWqyyn1CFIZSLS CopldSx25+7BI06zjpRPz3G+LGuvS9AnY6ZctTWYP2mN/heNWFNEV1MdnFxRtKDfGqLo kh1Dz2NJpHR8beYfm8+wAimWkCitYHMj+aDtnJpMkEs94w67zr8TUIw1NTJ+x6+9ZWnt J8dT8G8uU9JA4dBfMjwjnW6Si+2C2HHNY9CccR4f08C3sJV1L0zgdBhQqruVs42slaqG JPe+uHOg64STNpYzo0dTjOTKKVKbs9bhajg6dlp9vJMkhucoK+kjhWV9MvyF2WalkEOs B+Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=SkPn3fuqdBEiPx1ibhiW7gP+ha9Gg48C/XOlRi3xyYo=; b=H2uYBJCPZ2EOePch1evA0o/+Yh/goTBv2BrxkG1tdSSMDfJQJPuEF0B6eQTJS8nKrL Y06b2GLVI8izZWj32pwZvAdrC+G89po8cNg401/FzAfDueu9za/+cRneKW3LvbT/lfKP An7WH1dxx2sUmaoNrnKfREnSNeORDU3zck9DHWErx4+SK/PEXzSUgaB2SPcB9+6ktVbs bdLkvz4HuyUvGLz+Xm6wBUAyz16F9gDDj+BjGsddA9cj6wcBlX/v+wGsv3jsGFkoEmT1 3a+Ds32GbIdkoHL2aQqOTgSUzrCJ+Ri4NiS/FAChnpk93Ld7dt2EJZEcps6N1/pdftFI P8eA== X-Gm-Message-State: AOAM530ZfNYSwS029j2qpm+dDXq1kFd+9fs6nJ+YLtd28rinzVqnsCvy PlceW/sdr5cDsZIJUD8ZrIUHnROReYIWCynoAT9Sv5Me X-Google-Smtp-Source: ABdhPJx2OaKxY0AdIZf9wTVuk71bbMkVnbnNoqq7A5uQppSmJCgAwvD8YF9wEG6NR1KaOk2JZ/pSVa9ABgtH1KxNPZw= X-Received: by 2002:a17:907:384:: with SMTP id ss4mr572179ejb.478.1629924915465; Wed, 25 Aug 2021 13:55:15 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 25 Aug 2021 13:55:15 -0700 From: Alvaro Retana In-Reply-To: References: <202107220742327030208@zte.com.cn> <1867869445.417157.1629489910471@mail.yahoo.com> MIME-Version: 1.0 Date: Wed, 25 Aug 2021 13:55:14 -0700 Message-ID: Subject: Re: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05 To: Gyan Mishra , Reshad Rahman Cc: "pim-chairs@ietf.org" , Rtg-bfd WG , Michael McBride Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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, 25 Aug 2021 20:55:23 -0000 On August 22, 2021 at 11:18:40 AM, Gyan Mishra wrote: Gyan: Hi! > I agree with Alvaro that this draft has many use cases for future work us= ing > RFC 8562 P2MP BFD to bootstrap the BFD season for sub second convergence = and > action tale takes after detecting the failure. I am actually advocating for less future work, not more. ;-) BFD certainly has many applications, as does rfc8562. =C2=A0However, related specifically to this document, I believe that a single RFC is enough to document the applications related to monitoring PIM routers. Note that the reaction to a BFD timeout (for all applications) is simply to follow rfc7761. Thanks! Alvaro. From nobody Fri Aug 27 19:57:01 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF473A28C1; Fri, 27 Aug 2021 19:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 a1KK9aJRqswA; Fri, 27 Aug 2021 19:56:33 -0700 (PDT) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4E63A28C0; Fri, 27 Aug 2021 19:56:33 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id lc21so17976334ejc.7; Fri, 27 Aug 2021 19:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=M7lSKG7jdaRpkMf7K1UlSJes0faO5SNQoqwpK3psdK0=; b=AkCsRwWdJz9BN50CqDl25snVlxDVFIx/Wo4ysAWeW/tcF3HIRxn0rtdW0LtuTNTUoL IcmXNBZ8qVk93src1toK7Wp5unB4wwTMaOJYGQItaAJaVzMomgi3BGh4uWa3B048UDla 9pf4sBAN/zjrJG1tXnZgT3Y3O9HOLdh6leLwSi0iGLllfyHutN4SNHWFd+Kq2EUrn0D1 y9c6NLo8gghMEX1OsVDH2903NOqdO/c/jYrraQ9m1rwMAuDPpDXvHhEVOrKfJCNa9Ji2 VPX2xCLtotf1bp6jNe3ctx57LuadeiheNF3+9c13YYchqqDQJ1nqee7+FXgkoJImFp2t fIQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=M7lSKG7jdaRpkMf7K1UlSJes0faO5SNQoqwpK3psdK0=; b=pj4tAsuq6ISH0ZV3znFPsTHlaUuCr2k413rnJzfQtzj61fod35PBJIu4PXL6gdl5xE IydyWqt4f9okTIt0MAOXqtHJJWicI/znFNrHeWeoFl/k8vkMXiIWCESzY3p6OeNWZqWN o6OLH4Sh18lpK87sLGi6CepCXMzC3JoVKGVw86BMRyTptRcqsYvUP4EhnT53aCGuZbMk W1yEpiPkZs9oeMGNR9a48T4sicErwKGRF8F9UMYPM3cfzHVLNKJPACqggeVO0b7B7Iuq 5dz4ELyIP//bN2IFVhhXYYmfgvIsD48RHdo5bn1A+5MayPLqN5uyV6IiuNpj0xa4GhI0 jT1w== X-Gm-Message-State: AOAM5335IkN176qTQ3gmosFk1NWxlShTZPG8p8fELh98yehMoQwAN9hP dT/XluB25S7ch54f/lxXpzD1isbaf3fBgapkUimGwdXs4Rc= X-Google-Smtp-Source: ABdhPJzXTdmbhZvzx8xvr5rMdGieVjdgBJA29y7qS6nKUv6Uv7uwGSacw3Xkmv5454j9rUU7eQ6KZWNl53N5Sh9dLs4= X-Received: by 2002:a17:906:2817:: with SMTP id r23mr12862627ejc.285.1630119390427; Fri, 27 Aug 2021 19:56:30 -0700 (PDT) MIME-Version: 1.0 From: Greg Mirsky Date: Fri, 27 Aug 2021 19:56:19 -0700 Message-ID: Subject: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm To: draft-ietf-opsawg-l3sm-l3nm@ietf.org, opsawg , rtg-bfd WG Content-Type: multipart/alternative; boundary="000000000000353e4b05ca95bf6b" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2021 02:56:39 -0000 --000000000000353e4b05ca95bf6b Content-Type: text/plain; charset="UTF-8" Dear Authors, thank you for your work on this document. I've read the draft and have a question, and a suggestion. Section 7.6.4 describes how BFD is controlled in vpn-common. I've noticed that you use references to RFC 5880. While that is the basis for all subsequent BFD documents, for BFD YANG data model draft-ietf-bfd-yang may be more useful. Perhaps the container oam can re-use grouping base-cfg-parms. What are your thoughts? Regards, Greg --000000000000353e4b05ca95bf6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Authors,
thank you for your work on this document= . I've read the draft and have a question, and a suggestion. Section 7.6.4=C2=A0describes how BFD is controlled in vpn-common= . I've noticed that you use references to RFC 5880. While that is the b= asis for all subsequent BFD documents, for BFD YANG data model draft-ietf-bfd-yang may be more useful. Perhaps the container oam can re-use grouping base-c= fg-parms.

--000000000000353e4b05ca95bf6b-- From nobody Mon Aug 30 05:19:37 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDEF3A0CBB; Mon, 30 Aug 2021 05:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com 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 uP5UBh4eTqMk; Mon, 30 Aug 2021 05:19:27 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866C03A0B12; Mon, 30 Aug 2021 05:19:26 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar20.francetelecom.fr (ESMTP service) with ESMTPS id 4GyqBN4j58z8smm; Mon, 30 Aug 2021 14:19:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1630325964; bh=FqgbxuK55KlXRZNhRKWjmkL/UvqgNc5AozmaLTVzHvY=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=EtkWan8P31F+ntdXXHwZVxAULR1G74UHg3ibXYZzJHA6bQDvGZJ36Y9qEsEyHVozz /gud2pLtGsLtusGminjGnMwEIGJeCgDrne9Hp3HkW6ocTUYS5O0cnxmi61e4UOLbom jhwR4BQwf5zoL3B7/QCgsTcRDJB5g4czWFeWkQJf14+cm9G5u/G8H/la2DMjZoMr7B xs42sFuDNEVDlnLyuxGi6UvGrmGz02aXuVUcgtRkwT/4hgoTtY/3P9rZh2Zc/MPn+4 32KQub/WOUMAbk0E3MGOzvybH4uElFJ0GvSAzUwhvh7SypOZj/EmNTclhqdlC7UCTp CCoeLOgu9xEXw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar03.francetelecom.fr (ESMTP service) with ESMTPS id 4GyqBN3SHnzCqkS; Mon, 30 Aug 2021 14:19:24 +0200 (CEST) From: To: Greg Mirsky , "draft-ietf-opsawg-l3sm-l3nm@ietf.org" , opsawg , rtg-bfd WG Subject: RE: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm Thread-Topic: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm Thread-Index: AQHXm7hUF01labWnJkKEocRBbmkog6uLuGLg Date: Mon, 30 Aug 2021 12:19:23 +0000 Message-ID: <5697_1630325964_612CCCCC_5697_162_1_787AE7BB302AE849A7480A190F8B9330353E5905@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330353E5905OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 12:19:35 -0000 --_000_787AE7BB302AE849A7480A190F8B9330353E5905OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KVGhhbmsgeW91IGZvciBjaGVja2luZyB0aGUgT0FNIHBhcnQgYW5kIGZvciBz aGFyaW5nIHRoaXMgY29tbWVudC4NCg0KQXMgeW91IGNhbiByZWFkIGluIGJvdGggc2VjdGlvbnMg NCBhbmQgNSwgdGhpcyBtb2RlbCBpcyAqKiBub3QgYSBkZXZpY2UgY29uZmlndXJhdGlvbiBtb2Rl bCAqKi4gVGhlIGZvY3VzIGlzIG9uIGFzcGVjdHMgdGhhdCBjYW4gYmUgdHJpZ2dlcmVkIGJ5IHNl cnZpY2UgcmVxdWVzdHMgYW5kIG1hbmFnZWQgYnkgdGhlIG5ldHdvcmsgY29udHJvbGxlci4gVGhp cyBuZXR3b3JrIHZpZXcgb2YgdGhlIHNlcnZpY2Ugd2lsbCBiZSB0aGVuIGVucmljaGVkICh3aXRo IG90aGVyIHNvdXJjZXMgc3VjaCBhcyBsb2NhbCB0ZW1wbGF0ZXMvcHJvZmlsZXMvZGVmYXVsdHMp IHRvIGRlcml2ZSB0aGUgZXhoYXVzdGl2ZSBjb25maWd1cmF0aW9uIHRoYXQgd2lsbCBiZSBlbmZv cmNlZCBpbiBpbnZvbHZlZCBkZXZpY2VzIHRvIGRlbGl2ZXIgdGhlIHJlcXVlc3RlZCBzZXJ2aWNl Lg0KDQpXaXRoIHRoYXQgcmF0aW9uYWxlIGluIG1pbmQsIHlvdSBjYW4gdW5kZXJzdGFuZCB3aHkg d2UgZG9u4oCZdCBpbXBvcnQgZGV2aWNlIG1vZGVscyBidXQgcG9pbnQgdG8gdGhlIGF1dGhvcml0 YXRpdmUgUkZDcyBmb3IgYXNwZWN0cyB0aGF0IHdlIHRoaW5rIG1ha2Ugc2Vuc2UgdG8gYmUgdHdl YWtlZCBhdCB0aGUgbmV0d29yay1sZXZlbC4NCg0KVGhhbmtzLg0KDQpDaGVlcnMsDQpNZWQNCg0K RGUgOiBHcmVnIE1pcnNreSBbbWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbV0NCkVudm95w6kg OiBzYW1lZGkgMjggYW/Du3QgMjAyMSAwNDo1Ng0Kw4AgOiBkcmFmdC1pZXRmLW9wc2F3Zy1sM3Nt LWwzbm1AaWV0Zi5vcmc7IG9wc2F3ZyA8b3BzYXdnQGlldGYub3JnPjsgcnRnLWJmZCBXRyA8cnRn LWJmZEBpZXRmLm9yZz4NCk9iamV0IDogQSBxdWVzdGlvbiBvbiBPQU0gc2VjdGlvbiBpbiBkcmFm dC1pZXRmLW9wc2F3Zy1sM3NtLWwzbm0NCg0KRGVhciBBdXRob3JzLA0KdGhhbmsgeW91IGZvciB5 b3VyIHdvcmsgb24gdGhpcyBkb2N1bWVudC4gSSd2ZSByZWFkIHRoZSBkcmFmdCBhbmQgaGF2ZSBh IHF1ZXN0aW9uLCBhbmQgYSBzdWdnZXN0aW9uLiBTZWN0aW9uIDcuNi40PGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1vcHNhd2ctbDNzbS1sM25tI3NlY3Rp b24tNy42LjQ+IGRlc2NyaWJlcyBob3cgQkZEIGlzIGNvbnRyb2xsZWQgaW4gdnBuLWNvbW1vbi4g SSd2ZSBub3RpY2VkIHRoYXQgeW91IHVzZSByZWZlcmVuY2VzIHRvIFJGQyA1ODgwLiBXaGlsZSB0 aGF0IGlzIHRoZSBiYXNpcyBmb3IgYWxsIHN1YnNlcXVlbnQgQkZEIGRvY3VtZW50cywgZm9yIEJG RCBZQU5HIGRhdGEgbW9kZWwgZHJhZnQtaWV0Zi1iZmQteWFuZzxodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWJmZC15YW5nLz4gbWF5IGJlIG1vcmUgdXNlZnVsLiBQ ZXJoYXBzIHRoZSBjb250YWluZXIgb2FtIGNhbiByZS11c2UgZ3JvdXBpbmcgYmFzZS1jZmctcGFy bXMuDQpXaGF0IGFyZSB5b3VyIHRob3VnaHRzPw0KDQpSZWdhcmRzLA0KR3JlZw0KCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K CkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs ZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs ZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3Ig cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9y IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4K VGhhbmsgeW91LgoK --_000_787AE7BB302AE849A7480A190F8B9330353E5905OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0 IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5IaSBHcmVnLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGFuayB5b3UgZm9yIGNoZWNraW5nIHRoZSBP QU0gcGFydCBhbmQgZm9yIHNoYXJpbmcgdGhpcyBjb21tZW50Lg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BcyB5b3UgY2FuIHJlYWQg aW4gYm90aCBzZWN0aW9ucyA0IGFuZCA1LCB0aGlzIG1vZGVsIGlzICoqIG5vdCBhIGRldmljZSBj b25maWd1cmF0aW9uIG1vZGVsICoqLiBUaGUgZm9jdXMgaXMgb24gYXNwZWN0cyB0aGF0IGNhbiBi ZSB0cmlnZ2VyZWQgYnkgc2VydmljZSByZXF1ZXN0cyBhbmQgbWFuYWdlZCBieSB0aGUNCiBuZXR3 b3JrIGNvbnRyb2xsZXIuIFRoaXMgbmV0d29yayB2aWV3IG9mIHRoZSBzZXJ2aWNlIHdpbGwgYmUg dGhlbiBlbnJpY2hlZCAod2l0aCBvdGhlciBzb3VyY2VzIHN1Y2ggYXMgbG9jYWwgdGVtcGxhdGVz L3Byb2ZpbGVzL2RlZmF1bHRzKSB0byBkZXJpdmUgdGhlIGV4aGF1c3RpdmUgY29uZmlndXJhdGlv biB0aGF0IHdpbGwgYmUgZW5mb3JjZWQgaW4gaW52b2x2ZWQgZGV2aWNlcyB0byBkZWxpdmVyIHRo ZSByZXF1ZXN0ZWQgc2VydmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPldpdGggdGhhdCByYXRpb25hbGUgaW4gbWluZCwgeW91IGNh biB1bmRlcnN0YW5kIHdoeSB3ZSBkb27igJl0IGltcG9ydCBkZXZpY2UgbW9kZWxzIGJ1dCBwb2lu dCB0byB0aGUgYXV0aG9yaXRhdGl2ZSBSRkNzIGZvciBhc3BlY3RzIHRoYXQgd2UgdGhpbmsgbWFr ZSBzZW5zZSB0byBiZSB0d2Vha2VkIGF0IHRoZSBuZXR3b3JrLWxldmVsLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhhbmtzLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5D aGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiBHcmVnIE1pcnNreSBbbWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbV0NCjxicj4NCjxiPkVu dm95w6kmbmJzcDs6PC9iPiBzYW1lZGkgMjggYW/Du3QgMjAyMSAwNDo1Njxicj4NCjxiPsOAJm5i c3A7OjwvYj4gZHJhZnQtaWV0Zi1vcHNhd2ctbDNzbS1sM25tQGlldGYub3JnOyBvcHNhd2cgJmx0 O29wc2F3Z0BpZXRmLm9yZyZndDs7IHJ0Zy1iZmQgV0cgJmx0O3J0Zy1iZmRAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBBIHF1ZXN0aW9uIG9uIE9BTSBzZWN0aW9uIGluIGRy YWZ0LWlldGYtb3BzYXdnLWwzc20tbDNubTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIEF1dGhvcnMsPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhbmsgeW91IGZvciB5b3VyIHdvcmsgb24gdGhpcyBk b2N1bWVudC4gSSd2ZSByZWFkIHRoZSBkcmFmdCBhbmQgaGF2ZSBhIHF1ZXN0aW9uLCBhbmQgYSBz dWdnZXN0aW9uLg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1pZXRmLW9wc2F3Zy1sM3NtLWwzbm0jc2VjdGlvbi03LjYuNCI+DQpTZWN0aW9uIDcu Ni40PC9hPiZuYnNwO2Rlc2NyaWJlcyBob3cgQkZEIGlzIGNvbnRyb2xsZWQgaW4gdnBuLWNvbW1v bi4gSSd2ZSBub3RpY2VkIHRoYXQgeW91IHVzZSByZWZlcmVuY2VzIHRvIFJGQyA1ODgwLiBXaGls ZSB0aGF0IGlzIHRoZSBiYXNpcyBmb3IgYWxsIHN1YnNlcXVlbnQgQkZEIGRvY3VtZW50cywgZm9y IEJGRCBZQU5HIGRhdGEgbW9kZWwNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtYmZkLXlhbmcvIj5kcmFmdC1pZXRmLWJmZC15YW5nPC9hPiBtYXkg YmUgbW9yZSB1c2VmdWwuIFBlcmhhcHMgdGhlIGNvbnRhaW5lciBvYW0gY2FuIHJlLXVzZSBncm91 cGluZyBiYXNlLWNmZy1wYXJtcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPldoYXQgYXJlIHlvdXIgdGhvdWdodHM/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HcmVnPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVz c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp b25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBh cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h bGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpv aW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs dGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxk IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u LgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4K QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5 b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B9330353E5905OPEXCAUBMA2corp_-- From nobody Mon Aug 30 06:48:27 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5855F3A1297; Mon, 30 Aug 2021 06:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 THcLycia0w5w; Mon, 30 Aug 2021 06:48:19 -0700 (PDT) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FA23A1292; Mon, 30 Aug 2021 06:48:19 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id me10so31262228ejb.11; Mon, 30 Aug 2021 06:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bS3LUeOcTuap27atC9d86Q2wlK9J/wnvdxhpW5uf9ik=; b=hV6UvLtjqVYamIW6Yh8IgScvkQlFWMOl9cjIPQ0/izRZSRyu5Mbt2dzeZMsvMVW98a /c5pX2hcB+dqDFj66w7I8JL87sDHjEChNuk2XmnqYkGvvXxw5xc+4Vh6x2enXJs8xEqO 8HgAWtfsnhEj8oxWMdra5i4yRefUmis2uK7QjbxnN1pS5nZrZEqDrgHMTKkOMKHKnkWX nuyaXgNyT4XOX6o7Ku/nIZZX0NjDwvgEaD3lbAidDdYSYVksu4SNlcZ7cR4Sms+cxLVH HVuInJL4I+S5jVvKvD23p6H31/1Imu3Z1X1reBLclbdjcGVmo+UJZvGRr4HcumsodW99 W6kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bS3LUeOcTuap27atC9d86Q2wlK9J/wnvdxhpW5uf9ik=; b=IOWoUCAl9hqOM21tp79cKvnIFTGiF4z4gQvVG/njrb+SZ8fi9FA5ghg71IE8l6m6Oe ugwDX5Q3fNEh5GgnPd+z8VfpL7NzUf3uWGIp0oIYDXZI0ZH8p1YMx8wvWjRouNxU0a0V 6fvH3Dk0hHzDySK8MJKZf95nfNhaeNct9dOnRw3SozP7vn56zHV1mEWhj23xrQ3H30bZ 8KX9Qa1yNNtvz+iaVFyQUfsdkrja41+/7yLpqCQaqCZBldyDM+vwjxiLyXBA4BB4rU16 ZvEQjadNm5zJxXVCC1ZqQyfH4Nxs+PHQ9DeHfCKL4c+m2aM+90FJ2bOXFdWXVuVu5SJR v2mA== X-Gm-Message-State: AOAM533yIjH8aNLwJB2KLPCOi/79906puB4M9Hle9Kf0wNX+lgHm9CWm w5+LHX/bASYhxHps4JeqDW5QwzmwfVUxb4EmCWes/lVYfKc= X-Google-Smtp-Source: ABdhPJz+LVfcxTQiVMcAAgCxjWpJIRLpqzv3jQlHh1t/TVtym2IYcJGXyhvgJX0rhkHLLlSQzb4Pj1dLbmJtb1C6bU8= X-Received: by 2002:a17:907:2174:: with SMTP id rl20mr12689262ejb.199.1630331296408; Mon, 30 Aug 2021 06:48:16 -0700 (PDT) MIME-Version: 1.0 References: <5697_1630325964_612CCCCC_5697_162_1_787AE7BB302AE849A7480A190F8B9330353E5905@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <5697_1630325964_612CCCCC_5697_162_1_787AE7BB302AE849A7480A190F8B9330353E5905@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Greg Mirsky Date: Mon, 30 Aug 2021 06:48:05 -0700 Message-ID: Subject: Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm To: Med Boucadair Cc: "draft-ietf-opsawg-l3sm-l3nm@ietf.org" , opsawg , rtg-bfd WG Content-Type: multipart/alternative; boundary="000000000000c9ec9105cac715ea" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 13:48:26 -0000 --000000000000c9ec9105cac715ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Med, thank you for your detailed feedback; much appreciated. I think that I now understand better the philosophy of the model. But I will note that RFC 5880 does not cover RFC 7880 and 8562 (both have updated RFC 5880). It seems that adding bfd-session-type could be a very useful enhancement to the OAM container. Values for the new parameter should reflect values defined for bfd.SessionType in RFCs 7880, 8562, and 8563: - SBFDInitiator; - SBFDReflector; - PointToPoint; - MultipointHead; - MultipointTail; - MultipointClient And my apologies for my late comments. Regards, Greg On Mon, Aug 30, 2021 at 5:19 AM wrote: > Hi Greg, > > > > Thank you for checking the OAM part and for sharing this comment. > > > > As you can read in both sections 4 and 5, this model is ** not a device > configuration model **. The focus is on aspects that can be triggered by > service requests and managed by the network controller. This network view > of the service will be then enriched (with other sources such as local > templates/profiles/defaults) to derive the exhaustive configuration that > will be enforced in involved devices to deliver the requested service. > > > > With that rationale in mind, you can understand why we don=E2=80=99t impo= rt device > models but point to the authoritative RFCs for aspects that we think make > sense to be tweaked at the network-level. > > > > Thanks. > > > > Cheers, > > Med > > > > *De :* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Envoy=C3=A9 :* samedi 28 ao=C3=BBt 2021 04:56 > *=C3=80 :* draft-ietf-opsawg-l3sm-l3nm@ietf.org; opsawg = ; > rtg-bfd WG > *Objet :* A question on OAM section in draft-ietf-opsawg-l3sm-l3nm > > > > Dear Authors, > > thank you for your work on this document. I've read the draft and have a > question, and a suggestion. Section 7.6.4 > describes > how BFD is controlled in vpn-common. I've noticed that you use references > to RFC 5880. While that is the basis for all subsequent BFD documents, fo= r > BFD YANG data model draft-ietf-bfd-yang > may be more > useful. Perhaps the container oam can re-use grouping base-cfg-parms. > > What are your thoughts? > > > > Regards, > > Greg > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --000000000000c9ec9105cac715ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Med,
thank you for your detailed=C2=A0feedback; muc= h appreciated. I think that I now understand better the philosophy of the m= odel. But I will note that RFC 5880 does not cover RFC 7880 and 8562 (both = have updated RFC 5880). It seems that adding bfd-session-type could be a ve= ry useful enhancement to the OAM container. Values for the new parameter sh= ould reflect values defined for bfd.SessionType in RFCs 7880, 8562, and 856= 3:
  • SBFDInitiator;
  • SBFDReflector;
  • Poin= tToPoint;
  • MultipointHead;
  • MultipointTail;
    • <= li>MultipointClient
And my apologies for my late comments.

Regards,
Greg

On Mon, Aug 30, 2021 at = 5:19 AM <mohamed.boucada= ir@orange.com> wrote:

Hi Greg,

=C2=A0

Thank you for checking the OAM part and for sharing this com= ment.

=C2=A0

As you can read in both sections 4 and 5, this model is ** n= ot a device configuration model **. The focus is on aspects that can be tri= ggered by service requests and managed by the network controller. This network view of the service will be then enriched= (with other sources such as local templates/profiles/defaults) to derive t= he exhaustive configuration that will be enforced in involved devices to de= liver the requested service.

=C2=A0

With that rationale in mind, you can understand why we don= =E2=80=99t import device models but point to the authoritative RFCs for asp= ects that we think make sense to be tweaked at the network-level.=

=C2=A0

Thanks.

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Greg Mirsky [mailto:gregimirsky@gmail.com]
Envoy=C3=A9=C2=A0: samedi 28 ao=C3=BBt 2021 04:56
=C3=80=C2=A0: draft-ietf-opsawg-l3sm-l3nm@ietf.org; opsawg <opsawg@ietf.org>;= rtg-bfd WG <rtg-b= fd@ietf.org>
Objet=C2=A0: A question on OAM section in draft-ietf-opsawg-l3sm-l3n= m

=C2=A0

Dear Authors,

thank you for your work on this document. I've r= ead the draft and have a question, and a suggestion. Section 7.6.4=C2=A0describes how BFD is controlled in vpn-common. I'= ;ve noticed that you use references to RFC 5880. While that is the basis fo= r all subsequent BFD documents, for BFD YANG data model draft-ietf-bfd-yang may be more useful. Perhaps the container = oam can re-use grouping base-cfg-parms.

What are your thoughts?

=C2=A0

Regards,

Greg

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--000000000000c9ec9105cac715ea-- From nobody Mon Aug 30 07:36:47 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5C73A148D for ; Mon, 30 Aug 2021 07:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 tkyoG-4WrPz7 for ; Mon, 30 Aug 2021 07:36:40 -0700 (PDT) Received: from sonic311-13.consmr.mail.bf2.yahoo.com (sonic311-13.consmr.mail.bf2.yahoo.com [74.6.131.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A5D3A1486 for ; Mon, 30 Aug 2021 07:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1630334198; bh=OeG02G7WkYFliBRJphdnq+Qcu1k2ufqC30blhn+K3LA=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=KmvnEFW56DJmjDCTGU0XkI/IGfx3o5kxeXtpoNFGsTyGIMMd2pRguRUjC4dcijOH5Qg3VLF2zhJZmYxB0loMoR77unVOEUtlcmn7VHyQiqZBvmfwQ4u3KCiroeM1L3yjzx6oon6sXrMVIVa93iMWsnVHuQHLafCIKOVPRUdqNB48/zatOuNI/mKXMmZcd2rG+0TTL2oyoDl8EAT4ZlpN4UDhUK3olzcSIEvefwlW3bfLn9niy+ZSroJDtnhQ9crnE1/O+jGP96n2o8KzkQa5grREjduNg0SkjFOkQ4TSB8z3GgNwIUj14SZRJbBeRAqb/mpCLm+SK9cExhoQ7AxqXQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1630334198; bh=lUYVtvbTCjWCu6qUZvfU0NdbGELICJ+vxmPFwHTCatD=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=E8r7/k2vN/o5NwS2EfI6EDQ5W7RLpuciv1n86TZJbfH2eU7ORhXfYiuckVXq6a7Kd+hHXDAuYJ8GI0LQiynBVHeomnSVEK8X4WhWFFGalQWkFNnSWvGEn23WRAN6Ffefa7bqNvTkqxmRGc/QxhVpR7K1c6RZs8mbVd/Pf7pucdnv4KXieQ+5yONky6wQtkJbR276T+hiomW817YOjj06JeQQPFOPKGNkL/vbCRb56+VWJtbgs9aX0i8ru5WYX9eTYEkT4P0s0IAS2Rk4i7b6DPE+ai4ksSKOpuwceuLP2EeEYfInBF/xfNqT0bkda+s41JU7lhENKoTVYVCBuB976Q== X-YMail-OSG: tQmIDZUVM1kJQo2oUbIxBrNUwmbNApbP6gZaMb7TwBVPIl3rN_XgC_PxxleVsQr Yu0uwnsQIT63A_OSuzfkc_JORORD.kbOJXig8L6zcQzXnT0vunlTjmoJS_jjO3U15jilkR84K5.s 4.7i1_X4.6YDgrBwjZewjxsr.EXo5YjRVsXkrTuUqtZffjIZLWRn_mlbh.Zlrc7d_z7A1FaQccVA gFuH6m2d_oXkSDzAuhwfLrF4FqYQaA5RzACVsHGjQGbdrz.cmTOzre41ax2_Xrg9uUY9TLbJ0Av8 _97DET4F..kSkemkrhdNmIOVBbJlUNQu4la1rYdoRxy9.kFyHspWeV11TA6cqA6Ju5lJMoGSRzwY iziOpckjpAW7319yxOAfMvvVzZl.sRV1vlcv7z2bWT8RbZu2V272XCch.x7iPOZbCqhvlJbft2yX kVbKfQKvVzeuey0cIhOw8pLcWEoklQRy7gBfz3j7fWpPR8ujwcJ46rRA0pmp87srM8DVrHsbdlvI ZIN6.mANdHiM2E0qb.O8lU0Ft7D87mKhHjBIjEeOpBMuklrln4G5prj5xV8j3ZefRslUoo.1wyZu 2EAuyPdjJPfcTqintSETgfzuXuAezT2SrWYKrJVJk0k9oXUTQSVzhkhjQgxNtbpR7Qj6U4Sq3o8y gcJT7i9WHbGsOj4MUC78ROrEBAJKAwSC_QrfOK.Dy9SliuBXZ1gwedRfpbhVtwTiVZZfDIqepm4w YMfA3Z98oMKn6XMqhnL0JTa.zmO_XI1pL0RlmIoeVDe.ahMQTVP7df0nzqPxGVKXBVQ5WE4UTBYL nb3OXi.pwvexgzygTVs7Huw_gVxv5iZJlMnq.8JYQGddbUfnlqtSNd_C5P6..7geCo1BS2Tm38pO VrT1uD8_ghHkyIMrUgByHNJBNtzlnunjP4x8PT4Kcp7Cmo9SQl5azzKe2oUYkDCpvg43ELotZHNM YlrFZ07r7.0C_hK4gOZQfNbNfrBhGgY_Xex3f0z5_5hB4ObV1iVWAEkjO8nH7j1qzELRvwGMWqOo MOz9BNdETVdEuRShcu2wNI6CK9K7ZYj5eDSiU4hYzWZXmFzeIiapP0G2AtaPq3wgTHJV0lGYCqu3 cL_9oqxbHou413sktthn8mFwj.6ixJM47Gtrf7CtCwD1uOHtNPHCdo5H2CWngZslT4ipJ1KWBfhS eGTQVge2mrKlUJspYefuLYzY1Tmw4EOpnXLRD_C6_jWQZoJ.v81L8Sr9XSn7zZrErSyqnCs5QL3r .T4TlB9J9KlB.7t6GPaTWqFhZYEkUV5a6Yul6MREQVKd7PV8kFGrzUS0B7xnyuaP7nDPp.OcMg5X txUAYbeYhvDhXH9GzdKQ.x1UOPqfAvzNzfb7DEGg373JAXNxPm6X_iQ_1CBTJisFWL8mFezM1uue FWTacUwbwCibUgc5OUg.0nWx_5_NL0hXOHeIZDO7IL0BX3VgTyXr1Rg_6PEAjFNP0JsmItcRUXNX Kh0z7ub_ilmwYxO0.Bgv6mnHa2mDtYGMte5JlsUclnXPXkPyVCi2c5unDQfhNnjrgP12WJtjgHD8 V9R7aY6vKAJKMjziMogLa9D2__oWOG21jlzeDmb_jC2203XtgHMoQ56XJMLQSZgRej3RSPP5eiHm p6CGQyJiCHoGBBRO.ZBmHY5cEvYUk7..1S8xYwXifJhf8Mzvl8KisdYPUbmtxdvvxYakPMh11.nE yk9uKCcXVerQVit6HwnHaiNa2xa8MPw3SFtdzxM5BGcxDyCTJ6mCgrK9.ZG1omVrYk5U7FGpkAzS KFbsPfVFUJ92HWIJCDejNOP5DbKfwIfjlZfYsMVrAKpFDbo0GrsNPR3YbnzPlKcs_XBvigrt_U4u 8LUOMclaQBZ0Xcr58k_znfhfRMfjV2iwQcyWRfMMtPt7bzmiekuhEOdMcnH2oyHBHJFWkDO55wzJ fKJe_UJJTiG486rqbUCZb17fpQQ37ReRCFH4iREm40xN9SGaBBviApLlUo6ZLBD.Zp5yL7hm4x2G _TuhqqZ1c3ISLcP7pDvKW3FTW5QqSQjWrPbPz2BsCPDXYihcVyqRGbGtq8880GNiwoPO.jaabP1o 5SnQ4iH50TYafR7gCFyPug3nyjjXgs1V5WqQ1tFZi3ktyxluaANTY_oP8nzDM.Dxu_t0sW97LBSh m8DiJED.GK20Gb3tyfMlOl91y7nezfrgfK5lihkmSZPNxcAhkaDMsdL9bIUmaJ7hisAQGdv_itBz a4YxxCd47_TnsqE9z0VBkBzliFrnubotavHj9mcGBEIyk_kR01itrqvwoNnTkNtJ4zS4lKtr0B6v 0LQ1_GISvlhu7Xv.CuEW2PxkaJP8GNNCFgTJ1E0M4dNu390T_4qr7rW.l X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Mon, 30 Aug 2021 14:36:38 +0000 Date: Mon, 30 Aug 2021 14:36:37 +0000 (UTC) From: Reshad Rahman Reply-To: Reshad Rahman To: Rtg-bfd WG Message-ID: <929415576.390897.1630334197093@mail.yahoo.com> In-Reply-To: <00a001d79da8$bf30ec40$3d92c4c0$@yahoo.com> References: <163033223438.8507.13442799687479808565@ietfa.amsl.com> <00a001d79da8$bf30ec40$3d92c4c0$@yahoo.com> Subject: Fw: NomCom 2021-2022 Call for Nominations MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_390896_1354394601.1630334197090" X-Mailer: WebService/1.1.18924 YMailNorrin Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Aug 2021 14:36:46 -0000 ------=_Part_390896_1354394601.1630334197090 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI ----- Forwarded Message ----- From: "g_e_montenegro=3D40yahoo.com@dmarc.= ietf.org" To: "wgchairs@ietf.o= rg" Sent: Monday, August 30, 2021, 10:10:41 AM EDTSubjec= t: FW: NomCom 2021-2022 Call for Nominations Chairs, Please publicize this call for Nominations within your WGs. It is the best = way to reach IETF-ers as there are many who don't subscribe to the IETF mai= ling list, where these announcements typically go.=20 Your help is much appreciated in ensuring the IETF has healthy supply of no= minees for leadership positions. Thanks, Gabriel Montenegro NomCom Chair 2021-2022 nomcom-chair-2021 at ietf dot org -----Original Message----- From: ietf On Behalf Of NomCom Chair 2021 Sent: Monday, August 30, 2021 10:04 To: IETF Announcement List Cc: ietf@ietf.org Subject: NomCom 2021-2022 Call for Nominations Finally! The moment we've all been waiting for: =C2=A0 C A L L=C2=A0 =C2=A0 =C2=A0 F O R=C2=A0 =C2=A0 =C2=A0 N O M I N A T = I O N S=C2=A0 ! ! ! The 2021-22 IETF Nominating Committee (NomCom) is seeking nominations from = now until Monday, October 11, 2021.=20 The open positions and more information are found at the NomCom web site: https://datatracker.ietf.org/nomcom/2021/=20 They are also included below for convenience. Nominations may be made by selecting the Nominate link at the top of the No= mCom 2021 home page, or by visiting the following URL:=20 https://datatracker.ietf.org/nomcom/2021/nominate/ Self-nomination is welcome!=20 Note:=C2=A0 Nominations made using the web tool require an ietf.org datatra= cker account. You can create a datatracker ietf.org account if you don't ha= ve one already by visiting the following URL:=20 https://datatracker.ietf.org/accounts/create/ If you are unable to use the web form, nominations may instead be made by e= mail to nomcom-2021 at ietf dot org. If using email, please include the wor= d "Nominate"=20 in the Subject and indicate in the email who is being nominated, their emai= l address (to confirm acceptance of the nomination), and the position for w= hich you are making the nomination. If you are nominating someone other tha= n yourself, please tell us if we may tell the nominee that you were the one= who made the nomination. If you wish to nominate someone via email for mor= e than one position, please use separate emails to do so. Willing nominees will be asked to fill out a questionnaire specific to the = position for which they are nominated. The finalized questionnaires will be= available no later than Monday, September 6, 2021 (preliminary versions ar= e already posted) and have a submission deadline of Monday, October 18, 202= 1.=20 NomCom 2021-22 will follow the policy for "Open Disclosure of Willing Nomin= ees" described in BCP 10/RFC 8713: "The list of nominees willing to be cons= idered for positions under review in the current NomCom cycle is not confid= ential". Willing nominees for each position will be listed in a publicly ac= cessible way, e.g., anyone with a datatracker account may access the lists.= Additionally, the nomination form asks if we may share your own name with = the nominee. In all other ways, the confidentiality requirements of BCP 10 remain in effect. All feedback and all NomCom deliberations will remain = confidential and will not be disclosed. There is a field on the form you can mark in order to allow the NomCom to t= ell the nominee that you were the one who made the nomination. This default= s to =E2=80=9Cno=E2=80=9D - so if you don't mark the field we won=E2=80=99t= tell. In order to ensure time to collect sufficient community feedback about each= of the willing nominees, nominations must be received by the NomCom on or = before Monday, October 11, 2021. Please submit your nominations as early as possible for the sake of your no= minees. Note that nominations should not wait for nominee management permis= sion, as it is easier to decline the nomination than put one in late. The NomCom appoints individuals to fill open slots on the IAB, IESG, the IE= TF Trust and the LLC Board: =C2=A0=C2=A0=C2=A0 ART AD: 1 position =C2=A0=C2=A0=C2=A0 INT AD: 1 position =C2=A0=C2=A0=C2=A0 OPS AD: 1 position =C2=A0=C2=A0=C2=A0 RTG AD: 1 position =C2=A0=C2=A0=C2=A0 SEC AD: 1 position =C2=A0=C2=A0=C2=A0 TSV AD: 1 position =C2=A0=C2=A0=C2=A0 IETF Trust: 1 position =C2=A0=C2=A0=C2=A0 IETF LLC: 1 position =C2=A0=C2=A0=C2=A0 IAB: 6 positions The list of people and posts whose terms end with the March 2022 IETF meeti= ng, and thus the positions for which this NomCom is responsible, is: [An asterisk (*) next to a person's name indicates they do not intend to ac= cept renomination.] =C2=A0=C2=A0=C2=A0 LLC Board (3-year term) =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Jason Livingood =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0 IETF Trust (3-year term) =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Kathleen Moriarty =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0 IAB (2-year term) =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Ben Campbell * =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Cullen Jennings =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Mirja K=C3=BChlewind =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Jared Mauch =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Tommy Pauly =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Jiankang Yao =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0 IESG (2-year term) =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Murray Kucherawy, ART AD =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Erik Kline, INT AD =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Robert Wilton, OPS AD =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Martin Vigoureux, RTG AD =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Benjamin Kaduk, SEC AD * =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Martin Duke, TSV AD Please be resourceful in identifying possible candidates for these position= s, as developing our talent is a very crucial requirement for the IETF, and= also, please consider accepting a nomination. You'll find extensive inform= ation about specific positions, in individual tabs at:=20 https://datatracker.ietf.org/nomcom/2021/requirements/=20 In addition to nominations, the NomCom seeks community input on the positio= ns themselves. We need and welcome the community's views and input on the j= obs within each organization. If you have ideas on the positions=E2=80=99 r= esponsibilities (more, less, different), please let us know. Please send suggestions and feedback about this to nomcom-2021 at ietf dot = org.=20 Thank you for your help in identifying qualified nominees!=20 Thanks, Gabriel Montenegro IETF NomCom Chair 2021-22 nomcom-chair-2021 at ietf dot org =20 ------=_Part_390896_1354394601.1630334197090 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI

=20
----- Forwarded Message -----
From: "g_e_montenegro=3D40yahoo.com@dmarc.ietf.= org" <g_e_montenegro=3D40yahoo.com@dmarc.ietf.org>
To: "wgchairs@ietf.org" <wgchairs@ietf.org>
Sent: Mon= day, August 30, 2021, 10:10:41 AM EDT
Subject: FW: NomCom = 2021-2022 Call for Nominations

Chairs,
Please publicize this call for Nominations within y= our WGs. It is the best way to reach IETF-ers as there are many who don't s= ubscribe to the IETF mailing list, where these announcements typically go. =

Your help is much app= reciated in ensuring the IETF has healthy supply of nominees for leadership= positions.

Thanks,

Gabriel Montenegro
NomCom Chair 2021-2022
nomco= m-chair-2021 at ietf dot org

-----Original Message-----
From: ietf &l= t;ietf-bounces@ietf.org> On Behalf Of NomCom Chair 2021
Sent: Monday, August 30, 2021 10:04
To: IETF Announcement List <ietf-announce@ietf.org>
=
Subject: NomCom 2= 021-2022 Call for Nominations

Finally! The moment we've all been waiting for:

  C A L L      F = O R      N O M I N A T I O N S  ! ! !

The 2021-22 IETF Nominating Committee = (NomCom) is seeking nominations from now until Monday, October 11, 2021.

The open positions and = more information are found at the NomCom web site:


They a= re also included below for convenience.

Nominations may be made by selecting the Nominate link at= the top of the NomCom 2021 home page, or by visiting the following URL:


Self-nomination is welcome!

Note:  Nominations made using = the web tool require an ietf.org datatracker account. You can create a data= tracker ietf.org account if you don't have one already by visiting the foll= owing URL:


If you are unable to use the web form, = nominations may instead be made by email to nomcom-2021 at ietf dot org. If= using email, please include the word "Nominate"
in the Subject and indicate in the email who is being nominated, their ema= il address (to confirm acceptance of the nomination), and the position for = which you are making the nomination. If you are nominating someone other th= an yourself, please tell us if we may tell the nominee that you were the on= e who made the nomination. If you wish to nominate someone via email for mo= re than one position, please use separate emails to do so.

Willing nominees will be asked to fill= out a questionnaire specific to the position for which they are nominated.= The finalized questionnaires will be available no later than Monday, Septe= mber 6, 2021 (preliminary versions are already posted) and have a submissio= n deadline of Monday, October 18, 2021.

NomCom 2021-22 will follow the policy for "Open Disclosu= re of Willing Nominees" described in BCP 10/RFC 8713: "The list of nominees= willing to be considered for positions under review in the current NomCom = cycle is not confidential". Willing nominees for each position will be list= ed in a publicly accessible way, e.g., anyone with a datatracker account ma= y access the lists. Additionally, the nomination form asks if we may share = your own name with the nominee. In all other ways, the confidentiality requ= irements of BCP
10 remain in effect. All feedback= and all NomCom deliberations will remain confidential and will not be disc= losed.

There is a fiel= d on the form you can mark in order to allow the NomCom to tell the nominee= that you were the one who made the nomination. This defaults to =E2=80=9Cn= o=E2=80=9D - so if you don't mark the field we won=E2=80=99t tell.

In order to ensure time to col= lect sufficient community feedback about each of the willing nominees, nomi= nations must be received by the NomCom on or before Monday, October 11, 202= 1.

Please submit your = nominations as early as possible for the sake of your nominees. Note that n= ominations should not wait for nominee management permission, as it is easi= er to decline the nomination than put one in late.

The NomCom appoints individuals to fill open s= lots on the IAB, IESG, the IETF Trust and the LLC Board:

    ART AD: 1 position
    INT AD: 1 position
    OPS AD: 1 position
    RTG AD: 1 position
 &n= bsp;  SEC AD: 1 position
    = TSV AD: 1 position
    IETF Trust:= 1 position
    IETF LLC: 1 positi= on
    IAB: 6 positions
<= div dir=3D"ltr">
The list of people and posts who= se terms end with the March 2022 IETF meeting, and thus the positions for w= hich this NomCom is responsible, is:

[An asterisk (*) next to a person's name indicates they do n= ot intend to accept renomination.]

    LLC Board (3-year term)
        Jason Livingood
       
    IETF Trust (3-year term)
&= nbsp;       Kathleen Moriarty
       
&nbs= p;   IAB (2-year term)
  &nbs= p;     Ben Campbell *
  =       Cullen Jennings
 &= nbsp;      Mirja K=C3=BChlewind
        Jared Mauch
        Tommy Pauly
        Jiankang Yao
       
&= nbsp;   IESG (2-year term)
  =       Murray Kucherawy, ART AD
        Erik Kline, INT AD
        Robert Wilton, OPS AD
        Martin Vigoureux= , RTG AD
        Be= njamin Kaduk, SEC AD *
     &= nbsp;  Martin Duke, TSV AD

Please be resourceful in identifying possible candidates for thes= e positions, as developing our talent is a very crucial requirement for the= IETF, and also, please consider accepting a nomination. You'll find extens= ive information about specific positions, in individual tabs at:
=


In addition to nominations, the NomCom = seeks community input on the positions themselves. We need and welcome the = community's views and input on the jobs within each organization. If you ha= ve ideas on the positions=E2=80=99 responsibilities (more, less, different)= , please let us know.

= Please send suggestions and feedback about this to nomcom-2021 at ietf dot = org.

Thank you for yo= ur help in identifying qualified nominees!

<= /div>
Thanks,

Gabriel Montenegro
IETF NomCom Chair 202= 1-22
nomcom-chair-2021 at ietf dot org
<= div dir=3D"ltr">

------=_Part_390896_1354394601.1630334197090-- From nobody Mon Aug 30 23:55:06 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEB03A3593; Mon, 30 Aug 2021 23:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com 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 4J2oeA0RGUMI; Mon, 30 Aug 2021 23:54:54 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8AC53A3592; Mon, 30 Aug 2021 23:54:53 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar20.francetelecom.fr (ESMTP service) with ESMTPS id 4GzHxR4cqtz8t5h; Tue, 31 Aug 2021 08:54:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1630392891; bh=j1wydsSecXTooOuWjAu/nXUghFM2kUbSH31YwIPU/8U=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=OTkBRER5pYlxJ6VjXbWyu5OP2vaz7KCxd24ZGBlqT9o7soifbWmHZh7SAQt3Jx43C i1D86TORdEP5ZRh+4ZQfPpShO0qUx8u9tkTrYriH2uzKSlSSamkqd0VcjNNXdEEjO3 xfgpyM2Isu0nIs7RJkqGnh6wkQbd/Gg1f0gRn1PjFnLPWxA5ALObPqi9h9UYAzuaC0 03BQAnHz3LEqc1DLIpmL648IoVAQ1x4KOVMv1DrorGyL7yoBy8a8EiM4EnMd71DywS DlRazKCrX2z2PYO6OZu6M3TzeWPCmX3WY7v4+jr9YwzmwX95KNv4Tn9ES/x8WVcMzD kBFR6qyGz1znw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar04.francetelecom.fr (ESMTP service) with ESMTPS id 4GzHxR3GLzz1xpT; Tue, 31 Aug 2021 08:54:51 +0200 (CEST) From: To: Greg Mirsky CC: "draft-ietf-opsawg-l3sm-l3nm@ietf.org" , opsawg , rtg-bfd WG Subject: RE: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm Thread-Topic: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm Thread-Index: AQHXnaWoF+AImF6j4kyRdEknpTfMS6uNHnaQ Date: Tue, 31 Aug 2021 06:54:50 +0000 Message-ID: <12136_1630392891_612DD23B_12136_269_2_787AE7BB302AE849A7480A190F8B9330353E617C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <5697_1630325964_612CCCCC_5697_162_1_787AE7BB302AE849A7480A190F8B9330353E5905@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330353E617COPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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, 31 Aug 2021 06:55:00 -0000 --_000_787AE7BB302AE849A7480A190F8B9330353E617COPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IEdy ZWcgTWlyc2t5IFttYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tXQ0KRW52b3nDqSA6IGx1bmRp IDMwIGFvw7t0IDIwMjEgMTU6NDgNCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU5OT1YvTkVUIDxt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KQ2MgOiBkcmFmdC1pZXRmLW9wc2F3Zy1sM3Nt LWwzbm1AaWV0Zi5vcmc7IG9wc2F3ZyA8b3BzYXdnQGlldGYub3JnPjsgcnRnLWJmZCBXRyA8cnRn LWJmZEBpZXRmLm9yZz4NCk9iamV0IDogUmU6IEEgcXVlc3Rpb24gb24gT0FNIHNlY3Rpb24gaW4g ZHJhZnQtaWV0Zi1vcHNhd2ctbDNzbS1sM25tDQoNCkhpIE1lZCwNCnRoYW5rIHlvdSBmb3IgeW91 ciBkZXRhaWxlZCBmZWVkYmFjazsgbXVjaCBhcHByZWNpYXRlZC4gSSB0aGluayB0aGF0IEkgbm93 IHVuZGVyc3RhbmQgYmV0dGVyIHRoZSBwaGlsb3NvcGh5IG9mIHRoZSBtb2RlbC4NCg0KW01lZF0g R3JlYXQsIHRoYW5rcy4NCg0KQnV0IEkgd2lsbCBub3RlIHRoYXQgUkZDIDU4ODAgZG9lcyBub3Qg Y292ZXIgUkZDIDc4ODAgYW5kIDg1NjIgKGJvdGggaGF2ZSB1cGRhdGVkIFJGQyA1ODgwKS4gSXQg c2VlbXMgdGhhdCBhZGRpbmcgYmZkLXNlc3Npb24tdHlwZSBjb3VsZCBiZSBhIHZlcnkgdXNlZnVs IGVuaGFuY2VtZW50IHRvIHRoZSBPQU0gY29udGFpbmVyLiBWYWx1ZXMgZm9yIHRoZSBuZXcgcGFy YW1ldGVyIHNob3VsZCByZWZsZWN0IHZhbHVlcyBkZWZpbmVkIGZvciBiZmQuU2Vzc2lvblR5cGUg aW4gUkZDcyA3ODgwLCA4NTYyLCBhbmQgODU2MzoNCg0KICAqICAgU0JGREluaXRpYXRvcjsNCiAg KiAgIFNCRkRSZWZsZWN0b3I7DQogICogICBQb2ludFRvUG9pbnQ7DQogICogICBNdWx0aXBvaW50 SGVhZDsNCiAgKiAgIE11bHRpcG9pbnRUYWlsOw0KICAqICAgTXVsdGlwb2ludENsaWVudA0KW01l ZF0gSeKAmW0gYWZyYWlkIHRoYXQgbW9zdCBvZiB0aGVzZSBhcHBseSBiZXR3ZWVuIFBFcywgbm90 IHRvIHRoZSBDRS1QRSBzZWdtZW50LiBObz8gVGhlcmUgbWlnaHQgYmUgYSB2YWx1ZSBpbiBjb250 cm9sbGluZyB3aGV0aGVyIGJhc2Ugb3IgUy1CRkQgaXMgdXNlZCwgdGhvdWdoLg0KQW5kIG15IGFw b2xvZ2llcyBmb3IgbXkgbGF0ZSBjb21tZW50cy4NCg0KUmVnYXJkcywNCkdyZWcNCg0KT24gTW9u LCBBdWcgMzAsIDIwMjEgYXQgNToxOSBBTSA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+IHdyb3RlOg0KSGkgR3JlZywNCg0K VGhhbmsgeW91IGZvciBjaGVja2luZyB0aGUgT0FNIHBhcnQgYW5kIGZvciBzaGFyaW5nIHRoaXMg Y29tbWVudC4NCg0KQXMgeW91IGNhbiByZWFkIGluIGJvdGggc2VjdGlvbnMgNCBhbmQgNSwgdGhp cyBtb2RlbCBpcyAqKiBub3QgYSBkZXZpY2UgY29uZmlndXJhdGlvbiBtb2RlbCAqKi4gVGhlIGZv Y3VzIGlzIG9uIGFzcGVjdHMgdGhhdCBjYW4gYmUgdHJpZ2dlcmVkIGJ5IHNlcnZpY2UgcmVxdWVz dHMgYW5kIG1hbmFnZWQgYnkgdGhlIG5ldHdvcmsgY29udHJvbGxlci4gVGhpcyBuZXR3b3JrIHZp ZXcgb2YgdGhlIHNlcnZpY2Ugd2lsbCBiZSB0aGVuIGVucmljaGVkICh3aXRoIG90aGVyIHNvdXJj ZXMgc3VjaCBhcyBsb2NhbCB0ZW1wbGF0ZXMvcHJvZmlsZXMvZGVmYXVsdHMpIHRvIGRlcml2ZSB0 aGUgZXhoYXVzdGl2ZSBjb25maWd1cmF0aW9uIHRoYXQgd2lsbCBiZSBlbmZvcmNlZCBpbiBpbnZv bHZlZCBkZXZpY2VzIHRvIGRlbGl2ZXIgdGhlIHJlcXVlc3RlZCBzZXJ2aWNlLg0KDQpXaXRoIHRo YXQgcmF0aW9uYWxlIGluIG1pbmQsIHlvdSBjYW4gdW5kZXJzdGFuZCB3aHkgd2UgZG9u4oCZdCBp bXBvcnQgZGV2aWNlIG1vZGVscyBidXQgcG9pbnQgdG8gdGhlIGF1dGhvcml0YXRpdmUgUkZDcyBm b3IgYXNwZWN0cyB0aGF0IHdlIHRoaW5rIG1ha2Ugc2Vuc2UgdG8gYmUgdHdlYWtlZCBhdCB0aGUg bmV0d29yay1sZXZlbC4NCg0KVGhhbmtzLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBHcmVnIE1p cnNreSBbbWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21h aWwuY29tPl0NCkVudm95w6kgOiBzYW1lZGkgMjggYW/Du3QgMjAyMSAwNDo1Ng0Kw4AgOiBkcmFm dC1pZXRmLW9wc2F3Zy1sM3NtLWwzbm1AaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtb3BzYXdn LWwzc20tbDNubUBpZXRmLm9yZz47IG9wc2F3ZyA8b3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNh d2dAaWV0Zi5vcmc+PjsgcnRnLWJmZCBXRyA8cnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJm ZEBpZXRmLm9yZz4+DQpPYmpldCA6IEEgcXVlc3Rpb24gb24gT0FNIHNlY3Rpb24gaW4gZHJhZnQt aWV0Zi1vcHNhd2ctbDNzbS1sM25tDQoNCkRlYXIgQXV0aG9ycywNCnRoYW5rIHlvdSBmb3IgeW91 ciB3b3JrIG9uIHRoaXMgZG9jdW1lbnQuIEkndmUgcmVhZCB0aGUgZHJhZnQgYW5kIGhhdmUgYSBx dWVzdGlvbiwgYW5kIGEgc3VnZ2VzdGlvbi4gU2VjdGlvbiA3LjYuNDxodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLWwzc20tbDNubSNzZWN0aW9u LTcuNi40PiBkZXNjcmliZXMgaG93IEJGRCBpcyBjb250cm9sbGVkIGluIHZwbi1jb21tb24uIEkn dmUgbm90aWNlZCB0aGF0IHlvdSB1c2UgcmVmZXJlbmNlcyB0byBSRkMgNTg4MC4gV2hpbGUgdGhh dCBpcyB0aGUgYmFzaXMgZm9yIGFsbCBzdWJzZXF1ZW50IEJGRCBkb2N1bWVudHMsIGZvciBCRkQg WUFORyBkYXRhIG1vZGVsIGRyYWZ0LWlldGYtYmZkLXlhbmc8aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1iZmQteWFuZy8+IG1heSBiZSBtb3JlIHVzZWZ1bC4gUGVy aGFwcyB0aGUgY29udGFpbmVyIG9hbSBjYW4gcmUtdXNlIGdyb3VwaW5nIGJhc2UtY2ZnLXBhcm1z Lg0KV2hhdCBhcmUgeW91ciB0aG91Z2h0cz8NCg0KUmVnYXJkcywNCkdyZWcNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBk ZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl dWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNp IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50 IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3Bv bnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmll LiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBv ciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9k aWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2Ug bWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3Jt YXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25j CnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9u LiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNp Z25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2Vz IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBk J2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1l c3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hv dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVz c2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFu ayB5b3UuCgo= --_000_787AE7BB302AE849A7480A190F8B9330353E617COPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi UHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K c3Bhbi5QcmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1M IENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9y bWF0w6kgSFRNTCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3IjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVw dCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjE3NzAxNTkzOTQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMDI5MjU1MTEyO30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1i b3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SGkgR3JlZywNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ UGxlYXNlIHNlZSBpbmxpbmUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RGUm bmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gR3JlZyBNaXJza3kg W21haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7Ojwv Yj4gbHVuZGkgMzAgYW/Du3QgMjAyMSAxNTo0ODxicj4NCjxiPsOAJm5ic3A7OjwvYj4gQk9VQ0FE QUlSIE1vaGFtZWQgSU5OT1YvTkVUICZsdDttb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tJmd0 Ozxicj4NCjxiPkNjJm5ic3A7OjwvYj4gZHJhZnQtaWV0Zi1vcHNhd2ctbDNzbS1sM25tQGlldGYu b3JnOyBvcHNhd2cgJmx0O29wc2F3Z0BpZXRmLm9yZyZndDs7IHJ0Zy1iZmQgV0cgJmx0O3J0Zy1i ZmRAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogQSBxdWVzdGlvbiBv biBPQU0gc2VjdGlvbiBpbiBkcmFmdC1pZXRmLW9wc2F3Zy1sM3NtLWwzbm08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgTWVkLDxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYW5rIHlvdSBmb3IgeW91ciBk ZXRhaWxlZCZuYnNwO2ZlZWRiYWNrOyBtdWNoIGFwcHJlY2lhdGVkLiBJIHRoaW5rIHRoYXQgSSBu b3cgdW5kZXJzdGFuZCBiZXR0ZXIgdGhlIHBoaWxvc29waHkgb2YgdGhlIG1vZGVsLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPltNZWRdIEdyZWF0LCB0aGFua3MuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBJIHdpbGwgbm90 ZSB0aGF0IFJGQyA1ODgwIGRvZXMgbm90IGNvdmVyIFJGQyA3ODgwIGFuZCA4NTYyIChib3RoIGhh dmUgdXBkYXRlZCBSRkMgNTg4MCkuIEl0IHNlZW1zIHRoYXQgYWRkaW5nIGJmZC1zZXNzaW9uLXR5 cGUgY291bGQgYmUgYSB2ZXJ5IHVzZWZ1bCBlbmhhbmNlbWVudCB0byB0aGUgT0FNIGNvbnRhaW5l ci4gVmFsdWVzIGZvciB0aGUgbmV3IHBhcmFtZXRlciBzaG91bGQgcmVmbGVjdCB2YWx1ZXMNCiBk ZWZpbmVkIGZvciBiZmQuU2Vzc2lvblR5cGUgaW4gUkZDcyA3ODgwLCA4NTYyLCBhbmQgODU2Mzo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KU0JGREluaXRpYXRvcjs8 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+DQpTQkZEUmVmbGVjdG9yOzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClBvaW50VG9Qb2ludDs8bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpNdWx0 aXBvaW50SGVhZDs8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+DQpNdWx0aXBvaW50VGFpbDs8bzpwPjwvbzpwPjwvbGk+PGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpNdWx0aXBvaW50Q2xp ZW50PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5bTWVkXSBJ4oCZbSBhZnJhaWQgdGhhdCBtb3N0IG9mIHRoZXNlIGFwcGx5IGJldHdl ZW4gUEVzLCBub3QgdG8gdGhlIENFLVBFIHNlZ21lbnQuIE5vPyBUaGVyZSBtaWdodCBiZSBhIHZh bHVlIGluIGNvbnRyb2xsaW5nDQogd2hldGhlciBiYXNlIG9yIFMtQkZEIGlzIHVzZWQsIHRob3Vn aC4gPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFuZCBteSBhcG9sb2dpZXMgZm9yIG15IGxhdGUgY29tbWVudHMuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5H cmVnPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIE1vbiwgQXVnIDMwLCAyMDIxIGF0IDU6MTkgQU0gJmx0OzxhIGhyZWY9Im1haWx0bzptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkhpIEdyZWcsDQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5U aGFuayB5b3UgZm9yIGNoZWNraW5nIHRoZSBPQU0gcGFydCBhbmQgZm9yIHNoYXJpbmcgdGhpcyBj b21tZW50Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+QXMgeW91IGNhbiByZWFkIGluIGJvdGggc2VjdGlvbnMgNCBhbmQgNSwg dGhpcyBtb2RlbCBpcyAqKiBub3QgYSBkZXZpY2UgY29uZmlndXJhdGlvbiBtb2RlbCAqKi4gVGhl IGZvY3VzIGlzIG9uIGFzcGVjdHMNCiB0aGF0IGNhbiBiZSB0cmlnZ2VyZWQgYnkgc2VydmljZSBy ZXF1ZXN0cyBhbmQgbWFuYWdlZCBieSB0aGUgbmV0d29yayBjb250cm9sbGVyLiBUaGlzIG5ldHdv cmsgdmlldyBvZiB0aGUgc2VydmljZSB3aWxsIGJlIHRoZW4gZW5yaWNoZWQgKHdpdGggb3RoZXIg c291cmNlcyBzdWNoIGFzIGxvY2FsIHRlbXBsYXRlcy9wcm9maWxlcy9kZWZhdWx0cykgdG8gZGVy aXZlIHRoZSBleGhhdXN0aXZlIGNvbmZpZ3VyYXRpb24gdGhhdCB3aWxsIGJlIGVuZm9yY2VkDQog aW4gaW52b2x2ZWQgZGV2aWNlcyB0byBkZWxpdmVyIHRoZSByZXF1ZXN0ZWQgc2VydmljZS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5XaXRoIHRoYXQgcmF0aW9uYWxlIGluIG1pbmQsIHlvdSBjYW4gdW5kZXJzdGFuZCB3aHkgd2Ug ZG9u4oCZdCBpbXBvcnQgZGV2aWNlIG1vZGVscyBidXQgcG9pbnQgdG8gdGhlIGF1dGhvcml0YXRp dmUgUkZDcyBmb3INCiBhc3BlY3RzIHRoYXQgd2UgdGhpbmsgbWFrZSBzZW5zZSB0byBiZSB0d2Vh a2VkIGF0IHRoZSBuZXR3b3JrLWxldmVsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoYW5rcy4NCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNoZWVycyw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5NZWQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEdy ZWcgTWlyc2t5IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5FbnZv ecOpJm5ic3A7OjwvYj4gc2FtZWRpIDI4IGFvw7t0IDIwMjEgMDQ6NTY8YnI+DQo8Yj7DgCZuYnNw Ozo8L2I+IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW9wc2F3Zy1sM3NtLWwzbm1AaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWlldGYtb3BzYXdnLWwzc20tbDNubUBpZXRmLm9y ZzwvYT47IG9wc2F3ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9wc2F3Z0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm9wc2F3Z0BpZXRmLm9yZzwvYT4mZ3Q7OyBydGctYmZkIFdHICZsdDs8YSBocmVm PSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Zy1iZmRAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gQSBxdWVzdGlvbiBvbiBPQU0gc2Vj dGlvbiBpbiBkcmFmdC1pZXRmLW9wc2F3Zy1sM3NtLWwzbm08L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRlYXIgQXV0aG9ycyw8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRoYW5rIHlvdSBmb3IgeW91 ciB3b3JrIG9uIHRoaXMgZG9jdW1lbnQuIEkndmUgcmVhZCB0aGUgZHJhZnQgYW5kIGhhdmUgYSBx dWVzdGlvbiwgYW5kIGEgc3VnZ2VzdGlvbi4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1vcHNhd2ctbDNzbS1sM25tI3NlY3Rpb24tNy42 LjQiIHRhcmdldD0iX2JsYW5rIj4NClNlY3Rpb24gNy42LjQ8L2E+Jm5ic3A7ZGVzY3JpYmVzIGhv dyBCRkQgaXMgY29udHJvbGxlZCBpbiB2cG4tY29tbW9uLiBJJ3ZlIG5vdGljZWQgdGhhdCB5b3Ug dXNlIHJlZmVyZW5jZXMgdG8gUkZDIDU4ODAuIFdoaWxlIHRoYXQgaXMgdGhlIGJhc2lzIGZvciBh bGwgc3Vic2VxdWVudCBCRkQgZG9jdW1lbnRzLCBmb3IgQkZEIFlBTkcgZGF0YSBtb2RlbA0KPGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1iZmQteWFu Zy8iIHRhcmdldD0iX2JsYW5rIj5kcmFmdC1pZXRmLWJmZC15YW5nPC9hPiBtYXkgYmUgbW9yZSB1 c2VmdWwuIFBlcmhhcHMgdGhlIGNvbnRhaW5lciBvYW0gY2FuIHJlLXVzZSBncm91cGluZyBiYXNl LWNmZy1wYXJtcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+V2hhdCBhcmUgeW91ciB0aG91Z2h0cz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkdyZWc8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZT5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286 cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Q2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286 cD48L3ByZT4NCjxwcmU+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwg dmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hIGwnZXhwZWRpdGV1 ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3Bp ZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGFuayB5b3UuPG86cD48L286cD48L3ByZT4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRl cyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2 ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs ZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw dGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoK VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsK dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1 dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B9330353E617COPEXCAUBMA2corp_-- From nobody Tue Aug 31 11:13:05 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A633A0869; Tue, 31 Aug 2021 11:13:03 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 VPJhPYCwXpMF; Tue, 31 Aug 2021 11:12:58 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 975EB3A086E; Tue, 31 Aug 2021 11:12:57 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 013A91E28C; Tue, 31 Aug 2021 14:12:55 -0400 (EDT) Date: Tue, 31 Aug 2021 14:12:55 -0400 From: Jeffrey Haas To: Mahesh Jethanandani Cc: Alan DeKok , "rtg-bfd@ietf. org" , Reshad Rehman , draft-ietf-bfd-secure-sequence-numbers@ietf.org Subject: Re: I-D Action: draft-ietf-bfd-secure-sequence-numbers-08.txt Message-ID: <20210831181255.GB2820@pfrc.org> References: <20210405184656.GE12257@pfrc.org> <468C7D1D-7BE2-4759-9D81-0E18725FCA90@freeradius.org> <20210405190821.GF12257@pfrc.org> <14A4DD6D-7002-45A9-8FE4-42B512E97318@freeradius.org> <096BC9E7-8877-4EF3-A94B-394AFE0E76E7@freeradius.org> <20210726141455.GA32584@pfrc.org> <211EC22C-F4AB-4FE6-98AB-511C5CE4EB8B@freeradius.org> <20210726144826.GB32584@pfrc.org> <173DA06B-21E7-42A4-8EFF-82AA3D84B338@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <173DA06B-21E7-42A4-8EFF-82AA3D84B338@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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, 31 Aug 2021 18:13:03 -0000 Mahesh, Sorry for long delay. On Mon, Jul 26, 2021 at 04:25:25PM -0700, Mahesh Jethanandani wrote: > > On Jul 26, 2021, at 7:48 AM, Jeffrey Haas wrote: > > What's being requested is that our specifications have some specificity and > > a proposal be made for a suitable mechanism and how it integrates into BFD. > > :-) > > Here are the set of changes that I propose we make to the draft to bring > the specificity that you are requesting. For the introductory part of the > document there is no reference to the method being applied to come up with > a sequence number. It just states that the sequence number inserted is not > the monotonically increasing sequence number. As such no changes are > needed there. I agree. > The change therefore starts in Section 3 - Theory of operation. There are > two changes that I see. One has to do with carrying of nonce in the first > packet, and the other has to do with existing text in the section. > > For the carrying of nonce in the first packet, Alan has already suggested > adding the authentication section in the first packet. We will add text to > that effect. Since this mechanism is intended to work along with optimizing-authentication, which implies that we'll be using existing authentication mechanisms, how would this be carried? A core detail we're dealing with is establishing the expected sequence number to run through our hash. Consider the text from RFC 5880, §6.7.3 for keyed MD5: : If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For : Keyed MD5, if the sequence number lies outside of the range of : bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when : treated as an unsigned 32-bit circular number space), the received : packet MUST be discarded. For Meticulous Keyed MD5, if the : sequence number lies outside of the range of bfd.RcvAuthSeq+1 to : bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an : unsigned 32-bit circular number space) the received packet MUST be : discarded. : : Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to : 1, and bfd.RcvAuthSeq MUST be set to the value of the received : Sequence Number field. Until the implementation is ready to accept sequence numbers, the authentication sequence number is unknown. To use the secure sequence number procedures, we have to enter a state where the sequence number is known and then we can switch over to the new procedure. > As far as the existing text in the section is concerned, we will replace > reference to “symmetric key algorithm” and “symmetric algorithm” with > “hash”. As a result, the sender will include a ciphertext that is a 32-bit > hash computed using one of the algorithms Alan has suggested using a > shared key (that is not necessarily symmetric) and inserted in-lieu of the > sequence number of the packet. Please make sure the text discusses how that interacts with the authenticated packets. For example, if that authentication over the expected sequence number or the computed hash? But see below for some alternative thinking. > Yes, this draft is about obfuscation of the > sequence number field of the packet, not the entire packet. On reception > of the BFD Control packet, the receiver instead of decrypting the > ciphertext inserted in-place of the sequence number, will instead compare > the ciphertext to pre-computed set of hashes using the same shared key, on > the next k expected sequence numbers that are within the BFD Detect > Multiplier range. If there is a match, the receiver will replace the > ciphertext in the packet with the expected sequence number and pass the > frame for further processing. In the case there is no match, it will drop > the packet. This works for the case where we're having a series of next expected packets that do NOT differ from the prior ones aside from sequence number. That's the case we're trying to cover in the optimizing-authentication draft. One possibility to consider is that the core use-case for secure sequence numbers is to protect in cases where NULL auth was intended to be used. If the the procedure for secure sequence numbers is only intended to cover that use case, standard authenticated packets could use clear-text sequence numbers. This provides an entraining step where the sequence numbers are known. Once we're not authenticating the packets and would otherwise shift to NULL auth, we move specifically to secure-seq-auth and apply the procedures to those packets only. When a state change is necessary, this is indicated by moving to the prior expected authentication per optimizing-authentication. > There are some similar updates to the Security Considerations section to > replace “symmetric algorithm” with “hash”. > > Are these set of changes enough to bring the specificity that you are > looking for? I think we're starting to get there. And please note: We really do need a reference light-weight hash function to use in this draft before we can publish as an RFC, or perhaps a suite of them identified by a registry. If the text above about how we arrive at commonly understood sequence numbers seems reasoanble to the draft authors, we can discuss how we encode this in the BFD PDU. Perhaps as one or more auth types that aren't the NULL auth type. -- Jeff From nobody Tue Aug 31 13:50:48 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39363A0C81; Tue, 31 Aug 2021 13:50:46 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Fr3bBJq6tlFV; Tue, 31 Aug 2021 13:50:41 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 35A113A0C7D; Tue, 31 Aug 2021 13:50:41 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 898D11E28C; Tue, 31 Aug 2021 16:50:40 -0400 (EDT) Date: Tue, 31 Aug 2021 16:50:40 -0400 From: Jeffrey Haas To: Reshad Rahman Cc: Michael McBride , Rtg-bfd WG , "pim-chairs@ietf.org" Subject: Re: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05 Message-ID: <20210831205040.GC2820@pfrc.org> References: <202107220742327030208@zte.com.cn> <1867869445.417157.1629489910471@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1867869445.417157.1629489910471@mail.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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, 31 Aug 2021 20:50:47 -0000 Mike, Thanks for bringing this to the BFD Working Group. I've had a chance to read through the draft. In spite of it being several years since I've worked on/with PIM, I think I've understood it. :-) If I were to re-state the longer version of the draft's name, this is effectively "using BFD-MP to let PIM hello procedures fail faster". If that's an adequate assessment, perhaps the title might be adjusted a bit. I think Alvaro's point is that this is really covering a small bit of PIM procedure and it sounds like it's intended to be a lot more broad from the document title. The procedures seem to be largely straight-forward, as long as you're comfortable with the error handling procedures for the wrong OptionLength. Perhaps alternatively if this field is the incorrect length you simply ignore the procedure rather than stopping the processing of PIM. That said, do whatever is normative within the protocol for such cases. My two remaining comments are one operational one, and one related to forwarding: As written, any PIM speaker could become a BFD MultiPointHead. This theoretically means that on a busy LAN segment you can get a lot of chatty multi-point BFD traffic. I realize that typical PIM deployments mean that this is less likely to happen. Since PIM is used to build multicast trees, realistically you only need the MultiPointHead procedures to be running on upstream nodes. At typical multicast endpoints, it's usually clear what the upstreams will be. At other arbitrary points in the network, this is less clear but those are typically not LAN segments. If there's text to operationally suggest that you only do the MultiPointHead configuration on appropriate nodes, that may be helpful. My second concern is shorter. Section 2.3 recommends that the p2mp BFD sessions use a TTL of 255 and reference the GTSM procedures in RFC 5881. However, since the destination address is a multicast group and the underlying PIM protocol uses a TTL of 1 for its messages, I'm not sure the 255 is appropriate for this use case. If there is documentation in PIM for the use of GTSM procedures, I'd suggest referencing those procedures in this draft. -- Jeff On Fri, Aug 20, 2021 at 08:05:10PM +0000, Reshad Rahman wrote: > Thanks Michael. Adding BFD WG. > > Regards,Reshad. > -----Original Message----- > From: pim On Behalf Of Michael McBride > Sent: Tuesday, August 17, 2021 10:53 PM > To: Alvaro Retana ; gregory.mirsky@ztetx.com > Cc: draft-ietf-pim-bfd-p2mp-use-case@ietf.org; mmcbride7@gmail.com; pim-chairs@ietf.org; pim@ietf.org > Subject: Re: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05 > > Hi Greg, > > Please consider either 1) dropping the "use-case" from the draft name and keep it a specific pim-bfd-p2mp solution and less generalized or 2) keeping the existing name and make it more generalized with more use cases as Alvaro suggests. > > I'll ping the bfd chairs and cc you to ensure they are in the loop. > > Thanks, > mike > > -----Original Message-----2021-02-04-Network TMT Meetings : https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fefutureway.sharepoint.com%2Fteams%2FNetworkLabTMT%2FShared&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C58e9d5e586be49da514708d9620c8c21%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637648628320865112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AlTELyg1EqhpLnl8aYSCv9YKEH6zldm46UVAx8MZaus%3D&reserved=0 Documents/General/Network Lab TMT Meeting/February 4 2021 Meeting/2021-02-04-Network TMT Meetings.pptx?web=1G > From: pim On Behalf Of Alvaro Retana > Sent: Tuesday, August 17, 2021 8:19 AM > To: gregory.mirsky@ztetx.com > Cc: draft-ietf-pim-bfd-p2mp-use-case@ietf.org; mmcbride7@gmail.com; pim-chairs@ietf.org; pim@ietf.org > Subject: Re: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05 > > On July 21, 2021 at 7:42:42 PM, gregory.mirsky@ztetx.com wrote: > > > Greg: > > Hi! > > Thanks for the update!! > > I have some comments in-line. I am also attaching (below) a review of -06, which mostly contains minor issues and nits related to new/updated text. > > > The main item I would like WG input on is the generalization of the mechanism. In short, bootstrapping the BFD session is the main focus of this document; I don't see a reason to avoid generalizing its use to other scenarios. We already agree on the wider applicability -- the incremental changes needed to generalize the text is far less than the process it will take to do it later. > > Mike: as Shepherd/Chair, please start a conversation in the WG as needed. Please take a look at the discussion below. > > > Thanks! > > Alvaro. > > > > ... > > Sender: AlvaroRetana > ... > > This document specifies two things: (1) a Hello option to help the > > tail bootstrap the BFD session, and, (2) the actions that the tail > > takes when a failure is detected. The former is common to all cases, > > while the latter depends on the role of the head with respect to the > > tail. The actions are basically an acceleration of what would > > naturally happen (if BFD was not used and the failure detection was > > "slow"). Is this a fair characterization of the document? > > GIM>> Yes, absolutely correct. > > ... > > Are there other cases that could use this mechanism to track? I can > > think of a couple of cases: monitor PIM neighbors that send Joins, RPF > > neighbors, Assert winners... As with the DR case, for example, these > > cases don't require actions beyond an acceleration. It would be ideal > > if the document could cover these cases, and possibly others, in a > > generic way -- I can't think of good phrasing with now, but I'm sure > > you can. ;-) > > GIM>> I agree that the defined PIM Hello BFD Discriminator option can be > GIM>> used by not only PIM DR/BDR nodes. Indeed, there are other use > GIM>> cases where a faster detection will improve the convergence in the > GIM>> control plane and minimize the negative impact on the multicast > GIM>> data plane. These use cases may be covered in the future. > > Maybe I'm missing something obvious, and would like to understand what. :-) > > The Hello option helps the tail bootstrap a BFD session, correct? If so, there's nothing in that description about the function of the tail (or the head). The point that I'm trying to make above is that the only thing that BFD is providing any use case is faster detection of a failure (which is very significant, of course!), so regardless of the application or function of the tail/head, the operation can be generalized. Is this not true? What am I missing? > > To be more specific, the description in 2.1 (Using P2MP BFD in PIM DR/BDR Monitoring) is a generic description, and not one that only applies to a DR/BDR. In fact, the text says that any node "regardless of its role, MAY become a head of a p2mp BFD session" -- which means that it is up to the tail to monitor it or not. > > The last two paragraphs in 2.1 do mention the DR/BDR function, but they could easily be generalized: > > OLD> > If the tail detects a MultipointHead failure [RFC8562], it MUST > delete the corresponding neighbor state. If the failed head was the > DR (or BDR), the DR (or BDR) election mechanism in [RFC7761] or > [I-D.ietf-pim-dr-improvement] is followed. > > If the head ceases to include the BFD Discriminator PIM Hello option > in its PIM-Hello message, tails MUST close the corresponding > MultipointTail BFD session. Thus the tail stops using BFD to monitor > the head and reverts to the procedures defined in [RFC7761] and > [I-D.ietf-pim-dr-improvement]. > > > NEW> > If the tail detects a MultipointHead failure [RFC8562], it MUST > delete the corresponding neighbor state. If the head ceases to > include the BFD Discriminator PIM Hello option in its PIM-Hello > message, tails MUST close the corresponding MultipointTail BFD > session. In both cases, the tail continues to follow the > specification related to the function of the head. > > > > GIM>> As I think of it, one aspect would be homogeneity of p2mp BFD > GIM>> capability throughout the domain. In other words, what happens if > GIM>> some PIM nodes don't support the BFD Discriminator option and do > GIM>> not use p2mp BFD? What their slow (regular) convergence impact > GIM>> other nodes? But that, I think, is for further discussion, work. Would you agree? > > I don't. > > In fact, this is a very important deployment point that I had overlooked. If the support is not homogeneous, then some parts of the network will converge (to the new state) faster than others. As with unicast routing I think the main effect may be longer than expected inconsistency, but not worst than without BFD. The specific effect relates to the use case...but because the deployment would be localized (the DR and other routers on the LAN, for example), then any negative effect of not supporting BFD (i.e. behaving as today) would be localized. > > Thank you for bringing this up. If you consider the effect significant for a specific case then please add a couple of sentences. > > > ... > > 183 3.1. Using P2MP BFD in PIM DR/BDR Monitoring > ... > > 229 If the head ceased to include BFD TLV in its PIM-Hello message, > > tails > > 230 MUST close the corresponding MultipointTail BFD session. Thus the > > 231 tail stops using BFD to monitor the head and reverts to the > > 232 procedures defined in [RFC7761] and [I-D.ietf-pim-dr-improvement]. > ... > > [major] Let me see if I understand: if the head doesn't use the BFD > > hello option anymore then the tail can gracefully stop using BFD. > > IOW, this way the BFD session does not expire and result in the DR > > being declared dead. Is that it? > > GIM>> Yes, that is what we've intended - revert to "slow" detection. > > > Given that the BFD session can be bootstrapped at the tail by manually > > configuring the corresponding discriminator, it seems that stopping > > the use of the BFD hello option may not result in the expected > > outcome. ??? > > GIM>> Yes, the head's My Discriminator value can be provisioned using > GIM>> the management plane. If that is the case, then I think this > GIM>> document is not applicable as the head and leaves use RFC 8562 without any additions. > > The problem is that the text now says this: > > If the head ceases to include the BFD Discriminator PIM Hello option > in its PIM-Hello message, tails MUST close the corresponding > MultipointTail BFD session. Thus the tail stops using BFD to monitor > the head... > > s/MUST/SHOULD Provisioning the node is the exception, so the action should be recommended and not required. > > > ... > > 288 5. Security Considerations > ... > > 299 An implementation that supports this specification SHOULD use a > > 300 mechanism to control the maximum number of BFD sessions that can > > be > > 301 active at the same time. > > > > [major] rfc8562 already requires "protective measures to prevent an > > infinite number of MultipointTail sessions from being created". It is > > then not needed for this document to recommend anything that is > > required elsewhere. > > GIM>> Done. > > ?? You left the paragraph in. > > > > [major] What new security risks are introduced by the mechanism in > > this draft? In general, a rogue node can stop sending or delay BFD > > packets causing the tail to conclude that the head is down: the DR/BDR > > may change causing instability. I was surprised that rfc8562 did not > > mention the interaction risk, but rfc5880 already does. I feel that > > something needs to be mentioned specific to this document, even if it > > is highlighted that the risk is not new. > > GIM>> Then that "rogue" node is the PIM DR/BDR, not a man-in-the-middle. > GIM>> And the attack is by making the p2mp BFD session expire on leaves > GIM>> while still periodically sending PIM Hello. AFAIK, since PIM > GIM>> DR/BDR election takes several Hello cycles, I don't think that > GIM>> that behavior will affect the multicast service. Perhaps I'm missing something, please advise. > > Yes, the problem is that 2.1 says that the tail "MUST delete the corresponding neighbor state". This results in the DR not being elected for a while. > > I see what you mean: if the DR is still there then the election will probably elect it again. However, in the meantime the DR may not think it is the DR anymore if the other routers in the LAN start a new DR election. (??) Please add the explanation (or something like it) to make it clear that the risk is mitigated by the "double set of hellos". > > In the general case... If tracking the sender of a Join, for example, the effect would be more significant: an outage would exist until the next Join is received. > > > ... > > 310 7.1. Normative References > > .. > > 327 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding > > Detection > > 328 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, > > 329 DOI 10.17487/RFC5881, June 2010, > > 330 . > > > > [minor] This reference can be Informative. > > I know you moved it...but now that you added a reference to it in 2.3 then we need it to be Normative. Sorry. > > > ... > > [End of review -05.] > > > > [Start -06] > [Line numbers from idnits.] > > ... > 129 2. BFD Discriminator PIM Hello Option > ... > 153 If the value of the OptionLength field is not equal to 4, the BFD > 154 Discriminator PIM Hello option is considered malformed, and the > 155 receiver MUST stop processing PIM Hello options. If the value of the > 156 My Discriminator field equals zero, then the BFD Discriminator PIM > 157 Hello option MUST be considered invalid, and the receiver MUST ignore > 158 it. The receiver SHOULD log the notification regarding the malformed > 159 or invalid BFD Discriminator Hello option under the control of a > 160 throttling logging mechanism. > > [major] "MUST stop processing PIM Hello options" > > Stop in the current Hello message? Should it ignore all the options or just the ones after this one? In all future Hello messages? > > I haven't thought about this enough, but there could be an effect on other functionality. What is that effect? I couldn't find anywhere a general way to handle malformed Hello options -- did I miss it? > > > [nit] s/log the notification/log a notification > > > 162 2.1. Using P2MP BFD in PIM DR/BDR Monitoring > ... > 169 If a PIM-SM router is configured to monitor the head by using p2mp > 170 BFD, referred to through this document as 'tail', receives PIM-Hello > 171 packet with BFD Discriminator PIM Hello option, the tail MAY create a > 172 p2mp BFD session of type MultipointTail, as defined in [RFC8562]. > > [minor] s/router is configured/router that is configured > > [nit] s/receives PIM-Hello packet with BFD Discriminator/receives a PIM-Hello packet with the BFD Discriminator > > > ... > 188 If the head ceases to include the BFD Discriminator PIM Hello option > 189 in its PIM-Hello message, tails MUST close the corresponding > 190 MultipointTail BFD session. Thus the tail stops using BFD to monitor > 191 the head and reverts to the procedures defined in [RFC7761] and > 192 [I-D.ietf-pim-dr-improvement]. > > [minor] "...MUST close the corresponding MultipointTail BFD session" > > It might be a good thing adding that the PIM state is not affected by this action. > > > 194 2.2. P2MP BFD in PIM DR Load Balancing > > 196 [RFC8775] specifies the PIM Designated Router Load Balancing (DRLB) > 197 functionality. Any PIM router that advertises the DRLB-Cap Hello > 198 Option can become the head of a p2mp BFD session, as specified in > 199 Section 2.1. The head router administratively sets the > 200 bfd.SessionState to Up in the MultipointHead session [RFC8562] only > 201 if it is a Group Designated Router (GDR) Candidate, as specified in > 202 Sections 5.5 and 5.6 of [RFC8775]. If the router is no longer the > 203 GDR, then it MUST shut down following the procedures described in > 204 Section 5.9 [RFC8562]. For each GDR Candidate that includes BFD > 205 Discriminator option in its PIM Hello, the PIM DR creates a > 206 MultipointTail session [RFC8562]. PIM DR demultiplexes BFD sessions > 207 based on the value of the My Discriminator field and the source IP > 208 address. If PIM DR detects a failure of one of the sessions, it MUST > 209 remove that router from the GDR Candidate list and immediately > 210 transmit a new DRLB-List option. > > [] Continuing with my theme of generalizing this specification... > This section says everything that the last section already specified in a generic way. IOW, it is not really needed. > > There is one thing that this paragraph adds: "If the router is no longer the GDR, then it MUST shut down following the procedures described in Section 5.9 [RFC8562]." Yes, shutting down the BFD session is important, but so is not including the BFD Discriminator option in the Hello anymore. As with everything else, this part can also be generalized: > > If the head is no longer serving the function that prompted it > to be monitored, then it MUST cease including the BFD Discriminator > PIM Hello option in its PIM-Hello message, and it MUST shut down > the BFD session following the procedures described in Section 5.9 > [RFC8562]. > > > 212 2.3. Multipoint BFD Encapsulation > > 214 The MultipointHead of a p2mp BFD session when transmitting BFD > 215 Control packet: > > [nit] s/packet/packets > > > 217 MUST set TTL or Hop Limit value to 255 (Section 5 [RFC5881]); > > [major] "MUST set...RFC5881" This action is already required in an RFC that this document depends on, please don't specify the behavior again. I understand that rfc5682 can be used in multi-hop scenarios, but rfc5881 is the source here. s/MUST/must > > > ... > 222 3. IANA Considerations > ... > 227 +=============+================+===================+===============+ > 228 | Value Name | Length Number | Name Protocol | Reference | > 229 +=============+================+===================+===============+ > 230 | TBA | 4 | BFD Discriminator | This document | > 231 | | | Option | | > 232 +-------------+----------------+-------------------+---------------+ > > [major] Please use the same field names as in the registry: Value, Length, Name, Reference > > [EoR -06] > > _______________________________________________ > pim mailing list > pim@ietf.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C58e9d5e586be49da514708d9620c8c21%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637648628320865112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zhFkLPkgOJ9EeuloewKnNDe75JqgzbOWdfV3%2Bd5EBRk%3D&reserved=0 > > _______________________________________________ > pim mailing list > pim@ietf.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C58e9d5e586be49da514708d9620c8c21%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637648628320875108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4SrgiS9qdwYswCMitpP4Qf1iWZ4zJkVauDz%2B4%2BKyvyA%3D&reserved=0 > From nobody Tue Aug 31 14:31:00 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05DD3A010A; Tue, 31 Aug 2021 14:30:53 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 DpcTxFZCB-Wl; Tue, 31 Aug 2021 14:30:48 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 638C13A0115; Tue, 31 Aug 2021 14:30:48 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6B7C11E28D; Tue, 31 Aug 2021 17:30:47 -0400 (EDT) Date: Tue, 31 Aug 2021 17:30:46 -0400 From: Jeffrey Haas To: mohamed.boucadair@orange.com Cc: Greg Mirsky , "draft-ietf-opsawg-l3sm-l3nm@ietf.org" , opsawg , rtg-bfd WG Subject: Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm Message-ID: <20210831213046.GD2820@pfrc.org> References: <5697_1630325964_612CCCCC_5697_162_1_787AE7BB302AE849A7480A190F8B9330353E5905@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5697_1630325964_612CCCCC_5697_162_1_787AE7BB302AE849A7480A190F8B9330353E5905@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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, 31 Aug 2021 21:30:54 -0000 Med, On Mon, Aug 30, 2021 at 12:19:23PM +0000, mohamed.boucadair@orange.com wrote: > Hi Greg, > > Thank you for checking the OAM part and for sharing this comment. > > As you can read in both sections 4 and 5, this model is ** not a device configuration model **. The focus is on aspects that can be triggered by service requests and managed by the network controller. This network view of the service will be then enriched (with other sources such as local templates/profiles/defaults) to derive the exhaustive configuration that will be enforced in involved devices to deliver the requested service. > > With that rationale in mind, you can understand why we don’t import device models but point to the authoritative RFCs for aspects that we think make sense to be tweaked at the network-level. Greg's suggestion is not to import a device specific model. His suggestion is to leverage groupings defined in the BFD yang model that have the configuration semantics typical of most BFD implementations. Put a different way, if you're defining BFD parameters, why would you have different names or structures for BFD configuration elements in your module than everyone else? -- Jeff From nobody Tue Aug 31 23:49:03 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E507C3A1B8B; Tue, 31 Aug 2021 23:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com 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 GZ01bfdw9s_l; Tue, 31 Aug 2021 23:48:47 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1794A3A1B89; Tue, 31 Aug 2021 23:48:47 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr26.francetelecom.fr (ESMTP service) with ESMTPS id 4Gzvlx1krkz10X7; Wed, 1 Sep 2021 08:48:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1630478925; bh=Iqim9KmsgIcFwTzPbgTMKJps/BbqmxUbtv5NKUrHHdg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Cvs4ycVDuUyNknUip0vGEFB2GJ85jd5I8WOsND++1kE8M1baL7AlNXidlfsq+5KhT mlAwkSpntYr9ynLR6RybTP4cOEInw3chNyaf1Q1xQZawnuEUd6fKA2ix6kYxiooVuB 1p9vgHSIqKOJoI7md1uJg3smCvmHNnGnxgep1FOfS38NcrjLfxGB3v8ZQdhmWjcngh N0IYGOIS6XGIjC3i6Tmyj0G8M+snuNj/wUDYh92mH10n8CZCYJ/xsKzthx273FyOq0 uODvx6VZ2bxGCLb+8iD4BjJrgGsCXXt+Gb+694OwIHHQlMVXi6c7R0lkcF9WOSpOQN K3TRx+lN566rg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr04.francetelecom.fr (ESMTP service) with ESMTPS id 4Gzvlx09QNz1xpC; Wed, 1 Sep 2021 08:48:45 +0200 (CEST) From: To: Jeffrey Haas CC: Greg Mirsky , "draft-ietf-opsawg-l3sm-l3nm@ietf.org" , opsawg , rtg-bfd WG Subject: RE: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm Thread-Topic: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm Thread-Index: AQHXnq91F+AImF6j4kyRdEknpTfMS6uOteTA Date: Wed, 1 Sep 2021 06:48:43 +0000 Message-ID: <25527_1630478925_612F224D_25527_493_1_787AE7BB302AE849A7480A190F8B9330353E6E4D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <5697_1630325964_612CCCCC_5697_162_1_787AE7BB302AE849A7480A190F8B9330353E5905@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20210831213046.GD2820@pfrc.org> In-Reply-To: <20210831213046.GD2820@pfrc.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2021 06:48:53 -0000 SGkgSmVmZiwgDQoNCkFjdHVhbGx5LCBleGNlcHQgbG9jYWwtbXVsdGlwbGllciB0aGF0IHdlIGNh bGwgZGV0ZWN0aW9uLW11bHRpcGxpZXIsIHRoZSBzYW1lIG5hbWVzIGFyZSB1c2VkIGluIGJvdGgg ZHJhZnRzLiBXZSBjYW4gZml4IHRoYXQgb25lLg0KDQpQbGVhc2Ugbm90ZSB0aGF0IHdlIGFyZSBu b3QgdXNpbmcgdGhlIGludGVydmFsLWNvbmZpZy10eXBlIGNob2ljZSBnaXZlbiB0aGF0IHRoZSBz aW5nbGUgY2FzZSBjYW4gYmUgY292ZXJlZCBieSBzZXR0aW5nIGRlc2lyZWQtbWluLXR4LWludGVy dmFsIGFuZCByZXF1aXJlZC1taW4tcngtaW50ZXJ2YWwgdG8gdGhlIHNhbWUgdmFsdWUuIEl0IGlz IHRoZW4gc3RyYWlnaHRmb3J3YXJkIHRvIG1hcCBpdCB0aGUgZGV2aWNlIG1vZHVsZSBkZXBlbmRp bmcgd2hldGhlciBzaW5nbGUtbWluaW11bS1pbnRlcnZhbCBmZWF0dXJlIGlzIHN1cHBvcnRlZCBv ciBub3QuIFdlIGRvbid0IHdhbnQgdG8gY29tcGxpY2F0ZSB0aGUgbmV0d29yayB2aWV3IG9mIHRo ZSBzZXJ2aWNlIHdpdGggc3VjaCBkZXZpY2UtbGV2ZWwgZmVhdHVyZXMuDQoNClRoYW5rIHlvdS4g DQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKg OiBKZWZmcmV5IEhhYXMgW21haWx0bzpqaGFhc0BwZnJjLm9yZ10NCj4gRW52b3nDqcKgOiBtYXJk aSAzMSBhb8O7dCAyMDIxIDIzOjMxDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElOTk9WL05F VCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gQ2PCoDogR3JlZyBNaXJza3kgPGdy ZWdpbWlyc2t5QGdtYWlsLmNvbT47IGRyYWZ0LWlldGYtb3BzYXdnLWwzc20tDQo+IGwzbm1AaWV0 Zi5vcmc7IG9wc2F3ZyA8b3BzYXdnQGlldGYub3JnPjsgcnRnLWJmZCBXRyA8cnRnLQ0KPiBiZmRA aWV0Zi5vcmc+DQo+IE9iamV0wqA6IFJlOiBBIHF1ZXN0aW9uIG9uIE9BTSBzZWN0aW9uIGluIGRy YWZ0LWlldGYtb3BzYXdnLWwzc20tbDNubQ0KPiANCj4gTWVkLA0KPiANCj4gT24gTW9uLCBBdWcg MzAsIDIwMjEgYXQgMTI6MTk6MjNQTSArMDAwMCwNCj4gbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbSB3cm90ZToNCj4gPiBIaSBHcmVnLA0KPiA+DQo+ID4gVGhhbmsgeW91IGZvciBjaGVja2lu ZyB0aGUgT0FNIHBhcnQgYW5kIGZvciBzaGFyaW5nIHRoaXMgY29tbWVudC4NCj4gPg0KPiA+IEFz IHlvdSBjYW4gcmVhZCBpbiBib3RoIHNlY3Rpb25zIDQgYW5kIDUsIHRoaXMgbW9kZWwgaXMgKiog bm90IGENCj4gZGV2aWNlIGNvbmZpZ3VyYXRpb24gbW9kZWwgKiouIFRoZSBmb2N1cyBpcyBvbiBh c3BlY3RzIHRoYXQgY2FuIGJlDQo+IHRyaWdnZXJlZCBieSBzZXJ2aWNlIHJlcXVlc3RzIGFuZCBt YW5hZ2VkIGJ5IHRoZSBuZXR3b3JrIGNvbnRyb2xsZXIuDQo+IFRoaXMgbmV0d29yayB2aWV3IG9m IHRoZSBzZXJ2aWNlIHdpbGwgYmUgdGhlbiBlbnJpY2hlZCAod2l0aCBvdGhlcg0KPiBzb3VyY2Vz IHN1Y2ggYXMgbG9jYWwgdGVtcGxhdGVzL3Byb2ZpbGVzL2RlZmF1bHRzKSB0byBkZXJpdmUgdGhl DQo+IGV4aGF1c3RpdmUgY29uZmlndXJhdGlvbiB0aGF0IHdpbGwgYmUgZW5mb3JjZWQgaW4gaW52 b2x2ZWQgZGV2aWNlcw0KPiB0byBkZWxpdmVyIHRoZSByZXF1ZXN0ZWQgc2VydmljZS4NCj4gPg0K PiA+IFdpdGggdGhhdCByYXRpb25hbGUgaW4gbWluZCwgeW91IGNhbiB1bmRlcnN0YW5kIHdoeSB3 ZSBkb27igJl0DQo+IGltcG9ydCBkZXZpY2UgbW9kZWxzIGJ1dCBwb2ludCB0byB0aGUgYXV0aG9y aXRhdGl2ZSBSRkNzIGZvciBhc3BlY3RzDQo+IHRoYXQgd2UgdGhpbmsgbWFrZSBzZW5zZSB0byBi ZSB0d2Vha2VkIGF0IHRoZSBuZXR3b3JrLWxldmVsLg0KPiANCj4gR3JlZydzIHN1Z2dlc3Rpb24g aXMgbm90IHRvIGltcG9ydCBhIGRldmljZSBzcGVjaWZpYyBtb2RlbC4gIEhpcw0KPiBzdWdnZXN0 aW9uIGlzIHRvIGxldmVyYWdlIGdyb3VwaW5ncyBkZWZpbmVkIGluIHRoZSBCRkQgeWFuZyBtb2Rl bA0KPiB0aGF0IGhhdmUgdGhlIGNvbmZpZ3VyYXRpb24gc2VtYW50aWNzIHR5cGljYWwgb2YgbW9z dCBCRkQNCj4gaW1wbGVtZW50YXRpb25zLg0KPiANCj4gUHV0IGEgZGlmZmVyZW50IHdheSwgaWYg eW91J3JlIGRlZmluaW5nIEJGRCBwYXJhbWV0ZXJzLCB3aHkgd291bGQNCj4geW91IGhhdmUgZGlm ZmVyZW50IG5hbWVzIG9yIHN0cnVjdHVyZXMgZm9yIEJGRCBjb25maWd1cmF0aW9uDQo+IGVsZW1l bnRzIGluIHlvdXIgbW9kdWxlIHRoYW4gZXZlcnlvbmUgZWxzZT8NCj4gDQo+IC0tIEplZmYNCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly IGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBk b2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1 aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp LgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh dzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0 IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuClRoYW5rIHlvdS4KCg==