From nobody Mon May 2 12:36:28 2016 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 AD76D12D179; Mon, 2 May 2016 12:36:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" Subject: Kathleen Moriarty's Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS) X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160502193624.15732.51479.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2016 12:36:24 -0700 Archived-At: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 19:36:24 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-bfd-seamless-base-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This should be pretty easy to address. In the security consideration section, the following recommendation appears: o SBFDReflector MUST NOT look at the crypto sequence number before accepting the packet. Could you please add text to say what happens (what attacks are possible) if this is looked at? There is nothing to stop the crypt sequence number from being looked at, right? Is there a way to actually prevent that? From nobody Mon May 2 14:24:37 2016 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 8F70912D523; Mon, 2 May 2016 14:24:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" Subject: Alia Atlas' Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS and COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160502212434.15622.98408.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2016 14:24:34 -0700 Archived-At: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 21:24:34 -0000 Alia Atlas has entered the following ballot position for draft-ietf-bfd-seamless-base-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- a) In Sec 7.2.3: "If the SBFDReflector is generating a response S-BFD control packet for a local entity that is in service, then "state" in response BFD control packets MUST be set to UP." So far, it looked like the SBFDReflector only sends BFD control packets in response to receiving such packets from SBFDInitiators. This paragraph (not just copied) does not clearly describe the desired behavior. If the monitored local entity is "temporarily out of service", does the SBFDReflector respond back to the SBFDInitiator with 2 BFD control packets - one indicating UP (as a MUST) and then the next indicating ADMINDOWN? Is the SBFDReflector expected to store a list of active SBFDInitiators and proactively send BFD control packets indicating ADMINDOWN? Please clarify in non-trivial detail. b) Appendix A: The looping problem is nicely defined but the text still discusses three potential solutions; clearly the use of the D bit has been chosen. It would be much nicer to have the justification in line, but for this discuss - the unselected alternatives don't belong. c) Sec 7.2.1: " S-BFD packet MUST be demultiplexed with lower layer information (e.g., dedicated destination UDP port, associated channel type)." Where precisely is this defined or described? Is there an allocation for a dedicated UDP port for S-BFD? I don't see any normative reference to such. In particular, since the format for an S-BFD control packet is exactly the same as for BFD and since only this demultiplexing with lower layer information is used to tell the difference between S-BFD and BFD packets, this document requires more specifics. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) In the last paragraph of Sec 4.2: " Even when following the separate discriminator pool approach, collision is still possible between one S-BFD application to another S-BFD application, that may be using different values and algorithms to derive S-BFD discriminator values. If the two applications are using S-BFD for a same purpose (e.g., network reachability), then the colliding S-BFD discriminator value can be shared. If the two applications are using S-BFD for a different purpose, then the collision must be addressed. How such collisions are addressed is outside the scope of this document." Sec 4.1 talks about the need for the S-BFD Discriminator to be unique within an Administrative Domain. I don't see any details of that addressed here. What is addressed here seems to be the case for multiple S-BFD discriminators applying to the same node - which is specifically discouraged at the end of Sec 3. Rather than simply describing the issue as "outside the scope of this document", please either describe it as "future work and multiple S-BFD discriminators is discouraged" or add a reference. 2) In Sec 6.1: "bfd.SessionType:" is defined but the only possible values are for SBFD. Is it possible for a BFD session to still use the same bfd structure? I don't see a value for SessionType there; I'd expect to see at least a value for the original BFD session and possible an undefined or unspecified value for future proofing. From nobody Mon May 2 15:09:57 2016 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 C6CFD12D126; Mon, 2 May 2016 15:09:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" Subject: Alia Atlas' No Objection on draft-ietf-bfd-seamless-use-case-06: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160502220953.15818.52059.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2016 15:09:53 -0700 Archived-At: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-seamless-use-case@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 22:09:54 -0000 Alia Atlas has entered the following ballot position for draft-ietf-bfd-seamless-use-case-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-use-case/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) Sec 3.7: This section describes BFD Fault Isolation. It isn't clear to me that the S-BFD base spec has addressed this case at all. More clarification would be nice - either indicating that this use-case wasn't handled or having a small pointer to how it was. From nobody Mon May 2 15:14:49 2016 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 5328612D193; Mon, 2 May 2016 15:14:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" Subject: Alia Atlas' Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS and COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160502221446.15647.60892.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2016 15:14:46 -0700 Archived-At: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 22:14:46 -0000 Alia Atlas has entered the following ballot position for draft-ietf-bfd-seamless-base-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- a) In Sec 7.2.3: "If the SBFDReflector is generating a response S-BFD control packet for a local entity that is in service, then "state" in response BFD control packets MUST be set to UP." So far, it looked like the SBFDReflector only sends BFD control packets in response to receiving such packets from SBFDInitiators. This paragraph (not just copied) does not clearly describe the desired behavior. If the monitored local entity is "temporarily out of service", does the SBFDReflector respond back to the SBFDInitiator with 2 BFD control packets - one indicating UP (as a MUST) and then the next indicating ADMINDOWN? Is the SBFDReflector expected to store a list of active SBFDInitiators and proactively send BFD control packets indicating ADMINDOWN? Please clarify in non-trivial detail. b) Appendix A: The looping problem is nicely defined but the text still discusses three potential solutions; clearly the use of the D bit has been chosen. It would be much nicer to have the justification in line, but for this discuss - the unselected alternatives don't belong. c) Sec 7.2.1: " S-BFD packet MUST be demultiplexed with lower layer information (e.g., dedicated destination UDP port, associated channel type)." Please add a clear reference to [draft-ietf-bfd-seamless-ip] here to show where to find the dedicated UDP port for S-BFD; I think this or some other mechanism needs to be a normative reference, because I don't see how one could implement S-BFD without this knowledge. In particular, since the format for an S-BFD control packet is exactly the same as for BFD and since only this demultiplexing with lower layer information is used to tell the difference between S-BFD and BFD packets, this document requires more specifics. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) In the last paragraph of Sec 4.2: " Even when following the separate discriminator pool approach, collision is still possible between one S-BFD application to another S-BFD application, that may be using different values and algorithms to derive S-BFD discriminator values. If the two applications are using S-BFD for a same purpose (e.g., network reachability), then the colliding S-BFD discriminator value can be shared. If the two applications are using S-BFD for a different purpose, then the collision must be addressed. How such collisions are addressed is outside the scope of this document." Sec 4.1 talks about the need for the S-BFD Discriminator to be unique within an Administrative Domain. I don't see any details of that addressed here. What is addressed here seems to be the case for multiple S-BFD discriminators applying to the same node - which is specifically discouraged at the end of Sec 3. Rather than simply describing the issue as "outside the scope of this document", please either describe it as "future work and multiple S-BFD discriminators is discouraged" or add a reference. 2) In Sec 6.1: "bfd.SessionType:" is defined but the only possible values are for SBFD. Is it possible for a BFD session to still use the same bfd structure? I don't see a value for SessionType there; I'd expect to see at least a value for the original BFD session and possible an undefined or unspecified value for future proofing. From nobody Mon May 2 15:26:29 2016 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 35EBA12D191; Mon, 2 May 2016 15:26:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" Subject: Alia Atlas' Discuss on draft-ietf-bfd-seamless-ip-04: (with DISCUSS) X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160502222627.15846.1446.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2016 15:26:27 -0700 Archived-At: Cc: rtg-bfd@ietf.org, bfd-chairs@ietf.org, draft-ietf-bfd-seamless-ip@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 22:26:27 -0000 Alia Atlas has entered the following ballot position for draft-ietf-bfd-seamless-ip-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think that these are both simple fast issues to resolve. 1) Sec 3: "This document defines only the UDP port value for the S-BFD Echo function. The source port and the procedures for the S-BFD Echo function are outside the scope of this document." Please add a reference to the S-BFD base document for defining where the procedures are found. Where, precisely, is the source port defined? It wasn't in the S-BFD base document. This seems like a hole. Can you please clarify? 2) Sec 4: " If the port is not 7784, then the packet MUST be looked up to locate a corresponding SBFDInitiator session or classical BFD session based on the value from the "your discriminator" field in the table describing BFD discriminators. " I assume that you mean that UDP source port is used to look up the appropriate receiver. If that receiver handles BFD and S-BFD packets, then the "your discriminator" field is used to identify the BFD session. PLEASE clarify that because this reads as if BFD is the only application that uses UDP. From nobody Mon May 2 15:34:44 2016 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 061FA12B01C; Mon, 2 May 2016 15:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 d_i5VmqZsLpm; Mon, 2 May 2016 15:34:40 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7640212D191; Mon, 2 May 2016 15:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9117; q=dns/txt; s=iport; t=1462228480; x=1463438080; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3v4Okgl7+aIMIJQuw7GDaLb6cRi0G7rXlWprfbl570w=; b=OC8ma4nQi8MlBN1f4jnLmUEWJIYnmXN1HxL7rny7z6sm0VYp+DRWmrHg op3kxtEX+UwPGdR65wc9RMx6YrHL9/X7emg8b3dfZlCcH77CHOXMSIqwQ iuPVPwyesT0zDPedUv9czHTUQQuvbOsSRrAX2o/DVxFzS3KNlVy8zG4io s=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DUAgDH1CdX/4cNJK1egzhTfQauFIlSg?= =?us-ascii?q?g8OgXYihW4CgTc4FAEBAQEBAQFlJ4RBAQEBAwEjVgULAgEIDgoqAgIhESUCBA4?= =?us-ascii?q?FDg2HegMKCA6qG4xADYROAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQQEhiGBdgiCT?= =?us-ascii?q?oJBgU4RAU6CTiuCKwWHd4sshEAxAYMngWdthiWBdwqBXYRNiF2HUYdfAR4BQ4I?= =?us-ascii?q?2gTVsAYdICRcEG38BAQE?= X-IronPort-AV: E=Sophos;i="5.24,569,1454976000"; d="asc'?scan'208";a="268899569" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 May 2016 22:34:39 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u42MYcd8029621 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 May 2016 22:34:39 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 18:34:38 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Mon, 2 May 2016 18:34:37 -0400 From: "Carlos Pignataro (cpignata)" To: Alia Atlas Subject: Re: Alia Atlas' Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS and COMMENT) Thread-Topic: Alia Atlas' Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS and COMMENT) Thread-Index: AQHRpLkIQl1ke+WjZEO22I9fWz1zPp+mfzmA Date: Mon, 2 May 2016 22:34:37 +0000 Message-ID: References: <20160502212434.15622.98408.idtracker@ietfa.amsl.com> In-Reply-To: <20160502212434.15622.98408.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.169.162] Content-Type: multipart/signed; boundary="Apple-Mail=_A4CB4FE7-AB56-4530-9AC5-A118624DC036"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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 May 2016 22:34:43 -0000 --Apple-Mail=_A4CB4FE7-AB56-4530-9AC5-A118624DC036 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Alia, Thanks for your review and for bringing up these issues =E2=80=94 please = see inline. > On May 2, 2016, at 5:24 PM, Alia Atlas wrote: >=20 > Alia Atlas has entered the following ballot position for > draft-ietf-bfd-seamless-base-09: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > a) In Sec 7.2.3: "If the SBFDReflector is generating a response S-BFD > control packet for a local entity that is in > service, then "state" in response BFD control packets MUST be set > to UP." > So far, it looked like the SBFDReflector only sends BFD control > packets in response to receiving such packets > from SBFDInitiators. This paragraph (not just copied) does not > clearly describe the desired behavior. If the > monitored local entity is "temporarily out of service", does the > SBFDReflector respond back to the SBFDInitiator > with 2 BFD control packets - one indicating UP (as a MUST) and then > the next indicating ADMINDOWN? Is the > SBFDReflector expected to store a list of active SBFDInitiators and > proactively send BFD control packets indicating > ADMINDOWN? Please clarify in non-trivial detail. The way in which that particular bullet in that subsection is written = can be a bit confusing. First, you are right that the SBFDReflector only sends packets in = response to S-BFD control packets from the SBFDInitiators. This is = clearly spelled out in Section 5, and in other places that explain how = the reflector is stateless. The SBFDReflector only response and does not stores a list of = SBFDInitiators to proactively send S-BFD packets (see Section 5). = Further, it does not respond with two packets. (UP and ADMINDOWN). I think this can be rewritten to better explain what happens, as = follows: OLD: o If the SBFDReflector wishes to communicate to some or all SBFDInitiators that monitored local entity is "temporarily out of service", then S-BFD control packets with "state" set to ADMINDOWN are sent to those SBFDInitiators. The SBFDInitiators, upon reception of such packets, MUST NOT conclude loss of reachability to corresponding remote entity, and MUST back off packet transmission interval for the remote entity to an interval no faster than 1 second. If the SBFDReflector is generating a response S-BFD control packet for a local entity that is in service, then "state" in response BFD control packets MUST be set to UP. NEW: o If the SBFDReflector, upon receiving an S-BFD control packet from an SBFDInitiators, wishes to communicate to those SBFDInitiators that a monitored local entity is "temporarily out = of service", then an S-BFD control packet with "state" set to = ADMINDOWN is sent in response to those SBFDInitiators. The SBFDInitiators, = upon reception of such packets, MUST NOT conclude loss of reachability to corresponding remote entity, and MUST back off packet transmission interval for the remote entity to an interval no faster than 1 second. If, on the other hand, the SBFDReflector is = generating a response S-BFD control packet for a local entity that is in service, then "state" in response BFD control packets MUST be set to UP. Is that more clear? >=20 > b) Appendix A: The looping problem is nicely defined but the text = still > discusses three potential solutions; clearly the > use of the D bit has been chosen. It would be much nicer to have the > justification in line, but for this discuss - the > unselected alternatives don't belong. >=20 Sorry I=E2=80=99m not sure I understand fully your point. Are you = suggesting we mention in the actual reason for the D-bit procedures = outside the Appendix (although the procedures for the D bit are = explained in Section 6.2, 7.2.2, 7.2.3, 7.3.2, and 7.2.2), while still = leave the Appendix as-is? If so we can do that, but want to confirm. > c) Sec 7.2.1: " S-BFD packet MUST be demultiplexed with lower layer > information > (e.g., dedicated destination UDP port, associated channel type)." > Where precisely is this defined or described? Is there an allocation > for a dedicated UDP > port for S-BFD? I don't see any normative reference to such. In > particular, since the format > for an S-BFD control packet is exactly the same as for BFD and since = only > this demultiplexing > with lower layer information is used to tell the difference between = S-BFD > and BFD packets, > this document requires more specifics. >=20 This is similar to RFC 5880 and RFC 5881. The actual S-BFD applications = specify this. For example, bfd-seamless-ip defines the UDP port. We = purposely do not want to have the specification (either explicitly or = normatively pointed to) from this document, as this is just the base = specification. >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 1) In the last paragraph of Sec 4.2: " Even when following the = separate > discriminator pool approach, > collision is still possible between one S-BFD application to another > S-BFD application, that may be using different values and algorithms > to derive S-BFD discriminator values. If the two applications are > using S-BFD for a same purpose (e.g., network reachability), then = the > colliding S-BFD discriminator value can be shared. If the two > applications are using S-BFD for a different purpose, then the > collision must be addressed. How such collisions are addressed is > outside the scope of this document." >=20 > Sec 4.1 talks about the need for the S-BFD Discriminator to be unique > within an Administrative Domain. > I don't see any details of that addressed here. What is addressed > here seems to be the case for multiple > S-BFD discriminators applying to the same node - which is = specifically > discouraged at the end of Sec 3. > Rather than simply describing the issue as "outside the scope of this > document", please either describe it > as "future work and multiple S-BFD discriminators is discouraged" or > add a reference. >=20 Good point, will do. > 2) In Sec 6.1: "bfd.SessionType:" is defined but the only possible = values > are for SBFD. Is it possible for a BFD > session to still use the same bfd structure? I don't see a value for > SessionType there; I'd expect to see at least > a value for the original BFD session and possible an undefined or > unspecified value for future proofing. >=20 >=20 Traditional BFD does not use this state variable. That=E2=80=99s why we = don=E2=80=99t need to define a value for BFD. However, future specs can = when it is relevant (e.g, using BFD for various types as opposed to = S-BFD), as for example bfd-multipoint. Please let us know your thoughts on the responses above, and we can send = out diffs. Thanks! =E2=80=94 Carlos. --Apple-Mail=_A4CB4FE7-AB56-4530-9AC5-A118624DC036 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXJ9X9AAoJEIXgpQGOZny9y2MP/iEhKqcvDnl6433JPJgxJRit l0l/t3XwTbkJ7Yi8j05LYeYaNlG5vevNmA1TkY8INh5c8kWpQnwfpCKGBLvoOOTR UjOVSHhja+6ZxOJyyMf0Qb4TtoAICd7/CIqNChdr7kUbaq/AuPs1LeKUmefqcSXQ L0BnOusK/5Xv36izskb5/sDi2G74QkfMd3qRQQ43L3srIl0L/eC4S7LJ7sGMtP5F K9P+u91/XWr+3aLcGXwg/l/YhL0EPheAEbIRYg+njOCMo3I6GgVr6DdVlrCYh9G3 UJnmWAWjtrxPMBqo99hSLCtNIyOE5+koLKfLFitOreyGGc0l48/bLhCwJDkn5mHp 34I68nANI2Aa4QgbaCUQgMnIQC9ZUnrxvjyqn61fi5kVJSKwL55RoeqrDHy0b1Fj T088wR7BrA6/52fpqSHdi4OuuRGBAn973LW8VcLVTrJaipDFib/LXR1jUpJxHcwX jrYjmpWrB6jv4h3n2aPXISoGtDA00kcU+Zq1bWGBuQNDq+7DdD3mPoSAggxtjjBa 3r8ng1XSe4iiDAjXWixiscD/3egqxQiVdo1bEL5WLyMrouWdIF4xajgGOP4vq3kj E4AZZKKCj3skcY24O3RnDjwlyZhI/4+AeHfHu/6o8ZCyaSyvd93XcyioF6QID/Fs GvlQFpd2RL+aHeT9Jo8T =kH3L -----END PGP SIGNATURE----- --Apple-Mail=_A4CB4FE7-AB56-4530-9AC5-A118624DC036-- From nobody Mon May 2 15:57:30 2016 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 5C25312D677; Mon, 2 May 2016 15:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ptFzhgiBXi6f; Mon, 2 May 2016 15:57:21 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4449312D671; Mon, 2 May 2016 15:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1545; q=dns/txt; s=iport; t=1462229841; x=1463439441; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qLb+HtPnv3qOqiTUOFCGt17X5SglcEnPvI9f+5X3ofI=; b=UxSz4B70nai9br0hey/7O2xeRBCdXptDHr7wbix5zXNxE+dh2db1SIrO W1rVpssKm5mb6sI+jhWoGEl7Od2J6WjwW9Sd/ylRwWxUg4t0/Sgr9BlG7 fCjgthZupF7O3ausX1lxJjIopGz8Cb9TzS98E0ipxFJ9eQZ/XZx52CAFM w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAgAM2ydX/5tdJa1egzhTfQauFIlSg?= =?us-ascii?q?g8BDYF2IoVuAoE3OBQBAQEBAQEBZSeEQQEBAQQ6PwwEAgEIDgMDAQIfECERHQg?= =?us-ascii?q?CBAENBYgVAxIOtlcNhE4BAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYhhEyCQYFOE?= =?us-ascii?q?QFOhSQBBId3iyyEQDEBhXuGJYF3gWeETYhdh1GHXwEeAQFCgjaBNWwBh1E2fwE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.24,569,1454976000"; d="scan'208";a="268736682" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2016 22:57:20 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u42MvKqq018635 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 May 2016 22:57:20 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 18:57:19 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Mon, 2 May 2016 18:57:19 -0400 From: "Carlos Pignataro (cpignata)" To: Alia Atlas , The IESG Subject: Re: Alia Atlas' No Objection on draft-ietf-bfd-seamless-use-case-06: (with COMMENT) Thread-Topic: Alia Atlas' No Objection on draft-ietf-bfd-seamless-use-case-06: (with COMMENT) Thread-Index: AQHRpL9c1LGKt3tnXk+fxOridbV1Gp+mQnSA Date: Mon, 2 May 2016 22:57:19 +0000 Message-ID: References: <20160502220953.15818.52059.idtracker@ietfa.amsl.com> In-Reply-To: <20160502220953.15818.52059.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.169.162] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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 May 2016 22:57:23 -0000 Thanks, Alia! Will add a pointer. -----Original Message----- From: Alia Atlas Date: Monday, May 2, 2016 at 6:09 PM To: The IESG Cc: "draft-ietf-bfd-seamless-use-case@ietf.org" , Alvaro Retana , "bfd-chairs@ietf.org" , Jeff Haas , "rtg-bfd@ietf.org" Subject: Alia Atlas' No Objection on draft-ietf-bfd-seamless-use-case-06: (with COMMENT) >Alia Atlas has entered the following ballot position for >draft-ietf-bfd-seamless-use-case-06: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-use-case/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >1) Sec 3.7: This section describes BFD Fault Isolation. It isn't clear >to me that the S-BFD base spec has addressed this case at all. More >clarification would be nice - either indicating that this use-case wasn't >handled or having a small pointer to how it was. > > From nobody Mon May 2 16:22:34 2016 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 B10BF12D67B; Mon, 2 May 2016 16:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 864kOqBcMPLn; Mon, 2 May 2016 16:22:31 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1106B12D111; Mon, 2 May 2016 16:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5069; q=dns/txt; s=iport; t=1462231351; x=1463440951; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zfy5nBjlGR2e7ZVXdztBQ0K7B3FU6JQKX/qzO/TqCyE=; b=ecMO2D3/M/QXaPesghaQQijQx0o/AmYDpf4mDN2qEmUSLfXgftS8O8ZF 26ZCNUkWHgXxKnfTKpE+FWfz/9D6N9o2sLhBiDKYqMNJKYubzIK4ePJXo NPEorTgDlv1aJ6TXKkOuxBc++sN2uuynUMuoNakLYhEXeYurcFFlnS6IN U=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DUAgB14CdX/40NJK1UCoM4U30GrhSJU?= =?us-ascii?q?oIPDoF2IoVuAoE3OBQBAQEBAQEBZSeEQQEBAQMBI1YFCwIBCA4KKgICIRElAgQ?= =?us-ascii?q?OBQ6IBwMKCA6qCow+DYROAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQQEhiGBdgiCT?= =?us-ascii?q?oJBgU4GCwFOgk4rgisFh3ePbDEBgyeBZ22GJYF3gWeETYhdh1GHXwEeAUODa2w?= =?us-ascii?q?Bh0oHFwcYfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,569,1454976000"; d="asc'?scan'208";a="268096778" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 May 2016 23:22:30 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u42NMTcp023281 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 May 2016 23:22:30 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 19:22:29 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Mon, 2 May 2016 19:22:28 -0400 From: "Carlos Pignataro (cpignata)" To: Alia Atlas Subject: Re: Alia Atlas' Discuss on draft-ietf-bfd-seamless-ip-04: (with DISCUSS) Thread-Topic: Alia Atlas' Discuss on draft-ietf-bfd-seamless-ip-04: (with DISCUSS) Thread-Index: AQHRpMGsMRcZflh1j0ieWahk11MJYJ+mjIiA Date: Mon, 2 May 2016 23:22:28 +0000 Message-ID: <52C94004-5548-4701-AA81-EBF8D5EC1BDD@cisco.com> References: <20160502222627.15846.1446.idtracker@ietfa.amsl.com> In-Reply-To: <20160502222627.15846.1446.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.169.162] Content-Type: multipart/signed; boundary="Apple-Mail=_553E4443-2F42-4011-AA25-417653C74BEC"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-bfd-seamless-ip@ietf.org" , The IESG , "rtg-bfd@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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 May 2016 23:22:32 -0000 --Apple-Mail=_553E4443-2F42-4011-AA25-417653C74BEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alia, Thanks for the review and for these! Please see inline. > On May 2, 2016, at 6:26 PM, Alia Atlas wrote: >=20 > Alia Atlas has entered the following ballot position for > draft-ietf-bfd-seamless-ip-04: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I think that these are both simple fast issues to resolve. >=20 > 1) Sec 3: "This document defines only the UDP port value > for the S-BFD Echo function. The source port and the procedures for > the S-BFD Echo function are outside the scope of this document." > Please add a reference to the S-BFD base document for defining where = the > procedures are found. >=20 > Where, precisely, is the source port defined? It wasn't in the S-BFD > base > document. This seems like a hole. Can you please clarify? This is done exactly as in RFC 5881, purposefully. I can add a = clarifying sentence like: OLD: This document defines only the UDP port value for the S-BFD Echo function. The source port and the procedures for the S-BFD Echo function are outside the scope of this document. NEW: S-BFD echo follows the BFD echo definitions of [RFC 5881]. Consequently, this document defines only the UDP port value for the S-BFD Echo function; the source port and the procedures for the S-BFD Echo function are outside the scope of this document. >=20 > 2) Sec 4: " If the port is not 7784, then the packet MUST be looked = up > to locate > a corresponding SBFDInitiator session or classical BFD session based > on the value from the "your discriminator" field in the table > describing BFD discriminators. " >=20 > I assume that you mean that UDP source port is used to look up the > appropriate receiver. > If that receiver handles BFD and S-BFD packets, then the "your > discriminator" field is used > to identify the BFD session. PLEASE clarify that because this reads = as > if BFD is the only > application that uses UDP. >=20 Indeed, very much so. I suggest: OLD: If the port is not 7784, then the packet MUST be looked up to locate a corresponding SBFDInitiator session or classical BFD session based on the value from the "your discriminator" field in the table describing BFD discriminators. If the located session is an SBFDInitiator, then the destination IP address of the packet SHOULD be validated to be for self. If the packet is a classical BFD session, then the procedures from [RFC5880] apply. NEW: If the port is not 7784, but the packet is demultiplexed to be for an SBFDInitiator, then the packet MUST be looked up to locate a corresponding SBFDInitiator session based on the value from the "your discriminator" field in the table describing BFD discriminators. In that case, then the destination IP address of the packet SHOULD be validated to be for itself. If the packet demultiplexes to a = classical BFD session, then the procedures from [RFC5880] apply. Would that work? Thanks, =E2=80=94 Carlos. >=20 >=20 >=20 --Apple-Mail=_553E4443-2F42-4011-AA25-417653C74BEC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXJ+E0AAoJEIXgpQGOZny9bqEP/iqGBqHKsjgI7rwS5xVRKCkr AVUyDdt3dcpiyJFvA0ImooLYSlllUgPintLDmNZE6Xm8OGX4E+prL1gH6wluPAH8 kSyYxlRDfaWPLyXxK0JvXsGMPf9W8G/BQjOoQKDaWakzE6Wv73L3N5wsO65m/BgH /K+mex+/VqioX5zshqlLcZj/8HX7Xj57+9Ms0qpqoigX39JppWEtqfUI6a7iC1QO uSlezQawV3vXMg4maXMWE4+yzWjk2uFS2b/Kt31JSIQXeOLEek6T5Z6+tWbcuRVY sj+Bf2mODBfqdt+9y+jRe2Vso5VYhPXxbPCN1/d1rgRXwPWtdxBXaQKy6mk6RrFF JwG6gRdbr+Io5xAsa8hupbQsc6/sGcMupVTKoEOpQylLdJZ0QZqlZe1Z8nYYmAUj FuhIY+HHQtX/3QyPTRhPO+1cO2t37po2ToytCRr8KOjH1ukbSD4j1glPDNBi01fK PNC30e/Bur3IhJUtzqVs6IGjN46DC0noFHb0lPJZ94d3ozj88MODGR5rjcmnsiH7 a3/OHYYZejLSt0C57hIVMtdpXjCmIYBAkUj0HqxZ3zdWPxNWgQKq8N1Lu6/XQLT9 yYYeh1PIyCBcbVJqWzw3abrcpr0G0EcQ49x+AJFzIShnYZWGk/BZoeayjtu8u1re v0AcODAkU6/JchwczEmn =QzeM -----END PGP SIGNATURE----- --Apple-Mail=_553E4443-2F42-4011-AA25-417653C74BEC-- From nobody Mon May 2 16:48:27 2016 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 EAB8E12D128 for ; Mon, 2 May 2016 16:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ionosnetworks-com.20150623.gappssmtp.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 4dtlE-fzjSeK for ; Mon, 2 May 2016 16:48:24 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 9C90212B004 for ; Mon, 2 May 2016 16:48:24 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id o133so4699573vka.0 for ; Mon, 02 May 2016 16:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ionosnetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=0f1113fNVKuhzOOMgRYH65ADUeeu75dwmORREAhsTVE=; b=AH6eynpozLykQXZ4+x5I3siPUDpWIVEWBMUsvwfgGfj3zwwEYhiGdo4D5+/bNGgPkt oAqubEwp9O1KT4cqDEzXe3wvmidxjURBwFopjABszLspVCPUHWqGAD8BqxyjzDjN4ljy ymL5XnbherdEErXs+UyKILrvt8/Dj7FWivqbzZ488BC/a6t6CZYlRrpi1TK+i5DEMCho Q0gkebB8X6n/X8dexwNJGgZvbv/n2GKXDF60ciiYgjTyMAaP7z7QWrjw4kHrRNrx2DTm oaM91HxwVKd9B/teddFW+TQablIqej9FkIVjwQL/BGcOOVRMeQnpNM6ipEf6Bk6R+Ut6 Js/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=0f1113fNVKuhzOOMgRYH65ADUeeu75dwmORREAhsTVE=; b=kynGYYNwRJJ8fUPDXhH/h46T+T2Sgy0UkH/ke7GKZz0hyWEzyvCrAQ+4WL3utCY7Vl mTeUYfea+RefcmORUMHz1nAAqkoQUfzbH3Q46rByo0hCp9xd5l6RSO1GtiH28tTE2BBF jgTC93lNosq1JIcmmlsQc1qX2G+UOf9/Szp551zWmi1drpMlnmIz+s+3CKwSm2/3elbT kqocX+oTiC2rMYz4F6+EgaxDrm4R2N+VvH/gzWOzLTQot4+oSqunCSInTrWJTsMYGmjo 0tfnoneSoDiHExpA0KsUQhd3oH0vcJVGAt6mXQwHdsq3ED70p92DrWEJqNkXQkrTSbB4 YVQg== X-Gm-Message-State: AOPr4FXD3wCilNmYy7QI/6xA7+2alH3Z1IB5cTah81hG5Bz37vXrDuAMNiE5JFXYSCj3fh4ehKQMN5ht6p1WjA== MIME-Version: 1.0 X-Received: by 10.31.10.132 with SMTP id 126mr1123899vkk.147.1462232903747; Mon, 02 May 2016 16:48:23 -0700 (PDT) Received: by 10.31.32.197 with HTTP; Mon, 2 May 2016 16:48:23 -0700 (PDT) In-Reply-To: <20160502193624.15732.51479.idtracker@ietfa.amsl.com> References: <20160502193624.15732.51479.idtracker@ietfa.amsl.com> Date: Tue, 3 May 2016 05:18:23 +0530 Message-ID: Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS) From: Manav Bhatia To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=001a1145014ccea7f90531e4a019 Archived-At: Cc: The IESG , rtg-bfd@ietf.org, draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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 May 2016 23:48:27 -0000 --001a1145014ccea7f90531e4a019 Content-Type: text/plain; charset=UTF-8 Hi Kathleen, DISCUSS: > ---------------------------------------------------------------------- > > This should be pretty easy to address. In the security consideration > section, the following recommendation appears: > > o SBFDReflector MUST NOT look at the crypto sequence number before > accepting the packet. > > Could you please add text to say what happens (what attacks are possible) > if this is looked at? There is nothing to stop the crypt sequence number > from being looked at, right? Is there a way to actually prevent that? > > SBFD is state-less. The SBFDReflector is NOT maintaining any BFD peer state, and is thus incapable of doing the crypto-sequence checks. It has no idea of last sequence number that it had seen from a BFD peer, and hence CANNOT compare the new sequence number. Its for this reason that we mandate that the reflectors MUST NOT look at the sequence numbers. We cant prevent a peer from looking at the sequence number -- thats an implementation specific issue. The implementation is violating the standard. Not sure what we can do to prevent that. Does this help? Cheers, Manav --001a1145014ccea7f90531e4a019 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Kathleen,

DISCUSS:
----------------------------------------------------------------------

This should be pretty easy to address.=C2=A0 In the security consideration<= br> section, the following recommendation appears:

=C2=A0o=C2=A0 SBFDReflector MUST NOT look at the crypto sequence number bef= ore
=C2=A0 =C2=A0 =C2=A0 accepting the packet.

Could you please add text to say what happens (what attacks are possible) if this is looked at?=C2=A0 There is nothing to stop the crypt sequence num= ber
from being looked at, right?=C2=A0 Is there a way to actually prevent that?=


SBFD is state-less. The=C2=A0SBFDRefle= ctor=C2=A0is NOT maintaining any BFD peer state, and is thus incapable of d= oing the crypto-sequence checks. It has no idea of last sequence number tha= t it had seen from a BFD peer, and hence CANNOT compare the new sequence nu= mber. Its for this reason that we mandate that the reflectors MUST NOT look= at the sequence numbers.

We cant prevent a peer f= rom looking at the sequence number -- thats an implementation specific issu= e. The implementation is violating the standard. Not sure what we can do to= prevent that.

Does this help?

Cheers, Manav

--001a1145014ccea7f90531e4a019-- From nobody Mon May 2 16:52:35 2016 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 DA32612D533; Mon, 2 May 2016 16:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 4a1kip66QEgW; Mon, 2 May 2016 16:52:32 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 ADBB212D538; Mon, 2 May 2016 16:52:31 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id t10so4399761ywa.0; Mon, 02 May 2016 16:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=zWp3ZDWcIhNGBUhL1lqGh0ZZ5swwZBJ0hkZlF3fdCds=; b=J53t6kjt7BLHkfa8o49EsJsLZDrjMVBgEgKA2nCHH/G6CmRNbv8MwcIYdWXh7Vl1Ea TdyIHgiFRtH+0qys2As4hURCn4UON/214IHws9b8CbVGm7Ya8Rk4gLaSb0o6gq9RimXm JFqG0ntsPHlsG+n2XJQbvqMaLjmlTSKEbYlHCUEWRAvUzguVZDY4piMxrmUx/563iC/5 erPvMS4XiILv/bEgtRsqARed/ILWiN+XN5ngWTBpaj18BvdHlI7y4nX1Kban5l9Yu2hO WuOcHtil56p4tC6b0xWRdprR8Nu2CX8mxRt95/jmm2/Et1IAEjXpQV01T/nn7Av/KdPP 81Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=zWp3ZDWcIhNGBUhL1lqGh0ZZ5swwZBJ0hkZlF3fdCds=; b=GN+cv9D9+KAH3NbxdJwpy5mR0+frmBz5Txdar4qI6HUN1NaXuDsflIfdvq8cCsLqtr xqa2aNcDeGrmm7vIdYjahCMBONHLilLJcpqvsPCAESUIjv5AfrHEro8HZxAFZge0K6Ei S4t9gkHHsr9f4EhKoMEJbbj8tSlzn9AnvzD9uPIijsBzJQ65F2UIT/IaGDBciLcYZPwd iBfjdtvJ+fNX0tx55Pf8YxRT0MrdSr3Zr7CjMZwFfZoKz3Ip5kibIqePQl168KSlwiFV rxNf28bkcfuv4W1UKP6ixy32nkj+ozfG6VtxaAZVsYxIvBTYlf56bvPM2LD2E7NilEcM OkpQ== X-Gm-Message-State: AOPr4FUeAtb14xP4y1M9iXExR4oDI41r5wSQlxhXLebrOetCsYBIqGQbJhs+scgbVjcOEqwE9reFcHN2bbuzcw== MIME-Version: 1.0 X-Received: by 10.37.208.132 with SMTP id h126mr18909283ybg.185.1462233150981; Mon, 02 May 2016 16:52:30 -0700 (PDT) Received: by 10.13.216.129 with HTTP; Mon, 2 May 2016 16:52:30 -0700 (PDT) Date: Tue, 3 May 2016 05:22:30 +0530 Message-ID: Subject: Replace "seamless" with "stateless" From: Manav Bhatia To: draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org, "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c05601a8b0b370531e4af18 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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 May 2016 23:52:34 -0000 --94eb2c05601a8b0b370531e4af18 Content-Type: text/plain; charset=UTF-8 Hi, Does it make sense to change "seamless BFD" with "stateless BFD" in the documents? Its very convoluted to explain whats "seamless" about S-BFD. We called it "seamless" because it was simple and largely stateless. Any suggestions? Cheers, Manav --94eb2c05601a8b0b370531e4af18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Does it make sense to change "= seamless BFD" with "stateless BFD" in the documents? Its ver= y convoluted to explain whats "seamless" about S-BFD.
<= br>
We called it "seamless" because it was simple and l= argely stateless.=C2=A0

Any suggestions?

Cheers, Manav
--94eb2c05601a8b0b370531e4af18-- From nobody Mon May 2 17:04:41 2016 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 2A5F412D0AB; Mon, 2 May 2016 17:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 XeMlivKXR2on; Mon, 2 May 2016 17:04:33 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2919B12B04F; Mon, 2 May 2016 17:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6904; q=dns/txt; s=iport; t=1462233873; x=1463443473; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Q2tvWY1q/e5eN3+fGoFH6t7tG7GWKRCDhdDhDd4s6q8=; b=dAMbdZyj12znzCIdglZMIJARwm+FRrApdITDQpo4zNlB1R7slgcyL2XS I5dK3rEwycVjlctCufXgdp4bRD9paflzDbdBhhRVCd1EQllqCn49sFhtD uoAMajMXyQyq3cQme1I7S3N/ssletblDEuMsIj/5x355gxH4P3jMfbcM2 4=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYAgDY6SdX/4cNJK1egziBUAa1AoJkg?= =?us-ascii?q?g8OgXaGEAKBNzgUAQEBAQEBAWUnhEEBAQEDASNWBQsCAQgYKgICMiUCBA4FDog?= =?us-ascii?q?UCKoVkR0BAQEBAQEBAQEBAQEBAQEBAQEBAQENCIYhgXYIgk6HPSuCKwWHd5AdA?= =?us-ascii?q?YMngWeJCYFnhE2IXY8wAR4BQ4I2gTVsiAh/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,570,1454976000"; d="asc'?scan'208,217";a="98362183" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 May 2016 00:04:32 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4304VXq025548 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 00:04:32 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 20:04:31 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Mon, 2 May 2016 20:04:31 -0400 From: "Carlos Pignataro (cpignata)" To: Manav Bhatia Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS) Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS) Thread-Index: AQHRpKnri43BgFjE1Em49WT01UFDj5+mk/SAgAAEgAA= Date: Tue, 3 May 2016 00:04:30 +0000 Message-ID: References: <20160502193624.15732.51479.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.169.162] Content-Type: multipart/signed; boundary="Apple-Mail=_D47428E6-4CF0-46A6-A72C-26169D087A6F"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Kathleen Moriarty , The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 00:04:35 -0000 --Apple-Mail=_D47428E6-4CF0-46A6-A72C-26169D087A6F Content-Type: multipart/alternative; boundary="Apple-Mail=_44CDE263-BE02-4BD0-9D91-37047D285EFD" --Apple-Mail=_44CDE263-BE02-4BD0-9D91-37047D285EFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Kathleen, > On May 2, 2016, at 7:48 PM, Manav Bhatia = wrote: >=20 > Hi Kathleen, >=20 > DISCUSS: > ---------------------------------------------------------------------- >=20 > This should be pretty easy to address. In the security consideration > section, the following recommendation appears: >=20 > o SBFDReflector MUST NOT look at the crypto sequence number before > accepting the packet. >=20 > Could you please add text to say what happens (what attacks are = possible) > if this is looked at? There is nothing to stop the crypt sequence = number > from being looked at, right? Is there a way to actually prevent that? >=20 >=20 > SBFD is state-less. The SBFDReflector is NOT maintaining any BFD peer = state, and is thus incapable of doing the crypto-sequence checks. It has = no idea of last sequence number that it had seen from a BFD peer, and = hence CANNOT compare the new sequence number. Its for this reason that = we mandate that the reflectors MUST NOT look at the sequence numbers. >=20 Further to this, the SBFDReflector can be receiving S-BFD packets from = multiple SBFDInitiators. Hence, the authentications can be used from BFD = but not the sequence numbers. > We cant prevent a peer from looking at the sequence number -- thats an = implementation specific issue. The implementation is violating the = standard. Not sure what we can do to prevent that. >=20 > Does this help? >=20 We could also explain the rational behind this requirement a bit better. = Would that help? Thanks, =E2=80=94 Carlos. > Cheers, Manav >=20 --Apple-Mail=_44CDE263-BE02-4BD0-9D91-37047D285EFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Kathleen,

On May 2, 2016, at 7:48 PM, = Manav Bhatia <manav@ionosnetworks.com> wrote:

Hi Kathleen,

DISCUSS:
= ----------------------------------------------------------------------

This should be pretty easy to address.  In the security = consideration
section, the following recommendation appears:

 o  SBFDReflector MUST NOT look at the crypto sequence number = before
      accepting the packet.

Could you please add text to say what happens (what attacks are = possible)
if this is looked at?  There is nothing to stop the crypt sequence = number
from being looked at, right?  Is there a way to actually prevent = that?


SBFD is state-less. The SBFDReflector is NOT = maintaining any BFD peer state, and is thus incapable of doing the = crypto-sequence checks. It has no idea of last sequence number that it = had seen from a BFD peer, and hence CANNOT compare the new sequence = number. Its for this reason that we mandate that the reflectors MUST NOT = look at the sequence numbers.


Further to this, the SBFDReflector can be = receiving S-BFD packets from multiple SBFDInitiators. Hence, the = authentications can be used from BFD but not the sequence = numbers.

We cant = prevent a peer from looking at the sequence number -- thats an = implementation specific issue. The implementation is violating the = standard. Not sure what we can do to prevent that.

Does this = help?


We could also explain the rational behind this = requirement a bit better. Would that help?

Thanks,

=E2=80=94= Carlos.

Cheers, = Manav


= --Apple-Mail=_44CDE263-BE02-4BD0-9D91-37047D285EFD-- --Apple-Mail=_D47428E6-4CF0-46A6-A72C-26169D087A6F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXJ+sOAAoJEIXgpQGOZny9fg8P/1J4LuMpTh4A+db9GpBUyDKR ooVhtkDw8OykYHVIcIkpPVSPImguWvfJvVg1a+IESgOPGjE67Aur17oCqzkXtOOh dJk6+/LL+gfbbndmwAPukpYpN/fIWC4sf+J9G3UUbPsntkGb+M76f9ZBZo/V2q9u Sx7iO/eRY6C2cHNu08IRgP6yaTVMqw24YvCRhzav6+8XW9DTt9xrUjqUCWV7WMsV 3z/OdMsf/hnu2MthpS55SSs/zlB2WYGvCMUpVDYJ1g6RW1rxCNfQ8EZB/Jev7h2y fnG45jG1wsHpO4s6IbgonEsi7l/wrmuAo8aaR27xWwStFu62rBjVB15Rwy5oxxpl gfnkjV8AGCglCKTxaCRKdJTTOLoTTnAdzwVMc8CZmv9tfYisBkKymQ+HXXtZsr63 DCQEM9Od1XPPACuf6knRqpYY5gpyltmjywVjbOJWfwdyzb8xmgYiUkbhlgQX2FjM MFmqyZEsW/rq88flHm16fOFT7oWhvULN9vBE8ZXLEKTbbyhFDeYboavfFUpF9mUj 5OLwJ+rjPKbcc2VgwMHAAVAu+r+xfCAxmnDi19Pq+Es81qRMrFOfB7YPUJsXNbFA 8iUZBLPSChcRZh92gOWRuBbMCThXekJQ5Hfia0jUPJGFfYje4gOlD7DstICNAjfE kzo1wIO3V4C/J/KmjdOC =rVU8 -----END PGP SIGNATURE----- --Apple-Mail=_D47428E6-4CF0-46A6-A72C-26169D087A6F-- From nobody Mon May 2 17:16:07 2016 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 615AA12D53B; Mon, 2 May 2016 17:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Ngvf5jIb8aP3; Mon, 2 May 2016 17:16:04 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (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 2BBEB12D533; Mon, 2 May 2016 17:16:04 -0700 (PDT) Received: by mail-pa0-x235.google.com with SMTP id r5so2077319pag.1; Mon, 02 May 2016 17:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dhB7wf40vrrNFeKMQgWFhlh65Nn+0XjqBIzq1NgYJaI=; b=x1KXVxHtDVTGu703pTQmIM3n2jcjj8ZLLl3WtNOIHnnyneC18c35/jb38s+YSoS4+I hS7l05lGTMzQR9EFDHn2BcJpnYWbrUx0nA06PpyaIsI3CWcY9F5XcNaHfEie+x+hHSKU vk5GRo2yi7RfLP5xPdbVur3hXmBlT3Al/NLUzfd5pEMSgHioMHuUIDqK+cSYfGG4C7OQ H1wTkYeDf4XMTHghyn0WSoDu3JJX0hEGUE990yL2AfUaqaByfNQvTHQ9dF4J7B5tD2LJ 8Or+Pko5zHvjxal5Wl5MOwXjsIhNm+c9OMgrFqUK/a3kWi5ApgnYHVw+yPDynbItYrHi iaTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dhB7wf40vrrNFeKMQgWFhlh65Nn+0XjqBIzq1NgYJaI=; b=k4e7+cP3N55d4PIOwfwsjDprY8y6/a/Mbu/hPii77b1PmjHlOBya0M6agx8XsEgcXa clDvTUYU06IyA+74bQMtZvisTa8m0dyEgBOI8DnybJeghpwporlg8dr/ZRg+T+HgxLLH Nu3syd1eyTqukiAqBcTJQ93g2X8WXqdkF5zwftAZf96QCkXcKTKRJxAWc2s3R2etDAha ChZ0eitpZ9ztlQh+9IXEbhIt8qr0vworGG0R5RgAypvajMgnlUM7Ls/AUM5JV2Gudg3E JJ5cpBCPKB9Xs3Ec6YOqMxzYUlhFOr5hhgk5syvZEq2jsT9VR6tJxpYxIDITP5B+mMB5 K8gg== X-Gm-Message-State: AOPr4FUjZg+6Vd8kLpqcNVrwIiOlia9iTrRSgmS/rk+4ovVNTGsd+JKUtkVwuPT9o95P/Q== X-Received: by 10.66.25.133 with SMTP id c5mr55279403pag.104.1462234563876; Mon, 02 May 2016 17:16:03 -0700 (PDT) Received: from [10.60.161.163] ([166.170.39.227]) by smtp.gmail.com with ESMTPSA id l88sm585130pfb.79.2016.05.02.17.16.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2016 17:16:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Replace "seamless" with "stateless" From: Sam Aldrin X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Mon, 2 May 2016 17:16:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Manav Bhatia Archived-At: Cc: "rtg-bfd@ietf.org" , draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 00:16:06 -0000 Think there was some discussion during the extension of the charter for this= work item. Not sure what the conclusion was exactly. IIRC, we found the coo= l term 'seamless' and tried to fit in SBFD work into that definition, rather= than finding a term fitting the definition. Not sure if stateless is complete enough, but I have no opinion either way. O= n the contrary, someone asked if S means SDN :D Sam Sent from my iPhone > On May 2, 2016, at 4:52 PM, Manav Bhatia wrote: >=20 > Hi, >=20 > Does it make sense to change "seamless BFD" with "stateless BFD" in the do= cuments? Its very convoluted to explain whats "seamless" about S-BFD. >=20 > We called it "seamless" because it was simple and largely stateless.=20 >=20 > Any suggestions? >=20 > Cheers, Manav From nobody Mon May 2 17:34:29 2016 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 00F7F12D686; Mon, 2 May 2016 17:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 jrcXZejHcbYC; Mon, 2 May 2016 17:34:20 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (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 BA25212D684; Mon, 2 May 2016 17:34:20 -0700 (PDT) Received: by mail-qg0-x231.google.com with SMTP id 90so2079707qgz.1; Mon, 02 May 2016 17:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HBPE7sQTs9IxXgFlO4nBReXaO84Qw+RJBDLYhp5C488=; b=KzPYXXqWRRtvmZdQYU+hV+gI5JTDjHcPjMaDM+sZbgtjzMJguLKOaBA3hj2fNx6uqQ RO3Gulat5ChqBWG0s19RU7Y5sjr4MojL5E/+AKQq1ROkhgujn6NgeDkeDb9l3I2RCrb9 TsAg1IVbg/Ugt6LP634AhN1LE3y80NZdNIVBs6Dgt7vkQbu6PvsqaN4XvmD2GGt9xtQ0 UPuA8wyTrEUP1Z9Pgd+4GLx5mochl3K1kSS7yqg7MNAZj3NMDilJBiA+SHZawf1KQbe4 9AQIWrZ60mjhqmFJvdQOPU7hMtj72WEEGrZf4xG+6wAZR0W95FRqIQXJf2dnRLwfMbG/ LyqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HBPE7sQTs9IxXgFlO4nBReXaO84Qw+RJBDLYhp5C488=; b=V/VsAl5JFweYLBeDCaUc+pBGAneLUmGyNSEz93UDDU/exBJjiiFxF1oifa3LibHjEX 1PjMMnGQyjvHXcRyqjqkLongp8NGFyoh/xu1ceBMv/fPqHKeueF/Ja4jYwFKluG5Qg4i IB87AX664YU9MAldtQxmKtnkSoFzxA3wv/fKzbo7YY221CsBJCn2Tk2Rg8FyID3ZTMJ/ BGRHNW88kaFbn17/jRkDD8pgDSrWfO+pfgJEchXAVBxWftQ87B3Twm77DU/+BSExfacO 5yHRl+nGhMTsIRMJbG4kQMx0Kj91HIwTDKFsXBFICMkm7e3wVhvmkk7IXOPv6Pm/5HWN Kd9w== X-Gm-Message-State: AOPr4FUDIS1sj9WLTCL7neQaAXigL5oL2L9/s7vp9oQkW87lOPJtuX+dxa3HgzFF/n04Zg== X-Received: by 10.140.98.117 with SMTP id n108mr34607076qge.16.1462235659945; Mon, 02 May 2016 17:34:19 -0700 (PDT) Received: from [192.168.1.3] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id x6sm295089qka.16.2016.05.02.17.34.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2016 17:34:19 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-2F5D19E3-955D-4417-95E2-9CBD8A654477 Mime-Version: 1.0 (1.0) Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (12H143) In-Reply-To: Date: Mon, 2 May 2016 20:34:18 -0400 Content-Transfer-Encoding: 7bit Message-Id: <0FD64F08-19D5-4CD2-A1A9-FD9F505206B3@gmail.com> References: <20160502193624.15732.51479.idtracker@ietfa.amsl.com> To: "Carlos Pignataro (cpignata)" Archived-At: Cc: Manav Bhatia , The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 00:34:23 -0000 --Apple-Mail-2F5D19E3-955D-4417-95E2-9CBD8A654477 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Thanks for the quick responses. See inline=20 Sent from my iPhone > On May 2, 2016, at 8:04 PM, Carlos Pignataro (cpignata) wrote: >=20 > Kathleen, >=20 >> On May 2, 2016, at 7:48 PM, Manav Bhatia wrote:= >>=20 >> Hi Kathleen, >>=20 >>> DISCUSS: >>> ---------------------------------------------------------------------- >>>=20 >>> This should be pretty easy to address. In the security consideration >>> section, the following recommendation appears: >>>=20 >>> o SBFDReflector MUST NOT look at the crypto sequence number before >>> accepting the packet. >>>=20 >>> Could you please add text to say what happens (what attacks are possible= ) >>> if this is looked at? There is nothing to stop the crypt sequence numbe= r >>> from being looked at, right? Is there a way to actually prevent that? >>=20 >> SBFD is state-less. The SBFDReflector is NOT maintaining any BFD peer sta= te, and is thus incapable of doing the crypto-sequence checks. It has no ide= a of last sequence number that it had seen from a BFD peer, and hence CANNOT= compare the new sequence number. Its for this reason that we mandate that t= he reflectors MUST NOT look at the sequence numbers. >=20 > Further to this, the SBFDReflector can be receiving S-BFD packets from mul= tiple SBFDInitiators. Hence, the authentications can be used from BFD but no= t the sequence numbers. >=20 >> We cant prevent a peer from looking at the sequence number -- thats an im= plementation specific issue. The implementation is violating the standard. N= ot sure what we can do to prevent that. >>=20 >> Does this help? >=20 > We could also explain the rational behind this requirement a bit better. W= ould that help? >=20 Yes, that would be helpful. I'm glad to see that this is not an issue. Thanks, Kathleen=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >> Cheers, Manav >=20 --Apple-Mail-2F5D19E3-955D-4417-95E2-9CBD8A654477 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thanks fo= r the quick responses.  See inline 

Sent from my iPhone

On May 2, 2016, at 8:04 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:

Kathleen,

=
On May 2, 2016, at 7:48= PM, Manav Bhatia <= manav@ionosnetworks.com> wrote:

Hi Kathleen,
DISCUSS:
----------------------------------------------------------------------

This should be pretty easy to address.  In the security consideration section, the following recommendation appears:

 o  SBFDReflector MUST NOT look at the crypto sequence number befo= re
      accepting the packet.

Could you please add text to say what happens (what attacks are possible) if this is looked at?  There is nothing to stop the crypt sequence numb= er
from being looked at, right?  Is there a way to actually prevent that?<= br class=3D"">

SBFD is state-less. The SBFDReflector is NOT maintaining any BFD= peer state, and is thus incapable of doing the crypto-sequence checks. It h= as no idea of last sequence number that it had seen from a BFD peer, and hen= ce CANNOT compare the new sequence number. Its for this reason that we manda= te that the reflectors MUST NOT look at the sequence numbers.

=
Further to this, the SBFDReflector can be rec= eiving S-BFD packets from multiple SBFDInitiators. Hence, the authentic= ations can be used from BFD but not the sequence numbers.

We cant prevent a peer from looking at the sequence number -= - thats an implementation specific issue. The implementation is violating th= e standard. Not sure what we can do to prevent that.
Does this help?


We could also explain the rational behind this requirement a b= it better. Would that help?

Yes, that would be helpful.  I'm glad to see that this is= not an issue.

Thanks,
Kathleen 

Thanks,
<= div>
=E2=80=94 Carlos.

Cheers, Manav


= --Apple-Mail-2F5D19E3-955D-4417-95E2-9CBD8A654477-- From nobody Mon May 2 17:49:28 2016 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 E0B1912D53C; Mon, 2 May 2016 17:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 QAwGLiANgMdX; Mon, 2 May 2016 17:49:24 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6D812D6AB; Mon, 2 May 2016 17:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13903; q=dns/txt; s=iport; t=1462236564; x=1463446164; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Y7tHPp0BQWObnE8RiAY7UbyDXm3T0ZCniabeSLUUGYE=; b=TZmYez+mgPBz22SPsfzcmOm2xuWFwoZiye2IHc6KX/6TewbVMLtQoDp8 BZwGxWOsaKbQ4+EGnyfJcKnnbaw7YDVxn5iRzXF3x6wB7ycYGpCHNVWgn DhEViUGyMf/nZpJt8+8tWP9DWwDnZN2ZDQuaKyKL6U3Qc3Q40ULcKpM8d Q=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6AgCf9CdX/5BdJa1egmxMgVAGrhiGb?= =?us-ascii?q?oRzDoF2hhACgTc4FAEBAQEBAQFlHAuEQQEBAQMBI1YFCwIBCBgnAwICIREUEQI?= =?us-ascii?q?EDgUOiAcDCgiqA4xDDYROAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiGIYF2CIJOg?= =?us-ascii?q?kGEfCuCKwWHd49sMQGDJ4FnhxKBd4FnhE2IXYdRh18BHgFDgjaBNWwBhzx/AQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.24,570,1454976000"; d="asc'?scan'208,217";a="103726276" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2016 00:49:23 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u430nMri030851 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 00:49:23 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 20:49:22 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Mon, 2 May 2016 20:49:21 -0400 From: "Carlos Pignataro (cpignata)" To: "Kathleen.moriarty.ietf@gmail.com" Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS) Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS) Thread-Index: AQHRpKnri43BgFjE1Em49WT01UFDj5+mk/SAgAAEgACAAAhUAIAABDMA Date: Tue, 3 May 2016 00:49:21 +0000 Message-ID: References: <20160502193624.15732.51479.idtracker@ietfa.amsl.com> <0FD64F08-19D5-4CD2-A1A9-FD9F505206B3@gmail.com> In-Reply-To: <0FD64F08-19D5-4CD2-A1A9-FD9F505206B3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.169.162] Content-Type: multipart/signed; boundary="Apple-Mail=_EE68E6CD-DECE-4296-9473-674EB6E10450"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Manav Bhatia , The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 00:49:27 -0000 --Apple-Mail=_EE68E6CD-DECE-4296-9473-674EB6E10450 Content-Type: multipart/alternative; boundary="Apple-Mail=_BCED2EA2-2819-4C5D-BE96-1C809D6CE1C8" --Apple-Mail=_BCED2EA2-2819-4C5D-BE96-1C809D6CE1C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Kathleen, > On May 2, 2016, at 8:34 PM, Kathleen.moriarty.ietf@gmail.com wrote: >=20 > Hi, >=20 > Thanks for the quick responses. See inline >=20 > Sent from my iPhone >=20 > On May 2, 2016, at 8:04 PM, Carlos Pignataro (cpignata) = > wrote: >=20 >> Kathleen, >>=20 >>> On May 2, 2016, at 7:48 PM, Manav Bhatia > wrote: >>>=20 >>> Hi Kathleen, >>>=20 >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> This should be pretty easy to address. In the security = consideration >>> section, the following recommendation appears: >>>=20 >>> o SBFDReflector MUST NOT look at the crypto sequence number before >>> accepting the packet. >>>=20 >>> Could you please add text to say what happens (what attacks are = possible) >>> if this is looked at? There is nothing to stop the crypt sequence = number >>> from being looked at, right? Is there a way to actually prevent = that? >>>=20 >>>=20 >>> SBFD is state-less. The SBFDReflector is NOT maintaining any BFD = peer state, and is thus incapable of doing the crypto-sequence checks. = It has no idea of last sequence number that it had seen from a BFD peer, = and hence CANNOT compare the new sequence number. Its for this reason = that we mandate that the reflectors MUST NOT look at the sequence = numbers. >>>=20 >>=20 >> Further to this, the SBFDReflector can be receiving S-BFD packets = from multiple SBFDInitiators. Hence, the authentications can be used = from BFD but not the sequence numbers. >>=20 >>> We cant prevent a peer from looking at the sequence number -- thats = an implementation specific issue. The implementation is violating the = standard. Not sure what we can do to prevent that. >>>=20 >>> Does this help? >>>=20 >>=20 >> We could also explain the rational behind this requirement a bit = better. Would that help? >>=20 > Yes, that would be helpful. I'm glad to see that this is not an = issue. >=20 Indeed =E2=80=94 thanks. I added the following, ready in our working = copy: @@ -916,7 +916,10 @@ configured. o SBFDReflector MUST NOT look at the crypto sequence number before - accepting the packet. + accepting the packet. This is because the SBFDReflector does not + maintain S-BFD peer state, and because the SBFDReflector can + receive S-BFD packets from multiple SBFDInitiators. = Consequently, + BFD authentication can be used but not the sequence number. o SBFDReflector MAY look at the Auth Key ID in the incoming packet and verify the authentication data. Thanks, =E2=80=94 Carlos. > Thanks, > Kathleen >=20 >> Thanks, >>=20 >> =E2=80=94 Carlos. >>=20 >>> Cheers, Manav --Apple-Mail=_BCED2EA2-2819-4C5D-BE96-1C809D6CE1C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Kathleen,

On May 2, 2016, at 8:34 PM, Kathleen.moriarty.ietf@gmail.com wrote:

Hi,

Thanks for the quick = responses.  See inline 

Sent from = my iPhone

On May 2, 2016, at 8:04 PM, Carlos Pignataro (cpignata) = <cpignata@cisco.com> wrote:

Kathleen,

On May 2, 2016, at 7:48 PM, Manav Bhatia <manav@ionosnetworks.com> wrote:

Hi Kathleen,

DISCUSS:
---------------------------------------------------------------= -------

This should be pretty easy to = address.  In the security consideration
section, the = following recommendation appears:

 o  SBFDReflector MUST NOT look at the crypto = sequence number before
      accepting the = packet.

Could you please add text to say = what happens (what attacks are possible)
if this is looked = at?  There is nothing to stop the crypt sequence number
from being looked at, right?  Is there a way to actually = prevent that?


SBFD is state-less. = The SBFDReflector is NOT maintaining any BFD peer state, and = is thus incapable of doing the crypto-sequence checks. It has no idea of = last sequence number that it had seen from a BFD peer, and hence CANNOT = compare the new sequence number. Its for this reason that we mandate = that the reflectors MUST NOT look at the sequence numbers.


Further to this, = the SBFDReflector can be receiving S-BFD packets from = multiple SBFDInitiators. Hence, the authentications can be used = from BFD but not the sequence numbers.

We cant prevent a peer from looking at the sequence number -- = thats an implementation specific issue. The implementation is violating = the standard. Not sure what we can do to prevent that.

Does this = help?


We could also explain = the rational behind this requirement a bit better. Would that = help?

Yes, that would be helpful.  I'm glad to = see that this is not an issue.


Indeed =E2=80=94 thanks. I added the following, = ready in our working copy:

@@ -916,7 = +916,10 @@
       configured.
 
  =   o  SBFDReflector MUST NOT look at the crypto = sequence number before
-    =   accepting the packet.
+    =   accepting the packet.  This is because the = SBFDReflector does not
+      maintain = S-BFD peer state, and because the SBFDReflector can
+  =     receive S-BFD packets from multiple = SBFDInitiators.  Consequently,
+    =   BFD authentication can be used but not the sequence = number.
 
  =   o  SBFDReflector MAY look at the Auth Key ID in = the incoming packet
       and verify = the authentication data.


Thanks,

=E2=80=94= Carlos.

Thanks,
Kathleen 

Thanks,

=E2=80=94 Carlos.

Cheers, = Manav

= --Apple-Mail=_BCED2EA2-2819-4C5D-BE96-1C809D6CE1C8-- --Apple-Mail=_EE68E6CD-DECE-4296-9473-674EB6E10450 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXJ/WQAAoJEIXgpQGOZny9ISkQAKXpEuDQM9srJQJ/TC84/ICA HAlxq/2hlwK1Lu0Js5vvVoPCEu2C/B02rlJm8OtmfhVkpyPj6rEZtWCWZwVKj0Op Eic7kcPImZAZgM3BkH50BX9sfk0txCuuKP75yG9+zi7Z9n+eA7HMI27OhspOx7ak yC4qH8XWjx143EIKB8i0fks0nMsGznAEqf8zDrUjQlqxyNGKMjn8p+u7Tvs0bDYx smwZTdcRTWIPbsIjbhJMjn+whJX0zpv/PoW6Sp9Gw/kQsRHjnKwU3//AizozT3JX Bdc1I6uM9qRDVOkYxbpO8kahNWIVzW1gzNGB8ji1u2XHWU7Uk0CPdWm9VJxPqIRR x2kPmDG8gIBQNLRInRb2N6EOo8N+laEhdtZSSAWBQwbtlfcGZYdjC23RNA494vWg 5H0pgHGGbHjC12yl83uvHQHhk4/FQ01bnDtVh2EBgrUOffWtidVSMvd3pVlgHkLb rUBw0Ky2a0Zs+AV69yvGxI5LyqI6C5D5TQb/iPFH6fHqzTwxZGcAE0tM2XkykMCv z7BgwB4a6pkRH2zb7E8/UyU6ZvB8IW++F6lir4xCsvp7q9WDRYAYMVav7UN+qT2Z jhW45hvNF2dzy8Q88ILC/LeOqSgSs3xyXiSvCkLUq3vZG1glaM5yw7oQy4yPGP7R UUduz17mZR1cQhaAQK5l =ZF/m -----END PGP SIGNATURE----- --Apple-Mail=_EE68E6CD-DECE-4296-9473-674EB6E10450-- From nobody Mon May 2 17:55:04 2016 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 05D9412D6B9; Mon, 2 May 2016 17:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 FLWc5VH-IhH9; Mon, 2 May 2016 17:54:51 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (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 00B3812D6AA; Mon, 2 May 2016 17:54:50 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id f74so2216926qge.2; Mon, 02 May 2016 17:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oePyWhuwrFTRpHrkHIuf1nD72F+TY8Ev8/S9wgq3BsY=; b=PIIe6irRZc/2LJB1/Q3UplPve1QMvgOpDMnCt62blHlrcwsZhCmwPcSFQeVZg5nFJL abxHiD8ri5moBnqLVohTlMlyWIoPIVAH1RjO2xEfeWQqKb8xxHYp1oNZAvM1Y2BiF7cm lKk9SmjC9FMb66I0e4ySIWywlexu7Bp+LJ750+00GtUMecRDRW0blEssj1MX58Mrg7q+ OGmfex4Z9spmDMiSR5xdbs+4v+u3Ic8XyL5y//W/saubFmRrzPYhqChLmBYCOmRwL54d Yjk5Ju9gVfRflTwWnZzODVpoLG2RY0ATzSiWGwziJbYYoaz5p0YrDgAaK0vo4kTuDTYu 9CHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oePyWhuwrFTRpHrkHIuf1nD72F+TY8Ev8/S9wgq3BsY=; b=Z7bbhh6x5E9wMPPwz5CcCylJCXIx5q2h0FmmiAkGSmKrK4ZsEtg97ATqGYaRidSjNO wYfKljtgzX4dGCWbLkpXKxufbUnVA7bOFnpET2tXwGAU4ai9mL3iYOT3Gzq5dTfULuvg w2xaFRUiHIaOgzM99X87NGH9Wz7XKyaddyKUxw6dJ4EWmgZ+o3aUdB56dsVN8H07JlDR wPIioC3dM+J00NiaNuJ0PFQOPymsm9MNL+wokpyKdW73KesQxzU9sWKa92fed0VaMTzf AQ4h0YTxsPdKIBiz1gwt4n+Mp28xcEG1buKOo7HJB2E7E7nmftYTKFGfNPJ3RQmyY6cq bSrg== X-Gm-Message-State: AOPr4FVAWkOYMEZ5TCbqZDA9L+QUUxMp5IusCiGrnWZS4YR/NZDzrYUmKaExCocIkg6WQQ== X-Received: by 10.140.171.65 with SMTP id r62mr37105752qhr.45.1462236890089; Mon, 02 May 2016 17:54:50 -0700 (PDT) Received: from [192.168.1.3] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id f204sm329897qhe.1.2016.05.02.17.54.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2016 17:54:48 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-4E626F0B-9609-4B53-86DE-792709AB87F0 Mime-Version: 1.0 (1.0) Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (12H143) In-Reply-To: Date: Mon, 2 May 2016 20:54:48 -0400 Content-Transfer-Encoding: 7bit Message-Id: <1CCBFDAD-B0D5-4F10-B3F4-5D5A13D494EC@gmail.com> References: <20160502193624.15732.51479.idtracker@ietfa.amsl.com> <0FD64F08-19D5-4CD2-A1A9-FD9F505206B3@gmail.com> To: "Carlos Pignataro (cpignata)" Archived-At: Cc: Manav Bhatia , The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 00:54:58 -0000 --Apple-Mail-4E626F0B-9609-4B53-86DE-792709AB87F0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On May 2, 2016, at 8:49 PM, Carlos Pignataro (cpignata) wrote: >=20 > Hi, Kathleen, >=20 >> On May 2, 2016, at 8:34 PM, Kathleen.moriarty.ietf@gmail.com wrote: >>=20 >> Hi, >>=20 >> Thanks for the quick responses. See inline=20 >>=20 >> Sent from my iPhone >>=20 >>> On May 2, 2016, at 8:04 PM, Carlos Pignataro (cpignata) wrote: >>>=20 >>> Kathleen, >>>=20 >>>>> On May 2, 2016, at 7:48 PM, Manav Bhatia wro= te: >>>>>=20 >>>>> Hi Kathleen, >>>>>=20 >>>>> DISCUSS: >>>>> ----------------------------------------------------------------------= >>>>>=20 >>>>> This should be pretty easy to address. In the security consideration >>>>> section, the following recommendation appears: >>>>>=20 >>>>> o SBFDReflector MUST NOT look at the crypto sequence number before >>>>> accepting the packet. >>>>>=20 >>>>> Could you please add text to say what happens (what attacks are possib= le) >>>>> if this is looked at? There is nothing to stop the crypt sequence num= ber >>>>> from being looked at, right? Is there a way to actually prevent that?= >>>>=20 >>>> SBFD is state-less. The SBFDReflector is NOT maintaining any BFD peer s= tate, and is thus incapable of doing the crypto-sequence checks. It has no i= dea of last sequence number that it had seen from a BFD peer, and hence CANN= OT compare the new sequence number. Its for this reason that we mandate that= the reflectors MUST NOT look at the sequence numbers. >>>=20 >>> Further to this, the SBFDReflector can be receiving S-BFD packets from m= ultiple SBFDInitiators. Hence, the authentications can be used from BFD but n= ot the sequence numbers. >>>=20 >>>> We cant prevent a peer from looking at the sequence number -- thats an i= mplementation specific issue. The implementation is violating the standard. N= ot sure what we can do to prevent that. >>>>=20 >>>> Does this help? >>>=20 >>> We could also explain the rational behind this requirement a bit better.= Would that help? >> Yes, that would be helpful. I'm glad to see that this is not an issue. >=20 > Indeed =E2=80=94 thanks. I added the following, ready in our working copy:= >=20 > @@ -916,7 +916,10 @@ > configured. > =20 > o SBFDReflector MUST NOT look at the crypto sequence number before > - accepting the packet. > + accepting the packet. This is because the SBFDReflector does not > + maintain S-BFD peer state, and because the SBFDReflector can > + receive S-BFD packets from multiple SBFDInitiators. Consequently, > + BFD authentication can be used but not the sequence number. > =20 > o SBFDReflector MAY look at the Auth Key ID in the incoming packet > and verify the authentication data. Excellent, thank you. I'll move it to a comment in the morning for the shep= herd & AD to track when approving the draft. Best regards, Kathleen=20 >=20 >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >> Thanks, >> Kathleen=20 >>=20 >>> Thanks, >>>=20 >>> =E2=80=94 Carlos. >>>=20 >>>> Cheers, Manav >=20 --Apple-Mail-4E626F0B-9609-4B53-86DE-792709AB87F0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On May 2, 2016, at 8:49 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:

Hi, Kathleen,

On May 2, 2016, at 8:34 PM= , Kathleen.mo= riarty.ietf@gmail.com wrote:

Hi,

Thanks for the quick responses.  See inline 

Sent from my iPhone

On May 2, 2016, at 8:04 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:

Kathleen,

On May 2, 2016, at 7:48 PM, Manav Bhatia &= lt;manav@ionosnetworks= .com> wrote:

Hi Kathleen,

DISCUSS:
--------------------------------------------------= --------------------

This should be pretty easy= to address.  In the security consideration
section, the f= ollowing recommendation appears:

 o  S= BFDReflector MUST NOT look at the crypto sequence number before
      accepting the packet.

Co= uld you please add text to say what happens (what attacks are possible)
if this is looked at?  There is nothing to stop the crypt seq= uence number
from being looked at, right?  Is there a way= to actually prevent that?


SBFD is state-less. The S= BFDReflector is NOT maintaining any BFD peer state, and is thus incapab= le of doing the crypto-sequence checks. It has no idea of last sequence numb= er that it had seen from a BFD peer, and hence CANNOT compare the new sequen= ce number. Its for this reason that we mandate that the reflectors MUST NOT l= ook at the sequence numbers.


<= div class=3D"">Further to this, the SBFDReflector can be receiving S-BFD= packets from multiple SBFDInitiators. Hence, the authentications can b= e used from BFD but not the sequence numbers.

We cant prevent a peer from looking at the sequence number -- thats an im= plementation specific issue. The implementation is violating the standard. N= ot sure what we can do to prevent that.

=
Does this help?


We could also explain the rational behind this requi= rement a bit better. Would that help?

Yes, that would be helpful.  I'm glad to see that this i= s not an issue.


Indeed =E2=80=94 thanks. I added the followi= ng, ready in our working copy:

@@ -916,7= +916,10 @@
       configured.
 
    o  SBFDReflector MUST N= OT look at the crypto sequence number before
-    &n= bsp; accepting the packet.
+      acc= epting the packet.  This is because the SBFDReflector does not
+      maintain S-BFD peer state, and because t= he SBFDReflector can
+      receive S-BFD p= ackets from multiple SBFDInitiators.  Consequently,
= +      BFD authentication can be used but not the sequen= ce number.
 
    o &nbs= p;SBFDReflector MAY look at the Auth Key ID in the incoming packet
       and verify the authentication data.

Excellent, thank you.=  I'll move it to a comment in the morning for the shepherd & AD to= track when approving the draft.

Best regards,
= Kathleen 

=


Thanks,
<= div>
=E2=80=94 Carlos.

Thanks,
Kathleen 

Thanks,

= =E2=80=94 Carlos.

<= div class=3D"">
Cheers, Manav
=

= --Apple-Mail-4E626F0B-9609-4B53-86DE-792709AB87F0-- From nobody Mon May 2 21:25:34 2016 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 45D8C12D1B5; Mon, 2 May 2016 21:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 3UnoD6Z_dV6G; Mon, 2 May 2016 21:25:31 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 5BF8612B045; Mon, 2 May 2016 21:25:29 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id o66so8938385ywc.3; Mon, 02 May 2016 21:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=qhCuPqx5cTQWejw72lNPIzByN6iveI3aMHXJRgSkDBU=; b=wbnvd8/VQEfKT23eeTrMXA/whEOjrF9PeBo4ElIGYrXK0I0jd7T3GSCRikHqgEUX6r VKVVZ7bQPYM1ppCDz2zgLDvvRjOQJbLfOOkUXqvBtgjk76rywK/tIYJkSblNHdtp+686 Qyf0BgRPgv0X1P0WAj6Kc7ZUi11fj6kr8+/V88Ny7aI2ftBHkCFw/IpPDm6coU41JHvC QwTMQ/TRp7GksddALlFHXVC38PSyyA+mfWdyQbe410bhyUEINUWaoeFn3hBCQCuq2+RV 11nMkYmfnMxABYAr5CVCK2MPivVEqnIiFzFVFvEWzBX80vwGxJ8eeuIZxe0uPeWx51E/ b71Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=qhCuPqx5cTQWejw72lNPIzByN6iveI3aMHXJRgSkDBU=; b=HOoTaa1n+cRN5oqZUA9kNRuZ7juigHP5wWidJfUEHW2VOPJVIu4tHQZLlUtRR4T1sK gIdigOw4DR5CiXzqwXRUrNC9QzeoRUery17ZGsSvjMaAstsYmXO/2s0jT116ZczgXeSf gPNWNKKnU8S+wRaM27pPrwPNt1TRHaySpo7x9gWRUI6GHMTXzCFhCe0rWIysiWydHYz8 7o3r+aNSEk2ClUQTQhntB7Vh9OcytmgeeRd8DjeWD0qlo5rd27dC/vumlck4/WGvkdQI m57rELWySM2JCgGwnEyTcGFTeIbj13nocZxRGaMiFKnZ45Dr33vIipGaAI+92Mg5brmW DqQw== X-Gm-Message-State: AOPr4FWK2Y35wzUnoYJnfHPI9xvEUXiWG/4QiGG0SGVd7T9fA80odp2FENMsqf8GxfqrrWKsSXwRXbG0EjGimg== MIME-Version: 1.0 X-Received: by 10.37.5.212 with SMTP id 203mr99988ybf.45.1462249528552; Mon, 02 May 2016 21:25:28 -0700 (PDT) Received: by 10.13.216.129 with HTTP; Mon, 2 May 2016 21:25:28 -0700 (PDT) In-Reply-To: References: Date: Tue, 3 May 2016 09:55:28 +0530 Message-ID: Subject: Re: Replace "seamless" with "stateless" From: Manav Bhatia To: Sam Aldrin Content-Type: multipart/alternative; boundary=001a11c04fd0b8f9a10531e87f6e Archived-At: Cc: "rtg-bfd@ietf.org" , draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 04:25:34 -0000 --001a11c04fd0b8f9a10531e87f6e Content-Type: text/plain; charset=UTF-8 I agree that stateless may not be complete enough, and just highlights one aspect of SBFD -- however, its better than "seamless", which i grudgingly concede, may sound pretty nifty, but means and conveys almost nothing. I dont think its too late into the WG cycle to change the name -- heck, all it needs is a DISCUSS from one of the IESG members ! :-) If the WG consensus is that "seamless" succinctly captures the essence of SBFD then we could leave it as is. However, i propose that we replace it with something more meaningful, that hopefully starts with "S" so that its still "SBFD" because you dont want all developers out there to rename their variables and function names now. Cheers, Manav On Tue, May 3, 2016 at 5:46 AM, Sam Aldrin wrote: > Think there was some discussion during the extension of the charter for > this work item. Not sure what the conclusion was exactly. IIRC, we found > the cool term 'seamless' and tried to fit in SBFD work into that > definition, rather than finding a term fitting the definition. > > Not sure if stateless is complete enough, but I have no opinion either > way. On the contrary, someone asked if S means SDN :D > > Sam > > Sent from my iPhone > > > On May 2, 2016, at 4:52 PM, Manav Bhatia wrote: > > > > Hi, > > > > Does it make sense to change "seamless BFD" with "stateless BFD" in the > documents? Its very convoluted to explain whats "seamless" about S-BFD. > > > > We called it "seamless" because it was simple and largely stateless. > > > > Any suggestions? > > > > Cheers, Manav > --001a11c04fd0b8f9a10531e87f6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree that stateless may not be complete enough, and jus= t highlights one aspect of SBFD -- however, its better than "seamless&= quot;, which i grudgingly concede, may sound pretty nifty, but means and co= nveys almost nothing.

I dont think its too late into the= WG cycle to change the name -- heck, all it needs is a DISCUSS from one of= the IESG members ! :-)

If the WG consensus is tha= t "seamless" succinctly captures the essence of SBFD then we coul= d leave it as is. However, i propose that we replace it with something more= meaningful, that hopefully starts with "S" so that its still &qu= ot;SBFD" because you dont want all developers out there to rename thei= r variables and function names now.

Cheers, Manav<= /div>

On Tue= , May 3, 2016 at 5:46 AM, Sam Aldrin <aldrin.ietf@gmail.com> wrote:
Think there was some discussi= on during the extension of the charter for this work item. Not sure what th= e conclusion was exactly. IIRC, we found the cool term 'seamless' a= nd tried to fit in SBFD work into that definition, rather than finding a te= rm fitting the definition.

Not sure if stateless is complete enough, but I have no opinion either way.= On the contrary, someone asked if S means SDN :D

Sam

Sent from my iPhone

> On May 2, 2016, at 4:52 PM, Manav Bhatia <manavbhatia@gmail.com> wrote:
>
> Hi,
>
> Does it make sense to change "seamless BFD" with "state= less BFD" in the documents? Its very convoluted to explain whats "= ;seamless" about S-BFD.
>
> We called it "seamless" because it was simple and largely st= ateless.
>
> Any suggestions?
>
> Cheers, Manav

--001a11c04fd0b8f9a10531e87f6e-- From nobody Mon May 2 23:14:49 2016 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 93C3712B00E; Mon, 2 May 2016 23:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 HIx7ckffFnEl; Mon, 2 May 2016 23:14:45 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65CC512D537; Mon, 2 May 2016 23:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13782; q=dns/txt; s=iport; t=1462256085; x=1463465685; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qsG5sutSHPZtWhFP+UBW/9jR53Yg85be2aWM0z0Kksk=; b=D2LFZ3hgobimUWNTcE8f10865GJ8B1uXswE3N0NGTA+6dFTJhDl0XVgc HqfysLIqpPqoy+RSQTWB64calIeC0XGC09ergxc6mGVCaWiw5jrmoJSb/ o0rTGfVj25xojZs/7FnfGiLnMzvz+GUvZ7bo+yBoKtChHNGRFPRgmDLTK 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAgDLQChX/4YNJK1egmxMU30GriaGb?= =?us-ascii?q?4RzAQ2BdoYQAhyBHTgUAQEBAQEBAWUnhEEBAQEDASMKTAULAgEGAhEEAQEBJwM?= =?us-ascii?q?CAgIfERQJCAIEAQ0FCIgNAwoIjEqdHYxCDYROAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBFYYhg0qBAoJBgjKCSoJZBY1XigwxAYwggXCPGYdRh18BHgEBQoNrbIc9fwE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.24,571,1454976000"; d="scan'208,217";a="103060061" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 May 2016 06:14:44 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u436EiwV028812 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 06:14:44 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 01:14:43 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Tue, 3 May 2016 01:14:43 -0500 From: "Les Ginsberg (ginsberg)" To: Manav Bhatia , Sam Aldrin Subject: RE: Replace "seamless" with "stateless" Thread-Topic: Replace "seamless" with "stateless" Thread-Index: AQHRpM24HAo4XhncIU6Q/tu59M11ip+mrCiAgABFsgD//8lGQA== Date: Tue, 3 May 2016 06:14:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.87.208] Content-Type: multipart/alternative; boundary="_000_d75ae19d39cf4910afb17bcda1a3e314XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 06:14:47 -0000 --_000_d75ae19d39cf4910afb17bcda1a3e314XCHALN001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyB3YXMgZGViYXRlZCBhdCBsZW5ndGggMiB5ZWFycyBhZ28gYW5kIHNvbWVob3cgd2UgZW5k ZWQgdXAgd2l0aCDigJxzZWFtbGVzc+KAnS4NCldoaWxlIEkgYW0gbm8gd2F5IGludmVzdGVkIGlu IOKAnHNlYW1sZXNz4oCdIOKAkyB0aGUgSUdQIGRyYWZ0cyBoYXZlIGFscmVhZHkgcHJvY2VlZGVk IHRvIElFU0cgcmV2aWV3IOKAkyBhbmQgaW4gdGhlIGNhc2Ugb2YgdGhlIE9TUEYgZHJhZnQgYXQg bGVhc3QsIHRoZSB3b3JkIOKAnHNlYW1sZXNz4oCdIGlzIHVzZWQgbXVsdGlwbGUgdGltZXMuIFNv IHlvdSB3b3VsZCBoYXZlIHRvIGluc3VyZSDigJxzZWFtbGVzc+KAnSBpcyBleHB1bmdlZCBldmVy eXdoZXJlIGl0IG5lZWRzIHRvIGJlLg0KR2l2ZW4gdGhpcyB3YXNu4oCZdCBzaG90IGRvd24gMiB5 ZWFycyBhZ28gaXQgc2VlbXMgcmF0aGVyIGxhdGUgaW4gdGhlIGdhbWUgdG8gbWFrZSBzdWNoIGEg Y2hhbmdlLiBDYW7igJl0IHdlIHNpbXBseSBsaXZlIHdpdGggd2hhdCB3ZSBoYXZlPw0KDQpJZiBu b3RoaW5nIGVsc2UgaXQgd2lsbCBtYWtlIGEgZ3JlYXQgc3RvcnkgdG8gdGVsbCB5b3VyIG92ZXJs eSBuZXJkeSBncmFuZGNoaWxkcmVuLiDimLoNCg0KICAgTGVzDQoNCg0KDQpGcm9tOiBSdGctYmZk IFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFuYXYgQmhh dGlhDQpTZW50OiBNb25kYXksIE1heSAwMiwgMjAxNiA5OjI1IFBNDQpUbzogU2FtIEFsZHJpbg0K Q2M6IHJ0Zy1iZmRAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtYmZkLXNlYW1sZXNzLWJhc2VAaWV0Zi5v cmc7IGJmZC1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBSZXBsYWNlICJzZWFtbGVzcyIg d2l0aCAic3RhdGVsZXNzIg0KDQpJIGFncmVlIHRoYXQgc3RhdGVsZXNzIG1heSBub3QgYmUgY29t cGxldGUgZW5vdWdoLCBhbmQganVzdCBoaWdobGlnaHRzIG9uZSBhc3BlY3Qgb2YgU0JGRCAtLSBo b3dldmVyLCBpdHMgYmV0dGVyIHRoYW4gInNlYW1sZXNzIiwgd2hpY2ggaSBncnVkZ2luZ2x5IGNv bmNlZGUsIG1heSBzb3VuZCBwcmV0dHkgbmlmdHksIGJ1dCBtZWFucyBhbmQgY29udmV5cyBhbG1v c3Qgbm90aGluZy4NCg0KSSBkb250IHRoaW5rIGl0cyB0b28gbGF0ZSBpbnRvIHRoZSBXRyBjeWNs ZSB0byBjaGFuZ2UgdGhlIG5hbWUgLS0gaGVjaywgYWxsIGl0IG5lZWRzIGlzIGEgRElTQ1VTUyBm cm9tIG9uZSBvZiB0aGUgSUVTRyBtZW1iZXJzICEgOi0pDQoNCklmIHRoZSBXRyBjb25zZW5zdXMg aXMgdGhhdCAic2VhbWxlc3MiIHN1Y2NpbmN0bHkgY2FwdHVyZXMgdGhlIGVzc2VuY2Ugb2YgU0JG RCB0aGVuIHdlIGNvdWxkIGxlYXZlIGl0IGFzIGlzLiBIb3dldmVyLCBpIHByb3Bvc2UgdGhhdCB3 ZSByZXBsYWNlIGl0IHdpdGggc29tZXRoaW5nIG1vcmUgbWVhbmluZ2Z1bCwgdGhhdCBob3BlZnVs bHkgc3RhcnRzIHdpdGggIlMiIHNvIHRoYXQgaXRzIHN0aWxsICJTQkZEIiBiZWNhdXNlIHlvdSBk b250IHdhbnQgYWxsIGRldmVsb3BlcnMgb3V0IHRoZXJlIHRvIHJlbmFtZSB0aGVpciB2YXJpYWJs ZXMgYW5kIGZ1bmN0aW9uIG5hbWVzIG5vdy4NCg0KQ2hlZXJzLCBNYW5hdg0KDQpPbiBUdWUsIE1h eSAzLCAyMDE2IGF0IDU6NDYgQU0sIFNhbSBBbGRyaW4gPGFsZHJpbi5pZXRmQGdtYWlsLmNvbTxt YWlsdG86YWxkcmluLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpUaGluayB0aGVyZSB3YXMgc29t ZSBkaXNjdXNzaW9uIGR1cmluZyB0aGUgZXh0ZW5zaW9uIG9mIHRoZSBjaGFydGVyIGZvciB0aGlz IHdvcmsgaXRlbS4gTm90IHN1cmUgd2hhdCB0aGUgY29uY2x1c2lvbiB3YXMgZXhhY3RseS4gSUlS Qywgd2UgZm91bmQgdGhlIGNvb2wgdGVybSAnc2VhbWxlc3MnIGFuZCB0cmllZCB0byBmaXQgaW4g U0JGRCB3b3JrIGludG8gdGhhdCBkZWZpbml0aW9uLCByYXRoZXIgdGhhbiBmaW5kaW5nIGEgdGVy bSBmaXR0aW5nIHRoZSBkZWZpbml0aW9uLg0KDQpOb3Qgc3VyZSBpZiBzdGF0ZWxlc3MgaXMgY29t cGxldGUgZW5vdWdoLCBidXQgSSBoYXZlIG5vIG9waW5pb24gZWl0aGVyIHdheS4gT24gdGhlIGNv bnRyYXJ5LCBzb21lb25lIGFza2VkIGlmIFMgbWVhbnMgU0ROIDpEDQoNClNhbQ0KDQpTZW50IGZy b20gbXkgaVBob25lDQoNCj4gT24gTWF5IDIsIDIwMTYsIGF0IDQ6NTIgUE0sIE1hbmF2IEJoYXRp YSA8bWFuYXZiaGF0aWFAZ21haWwuY29tPG1haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb20+PiB3 cm90ZToNCj4NCj4gSGksDQo+DQo+IERvZXMgaXQgbWFrZSBzZW5zZSB0byBjaGFuZ2UgInNlYW1s ZXNzIEJGRCIgd2l0aCAic3RhdGVsZXNzIEJGRCIgaW4gdGhlIGRvY3VtZW50cz8gSXRzIHZlcnkg Y29udm9sdXRlZCB0byBleHBsYWluIHdoYXRzICJzZWFtbGVzcyIgYWJvdXQgUy1CRkQuDQo+DQo+ IFdlIGNhbGxlZCBpdCAic2VhbWxlc3MiIGJlY2F1c2UgaXQgd2FzIHNpbXBsZSBhbmQgbGFyZ2Vs eSBzdGF0ZWxlc3MuDQo+DQo+IEFueSBzdWdnZXN0aW9ucz8NCj4NCj4gQ2hlZXJzLCBNYW5hdg0K DQo= --_000_d75ae19d39cf4910afb17bcda1a3e314XCHALN001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoaXMgd2FzIGRlYmF0ZWQgYXQgbGVuZ3RoIDIgeWVhcnMgYWdvIGFuZCBz b21laG93IHdlIGVuZGVkIHVwIHdpdGgg4oCcc2VhbWxlc3PigJ0uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPldoaWxlIEkgYW0gbm8gd2F5IGludmVzdGVkIGluIOKAnHNlYW1sZXNz4oCd IOKAkyB0aGUgSUdQIGRyYWZ0cyBoYXZlIGFscmVhZHkgcHJvY2VlZGVkIHRvIElFU0cgcmV2aWV3 IOKAkyBhbmQgaW4gdGhlIGNhc2Ugb2YgdGhlIE9TUEYgZHJhZnQgYXQgbGVhc3QsIHRoZSB3b3Jk IOKAnHNlYW1sZXNz4oCdDQogaXMgdXNlZCBtdWx0aXBsZSB0aW1lcy4gU28geW91IHdvdWxkIGhh dmUgdG8gaW5zdXJlIOKAnHNlYW1sZXNz4oCdIGlzIGV4cHVuZ2VkIGV2ZXJ5d2hlcmUgaXQgbmVl ZHMgdG8gYmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkdpdmVuIHRoaXMgd2FzbuKA mXQgc2hvdCBkb3duIDIgeWVhcnMgYWdvIGl0IHNlZW1zIHJhdGhlciBsYXRlIGluIHRoZSBnYW1l IHRvIG1ha2Ugc3VjaCBhIGNoYW5nZS4gQ2Fu4oCZdCB3ZSBzaW1wbHkgbGl2ZSB3aXRoIHdoYXQg d2UgaGF2ZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIG5vdGhpbmcgZWxzZSBpdCB3aWxsIG1ha2UgYSBncmVhdCBz dG9yeSB0byB0ZWxsIHlvdXIgb3Zlcmx5IG5lcmR5IGdyYW5kY2hpbGRyZW4uDQo8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMx RjQ5N0QiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IExlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJ0Zy1iZmQgW21haWx0bzpydGctYmZk LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hbmF2IEJoYXRpYTxicj4N CjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSAwMiwgMjAxNiA5OjI1IFBNPGJyPg0KPGI+VG86PC9i PiBTYW0gQWxkcmluPGJyPg0KPGI+Q2M6PC9iPiBydGctYmZkQGlldGYub3JnOyBkcmFmdC1pZXRm LWJmZC1zZWFtbGVzcy1iYXNlQGlldGYub3JnOyBiZmQtY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBSZXBsYWNlICZxdW90O3NlYW1sZXNzJnF1b3Q7IHdpdGggJnF1b3Q7 c3RhdGVsZXNzJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgYWdyZWUgdGhhdCBzdGF0ZWxlc3MgbWF5IG5vdCBiZSBjb21wbGV0ZSBl bm91Z2gsIGFuZCBqdXN0IGhpZ2hsaWdodHMgb25lIGFzcGVjdCBvZiBTQkZEIC0tIGhvd2V2ZXIs IGl0cyBiZXR0ZXIgdGhhbiAmcXVvdDtzZWFtbGVzcyZxdW90Oywgd2hpY2ggaSBncnVkZ2luZ2x5 IGNvbmNlZGUsIG1heSBzb3VuZCBwcmV0dHkgbmlmdHksIGJ1dCBtZWFucyBhbmQgY29udmV5cyBh bG1vc3Qgbm90aGluZy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgZG9udCB0aGluayBpdHMgdG9vIGxhdGUgaW50byB0aGUgV0cgY3ljbGUgdG8gY2hhbmdl IHRoZSBuYW1lIC0tIGhlY2ssIGFsbCBpdCBuZWVkcyBpcyBhIERJU0NVU1MgZnJvbSBvbmUgb2Yg dGhlIElFU0cgbWVtYmVycyAhIDotKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgV0cgY29uc2Vuc3VzIGlzIHRoYXQgJnF1b3Q7c2Vh bWxlc3MmcXVvdDsgc3VjY2luY3RseSBjYXB0dXJlcyB0aGUgZXNzZW5jZSBvZiBTQkZEIHRoZW4g d2UgY291bGQgbGVhdmUgaXQgYXMgaXMuIEhvd2V2ZXIsIGkgcHJvcG9zZSB0aGF0IHdlIHJlcGxh Y2UgaXQgd2l0aCBzb21ldGhpbmcgbW9yZSBtZWFuaW5nZnVsLCB0aGF0IGhvcGVmdWxseSBzdGFy dHMgd2l0aCAmcXVvdDtTJnF1b3Q7IHNvIHRoYXQgaXRzIHN0aWxsICZxdW90O1NCRkQmcXVvdDsg YmVjYXVzZQ0KIHlvdSBkb250IHdhbnQgYWxsIGRldmVsb3BlcnMgb3V0IHRoZXJlIHRvIHJlbmFt ZSB0aGVpciB2YXJpYWJsZXMgYW5kIGZ1bmN0aW9uIG5hbWVzIG5vdy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLCBNYW5hdjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUs IE1heSAzLCAyMDE2IGF0IDU6NDYgQU0sIFNhbSBBbGRyaW4gJmx0OzxhIGhyZWY9Im1haWx0bzph bGRyaW4uaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5hbGRyaW4uaWV0ZkBnbWFpbC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo aW5rIHRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gZHVyaW5nIHRoZSBleHRlbnNpb24gb2YgdGhl IGNoYXJ0ZXIgZm9yIHRoaXMgd29yayBpdGVtLiBOb3Qgc3VyZSB3aGF0IHRoZSBjb25jbHVzaW9u IHdhcyBleGFjdGx5LiBJSVJDLCB3ZSBmb3VuZCB0aGUgY29vbCB0ZXJtICdzZWFtbGVzcycgYW5k IHRyaWVkIHRvIGZpdCBpbiBTQkZEIHdvcmsgaW50byB0aGF0IGRlZmluaXRpb24sIHJhdGhlciB0 aGFuIGZpbmRpbmcNCiBhIHRlcm0gZml0dGluZyB0aGUgZGVmaW5pdGlvbi48YnI+DQo8YnI+DQpO b3Qgc3VyZSBpZiBzdGF0ZWxlc3MgaXMgY29tcGxldGUgZW5vdWdoLCBidXQgSSBoYXZlIG5vIG9w aW5pb24gZWl0aGVyIHdheS4gT24gdGhlIGNvbnRyYXJ5LCBzb21lb25lIGFza2VkIGlmIFMgbWVh bnMgU0ROIDpEPGJyPg0KPGJyPg0KU2FtPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IGlQaG9uZTxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQom Z3Q7IE9uIE1heSAyLCAyMDE2LCBhdCA0OjUyIFBNLCBNYW5hdiBCaGF0aWEgJmx0OzxhIGhyZWY9 Im1haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb20iPm1hbmF2YmhhdGlhQGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDs8YnI+DQomZ3Q7IERv ZXMgaXQgbWFrZSBzZW5zZSB0byBjaGFuZ2UgJnF1b3Q7c2VhbWxlc3MgQkZEJnF1b3Q7IHdpdGgg JnF1b3Q7c3RhdGVsZXNzIEJGRCZxdW90OyBpbiB0aGUgZG9jdW1lbnRzPyBJdHMgdmVyeSBjb252 b2x1dGVkIHRvIGV4cGxhaW4gd2hhdHMgJnF1b3Q7c2VhbWxlc3MmcXVvdDsgYWJvdXQgUy1CRkQu PGJyPg0KJmd0Ozxicj4NCiZndDsgV2UgY2FsbGVkIGl0ICZxdW90O3NlYW1sZXNzJnF1b3Q7IGJl Y2F1c2UgaXQgd2FzIHNpbXBsZSBhbmQgbGFyZ2VseSBzdGF0ZWxlc3MuPGJyPg0KJmd0Ozxicj4N CiZndDsgQW55IHN1Z2dlc3Rpb25zPzxicj4NCiZndDs8YnI+DQomZ3Q7IENoZWVycywgTWFuYXY8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_d75ae19d39cf4910afb17bcda1a3e314XCHALN001ciscocom_-- From nobody Tue May 3 00:50:22 2016 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 B742A12D521; Tue, 3 May 2016 00:50:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" Subject: =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ietf-bfd-?= =?utf-8?q?seamless-use-case-06=3A_=28with_COMMENT=29?= X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503075019.7441.21628.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 00:50:19 -0700 Archived-At: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-seamless-use-case@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 07:50:20 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-bfd-seamless-use-case-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-use-case/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- While this document has a security requirement, I believe there is also a risk of misconfiguration: if no handshake is performed, a node might send S-BFD packets to a receiver that does not exists or is not aware of it or sits at a different part of the network that is somewhere else than expected which can overload the network accidentally. Should this be mentioned in this doc (or somewhere else... or both)? From nobody Tue May 3 02:26:29 2016 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 BE76A12D16A; Tue, 3 May 2016 02:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 acs3KixbC9ye; Tue, 3 May 2016 02:26:25 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4206712D1B6; Tue, 3 May 2016 02:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12518; q=dns/txt; s=iport; t=1462267585; x=1463477185; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3x1YeOoS/yJ6VooA8Y0JuNfGAZBe7mJJXAegGRl3S+Q=; b=POSc2Qf7jOhCsN19pPWUnD/oLy9ZYPAxMNZ2vPCveZwH8UX9WXbTBK1x dZpNGqJot+us0957sFy63z7lq9QLDJiRpodxWIuk748izO0yOsoI8hh2i h+8WO8voz5WP2T+y87+z0l7ZJqQ05VwZB9dKxOBiJp56iWMO8kr636F5D 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQB2bihX/51dJa1dgmxMU24Pri6Gb?= =?us-ascii?q?4RzAQ2BdiKFbgKBPzgUAQEBAQEBAWUnhEEBAQEDAS1MBQsCAQgRBAEBAScHIRE?= =?us-ascii?q?UCQgCBA4FiBUDCggOtg0NhE4BAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYhgXYIg?= =?us-ascii?q?UyBA4JDgV8BAVGCdYIuBY1YhUyEQTEBjCCBd48Sh1GHYAEeAQFCg2tsAYcGgTU?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="scan'208,217";a="268813173" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2016 09:26:24 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u439QNOs031598 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 09:26:24 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 05:26:23 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 3 May 2016 05:26:22 -0400 From: "Carlos Pignataro (cpignata)" To: "Les Ginsberg (ginsberg)" Subject: Re: Replace "seamless" with "stateless" Thread-Topic: Replace "seamless" with "stateless" Thread-Index: AQHRpM20/XnDUL1up0ms/YUmn3h7RJ+mm2SAgABFswCAAB6GgP//8n4h Date: Tue, 3 May 2016 09:26:22 +0000 Message-ID: <5D4A869A-1EDD-4EF8-9168-8F7AF7086F14@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_5D4A869A1EDD4EF891688F7AF7086F14ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 09:26:28 -0000 --_000_5D4A869A1EDD4EF891688F7AF7086F14ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm with Les -- that ship has sailed almost exactly two years ago, when we = had a most thorough and lengthy discussion about it: https://www.ietf.org/mail-archive/web/rtg-bfd/current/msg02051.html I, for one, use "S-BFD" (as there are really many fitting qualifiers that s= tart with "S". The docs explain the why for the "seamless" name, and the se= am being removed. Thanks! Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On May 3, 2016, at 02:14, Les Ginsberg (ginsberg) > wrote: This was debated at length 2 years ago and somehow we ended up with "seamle= ss". While I am no way invested in "seamless" - the IGP drafts have already proc= eeded to IESG review - and in the case of the OSPF draft at least, the word= "seamless" is used multiple times. So you would have to insure "seamless" = is expunged everywhere it needs to be. Given this wasn't shot down 2 years ago it seems rather late in the game to= make such a change. Can't we simply live with what we have? If nothing else it will make a great story to tell your overly nerdy grandc= hildren. :) Les From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Manav Bhatia Sent: Monday, May 02, 2016 9:25 PM To: Sam Aldrin Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-base= @ietf.org; bfd-chairs@ietf.or= g Subject: Re: Replace "seamless" with "stateless" I agree that stateless may not be complete enough, and just highlights one = aspect of SBFD -- however, its better than "seamless", which i grudgingly c= oncede, may sound pretty nifty, but means and conveys almost nothing. I dont think its too late into the WG cycle to change the name -- heck, all= it needs is a DISCUSS from one of the IESG members ! :-) If the WG consensus is that "seamless" succinctly captures the essence of S= BFD then we could leave it as is. However, i propose that we replace it wit= h something more meaningful, that hopefully starts with "S" so that its sti= ll "SBFD" because you dont want all developers out there to rename their va= riables and function names now. Cheers, Manav On Tue, May 3, 2016 at 5:46 AM, Sam Aldrin > wrote: Think there was some discussion during the extension of the charter for thi= s work item. Not sure what the conclusion was exactly. IIRC, we found the c= ool term 'seamless' and tried to fit in SBFD work into that definition, rat= her than finding a term fitting the definition. Not sure if stateless is complete enough, but I have no opinion either way.= On the contrary, someone asked if S means SDN :D Sam Sent from my iPhone > On May 2, 2016, at 4:52 PM, Manav Bhatia > wrote: > > Hi, > > Does it make sense to change "seamless BFD" with "stateless BFD" in the d= ocuments? Its very convoluted to explain whats "seamless" about S-BFD. > > We called it "seamless" because it was simple and largely stateless. > > Any suggestions? > > Cheers, Manav --_000_5D4A869A1EDD4EF891688F7AF7086F14ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'm with Les -- that ship has sailed almost exactly two years ago, whe= n we had a most thorough and lengthy discussion about it:

I, for one, use "S-BFD" (as there are really many fitting qu= alifiers that start with "S". The docs explain the why for the &q= uot;seamless" name, and the seam being removed. 

Thanks!

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On May 3, 2016, at 02:14, Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote:

This was debated at lengt= h 2 years ago and somehow we ended up with “seamless”.

While I am no way investe= d in “seamless” – the IGP drafts have already proceeded t= o IESG review – and in the case of the OSPF draft at least, the word = “seamless” is used multiple times. So you would have to insure “seamless”= is expunged everywhere it needs to be.

Given this wasn’t s= hot down 2 years ago it seems rather late in the game to make such a change= . Can’t we simply live with what we have?

 <= /p>

If nothing else it will m= ake a great story to tell your overly nerdy grandchildren. J

 <= /p>

   Les

 <= /p>

 <= /p>

 <= /p>

From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.or= g] On Behalf Of Manav Bhatia
Sent: Monday, May 02, 2016 9:25 PM
To: Sam Aldrin
Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-base@ietf.org; bfd-chairs@ietf.org
Subject: Re: Replace "seamless" with "stateless"=

 

I agree that stateless may not be complete enough, a= nd just highlights one aspect of SBFD -- however, its better than "sea= mless", which i grudgingly concede, may sound pretty nifty, but means = and conveys almost nothing.

 

I dont think its too late into the WG cycle to chang= e the name -- heck, all it needs is a DISCUSS from one of the IESG members = ! :-)

 

If the WG consensus is that "seamless" suc= cinctly captures the essence of SBFD then we could leave it as is. However,= i propose that we replace it with something more meaningful, that hopefull= y starts with "S" so that its still "SBFD" because you dont want all developers out there to rename their variables and funct= ion names now.

 

Cheers, Manav

 

On Tue, May 3, 2016 at 5:46 AM, Sam Aldrin <aldrin.ietf@gmail.com= > wrote:

Think there was some discussion during the extension= of the charter for this work item. Not sure what the conclusion was exactl= y. IIRC, we found the cool term 'seamless' and tried to fit in SBFD work in= to that definition, rather than finding a term fitting the definition.

Not sure if stateless is complete enough, but I have no opinion either way.= On the contrary, someone asked if S means SDN :D

Sam

Sent from my iPhone


> On May 2, 2016, at 4:52 PM, Manav Bhatia <manavbhatia@gmail.com> wrote:
>
> Hi,
>
> Does it make sense to change "seamless BFD" with "state= less BFD" in the documents? Its very convoluted to explain whats "= ;seamless" about S-BFD.
>
> We called it "seamless" because it was simple and largely st= ateless.
>
> Any suggestions?
>
> Cheers, Manav

 

--_000_5D4A869A1EDD4EF891688F7AF7086F14ciscocom_-- From nobody Tue May 3 02:31:47 2016 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 5968D12D1AB; Tue, 3 May 2016 02:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 2ZEbYj-tY0FR; Tue, 3 May 2016 02:31:40 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7120612B048; Tue, 3 May 2016 02:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1472; q=dns/txt; s=iport; t=1462267900; x=1463477500; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nx0l9hDXyZtFVD72yfAQEtNjeQ/dVV+R/sn//GodGJQ=; b=cY9t9nRhhjEAXQqIyxPFcQ7yQSbE4z8kZbdK5yOD7K1EWHSRkARC5XNd m1pLMWtfBQapXGsBb4lLrIqqqhSl3zz1sOv+v83M4AJatIDxjuPe9FKwU uWo7qTQ+0P7zVpC4zQR8byZKhCrfCGBb36Bz/hMKOLkGXQ2A4RSYBlXY0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQBubyhX/4QNJK1dgzhTfbgBgg8BD?= =?us-ascii?q?YF2IoVuAoE/OBQBAQEBAQEBZSeEQQEBAQMBeQULAgEIDgouMiUCBA4FiCIIDrp?= =?us-ascii?q?iAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGIYF2CIJPhBERAU6CeYIuBYd4hhiKB?= =?us-ascii?q?gGFe4gcCoFehE2IXY8xAR4BAUKCNoE1bAGHBoE1AQEB?= X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="scan'208";a="268131566" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 May 2016 09:31:39 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u439VdDV016034 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 09:31:39 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 05:31:38 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 3 May 2016 05:31:38 -0400 From: "Carlos Pignataro (cpignata)" To: Mirja Kuehlewind Subject: =?iso-8859-1?Q?Re:_Mirja_K=FChlewind's_No_Objection_on_draft-ietf-bfd-sea?= =?iso-8859-1?Q?mless-use-case-06:_(with_COMMENT)?= Thread-Topic: =?iso-8859-1?Q?Mirja_K=FChlewind's_No_Objection_on_draft-ietf-bfd-seamles?= =?iso-8859-1?Q?s-use-case-06:_(with_COMMENT)?= Thread-Index: AQHRpRBzFLkOi/gIWUu4JdbETqKt0Z+m8w6j Date: Tue, 3 May 2016 09:31:38 +0000 Message-ID: References: <20160503075019.7441.21628.idtracker@ietfa.amsl.com> In-Reply-To: <20160503075019.7441.21628.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 09:31:42 -0000 Thank you for this comment, Mirja. You have a good point, we will add it.=20 Thumb typed by Carlos Pignataro. Excuze typofraphicak errows > On May 3, 2016, at 03:50, Mirja Kuehlewind wrote: >=20 > Mirja K=FChlewind has entered the following ballot position for > draft-ietf-bfd-seamless-use-case-06: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-use-case/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > While this document has a security requirement, I believe there is also a > risk of misconfiguration: if no handshake is performed, a node might send > S-BFD packets to a receiver that does not exists or is not aware of it or > sits at a different part of the network that is somewhere else than > expected which can overload the network accidentally. Should this be > mentioned in this doc (or somewhere else... or both)? >=20 >=20 From nobody Tue May 3 02:35:14 2016 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 A0B8812D1B6; Tue, 3 May 2016 02:35:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" Subject: =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-bfd-seaml?= =?utf-8?q?ess-base-09=3A_=28with_DISCUSS=29?= X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503093512.7446.68991.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 02:35:12 -0700 Archived-At: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 09:35:12 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-bfd-seamless-base-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- As S-BFD has no initiation process anymore it is not guarenteed that the receiver/responder actually exists. That means that packets could float (uncontrolled) in the network or even outside of the adminstrative domain (e.g. due to configuration mistakes). From my point of view this document should recommend/require two things: 1) A maximum number of S-BFD packet that is allow to be send without getting a response (maybe leading to a local error report). 2) Egress filtering at the adminstrative border of the domain that uses S-BFD to make sure that no S-BFD packets leave the domain. From nobody Tue May 3 02:38:24 2016 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 5F8E412D68D for ; Tue, 3 May 2016 02:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ionosnetworks-com.20150623.gappssmtp.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 k3seVjDcIexD for ; Tue, 3 May 2016 02:38:20 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 ED2FA12D1C1 for ; Tue, 3 May 2016 02:38:19 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id o133so16475613vka.0 for ; Tue, 03 May 2016 02:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ionosnetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=tcmpP4ggtw3XhCQDIE2RLM/Z0E73brMScAHLGeJloCQ=; b=Xjyd8wswq3UjhUwweZj+Jj09rWWci3kqLSVHIhc0sM9G17W5JtCJ0gxpnflvpKktk+ On61uVm4jcChnkmu5fRI9hOw4I8CtTdXV+FAo20d8j6tALDIME+UazMPjct3dhbKAeFO /Gc4Sv/uiTyTy6yv6WjW/YgI6DyxJaoaw5omKsbANo43YoOQI287s0SAXDppzx4H1QE0 pxZgp4Kp+1HwTJY+UhXqK9MzPPYMJx9SwUJAy88PuU2X61PeWJwDNmhuCWqMtJCwQ4c3 GC728bhfr+20YZqjrQXwXziV45opbaxIXA7x3LeifRtrUXs7kcuZwHbgRcQW26tyZKqf KOHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=tcmpP4ggtw3XhCQDIE2RLM/Z0E73brMScAHLGeJloCQ=; b=IQpkQ6RR/n1dhVgKKZMp7XKzEj1Zel0tKD+JZzppHYre99G7nA10X6J0FguLQx/y0l HPYGHEhCi1FzINFXSRdpg8lled/skfh8wfLt9kc18zrbGxhF6ZL79hOpd8MxuIAPpslq 2vCK5ri+fFGmT6bPWgoSGakVjxY67jj8JoJq+ueiNgF9AGXo1nR7oWPzKUo4wgV0ITjD A9i3oAaUbrS2vqNBsESZhXIgMkmcGX2gl1COd7XVBQeLDL0n8+K9YGdU59Cq8EBkS88W 5/KUTSXCSZb1jFmTsJ6up9ORW6tfu83WWQQ+ymmEouRE08jpgw3cLzm7/ZbMaHEUNJ1+ Mzmw== X-Gm-Message-State: AOPr4FWdm8tNI6oyRJmQIPmb1YCqKF7P//+xq29L/r0JR7s6md9s6l4YzJI9qNcTCZte6ecQifDhY2SkPPqrUg== MIME-Version: 1.0 X-Received: by 10.176.5.194 with SMTP id e60mr552617uae.61.1462268298875; Tue, 03 May 2016 02:38:18 -0700 (PDT) Received: by 10.31.32.197 with HTTP; Tue, 3 May 2016 02:38:18 -0700 (PDT) In-Reply-To: <5D4A869A-1EDD-4EF8-9168-8F7AF7086F14@cisco.com> References: <5D4A869A-1EDD-4EF8-9168-8F7AF7086F14@cisco.com> Date: Tue, 3 May 2016 15:08:18 +0530 Message-ID: Subject: Re: Replace "seamless" with "stateless" From: Manav Bhatia To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=94eb2c1233348574140531ecde5e Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 09:38:23 -0000 --94eb2c1233348574140531ecde5e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am also with Les -- it'll make a great story to tell the kids some day on what we were sniffing when we came up with "seamless" ! :-) Matter closed. Lets move on to addressing the IESG comments now. Cheers, Manav On Tue, May 3, 2016 at 2:56 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > I'm with Les -- that ship has sailed almost exactly two years ago, when w= e > had a most thorough and lengthy discussion about it: > https://www.ietf.org/mail-archive/web/rtg-bfd/current/msg02051.html > > I, for one, use "S-BFD" (as there are really many fitting qualifiers that > start with "S". The docs explain the why for the "seamless" name, and the > seam being removed. > > Thanks! > > Thumb typed by Carlos Pignataro. > Excuze typofraphicak errows > > On May 3, 2016, at 02:14, Les Ginsberg (ginsberg) > wrote: > > This was debated at length 2 years ago and somehow we ended up with > =E2=80=9Cseamless=E2=80=9D. > > While I am no way invested in =E2=80=9Cseamless=E2=80=9D =E2=80=93 the IG= P drafts have already > proceeded to IESG review =E2=80=93 and in the case of the OSPF draft at l= east, the > word =E2=80=9Cseamless=E2=80=9D is used multiple times. So you would have= to insure > =E2=80=9Cseamless=E2=80=9D is expunged everywhere it needs to be. > > Given this wasn=E2=80=99t shot down 2 years ago it seems rather late in t= he game > to make such a change. Can=E2=80=99t we simply live with what we have? > > > > If nothing else it will make a great story to tell your overly nerdy > grandchildren. J > > > > Les > > > > > > > > *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org > ] *On Behalf Of *Manav Bhatia > *Sent:* Monday, May 02, 2016 9:25 PM > *To:* Sam Aldrin > *Cc:* rtg-bfd@ietf.org; draft-ietf-bfd-seamless-base@ietf.org; > bfd-chairs@ietf.org > *Subject:* Re: Replace "seamless" with "stateless" > > > > I agree that stateless may not be complete enough, and just highlights on= e > aspect of SBFD -- however, its better than "seamless", which i grudgingly > concede, may sound pretty nifty, but means and conveys almost nothing. > > > > I dont think its too late into the WG cycle to change the name -- heck, > all it needs is a DISCUSS from one of the IESG members ! :-) > > > > If the WG consensus is that "seamless" succinctly captures the essence of > SBFD then we could leave it as is. However, i propose that we replace it > with something more meaningful, that hopefully starts with "S" so that it= s > still "SBFD" because you dont want all developers out there to rename the= ir > variables and function names now. > > > > Cheers, Manav > > > > On Tue, May 3, 2016 at 5:46 AM, Sam Aldrin wrote: > > Think there was some discussion during the extension of the charter for > this work item. Not sure what the conclusion was exactly. IIRC, we found > the cool term 'seamless' and tried to fit in SBFD work into that > definition, rather than finding a term fitting the definition. > > Not sure if stateless is complete enough, but I have no opinion either > way. On the contrary, someone asked if S means SDN :D > > Sam > > Sent from my iPhone > > > > On May 2, 2016, at 4:52 PM, Manav Bhatia wrote: > > > > Hi, > > > > Does it make sense to change "seamless BFD" with "stateless BFD" in the > documents? Its very convoluted to explain whats "seamless" about S-BFD. > > > > We called it "seamless" because it was simple and largely stateless. > > > > Any suggestions? > > > > Cheers, Manav > > > > --94eb2c1233348574140531ecde5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am also with Les -- it'll make a great story to tell= the kids some day on what we were sniffing when we came up with "seam= less" ! :-)

Matter closed. Lets move on to addressi= ng the IESG comments now.

Cheers, Manav


On Tue, May 3, 2016 at 2:56 PM, Carlos Pignataro (cpignat= a) <cpignata@cisco.com> wrote:
I'm with Les -- that ship has sailed almost exactly two years ago,= when we had a most thorough and lengthy discussion about it:

I, for one, use "S-BFD" (as there are really many fitting qu= alifiers that start with "S". The docs explain the why for the &q= uot;seamless" name, and the seam being removed.=C2=A0

Thanks!

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On May 3, 2016, at 02:14, Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote:

This was debated at lengt= h 2 years ago and somehow we ended up with =E2=80=9Cseamless=E2=80=9D.

While I am no way investe= d in =E2=80=9Cseamless=E2=80=9D =E2=80=93 the IGP drafts have already proce= eded to IESG review =E2=80=93 and in the case of the OSPF draft at least, t= he word =E2=80=9Cseamless=E2=80=9D is used multiple times. So you would have to insure =E2=80=9Cseamless=E2= =80=9D is expunged everywhere it needs to be.

Given this wasn=E2=80=99t= shot down 2 years ago it seems rather late in the game to make such a chan= ge. Can=E2=80=99t we simply live with what we have?

=C2=A0

If nothing else it will m= ake a great story to tell your overly nerdy grandchildren. J

=C2=A0

=C2=A0=C2=A0 Les

=C2=A0

=C2=A0

=C2=A0

From: Rtg-bfd = [mailto:rtg-b= fd-bounces@ietf.org] On Behalf Of Manav Bhatia
Sent: Monday, May 02, 2016 9:25 PM
To: Sam Aldrin
Cc: rtg-bfd@ie= tf.org; draft-ietf-bfd-seamless-base@ietf.org; bfd-chairs@ietf.org
Subject: Re: Replace "seamless" with "stateless"=

=C2=A0

I agree that stateless may not be complete enough, a= nd just highlights one aspect of SBFD -- however, its better than "sea= mless", which i grudgingly concede, may sound pretty nifty, but means = and conveys almost nothing.

=C2=A0

I dont think its too late into the WG cycle to chang= e the name -- heck, all it needs is a DISCUSS from one of the IESG members = ! :-)

=C2=A0

If the WG consensus is that "seamless" suc= cinctly captures the essence of SBFD then we could leave it as is. However,= i propose that we replace it with something more meaningful, that hopefull= y starts with "S" so that its still "SBFD" because you dont want all developers out there to rename their variables and funct= ion names now.

=C2=A0

Cheers, Manav

=C2=A0

On Tue, May 3, 2016 at 5:46 AM, Sam Aldrin <aldrin.ietf@gmail.com= > wrote:

Think there was some discussion during the extension= of the charter for this work item. Not sure what the conclusion was exactl= y. IIRC, we found the cool term 'seamless' and tried to fit in SBFD= work into that definition, rather than finding a term fitting the definition.

Not sure if stateless is complete enough, but I have no opinion either way.= On the contrary, someone asked if S means SDN :D

Sam

Sent from my iPhone


> On May 2, 2016, at 4:52 PM, Manav Bhatia <manavbhatia@gmail.com> wrote:
>
> Hi,
>
> Does it make sense to change "seamless BFD" with "state= less BFD" in the documents? Its very convoluted to explain whats "= ;seamless" about S-BFD.
>
> We called it "seamless" because it was simple and largely st= ateless.
>
> Any suggestions?
>
> Cheers, Manav

=C2=A0


--94eb2c1233348574140531ecde5e-- From nobody Tue May 3 02:43:36 2016 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 95EF212D196 for ; Tue, 3 May 2016 02:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ionosnetworks-com.20150623.gappssmtp.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 Aa7uj_B12odP for ; Tue, 3 May 2016 02:43:31 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 9774112D688 for ; Tue, 3 May 2016 02:43:31 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id m188so16537871vka.1 for ; Tue, 03 May 2016 02:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ionosnetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=sCQh0bMJWPjwSBq68lTT9a1HIZIRNgSG9mOgywGN8QU=; b=12uGa14wMuCNKAoGZOnIbGc8SJIgOkZFGy/TsYNeABN4/iPHUcmEJQJOCvXfFfWnHA /et7wD338z9q/KT6JB6FTYqO1YaelCYUKbXCXfAbe9KC2kwbKZ1dmb/i0HzKeiATJ3Wp AeYQJPWKHQDIvnCrPkD4eEKjjt8NBgCzt+zdAVrpd0kKDRe+2HHivTohtL9x2JP0Ky/a Oz9heYtvIXeBeuxW16UxOsO/7xGBGGinXKg7JSIOA8G60ZEgOYC99roErOt9YG/fSjJ9 WoRyhmEBOXXFuImhtB27Z3EQOOCVpqfj1oOoM6I2YUJ7HV4OqgebGSCBRWiT81q5oBaU 9vhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=sCQh0bMJWPjwSBq68lTT9a1HIZIRNgSG9mOgywGN8QU=; b=N5/V68C5hOZHnz6XPiXEh40Fkb5dYUtwhJHamPdWn7x2HZy7/bpndQeg5LOXyLVpeD d0FpsVM8bLbs80j5zGB4aM7T2SutaeF5okXOSBLAVQy5dyYdhX+1dT3q9y7PLVcpD5rd bcuayKNsr0hURAal+2OsL0TjIsPUhwK8STjEWXVb32DJbnCKF19gVMqmkLvrg0lJNY6d ol9lH8jP6Za8gXA66GGxwVQrKKp1Ps12+JTtdUeKOw/UDxpozhEEKywLUMlEZBpaTyJT Wq6/BldQZM9a4dSrbU8KaN/4V0HlLNnH39oB6wB0/+bsabEhDeAc2q3PxUwjYN197UXy vFpQ== X-Gm-Message-State: AOPr4FUFrSwTSuiLdaj7zr+MrpJu7IkGzbjXBPp2cMEPkNzoreELK9QEaOw+kVEzGUT+/z7je2QSKBFzd+AkNA== MIME-Version: 1.0 X-Received: by 10.159.40.132 with SMTP id d4mr610068uad.21.1462268610625; Tue, 03 May 2016 02:43:30 -0700 (PDT) Received: by 10.31.32.197 with HTTP; Tue, 3 May 2016 02:43:30 -0700 (PDT) In-Reply-To: <20160503093512.7446.68991.idtracker@ietfa.amsl.com> References: <20160503093512.7446.68991.idtracker@ietfa.amsl.com> Date: Tue, 3 May 2016 15:13:30 +0530 Message-ID: Subject: =?UTF-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf=2Dbfd=2Dsea?= =?UTF-8?Q?mless=2Dbase=2D09=3A_=28with_DISCUSS=29?= From: Manav Bhatia To: Mirja Kuehlewind Content-Type: multipart/alternative; boundary=94eb2c123e281a5d1e0531ecf188 Archived-At: Cc: The IESG , rtg-bfd@ietf.org, draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 09:43:34 -0000 --94eb2c123e281a5d1e0531ecf188 Content-Type: text/plain; charset=UTF-8 Hi Mirja, > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > As S-BFD has no initiation process anymore it is not guarenteed that the > receiver/responder actually exists. That means that packets could float > (uncontrolled) in the network or even outside of the adminstrative domain > (e.g. due to configuration mistakes). From my point of view this document > should recommend/require two things: > > 1) A maximum number of S-BFD packet that is allow to be send without > getting a response (maybe leading to a local error report). > > 2) Egress filtering at the adminstrative border of the domain that uses > S-BFD to make sure that no S-BFD packets leave the domain. > > > How different is this from having a regular BFD/OSPF/ISIS speaker misconfigured to to peer with a router that it is not supposed to peer with. In such cases OSPF/ISIS, etc will continue sending HELLOs. So why do anything different for S-BFD. Moreover, the whole idea of rate-limiting S-BFD packets is fundamentally incorrect. Its possible that the SBFD peer that router is trying to send S-BFD packets to may be down for some reason. In such cases you will NOT receive a response. Its only when it comes up that you will get a response. Am i missing something here? Cheers, Manav --94eb2c123e281a5d1e0531ecf188 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mirja,


----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

As S-BFD has no initiation process anymore it is not guarenteed that the receiver/responder actually exists. That means that packets could float
(uncontrolled) in the network or even outside of the adminstrative domain (e.g. due to configuration mistakes). From my point of view this document should recommend/require two things:

1) A maximum number of S-BFD packet that is allow to be send without
getting a response (maybe leading to a local error report).

2) Egress filtering at the adminstrative border of the domain that uses
S-BFD to make sure that no S-BFD packets leave the domain.



How different is this from having a re= gular BFD/OSPF/ISIS speaker misconfigured to to peer with a router that it = is not supposed to peer with. In such cases OSPF/ISIS, etc will continue se= nding HELLOs. So why do anything different for S-BFD.

<= div>Moreover, the whole idea of rate-limiting S-BFD packets is fundamentall= y incorrect. Its possible that the SBFD peer that router is trying to send = S-BFD packets to may be down for some reason. In such cases you will NOT re= ceive a response. Its only when it comes up that you will get a response.

Am i missing something here?

Cheers, Manav

--94eb2c123e281a5d1e0531ecf188-- From nobody Tue May 3 02:46:19 2016 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 0527D12D6B2; Tue, 3 May 2016 02:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 IdD9OWk6lNZy; Tue, 3 May 2016 02:46:16 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B8F12D688; Tue, 3 May 2016 02:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4992; q=dns/txt; s=iport; t=1462268776; x=1463478376; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Dqh2Ax3LvRooB8yQCKvF3hRJ1onKTJvogZYhCmzkGPM=; b=gfOt0TyR1TuCblhPxaC2vwPdtV9BvdVWF/d0CXxYbQNEDiXRdokW4Luh 9SFvn4ByYvZwWkx7VZST3g/jISJSU1WCBn+8lbfypL5wtJfWd1rIZgjnH YrvOH3EXN3+qZCvq9dKs1G0/qFByhKqfcgnd05lOsxD0ehLD87q+veeCf k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANBQAZcyhX/4sNJK1dgziBULUdgmSCH?= =?us-ascii?q?YF2hhACgT86EgEBAQEBAQFlJ4RCAQEEeRACAQgEOwcyFBECBA4FiCq6eAEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARWGIYF2gleHaoIuBYd4hhiKBgGOF48SiUCFcQEnD?= =?us-ascii?q?C+Da2yIPAEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="scan'208,217";a="268819607" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 May 2016 09:45:53 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u439jrYP003334 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 09:45:53 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 05:45:52 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 3 May 2016 05:45:52 -0400 From: "Carlos Pignataro (cpignata)" To: Manav Bhatia Subject: =?iso-8859-1?Q?Re:_Mirja_K=FChlewind's_Discuss_on_draft-ietf-bfd-seamless?= =?iso-8859-1?Q?-base-09:_(with_DISCUSS)?= Thread-Topic: =?iso-8859-1?Q?Mirja_K=FChlewind's_Discuss_on_draft-ietf-bfd-seamless-bas?= =?iso-8859-1?Q?e-09:_(with_DISCUSS)?= Thread-Index: AQHRpR8YB75iFhnPVECZQ0i//enE0Z+nOU8A//+9nJI= Date: Tue, 3 May 2016 09:45:52 +0000 Message-ID: References: <20160503093512.7446.68991.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_C21163D1D537429AA5DB7289DC65413Fciscocom_" MIME-Version: 1.0 Archived-At: Cc: Mirja Kuehlewind , The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 09:46:18 -0000 --_000_C21163D1D537429AA5DB7289DC65413Fciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Manav, A router not configured for S-BFD can be more likely to receive S-BFD packe= ts. We can call that out. Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On May 3, 2016, at 05:43, Manav Bhatia > wrote: Hi Mirja, ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- As S-BFD has no initiation process anymore it is not guarenteed that the receiver/responder actually exists. That means that packets could float (uncontrolled) in the network or even outside of the adminstrative domain (e.g. due to configuration mistakes). From my point of view this document should recommend/require two things: 1) A maximum number of S-BFD packet that is allow to be send without getting a response (maybe leading to a local error report). 2) Egress filtering at the adminstrative border of the domain that uses S-BFD to make sure that no S-BFD packets leave the domain. How different is this from having a regular BFD/OSPF/ISIS speaker misconfig= ured to to peer with a router that it is not supposed to peer with. In such= cases OSPF/ISIS, etc will continue sending HELLOs. So why do anything diff= erent for S-BFD. Moreover, the whole idea of rate-limiting S-BFD packets is fundamentally in= correct. Its possible that the SBFD peer that router is trying to send S-BF= D packets to may be down for some reason. In such cases you will NOT receiv= e a response. Its only when it comes up that you will get a response. Am i missing something here? Cheers, Manav --_000_C21163D1D537429AA5DB7289DC65413Fciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Manav,

A router not configured for S-BFD can be mor= e likely to receive S-BFD packets. We can call that out. 

Excuze typofraphicak errows

On May 3, 2016, at 05:43, Manav Bhatia <manav@ionosnetworks.com> wrote:

Hi Mirja,


----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

As S-BFD has no initiation process anymore it is not guarenteed that the receiver/responder actually exists. That means that packets could float
(uncontrolled) in the network or even outside of the adminstrative domain (e.g. due to configuration mistakes). From my point of view this document should recommend/require two things:

1) A maximum number of S-BFD packet that is allow to be send without
getting a response (maybe leading to a local error report).

2) Egress filtering at the adminstrative border of the domain that uses
S-BFD to make sure that no S-BFD packets leave the domain.



How different is this from having a regular BFD/OSPF/ISIS speaker misc= onfigured to to peer with a router that it is not supposed to peer with. In= such cases OSPF/ISIS, etc will continue sending HELLOs. So why do anything= different for S-BFD.

Moreover, the whole idea of rate-limiting S-BFD packets is fundamental= ly incorrect. Its possible that the SBFD peer that router is trying to send= S-BFD packets to may be down for some reason. In such cases you will NOT r= eceive a response. Its only when it comes up that you will get a response.

Am i missing something here?

Cheers, Manav

--_000_C21163D1D537429AA5DB7289DC65413Fciscocom_-- From nobody Tue May 3 02:46:39 2016 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 3175612D6B2; Tue, 3 May 2016 02:46:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" Subject: =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ietf-bfd-?= =?utf-8?q?seamless-ip-04=3A_=28with_COMMENT=29?= X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503094626.7542.81246.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 02:46:26 -0700 Archived-At: Cc: rtg-bfd@ietf.org, bfd-chairs@ietf.org, draft-ietf-bfd-seamless-ip@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 09:46:28 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-bfd-seamless-ip-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This part is unclear to me: "It is, however, possible for an SBFDInitiator to carefully set "your discriminator" and TTL fields to perform a continuity test towards a target, but to a transit network node and not to the target itself. [...] This also requires S-BFD control packets not be dropped by the responder node due to TTL expiry. Thus implementations on the responder MUST allow received S-BFD control packets taking TTL expiry exception path to reach corresponding reflector BFD session." You basically perform a traceroute with (S-)BFD, right? Why do you need the last sentence? Wouldn't it be okay, if the packet get dropped by the responder, to simply re-send with a higher TTL? From nobody Tue May 3 02:52:58 2016 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 A503C12D6C9; Tue, 3 May 2016 02:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 8H3pjx1QrLav; Tue, 3 May 2016 02:52:53 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA0512D6C1; Tue, 3 May 2016 02:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2070; q=dns/txt; s=iport; t=1462269172; x=1463478772; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xRPe0+BPu28RfBMapSsP16yWumPSESoLPKdoDxBBAlc=; b=hjuyuyxfeEifareBwevjh8sbpVymG5JxnTEmBtNtWJ1s+dpsXvSDhgCP R99+rh+Tafo8+oDpmjIj2Qci+dkWbGFtcvQWVnMw2qVQOLaZ3UG88NwzS BD3NjrgojfgCDWBnqg0oEWqv7X4zKIgKfMC01wyK9L26f4MphWwtCG9vY A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQCncyhX/4gNJK1dgzhTfbgBgg8BD?= =?us-ascii?q?YF2IoVuAoE/OBQBAQEBAQEBZSeEQQEBAQMBeQULAgEIDgouMiUCBA4FiCIIDrp?= =?us-ascii?q?pAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGIYF2CIJPhBERARwygnmCLgWHeIYYh?= =?us-ascii?q?RSEcgGFe4gcgWiETYhdjzEBHgEBQoI2gTVsAYcGgTUBAQE?= X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="scan'208";a="98497313" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 May 2016 09:52:51 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u439qpXx023297 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 09:52:52 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 05:52:50 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 3 May 2016 05:52:50 -0400 From: "Carlos Pignataro (cpignata)" To: Mirja Kuehlewind Subject: =?iso-8859-1?Q?Re:_Mirja_K=FChlewind's_No_Objection_on_draft-ietf-bfd-sea?= =?iso-8859-1?Q?mless-ip-04:_(with_COMMENT)?= Thread-Topic: =?iso-8859-1?Q?Mirja_K=FChlewind's_No_Objection_on_draft-ietf-bfd-seamles?= =?iso-8859-1?Q?s-ip-04:_(with_COMMENT)?= Thread-Index: AQHRpSCswv3H3cc7k0Siga4id4/v2J+m+Nq0 Date: Tue, 3 May 2016 09:52:50 +0000 Message-ID: <28E62436-DE93-4164-9D03-9FFA7AD04B3F@cisco.com> References: <20160503094626.7542.81246.idtracker@ietfa.amsl.com> In-Reply-To: <20160503094626.7542.81246.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-bfd-seamless-ip@ietf.org" , The IESG , "rtg-bfd@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 09:52:54 -0000 Hi Mirja, Thanks for the question, please see inline.=20 Thumb typed by Carlos Pignataro. Excuze typofraphicak errows > On May 3, 2016, at 05:46, Mirja Kuehlewind wrote: >=20 > Mirja K=FChlewind has entered the following ballot position for > draft-ietf-bfd-seamless-ip-04: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > This part is unclear to me: > "It is, however, possible for an > SBFDInitiator to carefully set "your discriminator" and TTL fields to > perform a continuity test towards a target, but to a transit network > node and not to the target itself. [...]=20 > This also requires S-BFD control packets not be dropped by the > responder node due to TTL expiry. Thus implementations on the > responder MUST allow received S-BFD control packets taking TTL expiry > exception path to reach corresponding reflector BFD session." >=20 > You basically perform a traceroute with (S-)BFD, right? Almost. We are performing an S-BFD-aware traceroute with S-BFD.=20 > Why do you need > the last sentence? Wouldn't it be okay, if the packet get dropped by the > responder, to simply re-send with a higher TTL? >=20 No. Basically we need the router to process the pocket as S-BFD (i.e. Inter= cept it for processing on TTL expiry). Otherwise, we would get an ICMP back= while what we are after is an S-BFD back.=20 Thanks! Carlos.=20 >=20 From nobody Tue May 3 04:14:38 2016 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 A3FF812D744; Tue, 3 May 2016 04:14:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" Subject: Stephen Farrell's No Objection on draft-ietf-bfd-seamless-base-09: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503111437.7481.82666.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 04:14:37 -0700 Archived-At: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 11:14:37 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-bfd-seamless-base-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Section 11: I've had discussions with people from time to time about BFD and security. I think I've heard the claim made that authentication was too expensive. (Note: I am not saying that I accept that as a valid claim, but that's a different issue:-) Anyway, wouldn't the same issues apply here if they do to classical BFD? If not, great, and I'll quote you next time someone says crypto is too expensive. But if such claims are also to be made here, then why would you be specifying something that will not be used? - Do the implementations that are in-progress implement the BFD authentication schemes for S-BFD? - Why not recommend that the weaker options from rfc5880 not be used? At least saying to not send passwords in clear over networks would be a good thing. - This document could do with an editing pass. There are quite a few minor grammatical issues that make this a harder read. I guess the RFC editor will fix those though, and they're non-fatal, but seems like a pity to not have done that already. From nobody Tue May 3 04:26:05 2016 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 8A7F712D1C2 for ; Tue, 3 May 2016 04:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ionosnetworks-com.20150623.gappssmtp.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 d2VvK4lvd-o1 for ; Tue, 3 May 2016 04:25:59 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 36F8D12D1CF for ; Tue, 3 May 2016 04:25:57 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id c189so18921041vkb.3 for ; Tue, 03 May 2016 04:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ionosnetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=NBeYguY23oWC+N4QcuiI7e6b7KPN+ALG59KeUyG9sWM=; b=LDkypX+xnnzM2MoYdoky14VFBQ+5ev8uh7VZcgQu0OhLqxJdQmkglCdG0UJETRFJIK 4ck661CoN2eTmGjOCtliWiyO/Y0Hh1rq+6uJ+mQ+C+U06GfHPDNCQEECsNgxIke3De6Q nplHvjiCekumtBpYiBd5xv7yvJId6jl9UnPqsMYMlorLGTLNXQRgwnZV+hHWzvA4DXT1 AXrEv6LOI0I9usLu/c/LM/4ZrxCNvvNKlmd18q2AOVarl9si4WaTpnE++6RVMD9eh2/K wQka6ReaixVqDN/uRV3KWJEb7KBiNmRPUApwlKvGUQcC58NUrR+jjpP7LBKZrdmzDFhQ E9WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=NBeYguY23oWC+N4QcuiI7e6b7KPN+ALG59KeUyG9sWM=; b=NMc3MzVCdS1dtcFiBiwWmBQlBavwCbSjS1hq3t848z6ZWT3qcP/ZZFhbTgmXDKK3AD V59RepEeI0Mw8n12tM/4JH5X38nE+j0dKfmIi2Ues7LcoocbgOpQLFCTUW63lQ/curjP wWQjDtHC90ri3nBJ6/hjOhTL1dJ3Y98En7U+rmRrq7QxO49PfUrsH8QoKWjD8H8SYiHZ sBoenvn5jBhQtc33qBuPclZz52r1QZX2pefVknPEhCN1JrC4+YlRGqcwtwgIBjBtjOgd dkeXtFbmlkmul/a4jIUiYYJDlmZmKunGFypEieVayFZZC3odQrPiBq/2vZqxKF8ghtd3 IsNA== X-Gm-Message-State: AOPr4FUoTASau2NlfwtzO38OJIFbHXZaWjmOASYJKKK/MvuWIYf4FjKZ4YQI3BvIPT7+lmp1hlgOeu0wH6AO3Q== MIME-Version: 1.0 X-Received: by 10.176.5.194 with SMTP id e60mr737546uae.61.1462274756242; Tue, 03 May 2016 04:25:56 -0700 (PDT) Received: by 10.31.32.197 with HTTP; Tue, 3 May 2016 04:25:56 -0700 (PDT) In-Reply-To: <20160503111437.7481.82666.idtracker@ietfa.amsl.com> References: <20160503111437.7481.82666.idtracker@ietfa.amsl.com> Date: Tue, 3 May 2016 16:55:56 +0530 Message-ID: Subject: Re: Stephen Farrell's No Objection on draft-ietf-bfd-seamless-base-09: (with COMMENT) From: Manav Bhatia To: Stephen Farrell Content-Type: multipart/alternative; boundary=94eb2c1233346912ad0531ee5fd7 Archived-At: Cc: The IESG , rtg-bfd@ietf.org, draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 11:26:00 -0000 --94eb2c1233346912ad0531ee5fd7 Content-Type: text/plain; charset=UTF-8 Hi Stephen, Thanks for the review! > > - Section 11: I've had discussions with people from time > to time about BFD and security. I think I've heard the > claim made that authentication was too expensive. (Note: > I am not saying that I accept that as a valid claim, but > that's a different issue:-) Anyway, wouldn't the same > issues apply here if they do to classical BFD? If not, > There is a subtle difference -- with SBFD you may NOT send periodic BFD packets every milli-second, the way its done in traditional BFD. > great, and I'll quote you next time someone says crypto > is too expensive. But if such claims are also to be made > here, then why would you be specifying something that > will not be used? > > - Do the implementations that are in-progress implement > the BFD authentication schemes for S-BFD? > I have no idea about implementations that are in-progress. I'll let my co-authors chime in if they are aware of something. > > - Why not recommend that the weaker options from rfc5880 > not be used? At least saying to not send passwords in > clear over networks would be a good thing. > Most people use clear text passwords to avoid sessions coming up because of configuration issues and not necessarily to "protect" their sessions. There is thus a value in retaining clear text passwords. Cheers, Manav --94eb2c1233346912ad0531ee5fd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephen,

Thanks for the review!
<= div>



- Section 11: I've had discussions with people from time
to time about BFD and security. I think I've heard the
claim made that authentication was too expensive. (Note:
I am not saying that I accept that as a valid claim, but
that's a different issue:-)=C2=A0 Anyway, wouldn't the same
issues apply here if they do to classical BFD?=C2=A0 If not,

There is a subtle difference -- with SBFD you may NOT= send periodic BFD packets every milli-second, the way its done in traditio= nal BFD.

=C2=A0

- Why not recommend that the weaker options from rfc5880
not be used? At least saying to not send passwords in
clear over networks would be a good thing.

<= div>Most people use clear text passwords to avoid sessions coming up becaus= e of configuration issues and not necessarily to "protect" their = sessions. There is thus a value in retaining clear text passwords.

Cheers, Manav
--94eb2c1233346912ad0531ee5fd7-- From nobody Tue May 3 04:34:26 2016 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 A5D6112D755; Tue, 3 May 2016 04:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 281PeTGM99hD; Tue, 3 May 2016 04:34:21 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EECE12D758; Tue, 3 May 2016 04:34:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AC7D7BE77; Tue, 3 May 2016 12:34:18 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVn6JCTe0H6M; Tue, 3 May 2016 12:34:17 +0100 (IST) Received: from [10.87.49.100] (unknown [86.46.26.141]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A486CBE73; Tue, 3 May 2016 12:34:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462275255; bh=2UPlj0JG4bMcVgsQ3kCGTn1Hah9A/F4MzkaabHdNtwY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=GsMLIN5mh0vU6Dw3ki1H+vLqheTcNCUBC5nBAICShxVuN6OpRd991SiNWvEjKEk1r 9HZk/ucxGzvCl2z5vkeBK3UwB422EhNajqLaB/a3Kve9mrn29hAD5UYW+RxaRzRPAs dtGLGCRXvEQpXHaWyg6Jx57mGWNNc9M8ZwMFR33E= Subject: Re: Stephen Farrell's No Objection on draft-ietf-bfd-seamless-base-09: (with COMMENT) To: Manav Bhatia References: <20160503111437.7481.82666.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <57288CB6.9030202@cs.tcd.ie> Date: Tue, 3 May 2016 12:34:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020803040403030705030201" Archived-At: Cc: The IESG , rtg-bfd@ietf.org, draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 11:34:24 -0000 This is a cryptographically signed message in MIME format. --------------ms020803040403030705030201 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Thanks for the response. Good to know that the crypto here is not an issue:-) On 03/05/16 12:25, Manav Bhatia wrote: > There > is thus a value in retaining clear text passwords. I don't buy that tbh. There is a significant cost and risk too - passwords are re-used all over the place. Sending any password in clear anytime puts at risk whatever else that password is re-used for. And we know that does happen. (On average passwords used in the web are used in about 8 different places is the last study result that I recall.) I think this spec would be far better off advising to not continue that bad practice. S. --------------ms020803040403030705030201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MDMx MTM0MTRaMC8GCSqGSIb3DQEJBDEiBCD1kV4c9n13K5UFyG+1uip9eHnv94kr9vHIaKYdEPks aTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQA2kmGW750GYSDKPbknVO42bJBPbRnJ1NZyhHZlJ7rkwSsuVW1wkXet F+DxKT1LKfbsRo2qmAr7Z4JhUj7hLLkZwFKvngFxtmzQSKmgmjh/f1z51Vu3dRom/rnvDOI8 MmnTaVkbIodRjqFLlifvf9diBJQf2bXfdl52+L0Rdf05z8yttn6jvzY+aVNsiwoMkJ4e8TAy Msa29ne3Xe3XfaYgs+ngWzJMA5R7sDZQlr5GrSDi7GrakfkUp//OO47LwIuLlUaPdOK4jdnz QGWC+uEBHzbZr9vDtE3u6uYlTVtT1wZfxcpfv/bnYbsYnLY06b6/5qfLQ/gpUyXmDxaLOWlA AAAAAAAA --------------ms020803040403030705030201-- From nobody Tue May 3 04:52:20 2016 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 295D412D75C for ; Tue, 3 May 2016 04:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ionosnetworks-com.20150623.gappssmtp.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 u4qRbrvtYfV6 for ; Tue, 3 May 2016 04:52:16 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 4CD6712D1CD for ; Tue, 3 May 2016 04:52:11 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id m188so19787971vka.1 for ; Tue, 03 May 2016 04:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ionosnetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=wh9E4/F4ZbfI9vkxsZxVyjxEnYIgxhbdnzlZkBGAGrA=; b=CKNfUft4HJUy2uJQ0mbnMlhihEkaenif9MW/GSjp8KkJ8dat8zbbjhXu14a3vdl2bG CYBeTa028aD5Q9w82O59NTjLM2VglixludlWypcFipr/+gmeLiMF6heKCYPGYXcdfabv H70zgZ6fMq1R2/SYfkrffxPZf5WL0qh5JM6iccpKR/KJ7mp06X/xB4w1lBDevLF/xnrk GZKIDiyuMptf/C7rD7cBb5X3T5BBCWKxzMbUiQeEmXDIwxR6kljXxtvLwObIKpPD//x0 PGq7k+kG0H7PvRK6GEaDTvam4B2IOmOcsRLK4079/GSDTCVt/cUykiftQ60dLNMj8NIk SQ2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=wh9E4/F4ZbfI9vkxsZxVyjxEnYIgxhbdnzlZkBGAGrA=; b=X2CkDkxFpZCkHpOZlUGdkoETK6AQZDC9Y9crbhHTe1YdM2D4Z4olITPihZk9sERwUS b4prbFY1VBuvSJwvOJP1lBdcIv1wFl3YKntkAqrbZij3TAAp7YPKWig88ulHaVRi3+YJ a9rTSG2LcCplmMDUfVSkaF7I+0RPmxVX2U57gby/qcvZ9qdpGGE5RqawzZqa2R1+RTpZ 8HX6FT5XqBdNAVdHWZujxUy2sfiL7v9j69xrsFHqJxlw1LMVpaE5CDYmO4uZT1+f3gED qBa8F+hIUPJ4dRWS0m8QBkEZTg+o8fRrJOn1SHuB5fYK1z8jnaCn4oe7bKQAfOah/mHP Mt2Q== X-Gm-Message-State: AOPr4FViga2GSuD1cB5rviGEq0d7r/R151IPkWXHZe9eQrCmgUAsjOos8+3x6U3TRL1lkjlP6man14f/qd6yAg== MIME-Version: 1.0 X-Received: by 10.159.40.132 with SMTP id d4mr848030uad.21.1462276330423; Tue, 03 May 2016 04:52:10 -0700 (PDT) Received: by 10.31.32.197 with HTTP; Tue, 3 May 2016 04:52:10 -0700 (PDT) In-Reply-To: <57288CB6.9030202@cs.tcd.ie> References: <20160503111437.7481.82666.idtracker@ietfa.amsl.com> <57288CB6.9030202@cs.tcd.ie> Date: Tue, 3 May 2016 17:22:10 +0530 Message-ID: Subject: Re: Stephen Farrell's No Objection on draft-ietf-bfd-seamless-base-09: (with COMMENT) From: Manav Bhatia To: Stephen Farrell Content-Type: multipart/alternative; boundary=94eb2c123e283d20510531eebd99 Archived-At: Cc: The IESG , rtg-bfd@ietf.org, draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 11:52:19 -0000 --94eb2c123e283d20510531eebd99 Content-Type: text/plain; charset=UTF-8 Hi Stephen, On 03/05/16 12:25, Manav Bhatia wrote: > > There > > is thus a value in retaining clear text passwords. > > I don't buy that tbh. There is a significant cost and risk > too - passwords are re-used all over the place. Sending > any password in clear anytime puts at risk whatever else > that password is re-used for. And we know that does > happen. (On average passwords used in the web are used in > about 8 different places is the last study result that I > recall.) > I am sure you know that the way passwords are used in the web is different from how they are employed in securing the routing protocols ! :-) I know several deployments where clear-text passwords are used to avoid routing sessions from randomly coming up. So i dont see how we can remove that option. > I think this spec would be far better off advising to > not continue that bad practice. > I would instead suggest a one page BCP that discourages people from using clear-text password or an April 1 RFC that claims that clear-text passwords are most secure since no hacker would ever think that the network could be using a simple password ! I dont think that SBFD spec is the right place to knock sense into people who think that using clear text passwords for securing their networks is the smartest and the safest thing to do. That imo warrants a new draft. Dont you agree? Cheers, Manav > > S. > > --94eb2c123e283d20510531eebd99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephen,

=
= On 03/05/16 12:25, Manav Bhatia wrote:
>=C2=A0 There
> is thus a value in retaining clear text passwords.

I don't buy that tbh. There is a significant cost and risk
too - passwords are re-used all over the place. Sending
any password in clear anytime puts at risk whatever else
that password is re-used for. And we know that does
happen. (On average passwords used in the web are used in
about 8 different places is the last study result that I
recall.)

I am sure you know that the wa= y passwords are used in the web is different from how they are employed in = securing the routing protocols ! :-)

I know severa= l deployments where clear-text passwords are used to avoid routing sessions= from randomly coming up. So i dont see how we can remove that option.


I think this spec would be far better off advising to
not continue that bad practice.

I would= instead suggest a one page BCP that discourages people from using clear-te= xt password or an April 1 RFC that claims that clear-text passwords are mos= t secure since no hacker would ever think that the network could be using a= simple password !

I dont think that SBFD spec is = the right place to knock sense into people who think that using clear text = passwords for securing their networks is the smartest and the safest thing = to do. That imo warrants a new draft. Dont you agree?

<= div>Cheers, Manav

=C2=A0

S.


--94eb2c123e283d20510531eebd99-- From nobody Tue May 3 04:57:02 2016 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 A85AE12D76E; Tue, 3 May 2016 04:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 XxPagM-5Qtvd; Tue, 3 May 2016 04:56:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B18912D76A; Tue, 3 May 2016 04:56:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 274CFBE5B; Tue, 3 May 2016 12:56:52 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SoVAjGK5p0v; Tue, 3 May 2016 12:56:50 +0100 (IST) Received: from [10.87.49.100] (unknown [86.46.26.141]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D7951BE47; Tue, 3 May 2016 12:56:49 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462276610; bh=pCOFM+uNM0uXPNlUVo7CwL6aeliFipmss4OeNUe9W6Q=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ZO6DcRg54GzHF8f931eVcLzyvIDmk5EAhR3Sj1Yo/09fga3rpd8JNfjcSwpTh9vvS IEnwApl1/7wjQl/NzBDTSwJKIsTwMgRjUJWnKKGAdKUMd2lgjew/69R+4/kCVBuJ9u c8zT8a8c239HaJG++qNLgJis0iyXVoLzwBuBrmxU= Subject: Re: Stephen Farrell's No Objection on draft-ietf-bfd-seamless-base-09: (with COMMENT) To: Manav Bhatia References: <20160503111437.7481.82666.idtracker@ietfa.amsl.com> <57288CB6.9030202@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <57289201.600@cs.tcd.ie> Date: Tue, 3 May 2016 12:56:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000001090805070706020801" Archived-At: Cc: The IESG , rtg-bfd@ietf.org, draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 11:56:56 -0000 This is a cryptographically signed message in MIME format. --------------ms000001090805070706020801 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/05/16 12:52, Manav Bhatia wrote: > Hi Stephen, >=20 > On 03/05/16 12:25, Manav Bhatia wrote: >>> There >>> is thus a value in retaining clear text passwords. >> >> I don't buy that tbh. There is a significant cost and risk >> too - passwords are re-used all over the place. Sending >> any password in clear anytime puts at risk whatever else >> that password is re-used for. And we know that does >> happen. (On average passwords used in the web are used in >> about 8 different places is the last study result that I >> recall.) >> >=20 > I am sure you know that the way passwords are used in the web is differ= ent > from how they are employed in securing the routing protocols ! :-) People being people everywhere, I'm sure the differences aren't that great;-( >=20 > I know several deployments where clear-text passwords are used to avoid= > routing sessions from randomly coming up. So i dont see how we can remo= ve > that option. >=20 >=20 >> I think this spec would be far better off advising to >> not continue that bad practice. >> >=20 > I would instead suggest a one page BCP that discourages people from usi= ng > clear-text password or an April 1 RFC that claims that clear-text passw= ords > are most secure since no hacker would ever think that the network could= be > using a simple password ! >=20 > I dont think that SBFD spec is the right place to knock sense into peop= le > who think that using clear text passwords for securing their networks i= s > the smartest and the safest thing to do. That imo warrants a new draft.= > Dont you agree? I'd love to see someone write a draft about sensible things to do and silly things to do with all of the pre-shared keys used in routing protocols. If that exists, great! (And can you send a pointer? And then maybe refer to it from here.) If that doesn't exist, then adding relevant bits of it as appropriate seems to me like the best we might get. Or are you planning to write that? S. >=20 > Cheers, Manav >=20 >=20 >=20 >> >> S. >> >> >=20 --------------ms000001090805070706020801 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MDMx MTU2NDlaMC8GCSqGSIb3DQEJBDEiBCAgKuFsoKBoKGaHj4nVCaF70wi95xw+sBTkbCen0q5o RTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBD1QVdxF082T5S+KXvzKq9F2FcjmKBCFiC1mLuA+7JuzilgiwFwob5 ubgdZ9GMKk3bAW+Z3Bgy/5mX1AYNqiHF7O8AYEJJ5cIZ1yM02hbgZfC0MFvKYsWPTd3ZwD03 zqKlG7MKlznRF+V/EYgB5Qja+dmXgrnG9sKQGaON/9J3/OSIJ9m1VVR95ezkU7GN/9BO6y1c SwvDwwFQPEE9z0qAWScYCgJ30FeV9SOOxF6wkrZzT9t0dwGdpSac1e31DP6RnVsXRRQOQ4CT dOP6V0hw+uuPR2ySmdodYeXJfQ9vlJbs/uCXq/FVIY5bUe9VdWs3Ol8Sjk73uS9eV3ot97Mg AAAAAAAA --------------ms000001090805070706020801-- From nobody Tue May 3 05:08:48 2016 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 0FA2512D77F for ; Tue, 3 May 2016 05:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ionosnetworks-com.20150623.gappssmtp.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 DmogKUw5RDFd for ; Tue, 3 May 2016 05:08:44 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 2A1DF12D78B for ; Tue, 3 May 2016 05:08:39 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id b189so20198595vkh.2 for ; Tue, 03 May 2016 05:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ionosnetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=YIdBbpkyAlqcQ0P2Azz3Y7NZ3wpzL3uMR5Nl1tqv+SE=; b=DReKt3LYtrBNGSdvFm0CuHCSYQZ9rCyvPAAyUl3hW1HhM11BT7GoZeEoVgIYM/szpc LbQvgJ56WXfXKyYs+U9Ug7evnZPSBWnCLcUUYf/0oGSq2euLaPMsWdz19sWAoaWhWttF p87fqk1QEHzYEC//q5n+kjqf/V2otdisRKnqdUwL0Ie2Ftx8qgXFqi5wETem4D5EKPiW Y1zC4YaGefFAXvXAfjZAI+OQ/D4wYXCn7qwWGnBDVoaH7+4S7+2/g8xViY2OCpsqnmvg A6YYx47Tb1BU+DZCT/3UvQin8HTv4YV+2j/1LockQC58p1AbfoorZuELUDIt4qgvhIrb 8/XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=YIdBbpkyAlqcQ0P2Azz3Y7NZ3wpzL3uMR5Nl1tqv+SE=; b=Ceohdq1c5/85oQ+rnb+vs5yCvGLhwHH0DZKg6WzrXoCFWK9BklfoWhVf/RpaAmUe9u G/+V2D6VWrCHuAq36MVDaF/OXVDlimtJegcyTSjdIKP8x7DCPO4vGTa+FyLFESQUQfuu xID6noTKXy4kdLzcZkIPuvWl647ktOMaQNSTuY/B1LgPnA+jBPksGjW+XcP/awyHCE6I J7CTmCVaQTFGHB90TS9tqSTzh1RNsGlSeeEfIW9EEnIthlKdHmdBvgDN34X9ecsDhY9N NnQ5vMOvLozYom2AxlpuvFOBbRH9tfYsfuwxixy+IR3XnzMFqPsRnsI1VroiwuVNqrt3 NxAQ== X-Gm-Message-State: AOPr4FWFikUYYmlxaORbEwQDJTgPA1mEjxyfIne1m27QANjSoj6JSZeEtNlMHfh6va1cBDf0+VuXZD6noh0anw== MIME-Version: 1.0 X-Received: by 10.31.233.4 with SMTP id g4mr848887vkh.61.1462277318235; Tue, 03 May 2016 05:08:38 -0700 (PDT) Received: by 10.31.32.197 with HTTP; Tue, 3 May 2016 05:08:38 -0700 (PDT) In-Reply-To: <57289201.600@cs.tcd.ie> References: <20160503111437.7481.82666.idtracker@ietfa.amsl.com> <57288CB6.9030202@cs.tcd.ie> <57289201.600@cs.tcd.ie> Date: Tue, 3 May 2016 17:38:38 +0530 Message-ID: Subject: Re: Stephen Farrell's No Objection on draft-ietf-bfd-seamless-base-09: (with COMMENT) From: Manav Bhatia To: Stephen Farrell Content-Type: multipart/alternative; boundary=94eb2c094a3c1df1760531eef868 Archived-At: Cc: The IESG , rtg-bfd@ietf.org, draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 12:08:46 -0000 --94eb2c094a3c1df1760531eef868 Content-Type: text/plain; charset=UTF-8 > > > I'd love to see someone write a draft about sensible things to do > and silly things to do with all of the pre-shared keys used in routing > protocols. If that exists, great! (And can you send a pointer? And > then maybe refer to it from here.) > Am not aware of such a doc existing. > > If that doesn't exist, then adding relevant bits of it as appropriate > seems to me like the best we might get. Or are you planning to write > that? > :-) No, i dont intend to write one. We will add some text that says that one should not be using clear-text passwords for SBFD since that provides no (surprise! surprise !) security at all. Cheers, Manav > > S. > > > > > Cheers, Manav > > > > > > > >> > >> S. > >> > >> > > > > --94eb2c094a3c1df1760531eef868 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'd love to see someone write a draft about sensible things to d= o
and silly things to do with all of the pre-shared keys used in routing
protocols. If that exists, great! (And can you send a pointer? And
then maybe refer to it from here.)

Am n= ot aware of such a doc existing.=C2=A0
=C2=A0

If that doesn't exist, then adding relevant bits of it as appropriate seems to me like the best we might get. Or are you planning to write
that?

:-)

No, = i dont intend to write one.=C2=A0

We will add some= text that says that one should not be using clear-text passwords for SBFD = since that provides no (surprise! surprise !) security at all.
Cheers, Manav=C2=A0


= =C2=A0

S.

>
> Cheers, Manav
>
>
>
>>
>> S.
>>
>>
>


--94eb2c094a3c1df1760531eef868-- From nobody Tue May 3 06:40:50 2016 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 C2FBB12B010; Tue, 3 May 2016 06:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 8MlA_830ZrQi; Tue, 3 May 2016 06:40:42 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A21128874; Tue, 3 May 2016 06:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3731; q=dns/txt; s=iport; t=1462282841; x=1463492441; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IaxUS6IpgqTF5BNpoE20rAp603m4Y2RJ8M3bd0TZjsg=; b=J9axzQ+yx/5kbS+j8XC0L2otDLpx192rIHQOXWcX18l2DlmWHLeoNQzm v8PnCPPcBMv3JsOVN6BkiVgJB+o98iv1/1coefVyJ9tSVlXeIMZIkwB00 BAA0OLvftZlAiSsIDqs1/kcVkqR+fvYz7+rXqPCWGkmIzpz5wJtgrZssi E=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BOBAA4qShX/4cNJK1fgzhTfQa1XoIfg?= =?us-ascii?q?g8OgXUihW4CgUE4FAEBAQEBAQFlJ4RBAQEBAwEjVgULAgEIDgoqAgIyGgsCBA4?= =?us-ascii?q?FDogUCA6qS5EXAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQQEhiCBdoJXhBERAQZIg?= =?us-ascii?q?k6CWQWHeJAeAYMngWdtiBwKgV6ETYhdiUCFcQEeAUOCNoE1bAGHBjZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="asc'?scan'208";a="103921650" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 May 2016 13:40:40 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u43DeeK7005254 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 13:40:40 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 09:40:39 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 3 May 2016 09:40:39 -0400 From: "Carlos Pignataro (cpignata)" To: Mirja Kuehlewind Subject: =?utf-8?B?UmU6IE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt?= =?utf-8?Q?bfd-seamless-base-09:_(with_DISCUSS)?= Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1iZmQt?= =?utf-8?Q?seamless-base-09:_(with_DISCUSS)?= Thread-Index: AQHRpR8YB75iFhnPVECZQ0i//enE0Z+ne5KA Date: Tue, 3 May 2016 13:40:39 +0000 Message-ID: References: <20160503093512.7446.68991.idtracker@ietfa.amsl.com> In-Reply-To: <20160503093512.7446.68991.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.48.199] Content-Type: multipart/signed; boundary="Apple-Mail=_33A1349A-E6FC-445C-9658-EDE894D54844"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 13:40:44 -0000 --Apple-Mail=_33A1349A-E6FC-445C-9658-EDE894D54844 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Mirja, What is an uncontrolled packet in an IP network, and what entity = controls controlled ones? :-) More seriously, please see inline. > On May 3, 2016, at 5:35 AM, Mirja Kuehlewind = wrote: >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-bfd-seamless-base-09: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > As S-BFD has no initiation process anymore it is not guarenteed that = the > receiver/responder actually exists. That means that packets could = float > (uncontrolled) in the network or even outside of the adminstrative = domain > (e.g. due to configuration mistakes). =46rom my point of view this = document > should recommend/require two things: >=20 We have called out the misconfiguration =E2=80=94 however: > 1) A maximum number of S-BFD packet that is allow to be send without > getting a response (maybe leading to a local error report). >=20 This can result in a deadlock situation, if an S-BFD Reflector is = enabled much later. I=E2=80=99m very hesitant to cap the packets sent. = We can, and I think it is useful, MAY log an error for multiple = timeouts. > 2) Egress filtering at the adminstrative border of the domain that = uses > S-BFD to make sure that no S-BFD packets leave the domain. >=20 This is no different than any other application that uses UDP; a = misconfigured DNS server will result in the same, and a traceroute is = also not too different. This seems too onerous of a requirement. An = administrative domain filters at ingress. Seems to me the logging will alert someone/something to take action, and = should be enough. Thoughts? Thanks, =E2=80=94 Carlos. >=20 >=20 >=20 --Apple-Mail=_33A1349A-E6FC-445C-9658-EDE894D54844 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXKKpXAAoJEIXgpQGOZny9HdIQALHvst/3grSO9jUC9Fpml91x fSFJBCZdEmYPZwWDKwNuyLt0e3Gqj58G4QmSshXQP6+Mn6iFSsW76tFo6tACXY7x W0S0s+FIdVbCSF+BnWOSbIQzJIkE+41+la/9njo9daxBC3a98OCab0d9La7FDloK Vums63f7Tt6ANkDGX02CpJlPFDL46jXWUFrPziwOOXNOhNRp0dI+HfciLe/HFZ9y bObFWx9O9qH7WD+YrZY0WYyUcqGsh0ZVpyQnm3LUnDJY4QvPTvVt0OSiBA8sJMX/ 1ogRfLrrZ8h0fhbFbJYjoih7mWf3DIMYkpXXzBvuVbZgCHn6s/ymKilDSk6OkEQa zVm2p6F+4whNskTi4uLrTglODJny4Ci9jg9KXF9t8vQogXFXYYvmaaXTPKySnKmv VtNMyJttSMKf4LFmhggqSB6rkmyTIuhLHHJ1H7i2FLYo8jO7Qjdq41qVbqoY/Hn1 gietK5zTdkfegMr8+kjuI/FVxxEGLApTkyD5bojf7wQouVMNDZVFnz+dPE6+DIZm wnCLmQqH0ELDOhoKQxVJgnuoppRfxWYl93U3dZVmdGlDkc3CXfTFP36wGLJ0qZl6 Y/IW2vXbU2zI2Zcv0vOrpk8yd5VXxacGREir6fgGcoRLfHct3AimBwIRoba9bsdV 2oBL21GcpL4rniOitR60 =a8OA -----END PGP SIGNATURE----- --Apple-Mail=_33A1349A-E6FC-445C-9658-EDE894D54844-- From nobody Tue May 3 07:54:06 2016 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 88FCB1200A0; Tue, 3 May 2016 07:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Qx0VpoGtJP8w; Tue, 3 May 2016 07:53:50 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 66CC012B03C; Tue, 3 May 2016 07:53:50 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id k142so28657540oib.1; Tue, 03 May 2016 07:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=V2eWklYx0qzy795igV0ZPvaX0gyN1KAdv/pXjGSNfF0=; b=Tl6Kq6Z/UO+TQtHiFZQK39jzYOL6I8++GvxhOLGbf+bjiO//Ct1PLe7pWUBpuymx8u g0DZBL6WjisE9Y53TjL3GUc4k1SA3l1dH4hZE0UPdY5xRLo7YGeFO3nowgauLDJIKO4B A4ENMOIkk3a8nJ+GAI2yXHKALtYw4wJaM1JSB1YRmwNqLcrtTNUcOEOIeLytVhPuRMW9 NaI/QQFr8orBt6YYFzJAZo8fqDC3aH4lfLwg+h18tpFzVZ7j5PyJWZllu4fs1ScQBFOK asNxgPPn/NizoSOsno7rfFsqlkcsmUWwiIbVzLo3uL/5VG6tjuOnC9uIka+pSwHbwtAo 0x6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=V2eWklYx0qzy795igV0ZPvaX0gyN1KAdv/pXjGSNfF0=; b=VYAzyELzDEt227xLyBpXFUZfrh0qUY7MQ8pecqucQpOXGA4WYuCmQQSrdhFrw99fcm 0hii1NAU5wEuC1kQFTR6LTKSk70g7kZWkjzh/OAH/lZ+AGi/24v7f/JxqgzhItV+r2pJ a1kVRZ9AvWDj11bLmUD5AMRNUF+MdbTRRwSCKdkcLNHK4+iNO4PjdgmrB3V5LuQIbTAs BKy1rBqsEzzufT29CiBQIgKpO9EYlZnhis84sarviw04tyPolVm6rNQy3QzKfC/fy5sr rsEm9Kfpw6KBrapFucwdq3UKxTOV3TsivXOKjgzmHoOFT9BqvvjCuH3e+0bAIa8ppJQr HeMQ== X-Gm-Message-State: AOPr4FXf2ofiz1bwhk2HuhSnzKUQvT588gQIDyhdqaFUo7BjkWnlCbPLlo8qM6D6kH4T9IpvPqzs0/gbA1pXzg== MIME-Version: 1.0 X-Received: by 10.157.45.81 with SMTP id v75mr1540945ota.85.1462287229796; Tue, 03 May 2016 07:53:49 -0700 (PDT) Received: by 10.60.115.168 with HTTP; Tue, 3 May 2016 07:53:49 -0700 (PDT) In-Reply-To: References: <20160502212434.15622.98408.idtracker@ietfa.amsl.com> Date: Tue, 3 May 2016 10:53:49 -0400 Message-ID: Subject: Re: Alia Atlas' Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS and COMMENT) From: Alia Atlas To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a113e9f66e448490531f146ca Archived-At: Cc: The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 14:53:58 -0000 --001a113e9f66e448490531f146ca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, On Mon, May 2, 2016 at 6:34 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi, Alia, > > Thanks for your review and for bringing up these issues =E2=80=94 please = see > inline. > > > On May 2, 2016, at 5:24 PM, Alia Atlas wrote: > > > > Alia Atlas has entered the following ballot position for > > draft-ietf-bfd-seamless-base-09: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > a) In Sec 7.2.3: "If the SBFDReflector is generating a response S-BFD > > control packet for a local entity that is in > > service, then "state" in response BFD control packets MUST be set > > to UP." > > So far, it looked like the SBFDReflector only sends BFD control > > packets in response to receiving such packets > > from SBFDInitiators. This paragraph (not just copied) does not > > clearly describe the desired behavior. If the > > monitored local entity is "temporarily out of service", does the > > SBFDReflector respond back to the SBFDInitiator > > with 2 BFD control packets - one indicating UP (as a MUST) and then > > the next indicating ADMINDOWN? Is the > > SBFDReflector expected to store a list of active SBFDInitiators and > > proactively send BFD control packets indicating > > ADMINDOWN? Please clarify in non-trivial detail. > > The way in which that particular bullet in that subsection is written can > be a bit confusing. > > First, you are right that the SBFDReflector only sends packets in respons= e > to S-BFD control packets from the SBFDInitiators. This is clearly spelled > out in Section 5, and in other places that explain how the reflector is > stateless. > > The SBFDReflector only response and does not stores a list of > SBFDInitiators to proactively send S-BFD packets (see Section 5). Further= , > it does not respond with two packets. (UP and ADMINDOWN). > > I think this can be rewritten to better explain what happens, as follows: > > OLD: > o If the SBFDReflector wishes to communicate to some or all > SBFDInitiators that monitored local entity is "temporarily out of > service", then S-BFD control packets with "state" set to ADMINDOWN > are sent to those SBFDInitiators. The SBFDInitiators, upon > reception of such packets, MUST NOT conclude loss of reachability > to corresponding remote entity, and MUST back off packet > transmission interval for the remote entity to an interval no > faster than 1 second. If the SBFDReflector is generating a > response S-BFD control packet for a local entity that is in > service, then "state" in response BFD control packets MUST be set > to UP. > > NEW: > o If the SBFDReflector, upon receiving an S-BFD control packet from > an SBFDInitiators, wishes to communicate to those > SBFDInitiators that a monitored local entity is "temporarily out of > service", then an S-BFD control packet with "state" set to ADMINDOW= N > is sent in response to those SBFDInitiators. The SBFDInitiators, > upon > reception of such packets, MUST NOT conclude loss of reachability > to corresponding remote entity, and MUST back off packet > transmission interval for the remote entity to an interval no > faster than 1 second. If, on the other hand, the SBFDReflector is > generating a > response S-BFD control packet for a local entity that is in > service, then "state" in response BFD control packets MUST be set > to UP. > > Is that more clear? > Slightly - but what about: "When the SBFDReflector receives an S-BFD control packet from an SBFDInitiator, then the SBFDReflector needs to determine what state to send in the response S-BFD control packet. If the monitored local entity is in service, then the "state" MUST be set to UP. However, if the monitored local entity is "temporarily out of service" for rapidly processing S-BFD packets, for instance due to an overload, then the "state" SHOULD be set to ADMINDOWN. The SBFDReflector SHOULD send a response S-BFD control packet. When an SBFDInitiator receives a response S-BFD control packet, if the state specified is ADMINDOWN, the SBFDInitiator MUST NOT conclude loss of reachability to corresponding remote entity, and MUST back off packet transmission interval for the remote entity to an interval no faster than 1 second. " Either wording or a mixture is just fine. > > > > > > b) Appendix A: The looping problem is nicely defined but the text stil= l > > discusses three potential solutions; clearly the > > use of the D bit has been chosen. It would be much nicer to have the > > justification in line, but for this discuss - the > > unselected alternatives don't belong. > > > > Sorry I=E2=80=99m not sure I understand fully your point. Are you suggest= ing we > mention in the actual reason for the D-bit procedures outside the Appendi= x > (although the procedures for the D bit are explained in Section 6.2, 7.2.= 2, > 7.2.3, 7.3.2, and 7.2.2), while still leave the Appendix as-is? > > If so we can do that, but want to confirm. > I'm suggesting that you mention the reason for the D-bit procedures outside the Appendix and remove the Appendix. Alternately, keep the Appendix but remove discussion of the other ways the problem could have been solved and add a reference from the D-bit procedures to the Appendix. Once this is an RFC, it doesn't matter what the other possible and unselected design choices were. > c) Sec 7.2.1: " S-BFD packet MUST be demultiplexed with lower layer > > information > > (e.g., dedicated destination UDP port, associated channel type)." > > Where precisely is this defined or described? Is there an allocation > > for a dedicated UDP > > port for S-BFD? I don't see any normative reference to such. In > > particular, since the format > > for an S-BFD control packet is exactly the same as for BFD and since on= ly > > this demultiplexing > > with lower layer information is used to tell the difference between S-B= FD > > and BFD packets, > > this document requires more specifics. > > > > This is similar to RFC 5880 and RFC 5881. The actual S-BFD applications > specify this. For example, bfd-seamless-ip defines the UDP port. We > purposely do not want to have the specification (either explicitly or > normatively pointed to) from this document, as this is just the base > specification. > Why? Unlike RFC 5880, this document mentions UDP ports as an example of a demultiplexer. While I do understand that BFD can run with different transports, it is useful to clearly articulate one use transport that has enough information to be actually implemented. In this case, that's just a normative reference to another document progressing at the same time= . I can't get too worked up about normative vs. informative references in general - the guideline I use is whether an implementor would need to read the reference to properly implement the functionality. If you feel extremely strongly that the reference must be informative, I'm not going to dig in my heels - but PLEASE put a reference by the mention of the UDP port. > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > 1) In the last paragraph of Sec 4.2: " Even when following the separat= e > > discriminator pool approach, > > collision is still possible between one S-BFD application to another > > S-BFD application, that may be using different values and algorithms > > to derive S-BFD discriminator values. If the two applications are > > using S-BFD for a same purpose (e.g., network reachability), then the > > colliding S-BFD discriminator value can be shared. If the two > > applications are using S-BFD for a different purpose, then the > > collision must be addressed. How such collisions are addressed is > > outside the scope of this document." > > > > Sec 4.1 talks about the need for the S-BFD Discriminator to be unique > > within an Administrative Domain. > > I don't see any details of that addressed here. What is addressed > > here seems to be the case for multiple > > S-BFD discriminators applying to the same node - which is specifically > > discouraged at the end of Sec 3. > > Rather than simply describing the issue as "outside the scope of this > > document", please either describe it > > as "future work and multiple S-BFD discriminators is discouraged" or > > add a reference. > > > > Good point, will do. > > > 2) In Sec 6.1: "bfd.SessionType:" is defined but the only possible valu= es > > are for SBFD. Is it possible for a BFD > > session to still use the same bfd structure? I don't see a value for > > SessionType there; I'd expect to see at least > > a value for the original BFD session and possible an undefined or > > unspecified value for future proofing. > > > > > > Traditional BFD does not use this state variable. That=E2=80=99s why we d= on=E2=80=99t need > to define a value for BFD. However, future specs can when it is relevant > (e.g, using BFD for various types as opposed to S-BFD), as for example > bfd-multipoint. > Right - I understand that. I'm thinking a bit from the implementation perspective. If I have the same data-structures and similar logic for BFD and S-BFD, then there'll be a bfd.SessionType even for BFD sessions that don't need it. Clarifying a value of "Unused" or "Classical BFD" gives clarity that one of the S-BFD options doesn't need to be chosen. This is just a comment. It's up to your best judgement. Thanks, Alia Please let us know your thoughts on the responses above, and we can send > out diffs. > > Thanks! > > =E2=80=94 Carlos. > > > --001a113e9f66e448490531f146ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carlos,

On Mon, May 2, 2016 at 6:34 PM, Carlos Pignataro (cpignata) <cp= ignata@cisco.com> wrote:
Hi, Alia,

Thanks for your review and for bringing up these issues =E2=80=94 please se= e inline.

> On May 2, 2016, at 5:24 PM, Alia Atlas <akatlas@gmail.com> wrote:
>
> Alia Atlas has entered the following ballot position for
> draft-ietf-bfd-seamless-base-09: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/= draft-ietf-bfd-seamless-base/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> a) In Sec 7.2.3:=C2=A0 "If the SBFDReflector is generating a resp= onse S-BFD
> control packet for a local entity that is in
>=C2=A0 =C2=A0 =C2=A0 service, then "state" in response BFD co= ntrol packets MUST be set
> to UP."
>=C2=A0 =C2=A0 So far, it looked like the SBFDReflector only sends BFD c= ontrol
> packets in response to receiving such packets
>=C2=A0 =C2=A0 from SBFDInitiators.=C2=A0 =C2=A0This paragraph (not just= copied) does not
> clearly describe the desired behavior.=C2=A0 If the
>=C2=A0 =C2=A0monitored local entity is "temporarily out of service= ", does the
> SBFDReflector respond back to the SBFDInitiator
>=C2=A0 =C2=A0with 2 BFD control packets - one indicating UP (as a MUST)= and then
> the next indicating ADMINDOWN?=C2=A0 Is the
>=C2=A0 =C2=A0SBFDReflector expected to store a list of active SBFDIniti= ators and
> proactively send BFD control packets indicating
>=C2=A0 =C2=A0ADMINDOWN?=C2=A0 =C2=A0Please clarify in non-trivial detai= l.

The way in which that particular bullet in that subsection is w= ritten can be a bit confusing.

First, you are right that the SBFDReflector only sends packets in response = to S-BFD control packets from the SBFDInitiators. This is clearly spelled o= ut in Section 5, and in other places that explain how the reflector is stat= eless.

The SBFDReflector only response and does not stores a list of SBFDInitiator= s to proactively send S-BFD packets (see Section 5). Further, it does not r= espond with two packets. (UP and ADMINDOWN).

I think this can be rewritten to better explain what happens, as follows:
OLD:
=C2=A0 =C2=A0o=C2=A0 If the SBFDReflector wishes to communicate to some or = all
=C2=A0 =C2=A0 =C2=A0 SBFDInitiators that monitored local entity is "te= mporarily out of
=C2=A0 =C2=A0 =C2=A0 service", then S-BFD control packets with "s= tate" set to ADMINDOWN
=C2=A0 =C2=A0 =C2=A0 are sent to those SBFDInitiators.=C2=A0 The SBFDInitia= tors, upon
=C2=A0 =C2=A0 =C2=A0 reception of such packets, MUST NOT conclude loss of r= eachability
=C2=A0 =C2=A0 =C2=A0 to corresponding remote entity, and MUST back off pack= et
=C2=A0 =C2=A0 =C2=A0 transmission interval for the remote entity to an inte= rval no
=C2=A0 =C2=A0 =C2=A0 faster than 1 second.=C2=A0 If the SBFDReflector is ge= nerating a
=C2=A0 =C2=A0 =C2=A0 response S-BFD control packet for a l= ocal entity that is in
=C2=A0 =C2=A0 =C2=A0 service, then "state" in response BFD contro= l packets MUST be set
=C2=A0 =C2=A0 =C2=A0 to UP.

NEW:
=C2=A0 =C2=A0o=C2=A0 If the SBFDReflector, upon receiving an S-BFD control = packet from
=C2=A0 =C2=A0 =C2=A0 an SBFDInitiators, wishes to communicate to those
=C2=A0 =C2=A0 =C2=A0 SBFDInitiators that a monitored local entity is "= temporarily out of
=C2=A0 =C2=A0 =C2=A0 service", then an S-BFD control packet with "= ;state" set to ADMINDOWN
=C2=A0 =C2=A0 =C2=A0 is sent in response to those SBFDInitiators.=C2=A0 The= SBFDInitiators, upon
=C2=A0 =C2=A0 =C2=A0 reception of such packets, MUST NOT conclude loss of r= eachability
=C2=A0 =C2=A0 =C2=A0 to corresponding remote entity, and MUST back off pack= et
=C2=A0 =C2=A0 =C2=A0 transmission interval for the remote entity to an inte= rval no
=C2=A0 =C2=A0 =C2=A0 faster than 1 second.=C2=A0 If, on the other hand, the= SBFDReflector is generating a
=C2=A0 =C2=A0 =C2=A0 response S-BFD control packet for a l= ocal entity that is in
=C2=A0 =C2=A0 =C2=A0 service, then "state" in response BFD contro= l packets MUST be set
=C2=A0 =C2=A0 =C2=A0 to UP.

Is that more clear?

Slightly - b= ut what about:

"When the SBFDReflector receiv= es an S-BFD control packet from an SBFDInitiator,
then the SBFDRe= flector needs to determine what state to send in the response S-BFD
control packet.=C2=A0 If the monitored local entity is in service, then = the "state" MUST be
set to UP.=C2=A0 However, if the mo= nitored local entity is "temporarily out of service" for
rapidly processing S-BFD packets, for instance due to an overload, then t= he "state"=C2=A0
SHOULD be set to ADMINDOWN.=C2=A0 The = SBFDReflector SHOULD send a response
S-BFD control packet. =C2=A0=

When an SBFDInitiator receives a response S-BFD c= ontrol packet, if the state specified
is ADMINDOWN, the SBFDIniti= ator MUST NOT conclude loss of =C2=A0reachability
to corresponding rem= ote entity, and MUST back off packet=C2=A0transmission interval for the=C2= =A0
remote entity to an interval no=C2=A0fa= ster than 1 second. "

Either wording or a mixture is just fine. =C2=A0=C2=A0=

>
> b) Appendix A:=C2=A0 The looping problem is nicely defined but the tex= t still
> discusses three potential solutions; clearly the
> use of the D bit has been chosen.=C2=A0 =C2=A0It would be much nicer t= o have the
> justification in line, but for this discuss - the
> unselected alternatives don't belong.
>

Sorry I=E2=80=99m not sure I understand fully your point. Are you su= ggesting we mention in the actual reason for the D-bit procedures outside t= he Appendix (although the procedures for the D bit are explained in Section= 6.2, 7.2.2, 7.2.3, 7.3.2, and 7.2.2), while still leave the Appendix as-is= ?

If so we can do that, but want to confirm.

<= div>I'm suggesting that you mention the reason for the D-bit procedures= outside the Appendix and remove the Appendix.=C2=A0 Alternately, keep the = Appendix but remove discussion of the other ways the problem could have bee= n solved and add a reference from the D-bit procedures to the Appendix.
=C2=A0
Once this is an RFC, it doesn't matter what the= other possible and unselected design choices were.

> c) Sec 7.2.1: "=C2=A0 =C2=A0S-BFD packet MUST be demultiplexed wi= th lower layer
> information
>=C2=A0 =C2=A0(e.g., dedicated destination UDP port, associated channel = type)."
>=C2=A0 Where precisely is this defined or described?=C2=A0 Is there an = allocation
> for a dedicated UDP
> port for S-BFD?=C2=A0 I don't see any normative reference to such.= =C2=A0 In
> particular, since the format
> for an S-BFD control packet is exactly the same as for BFD and since o= nly
> this demultiplexing
> with lower layer information is used to tell the difference between S-= BFD
> and BFD packets,
> this document requires more specifics.
>

This is similar to RFC 5880 and RFC 5881. The actual S-BFD applicati= ons specify this. For example, bfd-seamless-ip defines the UDP port. We pur= posely do not want to have the specification (either explicitly or normativ= ely pointed to) from this document, as this is just the base specification.=

Why?=C2=A0 Unlike RFC 5880, this docum= ent mentions UDP ports as an example of a demultiplexer.
While I = do understand that BFD can run with different transports, it is useful to c= learly articulate
one use transport that has enough information t= o be actually implemented. =C2=A0 In this case, that's
just a= normative reference to another document progressing at the same time.

I can't get too worked up about normative vs. info= rmative references in general - the guideline I
use is whether an= implementor would need to read the reference to properly implement the
functionality.

If you feel extremely strong= ly that the reference must be informative, I'm not going to dig in my
heels - but PLEASE put a reference by the mention of the UDP port.=
=C2=A0
=C2=A0
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> 1) In the last paragraph of Sec 4.2: "=C2=A0 Even when following = the separate
> discriminator pool approach,
>=C2=A0 =C2=A0collision is still possible between one S-BFD application = to another
>=C2=A0 =C2=A0S-BFD application, that may be using different values and = algorithms
>=C2=A0 =C2=A0to derive S-BFD discriminator values.=C2=A0 If the two app= lications are
>=C2=A0 =C2=A0using S-BFD for a same purpose (e.g., network reachability= ), then the
>=C2=A0 =C2=A0colliding S-BFD discriminator value can be shared.=C2=A0 I= f the two
>=C2=A0 =C2=A0applications are using S-BFD for a different purpose, then= the
>=C2=A0 =C2=A0collision must be addressed.=C2=A0 How such collisions are= addressed is
>=C2=A0 =C2=A0outside the scope of this document."
>
>=C2=A0 Sec 4.1 talks about the need for the S-BFD Discriminator to be u= nique
> within an Administrative Domain.
>=C2=A0 I don't see any details of that addressed here.=C2=A0 =C2=A0= What is addressed
> here seems to be the case for multiple
>=C2=A0 S-BFD discriminators applying to the same node - which is specif= ically
> discouraged at the end of Sec 3.
>=C2=A0 Rather than simply describing the issue as "outside the sco= pe of this
> document", please either describe it
>=C2=A0 as "future work and multiple S-BFD discriminators is discou= raged" or
> add a reference.
>

Good point, will do.

> 2) In Sec 6.1: "bfd.SessionType:" is defined but the only po= ssible values
> are for SBFD.=C2=A0 =C2=A0Is it possible for a BFD
> session to still use the same bfd structure?=C2=A0 I don't see a v= alue for
> SessionType there; I'd expect to see at least
> a value for the original BFD session and possible an undefined or
> unspecified value for future proofing.
>
>

Traditional BFD does not use this state variable. That=E2=80=99s why= we don=E2=80=99t need to define a value for BFD. However, future specs can= when it is relevant (e.g, using BFD for various types as opposed to S-BFD)= , as for example bfd-multipoint.

Right = - I understand that.=C2=A0 I'm thinking a bit from the implementation p= erspective.=C2=A0 If I have the same data-structures and similar logic for = BFD and S-BFD, then there'll be a bfd.SessionType even for BFD sessions= that don't need it.=C2=A0 Clarifying a value of "Unused" or = "Classical BFD" gives clarity that one=C2=A0
of the S-B= FD options doesn't need to be chosen.

This is = just a comment.=C2=A0 It's up to your best judgement.

Thanks,
Alia=C2=A0


Please let us know your thoughts on the responses above, and we can send ou= t diffs.

Thanks!

=E2=80=94 Carlos.



--001a113e9f66e448490531f146ca-- From nobody Tue May 3 09:22:11 2016 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 9FC7412D57B; Tue, 3 May 2016 09:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 HqIKaTdKY-uc; Tue, 3 May 2016 09:22:01 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 B071212DA3C; Tue, 3 May 2016 09:21:30 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id x201so32404644oif.3; Tue, 03 May 2016 09:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=4Q806sfMPO5MrpnCgR9dm3FWv5v5zv6bZtULKJ0PsXA=; b=kNsonz8S9vxVpNthAkI7B54rzspCHynLdRquj/8mCMky756fYNqWcOvus4rWiY2xCx xMXBez7v+76aCEvpeQXcN6CUzMVZzEXhwn+kDMOa+jPI6Kve1GJsxBtAlPbj2mWgyFLM so4bT85R5uSogqxIDTJ90lhQnBf426Qozjile4fwYzQS1RH0uGt8aO1K4nJJ4PpNee1s lGvv/ss1x4lYgvrWAGPMPYJpVjZxoLKgXSn+zlOWnqVhi+29HaVNHd15Nifhkf7aezdY FjVKSyIy5N/P40zvlF+qDDf3bFxrfAlnKCTwzCA5dPmuqWpHybNZ4n40Hrk63PtVx7jk dmVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4Q806sfMPO5MrpnCgR9dm3FWv5v5zv6bZtULKJ0PsXA=; b=biYG2fjzivENOoB9S9biVslDspldkgMpy6O0KL+1oODBNVdcL1ehckKsuYmvIGrrcm toojV3RRiDHbrjlYWS00ZTH5LvFRgPgkWouEziK3vaCpdd74Gu+Mf0oHfn/s1sLKNs42 MlPFNKqnwee04iIYHix3bd4pdgohA5oC2/VUjWbbAF7E9h5x/A83n5qeL9kk/sAVFDqO slffLj+jNJ6shc26sV9Y/dC4EGz7s16C6L9lqlRMiOAFA0SuN9ywg8+aakCrufOMQagQ VE/JPr3tpV1kS+E20/fiyFurSXnmqekkiprmA7SzANyPG6GNpYx6KaCsKVpSPicB6ejp oSxQ== X-Gm-Message-State: AOPr4FXtVyHQjcQ3+QQh/noIF4c8VFmqR+ieUajfaTRVABSROENMIdFdeR4RWOjAo4S2/IlZZ1djXmip81O97g== MIME-Version: 1.0 X-Received: by 10.157.49.102 with SMTP id v35mr1910863otd.41.1462292489733; Tue, 03 May 2016 09:21:29 -0700 (PDT) Received: by 10.60.115.168 with HTTP; Tue, 3 May 2016 09:21:29 -0700 (PDT) In-Reply-To: <059ECD31-C883-4721-8FA1-3FCEE9FCE1AC@cisco.com> References: <20160502212434.15622.98408.idtracker@ietfa.amsl.com> <059ECD31-C883-4721-8FA1-3FCEE9FCE1AC@cisco.com> Date: Tue, 3 May 2016 12:21:29 -0400 Message-ID: Subject: Re: Alia Atlas' Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS and COMMENT) From: Alia Atlas To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a1141cd78688d6d0531f280c4 Archived-At: Cc: The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 16:22:07 -0000 --001a1141cd78688d6d0531f280c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, This all looks good to me. Thanks for the quick resolution! I'll clear my discuss assuming that you will submit the updated version very very soon. Regards, Alia On Tue, May 3, 2016 at 12:13 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi, Alia, > > Thanks for the response! > > We are on the exact same page regarding items #1 and #2. > > For item #3, we really want to modularize the specs and not tie the -base > to the transports. Note that we mention =E2=80=9CUDP=E2=80=9D but also = =E2=80=9Cassociated channel > type=E2=80=9D. > > For #3, here=E2=80=99s the change I implemented: > > S-BFD packet MUST be demultiplexed with lower layer information > - (e.g., dedicated destination UDP port, associated channel type). > - Following procedure SHOULD be executed on both initiator and > - reflector. > + (e.g., dedicated destination UDP port [I-D.ietf-bfd-seamless-ip], > + associated channel type [I-D.ietf-pals-seamless-vccv]). Following > + procedure SHOULD be executed on both initiator and reflector. > > And please find attached full diffs addressing all the Discuss points. > > Thanks! > > =E2=80=94 Carlos. > > > > On May 3, 2016, at 10:53 AM, Alia Atlas wrote: > > Hi Carlos, > > On Mon, May 2, 2016 at 6:34 PM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Hi, Alia, >> >> Thanks for your review and for bringing up these issues =E2=80=94 please= see >> inline. >> >> > On May 2, 2016, at 5:24 PM, Alia Atlas wrote: >> > >> > Alia Atlas has entered the following ballot position for >> > draft-ietf-bfd-seamless-base-09: Discuss >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut thi= s >> > introductory paragraph, however.) >> > >> > >> > Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> > for more information about IESG DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > DISCUSS: >> > ---------------------------------------------------------------------- >> > >> > a) In Sec 7.2.3: "If the SBFDReflector is generating a response S-BFD >> > control packet for a local entity that is in >> > service, then "state" in response BFD control packets MUST be set >> > to UP." >> > So far, it looked like the SBFDReflector only sends BFD control >> > packets in response to receiving such packets >> > from SBFDInitiators. This paragraph (not just copied) does not >> > clearly describe the desired behavior. If the >> > monitored local entity is "temporarily out of service", does the >> > SBFDReflector respond back to the SBFDInitiator >> > with 2 BFD control packets - one indicating UP (as a MUST) and then >> > the next indicating ADMINDOWN? Is the >> > SBFDReflector expected to store a list of active SBFDInitiators and >> > proactively send BFD control packets indicating >> > ADMINDOWN? Please clarify in non-trivial detail. >> >> The way in which that particular bullet in that subsection is written ca= n >> be a bit confusing. >> >> First, you are right that the SBFDReflector only sends packets in >> response to S-BFD control packets from the SBFDInitiators. This is clear= ly >> spelled out in Section 5, and in other places that explain how the >> reflector is stateless. >> >> The SBFDReflector only response and does not stores a list of >> SBFDInitiators to proactively send S-BFD packets (see Section 5). Furthe= r, >> it does not respond with two packets. (UP and ADMINDOWN). >> >> I think this can be rewritten to better explain what happens, as follows= : >> >> OLD: >> o If the SBFDReflector wishes to communicate to some or all >> SBFDInitiators that monitored local entity is "temporarily out of >> service", then S-BFD control packets with "state" set to ADMINDOWN >> are sent to those SBFDInitiators. The SBFDInitiators, upon >> reception of such packets, MUST NOT conclude loss of reachability >> to corresponding remote entity, and MUST back off packet >> transmission interval for the remote entity to an interval no >> faster than 1 second. If the SBFDReflector is generating a >> response S-BFD control packet for a local entity that is in >> service, then "state" in response BFD control packets MUST be set >> to UP. >> >> NEW: >> o If the SBFDReflector, upon receiving an S-BFD control packet from >> an SBFDInitiators, wishes to communicate to those >> SBFDInitiators that a monitored local entity is "temporarily out o= f >> service", then an S-BFD control packet with "state" set to ADMINDO= WN >> is sent in response to those SBFDInitiators. The SBFDInitiators, >> upon >> reception of such packets, MUST NOT conclude loss of reachability >> to corresponding remote entity, and MUST back off packet >> transmission interval for the remote entity to an interval no >> faster than 1 second. If, on the other hand, the SBFDReflector is >> generating a >> response S-BFD control packet for a local entity that is in >> service, then "state" in response BFD control packets MUST be set >> to UP. >> >> Is that more clear? >> > > Slightly - but what about: > > "When the SBFDReflector receives an S-BFD control packet from an > SBFDInitiator, > then the SBFDReflector needs to determine what state to send in the > response S-BFD > control packet. If the monitored local entity is in service, then the > "state" MUST be > set to UP. However, if the monitored local entity is "temporarily out of > service" for > rapidly processing S-BFD packets, for instance due to an overload, then > the "state" > SHOULD be set to ADMINDOWN. The SBFDReflector SHOULD send a response > S-BFD control packet. > > When an SBFDInitiator receives a response S-BFD control packet, if the > state specified > is ADMINDOWN, the SBFDInitiator MUST NOT conclude loss of reachability > to corresponding remote entity, and MUST back off packet transmission > interval for the > remote entity to an interval no faster than 1 second. " > > Either wording or a mixture is just fine. >> >> >> > >> > b) Appendix A: The looping problem is nicely defined but the text sti= ll >> > discusses three potential solutions; clearly the >> > use of the D bit has been chosen. It would be much nicer to have the >> > justification in line, but for this discuss - the >> > unselected alternatives don't belong. >> > >> >> Sorry I=E2=80=99m not sure I understand fully your point. Are you sugges= ting we >> mention in the actual reason for the D-bit procedures outside the Append= ix >> (although the procedures for the D bit are explained in Section 6.2, 7.2= .2, >> 7.2.3, 7.3.2, and 7.2.2), while still leave the Appendix as-is? >> >> If so we can do that, but want to confirm. >> > > I'm suggesting that you mention the reason for the D-bit procedures > outside the Appendix and remove the Appendix. Alternately, keep the > Appendix but remove discussion of the other ways the problem could have > been solved and add a reference from the D-bit procedures to the Appendix= . > > Once this is an RFC, it doesn't matter what the other possible and > unselected design choices were. > > > c) Sec 7.2.1: " S-BFD packet MUST be demultiplexed with lower layer >> > information >> > (e.g., dedicated destination UDP port, associated channel type)." >> > Where precisely is this defined or described? Is there an allocation >> > for a dedicated UDP >> > port for S-BFD? I don't see any normative reference to such. In >> > particular, since the format >> > for an S-BFD control packet is exactly the same as for BFD and since >> only >> > this demultiplexing >> > with lower layer information is used to tell the difference between >> S-BFD >> > and BFD packets, >> > this document requires more specifics. >> > >> >> This is similar to RFC 5880 and RFC 5881. The actual S-BFD applications >> specify this. For example, bfd-seamless-ip defines the UDP port. We >> purposely do not want to have the specification (either explicitly or >> normatively pointed to) from this document, as this is just the base >> specification. >> > > Why? Unlike RFC 5880, this document mentions UDP ports as an example of = a > demultiplexer. > While I do understand that BFD can run with different transports, it is > useful to clearly articulate > one use transport that has enough information to be actually implemented. > In this case, that's > just a normative reference to another document progressing at the same > time. > > I can't get too worked up about normative vs. informative references in > general - the guideline I > use is whether an implementor would need to read the reference to properl= y > implement the > functionality. > > If you feel extremely strongly that the reference must be informative, I'= m > not going to dig in my > heels - but PLEASE put a reference by the mention of the UDP port. > > > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > 1) In the last paragraph of Sec 4.2: " Even when following the separa= te >> > discriminator pool approach, >> > collision is still possible between one S-BFD application to another >> > S-BFD application, that may be using different values and algorithms >> > to derive S-BFD discriminator values. If the two applications are >> > using S-BFD for a same purpose (e.g., network reachability), then th= e >> > colliding S-BFD discriminator value can be shared. If the two >> > applications are using S-BFD for a different purpose, then the >> > collision must be addressed. How such collisions are addressed is >> > outside the scope of this document." >> > >> > Sec 4.1 talks about the need for the S-BFD Discriminator to be unique >> > within an Administrative Domain. >> > I don't see any details of that addressed here. What is addressed >> > here seems to be the case for multiple >> > S-BFD discriminators applying to the same node - which is specificall= y >> > discouraged at the end of Sec 3. >> > Rather than simply describing the issue as "outside the scope of this >> > document", please either describe it >> > as "future work and multiple S-BFD discriminators is discouraged" or >> > add a reference. >> > >> >> Good point, will do. >> >> > 2) In Sec 6.1: "bfd.SessionType:" is defined but the only possible >> values >> > are for SBFD. Is it possible for a BFD >> > session to still use the same bfd structure? I don't see a value for >> > SessionType there; I'd expect to see at least >> > a value for the original BFD session and possible an undefined or >> > unspecified value for future proofing. >> > >> > >> >> Traditional BFD does not use this state variable. That=E2=80=99s why we = don=E2=80=99t >> need to define a value for BFD. However, future specs can when it is >> relevant (e.g, using BFD for various types as opposed to S-BFD), as for >> example bfd-multipoint. >> > > Right - I understand that. I'm thinking a bit from the implementation > perspective. If I have the same data-structures and similar logic for BF= D > and S-BFD, then there'll be a bfd.SessionType even for BFD sessions that > don't need it. Clarifying a value of "Unused" or "Classical BFD" gives > clarity that one > of the S-BFD options doesn't need to be chosen. > > This is just a comment. It's up to your best judgement. > > Thanks, > Alia > > > Please let us know your thoughts on the responses above, and we can send >> out diffs. >> >> Thanks! >> >> =E2=80=94 Carlos. >> >> >> > > > --001a1141cd78688d6d0531f280c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carlos,

This all looks good to me.= =C2=A0 Thanks for the quick resolution!
I'll clear my discuss= assuming that you will submit the updated version very very soon.

Regards,
Alia

On Tue, May 3, 2016 at 12:13 PM, Carlos = Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hi, Alia,
<= br>
Thanks for the response!

We are on t= he exact same page regarding items #1 and #2.

For = item #3, we really want to modularize the specs and not tie the -base to th= e transports. Note that we mention =E2=80=9CUDP=E2=80=9D but also =E2=80=9C= associated channel type=E2=80=9D.

For #3, here=E2= =80=99s the change I implemented:

=C2=A0 =C2=A0 S-BFD packet MUST be demultiplexed with lower layer informat= ion
- =C2=A0 (e.g., dedicated destination UDP port, associated ch= annel type).
- =C2=A0 Following procedure SHOULD be executed on both ini= tiator and
- =C2=A0 reflector.
+ =C2=A0 (e.g., dedicated destination = UDP port [I-D.ietf-bfd-seamless-ip],
+ =C2=A0 associated channel type [I= -D.ietf-pals-seamless-vccv]).=C2=A0 Following
+ =C2=A0 procedure SHOULD = be executed on both initiator and reflector.

And please f= ind attached full diffs addressing all the Discuss points.

Thanks!
<= br>
=E2=80=94 Carlos.



On May 3, 2016, at 10:53 AM, Alia Atlas <akatlas@gmail.com&= gt; wrote:

Hi Carlos,

On Mon, May 2, 2016 at 6:34 PM, Carlos P= ignataro (cpignata) <cpignata@cisco.com> wrote:
Hi, Alia,

Thanks for your review and for bringing up these issues =E2=80=94 please se= e inline.

> On May 2, 2016, at 5:24 PM, Alia Atlas <akatlas@gmail.com> wrote:
>
> Alia Atlas has entered the following ballot position for
> draft-ietf-bfd-seamless-base-09: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/= draft-ietf-bfd-seamless-base/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> a) In Sec 7.2.3:=C2=A0 "If the SBFDReflector is generating a resp= onse S-BFD
> control packet for a local entity that is in
>=C2=A0 =C2=A0 =C2=A0 service, then "state" in response BFD co= ntrol packets MUST be set
> to UP."
>=C2=A0 =C2=A0 So far, it looked like the SBFDReflector only sends BFD c= ontrol
> packets in response to receiving such packets
>=C2=A0 =C2=A0 from SBFDInitiators.=C2=A0 =C2=A0This paragraph (not just= copied) does not
> clearly describe the desired behavior.=C2=A0 If the
>=C2=A0 =C2=A0monitored local entity is "temporarily out of service= ", does the
> SBFDReflector respond back to the SBFDInitiator
>=C2=A0 =C2=A0with 2 BFD control packets - one indicating UP (as a MUST)= and then
> the next indicating ADMINDOWN?=C2=A0 Is the
>=C2=A0 =C2=A0SBFDReflector expected to store a list of active SBFDIniti= ators and
> proactively send BFD control packets indicating
>=C2=A0 =C2=A0ADMINDOWN?=C2=A0 =C2=A0Please clarify in non-trivial detai= l.

The way in which that particular bullet in that subsection is w= ritten can be a bit confusing.

First, you are right that the SBFDReflector only sends packets in response = to S-BFD control packets from the SBFDInitiators. This is clearly spelled o= ut in Section 5, and in other places that explain how the reflector is stat= eless.

The SBFDReflector only response and does not stores a list of SBFDInitiator= s to proactively send S-BFD packets (see Section 5). Further, it does not r= espond with two packets. (UP and ADMINDOWN).

I think this can be rewritten to better explain what happens, as follows:
OLD:
=C2=A0 =C2=A0o=C2=A0 If the SBFDReflector wishes to communicate to some or = all
=C2=A0 =C2=A0 =C2=A0 SBFDInitiators that monitored local entity is "te= mporarily out of
=C2=A0 =C2=A0 =C2=A0 service", then S-BFD control packets with "s= tate" set to ADMINDOWN
=C2=A0 =C2=A0 =C2=A0 are sent to those SBFDInitiators.=C2=A0 The SBFDInitia= tors, upon
=C2=A0 =C2=A0 =C2=A0 reception of such packets, MUST NOT conclude loss of r= eachability
=C2=A0 =C2=A0 =C2=A0 to corresponding remote entity, and MUST back off pack= et
=C2=A0 =C2=A0 =C2=A0 transmission interval for the remote entity to an inte= rval no
=C2=A0 =C2=A0 =C2=A0 faster than 1 second.=C2=A0 If the SBFDReflector is ge= nerating a
=C2=A0 =C2=A0 =C2=A0 response S-BFD control packet for a local entity= that is in
=C2=A0 =C2=A0 =C2=A0 service, then "state" in response BFD contro= l packets MUST be set
=C2=A0 =C2=A0 =C2=A0 to UP.

NEW:
=C2=A0 =C2=A0o=C2=A0 If the SBFDReflector, upon receiving an S-BFD control = packet from
=C2=A0 =C2=A0 =C2=A0 an SBFDInitiators, wishes to communicate to those
=C2=A0 =C2=A0 =C2=A0 SBFDInitiators that a monitored local entity is "= temporarily out of
=C2=A0 =C2=A0 =C2=A0 service", then an S-BFD control packet with "= ;state" set to ADMINDOWN
=C2=A0 =C2=A0 =C2=A0 is sent in response to those SBFDInitiators.=C2=A0 The= SBFDInitiators, upon
=C2=A0 =C2=A0 =C2=A0 reception of such packets, MUST NOT conclude loss of r= eachability
=C2=A0 =C2=A0 =C2=A0 to corresponding remote entity, and MUST back off pack= et
=C2=A0 =C2=A0 =C2=A0 transmission interval for the remote entity to an inte= rval no
=C2=A0 =C2=A0 =C2=A0 faster than 1 second.=C2=A0 If, on the other hand, the= SBFDReflector is generating a
=C2=A0 =C2=A0 =C2=A0 response S-BFD control packet for a local entity= that is in
=C2=A0 =C2=A0 =C2=A0 service, then "state" in response BFD contro= l packets MUST be set
=C2=A0 =C2=A0 =C2=A0 to UP.

Is that more clear?

Slightly - b= ut what about:

"When the SBFDReflector receiv= es an S-BFD control packet from an SBFDInitiator,
then the SBFDRe= flector needs to determine what state to send in the response S-BFD
control packet.=C2=A0 If the monitored local entity is in service, then = the "state" MUST be
set to UP.=C2=A0 However, if the mo= nitored local entity is "temporarily out of service" for
rapidly processing S-BFD packets, for instance due to an overload, then t= he "state"=C2=A0
SHOULD be set to ADMINDOWN.=C2=A0 The = SBFDReflector SHOULD send a response
S-BFD control packet. =C2=A0=

When an SBFDInitiator receives a response S-BFD c= ontrol packet, if the state specified
is ADMINDOWN, the SBFDIniti= ator MUST NOT conclude loss of =C2=A0reachability
to corresponding rem= ote entity, and MUST back off packet=C2=A0transmission interval for the=C2= =A0
remote entity to an interval no=C2=A0fa= ster than 1 second. "

Either wording or a mixture is just fine. =C2=A0=C2=A0=

>
> b) Appendix A:=C2=A0 The looping problem is nicely defined but the tex= t still
> discusses three potential solutions; clearly the
> use of the D bit has been chosen.=C2=A0 =C2=A0It would be much nicer t= o have the
> justification in line, but for this discuss - the
> unselected alternatives don't belong.
>

Sorry I=E2=80=99m not sure I understand fully your point. Are you su= ggesting we mention in the actual reason for the D-bit procedures outside t= he Appendix (although the procedures for the D bit are explained in Section= 6.2, 7.2.2, 7.2.3, 7.3.2, and 7.2.2), while still leave the Appendix as-is= ?

If so we can do that, but want to confirm.

<= div>I'm suggesting that you mention the reason for the D-bit procedures= outside the Appendix and remove the Appendix.=C2=A0 Alternately, keep the = Appendix but remove discussion of the other ways the problem could have bee= n solved and add a reference from the D-bit procedures to the Appendix.
=C2=A0
Once this is an RFC, it doesn't matter what the= other possible and unselected design choices were.

> c) Sec 7.2.1: "=C2=A0 =C2=A0S-BFD packet MUST be demultiplexed wi= th lower layer
> information
>=C2=A0 =C2=A0(e.g., dedicated destination UDP port, associated channel = type)."
>=C2=A0 Where precisely is this defined or described?=C2=A0 Is there an = allocation
> for a dedicated UDP
> port for S-BFD?=C2=A0 I don't see any normative reference to such.= =C2=A0 In
> particular, since the format
> for an S-BFD control packet is exactly the same as for BFD and since o= nly
> this demultiplexing
> with lower layer information is used to tell the difference between S-= BFD
> and BFD packets,
> this document requires more specifics.
>

This is similar to RFC 5880 and RFC 5881. The actual S-BFD applicati= ons specify this. For example, bfd-seamless-ip defines the UDP port. We pur= posely do not want to have the specification (either explicitly or normativ= ely pointed to) from this document, as this is just the base specification.=

Why?=C2=A0 Unlike RFC 5880, this docum= ent mentions UDP ports as an example of a demultiplexer.
While I = do understand that BFD can run with different transports, it is useful to c= learly articulate
one use transport that has enough information t= o be actually implemented. =C2=A0 In this case, that's
just a= normative reference to another document progressing at the same time.

I can't get too worked up about normative vs. info= rmative references in general - the guideline I
use is whether an= implementor would need to read the reference to properly implement the
functionality.

If you feel extremely strong= ly that the reference must be informative, I'm not going to dig in my
heels - but PLEASE put a reference by the mention of the UDP port.=
=C2=A0
=C2=A0
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> 1) In the last paragraph of Sec 4.2: "=C2=A0 Even when following = the separate
> discriminator pool approach,
>=C2=A0 =C2=A0collision is still possible between one S-BFD application = to another
>=C2=A0 =C2=A0S-BFD application, that may be using different values and = algorithms
>=C2=A0 =C2=A0to derive S-BFD discriminator values.=C2=A0 If the two app= lications are
>=C2=A0 =C2=A0using S-BFD for a same purpose (e.g., network reachability= ), then the
>=C2=A0 =C2=A0colliding S-BFD discriminator value can be shared.=C2=A0 I= f the two
>=C2=A0 =C2=A0applications are using S-BFD for a different purpose, then= the
>=C2=A0 =C2=A0collision must be addressed.=C2=A0 How such collisions are= addressed is
>=C2=A0 =C2=A0outside the scope of this document."
>
>=C2=A0 Sec 4.1 talks about the need for the S-BFD Discriminator to be u= nique
> within an Administrative Domain.
>=C2=A0 I don't see any details of that addressed here.=C2=A0 =C2=A0= What is addressed
> here seems to be the case for multiple
>=C2=A0 S-BFD discriminators applying to the same node - which is specif= ically
> discouraged at the end of Sec 3.
>=C2=A0 Rather than simply describing the issue as "outside the sco= pe of this
> document", please either describe it
>=C2=A0 as "future work and multiple S-BFD discriminators is discou= raged" or
> add a reference.
>

Good point, will do.

> 2) In Sec 6.1: "bfd.SessionType:" is defined but the only po= ssible values
> are for SBFD.=C2=A0 =C2=A0Is it possible for a BFD
> session to still use the same bfd structure?=C2=A0 I don't see a v= alue for
> SessionType there; I'd expect to see at least
> a value for the original BFD session and possible an undefined or
> unspecified value for future proofing.
>
>

Traditional BFD does not use this state variable. That=E2=80=99s why= we don=E2=80=99t need to define a value for BFD. However, future specs can= when it is relevant (e.g, using BFD for various types as opposed to S-BFD)= , as for example bfd-multipoint.

Right = - I understand that.=C2=A0 I'm thinking a bit from the implementation p= erspective.=C2=A0 If I have the same data-structures and similar logic for = BFD and S-BFD, then there'll be a bfd.SessionType even for BFD sessions= that don't need it.=C2=A0 Clarifying a value of "Unused" or = "Classical BFD" gives clarity that one=C2=A0
of the S-B= FD options doesn't need to be chosen.

This is = just a comment.=C2=A0 It's up to your best judgement.

Thanks,
Alia=C2=A0


Please let us know your thoughts on the responses above, and we can send ou= t diffs.

Thanks!

=E2=80=94 Carlos.






--001a1141cd78688d6d0531f280c4-- From nobody Tue May 3 09:24:55 2016 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 4552612D110; Tue, 3 May 2016 09:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 BNiPUPF-QKlp; Tue, 3 May 2016 09:24:49 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D06012DA76; Tue, 3 May 2016 09:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35673; q=dns/txt; s=iport; t=1462292629; x=1463502229; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=A5e8/7Zexo3mHqA68xAVL4qE7p/+SCXCw2EJv8LdVoY=; b=DKXBP0T1XJNT/HS3mLAw3WOUHmrzDfyg/oDEcEzdMK0ZJyNhzWaxC8uh iM2Ap22LvbIeO6KcwJGu0AGrEZ2Esf4Cy3N2gbLezARyOTDafWbX+ueX3 bFhgDS7+nyihCKVlElFSOW3ad2o7QxYYwpvn+KHuvDxAf1FiPb4DBpCRy E=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DDAgD1zyhX/4cNJK1fgzhTfQauK4lTg?= =?us-ascii?q?g8OgXUihW4CgT04FAEBAQEBAQFlJ4RBAQEBAwEaCVYFCwIBCA4KIAcDAgIhERQ?= =?us-ascii?q?RAgQOBQ4Nh3oDCggOq1CMSA2EOwEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0EBIYgg?= =?us-ascii?q?XaBVIEDgkOBThEBgxwrgi4Fh3iLLINkXTEBgyeBZ22GJYF3gWiETYMphTSHUYd?= =?us-ascii?q?gAR4BQ4I2gTVsAYZ9CRcEG38BAQE?= X-IronPort-AV: E=Sophos;i="5.24,573,1454976000"; d="asc'?scan'208,217";a="104121553" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 May 2016 16:23:47 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u43GNl7U012225 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 16:23:47 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 12:23:46 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 3 May 2016 12:23:46 -0400 From: "Carlos Pignataro (cpignata)" To: Alia Atlas Subject: Re: Alia Atlas' Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS and COMMENT) Thread-Topic: Alia Atlas' Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS and COMMENT) Thread-Index: AQHRpLkIQl1ke+WjZEO22I9fWz1zPp+mfzmAgAERloCAABYsAIAAAlKAgAAAooA= Date: Tue, 3 May 2016 16:23:46 +0000 Message-ID: References: <20160502212434.15622.98408.idtracker@ietfa.amsl.com> <059ECD31-C883-4721-8FA1-3FCEE9FCE1AC@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.48.199] Content-Type: multipart/signed; boundary="Apple-Mail=_8A9D0AB1-7E12-4E55-B06D-44FFCD7CF9D4"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 16:24:52 -0000 --Apple-Mail=_8A9D0AB1-7E12-4E55-B06D-44FFCD7CF9D4 Content-Type: multipart/alternative; boundary="Apple-Mail=_2B747146-41F8-4172-B18B-DE31D659CC2E" --Apple-Mail=_2B747146-41F8-4172-B18B-DE31D659CC2E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alia, Thank you. Yes, I will submit before the telechat, but will still wait a = couple days for additional comments. Best, =E2=80=94 Carlos. > On May 3, 2016, at 12:21 PM, Alia Atlas wrote: >=20 > Hi Carlos, >=20 > This all looks good to me. Thanks for the quick resolution! > I'll clear my discuss assuming that you will submit the updated = version very very soon. >=20 > Regards, > Alia >=20 > On Tue, May 3, 2016 at 12:13 PM, Carlos Pignataro (cpignata) = > wrote: > Hi, Alia, >=20 > Thanks for the response! >=20 > We are on the exact same page regarding items #1 and #2. >=20 > For item #3, we really want to modularize the specs and not tie the = -base to the transports. Note that we mention =E2=80=9CUDP=E2=80=9D but = also =E2=80=9Cassociated channel type=E2=80=9D. >=20 > For #3, here=E2=80=99s the change I implemented: >=20 > S-BFD packet MUST be demultiplexed with lower layer information > - (e.g., dedicated destination UDP port, associated channel type). > - Following procedure SHOULD be executed on both initiator and > - reflector. > + (e.g., dedicated destination UDP port [I-D.ietf-bfd-seamless-ip], > + associated channel type [I-D.ietf-pals-seamless-vccv]). Following > + procedure SHOULD be executed on both initiator and reflector. >=20 > And please find attached full diffs addressing all the Discuss points. >=20 > Thanks! >=20 > =E2=80=94 Carlos. >=20 >=20 >=20 >> On May 3, 2016, at 10:53 AM, Alia Atlas > wrote: >>=20 >> Hi Carlos, >>=20 >> On Mon, May 2, 2016 at 6:34 PM, Carlos Pignataro (cpignata) = > wrote: >> Hi, Alia, >>=20 >> Thanks for your review and for bringing up these issues =E2=80=94 = please see inline. >>=20 >> > On May 2, 2016, at 5:24 PM, Alia Atlas > wrote: >> > >> > Alia Atlas has entered the following ballot position for >> > draft-ietf-bfd-seamless-base-09: Discuss >> > >> > When responding, please keep the subject line intact and reply to = all >> > email addresses included in the To and CC lines. (Feel free to cut = this >> > introductory paragraph, however.) >> > >> > >> > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = >> > for more information about IESG DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ = >> > >> > >> > >> > = ---------------------------------------------------------------------- >> > DISCUSS: >> > = ---------------------------------------------------------------------- >> > >> > a) In Sec 7.2.3: "If the SBFDReflector is generating a response = S-BFD >> > control packet for a local entity that is in >> > service, then "state" in response BFD control packets MUST be = set >> > to UP." >> > So far, it looked like the SBFDReflector only sends BFD control >> > packets in response to receiving such packets >> > from SBFDInitiators. This paragraph (not just copied) does not >> > clearly describe the desired behavior. If the >> > monitored local entity is "temporarily out of service", does the >> > SBFDReflector respond back to the SBFDInitiator >> > with 2 BFD control packets - one indicating UP (as a MUST) and = then >> > the next indicating ADMINDOWN? Is the >> > SBFDReflector expected to store a list of active SBFDInitiators = and >> > proactively send BFD control packets indicating >> > ADMINDOWN? Please clarify in non-trivial detail. >>=20 >> The way in which that particular bullet in that subsection is written = can be a bit confusing. >>=20 >> First, you are right that the SBFDReflector only sends packets in = response to S-BFD control packets from the SBFDInitiators. This is = clearly spelled out in Section 5, and in other places that explain how = the reflector is stateless. >>=20 >> The SBFDReflector only response and does not stores a list of = SBFDInitiators to proactively send S-BFD packets (see Section 5). = Further, it does not respond with two packets. (UP and ADMINDOWN). >>=20 >> I think this can be rewritten to better explain what happens, as = follows: >>=20 >> OLD: >> o If the SBFDReflector wishes to communicate to some or all >> SBFDInitiators that monitored local entity is "temporarily out = of >> service", then S-BFD control packets with "state" set to = ADMINDOWN >> are sent to those SBFDInitiators. The SBFDInitiators, upon >> reception of such packets, MUST NOT conclude loss of = reachability >> to corresponding remote entity, and MUST back off packet >> transmission interval for the remote entity to an interval no >> faster than 1 second. If the SBFDReflector is generating a >> response S-BFD control packet for a local entity that is in >> service, then "state" in response BFD control packets MUST be = set >> to UP. >>=20 >> NEW: >> o If the SBFDReflector, upon receiving an S-BFD control packet = from >> an SBFDInitiators, wishes to communicate to those >> SBFDInitiators that a monitored local entity is "temporarily = out of >> service", then an S-BFD control packet with "state" set to = ADMINDOWN >> is sent in response to those SBFDInitiators. The = SBFDInitiators, upon >> reception of such packets, MUST NOT conclude loss of = reachability >> to corresponding remote entity, and MUST back off packet >> transmission interval for the remote entity to an interval no >> faster than 1 second. If, on the other hand, the SBFDReflector = is generating a >> response S-BFD control packet for a local entity that is in >> service, then "state" in response BFD control packets MUST be = set >> to UP. >>=20 >> Is that more clear? >>=20 >> Slightly - but what about: >>=20 >> "When the SBFDReflector receives an S-BFD control packet from an = SBFDInitiator, >> then the SBFDReflector needs to determine what state to send in the = response S-BFD >> control packet. If the monitored local entity is in service, then = the "state" MUST be >> set to UP. However, if the monitored local entity is "temporarily = out of service" for >> rapidly processing S-BFD packets, for instance due to an overload, = then the "state" >> SHOULD be set to ADMINDOWN. The SBFDReflector SHOULD send a response >> S-BFD control packet. >>=20 >> When an SBFDInitiator receives a response S-BFD control packet, if = the state specified >> is ADMINDOWN, the SBFDInitiator MUST NOT conclude loss of = reachability >> to corresponding remote entity, and MUST back off packet transmission = interval for the >> remote entity to an interval no faster than 1 second. " >>=20 >> Either wording or a mixture is just fine. >>=20 >> > >> > b) Appendix A: The looping problem is nicely defined but the text = still >> > discusses three potential solutions; clearly the >> > use of the D bit has been chosen. It would be much nicer to have = the >> > justification in line, but for this discuss - the >> > unselected alternatives don't belong. >> > >>=20 >> Sorry I=E2=80=99m not sure I understand fully your point. Are you = suggesting we mention in the actual reason for the D-bit procedures = outside the Appendix (although the procedures for the D bit are = explained in Section 6.2, 7.2.2, 7.2.3, 7.3.2, and 7.2.2), while still = leave the Appendix as-is? >>=20 >> If so we can do that, but want to confirm. >>=20 >> I'm suggesting that you mention the reason for the D-bit procedures = outside the Appendix and remove the Appendix. Alternately, keep the = Appendix but remove discussion of the other ways the problem could have = been solved and add a reference from the D-bit procedures to the = Appendix. >>=20 >> Once this is an RFC, it doesn't matter what the other possible and = unselected design choices were. >>=20 >> > c) Sec 7.2.1: " S-BFD packet MUST be demultiplexed with lower = layer >> > information >> > (e.g., dedicated destination UDP port, associated channel type)." >> > Where precisely is this defined or described? Is there an = allocation >> > for a dedicated UDP >> > port for S-BFD? I don't see any normative reference to such. In >> > particular, since the format >> > for an S-BFD control packet is exactly the same as for BFD and = since only >> > this demultiplexing >> > with lower layer information is used to tell the difference between = S-BFD >> > and BFD packets, >> > this document requires more specifics. >> > >>=20 >> This is similar to RFC 5880 and RFC 5881. The actual S-BFD = applications specify this. For example, bfd-seamless-ip defines the UDP = port. We purposely do not want to have the specification (either = explicitly or normatively pointed to) from this document, as this is = just the base specification. >>=20 >> Why? Unlike RFC 5880, this document mentions UDP ports as an example = of a demultiplexer. >> While I do understand that BFD can run with different transports, it = is useful to clearly articulate >> one use transport that has enough information to be actually = implemented. In this case, that's >> just a normative reference to another document progressing at the = same time. >>=20 >> I can't get too worked up about normative vs. informative references = in general - the guideline I >> use is whether an implementor would need to read the reference to = properly implement the >> functionality. >>=20 >> If you feel extremely strongly that the reference must be = informative, I'm not going to dig in my >> heels - but PLEASE put a reference by the mention of the UDP port. >>=20 >>=20 >> > >> > = ---------------------------------------------------------------------- >> > COMMENT: >> > = ---------------------------------------------------------------------- >> > >> > 1) In the last paragraph of Sec 4.2: " Even when following the = separate >> > discriminator pool approach, >> > collision is still possible between one S-BFD application to = another >> > S-BFD application, that may be using different values and = algorithms >> > to derive S-BFD discriminator values. If the two applications = are >> > using S-BFD for a same purpose (e.g., network reachability), then = the >> > colliding S-BFD discriminator value can be shared. If the two >> > applications are using S-BFD for a different purpose, then the >> > collision must be addressed. How such collisions are addressed = is >> > outside the scope of this document." >> > >> > Sec 4.1 talks about the need for the S-BFD Discriminator to be = unique >> > within an Administrative Domain. >> > I don't see any details of that addressed here. What is = addressed >> > here seems to be the case for multiple >> > S-BFD discriminators applying to the same node - which is = specifically >> > discouraged at the end of Sec 3. >> > Rather than simply describing the issue as "outside the scope of = this >> > document", please either describe it >> > as "future work and multiple S-BFD discriminators is discouraged" = or >> > add a reference. >> > >>=20 >> Good point, will do. >>=20 >> > 2) In Sec 6.1: "bfd.SessionType:" is defined but the only possible = values >> > are for SBFD. Is it possible for a BFD >> > session to still use the same bfd structure? I don't see a value = for >> > SessionType there; I'd expect to see at least >> > a value for the original BFD session and possible an undefined or >> > unspecified value for future proofing. >> > >> > >>=20 >> Traditional BFD does not use this state variable. That=E2=80=99s why = we don=E2=80=99t need to define a value for BFD. However, future specs = can when it is relevant (e.g, using BFD for various types as opposed to = S-BFD), as for example bfd-multipoint. >>=20 >> Right - I understand that. I'm thinking a bit from the = implementation perspective. If I have the same data-structures and = similar logic for BFD and S-BFD, then there'll be a bfd.SessionType even = for BFD sessions that don't need it. Clarifying a value of "Unused" or = "Classical BFD" gives clarity that one >> of the S-BFD options doesn't need to be chosen. >>=20 >> This is just a comment. It's up to your best judgement. >>=20 >> Thanks, >> Alia >>=20 >>=20 >> Please let us know your thoughts on the responses above, and we can = send out diffs. >>=20 >> Thanks! >>=20 >> =E2=80=94 Carlos. >>=20 >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_2B747146-41F8-4172-B18B-DE31D659CC2E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Alia,

Thank you. Yes, I will submit before the telechat, but will = still wait a couple days for additional comments.
Best,

=E2=80=94 Carlos.

On May 3, 2016, at 12:21 PM, Alia Atlas <akatlas@gmail.com> = wrote:

Hi Carlos,

This all looks good to me.  Thanks = for the quick resolution!
I'll clear my discuss = assuming that you will submit the updated version very very = soon.

Regards,
Alia

On Tue, = May 3, 2016 at 12:13 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hi, Alia,

Thanks for the response!

We are on the exact same = page regarding items #1 and #2.

For item #3, we really want to = modularize the specs and not tie the -base to the transports. Note that = we mention =E2=80=9CUDP=E2=80=9D but also =E2=80=9Cassociated channel = type=E2=80=9D.

For #3, here=E2=80=99s the change I implemented:

  =   S-BFD packet MUST be demultiplexed with lower layer = information
-   (e.g., dedicated destination = UDP port, associated channel type).
-   Following = procedure SHOULD be executed on both initiator and
- =   reflector.
+   (e.g., dedicated destination = UDP port [I-D.ietf-bfd-seamless-ip],
+   associated = channel type [I-D.ietf-pals-seamless-vccv]).  Following
+   procedure SHOULD be executed on both initiator and = reflector.

And please = find attached full diffs addressing all the Discuss points.

Thanks!

=E2=80=94 Carlos.



On May 3, 2016, at 10:53 AM, Alia Atlas = <akatlas@gmail.com> wrote:

Hi Carlos,

On Mon, = May 2, 2016 at 6:34 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hi, Alia,

Thanks for your review and for bringing up these issues =E2=80=94 please = see inline.

> On May 2, 2016, at 5:24 PM, Alia Atlas <akatlas@gmail.com> wrote:
>
> Alia Atlas has entered the following ballot position for
> draft-ietf-bfd-seamless-base-09: Discuss
>
> When responding, please keep the subject line intact and reply to = all
> email addresses included in the To and CC lines. (Feel free to cut = this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found = here:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/<= /a>
>
>
>
> = ----------------------------------------------------------------------
> DISCUSS:
> = ----------------------------------------------------------------------
>
> a) In Sec 7.2.3:  "If the SBFDReflector is generating a = response S-BFD
> control packet for a local entity that is in
>      service, then "state" in response BFD control = packets MUST be set
> to UP."
>    So far, it looked like the SBFDReflector only sends = BFD control
> packets in response to receiving such packets
>    from SBFDInitiators.   This paragraph (not = just copied) does not
> clearly describe the desired behavior.  If the
>   monitored local entity is "temporarily out of service", = does the
> SBFDReflector respond back to the SBFDInitiator
>   with 2 BFD control packets - one indicating UP (as a = MUST) and then
> the next indicating ADMINDOWN?  Is the
>   SBFDReflector expected to store a list of active = SBFDInitiators and
> proactively send BFD control packets indicating
>   ADMINDOWN?   Please clarify in non-trivial = detail.

The way in which that particular bullet in that subsection = is written can be a bit confusing.

First, you are right that the SBFDReflector only sends packets in = response to S-BFD control packets from the SBFDInitiators. This is = clearly spelled out in Section 5, and in other places that explain how = the reflector is stateless.

The SBFDReflector only response and does not stores a list of = SBFDInitiators to proactively send S-BFD packets (see Section 5). = Further, it does not respond with two packets. (UP and ADMINDOWN).

I think this can be rewritten to better explain what happens, as = follows:

OLD:
   o  If the SBFDReflector wishes to communicate to some = or all
      SBFDInitiators that monitored local entity is = "temporarily out of
      service", then S-BFD control packets with "state" = set to ADMINDOWN
      are sent to those SBFDInitiators.  The = SBFDInitiators, upon
      reception of such packets, MUST NOT conclude loss = of reachability
      to corresponding remote entity, and MUST back off = packet
      transmission interval for the remote entity to an = interval no
      faster than 1 second.  If the SBFDReflector is = generating a
      response S-BFD control packet for = a local entity that is in
      service, then "state" in response BFD control = packets MUST be set
      to UP.

NEW:
   o  If the SBFDReflector, upon receiving an S-BFD = control packet from
      an SBFDInitiators, wishes to communicate to = those
      SBFDInitiators that a monitored local entity is = "temporarily out of
      service", then an S-BFD control packet with "state" = set to ADMINDOWN
      is sent in response to those SBFDInitiators.  = The SBFDInitiators, upon
      reception of such packets, MUST NOT conclude loss = of reachability
      to corresponding remote entity, and MUST back off = packet
      transmission interval for the remote entity to an = interval no
      faster than 1 second.  If, on the other hand, = the SBFDReflector is generating a
      response S-BFD control packet for = a local entity that is in
      service, then "state" in response BFD control = packets MUST be set
      to UP.

Is that more clear?

Slightly - but what about:

"When the SBFDReflector = receives an S-BFD control packet from an SBFDInitiator,
then the SBFDReflector needs to determine what state to send = in the response S-BFD
control packet.  If the = monitored local entity is in service, then the "state" MUST be
set to UP.  However, if the monitored local entity is = "temporarily out of service" for
rapidly processing = S-BFD packets, for instance due to an overload, then the = "state" 
SHOULD be set to ADMINDOWN.  The = SBFDReflector SHOULD send a response
S-BFD control = packet.  

When an SBFDInitiator receives a response S-BFD control = packet, if the state specified
is ADMINDOWN, the = SBFDInitiator MUST NOT conclude loss of  reachability
to = corresponding remote entity, and MUST back off packet transmission = interval for the 
remote entity to = an interval no faster than 1 second. "

Either wording or a mixture is just fine. =   

>
> b) Appendix A:  The looping problem is nicely defined but the = text still
> discusses three potential solutions; clearly the
> use of the D bit has been chosen.   It would be much = nicer to have the
> justification in line, but for this discuss - the
> unselected alternatives don't belong.
>

Sorry I=E2=80=99m not sure I understand fully your point. Are you = suggesting we mention in the actual reason for the D-bit procedures = outside the Appendix (although the procedures for the D bit are = explained in Section 6.2, 7.2.2, 7.2.3, 7.3.2, and 7.2.2), while still = leave the Appendix as-is?

If so we can do that, but want to confirm.

I'm suggesting that you = mention the reason for the D-bit procedures outside the Appendix and = remove the Appendix.  Alternately, keep the Appendix but remove = discussion of the other ways the problem could have been solved and add = a reference from the D-bit procedures to the Appendix.
 
Once this is an RFC, it doesn't = matter what the other possible and unselected design choices = were.

> c) Sec 7.2.1: "   S-BFD packet MUST be demultiplexed with = lower layer
> information
>   (e.g., dedicated destination UDP port, associated = channel type)."
>  Where precisely is this defined or described?  Is there = an allocation
> for a dedicated UDP
> port for S-BFD?  I don't see any normative reference to = such.  In
> particular, since the format
> for an S-BFD control packet is exactly the same as for BFD and = since only
> this demultiplexing
> with lower layer information is used to tell the difference between = S-BFD
> and BFD packets,
> this document requires more specifics.
>

This is similar to RFC 5880 and RFC 5881. The actual S-BFD = applications specify this. For example, bfd-seamless-ip defines the UDP = port. We purposely do not want to have the specification (either = explicitly or normatively pointed to) from this document, as this is = just the base specification.

Why?  Unlike RFC = 5880, this document mentions UDP ports as an example of a = demultiplexer.
While I do understand that BFD can = run with different transports, it is useful to clearly = articulate
one use transport that has enough = information to be actually implemented.   In this case, = that's
just a normative reference to another = document progressing at the same time.

I can't get too worked up about = normative vs. informative references in general - the guideline = I
use is whether an implementor would need to read = the reference to properly implement the
functionality.

If you feel extremely strongly that the reference must be = informative, I'm not going to dig in my
heels - but = PLEASE put a reference by the mention of the UDP port.
 
 
>
> = ----------------------------------------------------------------------
> COMMENT:
> = ----------------------------------------------------------------------
>
> 1) In the last paragraph of Sec 4.2: "  Even when following = the separate
> discriminator pool approach,
>   collision is still possible between one S-BFD = application to another
>   S-BFD application, that may be using different values = and algorithms
>   to derive S-BFD discriminator values.  If the two = applications are
>   using S-BFD for a same purpose (e.g., network = reachability), then the
>   colliding S-BFD discriminator value can be = shared.  If the two
>   applications are using S-BFD for a different purpose, = then the
>   collision must be addressed.  How such collisions = are addressed is
>   outside the scope of this document."
>
>  Sec 4.1 talks about the need for the S-BFD Discriminator to = be unique
> within an Administrative Domain.
>  I don't see any details of that addressed here.  =  What is addressed
> here seems to be the case for multiple
>  S-BFD discriminators applying to the same node - which is = specifically
> discouraged at the end of Sec 3.
>  Rather than simply describing the issue as "outside the scope = of this
> document", please either describe it
>  as "future work and multiple S-BFD discriminators is = discouraged" or
> add a reference.
>

Good point, will do.

> 2) In Sec 6.1: "bfd.SessionType:" is defined but the only possible = values
> are for SBFD.   Is it possible for a BFD
> session to still use the same bfd structure?  I don't see a = value for
> SessionType there; I'd expect to see at least
> a value for the original BFD session and possible an undefined = or
> unspecified value for future proofing.
>
>

Traditional BFD does not use this state variable. That=E2=80=99s = why we don=E2=80=99t need to define a value for BFD. However, future = specs can when it is relevant (e.g, using BFD for various types as = opposed to S-BFD), as for example bfd-multipoint.

Right - I understand that.  I'm thinking a bit from the = implementation perspective.  If I have the same data-structures and = similar logic for BFD and S-BFD, then there'll be a bfd.SessionType even = for BFD sessions that don't need it.  Clarifying a value of = "Unused" or "Classical BFD" gives clarity that one 
of the S-BFD options doesn't need to be chosen.

This is just a = comment.  It's up to your best judgement.

Thanks,
Alia 


Please let us know your thoughts on the responses above, and we can send = out diffs.

Thanks!

=E2=80=94 Carlos.







= --Apple-Mail=_2B747146-41F8-4172-B18B-DE31D659CC2E-- --Apple-Mail=_8A9D0AB1-7E12-4E55-B06D-44FFCD7CF9D4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXKNCRAAoJEIXgpQGOZny9alYP/RcERHzGp/BBh9cIdrtUKA00 rA7Vz23+dEsSop+KqnNj9ZGRMc7fH4J7B4cnhgmIzdNWsEQUzJzKbx0n+ngw31w/ aOr3GWNQxz0oIvC24Ok3CL1RUATeC/7WN3OF6yV/uaAPwNPJmGnZJ6zvH6piNPZY lpknATYqSLa0oPvsTH2N21Re1Xn+bLpkALNETKDoq7TE7TdA7/a7moo6FCoKsvCG nFFcwmjrfl0/x37S0SiGiUHBEJvey8+9zGt8QvEERd1sYVVevxFeCjAcfYlb7zzN paM/skjyrGVsHMV4xkEzzRipGzMRygaVKSiuGtEf/Jeb2QsywdcM+8ZpjC2JDRVT 5+FET+6GBWDblg2P3W6kSeROWF5Wc5m4bqVdwF+Q5wvw2HBaGPxIA4cYfaaHLJmP VaVjWIiu+pwGjuJNtC6j8MTu+gakW94dDi/MePD6ADQW5cfSoaTdIkWndJXVi1P5 5/pMWAxH3DlPMhh7C7rYE/wSRdhc/3J7prfQ0usAAzm5vHaqkN4cWXe+0kvw/oHN C+3ozORRNQqqzWhmySqn4rymREHOBDmt+7MdlZxAnzQFeSUR6QgSauWg+d/sMqk4 osT8EDWpQvqA2zTWqvNN0Tu/NMVPQvd5MuS/iyU/zFX0qP5Oil/sbMI1DWyOOATL 7Z6yaW0gyTqS34JZ5vNe =zCOp -----END PGP SIGNATURE----- --Apple-Mail=_8A9D0AB1-7E12-4E55-B06D-44FFCD7CF9D4-- From nobody Tue May 3 09:29:04 2016 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 0245712DAA2; Tue, 3 May 2016 09:29:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" Subject: Alia Atlas' Yes on draft-ietf-bfd-seamless-base-09: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503162903.8315.98411.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 09:29:03 -0700 Archived-At: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 16:29:03 -0000 Alia Atlas has entered the following ballot position for draft-ietf-bfd-seamless-base-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss concerns. I look forward to the updated draft. From nobody Tue May 3 09:32:06 2016 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 8A2A612DAA2; Tue, 3 May 2016 09:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Ro8QMP-DNNeX; Tue, 3 May 2016 09:31:57 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (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 3D7F212DA9F; Tue, 3 May 2016 09:30:46 -0700 (PDT) Received: by mail-ob0-x22c.google.com with SMTP id x1so7803051obt.0; Tue, 03 May 2016 09:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=aUM49Z+EiLbuyt+cBDSEyb48OtL/RHBlct4SQi1UWuw=; b=FNfm/ZpJmy+EzTklhlBvfVK6bMiowKjM2HAlXgmQvkV3sBfEHUmj15quYr7lq2y21j 1vKFTpFkPxey2qp1V4/vwmZ8AJ/Y+anwaJwHKD9svRG1b2xQW0Gy/+gieXcyH8lTyOYQ uXeraDJCJ4RrYlx57OdwqOdrGMRefAdxB8rdry8cjAavb/YviwFwhsGjzGd0YQskmHDL nhKNCJDBH4PNIx9BpjOjvKPJ3ogapjq3d6aU9mYk3MPgDVKaKz3Yy1/VcES5BHay0LDR xhUaZRIVkMIoAczSjDvmsFHDdKj8g/DAlxX3NQpf42Cl/vodkfgHtXWtcLvnP96dlYHR RG5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=aUM49Z+EiLbuyt+cBDSEyb48OtL/RHBlct4SQi1UWuw=; b=NZrou7wwmRA6AwhjDBLZYWCCrtp/ZgZ5RwQRPFpo/kJf5rLmABRa15wJ6FRrjvh/N9 m3gwaisTUgMljGol7dV+1LovEExU73f+hfSI8odsn7Z9FXkzwzt6jPo6PJCKfCWEUHOv wrdqp3JxXtaskV/sVc146pTvDm3c7a3pcyGuBPENRrQe2AP7TurCvcCv3Y0Xn4znsBOD N6zESFvmRipFErXK4Yp/U7krDV9mVI1lZAQ1kLz5AdJ8Or8BWz2zsyJwFRsxoiy6ZdT5 y46O/H4CgADqQPlPTKTxP2McJq7qykEqKloRAsivCX6jEEFlYhtmRkWepkoyHdmCGstT pokQ== X-Gm-Message-State: AOPr4FXapUJtceW8f3Pw7WYidssbu7Ewu5/NDfoTuy0ZD1HGfL0+qpMpbLkDKRLscXcIX9W0CgvVD2RJhBMp1w== MIME-Version: 1.0 X-Received: by 10.182.118.170 with SMTP id kn10mr1769115obb.57.1462293045573; Tue, 03 May 2016 09:30:45 -0700 (PDT) Received: by 10.60.115.168 with HTTP; Tue, 3 May 2016 09:30:45 -0700 (PDT) In-Reply-To: <52C94004-5548-4701-AA81-EBF8D5EC1BDD@cisco.com> References: <20160502222627.15846.1446.idtracker@ietfa.amsl.com> <52C94004-5548-4701-AA81-EBF8D5EC1BDD@cisco.com> Date: Tue, 3 May 2016 12:30:45 -0400 Message-ID: Subject: Re: Alia Atlas' Discuss on draft-ietf-bfd-seamless-ip-04: (with DISCUSS) From: Alia Atlas To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=089e0149cdc48a040c0531f2a10e Archived-At: Cc: "draft-ietf-bfd-seamless-ip@ietf.org" , The IESG , "rtg-bfd@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 16:32:00 -0000 --089e0149cdc48a040c0531f2a10e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, On Mon, May 2, 2016 at 7:22 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi Alia, > > Thanks for the review and for these! Please see inline. > > > On May 2, 2016, at 6:26 PM, Alia Atlas wrote: > > > > Alia Atlas has entered the following ballot position for > > draft-ietf-bfd-seamless-ip-04: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I think that these are both simple fast issues to resolve. > > > > 1) Sec 3: "This document defines only the UDP port value > > for the S-BFD Echo function. The source port and the procedures for > > the S-BFD Echo function are outside the scope of this document." > > Please add a reference to the S-BFD base document for defining where th= e > > procedures are found. > > > > Where, precisely, is the source port defined? It wasn't in the S-BFD > > base > > document. This seems like a hole. Can you please clarify? > > This is done exactly as in RFC 5881, purposefully. I can add a clarifying > sentence like: > > OLD: > This document defines only the UDP port value > for the S-BFD Echo function. The source port and the procedures for > the S-BFD Echo function are outside the scope of this document. > > NEW: > S-BFD echo follows the BFD echo definitions of [RFC 5881]. > Consequently, this document defines only the UDP port value > for the S-BFD Echo function; the source port and the procedures for > the S-BFD Echo function are outside the scope of this document. > How about a reference by the source port to [RFC 5881] and a reference for the procedures for the S-BFD Echo function [draft-ietf-bfd-seamless-base]? What wasn't clear to me - not having recently read RFC 5881 in detail - was that the UDP source port was defined in RFC 5881. I knew the procedures were in draft-ietf-bfd-seamless-base. > > > > 2) Sec 4: " If the port is not 7784, then the packet MUST be looked up > > to locate > > a corresponding SBFDInitiator session or classical BFD session based > > on the value from the "your discriminator" field in the table > > describing BFD discriminators. " > > > > I assume that you mean that UDP source port is used to look up the > > appropriate receiver. > > If that receiver handles BFD and S-BFD packets, then the "your > > discriminator" field is used > > to identify the BFD session. PLEASE clarify that because this reads a= s > > if BFD is the only > > application that uses UDP. > > > > Indeed, very much so. I suggest: > > OLD: > If the port is not 7784, then the packet MUST be looked up to locate > a corresponding SBFDInitiator session or classical BFD session based > on the value from the "your discriminator" field in the table > describing BFD discriminators. If the located session is an > SBFDInitiator, then the destination IP address of the packet SHOULD > be validated to be for self. If the packet is a classical BFD > session, then the procedures from [RFC5880] apply. > > NEW: > If the port is not 7784, but the packet is demultiplexed to be for an > SBFDInitiator, then the packet MUST be looked up to locate > a corresponding SBFDInitiator session based > on the value from the "your discriminator" field in the table > describing BFD discriminators. In that case, > then the destination IP address of the packet SHOULD > be validated to be for itself. If the packet demultiplexes to a > classical BFD > session, then the procedures from [RFC5880] apply. > > Would that work? > Sure - sounds good. Thanks, Alia > Thanks, > > =E2=80=94 Carlos. > > > > > > > > > --089e0149cdc48a040c0531f2a10e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carlos,

On Mon, May 2, 2016 at 7:22 PM, Carlos Pignataro (cpignata) <cp= ignata@cisco.com> wrote:
Hi= Alia,

Thanks for the review and for these! Please see inline.

> On May 2, 2016, at 6:26 PM, Alia Atlas <akatlas@gmail.com> wrote:
>
> Alia Atlas has entered the following ballot position for
> draft-ietf-bfd-seamless-ip-04: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/dr= aft-ietf-bfd-seamless-ip/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> I think that these are both simple fast issues to resolve.
>
> 1) Sec 3: "This document defines only the UDP port value
>=C2=A0 =C2=A0for the S-BFD Echo function.=C2=A0 The source port and the= procedures for
>=C2=A0 =C2=A0the S-BFD Echo function are outside the scope of this docu= ment."
> Please add a reference to the S-BFD base document for defining where t= he
> procedures are found.
>
> Where, precisely, is the source port defined?=C2=A0 It wasn't in t= he S-BFD
> base
> document.=C2=A0 This seems like a hole.=C2=A0 Can you please clarify?<= br>
This is done exactly as in RFC 5881, purposefully. I can add a clari= fying sentence like:

OLD:
=C2=A0 =C2=A0This document defines only the UDP port value=
=C2=A0 =C2=A0for the S-BFD Echo function.=C2=A0 The source port and the pro= cedures for
=C2=A0 =C2=A0the S-BFD Echo function are outside the scope of this document= .

NEW:
=C2=A0 =C2=A0S-BFD echo follows the BFD echo definitions of [RFC 5881].
=C2=A0 =C2=A0Consequently, this document defines only the UDP port value =C2=A0 =C2=A0for the S-BFD Echo function; the source port and the procedure= s for
=C2=A0 =C2=A0the S-BFD Echo function are outside the scope= of this document.

How about a r= eference by the source port to [RFC 5881] and a reference
for the= procedures for the S-BFD Echo function [draft-ietf-bfd-seamless-base]?

What wasn't clear to me - not having recently rea= d RFC 5881 in detail - was
that the UDP source port was defined i= n RFC 5881.=C2=A0 I knew the procedures were
in draft-ietf-bfd-se= amless-base.
=C2=A0
>
> 2) Sec 4:=C2=A0 " If the port is not 7784= , then the packet MUST be looked up
> to locate
>=C2=A0 =C2=A0a corresponding SBFDInitiator session or classical BFD ses= sion based
>=C2=A0 =C2=A0on the value from the "your discriminator" field= in the table
>=C2=A0 =C2=A0describing BFD discriminators. "
>
> I assume that you mean that UDP source port is used to look up the
> appropriate receiver.
> If that receiver handles BFD and S-BFD packets, then the "your > discriminator" field is used
> to identify the BFD session.=C2=A0 =C2=A0PLEASE clarify that because t= his reads as
> if BFD is the only
> application that uses UDP.
>

Indeed, very much so. I suggest:

OLD:
=C2=A0 =C2=A0If the port is not 7784, then the packet MUST= be looked up to locate
=C2=A0 =C2=A0a corresponding SBFDInitiator session or classical BFD session= based
=C2=A0 =C2=A0on the value from the "your discriminator" field in = the table
=C2=A0 =C2=A0describing BFD discriminators.=C2=A0 If the located ses= sion is an
=C2=A0 =C2=A0SBFDInitiator, then the destination IP address of the packet S= HOULD
=C2=A0 =C2=A0be validated to be for self.=C2=A0 If the packet is a classica= l BFD
=C2=A0 =C2=A0session, then the procedures from [RFC5880] apply.

NEW:
=C2=A0 =C2=A0If the port is not 7784, but the packet is demultiplexed to be= for an
=C2=A0 =C2=A0SBFDInitiator, then the packet MUST be looked up to locate
=C2=A0 =C2=A0a corresponding SBFDInitiator session based
=C2=A0 =C2=A0on the value from the "your discriminato= r" field in the table
=C2=A0 =C2=A0describing BFD discriminators.=C2=A0 In that case,
=C2=A0 =C2=A0then the destination IP address of the packet SHOULD
=C2=A0 =C2=A0be validated to be for itself.=C2=A0 If the packet demultiplex= es to a classical BFD
=C2=A0 =C2=A0session, then the procedures from [RFC5880] apply.

Would that work?

Sure - sounds good.=C2= =A0 Thanks,
Alia=C2=A0
=C2=A0
Thanks,

=E2=80=94 Carlos.

>
>
>


--089e0149cdc48a040c0531f2a10e-- From nobody Tue May 3 09:40:58 2016 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 2D4CE12DA95 for ; Tue, 3 May 2016 09:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 Zhg_Z8ofLTqZ for ; Tue, 3 May 2016 09:40:50 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 322C712DB1B for ; Tue, 3 May 2016 09:38:03 -0700 (PDT) Received: (qmail 31975 invoked from network); 3 May 2016 18:31:19 +0200 Received: from p5dec2476.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.36.118) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 3 May 2016 18:31:19 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-b?= =?utf-8?Q?fd-seamless-base-09=3A_=28with_DISCUSS=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Tue, 3 May 2016 18:31:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1EB9BDDB-483F-48BC-9D2F-D68E6ACA285E@kuehlewind.net> References: <20160503093512.7446.68991.idtracker@ietfa.amsl.com> To: "Carlos Pignataro (cpignata)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 16:40:53 -0000 Hi Carlos, > Am 03.05.2016 um 15:40 schrieb Carlos Pignataro (cpignata) = : >=20 > Hi, Mirja, >=20 > What is an uncontrolled packet in an IP network, and what entity = controls controlled ones? :-) Questions over questions=E2=80=A6 :-) See below... >=20 > More seriously, please see inline. >=20 >> On May 3, 2016, at 5:35 AM, Mirja Kuehlewind = wrote: >>=20 >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-bfd-seamless-base-09: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> As S-BFD has no initiation process anymore it is not guarenteed that = the >> receiver/responder actually exists. That means that packets could = float >> (uncontrolled) in the network or even outside of the adminstrative = domain >> (e.g. due to configuration mistakes). =46rom my point of view this = document >> should recommend/require two things: >>=20 >=20 > We have called out the misconfiguration =E2=80=94 however: >=20 >> 1) A maximum number of S-BFD packet that is allow to be send without >> getting a response (maybe leading to a local error report). >>=20 >=20 > This can result in a deadlock situation, if an S-BFD Reflector is = enabled much later. I=E2=80=99m very hesitant to cap the packets sent. = We can, and I think it is useful, MAY log an error for multiple = timeouts. Okay, I understand that a hard limit probably does make sense. An error = log seems definitely useful. Another proposal for consideration: = Currently the draft says an initiator should only send one packet per = second if the target is in ADMINDOWN state. In this case there this = state is explicit announced. However if the other end just disappears or = was never/not yet there, one could use an exponential back off instead, = starting with a smaller intervals than one second but then increase it = exponentially. Just an idea...=20 >=20 >> 2) Egress filtering at the adminstrative border of the domain that = uses >> S-BFD to make sure that no S-BFD packets leave the domain. >>=20 >=20 > This is no different than any other application that uses UDP; a = misconfigured DNS server will result in the same, and a traceroute is = also not too different. This seems too onerous of a requirement. An = administrative domain filters at ingress. First of all, just because other protocols might have such a problem, = that does mean it=E2=80=99s okay. However, correctly me if I=E2=80=99m = wrong, but there the situation seems slightly different because there is = no termination criterium at all that means an s-bfd node would send = useless data forever (=E2=80=A6 until manual change of the config). I still believe that egress filtering would be more appropriate here = (than ingress) because the domain that is using s-bfd knows about it and = therefor can set up the respective filters and should not spam others = while hoping that filters are in place. >=20 > Seems to me the logging will alert someone/something to take action, = and should be enough. Logging plus alerts is definitely a good thing. Mirja >=20 > Thoughts? >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >>=20 >>=20 >>=20 >=20 From nobody Tue May 3 09:55:37 2016 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 4D2A612D9E2; Tue, 3 May 2016 09:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 L5dZdZ7iztwF; Tue, 3 May 2016 09:13:17 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A18E12DA09; Tue, 3 May 2016 09:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45589; q=dns/txt; s=iport; t=1462291995; x=1463501595; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hdYwSzJRZGiuBrPb7UksPY1n4zLg1Ntp7L4a/h/sX08=; b=TWBjyMKinMg7FeGlx/87CYIiF7apCxXm3i8Uc2EtlUSLUg43PVpuwIyt /Vj0kBlGY4dDZ8k0RYbQB3MbVGttOyRKsK2MSDvGAtbC89j1Khzsd0CMR iI6A7zGIBRXEQR5v8v+1d6a4r8ktpf/kq0r6/Sli0knyviVwhGOmNzutZ g=; X-Files: draft-ietf-bfd-seamless-base-alia-diff.txt, signature.asc : 11039, 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCAgC7zChX/5ldJa1VCoM4U30GriqLY?= =?us-ascii?q?g6BdSKFbgKBPTgUAQEBAQEBAWUnhEEBAQEDARoBCFYFCwIBCA4KIAcDAgIhERQ?= =?us-ascii?q?RAgQOBQ4Nh3oDCggOq0yMRQ2EOwEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0IhiCBd?= =?us-ascii?q?giBTIEDgkOBTgYLAYMcK4IuBYd4iyyDZF0xAYMngWdthiWBd4FohE2DKYU0h1G?= =?us-ascii?q?HYAEeAUOCNoE1bAGGfQkXBBt/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,573,1454976000"; d="asc'?txt'?scan'208,217";a="269053757" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2016 16:13:12 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u43GDCvu032288 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 16:13:12 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 12:13:11 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 3 May 2016 12:13:11 -0400 From: "Carlos Pignataro (cpignata)" To: Alia Atlas Subject: Re: Alia Atlas' Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS and COMMENT) Thread-Topic: Alia Atlas' Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS and COMMENT) Thread-Index: AQHRpLkIQl1ke+WjZEO22I9fWz1zPp+mfzmAgAERloCAABYsAA== Date: Tue, 3 May 2016 16:13:11 +0000 Message-ID: <059ECD31-C883-4721-8FA1-3FCEE9FCE1AC@cisco.com> References: <20160502212434.15622.98408.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.48.199] Content-Type: multipart/signed; boundary="Apple-Mail=_31096B15-F84E-4396-939B-5F178DD052E3"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 03 May 2016 09:55:36 -0700 Cc: The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 16:13:25 -0000 --Apple-Mail=_31096B15-F84E-4396-939B-5F178DD052E3 Content-Type: multipart/alternative; boundary="Apple-Mail=_BB73336B-4A99-4A6C-ADB8-AAE1FED5B005" --Apple-Mail=_BB73336B-4A99-4A6C-ADB8-AAE1FED5B005 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Alia, Thanks for the response! We are on the exact same page regarding items #1 and #2. For item #3, we really want to modularize the specs and not tie the = -base to the transports. Note that we mention =E2=80=9CUDP=E2=80=9D but = also =E2=80=9Cassociated channel type=E2=80=9D. For #3, here=E2=80=99s the change I implemented: S-BFD packet MUST be demultiplexed with lower layer information - (e.g., dedicated destination UDP port, associated channel type). - Following procedure SHOULD be executed on both initiator and - reflector. + (e.g., dedicated destination UDP port [I-D.ietf-bfd-seamless-ip], + associated channel type [I-D.ietf-pals-seamless-vccv]). Following + procedure SHOULD be executed on both initiator and reflector. And please find attached full diffs addressing all the Discuss points. Thanks! =E2=80=94 Carlos. > On May 3, 2016, at 10:53 AM, Alia Atlas wrote: >=20 > Hi Carlos, >=20 > On Mon, May 2, 2016 at 6:34 PM, Carlos Pignataro (cpignata) = > wrote: > Hi, Alia, >=20 > Thanks for your review and for bringing up these issues =E2=80=94 = please see inline. >=20 > > On May 2, 2016, at 5:24 PM, Alia Atlas > wrote: > > > > Alia Atlas has entered the following ballot position for > > draft-ietf-bfd-seamless-base-09: Discuss > > > > When responding, please keep the subject line intact and reply to = all > > email addresses included in the To and CC lines. (Feel free to cut = this > > introductory paragraph, however.) > > > > > > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ = > > > > > > > > = ---------------------------------------------------------------------- > > DISCUSS: > > = ---------------------------------------------------------------------- > > > > a) In Sec 7.2.3: "If the SBFDReflector is generating a response = S-BFD > > control packet for a local entity that is in > > service, then "state" in response BFD control packets MUST be = set > > to UP." > > So far, it looked like the SBFDReflector only sends BFD control > > packets in response to receiving such packets > > from SBFDInitiators. This paragraph (not just copied) does not > > clearly describe the desired behavior. If the > > monitored local entity is "temporarily out of service", does the > > SBFDReflector respond back to the SBFDInitiator > > with 2 BFD control packets - one indicating UP (as a MUST) and = then > > the next indicating ADMINDOWN? Is the > > SBFDReflector expected to store a list of active SBFDInitiators = and > > proactively send BFD control packets indicating > > ADMINDOWN? Please clarify in non-trivial detail. >=20 > The way in which that particular bullet in that subsection is written = can be a bit confusing. >=20 > First, you are right that the SBFDReflector only sends packets in = response to S-BFD control packets from the SBFDInitiators. This is = clearly spelled out in Section 5, and in other places that explain how = the reflector is stateless. >=20 > The SBFDReflector only response and does not stores a list of = SBFDInitiators to proactively send S-BFD packets (see Section 5). = Further, it does not respond with two packets. (UP and ADMINDOWN). >=20 > I think this can be rewritten to better explain what happens, as = follows: >=20 > OLD: > o If the SBFDReflector wishes to communicate to some or all > SBFDInitiators that monitored local entity is "temporarily out = of > service", then S-BFD control packets with "state" set to = ADMINDOWN > are sent to those SBFDInitiators. The SBFDInitiators, upon > reception of such packets, MUST NOT conclude loss of = reachability > to corresponding remote entity, and MUST back off packet > transmission interval for the remote entity to an interval no > faster than 1 second. If the SBFDReflector is generating a > response S-BFD control packet for a local entity that is in > service, then "state" in response BFD control packets MUST be = set > to UP. >=20 > NEW: > o If the SBFDReflector, upon receiving an S-BFD control packet = from > an SBFDInitiators, wishes to communicate to those > SBFDInitiators that a monitored local entity is "temporarily out = of > service", then an S-BFD control packet with "state" set to = ADMINDOWN > is sent in response to those SBFDInitiators. The = SBFDInitiators, upon > reception of such packets, MUST NOT conclude loss of = reachability > to corresponding remote entity, and MUST back off packet > transmission interval for the remote entity to an interval no > faster than 1 second. If, on the other hand, the SBFDReflector = is generating a > response S-BFD control packet for a local entity that is in > service, then "state" in response BFD control packets MUST be = set > to UP. >=20 > Is that more clear? >=20 > Slightly - but what about: >=20 > "When the SBFDReflector receives an S-BFD control packet from an = SBFDInitiator, > then the SBFDReflector needs to determine what state to send in the = response S-BFD > control packet. If the monitored local entity is in service, then the = "state" MUST be > set to UP. However, if the monitored local entity is "temporarily out = of service" for > rapidly processing S-BFD packets, for instance due to an overload, = then the "state" > SHOULD be set to ADMINDOWN. The SBFDReflector SHOULD send a response > S-BFD control packet. >=20 > When an SBFDInitiator receives a response S-BFD control packet, if the = state specified > is ADMINDOWN, the SBFDInitiator MUST NOT conclude loss of = reachability > to corresponding remote entity, and MUST back off packet transmission = interval for the > remote entity to an interval no faster than 1 second. " >=20 > Either wording or a mixture is just fine. >=20 > > > > b) Appendix A: The looping problem is nicely defined but the text = still > > discusses three potential solutions; clearly the > > use of the D bit has been chosen. It would be much nicer to have = the > > justification in line, but for this discuss - the > > unselected alternatives don't belong. > > >=20 > Sorry I=E2=80=99m not sure I understand fully your point. Are you = suggesting we mention in the actual reason for the D-bit procedures = outside the Appendix (although the procedures for the D bit are = explained in Section 6.2, 7.2.2, 7.2.3, 7.3.2, and 7.2.2), while still = leave the Appendix as-is? >=20 > If so we can do that, but want to confirm. >=20 > I'm suggesting that you mention the reason for the D-bit procedures = outside the Appendix and remove the Appendix. Alternately, keep the = Appendix but remove discussion of the other ways the problem could have = been solved and add a reference from the D-bit procedures to the = Appendix. >=20 > Once this is an RFC, it doesn't matter what the other possible and = unselected design choices were. >=20 > > c) Sec 7.2.1: " S-BFD packet MUST be demultiplexed with lower = layer > > information > > (e.g., dedicated destination UDP port, associated channel type)." > > Where precisely is this defined or described? Is there an = allocation > > for a dedicated UDP > > port for S-BFD? I don't see any normative reference to such. In > > particular, since the format > > for an S-BFD control packet is exactly the same as for BFD and since = only > > this demultiplexing > > with lower layer information is used to tell the difference between = S-BFD > > and BFD packets, > > this document requires more specifics. > > >=20 > This is similar to RFC 5880 and RFC 5881. The actual S-BFD = applications specify this. For example, bfd-seamless-ip defines the UDP = port. We purposely do not want to have the specification (either = explicitly or normatively pointed to) from this document, as this is = just the base specification. >=20 > Why? Unlike RFC 5880, this document mentions UDP ports as an example = of a demultiplexer. > While I do understand that BFD can run with different transports, it = is useful to clearly articulate > one use transport that has enough information to be actually = implemented. In this case, that's > just a normative reference to another document progressing at the same = time. >=20 > I can't get too worked up about normative vs. informative references = in general - the guideline I > use is whether an implementor would need to read the reference to = properly implement the > functionality. >=20 > If you feel extremely strongly that the reference must be informative, = I'm not going to dig in my > heels - but PLEASE put a reference by the mention of the UDP port. >=20 >=20 > > > > = ---------------------------------------------------------------------- > > COMMENT: > > = ---------------------------------------------------------------------- > > > > 1) In the last paragraph of Sec 4.2: " Even when following the = separate > > discriminator pool approach, > > collision is still possible between one S-BFD application to = another > > S-BFD application, that may be using different values and = algorithms > > to derive S-BFD discriminator values. If the two applications are > > using S-BFD for a same purpose (e.g., network reachability), then = the > > colliding S-BFD discriminator value can be shared. If the two > > applications are using S-BFD for a different purpose, then the > > collision must be addressed. How such collisions are addressed is > > outside the scope of this document." > > > > Sec 4.1 talks about the need for the S-BFD Discriminator to be = unique > > within an Administrative Domain. > > I don't see any details of that addressed here. What is addressed > > here seems to be the case for multiple > > S-BFD discriminators applying to the same node - which is = specifically > > discouraged at the end of Sec 3. > > Rather than simply describing the issue as "outside the scope of = this > > document", please either describe it > > as "future work and multiple S-BFD discriminators is discouraged" = or > > add a reference. > > >=20 > Good point, will do. >=20 > > 2) In Sec 6.1: "bfd.SessionType:" is defined but the only possible = values > > are for SBFD. Is it possible for a BFD > > session to still use the same bfd structure? I don't see a value = for > > SessionType there; I'd expect to see at least > > a value for the original BFD session and possible an undefined or > > unspecified value for future proofing. > > > > >=20 > Traditional BFD does not use this state variable. That=E2=80=99s why = we don=E2=80=99t need to define a value for BFD. However, future specs = can when it is relevant (e.g, using BFD for various types as opposed to = S-BFD), as for example bfd-multipoint. >=20 > Right - I understand that. I'm thinking a bit from the implementation = perspective. If I have the same data-structures and similar logic for = BFD and S-BFD, then there'll be a bfd.SessionType even for BFD sessions = that don't need it. Clarifying a value of "Unused" or "Classical BFD" = gives clarity that one > of the S-BFD options doesn't need to be chosen. >=20 > This is just a comment. It's up to your best judgement. >=20 > Thanks, > Alia >=20 >=20 > Please let us know your thoughts on the responses above, and we can = send out diffs. >=20 > Thanks! >=20 > =E2=80=94 Carlos. >=20 >=20 >=20 --Apple-Mail=_BB73336B-4A99-4A6C-ADB8-AAE1FED5B005 Content-Type: multipart/mixed; boundary="Apple-Mail=_0B02F5DA-E1D2-4B7C-8D58-CEEB677F8140" --Apple-Mail=_0B02F5DA-E1D2-4B7C-8D58-CEEB677F8140 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Alia,

Thanks for the response!

We are on the exact same page regarding = items #1 and #2.

For item #3, we really want to modularize the specs and not = tie the -base to the transports. Note that we mention =E2=80=9CUDP=E2=80=9D= but also =E2=80=9Cassociated channel type=E2=80=9D.

For #3, here=E2=80=99s = the change I implemented:

    S-BFD packet MUST be demultiplexed with lower = layer information
-   (e.g., dedicated destination = UDP port, associated channel type).
-   Following = procedure SHOULD be executed on both initiator and
- =   reflector.
+   (e.g., dedicated destination = UDP port [I-D.ietf-bfd-seamless-ip],
+   associated = channel type [I-D.ietf-pals-seamless-vccv]).  Following
+   procedure SHOULD be executed on both initiator and = reflector.

And please = find attached full diffs addressing all the Discuss points.

Thanks!

=E2=80=94 = Carlos.

= --Apple-Mail=_0B02F5DA-E1D2-4B7C-8D58-CEEB677F8140 Content-Disposition: attachment; filename=draft-ietf-bfd-seamless-base-alia-diff.txt Content-Type: text/plain; name="draft-ietf-bfd-seamless-base-alia-diff.txt" Content-Transfer-Encoding: quoted-printable Index: draft-ietf-bfd-seamless-base-10.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- draft-ietf-bfd-seamless-base-10.txt (revision 3541) +++ draft-ietf-bfd-seamless-base-10.txt (working copy) @@ -92,7 +92,7 @@ 7.2.2. Transmission of S-BFD Control Packet by SBFDReflector = 10 7.2.3. Additional SBFDReflector Behaviors . . . . . . . . . = 11 7.3. Initiator Procedures . . . . . . . . . . . . . . . . . . = 12 - 7.3.1. SBFDInitiator State Machine . . . . . . . . . . . . . = 13 + 7.3.1. SBFDInitiator State Machine . . . . . . . . . . . . . = 12 7.3.2. Transmission of S-BFD Control Packet by SBFDInitiator = 13 7.3.3. Additional SBFDInitiator Behaviors . . . . . . . . . = 14 7.4. Diagnostic Values . . . . . . . . . . . . . . . . . . . . = 14 @@ -117,7 +117,7 @@ 15. References . . . . . . . . . . . . . . . . . . . . . . . . . = 18 15.1. Normative References . . . . . . . . . . . . . . . . . . = 18 15.2. Informative References . . . . . . . . . . . . . . . . . = 18 - Appendix A. Loop Problem . . . . . . . . . . . . . . . . . . . . = 19 + Appendix A. Loop Problem and Solution . . . . . . . . . . . . . = 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . = 20 =20 1. Introduction @@ -457,7 +457,7 @@ =20 o bfd.DemandMode: This variable MUST be initialized to 1 for = session type SBFDInitiator, and MUST be initialized to 0 for session type - SBFDReflector. + SBFDReflector. This is done to prevent loops (see Appendix A). =20 7. S-BFD Procedures =20 @@ -464,9 +464,9 @@ 7.1. Demultiplexing of S-BFD Control Packet =20 S-BFD packet MUST be demultiplexed with lower layer information - (e.g., dedicated destination UDP port, associated channel type). - Following procedure SHOULD be executed on both initiator and - reflector. + (e.g., dedicated destination UDP port [I-D.ietf-bfd-seamless-ip], + associated channel type [I-D.ietf-pals-seamless-vccv]). Following + procedure SHOULD be executed on both initiator and reflector. =20 If S-BFD packet =20 @@ -518,8 +518,7 @@ =20 7.2.1. Responder Demultiplexing =20 - S-BFD packet MUST be demultiplexed with lower layer information - (e.g., dedicated destination UDP port, associated channel type). + S-BFD packet MUST be demultiplexed with lower layer information. Following procedure SHOULD be executed by responder: =20 If "your discriminator" not one of the entry allocated for local @@ -552,7 +551,8 @@ =20 Demand (D) =20 - Set to 0. + Set to 0, to identify the S-BFD packet is sent by the + SBFDReflector. =20 =20 =20 @@ -618,20 +618,15 @@ Internet-Draft Seamless BFD Base May = 2016 =20 =20 - o If the SBFDReflector wishes to communicate to some or all - SBFDInitiators that monitored local entity is "temporarily out of - service", then S-BFD control packets with "state" set to = ADMINDOWN - are sent to those SBFDInitiators. The SBFDInitiators, upon - reception of such packets, MUST NOT conclude loss of reachability - to corresponding remote entity, and MUST back off packet - transmission interval for the remote entity to an interval no - faster than 1 second. If the SBFDReflector is generating a - response S-BFD control packet for a local entity that is in - service, then "state" in response BFD control packets MUST be set - to UP. + o When the SBFDReflector receives an S-BFD control packet from an + SBFDInitiator, then the SBFDReflector needs to determine what + "state" to send in the response S-BFD control packet. If the + monitored local entity is in service, then the "state" MUST be = set + to UP. If the monitored local entity is "temporarily out of + service", then the "state" SHOULD be set to ADMINDOWN. =20 o If an SBFDReflector receives an S-BFD control packet with Demand - (D) bit cleared, the packet MUST be discarded. + (D) bit cleared, the packet MUST be discarded (see Appendix A). =20 7.3. Initiator Procedures =20 @@ -665,7 +660,12 @@ =20 Figure 3: S-BFD Continuity Test =20 +7.3.1. SBFDInitiator State Machine =20 + An SBFDInitiator may be a persistent session on the initiator with a + timer for S-BFD control packet transmissions (stateful + SBFDInitiator). An SBFDInitiator may also be a module, a script or = a + tool on the initiator that transmits one or more S-BFD control =20 =20 =20 @@ -674,12 +674,6 @@ Internet-Draft Seamless BFD Base May = 2016 =20 =20 -7.3.1. SBFDInitiator State Machine - - An SBFDInitiator may be a persistent session on the initiator with a - timer for S-BFD control packet transmissions (stateful - SBFDInitiator). An SBFDInitiator may also be a module, a script or = a - tool on the initiator that transmits one or more S-BFD control packets "when needed" (stateless SBFDInitiator). For stateless SBFDInitiators, a complete BFD state machine may not be applicable. For stateful SBFDInitiators, the states and the state machine @@ -722,20 +716,20 @@ D bit is used to identify S-BFD packet originated from SBFDInitiator and is always set to 1. =20 + Your Discriminator =20 + Set to bfd.RemoteDiscr. bfd.RemoteDiscr is set to = discriminator + value of remote entity. It MAY be learnt from routing + protocols or configured locally. =20 =20 + + Akiya, et al. Expires November 3, 2016 [Page = 13] =0C Internet-Draft Seamless BFD Base May = 2016 =20 =20 - Your Discriminator - - Set to bfd.RemoteDiscr. bfd.RemoteDiscr is set to = discriminator - value of remote entity. It MAY be learnt from routing - protocols or configured locally. - Required Min RX Interval =20 Set to 0. @@ -751,6 +745,12 @@ then the SBFDInitiator SHOULD conclude that S-BFD control packet reached the intended remote entity. =20 + o When an SBFDInitiator receives a response S-BFD control packet, = if + the state specified is ADMINDOWN, the SBFDInitiator MUST NOT + conclude loss of reachability to the corresponding remote entity, + and MUST back off packet transmission interval for the remote + entity to an interval no faster than 1 second. + o When a sufficient number of S-BFD packets have not arrived as = they should, the SBFDInitiator SHOULD declare loss of reachability to the remote entity. The criteria for declaring loss of @@ -766,7 +766,7 @@ responder back to initiator. =20 o If the SBFDInitiator receives an S-BFD control packet with Demand - (D) bit set, the packet MUST be discarded. + (D) bit set, the packet MUST be discarded (see Appendix A). =20 7.4. Diagnostic Values =20 @@ -1022,6 +1022,11 @@ Cases", draft-ietf-bfd-seamless-use-case-06 (work in progress), April 2016. =20 + [I-D.ietf-pals-seamless-vccv] + Govindan, V. and C. Pignataro, "Seamless BFD for VCCV", + draft-ietf-pals-seamless-vccv-03 (work in progress), = April + 2016. + [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . @@ -1035,7 +1040,7 @@ DOI 10.17487/RFC3031, January 2001, . =20 -Appendix A. Loop Problem +Appendix A. Loop Problem and Solution =20 Consider a scenario where we have two nodes and both are S-BFD capable. @@ -1053,11 +1058,6 @@ =20 Suppose MiM sends a spoofed packet with MyDisc =3D 0x01010101, = YourDisc =3D 0x02020202, source IP as 2001:db8::1 and dest IP as 2001:db8::2. - When this packet reaches Node B, the reflector session on Node B = will - swap the discriminators and IP addresses of the received packet and - reflect it back, since YourDisc of the received packet matched with - reserved discriminator of Node B. The reflected packet that reached - Node A will have MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. = Since =20 =20 =20 @@ -1066,6 +1066,11 @@ Internet-Draft Seamless BFD Base May = 2016 =20 =20 + When this packet reaches Node B, the reflector session on Node B = will + swap the discriminators and IP addresses of the received packet and + reflect it back, since YourDisc of the received packet matched with + reserved discriminator of Node B. The reflected packet that reached + Node A will have MyDdisc=3D0x02020202 and YourDisc=3D0x01010101. = Since YourDisc of the received packet matched the reserved discriminator = of Node A, Node A will swap the discriminators and reflects the packet back to Node B. Since reflectors must set the TTL of the reflected @@ -1072,31 +1077,11 @@ packets to 255, the above scenario will result in an infinite loop with just one malicious packet injected from MiM. =20 - FYI: Packet fields do not carry any direction information, i.e., if - this is Ping packet or reply packet. + The solution to avoid the loop problem uses the "D" bit (Demand mode + bit). The Initiator always sets the 'D' bit and the reflector = always + clears it. This way we can identify if a received packet was a + reflected packet and avoid reflecting it back. =20 - Solutions - - The current proposals to avoid the loop problem are: - - o Overload "D" bit (Demand mode bit): Initiator always sets the 'D' - bit and reflector clears it. This way we can identify if a - received packet was a reflected packet and avoid reflecting it - back. However this changes the interpretation of 'D' bit. - - o Use of State field in the BFD control packets: Initiator will - always send packets with State set to DOWN and reflector will = send - back packets with state field set to UP. Reflectors will never - reflect any received packets with state as UP. However the only - issue is the use of state field differently i.e., state in the - S-BFD control packet from initiator does not reflect the local - state which is anyway not significant at reflector. - - o Use of local discriminator as My Disc at reflector: Reflector = will - always fill in My Discriminator with a locally allocated - discriminator value (not reserved discriminators) and will not - copy it from the received packet. - Authors' Addresses =20 Nobo Akiya @@ -1111,17 +1096,6 @@ Email: cpignata@cisco.com =20 =20 - - - - - - -Akiya, et al. Expires November 3, 2016 [Page = 20] -=0C -Internet-Draft Seamless BFD Base May = 2016 - - Dave Ward Cisco Systems, Inc. =20 @@ -1143,34 +1117,4 @@ =20 =20 =20 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Akiya, et al. Expires November 3, 2016 [Page = 21] +Akiya, et al. Expires November 3, 2016 [Page = 20] --Apple-Mail=_0B02F5DA-E1D2-4B7C-8D58-CEEB677F8140 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On = May 3, 2016, at 10:53 AM, Alia Atlas <akatlas@gmail.com> = wrote:

Hi Carlos,

On Mon, = May 2, 2016 at 6:34 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hi, Alia,

Thanks for your review and for bringing up these issues =E2=80=94 please = see inline.

> On May 2, 2016, at 5:24 PM, Alia Atlas <akatlas@gmail.com> = wrote:
>
> Alia Atlas has entered the following ballot position for
> draft-ietf-bfd-seamless-base-09: Discuss
>
> When responding, please keep the subject line intact and reply to = all
> email addresses included in the To and CC lines. (Feel free to cut = this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found = here:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/<= /a>
>
>
>
> = ----------------------------------------------------------------------
> DISCUSS:
> = ----------------------------------------------------------------------
>
> a) In Sec 7.2.3:  "If the SBFDReflector is generating a = response S-BFD
> control packet for a local entity that is in
>      service, then "state" in response BFD control = packets MUST be set
> to UP."
>    So far, it looked like the SBFDReflector only sends = BFD control
> packets in response to receiving such packets
>    from SBFDInitiators.   This paragraph (not = just copied) does not
> clearly describe the desired behavior.  If the
>   monitored local entity is "temporarily out of service", = does the
> SBFDReflector respond back to the SBFDInitiator
>   with 2 BFD control packets - one indicating UP (as a = MUST) and then
> the next indicating ADMINDOWN?  Is the
>   SBFDReflector expected to store a list of active = SBFDInitiators and
> proactively send BFD control packets indicating
>   ADMINDOWN?   Please clarify in non-trivial = detail.

The way in which that particular bullet in that subsection = is written can be a bit confusing.

First, you are right that the SBFDReflector only sends packets in = response to S-BFD control packets from the SBFDInitiators. This is = clearly spelled out in Section 5, and in other places that explain how = the reflector is stateless.

The SBFDReflector only response and does not stores a list of = SBFDInitiators to proactively send S-BFD packets (see Section 5). = Further, it does not respond with two packets. (UP and ADMINDOWN).

I think this can be rewritten to better explain what happens, as = follows:

OLD:
   o  If the SBFDReflector wishes to communicate to some = or all
      SBFDInitiators that monitored local entity is = "temporarily out of
      service", then S-BFD control packets with "state" = set to ADMINDOWN
      are sent to those SBFDInitiators.  The = SBFDInitiators, upon
      reception of such packets, MUST NOT conclude loss = of reachability
      to corresponding remote entity, and MUST back off = packet
      transmission interval for the remote entity to an = interval no
      faster than 1 second.  If the SBFDReflector is = generating a
      response S-BFD control packet for = a local entity that is in
      service, then "state" in response BFD control = packets MUST be set
      to UP.

NEW:
   o  If the SBFDReflector, upon receiving an S-BFD = control packet from
      an SBFDInitiators, wishes to communicate to = those
      SBFDInitiators that a monitored local entity is = "temporarily out of
      service", then an S-BFD control packet with "state" = set to ADMINDOWN
      is sent in response to those SBFDInitiators.  = The SBFDInitiators, upon
      reception of such packets, MUST NOT conclude loss = of reachability
      to corresponding remote entity, and MUST back off = packet
      transmission interval for the remote entity to an = interval no
      faster than 1 second.  If, on the other hand, = the SBFDReflector is generating a
      response S-BFD control packet for = a local entity that is in
      service, then "state" in response BFD control = packets MUST be set
      to UP.

Is that more clear?

Slightly - but what about:

"When the SBFDReflector = receives an S-BFD control packet from an SBFDInitiator,
then the SBFDReflector needs to determine what state to send = in the response S-BFD
control packet.  If the = monitored local entity is in service, then the "state" MUST be
set to UP.  However, if the monitored local entity is = "temporarily out of service" for
rapidly processing = S-BFD packets, for instance due to an overload, then the = "state" 
SHOULD be set to ADMINDOWN.  The = SBFDReflector SHOULD send a response
S-BFD control = packet.  

When an SBFDInitiator receives a response S-BFD control = packet, if the state specified
is ADMINDOWN, the = SBFDInitiator MUST NOT conclude loss of  reachability
to = corresponding remote entity, and MUST back off packet transmission = interval for the 
remote entity to = an interval no faster than 1 second. "

Either wording or a mixture is just fine. =   

>
> b) Appendix A:  The looping problem is nicely defined but the = text still
> discusses three potential solutions; clearly the
> use of the D bit has been chosen.   It would be much = nicer to have the
> justification in line, but for this discuss - the
> unselected alternatives don't belong.
>

Sorry I=E2=80=99m not sure I understand fully your point. Are you = suggesting we mention in the actual reason for the D-bit procedures = outside the Appendix (although the procedures for the D bit are = explained in Section 6.2, 7.2.2, 7.2.3, 7.3.2, and 7.2.2), while still = leave the Appendix as-is?

If so we can do that, but want to confirm.

I'm suggesting that you = mention the reason for the D-bit procedures outside the Appendix and = remove the Appendix.  Alternately, keep the Appendix but remove = discussion of the other ways the problem could have been solved and add = a reference from the D-bit procedures to the Appendix.
 
Once this is an RFC, it doesn't = matter what the other possible and unselected design choices = were.

> c) Sec 7.2.1: "   S-BFD packet MUST be demultiplexed with = lower layer
> information
>   (e.g., dedicated destination UDP port, associated = channel type)."
>  Where precisely is this defined or described?  Is there = an allocation
> for a dedicated UDP
> port for S-BFD?  I don't see any normative reference to = such.  In
> particular, since the format
> for an S-BFD control packet is exactly the same as for BFD and = since only
> this demultiplexing
> with lower layer information is used to tell the difference between = S-BFD
> and BFD packets,
> this document requires more specifics.
>

This is similar to RFC 5880 and RFC 5881. The actual S-BFD = applications specify this. For example, bfd-seamless-ip defines the UDP = port. We purposely do not want to have the specification (either = explicitly or normatively pointed to) from this document, as this is = just the base specification.

Why?  Unlike RFC = 5880, this document mentions UDP ports as an example of a = demultiplexer.
While I do understand that BFD can = run with different transports, it is useful to clearly = articulate
one use transport that has enough = information to be actually implemented.   In this case, = that's
just a normative reference to another = document progressing at the same time.

I can't get too worked up about = normative vs. informative references in general - the guideline = I
use is whether an implementor would need to read = the reference to properly implement the
functionality.

If you feel extremely strongly that the reference must be = informative, I'm not going to dig in my
heels - but = PLEASE put a reference by the mention of the UDP port.
 
 
>
> = ----------------------------------------------------------------------
> COMMENT:
> = ----------------------------------------------------------------------
>
> 1) In the last paragraph of Sec 4.2: "  Even when following = the separate
> discriminator pool approach,
>   collision is still possible between one S-BFD = application to another
>   S-BFD application, that may be using different values = and algorithms
>   to derive S-BFD discriminator values.  If the two = applications are
>   using S-BFD for a same purpose (e.g., network = reachability), then the
>   colliding S-BFD discriminator value can be = shared.  If the two
>   applications are using S-BFD for a different purpose, = then the
>   collision must be addressed.  How such collisions = are addressed is
>   outside the scope of this document."
>
>  Sec 4.1 talks about the need for the S-BFD Discriminator to = be unique
> within an Administrative Domain.
>  I don't see any details of that addressed here.  =  What is addressed
> here seems to be the case for multiple
>  S-BFD discriminators applying to the same node - which is = specifically
> discouraged at the end of Sec 3.
>  Rather than simply describing the issue as "outside the scope = of this
> document", please either describe it
>  as "future work and multiple S-BFD discriminators is = discouraged" or
> add a reference.
>

Good point, will do.

> 2) In Sec 6.1: "bfd.SessionType:" is defined but the only possible = values
> are for SBFD.   Is it possible for a BFD
> session to still use the same bfd structure?  I don't see a = value for
> SessionType there; I'd expect to see at least
> a value for the original BFD session and possible an undefined = or
> unspecified value for future proofing.
>
>

Traditional BFD does not use this state variable. That=E2=80=99s = why we don=E2=80=99t need to define a value for BFD. However, future = specs can when it is relevant (e.g, using BFD for various types as = opposed to S-BFD), as for example bfd-multipoint.

Right - I understand that.  I'm thinking a bit from the = implementation perspective.  If I have the same data-structures and = similar logic for BFD and S-BFD, then there'll be a bfd.SessionType even = for BFD sessions that don't need it.  Clarifying a value of = "Unused" or "Classical BFD" gives clarity that one 
of the S-BFD options doesn't need to be chosen.

This is just a = comment.  It's up to your best judgement.

Thanks,
Alia 


Please let us know your thoughts on the responses above, and we can send = out diffs.

Thanks!

=E2=80=94 Carlos.




= --Apple-Mail=_0B02F5DA-E1D2-4B7C-8D58-CEEB677F8140-- --Apple-Mail=_BB73336B-4A99-4A6C-ADB8-AAE1FED5B005-- --Apple-Mail=_31096B15-F84E-4396-939B-5F178DD052E3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXKM4WAAoJEIXgpQGOZny9B2gP/3XZxed7sjXr4x9vUKLPnWJ8 dakQ7rVrchTJPceji0CBOQVimp26RjuSWFzwK43UBUPDDG/wFnOaEJ1T73WvCjVF mFuwwwM7D+S+d4HJAJlNRWX/X+gSlMsfGRC4wYCpEQiU7aKZWqEhx3JXGwBFQrx0 wWZRONS22iP/qkfx8+LHzHsY4SMvdvyhkJ0wb8k/iWd6ayymjaNWgZ6TNwqtgmfD kn40YL9R2iOzWOL6bRl9e+JcpTpYbS23gLUlRyQ7MTh0KnXPVuiHPu+6F9hEzfNU OYbMKCPNMklWz0ezf1Tw/L6LXAtydEq6wIc4FuYNojG/GKWTs8rVITGxXlg/Up+V fGhSCB0fE4PQ744mOx1XRhVSojRlQkCnaiI/O3zIl16c0VEAW+cVwSkEb6/4N9O7 TT6zNDWvlnaqdZkhjpR92VVK/0iGMTlyFrIlJONLLefM3fxXyQJnaa5xCYnVhnCW 39x+VwKrOBaPYZ/cRz9+UpRI6kbuY7zaj84yYAsaK1Bq92UMRVP+XkPRhpJsIrgw 8Pr4tsdjLV4HGQB3POirWf6Mjk0RfrsAPNHOaU5AYcpe420LdCsNmSl36XhiFjH5 ZouvtTBGEQxoG4y5rMtxEpnsAg3lK5EBqZ0i0/PFkwVgD40rv/t7pDXXkgiiWwLL tlL4KHNDGyH1dY9kZpKy =RRNK -----END PGP SIGNATURE----- --Apple-Mail=_31096B15-F84E-4396-939B-5F178DD052E3-- From nobody Tue May 3 09:57:24 2016 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 5B46012DBF9; Tue, 3 May 2016 09:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Bmj6gE_GvlRZ; Tue, 3 May 2016 09:57:13 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A612612DBF8; Tue, 3 May 2016 09:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20339; q=dns/txt; s=iport; t=1462294409; x=1463504009; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jgXZMttCGtrShm3yWZg2sBhFErhmqmp3VfdSAoT+8S4=; b=MqN62NYq2xKJy6Zf1iBl6m+yXlGl07KoGsgF65q63FoUQqufXD7RYO/l ZlSTaJD/bK2eStgitdP1ZZ4cbW1x18x5Sl+smddNREjWpMq3cf6AL1DVo h+BswGLlq26NZ2zl1o8Y1gm/c77tINoi1f9WJNlbsvXE46xJ7de6zjlTH I=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMAgCS1ihX/4kNJK1VCoM4U30Gri+Gb?= =?us-ascii?q?4Jkgg8OgXUihW4CgT04FAEBAQEBAQFlJ4RBAQEBAwEjVgULAgEIDgonAwICIRE?= =?us-ascii?q?UEQIEDgUOiAcDCggOq1aMQw2EOwEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0EBIYgg?= =?us-ascii?q?XaCV4JDgU4GCwGDHCuCLgWHeI9tMQGDJ4FnbYYlgXeBaIRNgymFNIdRh2ABHgF?= =?us-ascii?q?Dg2tsAYZ/BxcHGH8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,573,1454976000"; d="asc'?scan'208,217";a="267284404" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 May 2016 16:53:28 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u43GrSEh025391 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 16:53:28 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 12:53:27 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 3 May 2016 12:53:27 -0400 From: "Carlos Pignataro (cpignata)" To: Alia Atlas Subject: Re: Alia Atlas' Discuss on draft-ietf-bfd-seamless-ip-04: (with DISCUSS) Thread-Topic: Alia Atlas' Discuss on draft-ietf-bfd-seamless-ip-04: (with DISCUSS) Thread-Index: AQHRpMGsMRcZflh1j0ieWahk11MJYJ+mjIiAgAEfS4CAAAZYgA== Date: Tue, 3 May 2016 16:53:27 +0000 Message-ID: <81AD480B-36AE-432B-BAF8-22BA10152573@cisco.com> References: <20160502222627.15846.1446.idtracker@ietfa.amsl.com> <52C94004-5548-4701-AA81-EBF8D5EC1BDD@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.48.199] Content-Type: multipart/signed; boundary="Apple-Mail=_6BCD97C5-7AD5-4718-9613-3C1D463D3734"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" , "bfd-chairs@ietf.org" , The IESG , "draft-ietf-bfd-seamless-ip@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 16:57:17 -0000 --Apple-Mail=_6BCD97C5-7AD5-4718-9613-3C1D463D3734 Content-Type: multipart/alternative; boundary="Apple-Mail=_54EB6F15-D547-46BE-A517-1BBB07F6C1D4" --Apple-Mail=_54EB6F15-D547-46BE-A517-1BBB07F6C1D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Alia, Thanks, and sounds good. This is what we have implemented, which should = address both: @@ -122,9 +122,9 @@ The BFD Echo port defined by [RFC5881], port 3785, is used for the S-BFD Echo function on IPv4, IPv6 and MPLS environments. SBFDInitiator sessions MUST transmit S-BFD echo packets with - destination port 3785. This document defines only the UDP port = value - for the S-BFD Echo function. The source port and the procedures for - the S-BFD Echo function are outside the scope of this document. + destination port 3785. The setting of the UDP source port [RFC5881] + and the procedures [I-D.ietf-bfd-seamless-base] for the S-BFD Echo + function are outside the scope of this document. 4. S-BFD Control Packet Demultiplexing @@ -138,13 +138,13 @@ S-BFDReflector), then the packet MUST be looked up to locate a corresponding SBFDReflector session based on the value from the = "your discriminator" field in the table describing S-BFD discriminators. - If the port is not 7784, then the packet MUST be looked up to locate - a corresponding SBFDInitiator session or classical BFD session based - on the value from the "your discriminator" field in the table - describing BFD discriminators. If the located session is an - SBFDInitiator, then the destination IP address of the packet SHOULD - be validated to be for self. If the packet is a classical BFD - session, then the procedures from [RFC5880] apply. + If the port is not 7784, but the packet is demultiplexed to be for = an + SBFDInitiator, then the packet MUST be looked up to locate a + corresponding SBFDInitiator session based on the value from the = "your + discriminator" field in the table describing BFD discriminators. In + that case, then the destination IP address of the packet SHOULD be + validated to be for itself. If the packet demultiplexes to a + classical BFD session, then the procedures from [RFC5880] apply. 5. Initiator Procedures @@ -165,7 +165,7 @@ Thanks, =E2=80=94 Carlos. > On May 3, 2016, at 12:30 PM, Alia Atlas wrote: >=20 > Hi Carlos, >=20 > On Mon, May 2, 2016 at 7:22 PM, Carlos Pignataro (cpignata) = > wrote: > Hi Alia, >=20 > Thanks for the review and for these! Please see inline. >=20 > > On May 2, 2016, at 6:26 PM, Alia Atlas > wrote: > > > > Alia Atlas has entered the following ballot position for > > draft-ietf-bfd-seamless-ip-04: Discuss > > > > When responding, please keep the subject line intact and reply to = all > > email addresses included in the To and CC lines. (Feel free to cut = this > > introductory paragraph, however.) > > > > > > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ = > > > > > > > > = ---------------------------------------------------------------------- > > DISCUSS: > > = ---------------------------------------------------------------------- > > > > I think that these are both simple fast issues to resolve. > > > > 1) Sec 3: "This document defines only the UDP port value > > for the S-BFD Echo function. The source port and the procedures = for > > the S-BFD Echo function are outside the scope of this document." > > Please add a reference to the S-BFD base document for defining where = the > > procedures are found. > > > > Where, precisely, is the source port defined? It wasn't in the = S-BFD > > base > > document. This seems like a hole. Can you please clarify? >=20 > This is done exactly as in RFC 5881, purposefully. I can add a = clarifying sentence like: >=20 > OLD: > This document defines only the UDP port value > for the S-BFD Echo function. The source port and the procedures = for > the S-BFD Echo function are outside the scope of this document. >=20 > NEW: > S-BFD echo follows the BFD echo definitions of [RFC 5881]. > Consequently, this document defines only the UDP port value > for the S-BFD Echo function; the source port and the procedures for > the S-BFD Echo function are outside the scope of this document. >=20 > How about a reference by the source port to [RFC 5881] and a reference > for the procedures for the S-BFD Echo function = [draft-ietf-bfd-seamless-base]? >=20 > What wasn't clear to me - not having recently read RFC 5881 in detail = - was > that the UDP source port was defined in RFC 5881. I knew the = procedures were > in draft-ietf-bfd-seamless-base. >=20 > > > > 2) Sec 4: " If the port is not 7784, then the packet MUST be looked = up > > to locate > > a corresponding SBFDInitiator session or classical BFD session = based > > on the value from the "your discriminator" field in the table > > describing BFD discriminators. " > > > > I assume that you mean that UDP source port is used to look up the > > appropriate receiver. > > If that receiver handles BFD and S-BFD packets, then the "your > > discriminator" field is used > > to identify the BFD session. PLEASE clarify that because this = reads as > > if BFD is the only > > application that uses UDP. > > >=20 > Indeed, very much so. I suggest: >=20 > OLD: > If the port is not 7784, then the packet MUST be looked up to = locate > a corresponding SBFDInitiator session or classical BFD session = based > on the value from the "your discriminator" field in the table > describing BFD discriminators. If the located session is an > SBFDInitiator, then the destination IP address of the packet SHOULD > be validated to be for self. If the packet is a classical BFD > session, then the procedures from [RFC5880] apply. >=20 > NEW: > If the port is not 7784, but the packet is demultiplexed to be for = an > SBFDInitiator, then the packet MUST be looked up to locate > a corresponding SBFDInitiator session based > on the value from the "your discriminator" field in the table > describing BFD discriminators. In that case, > then the destination IP address of the packet SHOULD > be validated to be for itself. If the packet demultiplexes to a = classical BFD > session, then the procedures from [RFC5880] apply. >=20 > Would that work? >=20 > Sure - sounds good. Thanks, > Alia >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 > > > > > > >=20 >=20 --Apple-Mail=_54EB6F15-D547-46BE-A517-1BBB07F6C1D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Alia,

Thanks, and sounds good. This is what we have implemented, = which should address both:

@@ -122,9 +122,9 @@
    The BFD = Echo port defined by [RFC5881], port 3785, is used for the
    S-BFD Echo function on IPv4, IPv6 and MPLS = environments.
    SBFDInitiator sessions = MUST transmit S-BFD echo packets with
-   destination port 3785.  This = document defines only the UDP port value
-   for the S-BFD Echo = function.  The source port and the procedures for
-   the S-BFD Echo function are outside the = scope of this document.
+   destination = port 3785.  The setting of the UDP source port [RFC5881]
+   and the procedures = [I-D.ietf-bfd-seamless-base] for the S-BFD Echo
+   function are outside the scope of this = document.
 
 4.  S-BFD = Control Packet Demultiplexing
 
@@ = -138,13 +138,13 @@
    S-BFDReflector), = then the packet MUST be looked up to locate a
  =   corresponding SBFDReflector session based on the value from = the "your
    discriminator" field in the = table describing S-BFD discriminators.
-   If= the port is not 7784, then the packet MUST be looked up to locate
-   a corresponding SBFDInitiator session or = classical BFD session based
-   on the = value from the "your discriminator" field in the table
-   describing BFD = discriminators.  If the located session is an
-   SBFDInitiator, then the destination IP = address of the packet SHOULD
-   be = validated to be for self.  If the packet is a classical BFD
-   session, then the procedures from = [RFC5880] apply.
+   If the port is not = 7784, but the packet is demultiplexed to be for an
+   SBFDInitiator, then the packet MUST be = looked up to locate a
+   corresponding = SBFDInitiator session based on the value from the "your
+   discriminator" field in the table = describing BFD discriminators.  In
+   that case, then the destination IP address = of the packet SHOULD be
+   validated to be = for itself.  If the packet demultiplexes to a
+   classical BFD session, then the procedures = from [RFC5880] apply.
 
 5.  Initiator Procedures
 
@@ -165,7 +165,7 @@


Thanks,

=E2=80=94 Carlos.

On = May 3, 2016, at 12:30 PM, Alia Atlas <akatlas@gmail.com> = wrote:

Hi Carlos,

On Mon, = May 2, 2016 at 7:22 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hi Alia,

Thanks for the review and for these! Please see inline.

> On May 2, 2016, at 6:26 PM, Alia Atlas <akatlas@gmail.com> = wrote:
>
> Alia Atlas has entered the following ballot position for
> draft-ietf-bfd-seamless-ip-04: Discuss
>
> When responding, please keep the subject line intact and reply to = all
> email addresses included in the To and CC lines. (Feel free to cut = this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found = here:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/
>
>
>
> = ----------------------------------------------------------------------
> DISCUSS:
> = ----------------------------------------------------------------------
>
> I think that these are both simple fast issues to resolve.
>
> 1) Sec 3: "This document defines only the UDP port value
>   for the S-BFD Echo function.  The source port and = the procedures for
>   the S-BFD Echo function are outside the scope of this = document."
> Please add a reference to the S-BFD base document for defining = where the
> procedures are found.
>
> Where, precisely, is the source port defined?  It wasn't in = the S-BFD
> base
> document.  This seems like a hole.  Can you please = clarify?

This is done exactly as in RFC 5881, purposefully. I can add a = clarifying sentence like:

OLD:
   This document defines only the UDP port = value
   for the S-BFD Echo function.  The source port and the = procedures for
   the S-BFD Echo function are outside the scope of this = document.

NEW:
   S-BFD echo follows the BFD echo definitions of [RFC = 5881].
   Consequently, this document defines only the UDP port = value
   for the S-BFD Echo function; the source port and the = procedures for
   the S-BFD Echo function are outside the = scope of this document.

How about a reference by = the source port to [RFC 5881] and a reference
for = the procedures for the S-BFD Echo function = [draft-ietf-bfd-seamless-base]?

What wasn't clear to me - not having = recently read RFC 5881 in detail - was
that the UDP = source port was defined in RFC 5881.  I knew the procedures = were
in draft-ietf-bfd-seamless-base.
 
>
> 2) Sec 4:  " If the port is not 7784, = then the packet MUST be looked up
> to locate
>   a corresponding SBFDInitiator session or classical BFD = session based
>   on the value from the "your discriminator" field in the = table
>   describing BFD discriminators. "
>
> I assume that you mean that UDP source port is used to look up = the
> appropriate receiver.
> If that receiver handles BFD and S-BFD packets, then the "your
> discriminator" field is used
> to identify the BFD session.   PLEASE clarify that = because this reads as
> if BFD is the only
> application that uses UDP.
>

Indeed, very much so. I suggest:

OLD:
   If the port is not 7784, then the packet = MUST be looked up to locate
   a corresponding SBFDInitiator session or classical BFD = session based
   on the value from the "your discriminator" field in the = table
   describing BFD discriminators.  If the located = session is an
   SBFDInitiator, then the destination IP address of the = packet SHOULD
   be validated to be for self.  If the packet is a = classical BFD
   session, then the procedures from [RFC5880] apply.

NEW:
   If the port is not 7784, but the packet is demultiplexed to = be for an
   SBFDInitiator, then the packet MUST be looked up to = locate
   a corresponding SBFDInitiator session based
   on the value from the "your discriminator" = field in the table
   describing BFD discriminators.  In that = case,
   then the destination IP address of the packet SHOULD
   be validated to be for itself.  If the packet = demultiplexes to a classical BFD
   session, then the procedures from [RFC5880] apply.

Would that work?

Sure - sounds good.  = Thanks,
Alia 
 
Thanks,

=E2=80=94 Carlos.

>
>
>



= --Apple-Mail=_54EB6F15-D547-46BE-A517-1BBB07F6C1D4-- --Apple-Mail=_6BCD97C5-7AD5-4718-9613-3C1D463D3734 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXKNeHAAoJEIXgpQGOZny9BzUP/0V5rQuMl2xewkEWCp7UwgiR lq6LbU2IoaUhyO8rLuUkqd6PPT5AoF1dK1ZwlK8OU/Fo1hbmHS8s1kouxO5Q7VcP Gjm2AqT1DQXhNhV8XgByodZsD5CLw51c5teJwHIRux+x/DIz1WV/DCgvGT65J2Eh eB0iRPSXbFA/VgwUrK+WHcPbwW/2DG7kSEwEkatLtJBmgwK8iJVINkEe1yutJ7KS nyinDAfuhGAQlBwr9mFeTKDICEiTV+Wh/k3zXy1WNBXaJ7QLRVuYjasKIgu+/b9v Gb7ZTSk9hSgfsrMTk3UBuphc2QBmvqjihIPY7lA4Ks6jQv0wVy8/5kQUNIh+OuM4 ComvpHIPlbIpq1lT2aYyRAsJ4L5K3tMDK6vAZLvK39J2W6OaxoNDeIWPGro5my/O t0ajxeZgio4p9EP3JIODDsQ1TJR5Z4dF82xvzUu8LbRSjsvC5vbOsoxcEaVQPkGI nFpxhfIVqcJA6eBy9U/C114l7DsL7vZsSSjo45qJpkrldjXqq4tpiQ6W47b7ROch wRTVY+FpJuh4TzqQAPdf4evgIFtWCPzMrRWBloZ/jokG+IfB32MRUHicEbbp8zFL XnK1rCbpMiAAkC3Yt3p3SYXEgY7iWs9sbYv3l/p8OnGMKDXf1g2Q18/g942pxs8/ gmSHi4jlNYqmGgstDcDM =bASa -----END PGP SIGNATURE----- --Apple-Mail=_6BCD97C5-7AD5-4718-9613-3C1D463D3734-- From nobody Tue May 3 10:01:29 2016 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 B55DF12DC29; Tue, 3 May 2016 10:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 yAWNXoWTrm95; Tue, 3 May 2016 10:01:25 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 8F4F012DC1C; Tue, 3 May 2016 09:56:45 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id k142so33980480oib.1; Tue, 03 May 2016 09:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=6OvVElz/03Oef1xfZY3gPiW0g7h2sWIgERwgvBRMxuA=; b=JM99PzYzFGjz5e4qwDyFZzw7WYnwIzlZqrS64hpyzxoaqksrsjfWSb3qL4q8XjsYKE 1eIbRLZHsGh7JPO+RH9Xzxw8U5UzCrz36nK0UTKDyu+icBkamdvI9GG0exEFDVgHrnRB DsQfjBwsE9e9O2rgjnNjqZH2+FCp8E7DaksDPzRmaKxO4hZ3ndxmYqklusyv4CkNntFf POUx1lxxqHexoqV5U2ePaVvvgNbu6tmu7ykp36iR9Gudi85GuBdcwyDpww1NumG9NEte lhq8a3DIYlhHRmNnF42WC4E5BPUxb4YwyF6C8NiE2KAshz4M0mcKcY8LKIVrCsxvyQQe YdiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=6OvVElz/03Oef1xfZY3gPiW0g7h2sWIgERwgvBRMxuA=; b=FgUrb35yfwikHv9/CtBUVz+vx5mL/vTwg8047ZGT8J/1zEtJ6J767nRKgyqHgRRaCT uD0NiEz+0m7rKIh8fieerSTVJVK+5mnwQCk7z1szbrEG7n9qTLVundxHgCBfVPcRk0MB dtQPudtJ8tzxj5Lq43bnNb1jNBTZp+fhjM4uxjWg5e0zQc7HApM2D41bdEl1eShDZc2q 7e4r1h9TXioXyqt91UOEprKUloAcF033FvDDkML0BLTFFhwUfpE3JZNdONqtIbqeASut Wvlw3lSEQFzjkK+rqPxMszhmJDi1Uicx7SK8QNKU4Y28WQHXNuhLUfC2nbBYFqYuED0I +Weg== X-Gm-Message-State: AOPr4FU0Y2MUTVpm2IRJSGcorcoelofrve8Zlh67fTRBPnPNtM3RbllqIUyp3rlO39M2EKRGeF0tw9HH4eSnbA== MIME-Version: 1.0 X-Received: by 10.202.58.134 with SMTP id h128mr1903889oia.174.1462294604096; Tue, 03 May 2016 09:56:44 -0700 (PDT) Received: by 10.60.115.168 with HTTP; Tue, 3 May 2016 09:56:44 -0700 (PDT) In-Reply-To: <81AD480B-36AE-432B-BAF8-22BA10152573@cisco.com> References: <20160502222627.15846.1446.idtracker@ietfa.amsl.com> <52C94004-5548-4701-AA81-EBF8D5EC1BDD@cisco.com> <81AD480B-36AE-432B-BAF8-22BA10152573@cisco.com> Date: Tue, 3 May 2016 12:56:44 -0400 Message-ID: Subject: Re: Alia Atlas' Discuss on draft-ietf-bfd-seamless-ip-04: (with DISCUSS) From: Alia Atlas To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a113ce1b66f2e820531f2feeb Archived-At: Cc: "rtg-bfd@ietf.org" , "bfd-chairs@ietf.org" , The IESG , "draft-ietf-bfd-seamless-ip@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 17:01:27 -0000 --001a113ce1b66f2e820531f2feeb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable LGTM On Tue, May 3, 2016 at 12:53 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi, Alia, > > Thanks, and sounds good. This is what we have implemented, which should > address both: > > @@ -122,9 +122,9 @@ > The BFD Echo port defined by [RFC5881], port 3785, is used for the > S-BFD Echo function on IPv4, IPv6 and MPLS environments. > SBFDInitiator sessions MUST transmit S-BFD echo packets with > - destination port 3785. This document defines only the UDP port value > - for the S-BFD Echo function. The source port and the procedures for > - the S-BFD Echo function are outside the scope of this document. > + destination port 3785. The setting of the UDP source port [RFC5881] > + and the procedures [I-D.ietf-bfd-seamless-base] for the S-BFD Echo > + function are outside the scope of this document. > > 4. S-BFD Control Packet Demultiplexing > > @@ -138,13 +138,13 @@ > S-BFDReflector), then the packet MUST be looked up to locate a > corresponding SBFDReflector session based on the value from the "your > discriminator" field in the table describing S-BFD discriminators. > - If the port is not 7784, then the packet MUST be looked up to locate > - a corresponding SBFDInitiator session or classical BFD session based > - on the value from the "your discriminator" field in the table > - describing BFD discriminators. If the located session is an > - SBFDInitiator, then the destination IP address of the packet SHOULD > - be validated to be for self. If the packet is a classical BFD > - session, then the procedures from [RFC5880] apply. > + If the port is not 7784, but the packet is demultiplexed to be for an > + SBFDInitiator, then the packet MUST be looked up to locate a > + corresponding SBFDInitiator session based on the value from the "your > + discriminator" field in the table describing BFD discriminators. In > + that case, then the destination IP address of the packet SHOULD be > + validated to be for itself. If the packet demultiplexes to a > + classical BFD session, then the procedures from [RFC5880] apply. > > 5. Initiator Procedures > > @@ -165,7 +165,7 @@ > > > Thanks, > > =E2=80=94 Carlos. > > On May 3, 2016, at 12:30 PM, Alia Atlas wrote: > > Hi Carlos, > > On Mon, May 2, 2016 at 7:22 PM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Hi Alia, >> >> Thanks for the review and for these! Please see inline. >> >> > On May 2, 2016, at 6:26 PM, Alia Atlas wrote: >> > >> > Alia Atlas has entered the following ballot position for >> > draft-ietf-bfd-seamless-ip-04: Discuss >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut thi= s >> > introductory paragraph, however.) >> > >> > >> > Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> > for more information about IESG DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > DISCUSS: >> > ---------------------------------------------------------------------- >> > >> > I think that these are both simple fast issues to resolve. >> > >> > 1) Sec 3: "This document defines only the UDP port value >> > for the S-BFD Echo function. The source port and the procedures for >> > the S-BFD Echo function are outside the scope of this document." >> > Please add a reference to the S-BFD base document for defining where t= he >> > procedures are found. >> > >> > Where, precisely, is the source port defined? It wasn't in the S-BFD >> > base >> > document. This seems like a hole. Can you please clarify? >> >> This is done exactly as in RFC 5881, purposefully. I can add a clarifyin= g >> sentence like: >> >> OLD: >> This document defines only the UDP port value >> for the S-BFD Echo function. The source port and the procedures for >> the S-BFD Echo function are outside the scope of this document. >> >> NEW: >> S-BFD echo follows the BFD echo definitions of [RFC 5881]. >> Consequently, this document defines only the UDP port value >> for the S-BFD Echo function; the source port and the procedures for >> the S-BFD Echo function are outside the scope of this document. >> > > How about a reference by the source port to [RFC 5881] and a reference > for the procedures for the S-BFD Echo function > [draft-ietf-bfd-seamless-base]? > > What wasn't clear to me - not having recently read RFC 5881 in detail - w= as > that the UDP source port was defined in RFC 5881. I knew the procedures > were > in draft-ietf-bfd-seamless-base. > > >> > >> > 2) Sec 4: " If the port is not 7784, then the packet MUST be looked u= p >> > to locate >> > a corresponding SBFDInitiator session or classical BFD session based >> > on the value from the "your discriminator" field in the table >> > describing BFD discriminators. " >> > >> > I assume that you mean that UDP source port is used to look up the >> > appropriate receiver. >> > If that receiver handles BFD and S-BFD packets, then the "your >> > discriminator" field is used >> > to identify the BFD session. PLEASE clarify that because this reads = as >> > if BFD is the only >> > application that uses UDP. >> > >> >> Indeed, very much so. I suggest: >> >> OLD: >> If the port is not 7784, then the packet MUST be looked up to locate >> a corresponding SBFDInitiator session or classical BFD session based >> on the value from the "your discriminator" field in the table >> describing BFD discriminators. If the located session is an >> SBFDInitiator, then the destination IP address of the packet SHOULD >> be validated to be for self. If the packet is a classical BFD >> session, then the procedures from [RFC5880] apply. >> >> NEW: >> If the port is not 7784, but the packet is demultiplexed to be for an >> SBFDInitiator, then the packet MUST be looked up to locate >> a corresponding SBFDInitiator session based >> on the value from the "your discriminator" field in the table >> describing BFD discriminators. In that case, >> then the destination IP address of the packet SHOULD >> be validated to be for itself. If the packet demultiplexes to a >> classical BFD >> session, then the procedures from [RFC5880] apply. >> >> Would that work? >> > > Sure - sounds good. Thanks, > Alia > > >> Thanks, >> >> =E2=80=94 Carlos. >> >> > >> > >> > >> >> > > --001a113ce1b66f2e820531f2feeb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
LGTM

On Tue, May 3, 2016 at 12:53 PM, Carlos Pignataro (cpignata) <c= pignata@cisco.com> wrote:
<= div style=3D"word-wrap:break-word">Hi, Alia,

Thanks, and= sounds good. This is what we have implemented, which should address both:<= /div>

@@ -122,9 +122,9 @@
=C2=A0 =C2=A0=C2=A0The BFD = Echo port defined by [RFC5881], port 3785, is used for the
=C2=A0 =C2=A0= =C2=A0S-BFD Echo function on IPv4, IPv6 and MPLS environments.
=C2=A0 = =C2=A0=C2=A0SBFDInitiator sessions MUST transmit S-BFD echo packets with-=C2=A0=C2=A0=C2=A0destination port 3785.=C2=A0=C2=A0This document defines= only the UDP port value
-=C2=A0=C2=A0=C2=A0for the S-BFD Echo function.= =C2=A0=C2=A0The source port and the procedures for
-=C2=A0=C2=A0=C2=A0th= e S-BFD Echo function are outside the scope of this document.
+=C2=A0=C2= =A0=C2=A0destination port 3785.=C2=A0=C2=A0The setting of the UDP source po= rt [RFC5881]
+=C2=A0=C2=A0=C2=A0and the procedures [I-D.ietf-bfd-seamles= s-base] for the S-BFD Echo
+=C2=A0=C2=A0=C2=A0function are outside the s= cope of this document.
=C2=A0
=C2=A04.=C2=A0=C2=A0S-BFD Control Packe= t Demultiplexing
=C2=A0
@@ -138,13 +138,13 @@
=C2=A0 =C2=A0=C2=A0S= -BFDReflector), then the packet MUST be looked up to locate a
=C2=A0 =C2= =A0=C2=A0corresponding SBFDReflector session based on the value from the &q= uot;your
=C2=A0 =C2=A0=C2=A0discriminator" field in the table descr= ibing S-BFD discriminators.
-=C2=A0=C2=A0=C2=A0If the port is not 7784, = then the packet MUST be looked up to locate
-=C2=A0=C2=A0=C2=A0a corresp= onding SBFDInitiator session or classical BFD session based
-=C2=A0=C2= =A0=C2=A0on the value from the "your discriminator" field in the = table
-=C2=A0=C2=A0=C2=A0describing BFD discriminators.=C2=A0=C2=A0If th= e located session is an
-=C2=A0=C2=A0=C2=A0SBFDInitiator, then the desti= nation IP address of the packet SHOULD
-=C2=A0=C2=A0=C2=A0be validated t= o be for self.=C2=A0=C2=A0If the packet is a classical BFD
-=C2=A0=C2=A0= =C2=A0session, then the procedures from [RFC5880] apply.
+=C2=A0=C2=A0= =C2=A0If the port is not 7784, but the packet is demultiplexed to be for an=
+=C2=A0=C2=A0=C2=A0SBFDInitiator, then the packet MUST be looked up to = locate a
+=C2=A0=C2=A0=C2=A0corresponding SBFDInitiator session based on= the value from the "your
+=C2=A0=C2=A0=C2=A0discriminator" fi= eld in the table describing BFD discriminators.=C2=A0=C2=A0In
+=C2=A0=C2= =A0=C2=A0that case, then the destination IP address of the packet SHOULD be=
+=C2=A0=C2=A0=C2=A0validated to be for itself.=C2=A0=C2=A0If the packet= demultiplexes to a
+=C2=A0=C2=A0=C2=A0classical BFD session, then the p= rocedures from [RFC5880] apply.
=C2=A0
=C2=A05.=C2=A0=C2=A0Initiator = Procedures
=C2=A0
@@ -165,7 +165,7 @@


Thanks,

=E2=80=94 Carlos.

On May 3, 2016, at 12:= 30 PM, Alia Atlas <akatlas@gmail.com> wrote:

Hi Carlos= ,

On Mon, May 2, 2= 016 at 7:22 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com>= wrote:
Hi Alia,

Thanks for the review and for these! Please see inline.

> On May 2, 2016, at 6:26 PM, Alia Atlas <akatlas@gmail.com> wrote:
>
> Alia Atlas has entered the following ballot position for
> draft-ietf-bfd-seamless-ip-04: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/dr= aft-ietf-bfd-seamless-ip/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> I think that these are both simple fast issues to resolve.
>
> 1) Sec 3: "This document defines only the UDP port value
>=C2=A0 =C2=A0for the S-BFD Echo function.=C2=A0 The source port and the= procedures for
>=C2=A0 =C2=A0the S-BFD Echo function are outside the scope of this docu= ment."
> Please add a reference to the S-BFD base document for defining where t= he
> procedures are found.
>
> Where, precisely, is the source port defined?=C2=A0 It wasn't in t= he S-BFD
> base
> document.=C2=A0 This seems like a hole.=C2=A0 Can you please clarify?<= br>
This is done exactly as in RFC 5881, purposefully. I can add a clari= fying sentence like:

OLD:
=C2=A0 =C2=A0This document defines only the UDP port value
=C2=A0 =C2=A0for the S-BFD Echo function.=C2=A0 The source port and the pro= cedures for
=C2=A0 =C2=A0the S-BFD Echo function are outside the scope of this document= .

NEW:
=C2=A0 =C2=A0S-BFD echo follows the BFD echo definitions of [RFC 5881].
=C2=A0 =C2=A0Consequently, this document defines only the UDP port value =C2=A0 =C2=A0for the S-BFD Echo function; the source port and the procedure= s for
=C2=A0 =C2=A0the S-BFD Echo function are outside the scope of this do= cument.

How about a reference by= the source port to [RFC 5881] and a reference
for the procedures= for the S-BFD Echo function [draft-ietf-bfd-seamless-base]?

=
What wasn't clear to me - not having recently read RFC 5881 = in detail - was
that the UDP source port was defined in RFC 5881.= =C2=A0 I knew the procedures were
in draft-ietf-bfd-seamless-base= .
=C2=A0
>
> 2) Sec 4:=C2=A0 " If the port is not 7784, then the = packet MUST be looked up
> to locate
>=C2=A0 =C2=A0a corresponding SBFDInitiator session or classical BFD ses= sion based
>=C2=A0 =C2=A0on the value from the "your discriminator" field= in the table
>=C2=A0 =C2=A0describing BFD discriminators. "
>
> I assume that you mean that UDP source port is used to look up the
> appropriate receiver.
> If that receiver handles BFD and S-BFD packets, then the "your > discriminator" field is used
> to identify the BFD session.=C2=A0 =C2=A0PLEASE clarify that because t= his reads as
> if BFD is the only
> application that uses UDP.
>

Indeed, very much so. I suggest:

OLD:
=C2=A0 =C2=A0If the port is not 7784, then the packet MUST be looked = up to locate
=C2=A0 =C2=A0a corresponding SBFDInitiator session or classical BFD session= based
=C2=A0 =C2=A0on the value from the "your discriminator" field in = the table
=C2=A0 =C2=A0describing BFD discriminators.=C2=A0 If the located ses= sion is an
=C2=A0 =C2=A0SBFDInitiator, then the destination IP address of the packet S= HOULD
=C2=A0 =C2=A0be validated to be for self.=C2=A0 If the packet is a classica= l BFD
=C2=A0 =C2=A0session, then the procedures from [RFC5880] apply.

NEW:
=C2=A0 =C2=A0If the port is not 7784, but the packet is demultiplexed to be= for an
=C2=A0 =C2=A0SBFDInitiator, then the packet MUST be looked up to locate
=C2=A0 =C2=A0a corresponding SBFDInitiator session based
=C2=A0 =C2=A0on the value from the "your discriminator" fie= ld in the table
=C2=A0 =C2=A0describing BFD discriminators.=C2=A0 In that case,
=C2=A0 =C2=A0then the destination IP address of the packet SHOULD
=C2=A0 =C2=A0be validated to be for itself.=C2=A0 If the packet demultiplex= es to a classical BFD
=C2=A0 =C2=A0session, then the procedures from [RFC5880] apply.

Would that work?

Sure - sounds good.=C2= =A0 Thanks,
Alia=C2=A0
=C2=A0
Thanks,

=E2=80=94 Carlos.

>
>
>



--001a113ce1b66f2e820531f2feeb-- From nobody Tue May 3 10:26:24 2016 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 0CB6512D789; Tue, 3 May 2016 10:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 08ne06C_jopa; Tue, 3 May 2016 10:26:21 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446D712DB61; Tue, 3 May 2016 10:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8167; q=dns/txt; s=iport; t=1462296290; x=1463505890; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mRxwMoGNKPbYnqTD73a4BJVAp53yfOsRy8rVoU4pA4M=; b=e6hx86dePbh/j0PigqN49jyocTa26wx8MXMddVdbogBQBUEFZQP0uGx6 vo8FL7VvLmzx66+rxyYm9bSrMCcGpjV0iLN0fTMcsRkrdI9KI2toQj7yC /Ji+w/YQGVn66wdz6yX/jEInRuevcBOWjejm+rFx5GuMZKmEMGM+G+CKG A=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BlBACZ3ShX/5NdJa1fgzhTLQFPBrVjg?= =?us-ascii?q?h+CDw6BdSKFbgKBPjgUAQEBAQEBAWUnhEEBAQEDASNWBQsCAQgYKgICMhoLAgQ?= =?us-ascii?q?OBQ6IFAgOq1SRBgEBAQEBAQEBAQEBAQEBAQEBAQEPBASGIIF2gleEEQsGAQZIg?= =?us-ascii?q?k4rgi4Fh3iLLIRyAYMngWdtiByBaIRNiF2JQIVxAR4BQ4I2gTVsAYZ+CBcffwE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.24,573,1454976000"; d="asc'?scan'208";a="269200913" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2016 17:24:49 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u43HOmM6029699 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 17:24:49 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 13:24:48 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 3 May 2016 13:24:47 -0400 From: "Carlos Pignataro (cpignata)" To: "Mirja Kuehlewind (IETF)" Subject: =?utf-8?B?UmU6IE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt?= =?utf-8?Q?bfd-seamless-base-09:_(with_DISCUSS)?= Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1iZmQt?= =?utf-8?Q?seamless-base-09:_(with_DISCUSS)?= Thread-Index: AQHRpR8YB75iFhnPVECZQ0i//enE0Z+ne5KAgAAvsACAAA7wAA== Date: Tue, 3 May 2016 17:24:47 +0000 Message-ID: References: <20160503093512.7446.68991.idtracker@ietfa.amsl.com> <1EB9BDDB-483F-48BC-9D2F-D68E6ACA285E@kuehlewind.net> In-Reply-To: <1EB9BDDB-483F-48BC-9D2F-D68E6ACA285E@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.48.199] Content-Type: multipart/signed; boundary="Apple-Mail=_F51A4EF7-5D3E-4E93-9405-EC16E9129AFC"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 17:26:23 -0000 --Apple-Mail=_F51A4EF7-5D3E-4E93-9405-EC16E9129AFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Mirja, > On May 3, 2016, at 12:31 PM, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi Carlos, >=20 >=20 >> Am 03.05.2016 um 15:40 schrieb Carlos Pignataro (cpignata) = : >>=20 >> Hi, Mirja, >>=20 >> What is an uncontrolled packet in an IP network, and what entity = controls controlled ones? :-) >=20 > Questions over questions=E2=80=A6 :-) >=20 > See below... >=20 >>=20 >> More seriously, please see inline. >>=20 >>> On May 3, 2016, at 5:35 AM, Mirja Kuehlewind = wrote: >>>=20 >>> Mirja K=C3=BChlewind has entered the following ballot position for >>> draft-ietf-bfd-seamless-base-09: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> As S-BFD has no initiation process anymore it is not guarenteed that = the >>> receiver/responder actually exists. That means that packets could = float >>> (uncontrolled) in the network or even outside of the adminstrative = domain >>> (e.g. due to configuration mistakes). =46rom my point of view this = document >>> should recommend/require two things: >>>=20 >>=20 >> We have called out the misconfiguration =E2=80=94 however: >>=20 >>> 1) A maximum number of S-BFD packet that is allow to be send without >>> getting a response (maybe leading to a local error report). >>>=20 >>=20 >> This can result in a deadlock situation, if an S-BFD Reflector is = enabled much later. I=E2=80=99m very hesitant to cap the packets sent. = We can, and I think it is useful, MAY log an error for multiple = timeouts. >=20 > Okay, I understand that a hard limit probably does make sense. An = error log seems definitely useful. OK, that sounds good. See below. > Another proposal for consideration: Currently the draft says an = initiator should only send one packet per second if the target is in = ADMINDOWN state. In this case there this state is explicit announced. = However if the other end just disappears or was never/not yet there, one = could use an exponential back off instead, starting with a smaller = intervals than one second but then increase it exponentially. Just an = idea... Thanks for the proposal. Please have in mind however that this is a = protocol for detecting liveness (and lack of it), so increasing = exponentially defeats the purpose. Further, exponential back off may not be the best choice when = interacting with routing protocols. What we currently say is: The criteria for declaring loss of reachability and the action that would be triggered as a result are outside the scope of this document. As much of these are implementation choices. But we can add at the end =E2=80=9C, and MAY include logging an error." >=20 >>=20 >>> 2) Egress filtering at the adminstrative border of the domain that = uses >>> S-BFD to make sure that no S-BFD packets leave the domain. >>>=20 >>=20 >> This is no different than any other application that uses UDP; a = misconfigured DNS server will result in the same, and a traceroute is = also not too different. This seems too onerous of a requirement. An = administrative domain filters at ingress. >=20 > First of all, just because other protocols might have such a problem, = that does mean it=E2=80=99s okay. I agree with this. I had a different point in mind though =E2=80=94 = trying to specify this on every UDP application might not be the most = effective way. Perhaps there=E2=80=99s a UDP guideline you are = uncovering. > However, correctly me if I=E2=80=99m wrong, but there the situation = seems slightly different because there is no termination criterium at = all that means an s-bfd node would send useless data forever (=E2=80=A6 = until manual change of the config). >=20 But as far as this doc is concerned, let me try to make some = clarifications (and a correction). There are termination criteria =E2=80=94 the document says: An SBFDInitiator may be a persistent session on the initiator with a timer for S-BFD control packet transmissions (stateful SBFDInitiator). An SBFDInitiator may also be a module, a script or a tool on the initiator that transmits one or more S-BFD control packets "when needed" (stateless SBFDInitiator). For the case in which you have a =E2=80=9Cwhen needed=E2=80=9D = SBFDInitiator, the workflow is like a =E2=80=9Cping=E2=80=9D. For the case in which you have a =E2=80=9Cpersistent" SBFDInitiator, in = theory this can run forever (for some value of ever). However, please = don=E2=80=99t loose track of why this protocol exists. Having OAM = failures and do nothing about it defeats the purpose of having OAM. = Meaning, a red alarm will blink, a honk will horn, and the config state = will be changed (manually or by some support system). In other words, I do not think this is such a unique case (insofar as = running ad-infinutum). > I still believe that egress filtering would be more appropriate here = (than ingress) because the domain that is using s-bfd knows about it and = therefor can set up the respective filters and should not spam others = while hoping that filters are in place. >=20 To me, there is no insignificant operational complexity with requiring = the addition of filters throughout, for one particular application not = leaking (where the leak does not cause anything special), and when the = leak might happen because of a misconfiguration (or bug) but will be = detected by the operational support systems. The ROI does not seem to = add up. Does the explanation of the termination criteria help? >>=20 >> Seems to me the logging will alert someone/something to take action, = and should be enough. >=20 > Logging plus alerts is definitely a good thing. >=20 I agree. Will add =E2=80=9C, and MAY include logging an error.=E2=80=9D as per = above. Do you think we should expand on this somewhere else in the document? Thanks, =E2=80=94 Carlos. > Mirja >=20 >=20 >>=20 >> Thoughts? >>=20 >> Thanks, >>=20 >> =E2=80=94 Carlos. >>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_F51A4EF7-5D3E-4E93-9405-EC16E9129AFC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXKN7fAAoJEIXgpQGOZny9tNAP/0F3Ay1DaCeDdTQKHSJNs9GQ 6gyZB9S86xf1nVJ6s4+D2FT0ID2E+y+VplWXFpYQ07OMebXGKhA/Ok5f7Nzx0cE/ aXSAgMuKXNTbWiJz94NvHr7gfwrhymkSJ9XfrSlvzmQ35w17C82FTHoP8EFe7a8n Lqc6P3cDvnYFDVFl4sWr4jK0rj5k2IQ5jddQEOTsuRlBx4sRDomzP7l5HN6S80uL rEwD/1MiY2WCrjYwxQYN118P1CsdbyDuG7pHHVLMUYFU4p5w/2ersH6e9XAqBPu0 ikGI4uwCb2R0vl7cexLPBn0SihnMttPolX+SRPxgYCC3odlz15A+qyt4rkDlGoHR M63Rvx3p9QX6taqbvmQlyEMs6kRgqZCDSbce2pHzUL8WQwMS+kFGNRg4Oi6sc1vm NoAGJ9n2CY/q/Es09QibLn61oB9wKhPqKKeVloMxRmx/IBy0b89LqHsZXo+waFiH YuBJDG745RTaYmnFT2xkYuipKu1KJ8eIYpzOW83tpKY4br817DF2pBUbXI7Fe6rd PXRWhGO2YO53qATkrYz2V5xaP2sRa4TOvyde+nas9W544zMwlt5BsPsMdVY2D/3g 2t6bwJuiKcoSno4l1e1O26hGDols6o7hM/1I8YclOBuAYjYbpZTNALcDUylgPiId 6rT8BQ/JoKIl1b6GOP+6 =Lyq4 -----END PGP SIGNATURE----- --Apple-Mail=_F51A4EF7-5D3E-4E93-9405-EC16E9129AFC-- From nobody Tue May 3 14:00:38 2016 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 C55CF12D647; Tue, 3 May 2016 14:00:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" Subject: Ben Campbell's Discuss on draft-ietf-bfd-seamless-ip-04: (with DISCUSS and COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503210037.8272.28136.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 14:00:37 -0700 Archived-At: Cc: rtg-bfd@ietf.org, bfd-chairs@ietf.org, draft-ietf-bfd-seamless-ip@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 21:00:38 -0000 Ben Campbell has entered the following ballot position for draft-ietf-bfd-seamless-ip-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 4, 2nd paragraph: " If the port is not 7784, then the packet MUST be looked up to locate a corresponding SBFDInitiator session or classical BFD session based on the value from the "your discriminator" field in the table describing BFD discriminators. " Do I understand correctly that whether or not the destination port is 7784 tells you if this is an "initial" packet vs a "reflected" packet? If the destination port is not 7784, how do you know it’s not some competely different protocol? Do you assume the receiver has no other UDP based services? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 2: This doesn't seem to allow an administrator to configure different listening ports by administrative action. Is that the intent? Also, why does it matter if the source port is 7784? - 6.1, first bullet: Does this imply that the initiator must listen for reflected packets at its source port? Was that explicitly mentioned somewhere that I missed? Editorial: -5.1.1, first paragraph: I had trouble parsing the last sentence in the paragraph. From nobody Tue May 3 14:04:07 2016 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 E4C6912D8FE; Tue, 3 May 2016 14:04:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" Subject: Kathleen Moriarty's No Objection on draft-ietf-bfd-seamless-base-09: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503210405.8301.12183.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 14:04:05 -0700 Archived-At: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 21:04:06 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-bfd-seamless-base-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my prior discuss comments in the updated draft, noting them here to check before approval. This should be pretty easy to address. In the security consideration section, the following recommendation appears: o SBFDReflector MUST NOT look at the crypto sequence number before accepting the packet. Could you please add text to say what happens (what attacks are possible) if this is looked at? There is nothing to stop the crypt sequence number from being looked at, right? Is there a way to actually prevent that? From nobody Tue May 3 18:12:55 2016 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 40BF712D95B; Tue, 3 May 2016 18:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 jdi9T7caKvV5; Tue, 3 May 2016 18:12:52 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2264F12D6A3; Tue, 3 May 2016 18:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6256; q=dns/txt; s=iport; t=1462324372; x=1463533972; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0Nj9vyDm/7R+tlnbRvr4diOtUsx0FVR0KM/LcYmxtro=; b=ZdqFtd/nEoxVng9mQbxG0PTitrbPfgfJbbwGZLFcON1OAIwPIulxvy0A h1vaHoJHFA1HWR5MMs5tQ6FDnyVxmyy0t2JVVIhf/xPDkPD3sN1xjr7HO AxPGx7vfAvFiPGkV7WmzMeMqAuQjDsCZZUI9p+xKRlNFI4QSF/+skQBf/ g=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DXAgDiSylX/51dJa1egzhTfQa4DYIPD?= =?us-ascii?q?oF1IoVuAoE5OBQBAQEBAQEBZSeEQQEBAQMBI1YFCwIBCBgqAgIyJQIEDgUOiBQ?= =?us-ascii?q?IDqtAkHwBAQEBAQEBAQEBAQEBAQEBAQEBAQENBASGIIF2gleEEREBToJOK4IuB?= =?us-ascii?q?Yd4kB4BgyeBZ22IHIFohE2IXo8xAR4BQ4IABRsWgTVsAYZ/BxcHGH8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,574,1454976000"; d="asc'?scan'208";a="269349314" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 May 2016 01:12:50 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u441Co5I026048 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 May 2016 01:12:50 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 21:12:49 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 3 May 2016 21:12:49 -0400 From: "Carlos Pignataro (cpignata)" To: Ben Campbell Subject: Re: Ben Campbell's Discuss on draft-ietf-bfd-seamless-ip-04: (with DISCUSS and COMMENT) Thread-Topic: Ben Campbell's Discuss on draft-ietf-bfd-seamless-ip-04: (with DISCUSS and COMMENT) Thread-Index: AQHRpX7cNZPD9VLivEySYFMP+uYn3p+oPDaA Date: Wed, 4 May 2016 01:12:49 +0000 Message-ID: <582AE743-177E-4A8A-9B77-10F37C13AA28@cisco.com> References: <20160503210037.8272.28136.idtracker@ietfa.amsl.com> In-Reply-To: <20160503210037.8272.28136.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.62] Content-Type: multipart/signed; boundary="Apple-Mail=_F07BB8BE-861D-42C6-80CB-39C4567823E9"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-bfd-seamless-ip@ietf.org" , The IESG , "rtg-bfd@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 01:12:54 -0000 --Apple-Mail=_F07BB8BE-861D-42C6-80CB-39C4567823E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Ben, Many thanks for this review and raising these issues, please see inline. > On May 3, 2016, at 5:00 PM, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-bfd-seamless-ip-04: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Section 4, 2nd paragraph: " If the port is not 7784, then the packet > MUST be looked up to locate > a corresponding SBFDInitiator session or classical BFD session based > on the value from the "your discriminator" field in the table > describing BFD discriminators. " >=20 > Do I understand correctly that whether or not the destination port is > 7784 tells you if this is an "initial" packet vs a "reflected" packet? = If > the destination port is not 7784, how do you know it=E2=80=99s not = some competely > different protocol? Do you assume the receiver has no other UDP based > services? >=20 Alia caught the same thing. The text is currently kinda broken as = written in rev -04. We fixed this as follows based on Alia=E2=80=99s discuss, from our = working copy: This procedure for an S-BFD packet is executed on both the initiator and the reflector. If the port is 7784 (i.e., S-BFD packet for S-BFDReflector), then the packet MUST be looked up to locate a corresponding SBFDReflector session based on the value from the "your discriminator" field in the table describing S-BFD discriminators. If the port is not 7784, but the packet is demultiplexed to be for an SBFDInitiator, then the packet MUST be looked up to locate a corresponding SBFDInitiator session based on the value from the "your discriminator" field in the table describing BFD discriminators. In that case, then the destination IP address of the packet SHOULD be validated to be for itself. If the packet demultiplexes to a classical BFD session, then the procedures from [RFC5880] apply. Which should clarify your point as well. >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > - 2: This doesn't seem to allow an administrator to configure = different > listening ports by administrative action. Is that the intent? Also, = why > does it matter if the source port is 7784? >=20 That is correct, the intent is to not allow that port to be changed. The = source port requirement is to have more differentiation between = initiator and reflector. > - 6.1, first bullet: Does this imply that the initiator must listen = for > reflected packets at its source port? Was that explicitly mentioned > somewhere that I missed? >=20 Implied and you did not miss it. I will add it explicitly in Section 2 = (last sentence). I also broke Section 2 in paragraphs for readability: 2. S-BFD UDP Port A new UDP port is defined for the use of the S-BFD on IPv4, IPv6 and MPLS environments: 7784. On S-BFD control packets from the SBFDInitiator to the SBFDReflector, the SBFDReflector session MUST listen for incoming S-BFD control packets on the port 7784. SBFDInitiator sessions MUST transmit S-BFD control packets with destination port 7784. The source port of the S-BFD control packets transmitted by SBFDInitiator sessions can be any but MUST NOT be 7784. The same UDP source port number MUST be used for all S-BFD control packets associated with a particular SBFDInitiator session. The source port number is unique among all SBFDInitiator sessions on the system. On S-BFD control packets from the SBFDReflecto to the SBFDInitiator, the SBFDInitiator MUST listen for reflected S-BFD control packets at its source port. > Editorial: >=20 > -5.1.1, first paragraph: I had trouble parsing the last sentence in = the > paragraph. >=20 >=20 Slightly wordsmithed as : address or the label stack. It is, however, possible for an SBFDInitiator to carefully set the "your discriminator" and TTL fields to perform a continuity test in the direction towards a target, but destined to a transit network node and not to the target itself. Hope this helps, =E2=80=94 Carlos. --Apple-Mail=_F07BB8BE-861D-42C6-80CB-39C4567823E9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXKUyRAAoJEIXgpQGOZny9WAYQAK9oNXfFEyY0L6UIcdxl8faj R7W/AkNoXNG5f/eYXPp1zxRPBGsSANO/S7SaOfpdvwlGM/YWgXa+FYtpm5ha12Z5 adARKsYuR6sGTY0CV1IFT7eawSEKQVPv1WZaBFZke4MGVsZQCr4Qr4yc680SngRa 1i/vVPpsAV6iTcmk+JBfh58JPFPm5O/otKA6tT6yriq/P3pnBWXOezL1GuxHaUKx Ha++nM7I3jaqE9mTKTX7dAivk2LTuxd8rHvGq7Xgq0czg76dD4MU6ONfKbdoTuvU p5s+VVv1iYUBLrYxDNA50OBHQLny5LCT6daTnaO1FMZtNpZLTG6+YgPIVbb7zpws qnAf4+iH/5aMhiG/rUNBSPbTU55dEGtI/eHmFadRUwo3gHhzGLcgM+44j1WVUT+t HF09uLeUu62NunHt9EZbS8jQzlWvSPNZIHOJA9GSfRHVI+k8QTWRSuOXCQN62N4x 5426rLSmgMcDKlGz3bA6CMPQH5ZVMutKuJi4z43HIu3y1pyJ69Byu5gaZsomba0A b/l4k4Wa2ZWpiNUsU7GjNmOk23m/xo8ahsjvbHfcmOlJSnxsbQtaETdjRUw3h5Fl E50YsZVmvuoJM8cnx5XfLu2ZdJhkqCUQbMA5hJmEUO7mQ2nLMhVGQxwqaD8f+AO2 o99SijplbUZUoVPGy/Sr =g9No -----END PGP SIGNATURE----- --Apple-Mail=_F07BB8BE-861D-42C6-80CB-39C4567823E9-- From nobody Tue May 3 18:23:51 2016 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 757D112DA9E; Tue, 3 May 2016 18:23:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" Subject: Ben Campbell's No Objection on draft-ietf-bfd-seamless-base-09: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504012348.8197.85394.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 18:23:48 -0700 Archived-At: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 01:23:48 -0000 Ben Campbell has entered the following ballot position for draft-ietf-bfd-seamless-base-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- DISCUSS cleared based on proposed edits by Carlos. Thanks for addressing it! From nobody Tue May 3 19:44:30 2016 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 A5FAA12D173; Tue, 3 May 2016 19:44:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" Subject: Spencer Dawkins' No Objection on draft-ietf-bfd-seamless-ip-04: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504024429.8276.24783.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 19:44:29 -0700 Archived-At: Cc: rtg-bfd@ietf.org, bfd-chairs@ietf.org, draft-ietf-bfd-seamless-ip@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 02:44:29 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-bfd-seamless-ip-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a couple of small things. I'm pretty sure I know why * UDP destination port MUST be set to a well-known UDP destination port assigned for S-BFD: 7784. * UDP source port MUST NOT be set to 7784. the UDP source port has this restriction, but it might be helpful to people who can't guess, if you could add a phrase explaining why. We were all new protocol designers once. It's a small thing, but BFD Chairs we're phasing out @tools.ietf.org in favor of @ietf.org, aren't we? From nobody Tue May 3 19:59:14 2016 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 95E6C12D585; Tue, 3 May 2016 19:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=unavailable 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 7SgC9tS2_btT; Tue, 3 May 2016 19:59:09 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5EDF712D5C0; Tue, 3 May 2016 19:59:08 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u442x58o015323 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 May 2016 21:59:06 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Carlos Pignataro" Subject: Re: Ben Campbell's Discuss on draft-ietf-bfd-seamless-ip-04: (with DISCUSS and COMMENT) Date: Tue, 03 May 2016 21:59:04 -0500 Message-ID: In-Reply-To: <582AE743-177E-4A8A-9B77-10F37C13AA28@cisco.com> References: <20160503210037.8272.28136.idtracker@ietfa.amsl.com> <582AE743-177E-4A8A-9B77-10F37C13AA28@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "draft-ietf-bfd-seamless-ip@ietf.org" , The IESG , "rtg-bfd@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 02:59:10 -0000 Hi Carlos, Thanks for the response. One question in-line (I removed sections that seem closed.): Thanks! Ben. On 3 May 2016, at 20:12, Carlos Pignataro (cpignata) wrote: [...] >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Section 4, 2nd paragraph: " If the port is not 7784, then the packet >> MUST be looked up to locate >> a corresponding SBFDInitiator session or classical BFD session >> based >> on the value from the "your discriminator" field in the table >> describing BFD discriminators. " >> >> Do I understand correctly that whether or not the destination port is >> 7784 tells you if this is an "initial" packet vs a "reflected" >> packet? If >> the destination port is not 7784, how do you know it’s not some >> competely >> different protocol? Do you assume the receiver has no other UDP based >> services? >> > > Alia caught the same thing. The text is currently kinda broken as > written in rev -04. > > We fixed this as follows based on Alia’s discuss, from our working > copy: > > This procedure for an S-BFD packet is executed on both the > initiator > and the reflector. If the port is 7784 (i.e., S-BFD packet for > S-BFDReflector), then the packet MUST be looked up to locate a > corresponding SBFDReflector session based on the value from the > "your > discriminator" field in the table describing S-BFD discriminators. > If the port is not 7784, but the packet is demultiplexed to be for > an > SBFDInitiator, then the packet MUST be looked up to locate a > corresponding SBFDInitiator session based on the value from the > "your > discriminator" field in the table describing BFD discriminators. > In > that case, then the destination IP address of the packet SHOULD be > validated to be for itself. If the packet demultiplexes to a > classical BFD session, then the procedures from [RFC5880] apply. > > Which should clarify your point as well. I think it does, and will clear the discuss. For my own curiosity: do I understand correctly, that the non 7784 port would be a port that a reflector learned from the source-port of an initiator message, which by necessity be listening for S-BFD packets (based on your answer below about an initiator listening on it's source port? [...] From nobody Tue May 3 20:00:32 2016 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 2156A12D54A; Tue, 3 May 2016 20:00:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" Subject: Ben Campbell's No Objection on draft-ietf-bfd-seamless-ip-04: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504030030.8366.66366.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 20:00:30 -0700 Archived-At: Cc: rtg-bfd@ietf.org, bfd-chairs@ietf.org, draft-ietf-bfd-seamless-ip@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 03:00:30 -0000 Ben Campbell has entered the following ballot position for draft-ietf-bfd-seamless-ip-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS point as well as my comments. From nobody Wed May 4 07:21:25 2016 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 EFDBE12D1EB for ; Wed, 4 May 2016 07:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 Un4hiEsEJ-H3 for ; Wed, 4 May 2016 07:21:17 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574C812D6AE for ; Wed, 4 May 2016 07:20:32 -0700 (PDT) Received: (qmail 14294 invoked from network); 4 May 2016 16:13:48 +0200 Received: from p5dec2412.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.36.18) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 4 May 2016 16:13:48 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-b?= =?utf-8?Q?fd-seamless-base-09=3A_=28with_DISCUSS=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Wed, 4 May 2016 16:13:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160503093512.7446.68991.idtracker@ietfa.amsl.com> <1EB9BDDB-483F-48BC-9D2F-D68E6ACA285E@kuehlewind.net> To: "Carlos Pignataro (cpignata)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 14:21:19 -0000 Hi Carlos, see below. > Am 03.05.2016 um 19:24 schrieb Carlos Pignataro (cpignata) = : >=20 > Hi, Mirja, >=20 >> On May 3, 2016, at 12:31 PM, Mirja Kuehlewind (IETF) = wrote: >>=20 >> Hi Carlos, >>=20 >>=20 >>> Am 03.05.2016 um 15:40 schrieb Carlos Pignataro (cpignata) = : >>>=20 >>> Hi, Mirja, >>>=20 >>> What is an uncontrolled packet in an IP network, and what entity = controls controlled ones? :-) >>=20 >> Questions over questions=E2=80=A6 :-) >>=20 >> See below... >>=20 >>>=20 >>> More seriously, please see inline. >>>=20 >>>> On May 3, 2016, at 5:35 AM, Mirja Kuehlewind = wrote: >>>>=20 >>>> Mirja K=C3=BChlewind has entered the following ballot position for >>>> draft-ietf-bfd-seamless-base-09: Discuss >>>>=20 >>>> When responding, please keep the subject line intact and reply to = all >>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>> introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> As S-BFD has no initiation process anymore it is not guarenteed = that the >>>> receiver/responder actually exists. That means that packets could = float >>>> (uncontrolled) in the network or even outside of the adminstrative = domain >>>> (e.g. due to configuration mistakes). =46rom my point of view this = document >>>> should recommend/require two things: >>>>=20 >>>=20 >>> We have called out the misconfiguration =E2=80=94 however: >>>=20 >>>> 1) A maximum number of S-BFD packet that is allow to be send = without >>>> getting a response (maybe leading to a local error report). >>>>=20 >>>=20 >>> This can result in a deadlock situation, if an S-BFD Reflector is = enabled much later. I=E2=80=99m very hesitant to cap the packets sent. = We can, and I think it is useful, MAY log an error for multiple = timeouts. >>=20 >> Okay, I understand that a hard limit probably does make sense. An = error log seems definitely useful. >=20 > OK, that sounds good. See below. >=20 >> Another proposal for consideration: Currently the draft says an = initiator should only send one packet per second if the target is in = ADMINDOWN state. In this case there this state is explicit announced. = However if the other end just disappears or was never/not yet there, one = could use an exponential back off instead, starting with a smaller = intervals than one second but then increase it exponentially. Just an = idea... >=20 > Thanks for the proposal. Please have in mind however that this is a = protocol for detecting liveness (and lack of it), so increasing = exponentially defeats the purpose. >=20 > Further, exponential back off may not be the best choice when = interacting with routing protocols. >=20 > What we currently say is: > The criteria for declaring loss of > reachability and the action that would be triggered as a result > are outside the scope of this document. >=20 > As much of these are implementation choices. >=20 > But we can add at the end =E2=80=9C, and MAY include logging an = error.=E2=80=9C Please do so. >>=20 >>>=20 >>>> 2) Egress filtering at the adminstrative border of the domain that = uses >>>> S-BFD to make sure that no S-BFD packets leave the domain. >>>>=20 >>>=20 >>> This is no different than any other application that uses UDP; a = misconfigured DNS server will result in the same, and a traceroute is = also not too different. This seems too onerous of a requirement. An = administrative domain filters at ingress. >>=20 >> First of all, just because other protocols might have such a problem, = that does mean it=E2=80=99s okay. >=20 > I agree with this. I had a different point in mind though =E2=80=94 = trying to specify this on every UDP application might not be the most = effective way. Perhaps there=E2=80=99s a UDP guideline you are = uncovering. >=20 >> However, correctly me if I=E2=80=99m wrong, but there the situation = seems slightly different because there is no termination criterium at = all that means an s-bfd node would send useless data forever (=E2=80=A6 = until manual change of the config). >>=20 >=20 > But as far as this doc is concerned, let me try to make some = clarifications (and a correction). >=20 > There are termination criteria =E2=80=94 the document says: >=20 > An SBFDInitiator may be a persistent session on the initiator with a > timer for S-BFD control packet transmissions (stateful > SBFDInitiator). An SBFDInitiator may also be a module, a script or = a > tool on the initiator that transmits one or more S-BFD control > packets "when needed" (stateless SBFDInitiator). >=20 > For the case in which you have a =E2=80=9Cwhen needed=E2=80=9D = SBFDInitiator, the workflow is like a =E2=80=9Cping=E2=80=9D. >=20 > For the case in which you have a =E2=80=9Cpersistent" SBFDInitiator, = in theory this can run forever (for some value of ever). However, please = don=E2=80=99t loose track of why this protocol exists. Having OAM = failures and do nothing about it defeats the purpose of having OAM. = Meaning, a red alarm will blink, a honk will horn, and the config state = will be changed (manually or by some support system). >=20 > In other words, I do not think this is such a unique case (insofar as = running ad-infinutum). I still believe that the case where you have a misconfiguration and the = initiator sends packets (forever) but never ever gest a reply (and never = has seen a reply in the past), is a different case and can be detected = and handled separately. >=20 >> I still believe that egress filtering would be more appropriate here = (than ingress) because the domain that is using s-bfd knows about it and = therefor can set up the respective filters and should not spam others = while hoping that filters are in place. >>=20 >=20 > To me, there is no insignificant operational complexity with requiring = the addition of filters throughout, for one particular application not = leaking (where the leak does not cause anything special), and when the = leak might happen because of a misconfiguration (or bug) but will be = detected by the operational support systems. The ROI does not seem to = add up. Okay the document should probably not require egress filtering in any = case but what=E2=80=99s about saying something like: =E2=80=9EIf S-BFD is used it SHOULD be ensured that S-BFD control packet = do not propagate outside of the administrative domain that uses it.=E2=80=9C= This is not an uncommon thing to specify also for other protocols. Mirja >=20 > Does the explanation of the termination criteria help? >=20 >>>=20 >>> Seems to me the logging will alert someone/something to take action, = and should be enough. >>=20 >> Logging plus alerts is definitely a good thing. >>=20 >=20 > I agree. >=20 > Will add =E2=80=9C, and MAY include logging an error.=E2=80=9D as per = above. >=20 > Do you think we should expand on this somewhere else in the document? >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >> Mirja >>=20 >>=20 >>>=20 >>> Thoughts? >>>=20 >>> Thanks, >>>=20 >>> =E2=80=94 Carlos. >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >=20 From nobody Wed May 4 07:34:02 2016 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 9041412D540; Wed, 4 May 2016 07:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 y2AuiP6BRI0g; Wed, 4 May 2016 07:33:52 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BF1E12D6B0; Wed, 4 May 2016 07:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34390; q=dns/txt; s=iport; t=1462372432; x=1463582032; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Eshu19X2f9ZdSnuLtZve6ofLj8fFjJklaZUwvIDLlpQ=; b=SQCxxwTiV0cBDuEX+TPnF1lWL9awhTh0RxogkKg4iJIfGuGVk4Zyd4oz mgn4ZjQc9vuA6WqB06YXGIdnDoyke6z61wHeqMtOF4ll+/golPoN1VvSh 8mh+eFhVon7G6z9N/DrwoupRR2WaJ9ntKZeSs7aCYHnuptTqRlRooloQM U=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvAwDzBypX/5JdJa1UCoJsTFMtAU8Gt?= =?us-ascii?q?TSCH4IPDoF1IoVuAoE0OBQBAQEBAQEBZSeEQQEBAQMBI1YFCwIBCBggAQkCAjI?= =?us-ascii?q?aCwIEDgUOiBQIDqwYkRcBAQEBAQEBAQEBAQEBAQEBAQEBAQENBASGIIF2gleEE?= =?us-ascii?q?QYFBgEGgxYrgi4Fh3iLLIR1AYMngWdtiByBaIRNiF6JQoVxAR4BQ4I2gTVsAYZ?= =?us-ascii?q?+CBcffwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,577,1454976000"; d="asc'?scan'208,217";a="99004132" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 May 2016 14:33:50 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u44EXoUi019766 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 May 2016 14:33:50 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 May 2016 10:33:49 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Wed, 4 May 2016 10:33:49 -0400 From: "Carlos Pignataro (cpignata)" To: "Mirja Kuehlewind (IETF)" Subject: =?utf-8?B?UmU6IE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt?= =?utf-8?Q?bfd-seamless-base-09:_(with_DISCUSS)?= Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1iZmQt?= =?utf-8?Q?seamless-base-09:_(with_DISCUSS)?= Thread-Index: AQHRpR8YB75iFhnPVECZQ0i//enE0Z+ne5KAgAAvsACAAA7wAIABXPwAgAAFk4A= Date: Wed, 4 May 2016 14:33:49 +0000 Message-ID: <2129C9FD-F4C4-4C2D-B3E9-369A754163A4@cisco.com> References: <20160503093512.7446.68991.idtracker@ietfa.amsl.com> <1EB9BDDB-483F-48BC-9D2F-D68E6ACA285E@kuehlewind.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.49.250] Content-Type: multipart/signed; boundary="Apple-Mail=_54959E82-5E16-4867-99D7-2079CEBFCDC2"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 14:33:55 -0000 --Apple-Mail=_54959E82-5E16-4867-99D7-2079CEBFCDC2 Content-Type: multipart/alternative; boundary="Apple-Mail=_5F7419A0-8ED7-4743-8483-488B1BF867DF" --Apple-Mail=_5F7419A0-8ED7-4743-8483-488B1BF867DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks much for the response, Mirja! I think we are converging, please see inline. > On May 4, 2016, at 10:13 AM, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi Carlos, >=20 > see below. >=20 >> Am 03.05.2016 um 19:24 schrieb Carlos Pignataro (cpignata) = : >>=20 >> Hi, Mirja, >>=20 >>> On May 3, 2016, at 12:31 PM, Mirja Kuehlewind (IETF) = wrote: >>>=20 >>> Hi Carlos, >>>=20 >>>=20 >>>> Am 03.05.2016 um 15:40 schrieb Carlos Pignataro (cpignata) = : >>>>=20 >>>> Hi, Mirja, >>>>=20 >>>> What is an uncontrolled packet in an IP network, and what entity = controls controlled ones? :-) >>>=20 >>> Questions over questions=E2=80=A6 :-) >>>=20 >>> See below... >>>=20 >>>>=20 >>>> More seriously, please see inline. >>>>=20 >>>>> On May 3, 2016, at 5:35 AM, Mirja Kuehlewind = wrote: >>>>>=20 >>>>> Mirja K=C3=BChlewind has entered the following ballot position for >>>>> draft-ietf-bfd-seamless-base-09: Discuss >>>>>=20 >>>>> When responding, please keep the subject line intact and reply to = all >>>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>>> introductory paragraph, however.) >>>>>=20 >>>>>=20 >>>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>=20 >>>>>=20 >>>>> The document, along with other ballot positions, can be found = here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> As S-BFD has no initiation process anymore it is not guarenteed = that the >>>>> receiver/responder actually exists. That means that packets could = float >>>>> (uncontrolled) in the network or even outside of the adminstrative = domain >>>>> (e.g. due to configuration mistakes). =46rom my point of view this = document >>>>> should recommend/require two things: >>>>>=20 >>>>=20 >>>> We have called out the misconfiguration =E2=80=94 however: >>>>=20 >>>>> 1) A maximum number of S-BFD packet that is allow to be send = without >>>>> getting a response (maybe leading to a local error report). >>>>>=20 >>>>=20 >>>> This can result in a deadlock situation, if an S-BFD Reflector is = enabled much later. I=E2=80=99m very hesitant to cap the packets sent. = We can, and I think it is useful, MAY log an error for multiple = timeouts. >>>=20 >>> Okay, I understand that a hard limit probably does make sense. An = error log seems definitely useful. >>=20 >> OK, that sounds good. See below. >>=20 >>> Another proposal for consideration: Currently the draft says an = initiator should only send one packet per second if the target is in = ADMINDOWN state. In this case there this state is explicit announced. = However if the other end just disappears or was never/not yet there, one = could use an exponential back off instead, starting with a smaller = intervals than one second but then increase it exponentially. Just an = idea... >>=20 >> Thanks for the proposal. Please have in mind however that this is a = protocol for detecting liveness (and lack of it), so increasing = exponentially defeats the purpose. >>=20 >> Further, exponential back off may not be the best choice when = interacting with routing protocols. >>=20 >> What we currently say is: >> The criteria for declaring loss of >> reachability and the action that would be triggered as a result >> are outside the scope of this document. >>=20 >> As much of these are implementation choices. >>=20 >> But we can add at the end =E2=80=9C, and MAY include logging an = error.=E2=80=9C >=20 > Please do so. Done. >=20 >>>=20 >>>>=20 >>>>> 2) Egress filtering at the adminstrative border of the domain that = uses >>>>> S-BFD to make sure that no S-BFD packets leave the domain. >>>>>=20 >>>>=20 >>>> This is no different than any other application that uses UDP; a = misconfigured DNS server will result in the same, and a traceroute is = also not too different. This seems too onerous of a requirement. An = administrative domain filters at ingress. >>>=20 >>> First of all, just because other protocols might have such a = problem, that does mean it=E2=80=99s okay. >>=20 >> I agree with this. I had a different point in mind though =E2=80=94 = trying to specify this on every UDP application might not be the most = effective way. Perhaps there=E2=80=99s a UDP guideline you are = uncovering. >>=20 >>> However, correctly me if I=E2=80=99m wrong, but there the situation = seems slightly different because there is no termination criterium at = all that means an s-bfd node would send useless data forever (=E2=80=A6 = until manual change of the config). >>>=20 >>=20 >> But as far as this doc is concerned, let me try to make some = clarifications (and a correction). >>=20 >> There are termination criteria =E2=80=94 the document says: >>=20 >> An SBFDInitiator may be a persistent session on the initiator with a >> timer for S-BFD control packet transmissions (stateful >> SBFDInitiator). An SBFDInitiator may also be a module, a script or = a >> tool on the initiator that transmits one or more S-BFD control >> packets "when needed" (stateless SBFDInitiator). >>=20 >> For the case in which you have a =E2=80=9Cwhen needed=E2=80=9D = SBFDInitiator, the workflow is like a =E2=80=9Cping=E2=80=9D. >>=20 >> For the case in which you have a =E2=80=9Cpersistent" SBFDInitiator, = in theory this can run forever (for some value of ever). However, please = don=E2=80=99t loose track of why this protocol exists. Having OAM = failures and do nothing about it defeats the purpose of having OAM. = Meaning, a red alarm will blink, a honk will horn, and the config state = will be changed (manually or by some support system). >>=20 >> In other words, I do not think this is such a unique case (insofar as = running ad-infinutum). >=20 > I still believe that the case where you have a misconfiguration and = the initiator sends packets (forever) but never ever gest a reply (and = never has seen a reply in the past), is a different case and can be = detected and handled separately. >=20 Again, I would not qualify this as =E2=80=98forever=E2=80=99, but I = understand what you mean. >>=20 >>> I still believe that egress filtering would be more appropriate here = (than ingress) because the domain that is using s-bfd knows about it and = therefor can set up the respective filters and should not spam others = while hoping that filters are in place. >>>=20 >>=20 >> To me, there is no insignificant operational complexity with = requiring the addition of filters throughout, for one particular = application not leaking (where the leak does not cause anything = special), and when the leak might happen because of a misconfiguration = (or bug) but will be detected by the operational support systems. The = ROI does not seem to add up. >=20 > Okay the document should probably not require egress filtering in any = case but what=E2=80=99s about saying something like: >=20 > =E2=80=9EIf S-BFD is used it SHOULD be ensured that S-BFD control = packet do not propagate outside of the administrative domain that uses = it.=E2=80=9C >=20 We can add an additional explanation of the problem before a statement, = but I do not think that particular SHOULD is actionable. How=E2=80=99s = something like: Explain that without handshake, a persistent initiator can send blindly, = to then add =E2=80=9CIn such case, operational measures SHOULD be taken = to identify if S-BFD packets are not responded to for an extended period = of time, and remediate the situation=E2=80=9D > This is not an uncommon thing to specify also for other protocols. >=20 I agree. Frankly, I am happy with either statement, but I think the = latter might be more operationally actionable. Preference? Thanks, =E2=80=94 Carlos. > Mirja >=20 >=20 >>=20 >> Does the explanation of the termination criteria help? >>=20 >>>>=20 >>>> Seems to me the logging will alert someone/something to take = action, and should be enough. >>>=20 >>> Logging plus alerts is definitely a good thing. >>>=20 >>=20 >> I agree. >>=20 >> Will add =E2=80=9C, and MAY include logging an error.=E2=80=9D as per = above. >>=20 >> Do you think we should expand on this somewhere else in the document? >>=20 >> Thanks, >>=20 >> =E2=80=94 Carlos. >>=20 >>> Mirja >>>=20 >>>=20 >>>>=20 >>>> Thoughts? >>>>=20 >>>> Thanks, >>>>=20 >>>> =E2=80=94 Carlos. --Apple-Mail=_5F7419A0-8ED7-4743-8483-488B1BF867DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks much for the response, Mirja!

I think we are converging, please see = inline.

On May 4, 2016, at 10:13 AM, Mirja = Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:

Hi Carlos,

see below.

Am = 03.05.2016 um 19:24 schrieb Carlos Pignataro (cpignata) <cpignata@cisco.com>:

Hi, = Mirja,

On May 3, 2016, at 12:31 PM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>= wrote:

Hi Carlos,


Am = 03.05.2016 um 15:40 schrieb Carlos Pignataro (cpignata) <cpignata@cisco.com>:

Hi, = Mirja,

What is an uncontrolled packet in an = IP network, and what entity controls controlled ones? :-)

Questions over questions=E2=80=A6 = :-)

See below...


More = seriously, please see inline.

On May 3, 2016, at 5:35 AM, Mirja Kuehlewind = <ietf@kuehlewind.net> wrote:

Mirja K=C3=BChlewind has entered the following ballot = position for
draft-ietf-bfd-seamless-base-09: Discuss

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/<= /a>



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

As S-BFD has no initiation process = anymore it is not guarenteed that the
receiver/responder = actually exists. That means that packets could float
(uncontrolled) in the network or even outside of the = adminstrative domain
(e.g. due to configuration mistakes). = =46rom my point of view this document
should = recommend/require two things:


We have called out the = misconfiguration =E2=80=94 however:

1) A maximum number of = S-BFD packet that is allow to be send without
getting a = response (maybe leading to a local error report).


This can result in a deadlock = situation, if an S-BFD Reflector is enabled much later. I=E2=80=99m very = hesitant to cap the packets sent. We can, and I think it is useful, MAY = log an error for multiple timeouts.

Okay, I understand that a hard limit probably does make = sense. An error log seems definitely useful.

OK, that sounds good. See = below.

Another proposal for consideration: Currently the draft says = an initiator should only send one packet per second if the target is in = ADMINDOWN state. In this case there this state is explicit announced. = However if the other end just disappears or was never/not yet there, one = could use an exponential back off instead, starting with a smaller = intervals than one second but then increase it exponentially. Just an = idea...

Thanks for the = proposal. Please have in mind however that this is a protocol for = detecting liveness (and lack of it), so increasing exponentially defeats = the purpose.

Further, exponential back off = may not be the best choice when interacting with routing protocols.

What we currently say is:
    The criteria for declaring loss of
    reachability and the action that = would be triggered as a result
    are = outside the scope of this document.

As much = of these are implementation choices.

But we = can add at the end =E2=80=9C, and MAY include logging an error.=E2=80=9C

Please do so.

Done.




2) Egress filtering at the adminstrative border of the domain = that uses
S-BFD to make sure that no S-BFD packets leave = the domain.


This = is no different than any other application that uses UDP; a = misconfigured DNS server will result in the same, and a traceroute is = also not too different. This seems too onerous of a requirement. An = administrative domain filters at ingress.

First of all, just because other protocols might have such a = problem, that does mean it=E2=80=99s okay.

I agree with this. I had a different point in mind though =E2=80= =94 trying to specify this on every UDP application might not be the = most effective way. Perhaps there=E2=80=99s a UDP guideline you are = uncovering.

However, correctly me if I=E2=80=99m wrong, but there the = situation seems slightly different because there is no termination = criterium at all that means an s-bfd node would send useless data = forever (=E2=80=A6 until manual change of the config).


But as far as this doc is = concerned, let me try to make some clarifications (and a correction).

There are termination criteria =E2=80=94 the = document says:

 An SBFDInitiator may = be a persistent session on the initiator with a
 timer = for S-BFD control packet transmissions (stateful
 SBFDInitiator).  An SBFDInitiator may also be a = module, a script or a
 tool on the initiator that = transmits one or more S-BFD control
 packets "when = needed" (stateless SBFDInitiator).

For the = case in which you have a =E2=80=9Cwhen needed=E2=80=9D SBFDInitiator, = the workflow is like a =E2=80=9Cping=E2=80=9D.

For the case in which you have a =E2=80=9Cpersistent" = SBFDInitiator, in theory this can run forever (for some value of ever). = However, please don=E2=80=99t loose track of why this protocol exists. = Having OAM failures and do nothing about it defeats the purpose of = having OAM. Meaning, a red alarm will blink, a honk will horn, and the = config state will be changed (manually or by some support system).

In other words, I do not think this is such a = unique case (insofar as running ad-infinutum).

I still believe that the case where you have a = misconfiguration and the initiator sends packets (forever) but never = ever gest a reply (and never has seen a reply in the past), is a = different case and can be detected and handled separately.




I = still believe that egress filtering would be more appropriate here (than = ingress) because the domain that is using s-bfd knows about it and = therefor can set up the respective filters and should not spam others = while hoping that filters are in place.


To me, there is no insignificant = operational complexity with requiring the addition of filters = throughout, for one particular application not leaking (where the leak = does not cause anything special), and when the leak might happen because = of a misconfiguration (or bug) but will be detected by the operational = support systems. The ROI does not seem to add up.

Okay the document should probably not require = egress filtering in any case but what=E2=80=99s about saying something = like:

=E2=80=9EIf S-BFD = is used it SHOULD be ensured that S-BFD control packet do not propagate = outside of the administrative domain that uses it.=E2=80=9C


We = can add an additional explanation of the problem before a statement, but = I do not think that particular SHOULD is actionable. How=E2=80=99s = something like:

Explain that without = handshake, a persistent initiator can send blindly, to then add =E2=80=9CI= n such case, operational measures SHOULD be taken to identify if S-BFD = packets are not responded to for an extended period of time, and = remediate the situation=E2=80=9D

This is not an = uncommon thing to specify also for other protocols.


I = agree. Frankly, I am happy with either statement, but I think the latter = might be more operationally actionable.

Preference?

Thanks,

=E2=80=94= Carlos.

Mirja



Does the = explanation of the termination criteria help?


Seems to me the logging will alert = someone/something to take action, and should be enough.

Logging plus alerts is definitely = a good thing.


I = agree.

Will add =E2=80=9C, and MAY include = logging an error.=E2=80=9D as per above.

Do = you think we should expand on this somewhere else in the document?

Thanks,

=E2=80=94 = Carlos.

Mirja



Thoughts?

Thanks,

=E2=80=94 = Carlos.
= --Apple-Mail=_5F7419A0-8ED7-4743-8483-488B1BF867DF-- --Apple-Mail=_54959E82-5E16-4867-99D7-2079CEBFCDC2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXKghNAAoJEIXgpQGOZny9PDUP/1I8JGs1yxTKVwoC11++PcEQ 2MZqpLfixVAzc1GE7crkb5siAdgEhmWSbsDHJp7B5T0lfhg1plHGF2o84Ppa+HbT r86WPBl+yGflLLRY5c5STgPwIrlkEB82MunZYjcOHSMvilBNPKKL1taTncpz7N8n 9tgYdiD5JX7SjnUHvdJ1bmQrVlGM2Q8uCSSZCuIB7c2SD5MN5VmYf/kOw/rgU2cb x8hcKyP/P3TN4kSjVwQltiYsU50Mug2Vjdwe4/fmmC6AWAl/Kb1bLUwFDiPnPQcA Aqj59Pm6pQhbb9q8G5ix5xWPdrQd548JEEhsbcuNnaJgXcA1G7eF4esXtCn0rbdK c03p4YGxkAmuJMdXZ9i1a7j02kUVHG6Av0IvfCj8NR2/if4nt1TsMV2soRKoilpW uNpT1nPA24jlWohQRWwKABe39G/UdGDfzrm+mJ8fvjUEsA/Ka9WARp1Ttd0zP4zX CYOnFvBP22I1t12W0MF851Ea279HupCVPa0AY1k5yPrT2Z000f3TCv8y5oXOi3Lh x1mOp+Aagae4aKaTLNaen4dI3pvc0dtDAXQnbqkxz6zuE5ySWGrIi8a1+12MC2iq 8OZZJD0C79TuHp6SFDUMfnsaaIyJ4Jkd0DU4X4W4dbTMSNNGjJZTRbW9dzMbN81S PQcaHMhmgVjXvobJOEoZ =Gm92 -----END PGP SIGNATURE----- --Apple-Mail=_54959E82-5E16-4867-99D7-2079CEBFCDC2-- From nobody Wed May 4 07:42:13 2016 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 3DBAC12D6D4 for ; Wed, 4 May 2016 07:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 QCOUdwQosnuj for ; Wed, 4 May 2016 07:42:09 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DE1812D6B1 for ; Wed, 4 May 2016 07:41:39 -0700 (PDT) Received: (qmail 15975 invoked from network); 4 May 2016 16:41:37 +0200 Received: from p5dec2412.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.36.18) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 4 May 2016 16:41:37 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-b?= =?utf-8?Q?fd-seamless-base-09=3A_=28with_DISCUSS=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: <2129C9FD-F4C4-4C2D-B3E9-369A754163A4@cisco.com> Date: Wed, 4 May 2016 16:41:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160503093512.7446.68991.idtracker@ietfa.amsl.com> <1EB9BDDB-483F-48BC-9D2F-D68E6ACA285E@kuehlewind.net> <2129C9FD-F4C4-4C2D-B3E9-369A754163A4@cisco.com> To: "Carlos Pignataro (cpignata)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 14:42:11 -0000 Hi Carlos, below. > Am 04.05.2016 um 16:33 schrieb Carlos Pignataro (cpignata) = : >=20 > Thanks much for the response, Mirja! >=20 > I think we are converging, please see inline. >=20 >> On May 4, 2016, at 10:13 AM, Mirja Kuehlewind (IETF) = wrote: >>=20 >> Hi Carlos, >>=20 >> see below. >>=20 >>> Am 03.05.2016 um 19:24 schrieb Carlos Pignataro (cpignata) = : >>>=20 >>> Hi, Mirja, >>>=20 >>>> On May 3, 2016, at 12:31 PM, Mirja Kuehlewind (IETF) = wrote: >>>>=20 >>>> Hi Carlos, >>>>=20 >>>>=20 >>>>> Am 03.05.2016 um 15:40 schrieb Carlos Pignataro (cpignata) = : >>>>>=20 >>>>> Hi, Mirja, >>>>>=20 >>>>> What is an uncontrolled packet in an IP network, and what entity = controls controlled ones? :-) >>>>=20 >>>> Questions over questions=E2=80=A6 :-) >>>>=20 >>>> See below... >>>>=20 >>>>>=20 >>>>> More seriously, please see inline. >>>>>=20 >>>>>> On May 3, 2016, at 5:35 AM, Mirja Kuehlewind = wrote: >>>>>>=20 >>>>>> Mirja K=C3=BChlewind has entered the following ballot position = for >>>>>> draft-ietf-bfd-seamless-base-09: Discuss >>>>>>=20 >>>>>> When responding, please keep the subject line intact and reply to = all >>>>>> email addresses included in the To and CC lines. (Feel free to = cut this >>>>>> introductory paragraph, however.) >>>>>>=20 >>>>>>=20 >>>>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>=20 >>>>>>=20 >>>>>> The document, along with other ballot positions, can be found = here: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> = ---------------------------------------------------------------------- >>>>>> DISCUSS: >>>>>> = ---------------------------------------------------------------------- >>>>>>=20 >>>>>> As S-BFD has no initiation process anymore it is not guarenteed = that the >>>>>> receiver/responder actually exists. That means that packets could = float >>>>>> (uncontrolled) in the network or even outside of the = adminstrative domain >>>>>> (e.g. due to configuration mistakes). =46rom my point of view = this document >>>>>> should recommend/require two things: >>>>>>=20 >>>>>=20 >>>>> We have called out the misconfiguration =E2=80=94 however: >>>>>=20 >>>>>> 1) A maximum number of S-BFD packet that is allow to be send = without >>>>>> getting a response (maybe leading to a local error report). >>>>>>=20 >>>>>=20 >>>>> This can result in a deadlock situation, if an S-BFD Reflector is = enabled much later. I=E2=80=99m very hesitant to cap the packets sent. = We can, and I think it is useful, MAY log an error for multiple = timeouts. >>>>=20 >>>> Okay, I understand that a hard limit probably does make sense. An = error log seems definitely useful. >>>=20 >>> OK, that sounds good. See below. >>>=20 >>>> Another proposal for consideration: Currently the draft says an = initiator should only send one packet per second if the target is in = ADMINDOWN state. In this case there this state is explicit announced. = However if the other end just disappears or was never/not yet there, one = could use an exponential back off instead, starting with a smaller = intervals than one second but then increase it exponentially. Just an = idea... >>>=20 >>> Thanks for the proposal. Please have in mind however that this is a = protocol for detecting liveness (and lack of it), so increasing = exponentially defeats the purpose. >>>=20 >>> Further, exponential back off may not be the best choice when = interacting with routing protocols. >>>=20 >>> What we currently say is: >>> The criteria for declaring loss of >>> reachability and the action that would be triggered as a result >>> are outside the scope of this document. >>>=20 >>> As much of these are implementation choices. >>>=20 >>> But we can add at the end =E2=80=9C, and MAY include logging an = error.=E2=80=9C >>=20 >> Please do so. >=20 > Done. >=20 >>=20 >>>>=20 >>>>>=20 >>>>>> 2) Egress filtering at the adminstrative border of the domain = that uses >>>>>> S-BFD to make sure that no S-BFD packets leave the domain. >>>>>>=20 >>>>>=20 >>>>> This is no different than any other application that uses UDP; a = misconfigured DNS server will result in the same, and a traceroute is = also not too different. This seems too onerous of a requirement. An = administrative domain filters at ingress. >>>>=20 >>>> First of all, just because other protocols might have such a = problem, that does mean it=E2=80=99s okay. >>>=20 >>> I agree with this. I had a different point in mind though =E2=80=94 = trying to specify this on every UDP application might not be the most = effective way. Perhaps there=E2=80=99s a UDP guideline you are = uncovering. >>>=20 >>>> However, correctly me if I=E2=80=99m wrong, but there the situation = seems slightly different because there is no termination criterium at = all that means an s-bfd node would send useless data forever (=E2=80=A6 = until manual change of the config). >>>>=20 >>>=20 >>> But as far as this doc is concerned, let me try to make some = clarifications (and a correction). >>>=20 >>> There are termination criteria =E2=80=94 the document says: >>>=20 >>> An SBFDInitiator may be a persistent session on the initiator with = a >>> timer for S-BFD control packet transmissions (stateful >>> SBFDInitiator). An SBFDInitiator may also be a module, a script or = a >>> tool on the initiator that transmits one or more S-BFD control >>> packets "when needed" (stateless SBFDInitiator). >>>=20 >>> For the case in which you have a =E2=80=9Cwhen needed=E2=80=9D = SBFDInitiator, the workflow is like a =E2=80=9Cping=E2=80=9D. >>>=20 >>> For the case in which you have a =E2=80=9Cpersistent" SBFDInitiator, = in theory this can run forever (for some value of ever). However, please = don=E2=80=99t loose track of why this protocol exists. Having OAM = failures and do nothing about it defeats the purpose of having OAM. = Meaning, a red alarm will blink, a honk will horn, and the config state = will be changed (manually or by some support system). >>>=20 >>> In other words, I do not think this is such a unique case (insofar = as running ad-infinutum). >>=20 >> I still believe that the case where you have a misconfiguration and = the initiator sends packets (forever) but never ever gest a reply (and = never has seen a reply in the past), is a different case and can be = detected and handled separately. >>=20 >=20 > Again, I would not qualify this as =E2=80=98forever=E2=80=99, but I = understand what you mean. >=20 >>>=20 >>>> I still believe that egress filtering would be more appropriate = here (than ingress) because the domain that is using s-bfd knows about = it and therefor can set up the respective filters and should not spam = others while hoping that filters are in place. >>>>=20 >>>=20 >>> To me, there is no insignificant operational complexity with = requiring the addition of filters throughout, for one particular = application not leaking (where the leak does not cause anything = special), and when the leak might happen because of a misconfiguration = (or bug) but will be detected by the operational support systems. The = ROI does not seem to add up. >>=20 >> Okay the document should probably not require egress filtering in any = case but what=E2=80=99s about saying something like: >>=20 >> =E2=80=9EIf S-BFD is used it SHOULD be ensured that S-BFD control = packet do not propagate outside of the administrative domain that uses = it.=E2=80=9C >>=20 >=20 > We can add an additional explanation of the problem before a = statement, but I do not think that particular SHOULD is actionable. = How=E2=80=99s something like: >=20 > Explain that without handshake, a persistent initiator can send = blindly, to then add =E2=80=9CIn such case, operational measures SHOULD = be taken to identify if S-BFD packets are not responded to for an = extended period of time, and remediate the situation=E2=80=9D >=20 >> This is not an uncommon thing to specify also for other protocols. >>=20 >=20 > I agree. Frankly, I am happy with either statement, but I think the = latter might be more operationally actionable. >=20 > Preference? I still would prefer something in the line as I proposed. I think there = could effectively be different action to be taken here, e.g. agree = filtering or measurement to detect failure, as well as no action if for = some other reason it can be ensure that should a misconfiguration can = not happen (or is at least very unlikely to happen) e.g because things = are automated and there are additional checks before apply a config. The second SHOULD that you proposed is from my point of view actually an = additional point that I would also be happy to see in the doc. Mirja >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >> Mirja >>=20 >>=20 >>>=20 >>> Does the explanation of the termination criteria help? >>>=20 >>>>>=20 >>>>> Seems to me the logging will alert someone/something to take = action, and should be enough. >>>>=20 >>>> Logging plus alerts is definitely a good thing. >>>>=20 >>>=20 >>> I agree. >>>=20 >>> Will add =E2=80=9C, and MAY include logging an error.=E2=80=9D as = per above. >>>=20 >>> Do you think we should expand on this somewhere else in the = document? >>>=20 >>> Thanks, >>>=20 >>> =E2=80=94 Carlos. >>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>>=20 >>>>> Thoughts? >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> =E2=80=94 Carlos. >=20 From nobody Wed May 4 08:15:26 2016 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 3493312D515; Wed, 4 May 2016 08:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 DPu9O9gfa9dq; Wed, 4 May 2016 08:15:17 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD0C612D6BB; Wed, 4 May 2016 08:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12067; q=dns/txt; s=iport; t=1462374810; x=1463584410; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DQDxQ3xbU6yb4b5FTAyZGMs7tDDAHg/Rqj7iqxyb7xU=; b=F1cZPK3h9VLUBupcr1o/QN29ZqaPUItdqxUCkiv2KHvzCygFLZzcyV2Y g3Asb75kx5rsfC93An8fY7kgP5Hik5HDijxHeVJ8wjv4q6qhNUuh0reAu fJDZUsiEGe7oZ6ioyA4re0nAJ4RZDrR/tsKPoUC/QXLVv/jtXKvdqBekv o=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvAwA4ESpX/40NJK1UCoM4Uy0BTwa1N?= =?us-ascii?q?IIfgg8OgXUihW4CgTQ4FAEBAQEBAQFlJ4RBAQEBAwEjVgULAgEIGCoCAjIaCwI?= =?us-ascii?q?EDgUOiBQIDqw2kQoBAQEBAQEBAQEBAQEBAQEBAQEBDwQEhiCBdoJXhBEGBQYBB?= =?us-ascii?q?kiCTiuCLgWHeJAhAYMngWdtiByBaIRNiF6JQoVxAR4BQ4I2gTVsAYZ+CBcffwE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.24,577,1454976000"; d="asc'?scan'208";a="268736121" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 May 2016 15:13:29 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u44FDT32010191 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 May 2016 15:13:29 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 May 2016 11:13:28 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Wed, 4 May 2016 11:13:28 -0400 From: "Carlos Pignataro (cpignata)" To: "Mirja Kuehlewind (IETF)" Subject: =?utf-8?B?UmU6IE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt?= =?utf-8?Q?bfd-seamless-base-09:_(with_DISCUSS)?= Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1iZmQt?= =?utf-8?Q?seamless-base-09:_(with_DISCUSS)?= Thread-Index: AQHRpR8YB75iFhnPVECZQ0i//enE0Z+ne5KAgAAvsACAAA7wAIABXPwAgAAFk4CAAAIzgIAACOEA Date: Wed, 4 May 2016 15:13:28 +0000 Message-ID: <7E0A3ABF-1C32-43D1-BC9B-E42BDB3090AB@cisco.com> References: <20160503093512.7446.68991.idtracker@ietfa.amsl.com> <1EB9BDDB-483F-48BC-9D2F-D68E6ACA285E@kuehlewind.net> <2129C9FD-F4C4-4C2D-B3E9-369A754163A4@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.49.250] Content-Type: multipart/signed; boundary="Apple-Mail=_E2582169-FCAC-4CEF-8FED-71675E06B647"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 15:15:20 -0000 --Apple-Mail=_E2582169-FCAC-4CEF-8FED-71675E06B647 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Mirja, > On May 4, 2016, at 10:41 AM, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi Carlos, >=20 > below. >=20 >> Am 04.05.2016 um 16:33 schrieb Carlos Pignataro (cpignata) = : >>=20 >> Thanks much for the response, Mirja! >>=20 >> I think we are converging, please see inline. >>=20 >>> On May 4, 2016, at 10:13 AM, Mirja Kuehlewind (IETF) = wrote: >>>=20 >>> Hi Carlos, >>>=20 >>> see below. >>>=20 >>>> Am 03.05.2016 um 19:24 schrieb Carlos Pignataro (cpignata) = : >>>>=20 >>>> Hi, Mirja, >>>>=20 >>>>> On May 3, 2016, at 12:31 PM, Mirja Kuehlewind (IETF) = wrote: >>>>>=20 >>>>> Hi Carlos, >>>>>=20 >>>>>=20 >>>>>> Am 03.05.2016 um 15:40 schrieb Carlos Pignataro (cpignata) = : >>>>>>=20 >>>>>> Hi, Mirja, >>>>>>=20 >>>>>> What is an uncontrolled packet in an IP network, and what entity = controls controlled ones? :-) >>>>>=20 >>>>> Questions over questions=E2=80=A6 :-) >>>>>=20 >>>>> See below... >>>>>=20 >>>>>>=20 >>>>>> More seriously, please see inline. >>>>>>=20 >>>>>>> On May 3, 2016, at 5:35 AM, Mirja Kuehlewind = wrote: >>>>>>>=20 >>>>>>> Mirja K=C3=BChlewind has entered the following ballot position = for >>>>>>> draft-ietf-bfd-seamless-base-09: Discuss >>>>>>>=20 >>>>>>> When responding, please keep the subject line intact and reply = to all >>>>>>> email addresses included in the To and CC lines. (Feel free to = cut this >>>>>>> introductory paragraph, however.) >>>>>>>=20 >>>>>>>=20 >>>>>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>>=20 >>>>>>>=20 >>>>>>> The document, along with other ballot positions, can be found = here: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> = ---------------------------------------------------------------------- >>>>>>> DISCUSS: >>>>>>> = ---------------------------------------------------------------------- >>>>>>>=20 >>>>>>> As S-BFD has no initiation process anymore it is not guarenteed = that the >>>>>>> receiver/responder actually exists. That means that packets = could float >>>>>>> (uncontrolled) in the network or even outside of the = adminstrative domain >>>>>>> (e.g. due to configuration mistakes). =46rom my point of view = this document >>>>>>> should recommend/require two things: >>>>>>>=20 >>>>>>=20 >>>>>> We have called out the misconfiguration =E2=80=94 however: >>>>>>=20 >>>>>>> 1) A maximum number of S-BFD packet that is allow to be send = without >>>>>>> getting a response (maybe leading to a local error report). >>>>>>>=20 >>>>>>=20 >>>>>> This can result in a deadlock situation, if an S-BFD Reflector is = enabled much later. I=E2=80=99m very hesitant to cap the packets sent. = We can, and I think it is useful, MAY log an error for multiple = timeouts. >>>>>=20 >>>>> Okay, I understand that a hard limit probably does make sense. An = error log seems definitely useful. >>>>=20 >>>> OK, that sounds good. See below. >>>>=20 >>>>> Another proposal for consideration: Currently the draft says an = initiator should only send one packet per second if the target is in = ADMINDOWN state. In this case there this state is explicit announced. = However if the other end just disappears or was never/not yet there, one = could use an exponential back off instead, starting with a smaller = intervals than one second but then increase it exponentially. Just an = idea... >>>>=20 >>>> Thanks for the proposal. Please have in mind however that this is a = protocol for detecting liveness (and lack of it), so increasing = exponentially defeats the purpose. >>>>=20 >>>> Further, exponential back off may not be the best choice when = interacting with routing protocols. >>>>=20 >>>> What we currently say is: >>>> The criteria for declaring loss of >>>> reachability and the action that would be triggered as a result >>>> are outside the scope of this document. >>>>=20 >>>> As much of these are implementation choices. >>>>=20 >>>> But we can add at the end =E2=80=9C, and MAY include logging an = error.=E2=80=9C >>>=20 >>> Please do so. >>=20 >> Done. >>=20 >>>=20 >>>>>=20 >>>>>>=20 >>>>>>> 2) Egress filtering at the adminstrative border of the domain = that uses >>>>>>> S-BFD to make sure that no S-BFD packets leave the domain. >>>>>>>=20 >>>>>>=20 >>>>>> This is no different than any other application that uses UDP; a = misconfigured DNS server will result in the same, and a traceroute is = also not too different. This seems too onerous of a requirement. An = administrative domain filters at ingress. >>>>>=20 >>>>> First of all, just because other protocols might have such a = problem, that does mean it=E2=80=99s okay. >>>>=20 >>>> I agree with this. I had a different point in mind though =E2=80=94 = trying to specify this on every UDP application might not be the most = effective way. Perhaps there=E2=80=99s a UDP guideline you are = uncovering. >>>>=20 >>>>> However, correctly me if I=E2=80=99m wrong, but there the = situation seems slightly different because there is no termination = criterium at all that means an s-bfd node would send useless data = forever (=E2=80=A6 until manual change of the config). >>>>>=20 >>>>=20 >>>> But as far as this doc is concerned, let me try to make some = clarifications (and a correction). >>>>=20 >>>> There are termination criteria =E2=80=94 the document says: >>>>=20 >>>> An SBFDInitiator may be a persistent session on the initiator with = a >>>> timer for S-BFD control packet transmissions (stateful >>>> SBFDInitiator). An SBFDInitiator may also be a module, a script or = a >>>> tool on the initiator that transmits one or more S-BFD control >>>> packets "when needed" (stateless SBFDInitiator). >>>>=20 >>>> For the case in which you have a =E2=80=9Cwhen needed=E2=80=9D = SBFDInitiator, the workflow is like a =E2=80=9Cping=E2=80=9D. >>>>=20 >>>> For the case in which you have a =E2=80=9Cpersistent" = SBFDInitiator, in theory this can run forever (for some value of ever). = However, please don=E2=80=99t loose track of why this protocol exists. = Having OAM failures and do nothing about it defeats the purpose of = having OAM. Meaning, a red alarm will blink, a honk will horn, and the = config state will be changed (manually or by some support system). >>>>=20 >>>> In other words, I do not think this is such a unique case (insofar = as running ad-infinutum). >>>=20 >>> I still believe that the case where you have a misconfiguration and = the initiator sends packets (forever) but never ever gest a reply (and = never has seen a reply in the past), is a different case and can be = detected and handled separately. >>>=20 >>=20 >> Again, I would not qualify this as =E2=80=98forever=E2=80=99, but I = understand what you mean. >>=20 >>>>=20 >>>>> I still believe that egress filtering would be more appropriate = here (than ingress) because the domain that is using s-bfd knows about = it and therefor can set up the respective filters and should not spam = others while hoping that filters are in place. >>>>>=20 >>>>=20 >>>> To me, there is no insignificant operational complexity with = requiring the addition of filters throughout, for one particular = application not leaking (where the leak does not cause anything = special), and when the leak might happen because of a misconfiguration = (or bug) but will be detected by the operational support systems. The = ROI does not seem to add up. >>>=20 >>> Okay the document should probably not require egress filtering in = any case but what=E2=80=99s about saying something like: >>>=20 >>> =E2=80=9EIf S-BFD is used it SHOULD be ensured that S-BFD control = packet do not propagate outside of the administrative domain that uses = it.=E2=80=9C >>>=20 >>=20 >> We can add an additional explanation of the problem before a = statement, but I do not think that particular SHOULD is actionable. = How=E2=80=99s something like: >>=20 >> Explain that without handshake, a persistent initiator can send = blindly, to then add =E2=80=9CIn such case, operational measures SHOULD = be taken to identify if S-BFD packets are not responded to for an = extended period of time, and remediate the situation=E2=80=9D >>=20 >>> This is not an uncommon thing to specify also for other protocols. >>>=20 >>=20 >> I agree. Frankly, I am happy with either statement, but I think the = latter might be more operationally actionable. >>=20 >> Preference? >=20 > I still would prefer something in the line as I proposed. I think = there could effectively be different action to be taken here, e.g. = agree filtering or measurement to detect failure, as well as no action = if for some other reason it can be ensure that should a misconfiguration = can not happen (or is at least very unlikely to happen) e.g because = things are automated and there are additional checks before apply a = config. >=20 Perhaps I can add =E2=80=9Cfor an extended period of time=E2=80=9D to = the first statement (or similar wording of your liking)? Your main concern is the =E2=80=9Cforever=E2=80=9D. Let=E2=80=99s ensure = it is not =E2=80=9Cforever=E2=80=9D. However, I=E2=80=99m concerned that = a single packet out (like a ping to the wrong address) will be violating = =E2=80=9C it SHOULD be ensured that S-BFD control packet do not = propagate outside=E2=80=9D Would that work? Thanks, =E2=80=94 Carlos. > The second SHOULD that you proposed is from my point of view actually = an additional point that I would also be happy to see in the doc. >=20 > Mirja >=20 >=20 >>=20 >> Thanks, >>=20 >> =E2=80=94 Carlos. >>=20 >>> Mirja >>>=20 >>>=20 >>>>=20 >>>> Does the explanation of the termination criteria help? >>>>=20 >>>>>>=20 >>>>>> Seems to me the logging will alert someone/something to take = action, and should be enough. >>>>>=20 >>>>> Logging plus alerts is definitely a good thing. >>>>>=20 >>>>=20 >>>> I agree. >>>>=20 >>>> Will add =E2=80=9C, and MAY include logging an error.=E2=80=9D as = per above. >>>>=20 >>>> Do you think we should expand on this somewhere else in the = document? >>>>=20 >>>> Thanks, >>>>=20 >>>> =E2=80=94 Carlos. >>>>=20 >>>>> Mirja >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Thoughts? >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> =E2=80=94 Carlos. >>=20 >=20 --Apple-Mail=_E2582169-FCAC-4CEF-8FED-71675E06B647 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXKhGYAAoJEIXgpQGOZny9uEsQAIyxwWSQJLgv3B71GnIct0VD jOnG4Ib0f3RQa+aJlo8eMYe5vkVtxdYyNvUASWwBhoEcMwWHFnt+Pe4uSfIP0EB3 fU75OSy7aOCLQIuy67DJnyt37L3NRFxky2WLWLHXvfaigLuEfxq1QUCyp2IelkrK Pd1iBj3CMG96Y2yOgZCxIFZyBdaeJ6cszVoYR4zTL7YQA10G3NzB/YbFKaeCUr6B +rf7ostYmUhqSjSHbG+arpUW9c31eMtXiGbIJKDgBJkvPN3OY7mZP6+9YOIkzV11 wwRtPj/MPVKCeMvKwihEEcKOj+8kc7QGnSnzRltaTxMm1eIzpTmu04t/5D22N7HE 1xvlR0hYJZ57BG5ykA8wKoV1946OtWoCFbLwkXMs2ksk8NnUYXVBOEk+mkyebvYb /KYEzXR6C4nFSxVoR/hxqJ9k83t+38Ao94991lLR6eFNoAxD9m6OYiEpquvUz4Ja TCFwDV/Zw+eeWqpvvVDrnrNzvsF49zUyRDwk5hcjV7YG3ScAuTlObFTnQbHyb2WX 924ziBKmIFN6xPIkHj6ESS0e0Q7JJIkOFpa2OlI4e5qhbLicteeBRM/TCFkqoWqS jnEKWyeJTsfwS6UlE/meJS7PT9EHKRXn4gsRlybHzklCEMTjn0PwLP4eE9ZeGRs9 Trn0FDL3z+EE7Opi30+Z =5yb5 -----END PGP SIGNATURE----- --Apple-Mail=_E2582169-FCAC-4CEF-8FED-71675E06B647-- From nobody Wed May 4 08:41:00 2016 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 3D6E412D7B9 for ; Wed, 4 May 2016 08:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 8GCcZm8fee3i for ; Wed, 4 May 2016 08:40:54 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D7012D7C2 for ; Wed, 4 May 2016 08:35:45 -0700 (PDT) Received: (qmail 18009 invoked from network); 4 May 2016 17:29:01 +0200 Received: from p5dec2412.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.36.18) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 4 May 2016 17:29:01 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-b?= =?utf-8?Q?fd-seamless-base-09=3A_=28with_DISCUSS=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: <7E0A3ABF-1C32-43D1-BC9B-E42BDB3090AB@cisco.com> Date: Wed, 4 May 2016 17:29:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4C6B695B-D796-464D-ACCC-74BADD577F32@kuehlewind.net> References: <20160503093512.7446.68991.idtracker@ietfa.amsl.com> <1EB9BDDB-483F-48BC-9D2F-D68E6ACA285E@kuehlewind.net> <2129C9FD-F4C4-4C2D-B3E9-369A754163A4@cisco.com> <7E0A3ABF-1C32-43D1-BC9B-E42BDB3090AB@cisco.com> To: "Carlos Pignataro (cpignata)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 15:40:56 -0000 Hi Carlos, > Am 04.05.2016 um 17:13 schrieb Carlos Pignataro (cpignata) = : >=20 > Hi, Mirja, >=20 >> On May 4, 2016, at 10:41 AM, Mirja Kuehlewind (IETF) = wrote: >>=20 >> Hi Carlos, >>=20 >> below. >>=20 >>> Am 04.05.2016 um 16:33 schrieb Carlos Pignataro (cpignata) = : >>>=20 >>> Thanks much for the response, Mirja! >>>=20 >>> I think we are converging, please see inline. >>>=20 >>>> On May 4, 2016, at 10:13 AM, Mirja Kuehlewind (IETF) = wrote: >>>>=20 >>>> Hi Carlos, >>>>=20 >>>> see below. >>>>=20 >>>>> Am 03.05.2016 um 19:24 schrieb Carlos Pignataro (cpignata) = : >>>>>=20 >>>>> Hi, Mirja, >>>>>=20 >>>>>> On May 3, 2016, at 12:31 PM, Mirja Kuehlewind (IETF) = wrote: >>>>>>=20 >>>>>> Hi Carlos, >>>>>>=20 >>>>>>=20 >>>>>>> Am 03.05.2016 um 15:40 schrieb Carlos Pignataro (cpignata) = : >>>>>>>=20 >>>>>>> Hi, Mirja, >>>>>>>=20 >>>>>>> What is an uncontrolled packet in an IP network, and what entity = controls controlled ones? :-) >>>>>>=20 >>>>>> Questions over questions=E2=80=A6 :-) >>>>>>=20 >>>>>> See below... >>>>>>=20 >>>>>>>=20 >>>>>>> More seriously, please see inline. >>>>>>>=20 >>>>>>>> On May 3, 2016, at 5:35 AM, Mirja Kuehlewind = wrote: >>>>>>>>=20 >>>>>>>> Mirja K=C3=BChlewind has entered the following ballot position = for >>>>>>>> draft-ietf-bfd-seamless-base-09: Discuss >>>>>>>>=20 >>>>>>>> When responding, please keep the subject line intact and reply = to all >>>>>>>> email addresses included in the To and CC lines. (Feel free to = cut this >>>>>>>> introductory paragraph, however.) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The document, along with other ballot positions, can be found = here: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> = ---------------------------------------------------------------------- >>>>>>>> DISCUSS: >>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>=20 >>>>>>>> As S-BFD has no initiation process anymore it is not guarenteed = that the >>>>>>>> receiver/responder actually exists. That means that packets = could float >>>>>>>> (uncontrolled) in the network or even outside of the = adminstrative domain >>>>>>>> (e.g. due to configuration mistakes). =46rom my point of view = this document >>>>>>>> should recommend/require two things: >>>>>>>>=20 >>>>>>>=20 >>>>>>> We have called out the misconfiguration =E2=80=94 however: >>>>>>>=20 >>>>>>>> 1) A maximum number of S-BFD packet that is allow to be send = without >>>>>>>> getting a response (maybe leading to a local error report). >>>>>>>>=20 >>>>>>>=20 >>>>>>> This can result in a deadlock situation, if an S-BFD Reflector = is enabled much later. I=E2=80=99m very hesitant to cap the packets = sent. We can, and I think it is useful, MAY log an error for multiple = timeouts. >>>>>>=20 >>>>>> Okay, I understand that a hard limit probably does make sense. An = error log seems definitely useful. >>>>>=20 >>>>> OK, that sounds good. See below. >>>>>=20 >>>>>> Another proposal for consideration: Currently the draft says an = initiator should only send one packet per second if the target is in = ADMINDOWN state. In this case there this state is explicit announced. = However if the other end just disappears or was never/not yet there, one = could use an exponential back off instead, starting with a smaller = intervals than one second but then increase it exponentially. Just an = idea... >>>>>=20 >>>>> Thanks for the proposal. Please have in mind however that this is = a protocol for detecting liveness (and lack of it), so increasing = exponentially defeats the purpose. >>>>>=20 >>>>> Further, exponential back off may not be the best choice when = interacting with routing protocols. >>>>>=20 >>>>> What we currently say is: >>>>> The criteria for declaring loss of >>>>> reachability and the action that would be triggered as a result >>>>> are outside the scope of this document. >>>>>=20 >>>>> As much of these are implementation choices. >>>>>=20 >>>>> But we can add at the end =E2=80=9C, and MAY include logging an = error.=E2=80=9C >>>>=20 >>>> Please do so. >>>=20 >>> Done. >>>=20 >>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>> 2) Egress filtering at the adminstrative border of the domain = that uses >>>>>>>> S-BFD to make sure that no S-BFD packets leave the domain. >>>>>>>>=20 >>>>>>>=20 >>>>>>> This is no different than any other application that uses UDP; a = misconfigured DNS server will result in the same, and a traceroute is = also not too different. This seems too onerous of a requirement. An = administrative domain filters at ingress. >>>>>>=20 >>>>>> First of all, just because other protocols might have such a = problem, that does mean it=E2=80=99s okay. >>>>>=20 >>>>> I agree with this. I had a different point in mind though =E2=80=94 = trying to specify this on every UDP application might not be the most = effective way. Perhaps there=E2=80=99s a UDP guideline you are = uncovering. >>>>>=20 >>>>>> However, correctly me if I=E2=80=99m wrong, but there the = situation seems slightly different because there is no termination = criterium at all that means an s-bfd node would send useless data = forever (=E2=80=A6 until manual change of the config). >>>>>>=20 >>>>>=20 >>>>> But as far as this doc is concerned, let me try to make some = clarifications (and a correction). >>>>>=20 >>>>> There are termination criteria =E2=80=94 the document says: >>>>>=20 >>>>> An SBFDInitiator may be a persistent session on the initiator with = a >>>>> timer for S-BFD control packet transmissions (stateful >>>>> SBFDInitiator). An SBFDInitiator may also be a module, a script = or a >>>>> tool on the initiator that transmits one or more S-BFD control >>>>> packets "when needed" (stateless SBFDInitiator). >>>>>=20 >>>>> For the case in which you have a =E2=80=9Cwhen needed=E2=80=9D = SBFDInitiator, the workflow is like a =E2=80=9Cping=E2=80=9D. >>>>>=20 >>>>> For the case in which you have a =E2=80=9Cpersistent" = SBFDInitiator, in theory this can run forever (for some value of ever). = However, please don=E2=80=99t loose track of why this protocol exists. = Having OAM failures and do nothing about it defeats the purpose of = having OAM. Meaning, a red alarm will blink, a honk will horn, and the = config state will be changed (manually or by some support system). >>>>>=20 >>>>> In other words, I do not think this is such a unique case (insofar = as running ad-infinutum). >>>>=20 >>>> I still believe that the case where you have a misconfiguration and = the initiator sends packets (forever) but never ever gest a reply (and = never has seen a reply in the past), is a different case and can be = detected and handled separately. >>>>=20 >>>=20 >>> Again, I would not qualify this as =E2=80=98forever=E2=80=99, but I = understand what you mean. >>>=20 >>>>>=20 >>>>>> I still believe that egress filtering would be more appropriate = here (than ingress) because the domain that is using s-bfd knows about = it and therefor can set up the respective filters and should not spam = others while hoping that filters are in place. >>>>>>=20 >>>>>=20 >>>>> To me, there is no insignificant operational complexity with = requiring the addition of filters throughout, for one particular = application not leaking (where the leak does not cause anything = special), and when the leak might happen because of a misconfiguration = (or bug) but will be detected by the operational support systems. The = ROI does not seem to add up. >>>>=20 >>>> Okay the document should probably not require egress filtering in = any case but what=E2=80=99s about saying something like: >>>>=20 >>>> =E2=80=9EIf S-BFD is used it SHOULD be ensured that S-BFD control = packet do not propagate outside of the administrative domain that uses = it.=E2=80=9C >>>>=20 >>>=20 >>> We can add an additional explanation of the problem before a = statement, but I do not think that particular SHOULD is actionable. = How=E2=80=99s something like: >>>=20 >>> Explain that without handshake, a persistent initiator can send = blindly, to then add =E2=80=9CIn such case, operational measures SHOULD = be taken to identify if S-BFD packets are not responded to for an = extended period of time, and remediate the situation=E2=80=9D >>>=20 >>>> This is not an uncommon thing to specify also for other protocols. >>>>=20 >>>=20 >>> I agree. Frankly, I am happy with either statement, but I think the = latter might be more operationally actionable. >>>=20 >>> Preference? >>=20 >> I still would prefer something in the line as I proposed. I think = there could effectively be different action to be taken here, e.g. = agree filtering or measurement to detect failure, as well as no action = if for some other reason it can be ensure that should a misconfiguration = can not happen (or is at least very unlikely to happen) e.g because = things are automated and there are additional checks before apply a = config. >>=20 >=20 > Perhaps I can add =E2=80=9Cfor an extended period of time=E2=80=9D to = the first statement (or similar wording of your liking)? >=20 > Your main concern is the =E2=80=9Cforever=E2=80=9D. Let=E2=80=99s = ensure it is not =E2=80=9Cforever=E2=80=9D. However, I=E2=80=99m = concerned that a single packet out (like a ping to the wrong address) = will be violating =E2=80=9C it SHOULD be ensured that S-BFD control = packet do not propagate outside=E2=80=9D The concern it not =E2=80=9Eforever=E2=80=9C but putting (unnecessary) = load on other network (by accident). So I agree, one or a few packets is = not a problem. So yes, adding =E2=80=9Cfor an extended period of time=E2=80= =9D is fine. We could also/instead exchange the word =E2=80=9Eensure=E2=80= =9C by something else (maybe =E2=80=9Econtrol=E2=80=9C=E2=80=A6?). Mirja >=20 > Would that work? >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >> The second SHOULD that you proposed is from my point of view actually = an additional point that I would also be happy to see in the doc. >>=20 >> Mirja >>=20 >>=20 >>>=20 >>> Thanks, >>>=20 >>> =E2=80=94 Carlos. >>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>>=20 >>>>> Does the explanation of the termination criteria help? >>>>>=20 >>>>>>>=20 >>>>>>> Seems to me the logging will alert someone/something to take = action, and should be enough. >>>>>>=20 >>>>>> Logging plus alerts is definitely a good thing. >>>>>>=20 >>>>>=20 >>>>> I agree. >>>>>=20 >>>>> Will add =E2=80=9C, and MAY include logging an error.=E2=80=9D as = per above. >>>>>=20 >>>>> Do you think we should expand on this somewhere else in the = document? >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> =E2=80=94 Carlos. >>>>>=20 >>>>>> Mirja >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Thoughts? >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> =E2=80=94 Carlos. >>>=20 >>=20 >=20 From nobody Wed May 4 08:50:26 2016 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 15CAF12D7EB; Wed, 4 May 2016 08:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 0ZC5Z9yYCdFP; Wed, 4 May 2016 08:50:21 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94BAD12D7E9; Wed, 4 May 2016 08:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35631; q=dns/txt; s=iport; t=1462376699; x=1463586299; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QTEluT10eJ3z3bvPOkEQ+d+xQMdIXlm8lUD3u9U/fsg=; b=WoqmsDEpQvZIPXaynsUpFIPdf3RsrOimF41mp31lk3ETmLQ8MPyfUgXL Ag50zBzgporyZuvpQw80b9erg6DhiIM+n5wA6qT7nefllj3ssagiF9INE +KK2+1dKfsrguzk4b/Nujf72vK0spPdfIVu82Zc4G7ztYzRaP0GpW0Gtg E=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAwB7GCpX/4wNJK1UCoJsTFMtAU8Gt?= =?us-ascii?q?TSCH4IPDoF1IoVuAoE1OBQBAQEBAQEBZSeEQQEBAQMBGglWBQsCAQYCGCAKAgI?= =?us-ascii?q?yGgsCBA4FDogUCA6PDJ0dkQUBAQEBAQEBAQEBAQEBAQEBAQEBAQENBASGIIF2g?= =?us-ascii?q?leEEQYFBgEGgxYrgi4Fh3iLLIR1AYMngWdtiByBaIRNiF6JQoVxAR4BQ4I2gTV?= =?us-ascii?q?sAYZ+CBcffwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,577,1454976000"; d="asc'?scan'208,217";a="269679620" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 May 2016 15:44:58 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u44Fivqi010406 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 May 2016 15:44:57 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 May 2016 11:44:56 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Wed, 4 May 2016 11:44:56 -0400 From: "Carlos Pignataro (cpignata)" To: "Mirja Kuehlewind (IETF)" Subject: =?utf-8?B?UmU6IE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt?= =?utf-8?Q?bfd-seamless-base-09:_(with_DISCUSS)?= Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1iZmQt?= =?utf-8?Q?seamless-base-09:_(with_DISCUSS)?= Thread-Index: AQHRpR8YB75iFhnPVECZQ0i//enE0Z+ne5KAgAAvsACAAA7wAIABXPwAgAAFk4CAAAIzgIAACOEAgAAEXYCAAARuAA== Date: Wed, 4 May 2016 15:44:56 +0000 Message-ID: References: <20160503093512.7446.68991.idtracker@ietfa.amsl.com> <1EB9BDDB-483F-48BC-9D2F-D68E6ACA285E@kuehlewind.net> <2129C9FD-F4C4-4C2D-B3E9-369A754163A4@cisco.com> <7E0A3ABF-1C32-43D1-BC9B-E42BDB3090AB@cisco.com> <4C6B695B-D796-464D-ACCC-74BADD577F32@kuehlewind.net> In-Reply-To: <4C6B695B-D796-464D-ACCC-74BADD577F32@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.49.250] Content-Type: multipart/signed; boundary="Apple-Mail=_CF5939F7-197A-4D65-8EDB-D6900468ADF5"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 15:50:25 -0000 --Apple-Mail=_CF5939F7-197A-4D65-8EDB-D6900468ADF5 Content-Type: multipart/alternative; boundary="Apple-Mail=_8521C713-AA43-415A-ADC4-BC80F447B630" --Apple-Mail=_8521C713-AA43-415A-ADC4-BC80F447B630 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Mirja, > On May 4, 2016, at 11:29 AM, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi Carlos, >=20 >> Am 04.05.2016 um 17:13 schrieb Carlos Pignataro (cpignata) = : >>=20 >> Hi, Mirja, >>=20 >>> On May 4, 2016, at 10:41 AM, Mirja Kuehlewind (IETF) = wrote: >>>=20 >>> Hi Carlos, >>>=20 >>> below. >>>=20 >>>> Am 04.05.2016 um 16:33 schrieb Carlos Pignataro (cpignata) = : >>>>=20 >>>> Thanks much for the response, Mirja! >>>>=20 >>>> I think we are converging, please see inline. >>>>=20 >>>>> On May 4, 2016, at 10:13 AM, Mirja Kuehlewind (IETF) = wrote: >>>>>=20 >>>>> Hi Carlos, >>>>>=20 >>>>> see below. >>>>>=20 >>>>>> Am 03.05.2016 um 19:24 schrieb Carlos Pignataro (cpignata) = : >>>>>>=20 >>>>>> Hi, Mirja, >>>>>>=20 >>>>>>> On May 3, 2016, at 12:31 PM, Mirja Kuehlewind (IETF) = wrote: >>>>>>>=20 >>>>>>> Hi Carlos, >>>>>>>=20 >>>>>>>=20 >>>>>>>> Am 03.05.2016 um 15:40 schrieb Carlos Pignataro (cpignata) = : >>>>>>>>=20 >>>>>>>> Hi, Mirja, >>>>>>>>=20 >>>>>>>> What is an uncontrolled packet in an IP network, and what = entity controls controlled ones? :-) >>>>>>>=20 >>>>>>> Questions over questions=E2=80=A6 :-) >>>>>>>=20 >>>>>>> See below... >>>>>>>=20 >>>>>>>>=20 >>>>>>>> More seriously, please see inline. >>>>>>>>=20 >>>>>>>>> On May 3, 2016, at 5:35 AM, Mirja Kuehlewind = wrote: >>>>>>>>>=20 >>>>>>>>> Mirja K=C3=BChlewind has entered the following ballot position = for >>>>>>>>> draft-ietf-bfd-seamless-base-09: Discuss >>>>>>>>>=20 >>>>>>>>> When responding, please keep the subject line intact and reply = to all >>>>>>>>> email addresses included in the To and CC lines. (Feel free to = cut this >>>>>>>>> introductory paragraph, however.) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The document, along with other ballot positions, can be found = here: >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>> DISCUSS: >>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>=20 >>>>>>>>> As S-BFD has no initiation process anymore it is not = guarenteed that the >>>>>>>>> receiver/responder actually exists. That means that packets = could float >>>>>>>>> (uncontrolled) in the network or even outside of the = adminstrative domain >>>>>>>>> (e.g. due to configuration mistakes). =46rom my point of view = this document >>>>>>>>> should recommend/require two things: >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> We have called out the misconfiguration =E2=80=94 however: >>>>>>>>=20 >>>>>>>>> 1) A maximum number of S-BFD packet that is allow to be send = without >>>>>>>>> getting a response (maybe leading to a local error report). >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> This can result in a deadlock situation, if an S-BFD Reflector = is enabled much later. I=E2=80=99m very hesitant to cap the packets = sent. We can, and I think it is useful, MAY log an error for multiple = timeouts. >>>>>>>=20 >>>>>>> Okay, I understand that a hard limit probably does make sense. = An error log seems definitely useful. >>>>>>=20 >>>>>> OK, that sounds good. See below. >>>>>>=20 >>>>>>> Another proposal for consideration: Currently the draft says an = initiator should only send one packet per second if the target is in = ADMINDOWN state. In this case there this state is explicit announced. = However if the other end just disappears or was never/not yet there, one = could use an exponential back off instead, starting with a smaller = intervals than one second but then increase it exponentially. Just an = idea... >>>>>>=20 >>>>>> Thanks for the proposal. Please have in mind however that this is = a protocol for detecting liveness (and lack of it), so increasing = exponentially defeats the purpose. >>>>>>=20 >>>>>> Further, exponential back off may not be the best choice when = interacting with routing protocols. >>>>>>=20 >>>>>> What we currently say is: >>>>>> The criteria for declaring loss of >>>>>> reachability and the action that would be triggered as a result >>>>>> are outside the scope of this document. >>>>>>=20 >>>>>> As much of these are implementation choices. >>>>>>=20 >>>>>> But we can add at the end =E2=80=9C, and MAY include logging an = error.=E2=80=9C >>>>>=20 >>>>> Please do so. >>>>=20 >>>> Done. >>>>=20 >>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>>> 2) Egress filtering at the adminstrative border of the domain = that uses >>>>>>>>> S-BFD to make sure that no S-BFD packets leave the domain. >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> This is no different than any other application that uses UDP; = a misconfigured DNS server will result in the same, and a traceroute is = also not too different. This seems too onerous of a requirement. An = administrative domain filters at ingress. >>>>>>>=20 >>>>>>> First of all, just because other protocols might have such a = problem, that does mean it=E2=80=99s okay. >>>>>>=20 >>>>>> I agree with this. I had a different point in mind though =E2=80=94= trying to specify this on every UDP application might not be the most = effective way. Perhaps there=E2=80=99s a UDP guideline you are = uncovering. >>>>>>=20 >>>>>>> However, correctly me if I=E2=80=99m wrong, but there the = situation seems slightly different because there is no termination = criterium at all that means an s-bfd node would send useless data = forever (=E2=80=A6 until manual change of the config). >>>>>>>=20 >>>>>>=20 >>>>>> But as far as this doc is concerned, let me try to make some = clarifications (and a correction). >>>>>>=20 >>>>>> There are termination criteria =E2=80=94 the document says: >>>>>>=20 >>>>>> An SBFDInitiator may be a persistent session on the initiator = with a >>>>>> timer for S-BFD control packet transmissions (stateful >>>>>> SBFDInitiator). An SBFDInitiator may also be a module, a script = or a >>>>>> tool on the initiator that transmits one or more S-BFD control >>>>>> packets "when needed" (stateless SBFDInitiator). >>>>>>=20 >>>>>> For the case in which you have a =E2=80=9Cwhen needed=E2=80=9D = SBFDInitiator, the workflow is like a =E2=80=9Cping=E2=80=9D. >>>>>>=20 >>>>>> For the case in which you have a =E2=80=9Cpersistent" = SBFDInitiator, in theory this can run forever (for some value of ever). = However, please don=E2=80=99t loose track of why this protocol exists. = Having OAM failures and do nothing about it defeats the purpose of = having OAM. Meaning, a red alarm will blink, a honk will horn, and the = config state will be changed (manually or by some support system). >>>>>>=20 >>>>>> In other words, I do not think this is such a unique case = (insofar as running ad-infinutum). >>>>>=20 >>>>> I still believe that the case where you have a misconfiguration = and the initiator sends packets (forever) but never ever gest a reply = (and never has seen a reply in the past), is a different case and can be = detected and handled separately. >>>>>=20 >>>>=20 >>>> Again, I would not qualify this as =E2=80=98forever=E2=80=99, but I = understand what you mean. >>>>=20 >>>>>>=20 >>>>>>> I still believe that egress filtering would be more appropriate = here (than ingress) because the domain that is using s-bfd knows about = it and therefor can set up the respective filters and should not spam = others while hoping that filters are in place. >>>>>>>=20 >>>>>>=20 >>>>>> To me, there is no insignificant operational complexity with = requiring the addition of filters throughout, for one particular = application not leaking (where the leak does not cause anything = special), and when the leak might happen because of a misconfiguration = (or bug) but will be detected by the operational support systems. The = ROI does not seem to add up. >>>>>=20 >>>>> Okay the document should probably not require egress filtering in = any case but what=E2=80=99s about saying something like: >>>>>=20 >>>>> =E2=80=9EIf S-BFD is used it SHOULD be ensured that S-BFD control = packet do not propagate outside of the administrative domain that uses = it.=E2=80=9C >>>>>=20 >>>>=20 >>>> We can add an additional explanation of the problem before a = statement, but I do not think that particular SHOULD is actionable. = How=E2=80=99s something like: >>>>=20 >>>> Explain that without handshake, a persistent initiator can send = blindly, to then add =E2=80=9CIn such case, operational measures SHOULD = be taken to identify if S-BFD packets are not responded to for an = extended period of time, and remediate the situation=E2=80=9D >>>>=20 >>>>> This is not an uncommon thing to specify also for other protocols. >>>>>=20 >>>>=20 >>>> I agree. Frankly, I am happy with either statement, but I think the = latter might be more operationally actionable. >>>>=20 >>>> Preference? >>>=20 >>> I still would prefer something in the line as I proposed. I think = there could effectively be different action to be taken here, e.g. = agree filtering or measurement to detect failure, as well as no action = if for some other reason it can be ensure that should a misconfiguration = can not happen (or is at least very unlikely to happen) e.g because = things are automated and there are additional checks before apply a = config. >>>=20 >>=20 >> Perhaps I can add =E2=80=9Cfor an extended period of time=E2=80=9D to = the first statement (or similar wording of your liking)? >>=20 >> Your main concern is the =E2=80=9Cforever=E2=80=9D. Let=E2=80=99s = ensure it is not =E2=80=9Cforever=E2=80=9D. However, I=E2=80=99m = concerned that a single packet out (like a ping to the wrong address) = will be violating =E2=80=9C it SHOULD be ensured that S-BFD control = packet do not propagate outside=E2=80=9D >=20 > The concern it not =E2=80=9Eforever=E2=80=9C but putting (unnecessary) = load on other network (by accident). So I agree, one or a few packets is = not a problem. So yes, adding =E2=80=9Cfor an extended period of time=E2=80= =9D is fine. We could also/instead exchange the word =E2=80=9Eensure=E2=80= =9C by something else (maybe =E2=80=9Econtrol=E2=80=9C=E2=80=A6?). >=20 These two changes would certainly work. Thank you. We will post a new rev today. [I still think that a few packets are not =E2=80=9C(unnecessary) load" = for an IP device, it=E2=80=99s really not different than doing a = traceroute and getting an icmp.unreach port unreachable (or if it is = critical and unwelcome load for a device, those devices are protected at = ingress at their border). But in any case, I do think that explaining the problem you highlight = helps and improves the doc, and the new text on what to do does not = hurt.] Thanks, =E2=80=94 Carlos. > Mirja >=20 >=20 >=20 >>=20 >> Would that work? >>=20 >> Thanks, >>=20 >> =E2=80=94 Carlos. >>=20 >>> The second SHOULD that you proposed is from my point of view = actually an additional point that I would also be happy to see in the = doc. >>>=20 >>> Mirja >>>=20 >>>=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> =E2=80=94 Carlos. >>>>=20 >>>>> Mirja >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Does the explanation of the termination criteria help? >>>>>>=20 >>>>>>>>=20 >>>>>>>> Seems to me the logging will alert someone/something to take = action, and should be enough. >>>>>>>=20 >>>>>>> Logging plus alerts is definitely a good thing. >>>>>>>=20 >>>>>>=20 >>>>>> I agree. >>>>>>=20 >>>>>> Will add =E2=80=9C, and MAY include logging an error.=E2=80=9D as = per above. >>>>>>=20 >>>>>> Do you think we should expand on this somewhere else in the = document? >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> =E2=80=94 Carlos. >>>>>>=20 >>>>>>> Mirja >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Thoughts? >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>>=20 >>>>>>>> =E2=80=94 Carlos. --Apple-Mail=_8521C713-AA43-415A-ADC4-BC80F447B630 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Mirja,

On May 4, 2016, at 11:29 AM, = Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:

Hi Carlos,

Am = 04.05.2016 um 17:13 schrieb Carlos Pignataro (cpignata) <cpignata@cisco.com>:

Hi, = Mirja,

On May 4, 2016, at 10:41 AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>= wrote:

Hi Carlos,

below.

Am 04.05.2016 um 16:33 schrieb Carlos Pignataro (cpignata) = <cpignata@cisco.com>:

Thanks= much for the response, Mirja!

I think we = are converging, please see inline.

On May 4, 2016, at 10:13 = AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:

Hi Carlos,

see below.

Am = 03.05.2016 um 19:24 schrieb Carlos Pignataro (cpignata) <cpignata@cisco.com>:

Hi, = Mirja,

On May 3, 2016, at 12:31 PM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>= wrote:

Hi Carlos,


Am = 03.05.2016 um 15:40 schrieb Carlos Pignataro (cpignata) <cpignata@cisco.com>:

Hi, = Mirja,

What is an uncontrolled packet in an = IP network, and what entity controls controlled ones? :-)

Questions over questions=E2=80=A6 = :-)

See below...


More = seriously, please see inline.

On May 3, 2016, at 5:35 AM, Mirja Kuehlewind = <ietf@kuehlewind.net> wrote:

Mirja K=C3=BChlewind has entered the following ballot = position for
draft-ietf-bfd-seamless-base-09: Discuss

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/<= /a>



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

As S-BFD has no initiation process = anymore it is not guarenteed that the
receiver/responder = actually exists. That means that packets could float
(uncontrolled) in the network or even outside of the = adminstrative domain
(e.g. due to configuration mistakes). = =46rom my point of view this document
should = recommend/require two things:


We have called out the = misconfiguration =E2=80=94 however:

1) A maximum number of = S-BFD packet that is allow to be send without
getting a = response (maybe leading to a local error report).


This can result in a deadlock = situation, if an S-BFD Reflector is enabled much later. I=E2=80=99m very = hesitant to cap the packets sent. We can, and I think it is useful, MAY = log an error for multiple timeouts.

Okay, I understand that a hard limit probably does make = sense. An error log seems definitely useful.

OK, that sounds good. See = below.

Another proposal for consideration: Currently the draft says = an initiator should only send one packet per second if the target is in = ADMINDOWN state. In this case there this state is explicit announced. = However if the other end just disappears or was never/not yet there, one = could use an exponential back off instead, starting with a smaller = intervals than one second but then increase it exponentially. Just an = idea...

Thanks for the = proposal. Please have in mind however that this is a protocol for = detecting liveness (and lack of it), so increasing exponentially defeats = the purpose.

Further, exponential back off = may not be the best choice when interacting with routing protocols.

What we currently say is:
 The criteria for declaring loss of
 reachability and the action that would be triggered as = a result
 are outside the scope of this document.

As much of these are implementation = choices.

But we can add at the end =E2=80=9C,= and MAY include logging an error.=E2=80=9C
Please do so.

Done.




2) Egress = filtering at the adminstrative border of the domain that uses
S-BFD to make sure that no S-BFD packets leave the domain.


This is no = different than any other application that uses UDP; a misconfigured DNS = server will result in the same, and a traceroute is also not too = different. This seems too onerous of a requirement. An administrative = domain filters at ingress.

First= of all, just because other protocols might have such a problem, that = does mean it=E2=80=99s okay.

I = agree with this. I had a different point in mind though =E2=80=94 trying = to specify this on every UDP application might not be the most effective = way. Perhaps there=E2=80=99s a UDP guideline you are uncovering.

However, = correctly me if I=E2=80=99m wrong, but there the situation seems = slightly different because there is no termination criterium at all that = means an s-bfd node would send useless data forever (=E2=80=A6 until = manual change of the config).


But as far as this doc is = concerned, let me try to make some clarifications (and a correction).

There are termination criteria =E2=80=94 the = document says:

An SBFDInitiator may be a = persistent session on the initiator with a
timer for S-BFD = control packet transmissions (stateful
SBFDInitiator). =  An SBFDInitiator may also be a module, a script or a
tool on the initiator that transmits one or more S-BFD = control
packets "when needed" (stateless = SBFDInitiator).

For the case in which you = have a =E2=80=9Cwhen needed=E2=80=9D SBFDInitiator, the workflow is like = a =E2=80=9Cping=E2=80=9D.

For the case in = which you have a =E2=80=9Cpersistent" SBFDInitiator, in theory this can = run forever (for some value of ever). However, please don=E2=80=99t = loose track of why this protocol exists. Having OAM failures and do = nothing about it defeats the purpose of having OAM. Meaning, a red alarm = will blink, a honk will horn, and the config state will be changed = (manually or by some support system).

In = other words, I do not think this is such a unique case (insofar as = running ad-infinutum).

I still = believe that the case where you have a misconfiguration and the = initiator sends packets (forever) but never ever gest a reply (and never = has seen a reply in the past), is a different case and can be detected = and handled separately.


Again, I would not qualify this as =E2=80=98forever=E2=80=99, = but I understand what you mean.


I still believe that = egress filtering would be more appropriate here (than ingress) because = the domain that is using s-bfd knows about it and therefor can set up = the respective filters and should not spam others while hoping that = filters are in place.


To me, there is no insignificant operational complexity with = requiring the addition of filters throughout, for one particular = application not leaking (where the leak does not cause anything = special), and when the leak might happen because of a misconfiguration = (or bug) but will be detected by the operational support systems. The = ROI does not seem to add up.

Okay the document should probably not require egress = filtering in any case but what=E2=80=99s about saying something like:

=E2=80=9EIf S-BFD is used it SHOULD be ensured = that S-BFD control packet do not propagate outside of the administrative = domain that uses it.=E2=80=9C


We can add an additional = explanation of the problem before a statement, but I do not think that = particular SHOULD is actionable. How=E2=80=99s something like:

Explain that without handshake, a persistent = initiator can send blindly, to then add =E2=80=9CIn such case, = operational measures SHOULD be taken to identify if S-BFD packets are = not responded to for an extended period of time, and remediate the = situation=E2=80=9D

This is not an uncommon thing to specify also for other = protocols.


I = agree. Frankly, I am happy with either statement, but I think the latter = might be more operationally actionable.

Preference?

I still = would prefer something in the line as I proposed. I think there could = effectively  be different action to be taken here, e.g. agree = filtering or measurement to detect failure, as well as no action if for = some other reason it can be ensure that should a misconfiguration can = not happen (or is at least very unlikely to happen) e.g because things = are automated and there are additional checks before apply a config.


Perhaps I can add = =E2=80=9Cfor an extended period of time=E2=80=9D to the first statement = (or similar wording of your liking)?

Your = main concern is the =E2=80=9Cforever=E2=80=9D. Let=E2=80=99s ensure it = is not =E2=80=9Cforever=E2=80=9D. However, I=E2=80=99m concerned that a = single packet out (like a ping to the wrong address) will be violating = =E2=80=9C it SHOULD be ensured that S-BFD control packet do not = propagate outside=E2=80=9D

The concern it not = =E2=80=9Eforever=E2=80=9C but putting (unnecessary) load on other = network (by accident). So I agree, one or a few packets is not a = problem. So yes, adding =E2=80=9Cfor an extended period of time=E2=80=9D = is fine. We could also/instead exchange the word =E2=80=9Eensure=E2=80=9C = by something else (maybe =E2=80=9Econtrol=E2=80=9C=E2=80=A6?).








Mirja




Would that work?

Thanks,

=E2=80=94 Carlos.

The = second SHOULD that you proposed is from my point of view actually an = additional point that I would also be happy to see in the doc.

Mirja



Thanks,

=E2=80=94 Carlos.

Mirja



Does the explanation of the termination criteria help?


Seems to me the logging will = alert someone/something to take action, and should be enough.

Logging plus alerts is definitely = a good thing.


I = agree.

Will add =E2=80=9C, and MAY include = logging an error.=E2=80=9D as per above.

Do = you think we should expand on this somewhere else in the document?

Thanks,

=E2=80=94 = Carlos.

Mirja



Thoughts?

Thanks,

=E2=80=94 = Carlos.

= --Apple-Mail=_8521C713-AA43-415A-ADC4-BC80F447B630-- --Apple-Mail=_CF5939F7-197A-4D65-8EDB-D6900468ADF5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXKhj4AAoJEIXgpQGOZny94bYP/2luk9iZMsD+A2rs4/dgR/s9 cdIhY+wVv58egqvyWcsA//PxV8N934XzH+UPShKElRELoIp7JjaMJHgQo3AtBA5e 0HcWXu25k5qc/byHyUnpAp+HdiObiToymiNfJolLsCZgbXl+mwD74xU+rAkos1Q0 dThYHuNucQVOnhq/hFfTyUofB7d+VS7oCJcKgUMUJFoRaRi8xmTpLOBfaBPezE6i PbA9ob6FY44O9Qy389Nn+91umEpKKPdYD1o9CPtbaeUVpSM7D1171AHbdoALfJmE DFofOPsf9G2uwlaQvelsRpkR8b3UmPvvNgb9AlUmbnMMxuKWiRvFJo69CUpE9NUw cYBB0bdDF+GB/oFzgNh/CL+cIq4FawPK288wzcFgcnxlW0+pKGV31mL4byewfbU0 1w06ysH2hrChXX7pEMVBet+qHqz1i0jTKFf3nJsuEanTvS9x/wgp2Rp2taVL+53A 7QxWi4br2IXPemGnaVdwL0Yro1H19nfSSqC2WS2gFELDUVIg5D6C91jY1oMP8MsN sV9j3F8FOAZP21oZltQtWBsO39B1VDNgFXCiWT7J3+fEzL3VUtBJV6XiUI068lIt efdee0AyM0dN4NaYPqDfHH71k8Z4mCW8k3Qp2ygdJd90HdfO6ZL6YY76mBhlqQyl 6qm6F/ZhqoSE2zLgJH/8 =4KQp -----END PGP SIGNATURE----- --Apple-Mail=_CF5939F7-197A-4D65-8EDB-D6900468ADF5-- From nobody Wed May 4 09:09:42 2016 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 EA0F012D0E4 for ; Wed, 4 May 2016 09:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 fNeSMZACzDas for ; Wed, 4 May 2016 09:09:38 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD1512DA44 for ; Wed, 4 May 2016 09:01:02 -0700 (PDT) Received: (qmail 19590 invoked from network); 4 May 2016 17:54:19 +0200 Received: from p5dec2412.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.36.18) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 4 May 2016 17:54:18 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-b?= =?utf-8?Q?fd-seamless-base-09=3A_=28with_DISCUSS=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Wed, 4 May 2016 17:54:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160503093512.7446.68991.idtracker@ietfa.amsl.com> <1EB9BDDB-483F-48BC-9D2F-D68E6ACA285E@kuehlewind.net> <2129C9FD-F4C4-4C2D-B3E9-369A754163A4@cisco.com> <7E0A3ABF-1C32-43D1-BC9B-E42BDB3090AB@cisco.com> <4C6B695B-D796-464D-ACCC-74BADD577F32@kuehlewind.net> To: "Carlos Pignataro (cpignata)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 16:09:41 -0000 Hi Carlos, > Am 04.05.2016 um 17:44 schrieb Carlos Pignataro (cpignata) = : >=20 > Hi, Mirja, >=20 >> On May 4, 2016, at 11:29 AM, Mirja Kuehlewind (IETF) = wrote: >>=20 >> Hi Carlos, >>=20 >>> Am 04.05.2016 um 17:13 schrieb Carlos Pignataro (cpignata) = : >>>=20 >>> Hi, Mirja, >>>=20 >>>> On May 4, 2016, at 10:41 AM, Mirja Kuehlewind (IETF) = wrote: >>>>=20 >>>> Hi Carlos, >>>>=20 >>>> below. >>>>=20 >>>>> Am 04.05.2016 um 16:33 schrieb Carlos Pignataro (cpignata) = : >>>>>=20 >>>>> Thanks much for the response, Mirja! >>>>>=20 >>>>> I think we are converging, please see inline. >>>>>=20 >>>>>> On May 4, 2016, at 10:13 AM, Mirja Kuehlewind (IETF) = wrote: >>>>>>=20 >>>>>> Hi Carlos, >>>>>>=20 >>>>>> see below. >>>>>>=20 >>>>>>> Am 03.05.2016 um 19:24 schrieb Carlos Pignataro (cpignata) = : >>>>>>>=20 >>>>>>> Hi, Mirja, >>>>>>>=20 >>>>>>>> On May 3, 2016, at 12:31 PM, Mirja Kuehlewind (IETF) = wrote: >>>>>>>>=20 >>>>>>>> Hi Carlos, >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Am 03.05.2016 um 15:40 schrieb Carlos Pignataro (cpignata) = : >>>>>>>>>=20 >>>>>>>>> Hi, Mirja, >>>>>>>>>=20 >>>>>>>>> What is an uncontrolled packet in an IP network, and what = entity controls controlled ones? :-) >>>>>>>>=20 >>>>>>>> Questions over questions=E2=80=A6 :-) >>>>>>>>=20 >>>>>>>> See below... >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> More seriously, please see inline. >>>>>>>>>=20 >>>>>>>>>> On May 3, 2016, at 5:35 AM, Mirja Kuehlewind = wrote: >>>>>>>>>>=20 >>>>>>>>>> Mirja K=C3=BChlewind has entered the following ballot = position for >>>>>>>>>> draft-ietf-bfd-seamless-base-09: Discuss >>>>>>>>>>=20 >>>>>>>>>> When responding, please keep the subject line intact and = reply to all >>>>>>>>>> email addresses included in the To and CC lines. (Feel free = to cut this >>>>>>>>>> introductory paragraph, however.) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>>>>> for more information about IESG DISCUSS and COMMENT = positions. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> The document, along with other ballot positions, can be found = here: >>>>>>>>>> = https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>> DISCUSS: >>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>>=20 >>>>>>>>>> As S-BFD has no initiation process anymore it is not = guarenteed that the >>>>>>>>>> receiver/responder actually exists. That means that packets = could float >>>>>>>>>> (uncontrolled) in the network or even outside of the = adminstrative domain >>>>>>>>>> (e.g. due to configuration mistakes). =46rom my point of view = this document >>>>>>>>>> should recommend/require two things: >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> We have called out the misconfiguration =E2=80=94 however: >>>>>>>>>=20 >>>>>>>>>> 1) A maximum number of S-BFD packet that is allow to be send = without >>>>>>>>>> getting a response (maybe leading to a local error report). >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> This can result in a deadlock situation, if an S-BFD Reflector = is enabled much later. I=E2=80=99m very hesitant to cap the packets = sent. We can, and I think it is useful, MAY log an error for multiple = timeouts. >>>>>>>>=20 >>>>>>>> Okay, I understand that a hard limit probably does make sense. = An error log seems definitely useful. >>>>>>>=20 >>>>>>> OK, that sounds good. See below. >>>>>>>=20 >>>>>>>> Another proposal for consideration: Currently the draft says an = initiator should only send one packet per second if the target is in = ADMINDOWN state. In this case there this state is explicit announced. = However if the other end just disappears or was never/not yet there, one = could use an exponential back off instead, starting with a smaller = intervals than one second but then increase it exponentially. Just an = idea... >>>>>>>=20 >>>>>>> Thanks for the proposal. Please have in mind however that this = is a protocol for detecting liveness (and lack of it), so increasing = exponentially defeats the purpose. >>>>>>>=20 >>>>>>> Further, exponential back off may not be the best choice when = interacting with routing protocols. >>>>>>>=20 >>>>>>> What we currently say is: >>>>>>> The criteria for declaring loss of >>>>>>> reachability and the action that would be triggered as a result >>>>>>> are outside the scope of this document. >>>>>>>=20 >>>>>>> As much of these are implementation choices. >>>>>>>=20 >>>>>>> But we can add at the end =E2=80=9C, and MAY include logging an = error.=E2=80=9C >>>>>>=20 >>>>>> Please do so. >>>>>=20 >>>>> Done. >>>>>=20 >>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> 2) Egress filtering at the adminstrative border of the domain = that uses >>>>>>>>>> S-BFD to make sure that no S-BFD packets leave the domain. >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> This is no different than any other application that uses UDP; = a misconfigured DNS server will result in the same, and a traceroute is = also not too different. This seems too onerous of a requirement. An = administrative domain filters at ingress. >>>>>>>>=20 >>>>>>>> First of all, just because other protocols might have such a = problem, that does mean it=E2=80=99s okay. >>>>>>>=20 >>>>>>> I agree with this. I had a different point in mind though =E2=80=94= trying to specify this on every UDP application might not be the most = effective way. Perhaps there=E2=80=99s a UDP guideline you are = uncovering. >>>>>>>=20 >>>>>>>> However, correctly me if I=E2=80=99m wrong, but there the = situation seems slightly different because there is no termination = criterium at all that means an s-bfd node would send useless data = forever (=E2=80=A6 until manual change of the config). >>>>>>>>=20 >>>>>>>=20 >>>>>>> But as far as this doc is concerned, let me try to make some = clarifications (and a correction). >>>>>>>=20 >>>>>>> There are termination criteria =E2=80=94 the document says: >>>>>>>=20 >>>>>>> An SBFDInitiator may be a persistent session on the initiator = with a >>>>>>> timer for S-BFD control packet transmissions (stateful >>>>>>> SBFDInitiator). An SBFDInitiator may also be a module, a script = or a >>>>>>> tool on the initiator that transmits one or more S-BFD control >>>>>>> packets "when needed" (stateless SBFDInitiator). >>>>>>>=20 >>>>>>> For the case in which you have a =E2=80=9Cwhen needed=E2=80=9D = SBFDInitiator, the workflow is like a =E2=80=9Cping=E2=80=9D. >>>>>>>=20 >>>>>>> For the case in which you have a =E2=80=9Cpersistent" = SBFDInitiator, in theory this can run forever (for some value of ever). = However, please don=E2=80=99t loose track of why this protocol exists. = Having OAM failures and do nothing about it defeats the purpose of = having OAM. Meaning, a red alarm will blink, a honk will horn, and the = config state will be changed (manually or by some support system). >>>>>>>=20 >>>>>>> In other words, I do not think this is such a unique case = (insofar as running ad-infinutum). >>>>>>=20 >>>>>> I still believe that the case where you have a misconfiguration = and the initiator sends packets (forever) but never ever gest a reply = (and never has seen a reply in the past), is a different case and can be = detected and handled separately. >>>>>>=20 >>>>>=20 >>>>> Again, I would not qualify this as =E2=80=98forever=E2=80=99, but = I understand what you mean. >>>>>=20 >>>>>>>=20 >>>>>>>> I still believe that egress filtering would be more appropriate = here (than ingress) because the domain that is using s-bfd knows about = it and therefor can set up the respective filters and should not spam = others while hoping that filters are in place. >>>>>>>>=20 >>>>>>>=20 >>>>>>> To me, there is no insignificant operational complexity with = requiring the addition of filters throughout, for one particular = application not leaking (where the leak does not cause anything = special), and when the leak might happen because of a misconfiguration = (or bug) but will be detected by the operational support systems. The = ROI does not seem to add up. >>>>>>=20 >>>>>> Okay the document should probably not require egress filtering in = any case but what=E2=80=99s about saying something like: >>>>>>=20 >>>>>> =E2=80=9EIf S-BFD is used it SHOULD be ensured that S-BFD control = packet do not propagate outside of the administrative domain that uses = it.=E2=80=9C >>>>>>=20 >>>>>=20 >>>>> We can add an additional explanation of the problem before a = statement, but I do not think that particular SHOULD is actionable. = How=E2=80=99s something like: >>>>>=20 >>>>> Explain that without handshake, a persistent initiator can send = blindly, to then add =E2=80=9CIn such case, operational measures SHOULD = be taken to identify if S-BFD packets are not responded to for an = extended period of time, and remediate the situation=E2=80=9D >>>>>=20 >>>>>> This is not an uncommon thing to specify also for other = protocols. >>>>>>=20 >>>>>=20 >>>>> I agree. Frankly, I am happy with either statement, but I think = the latter might be more operationally actionable. >>>>>=20 >>>>> Preference? >>>>=20 >>>> I still would prefer something in the line as I proposed. I think = there could effectively be different action to be taken here, e.g. = agree filtering or measurement to detect failure, as well as no action = if for some other reason it can be ensure that should a misconfiguration = can not happen (or is at least very unlikely to happen) e.g because = things are automated and there are additional checks before apply a = config. >>>>=20 >>>=20 >>> Perhaps I can add =E2=80=9Cfor an extended period of time=E2=80=9D = to the first statement (or similar wording of your liking)? >>>=20 >>> Your main concern is the =E2=80=9Cforever=E2=80=9D. Let=E2=80=99s = ensure it is not =E2=80=9Cforever=E2=80=9D. However, I=E2=80=99m = concerned that a single packet out (like a ping to the wrong address) = will be violating =E2=80=9C it SHOULD be ensured that S-BFD control = packet do not propagate outside=E2=80=9D >>=20 >> The concern it not =E2=80=9Eforever=E2=80=9C but putting = (unnecessary) load on other network (by accident). So I agree, one or a = few packets is not a problem. So yes, adding =E2=80=9Cfor an extended = period of time=E2=80=9D is fine. We could also/instead exchange the word = =E2=80=9Eensure=E2=80=9C by something else (maybe =E2=80=9Econtrol=E2=80=9C= =E2=80=A6?). >>=20 >=20 > These two changes would certainly work.=20 >=20 > Thank you. We will post a new rev today. >=20 > [I still think that a few packets are not =E2=80=9C(unnecessary) load" = for an IP device, it=E2=80=99s really not different than doing a = traceroute and getting an icmp.unreach port unreachable (or if it is = critical and unwelcome load for a device, those devices are protected at = ingress at their border). I do agree but you never know how people might (mis)use things in = future... >=20 > But in any case, I do think that explaining the problem you highlight = helps and improves the doc, and the new text on what to do does not = hurt.] Thanks. I=E2=80=99ll clear my discuss now and will have a look at the = new version next week! Mirja >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >> Mirja >>=20 >>=20 >>=20 >>>=20 >>> Would that work? >>>=20 >>> Thanks, >>>=20 >>> =E2=80=94 Carlos. >>>=20 >>>> The second SHOULD that you proposed is from my point of view = actually an additional point that I would also be happy to see in the = doc. >>>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> =E2=80=94 Carlos. >>>>>=20 >>>>>> Mirja >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Does the explanation of the termination criteria help? >>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Seems to me the logging will alert someone/something to take = action, and should be enough. >>>>>>>>=20 >>>>>>>> Logging plus alerts is definitely a good thing. >>>>>>>>=20 >>>>>>>=20 >>>>>>> I agree. >>>>>>>=20 >>>>>>> Will add =E2=80=9C, and MAY include logging an error.=E2=80=9D = as per above. >>>>>>>=20 >>>>>>> Do you think we should expand on this somewhere else in the = document? >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> =E2=80=94 Carlos. >>>>>>>=20 >>>>>>>> Mirja >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Thoughts? >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>>=20 >>>>>>>>> =E2=80=94 Carlos. >=20 From nobody Wed May 4 09:14:44 2016 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 B642612DDB5; Wed, 4 May 2016 09:14:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" Subject: Alia Atlas' Yes on draft-ietf-bfd-seamless-ip-04: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504161439.8272.44736.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 09:14:39 -0700 Archived-At: Cc: rtg-bfd@ietf.org, bfd-chairs@ietf.org, draft-ietf-bfd-seamless-ip@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 16:14:40 -0000 Alia Atlas has entered the following ballot position for draft-ietf-bfd-seamless-ip-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my discuss concerns. I look forward to the updated draft. From nobody Wed May 4 12:32:57 2016 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 6EA7012D5BA; Wed, 4 May 2016 12:32:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-seamless-base-10.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504193254.8201.27276.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 12:32:54 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 19:32:54 -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 of the IETF. Title : Seamless Bidirectional Forwarding Detection (S-BFD) Authors : Nobo Akiya Carlos Pignataro Dave Ward Manav Bhatia Santosh Pallagatti Filename : draft-ietf-bfd-seamless-base-10.txt Pages : 21 Date : 2016-05-04 Abstract: This document defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. This document updates RFC5880. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bfd-seamless-base-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-base-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 4 12:33:03 2016 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 A49D612D5BA; Wed, 4 May 2016 12:32:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-seamless-ip-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504193255.8214.19006.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 12:32:55 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 19:32:55 -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 of the IETF. Title : Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS Authors : Nobo Akiya Carlos Pignataro Dave Ward Filename : draft-ietf-bfd-seamless-ip-05.txt Pages : 8 Date : 2016-05-04 Abstract: This document defines procedures to use Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bfd-seamless-ip-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-ip-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 4 12:33:15 2016 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 C4F2412D5C7; Wed, 4 May 2016 12:33:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-seamless-use-case-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504193302.8201.513.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 12:33:02 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 19:33:03 -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 of the IETF. Title : Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases Authors : Sam Aldrin Carlos Pignataro Greg Mirsky Nagendra Kumar Filename : draft-ietf-bfd-seamless-use-case-07.txt Pages : 15 Date : 2016-05-04 Abstract: This document describes various use cases for a Seamless Bidirectional Forwarding Detection (S-BFD), and provides requirements such that protocol mechanisms allow for a simplified detection of forwarding failures. These use cases support S-BFD, as a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, accelerating the establishment of a BFD session. S-BFD benefits include quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-use-case/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bfd-seamless-use-case-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-use-case-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 4 13:29:02 2016 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 C280312D75B; Wed, 4 May 2016 13:28:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" Subject: Kathleen Moriarty's No Objection on draft-ietf-bfd-seamless-use-case-07: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504202858.8238.33864.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 13:28:58 -0700 Archived-At: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-seamless-use-case@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 20:28:59 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-bfd-seamless-use-case-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-use-case/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Shouldn't Requirement #10 explicitly state active and passive attacks? That way you cover interception and passive listening too. From nobody Wed May 4 19:05:11 2016 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 E662F12B037; Wed, 4 May 2016 19:05:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" Subject: Suresh Krishnan's No Objection on draft-ietf-bfd-seamless-base-10: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160505020508.8260.51761.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 19:05:08 -0700 Archived-At: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 02:05:09 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-bfd-seamless-base-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3: This sentence is not clear. Which one of the following Options (1&2) do you intend? I am guessing 2, but it may make sense to clarify in either case. Current: Once the above setup is complete, any network node, having the knowledge of the S-BFD discriminator allocated to by a remote node to remote entity/entities Option 1: Once the above setup is complete, any network node, having the knowledge of the S-BFD discriminator allocated to it by a remote node to remote entity/entities Option 2: Once the above setup is complete, any network node, having the knowledge of the S-BFD discriminator allocated by a remote node to remote entity/entities Section 7.2.1. Responder Demultiplexing The last step in section seems to be pointing to the initiator packet transmission. Shouldn't this point to the responder procedures (Section 7.2.2) instead? "Chosen reflector BFD session SHOULD transmit a response BFD control packet using procedures described in Section 7.3.2." From nobody Wed May 4 19:38:48 2016 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 2F3DB12D10C; Wed, 4 May 2016 19:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 tDu2sBL42FkL; Wed, 4 May 2016 19:38:40 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325FA12B012; Wed, 4 May 2016 19:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3607; q=dns/txt; s=iport; t=1462415920; x=1463625520; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tqsRWUUuNnPq3QMDsN8wk9uZvtuueEaW2gdSIHB2N+c=; b=dSoLM/9kv1NyZPdDxNOOZA7piEQnZcmiTG8JljV8iD7908S/Ns8ZFowp 2+oVL2Q+/zpFKpFi5kr5VCDXtuRwjS0ihvZXeCIe31yqszD5VIPK5lbkK +uFmDtBaZzm1EKipiuLYgOcS1TrQ63e8R3fs3JKrlH2254JXJdLOGwbGI o=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBQAfsSpX/4kNJK1egzhTfQa3V4Idg?= =?us-ascii?q?XYihW4CgTs6EgEBAQEBAQFlJ4RBAQEBAwEjVgULAgEIGCoCAjIlAgQOBQ6IFAg?= =?us-ascii?q?OrTaQcAEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0EBIYggXaCVoQREQFOgk4rgi4Fh?= =?us-ascii?q?3iLLIR1AYMngWdtiByBaIRNiF6PMwEnBDeCNoE1bAGHJDZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,580,1454976000"; d="asc'?scan'208";a="103849889" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2016 02:38:39 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u452ccJw026596 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 May 2016 02:38:39 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 May 2016 22:38:38 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Wed, 4 May 2016 22:38:38 -0400 From: "Carlos Pignataro (cpignata)" To: Suresh Krishnan Subject: Re: Suresh Krishnan's No Objection on draft-ietf-bfd-seamless-base-10: (with COMMENT) Thread-Topic: Suresh Krishnan's No Objection on draft-ietf-bfd-seamless-base-10: (with COMMENT) Thread-Index: AQHRpnKQsB2v8U66aUWfiSKwfRwTwZ+p5JyA Date: Thu, 5 May 2016 02:38:38 +0000 Message-ID: <67A5D11F-A797-42D1-A1DE-02DAAD8CA760@cisco.com> References: <20160505020508.8260.51761.idtracker@ietfa.amsl.com> In-Reply-To: <20160505020508.8260.51761.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.209.14] Content-Type: multipart/signed; boundary="Apple-Mail=_588C94E7-1F87-4AD1-8179-7FF009706E19"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: The IESG , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 02:38:42 -0000 --Apple-Mail=_588C94E7-1F87-4AD1-8179-7FF009706E19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the review, Suresh! Please see inline. > On May 4, 2016, at 10:05 PM, Suresh Krishnan = wrote: >=20 > Suresh Krishnan has entered the following ballot position for > draft-ietf-bfd-seamless-base-10: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Section 3: >=20 > This sentence is not clear. Which one of the following Options (1&2) = do > you intend? I am guessing 2, but it may make sense to clarify in = either > case. >=20 Yes, option 2. > Current: >=20 > Once the above setup is complete, any network node, having the > knowledge of the S-BFD discriminator allocated to by a remote node = to > remote entity/entities >=20 > Option 1: >=20 > Once the above setup is complete, any network node, having the > knowledge of the S-BFD discriminator allocated to it by a remote = node > to > remote entity/entities >=20 > Option 2: >=20 > Once the above setup is complete, any network node, having the > knowledge of the S-BFD discriminator allocated by a remote node to > remote entity/entities >=20 > Section 7.2.1. Responder Demultiplexing >=20 > The last step in section seems to be pointing to the initiator packet > transmission. Shouldn't this point to the responder procedures = (Section > 7.2.2) instead? >=20 Indeed. This should be 7.2.2 (somehow hardcoded in the xml source = instead of a pointer). We can fix these two. Thanks, =E2=80=94 Carlos. > "Chosen reflector BFD session SHOULD transmit a response BFD control > packet using procedures described in Section 7.3.2." >=20 >=20 --Apple-Mail=_588C94E7-1F87-4AD1-8179-7FF009706E19 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXKrItAAoJEIXgpQGOZny9lLoQAJnDK3b0qYb1KyMw6Auw8rp6 dHXBK2tb1rcuC+yUnG0iAn/hL8xrWpDvkaQHnfoyU4hSiLxqCqIK42GPqJNJXee+ 3lncPeG3tZycvK8w1LPBZXoV1pgCriG2Am0NpzN/a9iAz3mWE4tgcpHz0lE2kSM+ EcHgzckC5hPEF385ge7K3/uq8eL/3wgWztCNoY9Nf9VNyg0TOeN4WX/S+Nu7dFpJ jnyylGIf9zPCkYkybkl76ASVB+pO1tsBJxavKZAVVT87YNHvMXbnh+t22qXXp2JO /2AULZamng3TKi2WIiLWXlpX/kPT0ZC/a+AMmN4jeZveQlAeE9GQahnWWZeLf5+8 k7qvtRTJKoHar8is7BvJZO4Xl4qSEB/Aio6FrItFtrSYgwLR8jrNR0DKwW88LkoK JpCSs0sHue0NXIi1i3NNyG/HuSH7fTs94fGPfzWSJN5xAVq/vJVEWO07z3eSzceh koKT2MQUxVAB/6QrDIys77TcLa5pAfswrWjLSXMNlRhaG5twFtfGgZk25ZM37Dk5 9HUNMYqh2zZ6oAf4hg1gzEhIsZ/4q9PexR0Y5352ddEXslv0a0XxuKbHVBKI5vg9 o8TISEVt2ltCC4OaOUugEDjnQfSNJTKjJF9dAzcwOJKBuimJ+D9Yq7mui3EnoOyC BGdrynUIJxfUHHkOCWJR =uZp7 -----END PGP SIGNATURE----- --Apple-Mail=_588C94E7-1F87-4AD1-8179-7FF009706E19-- From nobody Wed May 4 19:42:35 2016 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 E14BF12B074; Wed, 4 May 2016 19:42:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" Subject: Suresh Krishnan's No Objection on draft-ietf-bfd-seamless-ip-05: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160505024232.8301.61064.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 19:42:32 -0700 Archived-At: Cc: rtg-bfd@ietf.org, bfd-chairs@ietf.org, draft-ietf-bfd-seamless-ip@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 02:42:33 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-bfd-seamless-ip-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 5.1, 6.1: The IPv4-mapped IPv6 prefix for the IPv4 loopback range 127.0.0.0/8 is incorrect. It is currently written as 0:0:0:0:0:FFFF:7F00/104. It should instead be 0:0:0:0:0:FFFF:7F00:0/104. Sections 5.1, 6.1: The document just talks about the TTL field being set to 255. It does not talk about the Hop Limit field for IPv6. I would assume you want to do the same for IPv6 packets as for the IPv4 packets. Can you include the Hop Limit as well if you want the same behavior for IPv6. I have two suggested forms of changes. Pick whatever works better for you. OLD: TTL field of the IP header SHOULD be set to 255 NEW: The TTL/Hop Limit field of the IP header SHOULD be set to 255 (or) The TTL field of the IPv4 header or the Hop Limit field of the IPv6 header SHOULD be set to 255 From nobody Thu May 5 06:09:20 2016 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 336EC12D631; Thu, 5 May 2016 06:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 3a5atXMQ841X; Thu, 5 May 2016 06:09:11 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC2612D641; Thu, 5 May 2016 06:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8227; q=dns/txt; s=iport; t=1462453746; x=1463663346; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vGnYN22pGtMo2wyJuqwfOamxn0CDi9odQyeapB1QXRU=; b=NP61yPVhDWbGpH0kS7SvPGOMfN5RWlsYEppyzg9+ExnPutAevaCjZZPh VK8NaraVbvnvg5OrHUTzRbfDXbqhS+z5JmKFYulTL0g4EREyfjK09t5ya kXepoHRieK0XcylbcgebKbOXMSzGwUk4SrhWKY9Wcq9EqPOSfkfxSZ01u Q=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvAwB/RStX/5tdJa1EGoJsTFN9BrQ4g?= =?us-ascii?q?mSCDw6BdiKFbgKBMTgUAQEBAQEBAWUnhEEBAQEDASNWBQsCAQYCGCoCAjIlAgQ?= =?us-ascii?q?OBQ6IFAgOLJBOnR2QfAEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0EBIYggXYIgk6EE?= =?us-ascii?q?QsGAYMcK4IuBYd5iyyEdQGDJ4FnbYgdgWiETYhejzMBHgFDggUbFoE1bAGHHAg?= =?us-ascii?q?XH38BAQE?= X-IronPort-AV: E=Sophos;i="5.24,582,1454976000"; d="asc'?scan'208,217";a="268121136" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 May 2016 13:08:55 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u45D8sZT015720 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 May 2016 13:08:55 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 May 2016 09:08:54 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Thu, 5 May 2016 09:08:54 -0400 From: "Carlos Pignataro (cpignata)" To: Suresh Krishnan Subject: Re: Suresh Krishnan's No Objection on draft-ietf-bfd-seamless-ip-05: (with COMMENT) Thread-Topic: Suresh Krishnan's No Objection on draft-ietf-bfd-seamless-ip-05: (with COMMENT) Thread-Index: AQHRpnfHDw7QyZcqrUSVv8NDU97dUp+qlKqA Date: Thu, 5 May 2016 13:08:54 +0000 Message-ID: <1F36A65B-13DC-4E65-8499-1EE07DE1FB6A@cisco.com> References: <20160505024232.8301.61064.idtracker@ietfa.amsl.com> In-Reply-To: <20160505024232.8301.61064.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.48.200] Content-Type: multipart/signed; boundary="Apple-Mail=_DF80D8E8-629B-4F6F-A1A2-43C5A3584912"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-bfd-seamless-ip@ietf.org" , The IESG , "rtg-bfd@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 13:09:14 -0000 --Apple-Mail=_DF80D8E8-629B-4F6F-A1A2-43C5A3584912 Content-Type: multipart/alternative; boundary="Apple-Mail=_70360C30-4ED7-42F2-9B57-6C77AB31475C" --Apple-Mail=_70360C30-4ED7-42F2-9B57-6C77AB31475C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Suresh, =F0=9F=8E=82=F0=9F=8E=BC=F0=9F=8E=89 Please see inline. > On May 4, 2016, at 10:42 PM, Suresh Krishnan = wrote: >=20 > Suresh Krishnan has entered the following ballot position for > draft-ietf-bfd-seamless-ip-05: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Section 5.1, 6.1: >=20 > The IPv4-mapped IPv6 prefix for the IPv4 loopback range 127.0.0.0/8 is > incorrect. >=20 > It is currently written as 0:0:0:0:0:FFFF:7F00/104. It should instead = be > 0:0:0:0:0:FFFF:7F00:0/104. >=20 OK =E2=80=94 in this case, a number of Errata items should be both = corrected and new ones filed. E.g.: https://www.rfc-editor.org/errata_search.php?rfc=3D4379&eid=3D1418 = > Sections 5.1, 6.1: >=20 > The document just talks about the TTL field being set to 255. It does = not > talk about the Hop Limit field for IPv6. I would assume you want to do > the same for IPv6 packets as for the IPv4 packets. Can you include the > Hop Limit as well if you want the same behavior for IPv6. I have two > suggested forms of changes. Pick whatever works better for you. >=20 > OLD: >=20 > TTL field of the IP header SHOULD be set to 255 >=20 > NEW: >=20 > The TTL/Hop Limit field of the IP header SHOULD be set to 255 >=20 Yes, I prefer this one. Thanks! =E2=80=94 Carlos. > (or) >=20 > The TTL field of the IPv4 header or the Hop Limit field of the IPv6 > header SHOULD be set to 255 >=20 >=20 --Apple-Mail=_70360C30-4ED7-42F2-9B57-6C77AB31475C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Suresh, 

=F0=9F=8E=82=F0=9F=8E=BC=F0=9F=8E=89

Please see = inline.


On = May 4, 2016, at 10:42 PM, Suresh Krishnan <suresh.krishnan@ericsson.com> wrote:

Suresh= Krishnan has entered the following ballot position for
draft-ietf-bfd-seamless-ip-05: No Objection

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC = lines. (Feel free to cut this
introductory paragraph, = however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Section 5.1, 6.1:

The IPv4-mapped IPv6 prefix for the IPv4 loopback range = 127.0.0.0/8 is
incorrect.

It = is currently written as 0:0:0:0:0:FFFF:7F00/104. It should instead be
0:0:0:0:0:FFFF:7F00:0/104.




Sections 5.1, = 6.1:

The document just talks about the TTL = field being set to 255. It does not
talk about the Hop = Limit field for IPv6. I would assume you want to do
the = same for IPv6 packets as for the IPv4 packets. Can you include the
Hop Limit as well if you want the same behavior for IPv6. I = have two
suggested forms of changes. Pick whatever works = better for you.

OLD:

TTL field of the IP header SHOULD be set to 255

NEW:

The TTL/Hop = Limit field of the IP header SHOULD be set to 255


Yes, = I prefer this one.

Thanks!

=E2=80=94= Carlos.

(or)

The TTL = field of the IPv4 header or the Hop Limit field of the IPv6
header SHOULD be set to 255



= --Apple-Mail=_70360C30-4ED7-42F2-9B57-6C77AB31475C-- --Apple-Mail=_DF80D8E8-629B-4F6F-A1A2-43C5A3584912 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXK0XlAAoJEIXgpQGOZny9FywP/2+NLr2IB3lL1rz9ZoJRebSw 66M87dI6ZCYrCjGm70o08PcPMRiHco/4d1OOSEGrkeKisJbhTyIIcMUCsOiqGUwr DSX4my863h9i+M3aymwaenRcGMuWj9cqRSQy9gSK9ysfFBIfXyWGYB0v7w0xeE4b XOF91+7BvUZNwEqgcquY6WoQNvc937xWbTCH22nr8DK7NFXLsHQFWGv5v5wF/+X0 HpVPxJMAIV5F3HlSyI7ZEiBirhqD19IMl2HxnLm+fTasg/iq+ZyTN3tiDnTtVOmp ZYmuFfHih+WxFLfBjJ8TOOq+9M1oiIS9iieEFntqxdgJHjOQ25RvX8H3HMbDmw28 2y/bm3qBw1Cl5jDq7A7R+qWuYTb/hsynbQErKbNPtfNaMLQoVh3X3YN23R1g4GEU lFZL4QxHfTQOB9sTdAxi4H81ixTc14VvmQTWr84By3u8V7zaVNat83Ovw4ZL5XR4 iuZOqCR4FKiCZqY9HuZhGnsB0/0kKb1W/U1yTXK9G7PcN3Y9rkWmV04WPNjo0zi2 Mh+cWcbzeAWMlNaA2OOvEsxm5ECKLwzienAh+fk72nLD/LAdEvWaS++P9TjLsX1A V7ZH0uImsfaZsPTO8admIpC3mIylKbBXru13UOHE7Ut3fY5p+/EIaYr/UKfgwhpY 0xcfV9fEg7QZHOjFfLXx =g6Y/ -----END PGP SIGNATURE----- --Apple-Mail=_DF80D8E8-629B-4F6F-A1A2-43C5A3584912-- From nobody Fri May 6 20:12:47 2016 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 0992A12D51F; Fri, 6 May 2016 20:12:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-seamless-base-11.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160507031244.7415.67901.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2016 20:12:44 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 03:12:44 -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 of the IETF. Title : Seamless Bidirectional Forwarding Detection (S-BFD) Authors : Carlos Pignataro Dave Ward Nobo Akiya Manav Bhatia Santosh Pallagatti Filename : draft-ietf-bfd-seamless-base-11.txt Pages : 21 Date : 2016-05-06 Abstract: This document defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. This document updates RFC5880. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bfd-seamless-base-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-base-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 6 20:12:55 2016 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 9F33C12D52F; Fri, 6 May 2016 20:12:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-seamless-ip-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160507031246.7341.1272.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2016 20:12:46 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 03:12:47 -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 of the IETF. Title : Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS Authors : Carlos Pignataro Dave Ward Nobo Akiya Filename : draft-ietf-bfd-seamless-ip-06.txt Pages : 8 Date : 2016-05-06 Abstract: This document defines procedures to use Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bfd-seamless-ip-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-ip-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 6 20:13:07 2016 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 99B4112D562; Fri, 6 May 2016 20:12:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-seamless-use-case-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160507031257.7480.58052.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2016 20:12:57 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 03:12:58 -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 of the IETF. Title : Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases Authors : Sam Aldrin Carlos Pignataro Greg Mirsky Nagendra Kumar Filename : draft-ietf-bfd-seamless-use-case-08.txt Pages : 15 Date : 2016-05-06 Abstract: This document describes various use cases for a Seamless Bidirectional Forwarding Detection (S-BFD), and provides requirements such that protocol mechanisms allow for a simplified detection of forwarding failures. These use cases support S-BFD, as a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, accelerating the establishment of a BFD session. S-BFD benefits include quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-use-case/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bfd-seamless-use-case-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-use-case-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 9 13:28:18 2016 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 5C28312D625; Mon, 9 May 2016 13:28:17 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" Subject: Document Action: 'Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases' to Informational RFC (draft-ietf-bfd-seamless-use-case-08.txt) X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160509202817.18418.37877.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2016 13:28:17 -0700 Archived-At: Cc: The IESG , rtg-bfd@ietf.org, draft-ietf-bfd-seamless-use-case@ietf.org, bfd-chairs@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 20:28:17 -0000 The IESG has approved the following document: - 'Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases' (draft-ietf-bfd-seamless-use-case-08.txt) as Informational RFC This document is the product of the Bidirectional Forwarding Detection Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-use-case/ Technical Summary This document provides various use cases and related requirements for Bidirectional Forwarding Detection (BFD) such that extensions could be developed to allow for simplified detection of forwarding failures. Working Group Summary The use cases are seen to enable the use of core BFD technologies in a fashion that leverages existing implementations and protocol machinery while providing a simplified and largely stateless infrastructure for continuity testing. While there were no objections for publishing this document, the WG also didn't show significant interest in it. Document Quality This document describes use cases. In general, the quality of the descriptions is good. Personnel Document Shepherd: Jeffrey Haas, co-chair BFD. Responsible Area Director: Alvaro Retana. From nobody Wed May 11 09:17:55 2016 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 E869112D1EB; Wed, 11 May 2016 09:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-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 OY1cBYWN1R8Q; Wed, 11 May 2016 09:17:51 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EA04312B04D; Wed, 11 May 2016 09:17:50 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 38B421E336; Wed, 11 May 2016 12:22:53 -0400 (EDT) Date: Wed, 11 May 2016 12:22:53 -0400 From: Jeffrey Haas To: Manav Bhatia Subject: Re: Replace "seamless" with "stateless" Message-ID: <20160511162253.GG7636@pfrc.org> References: <5D4A869A-1EDD-4EF8-9168-8F7AF7086F14@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "Les Ginsberg \(ginsberg\)" , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-base@ietf.org" , "bfd-chairs@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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 May 2016 16:17:53 -0000 On Tue, May 03, 2016 at 03:08:18PM +0530, Manav Bhatia wrote: > I am also with Les -- it'll make a great story to tell the kids some day on > what we were sniffing when we came up with "seamless" ! :-) > > Matter closed. Lets move on to addressing the IESG comments now. For the record, the reason I believe we eventually left it as "seamless" was some amount of name similarity with the suite of stuff working its way through MPLS as "seamless MPLS". And while these things make for interesting stories, it does mean some level of repeatedly explaining them to English as a second language speakers. (And don't get me started on the definition of "ephemeral" as was used in I2RS...) -- Jeff (who already has to explain to ESL speakers why some English speakers giggle about the name 'BFD') From nobody Wed May 11 09:30:46 2016 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 B040F12D09A for ; Wed, 11 May 2016 09:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-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 ZMUczF2aBMFs for ; Wed, 11 May 2016 09:30:44 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 33F9C12B02C for ; Wed, 11 May 2016 09:30:44 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 91B1E1E336; Wed, 11 May 2016 12:35:46 -0400 (EDT) Date: Wed, 11 May 2016 12:35:46 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: IETF 96 - shall we meet? Message-ID: <20160511163546.GH7636@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "Reshad Rahman \(rrahman\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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 May 2016 16:30:46 -0000 IETF 96 will be convening in Berlin July 17-22. BFD has not met recently, but our face to face meetings are driven by the need to advance work via in-person discussion. The chairs' perceived status of the Working Group is tracked on our wiki: https://wiki.tools.ietf.org/wg/bfd/trac/wiki Most of the recent WG attention has been spent on finishing IESG comments for S-BFD and we should hopefully be well on the way through the RFC Editor by the upcoming IETF, IESG telechat permitting. Our active work includes: - BFD Yang module (please comment!) - BFD Multipoint (likely WGLC ready with at least one implementation for the base document, and a trill use case for active tail). - Optimizing BFD Authentication - needs further discussion with security minded IETFers. We also have BFD related documents targeted for other WGs where we should consider providing comment, if needed: - BFD Directed Return Path (in MPLS), stalled. - draft-ietf-trill-p2mp-bfd - draft-nitish-vrrp-bfd - draft-spallagatti-bfd-vxlan (possibly BFD, possibly NVO3) And several other WG documents that are chartered but stalled (or dead?) If you believe you have an agenda item that's cause for the Working Group to meet, please respond to this thread. -- Jeff and Reshad From nobody Wed May 11 09:58:52 2016 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 1CA4D12D11C for ; Wed, 11 May 2016 09:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 VKe-pKNHaG5O for ; Wed, 11 May 2016 09:58:49 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 EF3AE12B02C for ; Wed, 11 May 2016 09:58:48 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id y69so20376163pfb.1 for ; Wed, 11 May 2016 09:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Ibqa2M3E7F9m335emF4I91cIuWSnTICXUHehBDwQWOA=; b=s4+J3b0338msTkaFmEPIzhQB4Iw62JztQbognljKEZcOwv/YU9cfpECwkRuznbKXrt TJSaT0Bx0iTiu08Duex0Lu2Ed9nXl2cWEX46LbSP3FsZusDVOfH47aSzxAQc9qh+yC62 CXzjLT2C8BU3Lthv37wJsk7oA0IBbzYfTKkepkibHmL5H/6NFNz2gqd6ShKXSBls2T57 /GVK+WgbmsgDphmqcSyW0w8HRGDITHH8izGhVOn7VyY7YW2phlwskQ2/wHQFIxq2xbiE KBdjN60Wu0JlUVWtKw9+kf/YYQIk2F0asxYNmlmhivbvfJnZTOoPOaRyRelXguL49NIS KCzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Ibqa2M3E7F9m335emF4I91cIuWSnTICXUHehBDwQWOA=; b=H30fRuM70gBaaxUAaK41SQLDwOuYjvSv66c/FxqQQi7xsdpJY/3+ebeV3U6to5Dqc2 bIaCiZkkNOuLwOp5js9G9wgB6GjcQ5kIRfbe2EDMnI4SO60JrF90SdtdFT+hdv7pjd5V icIj1G/pFCjBtV/Rr63FyQ7wClaChgruF/hinQcHO/r3h7YIzCnyXDi4zl9LrFtko45S bHr4DoNTC8qTaWxDFhQ2jyCuGB57qg0OLq/5jNKDuWyMwe3aUj02j0XcDpqkqD79EzaS GBdze412LKdB31++VSqf23ihoHJQhD+n/j2Qx4tk5iFPxT7hg5YHMW5V1Sapk8pUogd+ SxvQ== X-Gm-Message-State: AOPr4FVfMairLpdf1a/itsoIrM15hoJoc/opaAcB3zE7k6i+TmSHTzjnE5Ze9Ik/TRRYtw== X-Received: by 10.98.0.203 with SMTP id 194mr6507551pfa.126.1462985928587; Wed, 11 May 2016 09:58:48 -0700 (PDT) Received: from ?IPv6:2001:420:c0c8:1002::42d? ([2001:420:c0c8:1002::42d]) by smtp.gmail.com with ESMTPSA id b140sm13500588pfb.19.2016.05.11.09.58.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2016 09:58:47 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3FFBA0D2-1A27-484D-B836-BA6562957E3A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: IETF 96 - shall we meet? From: Mahesh Jethanandani In-Reply-To: <20160511163546.GH7636@pfrc.org> Date: Wed, 11 May 2016 09:58:45 -0700 Message-Id: <74487C77-1C06-44CC-8CE0-FADF0B229719@gmail.com> References: <20160511163546.GH7636@pfrc.org> To: Jeffrey Haas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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 May 2016 16:58:51 -0000 --Apple-Mail=_3FFBA0D2-1A27-484D-B836-BA6562957E3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 11, 2016, at 9:35 AM, Jeffrey Haas wrote: >=20 > IETF 96 will be convening in Berlin July 17-22. BFD has not met = recently, > but our face to face meetings are driven by the need to advance work = via > in-person discussion. >=20 > The chairs' perceived status of the Working Group is tracked on our = wiki: > https://wiki.tools.ietf.org/wg/bfd/trac/wiki >=20 > Most of the recent WG attention has been spent on finishing IESG = comments > for S-BFD and we should hopefully be well on the way through the RFC = Editor > by the upcoming IETF, IESG telechat permitting. Our active work = includes: >=20 > - BFD Yang module (please comment!) The BFD YANG model has undergone some changes that could use some = review. Expect an updated draft. > - BFD Multipoint (likely WGLC ready with at least one implementation = for the > base document, and a trill use case for active tail). > - Optimizing BFD Authentication - needs further discussion with = security > minded IETFers. And possibly a presentation in one of the other security focused WG?? >=20 > We also have BFD related documents targeted for other WGs where we = should > consider providing comment, if needed: >=20 > - BFD Directed Return Path (in MPLS), stalled. > - draft-ietf-trill-p2mp-bfd > - draft-nitish-vrrp-bfd > - draft-spallagatti-bfd-vxlan (possibly BFD, possibly NVO3) >=20 > And several other WG documents that are chartered but stalled (or = dead?) Not quite dead, but draft-ashesh-bfd-stability has been simplified, = posted earlier this year and could use some review. >=20 > If you believe you have an agenda item that's cause for the Working = Group to > meet, please respond to this thread. >=20 > -- Jeff and Reshad >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_3FFBA0D2-1A27-484D-B836-BA6562957E3A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On May 11, 2016, at 9:35 AM, Jeffrey Haas <jhaas@pfrc.org> = wrote:

IETF 96 will be convening in Berlin July 17-22.  BFD has = not met recently,
but our face to face meetings are driven = by the need to advance work via
in-person discussion.

The chairs' perceived status of the Working = Group is tracked on our wiki:
https://wiki.tools.ietf.org/wg/bfd/trac/wiki

Most of the recent WG attention has been spent = on finishing IESG comments
for S-BFD and we should = hopefully be well on the way through the RFC Editor
by the = upcoming IETF, IESG telechat permitting.  Our active work = includes:

- BFD Yang module (please = comment!)

The BFD YANG model has undergone some changes that = could use some review. Expect an updated draft.

- BFD Multipoint (likely WGLC ready with at least one = implementation for the
 base document, and a trill = use case for active tail).
- Optimizing BFD Authentication = - needs further discussion with security
 minded = IETFers.

And possibly a presentation in one of the other = security focused WG??


We also have = BFD related documents targeted for other WGs where we should
consider providing comment, if needed:

- BFD Directed Return Path (in MPLS), stalled.
- = draft-ietf-trill-p2mp-bfd
- draft-nitish-vrrp-bfd
- draft-spallagatti-bfd-vxlan (possibly BFD, possibly = NVO3)

And several other WG documents that = are chartered but stalled (or dead?)

Not quite = dead, but draft-ashesh-bfd-stability has been simplified, posted earlier = this year and could use some review.


If= you believe you have an agenda item that's cause for the Working Group = to
meet, please respond to this thread.

-- Jeff and Reshad


Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_3FFBA0D2-1A27-484D-B836-BA6562957E3A-- From nobody Wed May 11 10:49:11 2016 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 3E66D12D106 for ; Wed, 11 May 2016 10:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Qfy7bgFxuUQf for ; Wed, 11 May 2016 10:49:08 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 2AA4112D0F8 for ; Wed, 11 May 2016 10:49:07 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id t10so56152949ywa.0 for ; Wed, 11 May 2016 10:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=AUm+A8sRHVkXlFJ1s7Uyf43upAM1S/SgbR3T+bqR6X0=; b=yMRgw7BBocY9JGJJsaktR+jymLw/Wlw9wIh5QOuEJ7unSNaVpexnQbj/unPCOvCF4Y ytOur48xuhF1/LP2Adcp+AQsHvStdBfWfggmLrjYF5GCaEXjmL6JjMNsei+18R04sn9+ y9iZgG9UxCb7Ve9O4pC1wcibNLIn9BwkuGq/bacc2ZM6tNSKwcIWe3NYdZfvrrLVQIa2 041tfQw4hRo6T8CkPreScz2N5286eTFKd33HV1CNFG6swNgj9yiuGUZzSqp2ZOkO3X5v nHAr0pZ2j4GpZ6GK9MaIMwKOGQY2vriRlusAXpCFa3ruFStsGoYZOA3xT1QY3IqPXUdc wmaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=AUm+A8sRHVkXlFJ1s7Uyf43upAM1S/SgbR3T+bqR6X0=; b=l56D8JPLaB7vxrVfBZ9eULcEnAiZpggrCn7l5s7ueJaNIQCkAs/fXdQnE7PNny7LDr qnihY0gvWnyPV1DgDHgOTf4Fkq2bP5eEVx8Kz31AovUN75viABafrRUpojap4kfLBDst EkqIc73LHFnxBfn463YNFZ1NON10Xbn8ibWyaHRGNRHBT5k/WLtYOrOJGpsiBOWeKvuQ IxmwpQTArKIfAlhaAlrTmyIhxB0wp/h6xGHIb+4BMKGxY0JC9ysP0CJClZ2uu7BryEFH GXmsn5hlJKu+qdKDagMYms97XC7fnoTfBOOZ4Ffu3eZG/bDtNGaZPt6RxEvhryBNFDSn hfCw== X-Gm-Message-State: AOPr4FXk5wLvmj4rVauBoezA6jiqEUHdhY6iU6/Xd0NmY/7MYcdUjhEk+T0VxtXSbPyIggqyHZBU/ZZd5DyhTA== MIME-Version: 1.0 X-Received: by 10.37.32.193 with SMTP id g184mr2117259ybg.120.1462988947238; Wed, 11 May 2016 10:49:07 -0700 (PDT) Received: by 10.37.198.151 with HTTP; Wed, 11 May 2016 10:49:07 -0700 (PDT) In-Reply-To: <20160511163546.GH7636@pfrc.org> References: <20160511163546.GH7636@pfrc.org> Date: Wed, 11 May 2016 10:49:07 -0700 Message-ID: Subject: Re: IETF 96 - shall we meet? From: Greg Mirsky To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a1143e0d882b827053294a82c Archived-At: Cc: "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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 May 2016 17:49:10 -0000 --001a1143e0d882b827053294a82c Content-Type: text/plain; charset=UTF-8 Hi Chairs, BFD community, two drafts, draft-tanmir-rtgwg-bfd-mc-lag-ip and draft-tanmir-rtgwg-bfd-mc-lag-mpls*, * were referred to BFD WG in BA that clarify use of micro-BFD over MC-LAG interfaces in IP and IP/MPLS network respectively. Authors would appreciate opportunity to present and discuss. Regards, Greg On Wed, May 11, 2016 at 9:35 AM, Jeffrey Haas wrote: > IETF 96 will be convening in Berlin July 17-22. BFD has not met recently, > but our face to face meetings are driven by the need to advance work via > in-person discussion. > > The chairs' perceived status of the Working Group is tracked on our wiki: > https://wiki.tools.ietf.org/wg/bfd/trac/wiki > > Most of the recent WG attention has been spent on finishing IESG comments > for S-BFD and we should hopefully be well on the way through the RFC Editor > by the upcoming IETF, IESG telechat permitting. Our active work includes: > > - BFD Yang module (please comment!) > - BFD Multipoint (likely WGLC ready with at least one implementation for > the > base document, and a trill use case for active tail). > - Optimizing BFD Authentication - needs further discussion with security > minded IETFers. > > We also have BFD related documents targeted for other WGs where we should > consider providing comment, if needed: > > - BFD Directed Return Path (in MPLS), stalled. > - draft-ietf-trill-p2mp-bfd > - draft-nitish-vrrp-bfd > - draft-spallagatti-bfd-vxlan (possibly BFD, possibly NVO3) > > And several other WG documents that are chartered but stalled (or dead?) > > If you believe you have an agenda item that's cause for the Working Group > to > meet, please respond to this thread. > > -- Jeff and Reshad > > --001a1143e0d882b827053294a82c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Chairs, BFD community,
two drafts,=C2=A0draft-tanmir-r= tgwg-bfd-mc-lag-ip and=C2=A0draft-tanmir-rtgwg-bfd= -mc-lag-mpls,=C2=A0=C2=A0were referred to BFD WG in BA that c= larify use of micro-BFD over MC-LAG interfaces in IP and IP/MPLS network re= spectively. Authors would appreciate opportunity to present and discuss.

Regards, Greg
=
On Wed, May 11, 2016 at 9:35 AM, Jeffrey Haa= s <jhaas@pfrc.org> wrote:
IET= F 96 will be convening in Berlin July 17-22.=C2=A0 BFD has not met recently= ,
but our face to face meetings are driven by the need to advance work via in-person discussion.

The chairs' perceived status of the Working Group is tracked on our wik= i:
https://wiki.tools.ietf.org/wg/bfd/trac/wiki

Most of the recent WG attention has been spent on finishing IESG comments for S-BFD and we should hopefully be well on the way through the RFC Editor=
by the upcoming IETF, IESG telechat permitting.=C2=A0 Our active work inclu= des:

- BFD Yang module (please comment!)
- BFD Multipoint (likely WGLC ready with at least one implementation for th= e
=C2=A0 base document, and a trill use case for active tail).
- Optimizing BFD Authentication - needs further discussion with security =C2=A0 minded IETFers.

We also have BFD related documents targeted for other WGs where we should consider providing comment, if needed:

- BFD Directed Return Path (in MPLS), stalled.
- draft-ietf-trill-p2mp-bfd
- draft-nitish-vrrp-bfd
- draft-spallagatti-bfd-vxlan (possibly BFD, possibly NVO3)

And several other WG documents that are chartered but stalled (or dead?)
If you believe you have an agenda item that's cause for the Working Gro= up to
meet, please respond to this thread.

-- Jeff and Reshad


--001a1143e0d882b827053294a82c-- From nobody Wed May 11 12:19:03 2016 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 3A61912D798; Wed, 11 May 2016 12:18:57 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" Subject: Protocol Action: 'Seamless Bidirectional Forwarding Detection (S-BFD)' to Proposed Standard (draft-ietf-bfd-seamless-base-11.txt) X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160511191857.15211.21954.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2016 12:18:57 -0700 Archived-At: Cc: The IESG , rtg-bfd@ietf.org, draft-ietf-bfd-seamless-base@ietf.org, bfd-chairs@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 19:18:57 -0000 The IESG has approved the following document: - 'Seamless Bidirectional Forwarding Detection (S-BFD)' (draft-ietf-bfd-seamless-base-11.txt) as Proposed Standard This document is the product of the Bidirectional Forwarding Detection Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ Technical Summary This document defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. Working Group Summary This document was discussed at length with significant participation of the active members of the Bidirectional Forwarding Detection (BFD) Working Group. The use cases are seen to enable the use of core BFD technologies in a fashion that leverages existing implementations and protocol machinery while providing a simplified and largely stateless infrastructure for continuity testing. The high participation of the Working Group has ensured that the technical aspects of this mechanism have been thoroughly discussed. Document Quality This document has been subject to multiple Working Group reviews and includes participation from several large vendors. Many of these vendors have implementations in progress for this feature. Personnel Document Shepherd: Jeffrey Haas, co-chair BFD. Responsible Area Director: Alvaro Retana. From nobody Wed May 11 12:29:43 2016 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 6A62212D7D3; Wed, 11 May 2016 12:29:41 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" Subject: Protocol Action: 'Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS' to Proposed Standard (draft-ietf-bfd-seamless-ip-06.txt) X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160511192941.15162.98727.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2016 12:29:41 -0700 Archived-At: Cc: draft-ietf-bfd-seamless-ip@ietf.org, The IESG , rtg-bfd@ietf.org, bfd-chairs@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 19:29:41 -0000 The IESG has approved the following document: - 'Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS' (draft-ietf-bfd-seamless-ip-06.txt) as Proposed Standard This document is the product of the Bidirectional Forwarding Detection Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ Technical Summary This document defines procedures to use Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS environments. Working Group Summary This document was discussed at length with significant participation of the active members of the Bidirectional Forwarding Detection (BFD) Working Group. Document Quality This document has been subject to multiple Working Group reviews and includes participation from several large vendors. Many of these vendors have implementations in progress for this feature. Personnel Document Shepherd: Jeffrey Haas, co-chair BFD. Responsible Area Director: Alvaro Retana. From nobody Fri May 13 13:13:44 2016 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 B022C12B039; Fri, 13 May 2016 13:13:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Subject: bfd - New Meeting Session Request for IETF 96 X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160513201342.10620.14938.idtracker@ietfa.amsl.com> Date: Fri, 13 May 2016 13:13:42 -0700 Archived-At: Cc: rtg-bfd@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 20:13:43 -0000 A new meeting session request has just been submitted by Jeffrey Haas, a Chair of the bfd working group. --------------------------------------------------------- Working Group Name: Bidirectional Forwarding Detection Area Name: Routing Area Session Requester: Jeffrey Haas Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: idr,i2rs,mpls,sfc,spring,bier,lime Second Priority: bess,isis,nvo3,ospf,pals,rtgwg,teas Special Requests: --------------------------------------------------------- From nobody Fri May 13 13:18:19 2016 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 218BB12D0EE for ; Fri, 13 May 2016 13:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-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 j9nVSUdzsYQR for ; Fri, 13 May 2016 13:18:15 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C8C5512B039 for ; Fri, 13 May 2016 13:18:15 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6AA2D1E336; Fri, 13 May 2016 16:23:21 -0400 (EDT) Date: Fri, 13 May 2016 16:23:21 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: IETF 96 - shall we meet? Message-ID: <20160513202321.GF6332@pfrc.org> References: <20160511163546.GH7636@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160511163546.GH7636@pfrc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "Reshad Rahman \(rrahman\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 13 May 2016 20:18:17 -0000 On Wed, May 11, 2016 at 12:35:46PM -0400, Jeffrey Haas wrote: > If you believe you have an agenda item that's cause for the Working Group to > meet, please respond to this thread. With in and out of thread responses, I think we have enough agenda items to meet. I have requested a one hour session. If you have further agenda requests, please continue to respond in-thread. -- Jeff and Reshad From nobody Mon May 23 06:13:07 2016 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 D82A412D8A0 for ; Mon, 23 May 2016 06:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-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 pmqxmSTXr_64 for ; Mon, 23 May 2016 06:13:05 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E73EB12D89F for ; Mon, 23 May 2016 06:13:04 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2365E1E335; Mon, 23 May 2016 09:18:25 -0400 (EDT) Date: Mon, 23 May 2016 09:18:25 -0400 From: Jeffrey Haas To: Mahesh Jethanandani Subject: Re: IETF 96 - shall we meet? Message-ID: <20160523131824.GC11285@pfrc.org> References: <20160511163546.GH7636@pfrc.org> <74487C77-1C06-44CC-8CE0-FADF0B229719@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74487C77-1C06-44CC-8CE0-FADF0B229719@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 13:13:06 -0000 Mahesh, On Wed, May 11, 2016 at 09:58:45AM -0700, Mahesh Jethanandani wrote: > > - Optimizing BFD Authentication - needs further discussion with security > > minded IETFers. > > And possibly a presentation in one of the other security focused WG?? Could the authors please kick off the necessary discussion in the saag list? This one is complicated enough that it should start at the mic in the security open area meeting. -- Jeff From nobody Mon May 23 06:13:56 2016 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 3300F12D8AB for ; Mon, 23 May 2016 06:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-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 2_PxkSZb7Hs1 for ; Mon, 23 May 2016 06:13:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4755212D8A9 for ; Mon, 23 May 2016 06:13:49 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C22581E335; Mon, 23 May 2016 09:19:08 -0400 (EDT) Date: Mon, 23 May 2016 09:19:08 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: IETF 96 - shall we meet? Message-ID: <20160523131908.GD11285@pfrc.org> References: <20160511163546.GH7636@pfrc.org> <20160513202321.GF6332@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160513202321.GF6332@pfrc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "Reshad Rahman \(rrahman\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 13:13:54 -0000 On Fri, May 13, 2016 at 04:23:21PM -0400, Jeffrey Haas wrote: > On Wed, May 11, 2016 at 12:35:46PM -0400, Jeffrey Haas wrote: > > If you believe you have an agenda item that's cause for the Working Group to > > meet, please respond to this thread. > > With in and out of thread responses, I think we have enough agenda items to > meet. I have requested a one hour session. > > If you have further agenda requests, please continue to respond in-thread. A candidate agenda is posted in the BFD wiki: https://wiki.tools.ietf.org/wg/bfd/trac/wiki/IETF96%20Agenda -- Jeff From nobody Mon May 23 08:16:07 2016 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 D570D12D91A; Mon, 23 May 2016 08:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 QoE9akJ1gppf; Mon, 23 May 2016 08:16:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 B6B2912D952; Mon, 23 May 2016 08:15:52 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 0B08BDEC7D638; Mon, 23 May 2016 15:15:48 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4NFFoIV025431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2016 15:15:51 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4NFFb4u015879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 May 2016 17:15:50 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 23 May 2016 17:15:15 +0200 From: "Bocci, Matthew (Nokia - GB)" To: "Vengada Prasad Govindan (venggovi)" , "rtg-bfd@ietf.org" , "nvo3@ietf.org" Subject: Re: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt Thread-Topic: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt Thread-Index: AQHRtQXoVa0S8S9xaU+XVruc41hGuA== Date: Mon, 23 May 2016 15:15:15 +0000 Message-ID: References: <20160416060248.17419.11591.idtracker@ietfa.amsl.com> <8f73ecae119843dcba447c54084c80f8@XCH-RCD-020.cisco.com> In-Reply-To: <8f73ecae119843dcba447c54084c80f8@XCH-RCD-020.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 15:16:05 -0000 Folks Please could you direct any discussion on this draft to the NVO3 working group list. Regards Matthew On 18/04/2016, 07:54, "nvo3 on behalf of Vengada Prasad Govindan (venggovi)" wrote: >Hello all, > The authors request comments on the draft below. >Thanks >Prasad > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Saturday, April 16, 2016 11:33 AM >To: MALLIK MUDIGONDA (mmudigon) ; Basil Saji >; Greg Mirsky ; Vengada >Prasad Govindan (venggovi) ; Juniper Networks >; Sudarsan Paragiri ; >Santosh Pallagatti ; sajibasil@gmail.com > >Subject: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt > > >A new version of I-D, draft-spallagatti-bfd-vxlan-03.txt >has been successfully submitted by Vengada Prasad Govindan and posted to >the IETF repository. > >Name: draft-spallagatti-bfd-vxlan >Revision: 03 >Title: BFD for VXLAN >Document date: 2016-04-15 >Group: Individual Submission >Pages: 9 >URL: =20 >https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan-03.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ >Htmlized: https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-03 >Diff: =20 >https://www.ietf.org/rfcdiff?url2=3Ddraft-spallagatti-bfd-vxlan-03 > >Abstract: > This document describes use of Bidirectional Forwarding Detection > (BFD) protocol for VXLAN . > > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 From nobody Mon May 23 09:57:50 2016 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 80E1412DA26; Mon, 23 May 2016 09:57:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-multipoint-active-tail-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160523165748.21008.69270.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 09:57:48 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 16:57:48 -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 of the IETF. Title : BFD Multipoint Active Tails. Authors : Dave Katz Dave Ward Santosh Pallagatti Filename : draft-ietf-bfd-multipoint-active-tail-02.txt Pages : 17 Date : 2016-05-20 Abstract: This document describes active tail extensions to the Bidirectional Forwarding Detection (BFD) protocol for multipoint and multicast networks. Comments on this draft should be directed to rtg- bfd@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-active-tail-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 23 12:47:30 2016 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 C483A12D555; Mon, 23 May 2016 12:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 EnzhoeC0Dtxq; Mon, 23 May 2016 12:47:24 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 2083312D560; Mon, 23 May 2016 12:47:24 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id o16so63603534ywd.2; Mon, 23 May 2016 12:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Z3tW36UIGsVdX/PhTHcsWS4vv3wyTc8Q17TzrLvq+gU=; b=ZEoh0lAb6+S2VLPQRRh1gY8QqTnR0lVQNRVTJkqoQnm+HF4leIhCZElnmxa0W/8K78 fF0uViYQ7dJSNUt/LT+6NwpdAQrChlNOdZXyfbaZJ9/pXM263D31EYaN6d97XXR5hfVo B1tUM2IL40RprOf41nzY6GT63WKysTwCYfjh/CxvCN79erAlGSDRn3OKfGSTubzY8BaX XN08r2UsHNjFFR8zQoicGNpENAnYoh0uNPNnPJ9o45QZu0zV0aP8szjjDaIyLGNXWI2Y 1+GOmP0v6I2qdPW1CQ9l6bEEyNMxokWmamSGXMGTvvEz3cKQIVo8bZOUN8KbQeCSuzo7 K2wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Z3tW36UIGsVdX/PhTHcsWS4vv3wyTc8Q17TzrLvq+gU=; b=JkshQ7uB4qibh69KvUGD/hdmEsVT4zRXexwxJuJwaeZrB1uYUuisbqL9VHnPSP2U/B NovT0n393cJZ89qEo89GpNAus1nDQYPTiYDzpN7KVKRr3/LFggD3Uyc6N8lS6cP2tKfJ Fv+wnsQTbPeYilzrH8pCi8lTcbLwlRNVYom4NWcROlHl1ibL6YyrboUZxapMI4ERpUEp pnL2FcSnhNF37RIZ5ngat/SVi7Y3bBCsqycEErkNeZMRzF8rLp4QIRdobFb6jWvD6b8b WMGQplDFV3yJ9dgin/QIUP1WAabC1KnD41aUeJvBCvLOTmn3rOHiJeG1eJfR+z2JmVil c6Ww== X-Gm-Message-State: ALyK8tLsGO41byhe/wlCB63+ATzEHGGAQFqBmmj19bQ75afGgCiS0RlWVLTDSHoc1qFm/z5ezD8F/ZjhpP+ZrA== MIME-Version: 1.0 X-Received: by 10.129.91.132 with SMTP id p126mr384645ywb.188.1464032843261; Mon, 23 May 2016 12:47:23 -0700 (PDT) Received: by 10.37.229.72 with HTTP; Mon, 23 May 2016 12:47:23 -0700 (PDT) In-Reply-To: References: <20160416060248.17419.11591.idtracker@ietfa.amsl.com> <8f73ecae119843dcba447c54084c80f8@XCH-RCD-020.cisco.com> Date: Mon, 23 May 2016 12:47:23 -0700 Message-ID: Subject: Re: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt From: Greg Mirsky To: Anoop Ghanwani Content-Type: multipart/alternative; boundary=001a114c78628fefe9053387b51e Archived-At: Cc: rtgwg-ooam-dt@ietf.org, "rtg-bfd@ietf.org" , "nvo3@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 19:47:27 -0000 --001a114c78628fefe9053387b51e Content-Type: text/plain; charset=UTF-8 +BFD WG and RTGWG OOAM DT Hi Anoop, thank you for your review and the question. The scope of this draft is only for the VXLAN. The Overlay OAM Desing Team is working on the Requirements, Gap Analysis and, if there will be required, enhancements and/or new OAM protocols for BIER, NSH, VXLAN-GPE, GENEVE, and GUE, as defined in its charter. Would appreciate you review and comments of the two documents the OOAM-DT already presented in BA meeting: - OOAM Requirements - OAM for Overlay Networks: Gap analysis In the latter you'll find the example to demonstrate applicability of BFD Async mode in BIER domain. As we've discussed, other BFD may be applied to other overlay networks that I've listed above even though their method of indication OAM payload may be different from BIER. Would you agree, or suggest to have another example of BFD? Regards, Greg On Mon, May 23, 2016 at 12:26 PM, Anoop Ghanwani wrote: > Authors, > > In section 4.1, you have this: > >>> > > Next Protocol Field in GPE header MUST be set to IPv4 or IPv6. > ... > The BFD packet MUST be carried inside the inner MAC frame of the > VxLAN packet. The inner MAC frame carrying the BFD payload has the > following format: > > >>> > > These two statements seem to contradict each other. If the GPE header > indicates IPv4 or IPv6, then how can the BFD packet be encapsulated within > a MAC frame? > > Can you please clarify? > > Thanks, > Anoop > > > On Mon, May 23, 2016 at 8:15 AM, Bocci, Matthew (Nokia - GB) < > matthew.bocci@nokia.com> wrote: > >> Folks >> >> Please could you direct any discussion on this draft to the NVO3 working >> group list. >> >> Regards >> >> Matthew >> >> On 18/04/2016, 07:54, "nvo3 on behalf of Vengada Prasad Govindan >> (venggovi)" >> wrote: >> >> >Hello all, >> > The authors request comments on the draft below. >> >Thanks >> >Prasad >> > >> >-----Original Message----- >> >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> >Sent: Saturday, April 16, 2016 11:33 AM >> >To: MALLIK MUDIGONDA (mmudigon) ; Basil Saji >> >; Greg Mirsky ; Vengada >> >Prasad Govindan (venggovi) ; Juniper Networks >> >; Sudarsan Paragiri ; >> >Santosh Pallagatti ; sajibasil@gmail.com >> > >> >Subject: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt >> > >> > >> >A new version of I-D, draft-spallagatti-bfd-vxlan-03.txt >> >has been successfully submitted by Vengada Prasad Govindan and posted to >> >the IETF repository. >> > >> >Name: draft-spallagatti-bfd-vxlan >> >Revision: 03 >> >Title: BFD for VXLAN >> >Document date: 2016-04-15 >> >Group: Individual Submission >> >Pages: 9 >> >URL: >> >https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan-03.txt >> >Status: >> >https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ >> >Htmlized: >> https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-03 >> >Diff: >> >https://www.ietf.org/rfcdiff?url2=draft-spallagatti-bfd-vxlan-03 >> > >> >Abstract: >> > This document describes use of Bidirectional Forwarding Detection >> > (BFD) protocol for VXLAN . >> > >> > >> > >> > >> > >> > >> >Please note that it may take a couple of minutes from the time of >> >submission until the htmlized version and diff are available at >> >tools.ietf.org. >> > >> >The IETF Secretariat >> > >> >_______________________________________________ >> >nvo3 mailing list >> >nvo3@ietf.org >> >https://www.ietf.org/mailman/listinfo/nvo3 >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > --001a114c78628fefe9053387b51e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+BFD WG and RTGWG OOAM DT

Hi Anoop,
thank you for your review and the question. The scope of this draft = is only for the VXLAN. The Overlay OAM Desing Team is working on the Requir= ements, Gap Analysis and, if there will be required, enhancements and/or ne= w OAM protocols for=C2=A0BIER, NSH, VXLAN-GPE, = GENEVE, and GUE, as defined in its charter. Would appreciate you review and= comments of the two documents the OOAM-DT already presented in BA meeting:=
  • OOAM Requirements<= /font>
  • OAM for Overlay Networks: Gap analys= is
In the latter you'll = find the example to demonstrate applicability of BFD Async mode in BIER dom= ain. As we've discussed, other BFD may be applied to other overlay netw= orks that I've listed above even though their method of indication OAM = payload may be different from BIER. Would you agree, or suggest to have ano= ther example of BFD?

=
Regards, Greg

On M= on, May 23, 2016 at 12:26 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
Aut= hors,

In section 4.1, you have this:
>>&= gt;
   Next Protocol Field in GPE header MUST be set to=
 IPv4 or IPv6.
...
   The BFD packet MUST be carried inside the inner MAC frame of the
   VxLAN packet.  The inner MAC frame carrying the BFD payload has the
   following format:
>>>

= These two statements seem to contradict each other.=C2=A0 If the GPE header= indicates IPv4 or IPv6, then how can the BFD packet be encapsulated within= a MAC frame?

Can you please clarify?
Thanks,
Anoop


On Mon, May 23, 2016 at 8:15 AM, Bocci, Matthew (Nokia - GB) <= span dir=3D"ltr"><matthew.bocci@nokia.com> wrote:
Folks

Please could you direct any discussion on this draft to the NVO3 working group list.

Regards

Matthew

On 18/04/2016, 07:54, "nvo3 on behalf of Vengada Prasad Govindan
(venggovi)" <nvo3-bounces@ietf.org on behalf of venggovi@cisco.com> wrote:

>Hello all,
>=C2=A0 The authors request comments on the draft below.
>Thanks
>Prasad
>
>-----Original Message-----
>From: int= ernet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>Sent: Saturday, April 16, 2016 11:33 AM
>To: MALLIK MUDIGONDA (mmudigon) <mmudigon@cisco.com>; Basil Saji
><sbasil@juni= per.net>; Greg Mirsky <gregory.mirsky@ericsson.com>; Vengada
>Prasad Govindan (venggovi) <venggovi@cisco.com>; Juniper Networks
><santoshp= k@juniper.net>; Sudarsan Paragiri <sparagiri@juniper.net>;
>Santosh Pallagatti <santoshpk@juniper.net>; sajibasil@gmail.com
><sbasil@juni= per.net>
>Subject: New Version Notification for draft-spallagatti-bfd-vxlan-03.tx= t
>
>
>A new version of I-D, draft-spallagatti-bfd-vxlan-03.txt
>has been successfully submitted by Vengada Prasad Govindan and posted t= o
>the IETF repository.
>
>Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-spallagatti-bfd-vxlan
>Revision:=C2=A0 =C2=A0 =C2=A0 03
>Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD for VXLAN
>Document date: 2016-04-15
>Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
>Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A09
>URL:
>https://www.ietf.org/inte= rnet-drafts/draft-spallagatti-bfd-vxlan-03.txt
>Status:
>https://datatracker.ietf.org/doc/dr= aft-spallagatti-bfd-vxlan/
>Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-03
>Diff:
>https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-spallagatti-bfd-vxlan-03
>
>Abstract:
>=C2=A0 =C2=A0This document describes use of Bidirectional Forwarding De= tection
>=C2=A0 =C2=A0(BFD) protocol for VXLAN .
>
>
>
>
>
>
>Please note that it may take a couple of minutes from the time of
>submission until the htmlized version and diff are available at
>= tools.ietf.org.
>
>The IETF Secretariat
>
>_______________________________________________
>nvo3 mailing list
>nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


--001a114c78628fefe9053387b51e-- From nobody Mon May 23 12:49:07 2016 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 D9C3812DB02; Mon, 23 May 2016 12:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 AK5MYJ6n_U9v; Mon, 23 May 2016 12:49:02 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 CFC1712D568; Mon, 23 May 2016 12:49:01 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id o16so63646960ywd.2; Mon, 23 May 2016 12:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=dk73HACA0Nj8dT1qXYtJ7ureyqqTB+ik/cwAEjA+xSY=; b=R7h7KX269yxeFN8785gz2Rugc4BwEQwiuihApOCyPX5+03AHkr+CH8U9iMWKZotbmN 0f9OGoZkwnY5Nu/RWHSo65YEbdRZZbZpqOS5jTpPGEwM/qkyWcVpUgjkKoia1iXhee+P 0Pgmu2PoIm1ocmHF5mkg8r4g5TD5YFTrm+6pyVvtWcRnLsUJja3avCTaz+bp6XbsFHdL DVq0Hp0kwmY+CkQ3qNkAfqLax4E/Ml/vy2SipSvy7qf5v30WYwoZuPOY48m6KY2C0Utd Wh/jrYig0JkzkLBUhgsDnNcc0xJWYD4kCSxlEamPsq6ZC9eyyrR9wcA5yXz8Ubm2LVmh F+UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=dk73HACA0Nj8dT1qXYtJ7ureyqqTB+ik/cwAEjA+xSY=; b=aDLrMAx2jMj3S4FCEzEq9MZw6n/EdwvNyaBkKppLLg5iTl+sNVUm3SLBAb4kubXyXX HPj/S9mV1QAT78FJ8cNMk8C9216OsZY9LUxxXwyRq9Tg0rvkv1lJGu5Gls7wdi7AVyj4 igOjNfAKACcncz4e2N6Y4DJiIip57Md32ArCVhDbq/Ct8A/x7juQjB6hHQOHfl6a8/DY f4fLO3ex7U1P6qgt4LNiaBAWrQsOvnrdEBn/4HQDfzJn/i4MSPH0Lrhe1k6tS014IXEm mkGUU8Hv2OSp8zN36XdD8OoNYDCZ9fBfeTCTXQY4ADkpwQWwzU/kNLF7++iLm4E6U8kb bLaA== X-Gm-Message-State: ALyK8tLdhFddYvQN8fd2n166UFuUzbzD2Z0DnJ0dAvzP0i10JNQ8NJfC+d7vehbbpap1oIcYQbtk4xeG5TAO9w== MIME-Version: 1.0 X-Received: by 10.13.193.134 with SMTP id c128mr397530ywd.270.1464032940974; Mon, 23 May 2016 12:49:00 -0700 (PDT) Received: by 10.37.229.72 with HTTP; Mon, 23 May 2016 12:49:00 -0700 (PDT) In-Reply-To: References: <20160416060248.17419.11591.idtracker@ietfa.amsl.com> <8f73ecae119843dcba447c54084c80f8@XCH-RCD-020.cisco.com> Date: Mon, 23 May 2016 12:49:00 -0700 Message-ID: Subject: Re: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt From: Greg Mirsky To: Anoop Ghanwani Content-Type: multipart/alternative; boundary=001a114e70c662e729053387bbe2 Archived-At: Cc: rtg-ooam-dt@ietf.org, "rtg-bfd@ietf.org" , "nvo3@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 19:49:05 -0000 --001a114e70c662e729053387bbe2 Content-Type: text/plain; charset=UTF-8 Now with the correct OOAM-DT address On Mon, May 23, 2016 at 12:47 PM, Greg Mirsky wrote: > +BFD WG and RTGWG OOAM DT > > Hi Anoop, > thank you for your review and the question. The scope of this draft is > only for the VXLAN. The Overlay OAM Desing Team is working on the > Requirements, Gap Analysis and, if there will be required, enhancements > and/or new OAM protocols for BIER, NSH, VXLAN-GPE, GENEVE, and GUE, as > defined in its charter. Would appreciate you review and comments of the two > documents the OOAM-DT already presented in BA meeting: > > - OOAM Requirements > - OAM for Overlay Networks: Gap analysis > > In the latter you'll find the example to demonstrate applicability of BFD > Async mode in BIER domain. As we've discussed, other BFD may be applied to > other overlay networks that I've listed above even though their method of > indication OAM payload may be different from BIER. Would you agree, or > suggest to have another example of BFD? > > Regards, Greg > > On Mon, May 23, 2016 at 12:26 PM, Anoop Ghanwani > wrote: > >> Authors, >> >> In section 4.1, you have this: >> >>> >> >> Next Protocol Field in GPE header MUST be set to IPv4 or IPv6. >> ... >> The BFD packet MUST be carried inside the inner MAC frame of the >> VxLAN packet. The inner MAC frame carrying the BFD payload has the >> following format: >> >> >>> >> >> These two statements seem to contradict each other. If the GPE header >> indicates IPv4 or IPv6, then how can the BFD packet be encapsulated within >> a MAC frame? >> >> Can you please clarify? >> >> Thanks, >> Anoop >> >> >> On Mon, May 23, 2016 at 8:15 AM, Bocci, Matthew (Nokia - GB) < >> matthew.bocci@nokia.com> wrote: >> >>> Folks >>> >>> Please could you direct any discussion on this draft to the NVO3 working >>> group list. >>> >>> Regards >>> >>> Matthew >>> >>> On 18/04/2016, 07:54, "nvo3 on behalf of Vengada Prasad Govindan >>> (venggovi)" >>> wrote: >>> >>> >Hello all, >>> > The authors request comments on the draft below. >>> >Thanks >>> >Prasad >>> > >>> >-----Original Message----- >>> >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> >Sent: Saturday, April 16, 2016 11:33 AM >>> >To: MALLIK MUDIGONDA (mmudigon) ; Basil Saji >>> >; Greg Mirsky ; >>> Vengada >>> >Prasad Govindan (venggovi) ; Juniper Networks >>> >; Sudarsan Paragiri ; >>> >Santosh Pallagatti ; sajibasil@gmail.com >>> > >>> >Subject: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt >>> > >>> > >>> >A new version of I-D, draft-spallagatti-bfd-vxlan-03.txt >>> >has been successfully submitted by Vengada Prasad Govindan and posted to >>> >the IETF repository. >>> > >>> >Name: draft-spallagatti-bfd-vxlan >>> >Revision: 03 >>> >Title: BFD for VXLAN >>> >Document date: 2016-04-15 >>> >Group: Individual Submission >>> >Pages: 9 >>> >URL: >>> >https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan-03.txt >>> >Status: >>> >https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ >>> >Htmlized: >>> https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-03 >>> >Diff: >>> >https://www.ietf.org/rfcdiff?url2=draft-spallagatti-bfd-vxlan-03 >>> > >>> >Abstract: >>> > This document describes use of Bidirectional Forwarding Detection >>> > (BFD) protocol for VXLAN . >>> > >>> > >>> > >>> > >>> > >>> > >>> >Please note that it may take a couple of minutes from the time of >>> >submission until the htmlized version and diff are available at >>> >tools.ietf.org. >>> > >>> >The IETF Secretariat >>> > >>> >_______________________________________________ >>> >nvo3 mailing list >>> >nvo3@ietf.org >>> >https://www.ietf.org/mailman/listinfo/nvo3 >>> >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >> >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> > --001a114e70c662e729053387bbe2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Now with the correct OOAM-DT address

On Mon, May 23, 2016 at 12:47 PM,= Greg Mirsky <gregimirsky@gmail.com> wrote:
+BFD WG and RTGWG OOAM DT

Hi Anoop,
thank you for your review and the question. Th= e scope of this draft is only for the VXLAN. The Overlay OAM Desing Team is= working on the Requirements, Gap Analysis and, if there will be required, = enhancements and/or new OAM protocols for=C2=A0= BIER, NSH, VXLAN-GPE, GENEVE, and GUE, as defined in its charter. Would app= reciate you review and comments of the two documents the OOAM-DT already pr= esented in BA meeting:
  • OOA= M Requirements
  • OAM for Overla= y Networks: Gap analysis
In = the latter you'll find the example to demonstrate applicability of BFD = Async mode in BIER domain. As we've discussed, other BFD may be applied= to other overlay networks that I've listed above even though their met= hod of indication OAM payload may be different from BIER. Would you agree, = or suggest to have another example of BFD?

Rega= rds, Greg
=

On Mon, May 23, 2= 016 at 12:26 PM, Anoop Ghanwani <anoop@alumni.duke.edu> = wrote:
Authors,

=
In section 4.1, you have this:
>>>
= 
   Next Protocol Field in GPE header MUST be set to IPv4 or IPv6.
...
   The BFD packet MUST be carried inside the inner MAC frame of the
   VxLAN packet.  The inner MAC frame carrying the BFD payload has the
   following format:
>>>

= These two statements seem to contradict each other.=C2=A0 If the GPE header= indicates IPv4 or IPv6, then how can the BFD packet be encapsulated within= a MAC frame?

Can you please clarify?
Thanks,
Anoop


On Mon, May 23, 201= 6 at 8:15 AM, Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com> wrote:
Folks

Please could you direct any discussion on this draft to the NVO3 working group list.

Regards

Matthew

On 18/04/2016, 07:54, "nvo3 on behalf of Vengada Prasad Govindan
(venggovi)" <nvo3-bounces@ietf.org on behalf of venggovi@cisco.com> wrote:

>Hello all,
>=C2=A0 The authors request comments on the draft below.
>Thanks
>Prasad
>
>-----Original Message-----
>From: int= ernet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>Sent: Saturday, April 16, 2016 11:33 AM
>To: MALLIK MUDIGONDA (mmudigon) <mmudigon@cisco.com>; Basil Saji
><sbasil@juni= per.net>; Greg Mirsky <gregory.mirsky@ericsson.com>; Vengada
>Prasad Govindan (venggovi) <venggovi@cisco.com>; Juniper Networks
><santoshp= k@juniper.net>; Sudarsan Paragiri <sparagiri@juniper.net>;
>Santosh Pallagatti <santoshpk@juniper.net>; sajibasil@gmail.com
><sbasil@juni= per.net>
>Subject: New Version Notification for draft-spallagatti-bfd-vxlan-03.tx= t
>
>
>A new version of I-D, draft-spallagatti-bfd-vxlan-03.txt
>has been successfully submitted by Vengada Prasad Govindan and posted t= o
>the IETF repository.
>
>Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-spallagatti-bfd-vxlan
>Revision:=C2=A0 =C2=A0 =C2=A0 03
>Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD for VXLAN
>Document date: 2016-04-15
>Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
>Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A09
>URL:
>https://www.ietf.org/inte= rnet-drafts/draft-spallagatti-bfd-vxlan-03.txt
>Status:
>https://datatracker.ietf.org/doc/dr= aft-spallagatti-bfd-vxlan/
>Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-03
>Diff:
>https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-spallagatti-bfd-vxlan-03
>
>Abstract:
>=C2=A0 =C2=A0This document describes use of Bidirectional Forwarding De= tection
>=C2=A0 =C2=A0(BFD) protocol for VXLAN .
>
>
>
>
>
>
>Please note that it may take a couple of minutes from the time of
>submission until the htmlized version and diff are available at
>= tools.ietf.org.
>
>The IETF Secretariat
>
>_______________________________________________
>nvo3 mailing list
>nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3



--001a114e70c662e729053387bbe2-- From nobody Mon May 23 13:17:53 2016 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 DB59912DB51 for ; Mon, 23 May 2016 13:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 YXH_gqvrgbtw for ; Mon, 23 May 2016 13:17:46 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 C5FBF12DB5B for ; Mon, 23 May 2016 13:17:42 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id y2so167133154vka.3 for ; Mon, 23 May 2016 13:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=q//P71CIw60gf85UjTMHflaKZXU6hWQZnff3Lgmv88o=; b=OjVLRhmzJ6rhTV9gib81vV2mKRtXwC4QwOyzhEfYpwQ55nLBnMvkumYeft0ULDGM2D EO89QKpzKQ1v5dsh5HbA0Oi2vZifalKw+YeUh/VmdldyvqfxcOtBsQpmD+lkmMjz51FY ElQiu4nWKGKGbO6IYd26gy+AvQh3D5oUO2wME= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=q//P71CIw60gf85UjTMHflaKZXU6hWQZnff3Lgmv88o=; b=YowIyKLCrk21WxcVKzL7BH0UsAw7hEXA4XKodjJHrPu9ljMcSyVNVN1ODZjuLtFWry HJwCoKrOH11Pl0Vh8f045G2Jyy0McATYPi2j+FGj2yBPyn5Hvt1YZK9rvBF5cVYAhpIz lqsCIPcJnruEDolchnA+yXPtIwcToX2XTP/vn9TP9xooyVwTXhZfM84YZbWB6vPKMhgN ZRtZHv3gDJAWwjZB/FnSKsebKXXOruinCRlSHIyCCUj5zHtnCKUEWgjZ7UMItUUjEwzt IngWAmwe5+4KcxoyyPXd7K49lm6CYkA3Y8hXwrFqPoutd3mufaKV2m5IaFah0r9pYCH5 my9g== X-Gm-Message-State: ALyK8tIUhPS9n/4qzyBgb4kaHyzx7Hh84SVsY7IIrpIRU3uz8Rz2YKZHZClFZIwvR6Irul37ikbIGNzjOFAsfgyB X-Received: by 10.159.41.71 with SMTP id t65mr474113uat.22.1464034661506; Mon, 23 May 2016 13:17:41 -0700 (PDT) From: Shahram Davari References: <20160416060248.17419.11591.idtracker@ietfa.amsl.com> <8f73ecae119843dcba447c54084c80f8@XCH-RCD-020.cisco.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIMrdB/5G2mlwEeqn9cfT8TbquBagFzuiT1AuMuV+UChXSj3AGFqJCxAjED+U6e/GvOwA== Date: Mon, 23 May 2016 13:17:39 -0700 Message-ID: <0c05fec5720ad0229565ffa74973e96e@mail.gmail.com> Subject: RE: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt To: Greg Mirsky , Anoop Ghanwani Content-Type: multipart/alternative; boundary=001a114b1c8af0efaa053388210e Archived-At: Cc: rtg-ooam-dt@ietf.org, rtg-bfd@ietf.org, nvo3@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 20:17:48 -0000 --001a114b1c8af0efaa053388210e Content-Type: text/plain; charset=UTF-8 Greg, I am wondering why you are not using Ethernet-OAM over VXLAN rather than encapsulating BFD in UDP/IP/Ethernet and then encapsulating it in VXLAN? Thx Shahram *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] *On Behalf Of *Greg Mirsky *Sent:* Monday, May 23, 2016 12:49 PM *To:* Anoop Ghanwani *Cc:* rtg-ooam-dt@ietf.org; rtg-bfd@ietf.org; nvo3@ietf.org *Subject:* Re: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt Now with the correct OOAM-DT address On Mon, May 23, 2016 at 12:47 PM, Greg Mirsky wrote: +BFD WG and RTGWG OOAM DT Hi Anoop, thank you for your review and the question. The scope of this draft is only for the VXLAN. The Overlay OAM Desing Team is working on the Requirements, Gap Analysis and, if there will be required, enhancements and/or new OAM protocols for BIER, NSH, VXLAN-GPE, GENEVE, and GUE, as defined in its charter. Would appreciate you review and comments of the two documents the OOAM-DT already presented in BA meeting: - OOAM Requirements - OAM for Overlay Networks: Gap analysis In the latter you'll find the example to demonstrate applicability of BFD Async mode in BIER domain. As we've discussed, other BFD may be applied to other overlay networks that I've listed above even though their method of indication OAM payload may be different from BIER. Would you agree, or suggest to have another example of BFD? Regards, Greg On Mon, May 23, 2016 at 12:26 PM, Anoop Ghanwani wrote: Authors, In section 4.1, you have this: >>> Next Protocol Field in GPE header MUST be set to IPv4 or IPv6. ... The BFD packet MUST be carried inside the inner MAC frame of the VxLAN packet. The inner MAC frame carrying the BFD payload has the following format: >>> These two statements seem to contradict each other. If the GPE header indicates IPv4 or IPv6, then how can the BFD packet be encapsulated within a MAC frame? Can you please clarify? Thanks, Anoop On Mon, May 23, 2016 at 8:15 AM, Bocci, Matthew (Nokia - GB) < matthew.bocci@nokia.com> wrote: Folks Please could you direct any discussion on this draft to the NVO3 working group list. Regards Matthew On 18/04/2016, 07:54, "nvo3 on behalf of Vengada Prasad Govindan (venggovi)" wrote: >Hello all, > The authors request comments on the draft below. >Thanks >Prasad > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Saturday, April 16, 2016 11:33 AM >To: MALLIK MUDIGONDA (mmudigon) ; Basil Saji >; Greg Mirsky ; Vengada >Prasad Govindan (venggovi) ; Juniper Networks >; Sudarsan Paragiri ; >Santosh Pallagatti ; sajibasil@gmail.com > >Subject: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt > > >A new version of I-D, draft-spallagatti-bfd-vxlan-03.txt >has been successfully submitted by Vengada Prasad Govindan and posted to >the IETF repository. > >Name: draft-spallagatti-bfd-vxlan >Revision: 03 >Title: BFD for VXLAN >Document date: 2016-04-15 >Group: Individual Submission >Pages: 9 >URL: >https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan-03.txt >Status: >https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ >Htmlized: https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-03 >Diff: >https://www.ietf.org/rfcdiff?url2=draft-spallagatti-bfd-vxlan-03 > >Abstract: > This document describes use of Bidirectional Forwarding Detection > (BFD) protocol for VXLAN . > > > > > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --001a114b1c8af0efaa053388210e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Gr= eg,

=C2=A0

I am wondering why = you are not using Ethernet-OAM over VXLAN rather than encapsulating BFD in = UDP/IP/Ethernet and then encapsulating it in VXLAN?

=C2=A0

Thx

Shahram

=C2=A0

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Greg Mirsky
Se= nt: Monday, May 23, 2016 12:49 PM
To: Anoop Ghanwani
Cc= : rtg-ooam-dt@ietf.org; rtg-bfd@ietf.org; nvo3@ietf.org
Subject: Re: [nvo3] FW: New Versio= n Notification for draft-spallagatti-bfd-vxlan-03.txt

=C2=A0

Now with the correct OOAM= -DT address

=C2=A0

On Mon, May 23, 2016 at 12:47 PM, Greg Mirsky <gregimirsky@gmail.com>= wrote:

+BFD WG and RTGWG OOAM DT

=C2=A0

Hi Anoop,<= /p>

thank you for your review and the ques= tion. The scope of this draft is only for the VXLAN. The Overlay OAM Desing= Team is working on the Requirements, Gap Analysis and, if there will be re= quired, enhancements and/or new OAM protocols for=C2=A0BIER, NSH, VXLAN-GPE, GENEVE, and GUE, as defined = in its charter. Would appreciate you review and comments of the two documen= ts the OOAM-DT already presented in BA meeting:

  • OOAM Requirements
  • OAM for Overlay Networks:= Gap analysis

In the latter you'll find the example to demonst= rate applicability of BFD Async mode in BIER domain. As we've discussed= , other BFD may be applied to other overlay networks that I've listed a= bove even though their method of indication OAM payload may be different fr= om BIER. Would you agree, or suggest to have another example of BFD?=

=C2=A0

Regards, Greg

=C2=A0

On Mon, May 23, 2016 at 12:26 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:

Authors,

= 
=C2=A0=C2=A0 Next Protocol Field in G=
PE header MUST be set to IPv4 or IPv6.
...
=C2=A0=C2=A0 The =
BFD packet MUST be carried inside the inner MAC frame of the
=C2=A0=C2=A0 VxLAN packet.=C2=A0 The inner M= AC frame carrying the BFD payload has the
=C2=A0=C2=A0 following format:

>>>=C2=A0

=C2= =A0

These two statements seem to contr= adict each other.=C2=A0 If the GPE header indicates IPv4 or IPv6, then how = can the BFD packet be encapsulated within a MAC frame?

=C2=A0

Can you please= clarify?

=C2=A0

Thanks,

Anoop

=C2=A0

=C2=A0

On Mon, May 23, 2016 a= t 8:15 AM, Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com> wrote:

Folks

Please could you direct any discussion on t= his draft to the NVO3 working
group list.

Regards

Matthew<= br>
On 18/04/2016, 07:54, "nvo3 on behalf of Vengada Prasad Govinda= n
(venggovi)" <nvo3-bounces@ietf.org on behalf of venggovi@cisco.com> wrote:

&g= t;Hello all,
>=C2=A0 The authors request comments on the draft below.=
>Thanks
>Prasad
>
>-----Original Message-----
&= gt;From: inte= rnet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>Sent: Saturday, Ap= ril 16, 2016 11:33 AM
>To: MALLIK MUDIGONDA (mmudigon) <mmudigon@cisco.com>; B= asil Saji
><sbasil@juniper.net>; Greg Mirsky <gregory.mirsky@ericsson.com>; Ve= ngada
>Prasad Govindan (venggovi) <venggovi@cisco.com>; Juniper Networks
&g= t;<santoshpk@= juniper.net>; Sudarsan Paragiri <sparagiri@juniper.net>;
>Santosh Pa= llagatti <san= toshpk@juniper.net>; sajibasil@gmail.com
><sbasil@juniper.net>
>Subject: New = Version Notification for draft-spallagatti-bfd-vxlan-03.txt
>
>=
>A new version of I-D, draft-spallagatti-bfd-vxlan-03.txt
>has= been successfully submitted by Vengada Prasad Govindan and posted to
&g= t;the IETF repository.
>
>Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 draft-spallagatti-bfd-vxlan
>Revision:=C2=A0 =C2=A0 =C2=A0 03
= >Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD for VXLAN
>Document d= ate: 2016-04-15
>Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual S= ubmission
>Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A09
>URL:
&= gt;https://www.ietf.org/internet-drafts/draft-sp= allagatti-bfd-vxlan-03.txt
>Status:
>https= ://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/
>Htmlize= d:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draf= t-spallagatti-bfd-vxlan-03
>Diff:
>ht= tps://www.ietf.org/rfcdiff?url2=3Ddraft-spallagatti-bfd-vxlan-03
>= ;
>Abstract:
>=C2=A0 =C2=A0This document describes use of Bidir= ectional Forwarding Detection
>=C2=A0 =C2=A0(BFD) protocol for VXLAN = .
>
>
>
>
>
>
>Please note that i= t may take a couple of minutes from the time of
>submission until the= htmlized version and diff are available at
>tools.ietf.org.
>
>The IETF Sec= retariat
>
>_______________________________________________
= >nvo3 mailing list
>nvo3@ietf.org
>https://www.ietf.org/mailman/listinfo/nvo3<= br>
_______________________________________________
nvo3 mailing list=
nvo3@ietf.orgh= ttps://www.ietf.org/mailman/listinfo/nvo3

=C2=A0


_______________________________________________
nvo3 maili= ng list
nvo3@ietf.org=
https://www.ietf.org/mailman/listinfo/nvo3

=C2=A0

=C2=A0

--001a114b1c8af0efaa053388210e-- From nobody Mon May 23 13:23:18 2016 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 9DB9312DB62; Mon, 23 May 2016 13:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 Qf-C0tEheu1P; Mon, 23 May 2016 13:23:01 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A0912DB70; Mon, 23 May 2016 13:22:47 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-3a-574366619e93 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id AB.11.03614.16663475; Mon, 23 May 2016 22:21:54 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0294.000; Mon, 23 May 2016 16:22:44 -0400 From: Gregory Mirsky To: Shahram Davari , Greg Mirsky , Anoop Ghanwani Subject: RE: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt Thread-Topic: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt Thread-Index: AQHRl6WcnVPWQh0sjkaryhtWVkeuZJ+PkgEAgDeNkoCAAAkMt4AAQ3AAgAAIAoD//75MEA== Date: Mon, 23 May 2016 20:22:44 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A81BF2@eusaamb103.ericsson.se> References: <20160416060248.17419.11591.idtracker@ietfa.amsl.com> <8f73ecae119843dcba447c54084c80f8@XCH-RCD-020.cisco.com> <0c05fec5720ad0229565ffa74973e96e@mail.gmail.com> In-Reply-To: <0c05fec5720ad0229565ffa74973e96e@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A81BF2eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyuXRPuG5SmnO4wc9V/BZ7j7tZfJv2lNXi 6XxJi89/tjFa/Gvdy2qxadEtdgc2jy0n0z1m3T/L5rFz1l12jyVLfjIFsERx2aSk5mSWpRbp 2yVwZVx6O4294FwbU8W2no9MDYx3/jN2MXJySAiYSKw49ZUFwhaTuHBvPVsXIxeHkMBRRonO D78ZIZzljBLf2xeAVbEJGEm82NjDDmKLCNRLbNjfBBZnFqiWuD11L5gtLBApMenMAVaImiiJ Bd9nM0PYYRIr75wFsjk4WARUJVbOKQIJ8wr4SizZtp8ZYtcGZokTrf/AejkF7CQ2r9kN1ssI dN33U2uYIHaJS9x6Mp8J4moBiSV7zjND2KISLx9D9EoIKElMWnqOFaI+X+L5qYuMEMsEJU7O fMIygVF0FpJRs5CUzUJSNgvoVGYBTYn1u/QhShQlpnQ/ZIewNSRa58xlRxZfwMi+ipGjtLgg JzfdyHATIzAej0mwOe5g3NvreYhRgINRiYf3gbZTuBBrYllxZe4hRgkOZiUR3kWpzuFCvCmJ lVWpRfnxRaU5qcWHGKU5WJTEefVfKoYLCaQnlqRmp6YWpBbBZJk4OKUaGCXVLs18mh3E8+4W K/cFXtGVu3dL3VpTIrL6adyhpme/ZLoubdwqlbus92FHlfefzZYf/eR06+9nZ0yavkRj8ca2 AIG2sh1WCa+N7A08NmXXPq10WF0yoWyxfknJri1/2n2CGu9+Ks/s2b/kzNMXBY6rl8y5LrXe oMFwT5LD/425t10bV96Lv6TEUpyRaKjFXFScCADE0lp+wwIAAA== Archived-At: Cc: "rtg-ooam-dt@ietf.org" , "rtg-bfd@ietf.org" , "nvo3@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 20:23:03 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A81BF2eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVjYXVzZSB0aGlzIGlzIElFVEYg4pi6DQoNCkZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZk LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTaGFocmFtIERhdmFyaQ0KU2VudDogTW9u ZGF5LCBNYXkgMjMsIDIwMTYgMToxOCBQTQ0KVG86IEdyZWcgTWlyc2t5OyBBbm9vcCBHaGFud2Fu aQ0KQ2M6IHJ0Zy1vb2FtLWR0QGlldGYub3JnOyBydGctYmZkQGlldGYub3JnOyBudm8zQGlldGYu b3JnDQpTdWJqZWN0OiBSRTogW252bzNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXNwYWxsYWdhdHRpLWJmZC12eGxhbi0wMy50eHQNCg0KR3JlZywNCg0KSSBhbSB3b25k ZXJpbmcgd2h5IHlvdSBhcmUgbm90IHVzaW5nIEV0aGVybmV0LU9BTSBvdmVyIFZYTEFOIHJhdGhl ciB0aGFuIGVuY2Fwc3VsYXRpbmcgQkZEIGluIFVEUC9JUC9FdGhlcm5ldCBhbmQgdGhlbiBlbmNh cHN1bGF0aW5nIGl0IGluIFZYTEFOPw0KDQpUaHgNClNoYWhyYW0NCg0KRnJvbTogUnRnLWJmZCBb bWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRnLWJmZC1ib3VuY2VzQGll dGYub3JnPl0gT24gQmVoYWxmIE9mIEdyZWcgTWlyc2t5DQpTZW50OiBNb25kYXksIE1heSAyMywg MjAxNiAxMjo0OSBQTQ0KVG86IEFub29wIEdoYW53YW5pDQpDYzogcnRnLW9vYW0tZHRAaWV0Zi5v cmc8bWFpbHRvOnJ0Zy1vb2FtLWR0QGlldGYub3JnPjsgcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86 cnRnLWJmZEBpZXRmLm9yZz47IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW252bzNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXNwYWxsYWdhdHRpLWJmZC12eGxhbi0wMy50eHQNCg0KTm93IHdpdGggdGhlIGNvcnJlY3QgT09B TS1EVCBhZGRyZXNzDQoNCk9uIE1vbiwgTWF5IDIzLCAyMDE2IGF0IDEyOjQ3IFBNLCBHcmVnIE1p cnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+ PiB3cm90ZToNCitCRkQgV0cgYW5kIFJUR1dHIE9PQU0gRFQNCg0KSGkgQW5vb3AsDQp0aGFuayB5 b3UgZm9yIHlvdXIgcmV2aWV3IGFuZCB0aGUgcXVlc3Rpb24uIFRoZSBzY29wZSBvZiB0aGlzIGRy YWZ0IGlzIG9ubHkgZm9yIHRoZSBWWExBTi4gVGhlIE92ZXJsYXkgT0FNIERlc2luZyBUZWFtIGlz IHdvcmtpbmcgb24gdGhlIFJlcXVpcmVtZW50cywgR2FwIEFuYWx5c2lzIGFuZCwgaWYgdGhlcmUg d2lsbCBiZSByZXF1aXJlZCwgZW5oYW5jZW1lbnRzIGFuZC9vciBuZXcgT0FNIHByb3RvY29scyBm b3IgQklFUiwgTlNILCBWWExBTi1HUEUsIEdFTkVWRSwgYW5kIEdVRSwgYXMgZGVmaW5lZCBpbiBp dHMgY2hhcnRlci4gV291bGQgYXBwcmVjaWF0ZSB5b3UgcmV2aWV3IGFuZCBjb21tZW50cyBvZiB0 aGUgdHdvIGRvY3VtZW50cyB0aGUgT09BTS1EVCBhbHJlYWR5IHByZXNlbnRlZCBpbiBCQSBtZWV0 aW5nOg0KDQogICogICBPT0FNIFJlcXVpcmVtZW50cw0KICAqICAgT0FNIGZvciBPdmVybGF5IE5l dHdvcmtzOiBHYXAgYW5hbHlzaXMNCkluIHRoZSBsYXR0ZXIgeW91J2xsIGZpbmQgdGhlIGV4YW1w bGUgdG8gZGVtb25zdHJhdGUgYXBwbGljYWJpbGl0eSBvZiBCRkQgQXN5bmMgbW9kZSBpbiBCSUVS IGRvbWFpbi4gQXMgd2UndmUgZGlzY3Vzc2VkLCBvdGhlciBCRkQgbWF5IGJlIGFwcGxpZWQgdG8g b3RoZXIgb3ZlcmxheSBuZXR3b3JrcyB0aGF0IEkndmUgbGlzdGVkIGFib3ZlIGV2ZW4gdGhvdWdo IHRoZWlyIG1ldGhvZCBvZiBpbmRpY2F0aW9uIE9BTSBwYXlsb2FkIG1heSBiZSBkaWZmZXJlbnQg ZnJvbSBCSUVSLiBXb3VsZCB5b3UgYWdyZWUsIG9yIHN1Z2dlc3QgdG8gaGF2ZSBhbm90aGVyIGV4 YW1wbGUgb2YgQkZEPw0KDQpSZWdhcmRzLCBHcmVnDQoNCk9uIE1vbiwgTWF5IDIzLCAyMDE2IGF0 IDEyOjI2IFBNLCBBbm9vcCBHaGFud2FuaSA8YW5vb3BAYWx1bW5pLmR1a2UuZWR1PG1haWx0bzph bm9vcEBhbHVtbmkuZHVrZS5lZHU+PiB3cm90ZToNCkF1dGhvcnMsDQoNCkluIHNlY3Rpb24gNC4x LCB5b3UgaGF2ZSB0aGlzOg0KPj4+DQoNCiAgIE5leHQgUHJvdG9jb2wgRmllbGQgaW4gR1BFIGhl YWRlciBNVVNUIGJlIHNldCB0byBJUHY0IG9yIElQdjYuDQoNCi4uLg0KDQogICBUaGUgQkZEIHBh Y2tldCBNVVNUIGJlIGNhcnJpZWQgaW5zaWRlIHRoZSBpbm5lciBNQUMgZnJhbWUgb2YgdGhlDQoN CiAgIFZ4TEFOIHBhY2tldC4gIFRoZSBpbm5lciBNQUMgZnJhbWUgY2FycnlpbmcgdGhlIEJGRCBw YXlsb2FkIGhhcyB0aGUNCg0KICAgZm9sbG93aW5nIGZvcm1hdDoNCj4+Pg0KDQpUaGVzZSB0d28g c3RhdGVtZW50cyBzZWVtIHRvIGNvbnRyYWRpY3QgZWFjaCBvdGhlci4gIElmIHRoZSBHUEUgaGVh ZGVyIGluZGljYXRlcyBJUHY0IG9yIElQdjYsIHRoZW4gaG93IGNhbiB0aGUgQkZEIHBhY2tldCBi ZSBlbmNhcHN1bGF0ZWQgd2l0aGluIGEgTUFDIGZyYW1lPw0KDQpDYW4geW91IHBsZWFzZSBjbGFy aWZ5Pw0KDQpUaGFua3MsDQpBbm9vcA0KDQoNCk9uIE1vbiwgTWF5IDIzLCAyMDE2IGF0IDg6MTUg QU0sIEJvY2NpLCBNYXR0aGV3IChOb2tpYSAtIEdCKSA8bWF0dGhldy5ib2NjaUBub2tpYS5jb208 bWFpbHRvOm1hdHRoZXcuYm9jY2lAbm9raWEuY29tPj4gd3JvdGU6DQpGb2xrcw0KDQpQbGVhc2Ug Y291bGQgeW91IGRpcmVjdCBhbnkgZGlzY3Vzc2lvbiBvbiB0aGlzIGRyYWZ0IHRvIHRoZSBOVk8z IHdvcmtpbmcNCmdyb3VwIGxpc3QuDQoNClJlZ2FyZHMNCg0KTWF0dGhldw0KDQpPbiAxOC8wNC8y MDE2LCAwNzo1NCwgIm52bzMgb24gYmVoYWxmIG9mIFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuDQoo dmVuZ2dvdmkpIiA8bnZvMy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpudm8zLWJvdW5jZXNAaWV0 Zi5vcmc+IG9uIGJlaGFsZiBvZiB2ZW5nZ292aUBjaXNjby5jb208bWFpbHRvOnZlbmdnb3ZpQGNp c2NvLmNvbT4+IHdyb3RlOg0KDQo+SGVsbG8gYWxsLA0KPiAgVGhlIGF1dGhvcnMgcmVxdWVzdCBj b21tZW50cyBvbiB0aGUgZHJhZnQgYmVsb3cuDQo+VGhhbmtzDQo+UHJhc2FkDQo+DQo+LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz5dDQo+U2VudDogU2F0dXJkYXks IEFwcmlsIDE2LCAyMDE2IDExOjMzIEFNDQo+VG86IE1BTExJSyBNVURJR09OREEgKG1tdWRpZ29u KSA8bW11ZGlnb25AY2lzY28uY29tPG1haWx0bzptbXVkaWdvbkBjaXNjby5jb20+PjsgQmFzaWwg U2FqaQ0KPjxzYmFzaWxAanVuaXBlci5uZXQ8bWFpbHRvOnNiYXNpbEBqdW5pcGVyLm5ldD4+OyBH cmVnIE1pcnNreSA8Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPG1haWx0bzpncmVnb3J5Lm1p cnNreUBlcmljc3Nvbi5jb20+PjsgVmVuZ2FkYQ0KPlByYXNhZCBHb3ZpbmRhbiAodmVuZ2dvdmkp IDx2ZW5nZ292aUBjaXNjby5jb208bWFpbHRvOnZlbmdnb3ZpQGNpc2NvLmNvbT4+OyBKdW5pcGVy IE5ldHdvcmtzDQo+PHNhbnRvc2hwa0BqdW5pcGVyLm5ldDxtYWlsdG86c2FudG9zaHBrQGp1bmlw ZXIubmV0Pj47IFN1ZGFyc2FuIFBhcmFnaXJpIDxzcGFyYWdpcmlAanVuaXBlci5uZXQ8bWFpbHRv OnNwYXJhZ2lyaUBqdW5pcGVyLm5ldD4+Ow0KPlNhbnRvc2ggUGFsbGFnYXR0aSA8c2FudG9zaHBr QGp1bmlwZXIubmV0PG1haWx0bzpzYW50b3NocGtAanVuaXBlci5uZXQ+Pjsgc2FqaWJhc2lsQGdt YWlsLmNvbTxtYWlsdG86c2FqaWJhc2lsQGdtYWlsLmNvbT4NCj48c2Jhc2lsQGp1bmlwZXIubmV0 PG1haWx0bzpzYmFzaWxAanVuaXBlci5uZXQ+Pg0KPlN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLTAzLnR4dA0KPg0KPg0KPkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4tMDMudHh0DQo+ aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBWZW5nYWRhIFByYXNhZCBHb3ZpbmRh biBhbmQgcG9zdGVkIHRvDQo+dGhlIElFVEYgcmVwb3NpdG9yeS4NCj4NCj5OYW1lOiAgICAgICAg ICBkcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4NCj5SZXZpc2lvbjogICAgICAwMw0KPlRpdGxl OiAgICAgICAgIEJGRCBmb3IgVlhMQU4NCj5Eb2N1bWVudCBkYXRlOiAyMDE2LTA0LTE1DQo+R3Jv dXA6ICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+UGFnZXM6ICAgICAgICAgOQ0KPlVS TDoNCj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc3BhbGxhZ2F0 dGktYmZkLXZ4bGFuLTAzLnR4dA0KPlN0YXR1czoNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4vDQo+SHRtbGl6ZWQ6ICAgICAgIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4tMDMN Cj5EaWZmOg0KPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zcGFsbGFn YXR0aS1iZmQtdnhsYW4tMDMNCj4NCj5BYnN0cmFjdDoNCj4gICBUaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyB1c2Ugb2YgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbg0KPiAgIChCRkQp IHByb3RvY29sIGZvciBWWExBTiAuDQo+DQo+DQo+DQo+DQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj5zdWJt aXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQNCj50b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KPg0KPlRoZSBJRVRG IFNlY3JldGFyaWF0DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj5udm8zIG1haWxpbmcgbGlzdA0KPm52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNA aWV0Zi5vcmc+DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpudm8zIG1h aWxpbmcgbGlzdA0KbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMw0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpudm8zIG1haWxpbmcgbGlzdA0KbnZvM0Bp ZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbnZvMw0KDQoNCg== --_000_7347100B5761DC41A166AC17F22DF11221A81BF2eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28t bGlzdC1pZDo1OTE3OTA0NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTcxNDcwOTQwO30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo4MDEwMDI0MTY7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOi0xNDE3MzcyNjQ4O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5CZWNhdXNlIHRoaXMgaXMgSUVURg0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdE Ij5KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TaGFocmFtIERhdmFyaTxicj4NCjxiPlNlbnQ6PC9iPiBN b25kYXksIE1heSAyMywgMjAxNiAxOjE4IFBNPGJyPg0KPGI+VG86PC9iPiBHcmVnIE1pcnNreTsg QW5vb3AgR2hhbndhbmk8YnI+DQo8Yj5DYzo8L2I+IHJ0Zy1vb2FtLWR0QGlldGYub3JnOyBydGct YmZkQGlldGYub3JnOyBudm8zQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbbnZv M10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3BhbGxhZ2F0dGktYmZk LXZ4bGFuLTAzLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5HcmVnLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSBhbSB3b25kZXJpbmcgd2h5IHlvdSBhcmUgbm90IHVzaW5nIEV0aGVybmV0LU9BTSBv dmVyIFZYTEFOIHJhdGhlciB0aGFuIGVuY2Fwc3VsYXRpbmcgQkZEIGluIFVEUC9JUC9FdGhlcm5l dCBhbmQgdGhlbiBlbmNhcHN1bGF0aW5nIGl0IGluIFZYTEFOPzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGh4PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNoYWhyYW08L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IFJ0Zy1iZmQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cnRnLWJm ZC1ib3VuY2VzQGlldGYub3JnIj5ydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5HcmVnIE1pcnNreTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSAy MywgMjAxNiAxMjo0OSBQTTxicj4NCjxiPlRvOjwvYj4gQW5vb3AgR2hhbndhbmk8YnI+DQo8Yj5D Yzo8L2I+IDxhIGhyZWY9Im1haWx0bzpydGctb29hbS1kdEBpZXRmLm9yZyI+cnRnLW9vYW0tZHRA aWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyI+DQpydGctYmZk QGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm52bzNAaWV0Zi5vcmciPm52bzNAaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbnZvM10gRlc6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLTAzLnR4dDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdyB3aXRoIHRoZSBjb3JyZWN0IE9PQU0t RFQgYWRkcmVzczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gTW9uLCBNYXkgMjMsIDIwMTYgYXQgMTI6NDcgUE0sIEdyZWcgTWlyc2t5ICZsdDs8YSBocmVm PSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+Z3JlZ2ltaXJz a3lAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+JiM0MztCRkQgV0cgYW5kIFJUR1dHIE9PQU0gRFQ8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEFub29wLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhbmsgeW91IGZvciB5b3Vy IHJldmlldyBhbmQgdGhlIHF1ZXN0aW9uLiBUaGUgc2NvcGUgb2YgdGhpcyBkcmFmdCBpcyBvbmx5 IGZvciB0aGUgVlhMQU4uIFRoZSBPdmVybGF5IE9BTSBEZXNpbmcgVGVhbSBpcyB3b3JraW5nIG9u IHRoZSBSZXF1aXJlbWVudHMsIEdhcCBBbmFseXNpcyBhbmQsIGlmIHRoZXJlIHdpbGwgYmUgcmVx dWlyZWQsIGVuaGFuY2VtZW50cyBhbmQvb3IgbmV3IE9BTSBwcm90b2NvbHMgZm9yJm5ic3A7PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPkJJRVIsDQogTlNILCBWWExB Ti1HUEUsIEdFTkVWRSwgYW5kIEdVRSwgYXMgZGVmaW5lZCBpbiBpdHMgY2hhcnRlci4gV291bGQg YXBwcmVjaWF0ZSB5b3UgcmV2aWV3IGFuZCBjb21tZW50cyBvZiB0aGUgdHdvIGRvY3VtZW50cyB0 aGUgT09BTS1EVCBhbHJlYWR5IHByZXNlbnRlZCBpbiBCQSBtZWV0aW5nOjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6YmxhY2siPk9PQU0gUmVxdWlyZW1lbnRzPC9zcGFuPjxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5PQU0gZm9yIE92ZXJsYXkg TmV0d29ya3M6IEdhcCBhbmFseXNpczwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNr Ij5JbiB0aGUgbGF0dGVyIHlvdSdsbCBmaW5kIHRoZSBleGFtcGxlIHRvIGRlbW9uc3RyYXRlIGFw cGxpY2FiaWxpdHkgb2YgQkZEIEFzeW5jIG1vZGUgaW4gQklFUiBkb21haW4uIEFzIHdlJ3ZlIGRp c2N1c3NlZCwgb3RoZXIgQkZEIG1heSBiZSBhcHBsaWVkIHRvIG90aGVyIG92ZXJsYXkgbmV0d29y a3MgdGhhdCBJJ3ZlIGxpc3RlZCBhYm92ZQ0KIGV2ZW4gdGhvdWdoIHRoZWlyIG1ldGhvZCBvZiBp bmRpY2F0aW9uIE9BTSBwYXlsb2FkIG1heSBiZSBkaWZmZXJlbnQgZnJvbSBCSUVSLiBXb3VsZCB5 b3UgYWdyZWUsIG9yIHN1Z2dlc3QgdG8gaGF2ZSBhbm90aGVyIGV4YW1wbGUgb2YgQkZEPzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlJlZ2FyZHMsIEdyZWc8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBNYXkgMjMsIDIwMTYgYXQgMTI6MjYgUE0sIEFub29w IEdoYW53YW5pICZsdDs8YSBocmVmPSJtYWlsdG86YW5vb3BAYWx1bW5pLmR1a2UuZWR1IiB0YXJn ZXQ9Il9ibGFuayI+YW5vb3BAYWx1bW5pLmR1a2UuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXV0aG9ycyw8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHNlY3Rpb24gNC4xLCB5b3UgaGF2 ZSB0aGlzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IE5leHQgUHJvdG9jb2wgRmll bGQgaW4gR1BFIGhlYWRlciBNVVNUIGJlIHNldCB0byBJUHY0IG9yIElQdjYuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Li4uPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IFRoZSBCRkQgcGFja2V0IE1VU1QgYmUgY2FycmllZCBpbnNpZGUgdGhlIGlubmVyIE1BQyBm cmFtZSBvZiB0aGU8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgVnhMQU4gcGFja2V0LiZuYnNwOyBUaGUgaW5uZXIgTUFD IGZyYW1lIGNhcnJ5aW5nIHRoZSBCRkQgcGF5bG9hZCBoYXMgdGhlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGZvbGxv d2luZyBmb3JtYXQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlc2UgdHdvIHN0YXRlbWVudHMgc2Vl bSB0byBjb250cmFkaWN0IGVhY2ggb3RoZXIuJm5ic3A7IElmIHRoZSBHUEUgaGVhZGVyIGluZGlj YXRlcyBJUHY0IG9yIElQdjYsIHRoZW4gaG93IGNhbiB0aGUgQkZEIHBhY2tldCBiZSBlbmNhcHN1 bGF0ZWQgd2l0aGluIGEgTUFDIGZyYW1lPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYW4geW91IHBsZWFzZSBjbGFyaWZ5PzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bbm9vcDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gTW9uLCBNYXkgMjMsIDIwMTYgYXQgODoxNSBBTSwgQm9jY2ksIE1hdHRoZXcg KE5va2lhIC0gR0IpICZsdDs8YSBocmVmPSJtYWlsdG86bWF0dGhldy5ib2NjaUBub2tpYS5jb20i IHRhcmdldD0iX2JsYW5rIj5tYXR0aGV3LmJvY2NpQG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9sa3M8YnI+DQo8YnI+DQpQbGVh c2UgY291bGQgeW91IGRpcmVjdCBhbnkgZGlzY3Vzc2lvbiBvbiB0aGlzIGRyYWZ0IHRvIHRoZSBO Vk8zIHdvcmtpbmc8YnI+DQpncm91cCBsaXN0Ljxicj4NCjxicj4NClJlZ2FyZHM8YnI+DQo8YnI+ DQpNYXR0aGV3PGJyPg0KPGJyPg0KT24gMTgvMDQvMjAxNiwgMDc6NTQsICZxdW90O252bzMgb24g YmVoYWxmIG9mIFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuPGJyPg0KKHZlbmdnb3ZpKSZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm52bzMtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86 dmVuZ2dvdmlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+dmVuZ2dvdmlAY2lzY28uY29tPC9h PiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0O0hlbGxvIGFsbCw8YnI+DQomZ3Q7Jm5ic3A7IFRo ZSBhdXRob3JzIHJlcXVlc3QgY29tbWVudHMgb24gdGhlIGRyYWZ0IGJlbG93Ljxicj4NCiZndDtU aGFua3M8YnI+DQomZ3Q7UHJhc2FkPGJyPg0KJmd0Ozxicj4NCiZndDstLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCiZndDtGcm9tOiA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiBb bWFpbHRvOjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+XTxicj4NCiZndDtTZW50OiBTYXR1 cmRheSwgQXByaWwgMTYsIDIwMTYgMTE6MzMgQU08YnI+DQomZ3Q7VG86IE1BTExJSyBNVURJR09O REEgKG1tdWRpZ29uKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1tdWRpZ29uQGNpc2NvLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPm1tdWRpZ29uQGNpc2NvLmNvbTwvYT4mZ3Q7OyBCYXNpbCBTYWppPGJyPg0K Jmd0OyZsdDs8YSBocmVmPSJtYWlsdG86c2Jhc2lsQGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFu ayI+c2Jhc2lsQGp1bmlwZXIubmV0PC9hPiZndDs7IEdyZWcgTWlyc2t5ICZsdDs8YSBocmVmPSJt YWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Z3JlZ29y eS5taXJza3lAZXJpY3Nzb24uY29tPC9hPiZndDs7IFZlbmdhZGE8YnI+DQomZ3Q7UHJhc2FkIEdv dmluZGFuICh2ZW5nZ292aSkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZW5nZ292aUBjaXNjby5jb20i IHRhcmdldD0iX2JsYW5rIj52ZW5nZ292aUBjaXNjby5jb208L2E+Jmd0OzsgSnVuaXBlciBOZXR3 b3Jrczxicj4NCiZndDsmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhbnRvc2hwa0BqdW5pcGVyLm5ldCIg dGFyZ2V0PSJfYmxhbmsiPnNhbnRvc2hwa0BqdW5pcGVyLm5ldDwvYT4mZ3Q7OyBTdWRhcnNhbiBQ YXJhZ2lyaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwYXJhZ2lyaUBqdW5pcGVyLm5ldCIgdGFyZ2V0 PSJfYmxhbmsiPnNwYXJhZ2lyaUBqdW5pcGVyLm5ldDwvYT4mZ3Q7Ozxicj4NCiZndDtTYW50b3No IFBhbGxhZ2F0dGkgJmx0OzxhIGhyZWY9Im1haWx0bzpzYW50b3NocGtAanVuaXBlci5uZXQiIHRh cmdldD0iX2JsYW5rIj5zYW50b3NocGtAanVuaXBlci5uZXQ8L2E+Jmd0OzsNCjxhIGhyZWY9Im1h aWx0bzpzYWppYmFzaWxAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FqaWJhc2lsQGdtYWls LmNvbTwvYT48YnI+DQomZ3Q7Jmx0OzxhIGhyZWY9Im1haWx0bzpzYmFzaWxAanVuaXBlci5uZXQi IHRhcmdldD0iX2JsYW5rIj5zYmFzaWxAanVuaXBlci5uZXQ8L2E+Jmd0Ozxicj4NCiZndDtTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNwYWxsYWdhdHRpLWJmZC12 eGxhbi0wMy50eHQ8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDtBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLTAzLnR4dDxicj4NCiZndDtoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuIGFuZCBw b3N0ZWQgdG88YnI+DQomZ3Q7dGhlIElFVEYgcmVwb3NpdG9yeS48YnI+DQomZ3Q7PGJyPg0KJmd0 O05hbWU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkcmFmdC1zcGFsbGFnYXR0 aS1iZmQtdnhsYW48YnI+DQomZ3Q7UmV2aXNpb246Jm5ic3A7ICZuYnNwOyAmbmJzcDsgMDM8YnI+ DQomZ3Q7VGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0JGRCBmb3IgVlhM QU48YnI+DQomZ3Q7RG9jdW1lbnQgZGF0ZTogMjAxNi0wNC0xNTxicj4NCiZndDtHcm91cDombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0K Jmd0O1BhZ2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs5PGJyPg0KJmd0O1VS TDo8YnI+DQomZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LXNwYWxsYWdhdHRpLWJmZC12eGxhbi0wMy50eHQiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4 bGFuLTAzLnR4dDwvYT48YnI+DQomZ3Q7U3RhdHVzOjxicj4NCiZndDs8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4vIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3Bh bGxhZ2F0dGktYmZkLXZ4bGFuLzwvYT48YnI+DQomZ3Q7SHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNw YWxsYWdhdHRpLWJmZC12eGxhbi0wMyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4tMDM8L2E+PGJyPg0KJmd0O0Rp ZmY6PGJyPg0KJmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4tMDMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLTAzPC9h Pjxicj4NCiZndDs8YnI+DQomZ3Q7QWJzdHJhY3Q6PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyB1c2Ugb2YgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVj dGlvbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7KEJGRCkgcHJvdG9jb2wgZm9yIFZYTEFOIC48YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Y8YnI+DQomZ3Q7c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0PGJyPg0KJmd0OzxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRvb2xzLmlldGYub3JnPC9hPi48YnI+ DQomZ3Q7PGJyPg0KJmd0O1RoZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0KJmd0Ozxicj4NCiZndDtf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDtu dm8zIG1haWxpbmcgbGlzdDxicj4NCiZndDs8YSBocmVmPSJtYWlsdG86bnZvM0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm52bzNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OzxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMzwvYT48YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm52bzMg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm52bzNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5udm8zQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbnZvMyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KbnZvMyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bnZvM0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm52bzNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7347100B5761DC41A166AC17F22DF11221A81BF2eusaamb103erics_-- From nobody Mon May 23 13:42:15 2016 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 7D7B812D586; Mon, 23 May 2016 13:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 tT3hlMnufFHB; Mon, 23 May 2016 13:42:09 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9319012B056; Mon, 23 May 2016 13:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3210; q=dns/txt; s=iport; t=1464036129; x=1465245729; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Pc9tEvTRMRhSTm5KPpfyktLBYL8aueNw9tNrv/DYKUs=; b=k03CYvhG948iTZE0bZeXZ4YNybKxIhjEvYEu9tBEwse368IxBJxzia4C 1qDQ6Fahm65f7RtceBUN4gepx8Km/k5vfXqxaYQYXrG0741ZdlflWkJnZ wIRia6XWDOywl4qyfeQdrZG1i7WK7lwvebTgT6kfjNbpLQYqrfFSETUkA I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAgACakNX/5ldJa1cgzdWfQauDItvA?= =?us-ascii?q?Q2BdxcLhW8CgTY4FAEBAQEBAQFlJ4RCAQEBBAEBAWsJDgQCAQgRBAEBAScHIQY?= =?us-ascii?q?LFAgBCAIEARKIFQMWAQ6/TQ2EJgEBAQEBAQEBAQEBAQEBAQEBAQEBARyKdIJDh?= =?us-ascii?q?1YFjWU4iWczAYV/hieBeYFpToQBiGSHZIdnAR4BAUKDbW4BiFEBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,357,1459814400"; d="scan'208";a="105258651" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 May 2016 20:42:08 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4NKg8bw004987 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 May 2016 20:42:08 GMT Received: from xch-rtp-007.cisco.com (64.101.220.147) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 23 May 2016 16:42:07 -0400 Received: from xch-rtp-007.cisco.com ([64.101.220.147]) by XCH-RTP-007.cisco.com ([64.101.220.147]) with mapi id 15.00.1104.009; Mon, 23 May 2016 16:42:07 -0400 From: "Larry Kreeger (kreeger)" To: "Bocci, Matthew (Nokia - GB)" , "Vengada Prasad Govindan (venggovi)" , "rtg-bfd@ietf.org" , "nvo3@ietf.org" , "rtg-ooam-dt@ietf.org" Subject: Re: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt Thread-Topic: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt Thread-Index: AQHRtQY0uqUxwWYgskqjcJFN8vvECJ/GysQA Date: Mon, 23 May 2016 20:42:07 +0000 Message-ID: References: <20160416060248.17419.11591.idtracker@ietfa.amsl.com> <8f73ecae119843dcba447c54084c80f8@XCH-RCD-020.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [171.71.35.113] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 20:42:11 -0000 Hello Authors, First, when referencing VXLAN GPE I would prefer it not be shortened to =B3GPE=B2 but use the full =B3VXLAN GPE=B2 to be sure it is not ambiguous. Second, I agree with Anoop=B9s comment about using the next protocol of IPv4/v6. When directly encapsulating these protocols, there is no Ethernet header present. Third, in both these cases (L2 being encapsulated or IP being encapsulated), I am concerned that since this draft is using the VTEP (underlay) address space within the inner frames/packets, there could be a collision between the VTEP addresses and the tenant=B9s addresses. As it stands with VXLAN, it is perfectly acceptable for tenants to overlap MAC or IP addresses with the VTEPs. With this draft, I believe it will be broken. - Larry On 5/23/16, 8:15 AM, "nvo3 on behalf of Bocci, Matthew (Nokia - GB)" wrote: >Folks > >Please could you direct any discussion on this draft to the NVO3 working >group list. > >Regards > >Matthew > >On 18/04/2016, 07:54, "nvo3 on behalf of Vengada Prasad Govindan >(venggovi)" wrote: > >>Hello all, >> The authors request comments on the draft below. >>Thanks >>Prasad >> >>-----Original Message----- >>From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>Sent: Saturday, April 16, 2016 11:33 AM >>To: MALLIK MUDIGONDA (mmudigon) ; Basil Saji >>; Greg Mirsky ; Vengada >>Prasad Govindan (venggovi) ; Juniper Networks >>; Sudarsan Paragiri ; >>Santosh Pallagatti ; sajibasil@gmail.com >> >>Subject: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt >> >> >>A new version of I-D, draft-spallagatti-bfd-vxlan-03.txt >>has been successfully submitted by Vengada Prasad Govindan and posted to >>the IETF repository. >> >>Name: draft-spallagatti-bfd-vxlan >>Revision: 03 >>Title: BFD for VXLAN >>Document date: 2016-04-15 >>Group: Individual Submission >>Pages: 9 >>URL: =20 >>https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan-03.txt >>Status: =20 >>https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ >>Htmlized: =20 >>https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-03 >>Diff: =20 >>https://www.ietf.org/rfcdiff?url2=3Ddraft-spallagatti-bfd-vxlan-03 >> >>Abstract: >> This document describes use of Bidirectional Forwarding Detection >> (BFD) protocol for VXLAN . >> >> >> =20 >> =20 >> >> >>Please note that it may take a couple of minutes from the time of >>submission until the htmlized version and diff are available at >>tools.ietf.org. >> >>The IETF Secretariat >> >>_______________________________________________ >>nvo3 mailing list >>nvo3@ietf.org >>https://www.ietf.org/mailman/listinfo/nvo3 > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 From nobody Mon May 23 13:47:10 2016 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 94C5512D57C for ; Mon, 23 May 2016 13:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 06bjzzuBcLc3 for ; Mon, 23 May 2016 13:46:56 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 110AC12D586 for ; Mon, 23 May 2016 13:46:54 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id c189so69942280pfb.3 for ; Mon, 23 May 2016 13:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4xJQV/367NCtICKNeZDlqu7+GcUd0tMLApOAPuRPMiY=; b=foy0QpszskdLeII9ryiaS9VgtLPbvTS6AdRKbjAlw6Qp/4kYjvsrk7igtS+gD+ebdy QkD9ZNAbFdxaWySlCKMmYILpEJZ92g2Ik4BDIxjreB40nJHtPZ3oW4xj+AACaogWeTMl Z7ADn/7bIgiyqG2Ul95dku+ejFZ0yqVqYl+hs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4xJQV/367NCtICKNeZDlqu7+GcUd0tMLApOAPuRPMiY=; b=MnMj3w8H4I5fdJrXwNvPBr9SfRz58yj+797S7r+BDUfK8HK0h96ym2Bk1Znj8dwbz4 yNgWhVULqtPCoka0SGrwh+x/BnGxiWzH92VTCrZd4XZqv5QmgXz5DmCzVO1AFsrd23TM Tp35OADu3aqlnKDO4pNFFSRI4jCCsTFgoLezTSAqkMtkSktb3ghjh+4iMbzXpFjMK3Ez le/4ln9Kww0zq1mvyx0VW8H4uHumjYUXESicycpXxybdZg1oHDsAfQ+bfdnP71jFMnP8 wuiJ6kvoGKFbDHZqefS2piIqmzRVqfj5SL8VyUUTxk+vwnhpT8HYap9Pymd4/aMTFN5Q Dmpw== X-Gm-Message-State: ALyK8tKvCYh5RRI5E6cu+qY/Lt1UwbMVXtTAtQfGza9zqJnaIbZmQdWJckhPpNsM4iVshwhK X-Received: by 10.98.27.129 with SMTP id b123mr1127727pfb.111.1464036413257; Mon, 23 May 2016 13:46:53 -0700 (PDT) Received: from [10.128.167.13] ([166.170.37.199]) by smtp.gmail.com with ESMTPSA id u65sm48714048pfa.9.2016.05.23.13.46.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2016 13:46:52 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E735CAF6-E663-49A3-9FF7-BB337CA1FDF9 Mime-Version: 1.0 (1.0) Subject: Re: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt From: Shahram Davari X-Mailer: iPhone Mail (13E238) In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A81BF2@eusaamb103.ericsson.se> Date: Mon, 23 May 2016 13:46:51 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20160416060248.17419.11591.idtracker@ietfa.amsl.com> <8f73ecae119843dcba447c54084c80f8@XCH-RCD-020.cisco.com> <0c05fec5720ad0229565ffa74973e96e@mail.gmail.com> <7347100B5761DC41A166AC17F22DF11221A81BF2@eusaamb103.ericsson.se> To: Gregory Mirsky Archived-At: Cc: "rtg-bfd@ietf.org" , Anoop Ghanwani , "nvo3@ietf.org" , "rtg-ooam-dt@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 20:46:58 -0000 --Apple-Mail-E735CAF6-E663-49A3-9FF7-BB337CA1FDF9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Haha! Regards, Shahram > On May 23, 2016, at 1:22 PM, Gregory Mirsky w= rote: >=20 > Because this is IETF J > =20 > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Shahram Davar= i > Sent: Monday, May 23, 2016 1:18 PM > To: Greg Mirsky; Anoop Ghanwani > Cc: rtg-ooam-dt@ietf.org; rtg-bfd@ietf.org; nvo3@ietf.org > Subject: RE: [nvo3] FW: New Version Notification for draft-spallagatti-bfd= -vxlan-03.txt > =20 > Greg, > =20 > I am wondering why you are not using Ethernet-OAM over VXLAN rather than e= ncapsulating BFD in UDP/IP/Ethernet and then encapsulating it in VXLAN? > =20 > Thx > Shahram > =20 > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Greg Mirsky > Sent: Monday, May 23, 2016 12:49 PM > To: Anoop Ghanwani > Cc: rtg-ooam-dt@ietf.org; rtg-bfd@ietf.org; nvo3@ietf.org > Subject: Re: [nvo3] FW: New Version Notification for draft-spallagatti-bfd= -vxlan-03.txt > =20 > Now with the correct OOAM-DT address > =20 > On Mon, May 23, 2016 at 12:47 PM, Greg Mirsky wrot= e: > +BFD WG and RTGWG OOAM DT > =20 > Hi Anoop, > thank you for your review and the question. The scope of this draft is onl= y for the VXLAN. The Overlay OAM Desing Team is working on the Requirements,= Gap Analysis and, if there will be required, enhancements and/or new OAM pr= otocols for BIER, NSH, VXLAN-GPE, GENEVE, and GUE, as defined in its charter= . Would appreciate you review and comments of the two documents the OOAM-DT a= lready presented in BA meeting: > OOAM Requirements > OAM for Overlay Networks: Gap analysis > In the latter you'll find the example to demonstrate applicability of BFD A= sync mode in BIER domain. As we've discussed, other BFD may be applied to ot= her overlay networks that I've listed above even though their method of indi= cation OAM payload may be different from BIER. Would you agree, or suggest t= o have another example of BFD? > =20 > Regards, Greg > =20 > On Mon, May 23, 2016 at 12:26 PM, Anoop Ghanwani w= rote: > Authors, > =20 > In section 4.1, you have this: > >>>=20 > Next Protocol Field in GPE header MUST be set to IPv4 or IPv6. > ... > The BFD packet MUST be carried inside the inner MAC frame of the > VxLAN packet. The inner MAC frame carrying the BFD payload has the > following format: > >>>=20 > =20 > These two statements seem to contradict each other. If the GPE header ind= icates IPv4 or IPv6, then how can the BFD packet be encapsulated within a MA= C frame? > =20 > Can you please clarify? > =20 > Thanks, > Anoop > =20 > =20 > On Mon, May 23, 2016 at 8:15 AM, Bocci, Matthew (Nokia - GB) wrote: > Folks >=20 > Please could you direct any discussion on this draft to the NVO3 working > group list. >=20 > Regards >=20 > Matthew >=20 > On 18/04/2016, 07:54, "nvo3 on behalf of Vengada Prasad Govindan > (venggovi)" wrote:= >=20 > >Hello all, > > The authors request comments on the draft below. > >Thanks > >Prasad > > > >-----Original Message----- > >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >Sent: Saturday, April 16, 2016 11:33 AM > >To: MALLIK MUDIGONDA (mmudigon) ; Basil Saji > >; Greg Mirsky ; Vengada > >Prasad Govindan (venggovi) ; Juniper Networks > >; Sudarsan Paragiri ; > >Santosh Pallagatti ; sajibasil@gmail.com > > > >Subject: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt > > > > > >A new version of I-D, draft-spallagatti-bfd-vxlan-03.txt > >has been successfully submitted by Vengada Prasad Govindan and posted to > >the IETF repository. > > > >Name: draft-spallagatti-bfd-vxlan > >Revision: 03 > >Title: BFD for VXLAN > >Document date: 2016-04-15 > >Group: Individual Submission > >Pages: 9 > >URL: > >https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan-03.txt > >Status: > >https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ > >Htmlized: https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-0= 3 > >Diff: > >https://www.ietf.org/rfcdiff?url2=3Ddraft-spallagatti-bfd-vxlan-03 > > > >Abstract: > > This document describes use of Bidirectional Forwarding Detection > > (BFD) protocol for VXLAN . > > > > > > > > > > > > > >Please note that it may take a couple of minutes from the time of > >submission until the htmlized version and diff are available at > >tools.ietf.org. > > > >The IETF Secretariat > > > >_______________________________________________ > >nvo3 mailing list > >nvo3@ietf.org > >https://www.ietf.org/mailman/listinfo/nvo3 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > =20 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 >=20 > =20 > =20 --Apple-Mail-E735CAF6-E663-49A3-9FF7-BB337CA1FDF9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Haha!

Regards,
Shahram


On May 23, 2016, at 1:22 PM, Gregory Mirsky &= lt;gregory.mirsky@ericsson.co= m> wrote:

Because this is IETF = J

 

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Shahram Davari
Sent: Monday, May 23, 2016 1:18 PM
To: Greg Mirsky; Anoop Ghanwani
Cc: rtg-ooam-dt@ietf.org;= rtg-bfd@ietf.org; nvo3@ietf.org
Subject: RE: [nvo3] FW: New Version Notification for draft-spallagatt= i-bfd-vxlan-03.txt

 

Greg,

=

 

I am wondering why you are n= ot using Ethernet-OAM over VXLAN rather than encapsulating BFD in UDP/IP/Eth= ernet and then encapsulating it in VXLAN?

 

Thx

Shahram

 

From: Rtg-bfd [ma= ilto:rtg-bfd-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Monday, May 23, 2016 12:49 PM
To: Anoop Ghanwani
Cc: rtg-ooam-dt@ietf.org;= rtg-bfd@ietf.org; nvo3@ietf.org
= Subject: Re: [nvo3] FW: New Version Notification for draft-spallagatt= i-bfd-vxlan-03.txt

 

Now with the correct OOAM-DT address

 

On Mon, May 23, 2016 at 12:47 PM, Greg Mirsky <gregimirsky@gmail.com= > wrote:

+BFD WG and RTGWG OOAM DT

 

Hi Anoop,

thank you for your review and the question. The scope= of this draft is only for the VXLAN. The Overlay OAM Desing Team is working= on the Requirements, Gap Analysis and, if there will be required, enhanceme= nts and/or new OAM protocols for BIER, NSH, VXLAN-GPE, GENEVE, and GUE, as defined in its charter. Would appreciat= e you review and comments of the two documents the OOAM-DT already presented= in BA meeting:

  • OOAM Requirements
  • OAM for Overlay Networks: Gap a= nalysis

In the l= atter you'll find the example to demonstrate applicability of BFD Async mode= in BIER domain. As we've discussed, other BFD may be applied to other overl= ay networks that I've listed above even though their method of indication OAM payload may be different from BI= ER. Would you agree, or suggest to have another example of BFD?<= /o:p>

 

Regards,= Greg

 

On Mon, May 23, 2016 at 12:26 PM, Anoop Ghanwani <= anoop@alumni.duke= .edu> wrote:

Authors,

 

In section 4.1, you have this:

>>> 

   Next Protocol Field in GPE hea=
der MUST be set to IPv4 or IPv6.
...
   The BFD packet MUST be carried=
 inside the inner MAC frame of the
   VxLAN packet.  The inner M=
AC frame carrying the BFD payload has the
   following format:<=
/o:p>

>>> 

 

These two statements seem to contradict each other.&n= bsp; If the GPE header indicates IPv4 or IPv6, then how can the BFD packet b= e encapsulated within a MAC frame?

 

Can you please clarify?

 

Thanks,

Anoop

 

 

On Mon, May 23, 2016 at 8:15 AM, Bocci, Matthew (Noki= a - GB) <mat= thew.bocci@nokia.com> wrote:

Folks

Please could you direct any discussion on this draft to the NVO3 working
= group list.

Regards

Matthew

On 18/04/2016, 07:54, "nvo3 on behalf of Vengada Prasad Govindan
(venggovi)" <n= vo3-bounces@ietf.org on behalf of venggovi@cisco.com> wrote:

>Hello all,
>  The authors request comments on the draft below.
>Thanks
>Prasad
>
>-----Original Message-----
>From: inte= rnet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>Sent: Saturday, April 16, 2016 11:33 AM
>To: MALLIK MUDIGONDA (mmudigon) <mmudigon@cisco.com>; Basil Saji
><sbasil@junip= er.net>; Greg Mirsky <gregory.mirsky@ericsson.com>; Vengada
>Prasad Govindan (venggovi) <venggovi@cisco.com>; Juniper Networks
><santoshpk= @juniper.net>; Sudarsan Paragiri <sparagiri@juniper.net>;
>Santosh Pallagatti <santoshpk@juniper.net>; sajibasil@gmail.com=
><sbasil@junip= er.net>
>Subject: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt=
>
>
>A new version of I-D, draft-spallagatti-bfd-vxlan-03.txt
>has been successfully submitted by Vengada Prasad Govindan and posted to=
>the IETF repository.
>
>Name:          draft-spallagatti-bfd-vxlan
>Revision:      03
>Title:         BFD for VXLAN
>Document date: 2016-04-15
>Group:         Individual Submission
>Pages:         9
>URL:
>https://www.ietf.org/internet-drafts/draft-spa= llagatti-bfd-vxlan-03.txt
>Status:
>https://datatracker.ietf.org/doc/draft-spallagatti-bfd-v= xlan/
>Htmlized:       https://tools.ietf.org/= html/draft-spallagatti-bfd-vxlan-03
>Diff:
>https://www.ietf.org/rfcdiff?url2=3Ddraft-spallagat= ti-bfd-vxlan-03
>
>Abstract:
>   This document describes use of Bidirectional Forwarding Det= ection
>   (BFD) protocol for VXLAN .
>
>
>
>
>
>
>Please note that it may take a couple of minutes from the time of
>submission until the htmlized version and diff are available at
>tools.ietf.org.<= br> >
>The IETF Secretariat
>
>_______________________________________________
>nvo3 mailing list
>nvo3@ietf.org
= >https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/nvo3

 


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/nvo3

 

 

= --Apple-Mail-E735CAF6-E663-49A3-9FF7-BB337CA1FDF9-- From nobody Mon May 23 14:22:55 2016 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 CC56C12DBE6 for ; Mon, 23 May 2016 14:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 4C0JNOCeiVHF for ; Mon, 23 May 2016 14:22:42 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 947C412DBD6 for ; Mon, 23 May 2016 14:22:38 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id f66so240141551vkh.2 for ; Mon, 23 May 2016 14:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=jS5d9wyyPVrQefaQV02sPPjw8XOj0QmnQDb7Sq8LpZU=; b=ZvQcRZWBM7wCI46KPPtOBQ9QNjXodsKbrbIbBQql2T0dksqNtY1FhW4Qx+MdqOYKKP gZJirZimjH0ackCKTUr9w7DDXdOLNl5CZEDb1QLY6/ybpYjS7inxXDRzMqjzbhl+IMOv bN+l6Ar8fd0/yTBPck0xbMVWbu1nxrT5QmBqE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=jS5d9wyyPVrQefaQV02sPPjw8XOj0QmnQDb7Sq8LpZU=; b=G/fPHh4HLkdc3LG+5y2v52nDneRNg064/4YBcJ7+y5Jq0w1mltkvGs+BIhHpldQSk9 m06xDTCmdrl044jGh81PIDKHgy5iL3v/STLJbQSlR6wfY5Slz4CJqDZzARQI/gjEEC4u SyULg4wow6PpPtmKSuuxOWLWJwJBPKVZNK0htya4CXHRZbKxCSjcQt/oY2UVdd0Z9O5D PXoAjV0bHPq8mzlPP1zeHWR88Ht0OQlcgwA+RP1iqfUis01dzvNnHGzzjdrzckZ+s8DS ckUWFNKd5Mg4SEQt1IGnIRaTmTrYD+tfj60yHDP9apHffjAz9kV+YeSt67M7SF8dBYH6 lxxg== X-Gm-Message-State: ALyK8tKbqH8JGgeQ91b1LFI/4r1gGq+T2KBOf+LPjF43UO3hPfqjFhk2Xzc5HMXRxu8wfOYZf4FwyBNUf4nNLVjy X-Received: by 10.159.36.168 with SMTP id 37mr598602uar.136.1464038557302; Mon, 23 May 2016 14:22:37 -0700 (PDT) From: Shahram Davari References: <20160416060248.17419.11591.idtracker@ietfa.amsl.com> <8f73ecae119843dcba447c54084c80f8@XCH-RCD-020.cisco.com> <0c05fec5720ad0229565ffa74973e96e@mail.gmail.com> <7347100B5761DC41A166AC17F22DF11221A81BF2@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A81BF2@eusaamb103.ericsson.se> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIMrdB/5G2mlwEeqn9cfT8TbquBagFzuiT1AuMuV+UChXSj3AGFqJCxAjED+U4CMZbQEAGZxsBnnt4bbCA= Date: Mon, 23 May 2016 14:22:34 -0700 Message-ID: Subject: RE: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt To: Gregory Mirsky , Greg Mirsky , Anoop Ghanwani Content-Type: multipart/alternative; boundary=001a113cf8b8261a310533890acd Archived-At: Cc: rtg-ooam-dt@ietf.org, rtg-bfd@ietf.org, nvo3@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 21:22:51 -0000 --001a113cf8b8261a310533890acd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Greg, On a serious note, Ethernet OAM seems a much better fit here, since we are talking about Layer 2 connectivity. If that is not acceptable by IETF then I have the following questions: 1) We know that the outer IP addresses are the addresses of originating and terminating VTEP. Then Why the inner IP Address is also the Address of VTEP? Shouldn=E2=80=99t the inner IP addresses represent the ori= ginating and terminating OAM processor? 2) Similarly shouldn=E2=80=99t the inner MAC should represent the MAC = address of the OAM processor? 3) Why don=E2=80=99t we define a new Ethertype so we can encapsulate B= FD directly over inner L2? The draft requires multiple IP and UDP headers, that makes processing very complex. Thanks Shahram *From:* Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] *Sent:* Monday, May 23, 2016 1:23 PM *To:* Shahram Davari; Greg Mirsky; Anoop Ghanwani *Cc:* rtg-ooam-dt@ietf.org; rtg-bfd@ietf.org; nvo3@ietf.org *Subject:* RE: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt Because this is IETF J *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org = ] *On Behalf Of *Shahram Davari *Sent:* Monday, May 23, 2016 1:18 PM *To:* Greg Mirsky; Anoop Ghanwani *Cc:* rtg-ooam-dt@ietf.org; rtg-bfd@ietf.org; nvo3@ietf.org *Subject:* RE: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt Greg, I am wondering why you are not using Ethernet-OAM over VXLAN rather than encapsulating BFD in UDP/IP/Ethernet and then encapsulating it in VXLAN? Thx Shahram *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] *On Behalf Of *Greg Mirsk= y *Sent:* Monday, May 23, 2016 12:49 PM *To:* Anoop Ghanwani *Cc:* rtg-ooam-dt@ietf.org; rtg-bfd@ietf.org; nvo3@ietf.org *Subject:* Re: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt Now with the correct OOAM-DT address On Mon, May 23, 2016 at 12:47 PM, Greg Mirsky wrote= : +BFD WG and RTGWG OOAM DT Hi Anoop, thank you for your review and the question. The scope of this draft is only for the VXLAN. The Overlay OAM Desing Team is working on the Requirements, Gap Analysis and, if there will be required, enhancements and/or new OAM protocols for BIER, NSH, VXLAN-GPE, GENEVE, and GUE, as defined in its charter. Would appreciate you review and comments of the two documents the OOAM-DT already presented in BA meeting: - OOAM Requirements - OAM for Overlay Networks: Gap analysis In the latter you'll find the example to demonstrate applicability of BFD Async mode in BIER domain. As we've discussed, other BFD may be applied to other overlay networks that I've listed above even though their method of indication OAM payload may be different from BIER. Would you agree, or suggest to have another example of BFD? Regards, Greg On Mon, May 23, 2016 at 12:26 PM, Anoop Ghanwani wrote: Authors, In section 4.1, you have this: >>> Next Protocol Field in GPE header MUST be set to IPv4 or IPv6. ... The BFD packet MUST be carried inside the inner MAC frame of the VxLAN packet. The inner MAC frame carrying the BFD payload has the following format: >>> These two statements seem to contradict each other. If the GPE header indicates IPv4 or IPv6, then how can the BFD packet be encapsulated within a MAC frame? Can you please clarify? Thanks, Anoop On Mon, May 23, 2016 at 8:15 AM, Bocci, Matthew (Nokia - GB) < matthew.bocci@nokia.com> wrote: Folks Please could you direct any discussion on this draft to the NVO3 working group list. Regards Matthew On 18/04/2016, 07:54, "nvo3 on behalf of Vengada Prasad Govindan (venggovi)" wrote: >Hello all, > The authors request comments on the draft below. >Thanks >Prasad > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Saturday, April 16, 2016 11:33 AM >To: MALLIK MUDIGONDA (mmudigon) ; Basil Saji >; Greg Mirsky ; Vengada >Prasad Govindan (venggovi) ; Juniper Networks >; Sudarsan Paragiri ; >Santosh Pallagatti ; sajibasil@gmail.com > >Subject: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt > > >A new version of I-D, draft-spallagatti-bfd-vxlan-03.txt >has been successfully submitted by Vengada Prasad Govindan and posted to >the IETF repository. > >Name: draft-spallagatti-bfd-vxlan >Revision: 03 >Title: BFD for VXLAN >Document date: 2016-04-15 >Group: Individual Submission >Pages: 9 >URL: >https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan-03.txt >Status: >https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ >Htmlized: https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-03 >Diff: >https://www.ietf.org/rfcdiff?url2=3Ddraft-spallagatti-bfd-vxlan-03 > >Abstract: > This document describes use of Bidirectional Forwarding Detection > (BFD) protocol for VXLAN . > > > > > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --001a113cf8b8261a310533890acd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Gr= eg,

=C2=A0

On a serious note, = Ethernet OAM seems a much better fit here, since we are talking about Layer= 2 connectivity.

=C2=A0

If th= at is not acceptable by IETF then I have the following questions:

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = We know that the outer IP a= ddresses are the addresses of originating and terminating VTEP. Then Why th= e inner IP Address is also the Address of VTEP? Shouldn=E2=80=99t the inner= IP addresses represent the originating and terminating OAM processor?

2)= =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Similarly shou= ldn=E2=80=99t the inner MAC should represent the MAC address of the OAM pro= cessor?

3)=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Wh= y don=E2=80=99t we define a new Ethertype so we can encapsulate BFD directl= y over inner L2? The draft requires multiple IP and UDP headers, that makes= processing very complex.

=C2=A0

Thanks

Shahr= am

=C2=A0

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Monday, May 23, 201= 6 1:23 PM
To: Shahram Davari; Greg Mirsky; Anoop Ghanwani
C= c: rtg-ooam-dt@ietf.org; rtg-bfd@ietf.org; nvo3@ietf.org
Subject: RE: [nvo3] FW: New Versi= on Notification for draft-spallagatti-bfd-vxlan-03.txt

=C2=A0

Because this is IETF J<= /p>

=C2=A0

=

From: Rtg-bfd [mailto:rtg-bfd-bounc= es@ietf.org] On Behalf Of Shahram Davari
Sent: Monday,= May 23, 2016 1:18 PM
To: Greg Mirsky; Anoop Ghanwani
Cc: rtg-ooam-dt@ietf.org; rtg-bfd@ietf.org; nvo3@ietf.org
Subject: RE: [nvo3] FW: New Version N= otification for draft-spallagatti-bfd-vxlan-03.txt

=C2=A0

Greg,

=C2= =A0

I am wonder= ing why you are not using Ethernet-OAM over VXLAN rather than encapsulating= BFD in UDP/IP/Ethernet and then encapsulating it in VXLAN?

=C2=A0

Thx

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">Shahram

=C2=A0

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Greg Mirsk= y
Sent: Monday, May 23, 2016 12:49 PM
To: Anoop Ghanwan= i
Cc: rtg-ooam-dt@ietf.or= g; rtg-bfd@ietf.org; nvo3@ietf.org
Subject: Re: [nvo3] FW: = New Version Notification for draft-spallagatti-bfd-vxlan-03.txt

<= p class=3D"MsoNormal">=C2=A0

Now with the co= rrect OOAM-DT address

=C2=A0

<= p class=3D"MsoNormal">On Mon, May 23, 2016 at 12:47 PM, Greg Mirsky <gregimirsky@gmail.c= om> wrote:

+BFD WG and RTGWG OOAM DT<= /p>

=C2=A0

= Hi Anoop,

thank you for your review an= d the question. The scope of this draft is only for the VXLAN. The Overlay = OAM Desing Team is working on the Requirements, Gap Analysis and, if there = will be required, enhancements and/or new OAM protocols for=C2=A0BIER, NSH, VXLAN-GPE, GENEVE, and GUE, a= s defined in its charter. Would appreciate you review and comments of the t= wo documents the OOAM-DT already presented in BA meeting:

<= div>
  • OOAM Requirements
  • OAM for Overlay = Networks: Gap analysis

In the latter you'll find the example= to demonstrate applicability of BFD Async mode in BIER domain. As we'v= e discussed, other BFD may be applied to other overlay networks that I'= ve listed above even though their method of indication OAM payload may be d= ifferent from BIER. Would you agree, or suggest to have another example of = BFD?

=C2=A0

Regards, Gre= g

=C2=A0

On Mon, May 23, 2016 at 12:26 PM, Anoop Ghanwani &= lt;anoop@alumni.= duke.edu> wrote:

Authors,

=C2=A0

In section = 4.1, you have this:

>>>=C2=A0= 

=C2=A0=C2=A0 Next Protocol =
Field in GPE header MUST be set to IPv4 or IPv6.
...
=C2=A0=
=C2=A0 The BFD packet MUST be carried inside the inner MAC frame of the
=C2=A0=C2=A0 VxLAN packet.=C2=A0 =
The inner MAC frame carrying the BFD payload has the
=C2=A0=C2=A0 following format:

>>>=C2=A0

=C2=A0

These two statements seem= to contradict each other.=C2=A0 If the GPE header indicates IPv4 or IPv6, = then how can the BFD packet be encapsulated within a MAC frame?

=C2=A0

Can y= ou please clarify?

=C2=A0

Thanks,

Anoop=

=C2=A0

=

=C2=A0

On Mon, May 23= , 2016 at 8:15 AM, Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com> wrote:=

Folks

Please could you direct any discuss= ion on this draft to the NVO3 working
group list.

Regards

= Matthew

On 18/04/2016, 07:54, "nvo3 on behalf of Vengada Prasad= Govindan
(venggovi)" <nvo3-bounces@ietf.org on behalf of venggovi@cisco.com> wrote:
=
>Hello all,
>=C2=A0 The authors request comments on the draft = below.
>Thanks
>Prasad
>
>-----Original Message----= -
>From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>Sent: Saturd= ay, April 16, 2016 11:33 AM
>To: MALLIK MUDIGONDA (mmudigon) <mmudigon@cisco.com&= gt;; Basil Saji
><sbasil@juniper.net>; Greg Mirsky <gregory.mirsky@ericsson.com&g= t;; Vengada
>Prasad Govindan (venggovi) <venggovi@cisco.com>; Juniper Networks=
><sant= oshpk@juniper.net>; Sudarsan Paragiri <sparagiri@juniper.net>;
>Sant= osh Pallagatti <santoshpk@juniper.net>; sajibasil@gmail.com
><sbasil@juniper.net>
>Subject: = New Version Notification for draft-spallagatti-bfd-vxlan-03.txt
>
= >
>A new version of I-D, draft-spallagatti-bfd-vxlan-03.txt
>= ;has been successfully submitted by Vengada Prasad Govindan and posted to>the IETF repository.
>
>Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 draft-spallagatti-bfd-vxlan
>Revision:=C2=A0 =C2=A0 =C2=A0 03<= br>>Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD for VXLAN
>Documen= t date: 2016-04-15
>Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individua= l Submission
>Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A09
>URL:>https://www.ietf.org/internet-drafts/draft= -spallagatti-bfd-vxlan-03.txt
>Status:
>ht= tps://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/
>Html= ized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/d= raft-spallagatti-bfd-vxlan-03
>Diff:
>https://www.ietf.org/rfcdiff?url2=3Ddraft-spallagatti-bfd-vxlan-03
= >
>Abstract:
>=C2=A0 =C2=A0This document describes use of Bi= directional Forwarding Detection
>=C2=A0 =C2=A0(BFD) protocol for VXL= AN .
>
>
>
>
>
>
>Please note tha= t it may take a couple of minutes from the time of
>submission until = the htmlized version and diff are available at
>tools.ietf.org.
>
>The IETF = Secretariat
>
>_______________________________________________<= br>>nvo3 mailing list
>nvo3@ietf.org
>https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
nvo3 mailing l= ist
nvo3@ietf.org=
https://www.ietf.org/mailman/listinfo/nvo3

=C2=A0


_______________________________________________
nvo3 ma= iling list
nvo3@ietf.= org
https://www.ietf.org/mailman/listinfo/nvo3

=C2=A0

=C2= =A0

--001a113cf8b8261a310533890acd-- From nobody Mon May 23 14:35:34 2016 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 B120612D1D9; Mon, 23 May 2016 14:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 0rmAJt-qMgzs; Mon, 23 May 2016 14:35:29 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 E4E5212D587; Mon, 23 May 2016 14:35:28 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id n63so117877936qkf.0; Mon, 23 May 2016 14:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=ceSV0NHO359afKoomou24ZIhScpnZ36sN6SGTKsY8/I=; b=hO5Z3zHPP0SNjBwZLmc2bK22zr1fpY+h0qAyWgMISJlStIpI4vg2OVbuzDpj0vcYNd ykRVxAwqSEyVE+gN18tx/+NX4d8/p17FhkRWUnnzpwFiAFWl/CaAt1o9giFmucZfsXKr FWLTNyWZXOC3PdB8v9nudxEydTqu+TuGl0V2zyIwHvojyYyhcTAWYZIIT3Imem2oqKzf rZ7rtc6K5FW7ZQ2bDSw0sEPsdXQsZYtrUERLz7y8gJldGA7bCeISyhmMTrSE3/Qke4uU fmfkozjjp0L3Pw1geFbV3g5bZ7GqAgwsq4PeiK8CuKpLIPvaWGXgj0WCasseCrcG9NgB iOMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ceSV0NHO359afKoomou24ZIhScpnZ36sN6SGTKsY8/I=; b=a5NZXniC9kpFw8J3y6/vcnTvreD6YDSeZhNqV2tIOVgldRoXmDnMb39u50h6CuuR45 LT1ZEKcMZNJBD60cDT8iKKDomN5LFL8XObG1AMvU7fH6hySPTWJ1otaa5/DVrCgcvZ6Z MKbxJ2KgIGkACKypFftjgdK225tnu4zZmr5ZePfBY7rLj7LLrCHNxRqJ4ZF8jB/6QNPt i09v+nYjX3n9txlQBD9P7nk4BwXCLeh5ukgPTjzz9ntmhxt7RcTPl/21HEjlTQIXT79M OVASs1hiE/c45myQ1JXvwherISPsJGryfa9peBol7D6Wtqq0wLc/NOWng66PuY+hGS8s tBNQ== X-Gm-Message-State: ALyK8tIOUPSS+qKIS0aYj5Zx5evubikfdCJNgY4phl4R60CCj9qP8lHAvRQiKQpJaQ0v5eFVYGoB8rdN6k/JQA== MIME-Version: 1.0 X-Received: by 10.55.192.209 with SMTP id v78mr339889qkv.122.1464039327972; Mon, 23 May 2016 14:35:27 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.55.135.199 with HTTP; Mon, 23 May 2016 14:35:27 -0700 (PDT) In-Reply-To: References: <20160416060248.17419.11591.idtracker@ietfa.amsl.com> <8f73ecae119843dcba447c54084c80f8@XCH-RCD-020.cisco.com> Date: Mon, 23 May 2016 14:35:27 -0700 X-Google-Sender-Auth: n4cF5WB511KBAbJFMDnXJ0mBYOk Message-ID: Subject: Re: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt From: Anoop Ghanwani To: Greg Mirsky Content-Type: multipart/alternative; boundary=001a1147a66a14c4530533893824 Archived-At: Cc: rtgwg-ooam-dt@ietf.org, "rtg-bfd@ietf.org" , "nvo3@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 21:35:32 -0000 --001a1147a66a14c4530533893824 Content-Type: text/plain; charset=UTF-8 Hi Greg, I think Larry has covered the points I was trying to bring up...if there's a MAC header present, then the VXLAN GPE next header has to indicate "Ethernet" rather than "IPv4" or "IPv6". Thanks, Anoop On Mon, May 23, 2016 at 12:47 PM, Greg Mirsky wrote: > +BFD WG and RTGWG OOAM DT > > Hi Anoop, > thank you for your review and the question. The scope of this draft is > only for the VXLAN. The Overlay OAM Desing Team is working on the > Requirements, Gap Analysis and, if there will be required, enhancements > and/or new OAM protocols for BIER, NSH, VXLAN-GPE, GENEVE, and GUE, as > defined in its charter. Would appreciate you review and comments of the two > documents the OOAM-DT already presented in BA meeting: > > - OOAM Requirements > - OAM for Overlay Networks: Gap analysis > > In the latter you'll find the example to demonstrate applicability of BFD > Async mode in BIER domain. As we've discussed, other BFD may be applied to > other overlay networks that I've listed above even though their method of > indication OAM payload may be different from BIER. Would you agree, or > suggest to have another example of BFD? > > Regards, Greg > > On Mon, May 23, 2016 at 12:26 PM, Anoop Ghanwani > wrote: > >> Authors, >> >> In section 4.1, you have this: >> >>> >> >> Next Protocol Field in GPE header MUST be set to IPv4 or IPv6. >> ... >> The BFD packet MUST be carried inside the inner MAC frame of the >> VxLAN packet. The inner MAC frame carrying the BFD payload has the >> following format: >> >> >>> >> >> These two statements seem to contradict each other. If the GPE header >> indicates IPv4 or IPv6, then how can the BFD packet be encapsulated within >> a MAC frame? >> >> Can you please clarify? >> >> Thanks, >> Anoop >> >> >> On Mon, May 23, 2016 at 8:15 AM, Bocci, Matthew (Nokia - GB) < >> matthew.bocci@nokia.com> wrote: >> >>> Folks >>> >>> Please could you direct any discussion on this draft to the NVO3 working >>> group list. >>> >>> Regards >>> >>> Matthew >>> >>> On 18/04/2016, 07:54, "nvo3 on behalf of Vengada Prasad Govindan >>> (venggovi)" >>> wrote: >>> >>> >Hello all, >>> > The authors request comments on the draft below. >>> >Thanks >>> >Prasad >>> > >>> >-----Original Message----- >>> >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> >Sent: Saturday, April 16, 2016 11:33 AM >>> >To: MALLIK MUDIGONDA (mmudigon) ; Basil Saji >>> >; Greg Mirsky ; >>> Vengada >>> >Prasad Govindan (venggovi) ; Juniper Networks >>> >; Sudarsan Paragiri ; >>> >Santosh Pallagatti ; sajibasil@gmail.com >>> > >>> >Subject: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt >>> > >>> > >>> >A new version of I-D, draft-spallagatti-bfd-vxlan-03.txt >>> >has been successfully submitted by Vengada Prasad Govindan and posted to >>> >the IETF repository. >>> > >>> >Name: draft-spallagatti-bfd-vxlan >>> >Revision: 03 >>> >Title: BFD for VXLAN >>> >Document date: 2016-04-15 >>> >Group: Individual Submission >>> >Pages: 9 >>> >URL: >>> >https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan-03.txt >>> >Status: >>> >https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ >>> >Htmlized: >>> https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-03 >>> >Diff: >>> >https://www.ietf.org/rfcdiff?url2=draft-spallagatti-bfd-vxlan-03 >>> > >>> >Abstract: >>> > This document describes use of Bidirectional Forwarding Detection >>> > (BFD) protocol for VXLAN . >>> > >>> > >>> > >>> > >>> > >>> > >>> >Please note that it may take a couple of minutes from the time of >>> >submission until the htmlized version and diff are available at >>> >tools.ietf.org. >>> > >>> >The IETF Secretariat >>> > >>> >_______________________________________________ >>> >nvo3 mailing list >>> >nvo3@ietf.org >>> >https://www.ietf.org/mailman/listinfo/nvo3 >>> >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >> >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> > --001a1147a66a14c4530533893824 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Greg,

I think Larry has covered the = points I was trying to bring up...if there's a MAC header present, then= the VXLAN GPE next header has to indicate "Ethernet" rather than= "IPv4" or "IPv6".

Thanks,
Anoop

On Mon, May 23, 2016 at 12:47 PM, Greg Mirsky <= gregimirsky@gmai= l.com> wrote:
+BFD WG and RTGWG OOAM DT

Hi Anoop,
thank = you for your review and the question. The scope of this draft is only for t= he VXLAN. The Overlay OAM Desing Team is working on the Requirements, Gap A= nalysis and, if there will be required, enhancements and/or new OAM protoco= ls for=C2=A0BIER, NSH, VXLAN-GPE, GENEVE, and G= UE, as defined in its charter. Would appreciate you review and comments of = the two documents the OOAM-DT already presented in BA meeting:
=
  • OOAM Requirements
    • OAM for Overlay Networks: Gap analysis
In the latter you'll find the exam= ple to demonstrate applicability of BFD Async mode in BIER domain. As we= 9;ve discussed, other BFD may be applied to other overlay networks that I&#= 39;ve listed above even though their method of indication OAM payload may b= e different from BIER. Would you agree, or suggest to have another example = of BFD?

<= /div>
Regards, Greg

On Mon, May 23, 2016 at 12:26 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
Authors,

In section 4.1, you have t= his:
>>>
   Next Protocol Field in G=
PE header MUST be set to IPv4 or IPv6.
...
   The BFD packet MUST be carried inside the inner MAC frame of the
   VxLAN packet.  The inner MAC frame carrying the BFD payload has the
   following format:
>>>

= These two statements seem to contradict each other.=C2=A0 If the GPE header= indicates IPv4 or IPv6, then how can the BFD packet be encapsulated within= a MAC frame?

Can you please clarify?
Thanks,
Anoop


On Mon, May 23, 201= 6 at 8:15 AM, Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com> wrote:
Folks

Please could you direct any discussion on this draft to the NVO3 working group list.

Regards

Matthew

On 18/04/2016, 07:54, "nvo3 on behalf of Vengada Prasad Govindan
(venggovi)" <nvo3-bounces@ietf.org on behalf of venggovi@cisco.com> wrote:

>Hello all,
>=C2=A0 The authors request comments on the draft below.
>Thanks
>Prasad
>
>-----Original Message-----
>From: int= ernet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>Sent: Saturday, April 16, 2016 11:33 AM
>To: MALLIK MUDIGONDA (mmudigon) <mmudigon@cisco.com>; Basil Saji
><sbasil@juni= per.net>; Greg Mirsky <gregory.mirsky@ericsson.com>; Vengada
>Prasad Govindan (venggovi) <venggovi@cisco.com>; Juniper Networks
><santoshp= k@juniper.net>; Sudarsan Paragiri <sparagiri@juniper.net>;
>Santosh Pallagatti <santoshpk@juniper.net>; sajibasil@gmail.com
><sbasil@juni= per.net>
>Subject: New Version Notification for draft-spallagatti-bfd-vxlan-03.tx= t
>
>
>A new version of I-D, draft-spallagatti-bfd-vxlan-03.txt
>has been successfully submitted by Vengada Prasad Govindan and posted t= o
>the IETF repository.
>
>Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-spallagatti-bfd-vxlan
>Revision:=C2=A0 =C2=A0 =C2=A0 03
>Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD for VXLAN
>Document date: 2016-04-15
>Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
>Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A09
>URL:
>https://www.ietf.org/inte= rnet-drafts/draft-spallagatti-bfd-vxlan-03.txt
>Status:
>https://datatracker.ietf.org/doc/dr= aft-spallagatti-bfd-vxlan/
>Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-03
>Diff:
>https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-spallagatti-bfd-vxlan-03
>
>Abstract:
>=C2=A0 =C2=A0This document describes use of Bidirectional Forwarding De= tection
>=C2=A0 =C2=A0(BFD) protocol for VXLAN .
>
>
>
>
>
>
>Please note that it may take a couple of minutes from the time of
>submission until the htmlized version and diff are available at
>= tools.ietf.org.
>
>The IETF Secretariat
>
>_______________________________________________
>nvo3 mailing list
>nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3



--001a1147a66a14c4530533893824-- From nobody Mon May 23 14:36:18 2016 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 8E35D12D5A7 for ; Mon, 23 May 2016 14:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 ryvv4pi2iFOj for ; Mon, 23 May 2016 14:36:14 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 D067312D52A for ; Mon, 23 May 2016 14:36:13 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id r140so62782693vkf.0 for ; Mon, 23 May 2016 14:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=/rVuy69PEfLhucizZGEJe+rq8r+DZ+SKfZOCcBy0swc=; b=LkpR5NX/9akfeEL6MvscuLIU82Tnj75uXrAybjmFO5oYWpOpZzycMoAhnGrg+Mvlax OJgeYCEmWlqFplBhDrNQX9/YtRrOMUwdHv8ZMupoSVoy5TMSTfmKvTcN7hidU9H87lPB kVYCIjU6r9kexPJPPAxdGkF8gsthW3pdcaSt4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=/rVuy69PEfLhucizZGEJe+rq8r+DZ+SKfZOCcBy0swc=; b=bro+usXwXMBewjYJYSKCNbs+bf5vtR7wfN/xNiz/B5NhZf4Yby2dMjwc2vYCCN+z9M EAX/HdpRJmYaXD42+ghd1H19se3g6E5kiqHigTAiXFIjQ4nvvicpjnnPpBYqXFzPEzQw /YEOkF9cpSiWD1oXz1S3Iyu4PHUx5+rYVTcs/yvhrIu2jNptTnY64Sal2L0uDwCP2KQg V0trQXbqpvjey6/lZwo2c5T0x+8NW3onUZjIGodWGo2BipUZYVJ/xIuXNLvFeXQBkQlr TcdsKhw/NnMjNi0oNrd2kTBBpQ2nVgunA1WIfCbHKHVcR4Qz/8eCh+ukzNlKNf/hCKCS jC+Q== X-Gm-Message-State: ALyK8tIvm65XiwUvgEUawZUeAvJUma3po8oQMX7gNU7ihCWprsd7QPK7Jd30oT2vlXMdx1xKO2eKFEtNCd6+2F/l X-Received: by 10.159.41.71 with SMTP id t65mr672523uat.22.1464039372696; Mon, 23 May 2016 14:36:12 -0700 (PDT) From: Shahram Davari References: <20160416060248.17419.11591.idtracker@ietfa.amsl.com> <8f73ecae119843dcba447c54084c80f8@XCH-RCD-020.cisco.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIMrdB/5G2mlwEeqn9cfT8TbquBagFzuiT1AuMuV+UChXSj3AGFqJCxApxeQaSe+Sdt0A== Date: Mon, 23 May 2016 14:36:10 -0700 Message-ID: <00ac6551aee9714b93b8f94079b57cbf@mail.gmail.com> Subject: RE: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt To: Anoop Ghanwani , Greg Mirsky Content-Type: multipart/alternative; boundary=001a114b1c8ac00d4e0533893a2f Archived-At: Cc: rtgwg-ooam-dt@ietf.org, rtg-bfd@ietf.org, nvo3@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 21:36:16 -0000 --001a114b1c8ac00d4e0533893a2f Content-Type: text/plain; charset=UTF-8 Anoop is correct. Thx SD *From:* nvo3 [mailto:nvo3-bounces@ietf.org] *On Behalf Of *Anoop Ghanwani *Sent:* Monday, May 23, 2016 2:35 PM *To:* Greg Mirsky *Cc:* rtgwg-ooam-dt@ietf.org; rtg-bfd@ietf.org; nvo3@ietf.org *Subject:* Re: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt Hi Greg, I think Larry has covered the points I was trying to bring up...if there's a MAC header present, then the VXLAN GPE next header has to indicate "Ethernet" rather than "IPv4" or "IPv6". Thanks, Anoop On Mon, May 23, 2016 at 12:47 PM, Greg Mirsky wrote: +BFD WG and RTGWG OOAM DT Hi Anoop, thank you for your review and the question. The scope of this draft is only for the VXLAN. The Overlay OAM Desing Team is working on the Requirements, Gap Analysis and, if there will be required, enhancements and/or new OAM protocols for BIER, NSH, VXLAN-GPE, GENEVE, and GUE, as defined in its charter. Would appreciate you review and comments of the two documents the OOAM-DT already presented in BA meeting: - OOAM Requirements - OAM for Overlay Networks: Gap analysis In the latter you'll find the example to demonstrate applicability of BFD Async mode in BIER domain. As we've discussed, other BFD may be applied to other overlay networks that I've listed above even though their method of indication OAM payload may be different from BIER. Would you agree, or suggest to have another example of BFD? Regards, Greg On Mon, May 23, 2016 at 12:26 PM, Anoop Ghanwani wrote: Authors, In section 4.1, you have this: >>> Next Protocol Field in GPE header MUST be set to IPv4 or IPv6. ... The BFD packet MUST be carried inside the inner MAC frame of the VxLAN packet. The inner MAC frame carrying the BFD payload has the following format: >>> These two statements seem to contradict each other. If the GPE header indicates IPv4 or IPv6, then how can the BFD packet be encapsulated within a MAC frame? Can you please clarify? Thanks, Anoop On Mon, May 23, 2016 at 8:15 AM, Bocci, Matthew (Nokia - GB) < matthew.bocci@nokia.com> wrote: Folks Please could you direct any discussion on this draft to the NVO3 working group list. Regards Matthew On 18/04/2016, 07:54, "nvo3 on behalf of Vengada Prasad Govindan (venggovi)" wrote: >Hello all, > The authors request comments on the draft below. >Thanks >Prasad > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Saturday, April 16, 2016 11:33 AM >To: MALLIK MUDIGONDA (mmudigon) ; Basil Saji >; Greg Mirsky ; Vengada >Prasad Govindan (venggovi) ; Juniper Networks >; Sudarsan Paragiri ; >Santosh Pallagatti ; sajibasil@gmail.com > >Subject: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt > > >A new version of I-D, draft-spallagatti-bfd-vxlan-03.txt >has been successfully submitted by Vengada Prasad Govindan and posted to >the IETF repository. > >Name: draft-spallagatti-bfd-vxlan >Revision: 03 >Title: BFD for VXLAN >Document date: 2016-04-15 >Group: Individual Submission >Pages: 9 >URL: >https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan-03.txt >Status: >https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ >Htmlized: https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-03 >Diff: >https://www.ietf.org/rfcdiff?url2=draft-spallagatti-bfd-vxlan-03 > >Abstract: > This document describes use of Bidirectional Forwarding Detection > (BFD) protocol for VXLAN . > > > > > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --001a114b1c8ac00d4e0533893a2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

An= oop is correct.

=C2=A0

Thx
= SD

=C2=A0

From: nvo= 3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Anoop Ghanwani
Sent: Monday, May 23, 2016 = 2:35 PM
To: Greg Mirsky
Cc: rtgwg-ooam-dt@ietf.org; rtg-bfd@ietf.org; nvo3@ietf.org
Subject: Re: [nvo3] FW: New Version Notification for draft-spal= lagatti-bfd-vxlan-03.txt

=C2=A0

Hi Greg,

=C2=A0

I think Larry has covered the points I was tr= ying to bring up...if there's a MAC header present, then the VXLAN GPE = next header has to indicate "Ethernet" rather than "IPv4&quo= t; or "IPv6".

=C2=A0

Thanks,

= Anoop

=C2=A0

On Mon, May 23, 2016 at 12:47 PM, Greg Mirsky <gregimirsky@gmail.com>= wrote:

+BFD WG and RTGWG OOAM DT

=C2=A0

Hi Anoop,<= /p>

thank you for your review and the ques= tion. The scope of this draft is only for the VXLAN. The Overlay OAM Desing= Team is working on the Requirements, Gap Analysis and, if there will be re= quired, enhancements and/or new OAM protocols for=C2=A0BIER, NSH, VXLAN-GPE, GENEVE, and GUE, as defined = in its charter. Would appreciate you review and comments of the two documen= ts the OOAM-DT already presented in BA meeting:

  • OOAM Requirements
  • OAM for Overlay Networks:= Gap analysis

In the latter you'll find the example to demonst= rate applicability of BFD Async mode in BIER domain. As we've discussed= , other BFD may be applied to other overlay networks that I've listed a= bove even though their method of indication OAM payload may be different fr= om BIER. Would you agree, or suggest to have another example of BFD?=

=C2=A0

Regards, Greg

=C2=A0

On Mon, May 23, 2016 at 12:26 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:

Authors,

= 
=C2=A0=C2=A0 Next Protocol Field in G=
PE header MUST be set to IPv4 or IPv6.
...
=C2=A0=C2=A0 The =
BFD packet MUST be carried inside the inner MAC frame of the
=C2=A0=C2=A0 VxLAN packet.=C2=A0 The inner M= AC frame carrying the BFD payload has the
=C2=A0=C2=A0 following format:

>>>=C2=A0

=C2= =A0

These two statements seem to contr= adict each other.=C2=A0 If the GPE header indicates IPv4 or IPv6, then how = can the BFD packet be encapsulated within a MAC frame?

=C2=A0

Can you please= clarify?

=C2=A0

Thanks,

Anoop

=C2=A0

=C2=A0

On Mon, May 23, 2016 a= t 8:15 AM, Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com> wrote:

Folks

Please could you direct any discussion on t= his draft to the NVO3 working
group list.

Regards

Matthew<= br>
On 18/04/2016, 07:54, "nvo3 on behalf of Vengada Prasad Govinda= n
(venggovi)" <nvo3-bounces@ietf.org on behalf of venggovi@cisco.com> wrote:

&g= t;Hello all,
>=C2=A0 The authors request comments on the draft below.=
>Thanks
>Prasad
>
>-----Original Message-----
&= gt;From: inte= rnet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>Sent: Saturday, Ap= ril 16, 2016 11:33 AM
>To: MALLIK MUDIGONDA (mmudigon) <mmudigon@cisco.com>; B= asil Saji
><sbasil@juniper.net>; Greg Mirsky <gregory.mirsky@ericsson.com>; Ve= ngada
>Prasad Govindan (venggovi) <venggovi@cisco.com>; Juniper Networks
&g= t;<santoshpk@= juniper.net>; Sudarsan Paragiri <sparagiri@juniper.net>;
>Santosh Pa= llagatti <san= toshpk@juniper.net>; sajibasil@gmail.com
><sbasil@juniper.net>
>Subject: New = Version Notification for draft-spallagatti-bfd-vxlan-03.txt
>
>=
>A new version of I-D, draft-spallagatti-bfd-vxlan-03.txt
>has= been successfully submitted by Vengada Prasad Govindan and posted to
&g= t;the IETF repository.
>
>Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 draft-spallagatti-bfd-vxlan
>Revision:=C2=A0 =C2=A0 =C2=A0 03
= >Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD for VXLAN
>Document d= ate: 2016-04-15
>Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual S= ubmission
>Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A09
>URL:
&= gt;https://www.ietf.org/internet-drafts/draft-sp= allagatti-bfd-vxlan-03.txt
>Status:
>https= ://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/
>Htmlize= d:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draf= t-spallagatti-bfd-vxlan-03
>Diff:
>ht= tps://www.ietf.org/rfcdiff?url2=3Ddraft-spallagatti-bfd-vxlan-03
>= ;
>Abstract:
>=C2=A0 =C2=A0This document describes use of Bidir= ectional Forwarding Detection
>=C2=A0 =C2=A0(BFD) protocol for VXLAN = .
>
>
>
>
>
>
>Please note that i= t may take a couple of minutes from the time of
>submission until the= htmlized version and diff are available at
>tools.ietf.org.
>
>The IETF Sec= retariat
>
>_______________________________________________
= >nvo3 mailing list
>nvo3@ietf.org
>https://www.ietf.org/mailman/listinfo/nvo3<= br>
_______________________________________________
nvo3 mailing list=
nvo3@ietf.orgh= ttps://www.ietf.org/mailman/listinfo/nvo3

=C2=A0


_______________________________________________
nvo3 maili= ng list
nvo3@ietf.org=
https://www.ietf.org/mailman/listinfo/nvo3

=C2=A0

=C2=A0

--001a114b1c8ac00d4e0533893a2f-- From nobody Mon May 23 14:46:54 2016 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 11D8112D59A; Mon, 23 May 2016 14:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 dblT27f1gpjr; Mon, 23 May 2016 14:46:48 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED18212D177; Mon, 23 May 2016 14:46:47 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-eb-574371c4e729 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id FA.C6.09012.5C173475; Mon, 23 May 2016 23:10:29 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0294.000; Mon, 23 May 2016 17:46:45 -0400 From: Gregory Mirsky To: Anoop Ghanwani , Greg Mirsky Subject: RE: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt Thread-Topic: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt Thread-Index: AQHRl6WcnVPWQh0sjkaryhtWVkeuZJ+PkgEAgDeNkoCAAAkMt4AAYS6A//+/Y0A= Date: Mon, 23 May 2016 21:46:44 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A81D6F@eusaamb103.ericsson.se> References: <20160416060248.17419.11591.idtracker@ietfa.amsl.com> <8f73ecae119843dcba447c54084c80f8@XCH-RCD-020.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A81D6Feusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyuXRPiO7RQudwg4YjohZ7j7tZfJv2lNXi 6XxJi89/tjFa/Gvdy+rA6rHlZLrHzll32T2WLPnJFMAcxWWTkpqTWZZapG+XwJXx+OwW5oIl Dxkrjs35wNTAuOY2YxcjJ4eEgInE54W3WCFsMYkL99azdTFycQgJHGWUeNv1gxXCWc4o0T17 E1gHm4CRxIuNPewgtohAoMSXxwvYQGxmgWqJ21P3soDYwgKREpPOHGCFqImSWPB9NnMXIweQ 7SexcGkKSJhFQFXiTssCsHJeAV+J27PPMkPs+sMksfXpHrCZnEDzf0/vB9vLCHTd91NrmCB2 iUvcejKfCeJqAYkle84zQ9iiEi8f/4P6Rkli0tJzrCB7mQXyJb7Mj4XYJShxcuYTlgmMorOQ TJqFUDULSRVEWFNi/S59iGpFiSndD9khbA2J1jlz2ZHFFzCyr2LkKC0uyMlNNzLYxAiMu2MS bLo7GO9P9zzEKMDBqMTD+0DbKVyINbGsuDL3EKMEB7OSCK9ypXO4EG9KYmVValF+fFFpTmrx IUZpDhYlcV6xR4rhQgLpiSWp2ampBalFMFkmDk6pBsbkAMaLOs941UL2cjJHardt+rOEVfHv j+fJ96Xj43in/nh0Im6ay7r8YOuZX9/LuhevP6i7JC2NfX+4KvOx93PnnticO2f9zbs/9T23 nfbfdvv5OnMVjU+M574xtTi5+0n8EGY7d6ZvckaRuGfe9p3+W4rD/Pk7rz4Uk2xMkmp/7+p+ ZfL9E3ZKLMUZiYZazEXFiQCmnQkQtwIAAA== Archived-At: Cc: "rtg-ooam-dt@ietf.org" , "rtg-bfd@ietf.org" , "nvo3@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 21:46:51 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A81D6Feusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5vb3AsIExhcnJ5LCBTaGFocmFtLCBldC4gYWwsDQp0aGFuayB5b3UgZm9yIHRoZSBjb3Jy ZWN0aW9uLiBXZeKAmWxsIGFkZHJlc3MgaXQgaW4gdGhlIG5leHQgdXBkYXRlLg0KDQogICAgICAg ICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZw0K DQpGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgQW5vb3AgR2hhbndhbmkNClNlbnQ6IE1vbmRheSwgTWF5IDIzLCAyMDE2IDI6MzUgUE0N ClRvOiBHcmVnIE1pcnNreQ0KQ2M6IHJ0Z3dnLW9vYW0tZHRAaWV0Zi5vcmc7IHJ0Zy1iZmRAaWV0 Zi5vcmc7IG52bzNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbnZvM10gRlc6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLTAzLnR4dA0KDQpI aSBHcmVnLA0KDQpJIHRoaW5rIExhcnJ5IGhhcyBjb3ZlcmVkIHRoZSBwb2ludHMgSSB3YXMgdHJ5 aW5nIHRvIGJyaW5nIHVwLi4uaWYgdGhlcmUncyBhIE1BQyBoZWFkZXIgcHJlc2VudCwgdGhlbiB0 aGUgVlhMQU4gR1BFIG5leHQgaGVhZGVyIGhhcyB0byBpbmRpY2F0ZSAiRXRoZXJuZXQiIHJhdGhl ciB0aGFuICJJUHY0IiBvciAiSVB2NiIuDQoNClRoYW5rcywNCkFub29wDQoNCk9uIE1vbiwgTWF5 IDIzLCAyMDE2IGF0IDEyOjQ3IFBNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29t PG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiB3cm90ZToNCitCRkQgV0cgYW5kIFJUR1dH IE9PQU0gRFQNCg0KSGkgQW5vb3AsDQp0aGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3IGFuZCB0aGUg cXVlc3Rpb24uIFRoZSBzY29wZSBvZiB0aGlzIGRyYWZ0IGlzIG9ubHkgZm9yIHRoZSBWWExBTi4g VGhlIE92ZXJsYXkgT0FNIERlc2luZyBUZWFtIGlzIHdvcmtpbmcgb24gdGhlIFJlcXVpcmVtZW50 cywgR2FwIEFuYWx5c2lzIGFuZCwgaWYgdGhlcmUgd2lsbCBiZSByZXF1aXJlZCwgZW5oYW5jZW1l bnRzIGFuZC9vciBuZXcgT0FNIHByb3RvY29scyBmb3IgQklFUiwgTlNILCBWWExBTi1HUEUsIEdF TkVWRSwgYW5kIEdVRSwgYXMgZGVmaW5lZCBpbiBpdHMgY2hhcnRlci4gV291bGQgYXBwcmVjaWF0 ZSB5b3UgcmV2aWV3IGFuZCBjb21tZW50cyBvZiB0aGUgdHdvIGRvY3VtZW50cyB0aGUgT09BTS1E VCBhbHJlYWR5IHByZXNlbnRlZCBpbiBCQSBtZWV0aW5nOg0KDQogICogICBPT0FNIFJlcXVpcmVt ZW50cw0KICAqICAgT0FNIGZvciBPdmVybGF5IE5ldHdvcmtzOiBHYXAgYW5hbHlzaXMNCkluIHRo ZSBsYXR0ZXIgeW91J2xsIGZpbmQgdGhlIGV4YW1wbGUgdG8gZGVtb25zdHJhdGUgYXBwbGljYWJp bGl0eSBvZiBCRkQgQXN5bmMgbW9kZSBpbiBCSUVSIGRvbWFpbi4gQXMgd2UndmUgZGlzY3Vzc2Vk LCBvdGhlciBCRkQgbWF5IGJlIGFwcGxpZWQgdG8gb3RoZXIgb3ZlcmxheSBuZXR3b3JrcyB0aGF0 IEkndmUgbGlzdGVkIGFib3ZlIGV2ZW4gdGhvdWdoIHRoZWlyIG1ldGhvZCBvZiBpbmRpY2F0aW9u IE9BTSBwYXlsb2FkIG1heSBiZSBkaWZmZXJlbnQgZnJvbSBCSUVSLiBXb3VsZCB5b3UgYWdyZWUs IG9yIHN1Z2dlc3QgdG8gaGF2ZSBhbm90aGVyIGV4YW1wbGUgb2YgQkZEPw0KDQpSZWdhcmRzLCBH cmVnDQoNCk9uIE1vbiwgTWF5IDIzLCAyMDE2IGF0IDEyOjI2IFBNLCBBbm9vcCBHaGFud2FuaSA8 YW5vb3BAYWx1bW5pLmR1a2UuZWR1PG1haWx0bzphbm9vcEBhbHVtbmkuZHVrZS5lZHU+PiB3cm90 ZToNCkF1dGhvcnMsDQoNCkluIHNlY3Rpb24gNC4xLCB5b3UgaGF2ZSB0aGlzOg0KPj4+DQoNCiAg IE5leHQgUHJvdG9jb2wgRmllbGQgaW4gR1BFIGhlYWRlciBNVVNUIGJlIHNldCB0byBJUHY0IG9y IElQdjYuDQoNCi4uLg0KDQogICBUaGUgQkZEIHBhY2tldCBNVVNUIGJlIGNhcnJpZWQgaW5zaWRl IHRoZSBpbm5lciBNQUMgZnJhbWUgb2YgdGhlDQoNCiAgIFZ4TEFOIHBhY2tldC4gIFRoZSBpbm5l ciBNQUMgZnJhbWUgY2FycnlpbmcgdGhlIEJGRCBwYXlsb2FkIGhhcyB0aGUNCg0KICAgZm9sbG93 aW5nIGZvcm1hdDoNCj4+Pg0KDQpUaGVzZSB0d28gc3RhdGVtZW50cyBzZWVtIHRvIGNvbnRyYWRp Y3QgZWFjaCBvdGhlci4gIElmIHRoZSBHUEUgaGVhZGVyIGluZGljYXRlcyBJUHY0IG9yIElQdjYs IHRoZW4gaG93IGNhbiB0aGUgQkZEIHBhY2tldCBiZSBlbmNhcHN1bGF0ZWQgd2l0aGluIGEgTUFD IGZyYW1lPw0KDQpDYW4geW91IHBsZWFzZSBjbGFyaWZ5Pw0KDQpUaGFua3MsDQpBbm9vcA0KDQoN Ck9uIE1vbiwgTWF5IDIzLCAyMDE2IGF0IDg6MTUgQU0sIEJvY2NpLCBNYXR0aGV3IChOb2tpYSAt IEdCKSA8bWF0dGhldy5ib2NjaUBub2tpYS5jb208bWFpbHRvOm1hdHRoZXcuYm9jY2lAbm9raWEu Y29tPj4gd3JvdGU6DQpGb2xrcw0KDQpQbGVhc2UgY291bGQgeW91IGRpcmVjdCBhbnkgZGlzY3Vz c2lvbiBvbiB0aGlzIGRyYWZ0IHRvIHRoZSBOVk8zIHdvcmtpbmcNCmdyb3VwIGxpc3QuDQoNClJl Z2FyZHMNCg0KTWF0dGhldw0KDQpPbiAxOC8wNC8yMDE2LCAwNzo1NCwgIm52bzMgb24gYmVoYWxm IG9mIFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuDQoodmVuZ2dvdmkpIiA8bnZvMy1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiB2ZW5nZ292 aUBjaXNjby5jb208bWFpbHRvOnZlbmdnb3ZpQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQo+SGVsbG8g YWxsLA0KPiAgVGhlIGF1dGhvcnMgcmVxdWVzdCBjb21tZW50cyBvbiB0aGUgZHJhZnQgYmVsb3cu DQo+VGhhbmtzDQo+UHJhc2FkDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zz4gW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZz5dDQo+U2VudDogU2F0dXJkYXksIEFwcmlsIDE2LCAyMDE2IDExOjMzIEFNDQo+ VG86IE1BTExJSyBNVURJR09OREEgKG1tdWRpZ29uKSA8bW11ZGlnb25AY2lzY28uY29tPG1haWx0 bzptbXVkaWdvbkBjaXNjby5jb20+PjsgQmFzaWwgU2FqaQ0KPjxzYmFzaWxAanVuaXBlci5uZXQ8 bWFpbHRvOnNiYXNpbEBqdW5pcGVyLm5ldD4+OyBHcmVnIE1pcnNreSA8Z3JlZ29yeS5taXJza3lA ZXJpY3Nzb24uY29tPG1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+PjsgVmVuZ2Fk YQ0KPlByYXNhZCBHb3ZpbmRhbiAodmVuZ2dvdmkpIDx2ZW5nZ292aUBjaXNjby5jb208bWFpbHRv OnZlbmdnb3ZpQGNpc2NvLmNvbT4+OyBKdW5pcGVyIE5ldHdvcmtzDQo+PHNhbnRvc2hwa0BqdW5p cGVyLm5ldDxtYWlsdG86c2FudG9zaHBrQGp1bmlwZXIubmV0Pj47IFN1ZGFyc2FuIFBhcmFnaXJp IDxzcGFyYWdpcmlAanVuaXBlci5uZXQ8bWFpbHRvOnNwYXJhZ2lyaUBqdW5pcGVyLm5ldD4+Ow0K PlNhbnRvc2ggUGFsbGFnYXR0aSA8c2FudG9zaHBrQGp1bmlwZXIubmV0PG1haWx0bzpzYW50b3No cGtAanVuaXBlci5uZXQ+Pjsgc2FqaWJhc2lsQGdtYWlsLmNvbTxtYWlsdG86c2FqaWJhc2lsQGdt YWlsLmNvbT4NCj48c2Jhc2lsQGp1bmlwZXIubmV0PG1haWx0bzpzYmFzaWxAanVuaXBlci5uZXQ+ Pg0KPlN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3BhbGxhZ2F0 dGktYmZkLXZ4bGFuLTAzLnR4dA0KPg0KPg0KPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1z cGFsbGFnYXR0aS1iZmQtdnhsYW4tMDMudHh0DQo+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBWZW5nYWRhIFByYXNhZCBHb3ZpbmRhbiBhbmQgcG9zdGVkIHRvDQo+dGhlIElFVEYg cmVwb3NpdG9yeS4NCj4NCj5OYW1lOiAgICAgICAgICBkcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhs YW4NCj5SZXZpc2lvbjogICAgICAwMw0KPlRpdGxlOiAgICAgICAgIEJGRCBmb3IgVlhMQU4NCj5E b2N1bWVudCBkYXRlOiAyMDE2LTA0LTE1DQo+R3JvdXA6ICAgICAgICAgSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQo+UGFnZXM6ICAgICAgICAgOQ0KPlVSTDoNCj5odHRwczovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLTAzLnR4dA0KPlN0YXR1 czoNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zcGFsbGFnYXR0aS1i ZmQtdnhsYW4vDQo+SHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4tMDMNCj5EaWZmOg0KPmh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4tMDMNCj4NCj5BYnN0 cmFjdDoNCj4gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB1c2Ugb2YgQmlkaXJlY3Rpb25hbCBG b3J3YXJkaW5nIERldGVjdGlvbg0KPiAgIChCRkQpIHByb3RvY29sIGZvciBWWExBTiAuDQo+DQo+ DQo+DQo+DQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj5zdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj50b29scy5pZXRmLm9yZzxodHRwOi8v dG9vbHMuaWV0Zi5vcmc+Lg0KPg0KPlRoZSBJRVRGIFNlY3JldGFyaWF0DQo+DQo+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5udm8zIG1haWxpbmcgbGlz dA0KPm52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+DQo+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpudm8zIG1haWxpbmcgbGlzdA0KbnZvM0BpZXRmLm9yZzxt YWlsdG86bnZvM0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbnZvMw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpudm8zIG1haWxpbmcgbGlzdA0KbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMw0KDQoNCg== --_000_7347100B5761DC41A166AC17F22DF11221A81D6Feusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs MA0KCXttc28tbGlzdC1pZDoxODc5Nzc1NTk0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMDQw NzIxOTA4O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhpIEFub29wLCBMYXJyeSwgU2hhaHJhbSwgZXQuIGFsLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj50aGFuayB5b3UgZm9yIHRoZSBjb3JyZWN0aW9uLiBXZeKAmWxsIGFkZHJl c3MgaXQgaW4gdGhlIG5leHQgdXBkYXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBHcmVnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5Bbm9vcCBHaGFud2FuaTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSAyMywg MjAxNiAyOjM1IFBNPGJyPg0KPGI+VG86PC9iPiBHcmVnIE1pcnNreTxicj4NCjxiPkNjOjwvYj4g cnRnd2ctb29hbS1kdEBpZXRmLm9yZzsgcnRnLWJmZEBpZXRmLm9yZzsgbnZvM0BpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW252bzNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXNwYWxsYWdhdHRpLWJmZC12eGxhbi0wMy50eHQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBHcmVnLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBMYXJyeSBoYXMgY292ZXJlZCB0aGUgcG9pbnRz IEkgd2FzIHRyeWluZyB0byBicmluZyB1cC4uLmlmIHRoZXJlJ3MgYSBNQUMgaGVhZGVyIHByZXNl bnQsIHRoZW4gdGhlIFZYTEFOIEdQRSBuZXh0IGhlYWRlciBoYXMgdG8gaW5kaWNhdGUgJnF1b3Q7 RXRoZXJuZXQmcXVvdDsgcmF0aGVyIHRoYW4gJnF1b3Q7SVB2NCZxdW90OyBvciAmcXVvdDtJUHY2 JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Bbm9vcDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBNb24sIE1heSAyMywgMjAxNiBhdCAxMjo0NyBQTSwgR3JlZyBNaXJza3kg Jmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzO0JGRCBXRyBhbmQgUlRHV0cgT09BTSBEVDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQW5vb3AsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGFuayB5 b3UgZm9yIHlvdXIgcmV2aWV3IGFuZCB0aGUgcXVlc3Rpb24uIFRoZSBzY29wZSBvZiB0aGlzIGRy YWZ0IGlzIG9ubHkgZm9yIHRoZSBWWExBTi4gVGhlIE92ZXJsYXkgT0FNIERlc2luZyBUZWFtIGlz IHdvcmtpbmcgb24gdGhlIFJlcXVpcmVtZW50cywgR2FwIEFuYWx5c2lzIGFuZCwgaWYgdGhlcmUg d2lsbCBiZSByZXF1aXJlZCwgZW5oYW5jZW1lbnRzIGFuZC9vciBuZXcgT0FNIHByb3RvY29scyBm b3ImbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+QklFUiwN CiBOU0gsIFZYTEFOLUdQRSwgR0VORVZFLCBhbmQgR1VFLCBhcyBkZWZpbmVkIGluIGl0cyBjaGFy dGVyLiBXb3VsZCBhcHByZWNpYXRlIHlvdSByZXZpZXcgYW5kIGNvbW1lbnRzIG9mIHRoZSB0d28g ZG9jdW1lbnRzIHRoZSBPT0FNLURUIGFscmVhZHkgcHJlc2VudGVkIGluIEJBIG1lZXRpbmc6PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+T09BTSBSZXF1aXJlbWVudHM8L3NwYW4+ PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPk9BTSBm b3IgT3ZlcmxheSBOZXR3b3JrczogR2FwIGFuYWx5c2lzPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48 L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6YmxhY2siPkluIHRoZSBsYXR0ZXIgeW91J2xsIGZpbmQgdGhlIGV4YW1wbGUgdG8gZGVt b25zdHJhdGUgYXBwbGljYWJpbGl0eSBvZiBCRkQgQXN5bmMgbW9kZSBpbiBCSUVSIGRvbWFpbi4g QXMgd2UndmUgZGlzY3Vzc2VkLCBvdGhlciBCRkQgbWF5IGJlIGFwcGxpZWQgdG8gb3RoZXIgb3Zl cmxheSBuZXR3b3JrcyB0aGF0IEkndmUgbGlzdGVkIGFib3ZlDQogZXZlbiB0aG91Z2ggdGhlaXIg bWV0aG9kIG9mIGluZGljYXRpb24gT0FNIHBheWxvYWQgbWF5IGJlIGRpZmZlcmVudCBmcm9tIEJJ RVIuIFdvdWxkIHlvdSBhZ3JlZSwgb3Igc3VnZ2VzdCB0byBoYXZlIGFub3RoZXIgZXhhbXBsZSBv ZiBCRkQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+UmVn YXJkcywgR3JlZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1heSAyMywgMjAxNiBhdCAxMjoy NiBQTSwgQW5vb3AgR2hhbndhbmkgJmx0OzxhIGhyZWY9Im1haWx0bzphbm9vcEBhbHVtbmkuZHVr ZS5lZHUiIHRhcmdldD0iX2JsYW5rIj5hbm9vcEBhbHVtbmkuZHVrZS5lZHU8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BdXRob3JzLDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gc2VjdGlvbiA0 LjEsIHlvdSBoYXZlIHRoaXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgTmV4dCBQ cm90b2NvbCBGaWVsZCBpbiBHUEUgaGVhZGVyIE1VU1QgYmUgc2V0IHRvIElQdjQgb3IgSVB2Ni48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4u Li48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgVGhlIEJGRCBwYWNrZXQgTVVTVCBiZSBjYXJyaWVkIGluc2lkZSB0aGUg aW5uZXIgTUFDIGZyYW1lIG9mIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBWeExBTiBwYWNrZXQuJm5ic3A7IFRo ZSBpbm5lciBNQUMgZnJhbWUgY2FycnlpbmcgdGhlIEJGRCBwYXlsb2FkIGhhcyB0aGU8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgZm9sbG93aW5nIGZvcm1hdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVzZSB0d28gc3Rh dGVtZW50cyBzZWVtIHRvIGNvbnRyYWRpY3QgZWFjaCBvdGhlci4mbmJzcDsgSWYgdGhlIEdQRSBo ZWFkZXIgaW5kaWNhdGVzIElQdjQgb3IgSVB2NiwgdGhlbiBob3cgY2FuIHRoZSBCRkQgcGFja2V0 IGJlIGVuY2Fwc3VsYXRlZCB3aXRoaW4gYSBNQUMgZnJhbWU/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhbiB5b3UgcGxlYXNlIGNsYXJpZnk/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo YW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFub29wPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1heSAyMywgMjAxNiBhdCA4OjE1IEFNLCBCb2Nj aSwgTWF0dGhldyAoTm9raWEgLSBHQikgJmx0OzxhIGhyZWY9Im1haWx0bzptYXR0aGV3LmJvY2Np QG5va2lhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hdHRoZXcuYm9jY2lAbm9raWEuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb2xrczxicj4N Cjxicj4NClBsZWFzZSBjb3VsZCB5b3UgZGlyZWN0IGFueSBkaXNjdXNzaW9uIG9uIHRoaXMgZHJh ZnQgdG8gdGhlIE5WTzMgd29ya2luZzxicj4NCmdyb3VwIGxpc3QuPGJyPg0KPGJyPg0KUmVnYXJk czxicj4NCjxicj4NCk1hdHRoZXc8YnI+DQo8YnI+DQpPbiAxOC8wNC8yMDE2LCAwNzo1NCwgJnF1 b3Q7bnZvMyBvbiBiZWhhbGYgb2YgVmVuZ2FkYSBQcmFzYWQgR292aW5kYW48YnI+DQoodmVuZ2dv dmkpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+bnZvMy1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhy ZWY9Im1haWx0bzp2ZW5nZ292aUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj52ZW5nZ292aUBj aXNjby5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7SGVsbG8gYWxsLDxicj4NCiZn dDsmbmJzcDsgVGhlIGF1dGhvcnMgcmVxdWVzdCBjb21tZW50cyBvbiB0aGUgZHJhZnQgYmVsb3cu PGJyPg0KJmd0O1RoYW5rczxicj4NCiZndDtQcmFzYWQ8YnI+DQomZ3Q7PGJyPg0KJmd0Oy0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0O0Zyb206IDxhIGhyZWY9Im1haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT5dPGJyPg0KJmd0 O1NlbnQ6IFNhdHVyZGF5LCBBcHJpbCAxNiwgMjAxNiAxMTozMyBBTTxicj4NCiZndDtUbzogTUFM TElLIE1VRElHT05EQSAobW11ZGlnb24pICZsdDs8YSBocmVmPSJtYWlsdG86bW11ZGlnb25AY2lz Y28uY29tIiB0YXJnZXQ9Il9ibGFuayI+bW11ZGlnb25AY2lzY28uY29tPC9hPiZndDs7IEJhc2ls IFNhamk8YnI+DQomZ3Q7Jmx0OzxhIGhyZWY9Im1haWx0bzpzYmFzaWxAanVuaXBlci5uZXQiIHRh cmdldD0iX2JsYW5rIj5zYmFzaWxAanVuaXBlci5uZXQ8L2E+Jmd0OzsgR3JlZyBNaXJza3kgJmx0 OzxhIGhyZWY9Im1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2Js YW5rIj5ncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208L2E+Jmd0OzsgVmVuZ2FkYTxicj4NCiZn dDtQcmFzYWQgR292aW5kYW4gKHZlbmdnb3ZpKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlbmdnb3Zp QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlbmdnb3ZpQGNpc2NvLmNvbTwvYT4mZ3Q7OyBK dW5pcGVyIE5ldHdvcmtzPGJyPg0KJmd0OyZsdDs8YSBocmVmPSJtYWlsdG86c2FudG9zaHBrQGp1 bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+c2FudG9zaHBrQGp1bmlwZXIubmV0PC9hPiZndDs7 IFN1ZGFyc2FuIFBhcmFnaXJpICZsdDs8YSBocmVmPSJtYWlsdG86c3BhcmFnaXJpQGp1bmlwZXIu bmV0IiB0YXJnZXQ9Il9ibGFuayI+c3BhcmFnaXJpQGp1bmlwZXIubmV0PC9hPiZndDs7PGJyPg0K Jmd0O1NhbnRvc2ggUGFsbGFnYXR0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhbnRvc2hwa0BqdW5p cGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnNhbnRvc2hwa0BqdW5pcGVyLm5ldDwvYT4mZ3Q7Ow0K PGEgaHJlZj0ibWFpbHRvOnNhamliYXNpbEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWpp YmFzaWxAZ21haWwuY29tPC9hPjxicj4NCiZndDsmbHQ7PGEgaHJlZj0ibWFpbHRvOnNiYXNpbEBq dW5pcGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnNiYXNpbEBqdW5pcGVyLm5ldDwvYT4mZ3Q7PGJy Pg0KJmd0O1N1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3BhbGxh Z2F0dGktYmZkLXZ4bGFuLTAzLnR4dDxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0O0EgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4tMDMudHh0PGJyPg0K Jmd0O2hhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVmVuZ2FkYSBQcmFzYWQgR292 aW5kYW4gYW5kIHBvc3RlZCB0bzxicj4NCiZndDt0aGUgSUVURiByZXBvc2l0b3J5Ljxicj4NCiZn dDs8YnI+DQomZ3Q7TmFtZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRyYWZ0 LXNwYWxsYWdhdHRpLWJmZC12eGxhbjxicj4NCiZndDtSZXZpc2lvbjombmJzcDsgJm5ic3A7ICZu YnNwOyAwMzxicj4NCiZndDtUaXRsZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 QkZEIGZvciBWWExBTjxicj4NCiZndDtEb2N1bWVudCBkYXRlOiAyMDE2LTA0LTE1PGJyPg0KJmd0 O0dyb3VwOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJbmRpdmlkdWFsIFN1Ym1p c3Npb248YnI+DQomZ3Q7UGFnZXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzk8 YnI+DQomZ3Q7VVJMOjxicj4NCiZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLTAzLnR4dCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zcGFsbGFn YXR0aS1iZmQtdnhsYW4tMDMudHh0PC9hPjxicj4NCiZndDtTdGF0dXM6PGJyPg0KJmd0OzxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNwYWxsYWdhdHRpLWJm ZC12eGxhbi8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4vPC9hPjxicj4NCiZndDtIdG1saXplZDombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLTAzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNwYWxsYWdhdHRpLWJmZC12eGxhbi0wMzwvYT48 YnI+DQomZ3Q7RGlmZjo8YnI+DQomZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LXNwYWxsYWdhdHRpLWJmZC12eGxhbi0wMyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zcGFsbGFnYXR0aS1iZmQt dnhsYW4tMDM8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDtBYnN0cmFjdDo8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHVzZSBvZiBCaWRpcmVjdGlvbmFsIEZvcndh cmRpbmcgRGV0ZWN0aW9uPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsoQkZEKSBwcm90b2NvbCBmb3Ig VlhMQU4gLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDtQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZjxicj4NCiZndDtzdWJtaXNzaW9uIHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQ8YnI+DQomZ3Q7PGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dG9vbHMuaWV0Zi5v cmc8L2E+Ljxicj4NCiZndDs8YnI+DQomZ3Q7VGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQomZ3Q7 PGJyPg0KJmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KJmd0O252bzMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OzxhIGhyZWY9Im1haWx0bzpudm8z QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bnZvM0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zPC9hPjxi cj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KbnZvMyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bnZvM0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm52bzNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpudm8zIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpu dm8zQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bnZvM0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzM8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7347100B5761DC41A166AC17F22DF11221A81D6Feusaamb103erics_-- From nobody Mon May 23 16:11:43 2016 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 4821612DC03; Mon, 23 May 2016 16:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 zYzarLasGkDB; Mon, 23 May 2016 16:11:37 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 1D36612DC02; Mon, 23 May 2016 16:11:37 -0700 (PDT) Received: by mail-qg0-x236.google.com with SMTP id 90so68616qgz.1; Mon, 23 May 2016 16:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=20WuHoWLbBjLFYbQhoqUNS278zIq/vSfUn14Qj5QaJc=; b=sgRH9GeBRvHxqgiTEnPqwKdeNfGkJ9xwDkIkoWKQDR2eMmrWd+40Dx2wPYC45KyxBK olxaaADYuB8+n15BjTjI287QvJNClmbN4cbpee1koBHVewqpmBBktIVPCxNol/2n32zS OorSEspiOu5TLnSvZMb30f3XnAMUaPOtSVMQMvvYn5na6pP78Yekcro2CvKQ7SjNMBMQ d4uKq5qkU+exNOdCwLv9F+P+auYsIU6I6Zeh/3WDYLwaI8LQdACWkFZW9diBvyxOF0oO uJbCJ9h68Lkcvw+tsa5MQ1MKptuNMlrV8JE1PIlLdlwIXDMJ1+14vd9XBq1sPqav/pJB daww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=20WuHoWLbBjLFYbQhoqUNS278zIq/vSfUn14Qj5QaJc=; b=GYs+2DFl7ze5sjzBmLwQDOr6gQObfSRJuLC7RJXhPu0kUGdDZxdnspHJcj+9MDRc47 KxJ108CvcaoK1heRWOJTazZ5322L8ZphVNdB16LI0ZV5GCXTBbFUB8GnjxDeBtfKKthf xhswZSrNwDF/Wdy1QEBmsPEoLD8vuOA5U9rfe7tdq7OMg3WAk+Wfr7pb3JCb2tvoPLEX +LHnc5g+zQZTxJhQlQrERIBnEhwSRTskUD5PCr4mZS/l+98rfgKB9VDl+nNgqa8+RwO/ WPuC5e0dC1jzgk3G68mHwbo1YGIt7beTZWa8gJp68Hyc9AFKwWBtFeWz0Kx0DRA/MEHA xRDQ== X-Gm-Message-State: ALyK8tIocWn1AFBwaT+IgOODrgFa7VPl3Fezaysew2T8FlZIlWr7R0TKiL+a+7u8Cc8FviT/tO2kS0lHdLof0g== MIME-Version: 1.0 X-Received: by 10.140.205.18 with SMTP id a18mr708415qhb.6.1464045096137; Mon, 23 May 2016 16:11:36 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.55.135.199 with HTTP; Mon, 23 May 2016 16:11:36 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A81D6F@eusaamb103.ericsson.se> References: <20160416060248.17419.11591.idtracker@ietfa.amsl.com> <8f73ecae119843dcba447c54084c80f8@XCH-RCD-020.cisco.com> <7347100B5761DC41A166AC17F22DF11221A81D6F@eusaamb103.ericsson.se> Date: Mon, 23 May 2016 16:11:36 -0700 X-Google-Sender-Auth: b0gQF0s4QZksCPyOTOC-hy6wAPY Message-ID: Subject: Re: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt From: Anoop Ghanwani To: Gregory Mirsky Content-Type: multipart/alternative; boundary=94eb2c094902e3fddf05338a8f5b Archived-At: Cc: "rtg-bfd@ietf.org" , "nvo3@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 23:11:40 -0000 --94eb2c094902e3fddf05338a8f5b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Greg. Perhaps what you meant to say was that the Ethertype in the inner MAC header must be either IPv4 or IPv6. Anoop On Mon, May 23, 2016 at 2:46 PM, Gregory Mirsky wrote: > Hi Anoop, Larry, Shahram, et. al, > > thank you for the correction. We=E2=80=99ll address it in the next update= . > > > > Regards, > > Greg > > > > *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] *On Behalf Of *Anoop > Ghanwani > > *Sent:* Monday, May 23, 2016 2:35 PM > *To:* Greg Mirsky > *Cc:* rtgwg-ooam-dt@ietf.org; rtg-bfd@ietf.org; nvo3@ietf.org > *Subject:* Re: [nvo3] FW: New Version Notification for > draft-spallagatti-bfd-vxlan-03.txt > > > > Hi Greg, > > > > I think Larry has covered the points I was trying to bring up...if there'= s > a MAC header present, then the VXLAN GPE next header has to indicate > "Ethernet" rather than "IPv4" or "IPv6". > > > > Thanks, > > Anoop > > > > On Mon, May 23, 2016 at 12:47 PM, Greg Mirsky > wrote: > > +BFD WG and RTGWG OOAM DT > > > > Hi Anoop, > > thank you for your review and the question. The scope of this draft is > only for the VXLAN. The Overlay OAM Desing Team is working on the > Requirements, Gap Analysis and, if there will be required, enhancements > and/or new OAM protocols for BIER, NSH, VXLAN-GPE, GENEVE, and GUE, as > defined in its charter. Would appreciate you review and comments of the t= wo > documents the OOAM-DT already presented in BA meeting: > > - OOAM Requirements > - OAM for Overlay Networks: Gap analysis > > In the latter you'll find the example to demonstrate applicability of BFD > Async mode in BIER domain. As we've discussed, other BFD may be applied t= o > other overlay networks that I've listed above even though their method of > indication OAM payload may be different from BIER. Would you agree, or > suggest to have another example of BFD? > > > > Regards, Greg > > > > On Mon, May 23, 2016 at 12:26 PM, Anoop Ghanwani > wrote: > > Authors, > > > > In section 4.1, you have this: > > >>> > > Next Protocol Field in GPE header MUST be set to IPv4 or IPv6. > > ... > > The BFD packet MUST be carried inside the inner MAC frame of the > > VxLAN packet. The inner MAC frame carrying the BFD payload has the > > following format: > > >>> > > > > These two statements seem to contradict each other. If the GPE header > indicates IPv4 or IPv6, then how can the BFD packet be encapsulated withi= n > a MAC frame? > > > > Can you please clarify? > > > > Thanks, > > Anoop > > > > > > On Mon, May 23, 2016 at 8:15 AM, Bocci, Matthew (Nokia - GB) < > matthew.bocci@nokia.com> wrote: > > Folks > > Please could you direct any discussion on this draft to the NVO3 working > group list. > > Regards > > Matthew > > On 18/04/2016, 07:54, "nvo3 on behalf of Vengada Prasad Govindan > (venggovi)" wrote= : > > >Hello all, > > The authors request comments on the draft below. > >Thanks > >Prasad > > > >-----Original Message----- > >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >Sent: Saturday, April 16, 2016 11:33 AM > >To: MALLIK MUDIGONDA (mmudigon) ; Basil Saji > >; Greg Mirsky ; Vengada > >Prasad Govindan (venggovi) ; Juniper Networks > >; Sudarsan Paragiri ; > >Santosh Pallagatti ; sajibasil@gmail.com > > > >Subject: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt > > > > > >A new version of I-D, draft-spallagatti-bfd-vxlan-03.txt > >has been successfully submitted by Vengada Prasad Govindan and posted to > >the IETF repository. > > > >Name: draft-spallagatti-bfd-vxlan > >Revision: 03 > >Title: BFD for VXLAN > >Document date: 2016-04-15 > >Group: Individual Submission > >Pages: 9 > >URL: > >https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan-03.txt > >Status: > >https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ > >Htmlized: > https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-03 > >Diff: > >https://www.ietf.org/rfcdiff?url2=3Ddraft-spallagatti-bfd-vxlan-03 > > > >Abstract: > > This document describes use of Bidirectional Forwarding Detection > > (BFD) protocol for VXLAN . > > > > > > > > > > > > > >Please note that it may take a couple of minutes from the time of > >submission until the htmlized version and diff are available at > >tools.ietf.org. > > > >The IETF Secretariat > > > >_______________________________________________ > >nvo3 mailing list > >nvo3@ietf.org > >https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > --94eb2c094902e3fddf05338a8f5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Greg.

Perhaps what you meant to = say was that the Ethertype in the inner MAC header must be either IPv4 or I= Pv6.

Anoop
<= br>
On Mon, May 23, 2016 at 2:46 PM, Gregory Mirs= ky <gregory.mirsky@ericsson.com> wrote:

Hi Anoop, Larry, Shahram,= et. al,

thank you for the correct= ion. We=E2=80=99ll address it in the next update.

=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 Regards,=

=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=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 Greg

=C2=A0

From: Rtg-bfd = [mailto:rtg-b= fd-bounces@ietf.org] On Behalf Of Anoop Ghanwani


Sent: Monday, May 23, 2016 2:35 PM
To: Greg Mirsky
Cc: rtgw= g-ooam-dt@ietf.org; rtg-bfd@ietf.org; nvo3@ietf.org
Subject: Re: [nvo3] FW: New Version Notification for draft-spallagat= ti-bfd-vxlan-03.txt

=C2=A0

Hi Greg,

=C2=A0

I think Larry has covered the points I was trying to= bring up...if there's a MAC header present, then the VXLAN GPE next he= ader has to indicate "Ethernet" rather than "IPv4" or &= quot;IPv6".

=C2=A0

Thanks,

Anoop

=C2=A0

On Mon, May 23, 2016 at 12:47 PM, Greg Mirsky <gregimirsky@gmail.= com> wrote:

+BFD WG and RTGWG OOAM DT

=C2=A0

Hi Anoop,

thank you for your review and the question. The scop= e of this draft is only for the VXLAN. The Overlay OAM Desing Team is worki= ng on the Requirements, Gap Analysis and, if there will be required, enhanc= ements and/or new OAM protocols for=C2=A0BIER, NSH, VXLAN-GPE, GENEVE, and GUE, as defined in its charter. Would apprecia= te you review and comments of the two documents the OOAM-DT already present= ed in BA meeting:

  • OOAM Requirements
  • OAM for Overlay Networks: Gap = analysis

In the = latter you'll find the example to demonstrate applicability of BFD Asyn= c mode in BIER domain. As we've discussed, other BFD may be applied to = other overlay networks that I've listed above even though their method of indication OAM payload may be different from B= IER. Would you agree, or suggest to have another example of BFD?<= /u>

=C2=A0

Regards= , Greg

=C2=A0

On Mon, May 23, 2016 at 12:26 PM, Anoop Ghanwani <= ;anoop@alumni.du= ke.edu> wrote:

Authors,

=C2=A0

In section 4.1, you have this:

>>>=C2=A0

=C2=A0=C2=A0 Next Protocol Field in GPE he=
ader MUST be set to IPv4 or IPv6.
...
=C2=A0=C2=A0 The BFD packet MUST be carrie=
d inside the inner MAC frame of the
=C2=A0=C2=A0 VxLAN packet.=C2=A0 The inner=
 MAC frame carrying the BFD payload has the
=C2=A0=C2=A0 following format:

>>>=C2=A0

=C2=A0

These two statements seem to contradict each other.= =C2=A0 If the GPE header indicates IPv4 or IPv6, then how can the BFD packe= t be encapsulated within a MAC frame?

=C2=A0

Can you please clarify?

=C2=A0

Thanks,

Anoop

=C2=A0

=C2=A0

On Mon, May 23, 2016 at 8:15 AM, Bocci, Matthew (Nok= ia - GB) <m= atthew.bocci@nokia.com> wrote:

Folks

Please could you direct any discussion on this draft to the NVO3 working group list.

Regards

Matthew

On 18/04/2016, 07:54, "nvo3 on behalf of Vengada Prasad Govindan
(venggovi)" <nvo3-bounces@ietf.org on behalf of venggovi@cisco.com<= /a>> wrote:

>Hello all,
>=C2=A0 The authors request comments on the draft below.
>Thanks
>Prasad
>
>-----Original Message-----
>From: int= ernet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>Sent: Saturday, April 16, 2016 11:33 AM
>To: MALLIK MUDIGONDA (mmudigon) <mmudigon@cisco.com>; Basil Saji
><sbasil@juni= per.net>; Greg Mirsky <gregory.mirsky@ericsson.com>; Vengada
>Prasad Govindan (venggovi) <venggovi@cisco.com>; Juniper Networks
><santoshp= k@juniper.net>; Sudarsan Paragiri <sparagiri@juniper.net>;
>Santosh Pallagatti <santoshpk@juniper.net>; sajibasil@gmail.co= m
><sbasil@juni= per.net>
>Subject: New Version Notification for draft-spallagatti-bfd-vxlan-03.tx= t
>
>
>A new version of I-D, draft-spallagatti-bfd-vxlan-03.txt
>has been successfully submitted by Vengada Prasad Govindan and posted t= o
>the IETF repository.
>
>Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-spallagatti-bfd-vxlan
>Revision:=C2=A0 =C2=A0 =C2=A0 03
>Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD for VXLAN
>Document date: 2016-04-15
>Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
>Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A09
>URL:
>https://www.ietf.org/internet-drafts/draft-s= pallagatti-bfd-vxlan-03.txt
>Status:
>https://datatracker.ietf.org/doc/draft-spallagatti-bfd= -vxlan/
>Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.or= g/html/draft-spallagatti-bfd-vxlan-03
>Diff:
>https://www.ietf.org/rfcdiff?url2=3Ddraft-spallag= atti-bfd-vxlan-03
>
>Abstract:
>=C2=A0 =C2=A0This document describes use of Bidirectional Forwarding De= tection
>=C2=A0 =C2=A0(BFD) protocol for VXLAN .
>
>
>
>
>
>
>Please note that it may take a couple of minutes from the time of
>submission until the htmlized version and diff are available at
>tools.ietf.org.=
>
>The IETF Secretariat
>
>_______________________________________________
>nvo3 mailing list
>nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

=C2=A0


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

=C2=A0

=C2=A0


--94eb2c094902e3fddf05338a8f5b-- From nobody Mon May 23 16:19:54 2016 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 7A18212D500; Mon, 23 May 2016 16:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 wYjuQiHuTBrn; Mon, 23 May 2016 16:19:46 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B615712B076; Mon, 23 May 2016 16:19:45 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-22-5743878fe8e0 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 53.9A.09012.F8783475; Tue, 24 May 2016 00:43:28 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0294.000; Mon, 23 May 2016 19:19:44 -0400 From: Gregory Mirsky To: Anoop Ghanwani Subject: RE: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt Thread-Topic: [nvo3] FW: New Version Notification for draft-spallagatti-bfd-vxlan-03.txt Thread-Index: AQHRl6WcnVPWQh0sjkaryhtWVkeuZJ+PkgEAgDeNkoCAAAkMt4AAYS6A//+/Y0CAAFt7AP//vqXg Date: Mon, 23 May 2016 23:19:43 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A81EFD@eusaamb103.ericsson.se> References: <20160416060248.17419.11591.idtracker@ietfa.amsl.com> <8f73ecae119843dcba447c54084c80f8@XCH-RCD-020.cisco.com> <7347100B5761DC41A166AC17F22DF11221A81D6F@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A81EFDeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyuXRPiO6Edudwg//LuSz2HnezeDpf0uLz n22MDsweW06meyxZ8pMpgCmKyyYlNSezLLVI3y6BK+Pa/HmMBbPWMFXcnWPUwLhmCVMXIyeH hICJxIZ3jxkhbDGJC/fWs4HYQgJHGSUuHa/pYuQCspczSrSt6mcHSbAJGEm82NgDZosIaElc WLQPbBCzgJfE5mXrwJqFBSIlJp05wApREyWx4PtsZhh7x+LvQDYHB4uAqsTJ41IgYV4BX4lf e6axQOxqZ5F4tGsPC0gNp0CgxKHXdiA1jEC3fT+1BmqVuMStJ/Oh7heQWLLnPDOELSrx8vE/ VghbSWLS0nOsIGOYBfIltr2phVglKHFy5hOWCYyis5BMmoVQNQtJFURYU2L9Ln2IakWJKd0P 2SFsDYnWOXPZkcUXMLKvYuQoLS7IyU03MtjECIypYxJsujsY70/3PMQowMGoxMObUOscLsSa WFZcmXuIUYKDWUmEl7EfKMSbklhZlVqUH19UmpNafIhRmoNFSZxX7JFiuJBAemJJanZqakFq EUyWiYNTqoFxqcoPAblZd4zizJRPTFm8JtMzbueT69MuOK7I+xnx6VCZ5POFX79zH6vusb+y 4vPpvrCFm1purhPlCH33SPWAqEAvx9xizoaQziqul9MKVjI8ezRtWt7B1849mqpGZV6BQXFb lwXF77m3ZsFp7ZiQTS36032uXz3XXp375PJhVUvzM0//mzMVK7EUZyQaajEXFScCAEqDb8il AgAA Archived-At: Cc: "rtg-bfd@ietf.org" , "nvo3@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 23:19:48 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A81EFDeusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5vb3AsDQp0aGFuayB5b3UgZm9yIHRoZSBzdWdnZXN0aW9uLCBpdCBkb2VzIG1ha2UgbG90 cyBvZiBzZW5zZS4gRnJhbmtseSwgbmVlZCB0byByZWZyZXNoIG15IG1lbW9yeSBvbiB0aGlzIGRy YWZ0Lg0KV291bGQgYXBwcmVjaWF0ZSB5b3VyIHJldmlldyBhbmQgY29tbWVudHMgb24gdGhlIHdv cmsgYnkgT09BTS1EVC4NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogZ2hhbndhbmlAZ21haWwuY29tIFttYWls dG86Z2hhbndhbmlAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgQW5vb3AgR2hhbndhbmkNClNlbnQ6 IE1vbmRheSwgTWF5IDIzLCAyMDE2IDQ6MTIgUE0NClRvOiBHcmVnb3J5IE1pcnNreQ0KQ2M6IHJ0 Zy1iZmRAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbnZvM10gRlc6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLTAz LnR4dA0KDQpUaGFua3MgR3JlZy4NCg0KUGVyaGFwcyB3aGF0IHlvdSBtZWFudCB0byBzYXkgd2Fz IHRoYXQgdGhlIEV0aGVydHlwZSBpbiB0aGUgaW5uZXIgTUFDIGhlYWRlciBtdXN0IGJlIGVpdGhl ciBJUHY0IG9yIElQdjYuDQoNCkFub29wDQoNCk9uIE1vbiwgTWF5IDIzLCAyMDE2IGF0IDI6NDYg UE0sIEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208bWFpbHRvOmdy ZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGkgQW5vb3AsIExhcnJ5LCBTaGFo cmFtLCBldC4gYWwsDQp0aGFuayB5b3UgZm9yIHRoZSBjb3JyZWN0aW9uLiBXZeKAmWxsIGFkZHJl c3MgaXQgaW4gdGhlIG5leHQgdXBkYXRlLg0KDQogICAgICAgICAgICAgICAgUmVnYXJkcywNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZw0KDQpGcm9tOiBSdGctYmZkIFttYWls dG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5v cmc+XSBPbiBCZWhhbGYgT2YgQW5vb3AgR2hhbndhbmkNCg0KU2VudDogTW9uZGF5LCBNYXkgMjMs IDIwMTYgMjozNSBQTQ0KVG86IEdyZWcgTWlyc2t5DQpDYzogcnRnd2ctb29hbS1kdEBpZXRmLm9y ZzxtYWlsdG86cnRnd2ctb29hbS1kdEBpZXRmLm9yZz47IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRv OnJ0Zy1iZmRAaWV0Zi5vcmc+OyBudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtudm8zXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4tMDMudHh0DQoNCkhpIEdyZWcsDQoNCkkgdGhpbmsgTGFy cnkgaGFzIGNvdmVyZWQgdGhlIHBvaW50cyBJIHdhcyB0cnlpbmcgdG8gYnJpbmcgdXAuLi5pZiB0 aGVyZSdzIGEgTUFDIGhlYWRlciBwcmVzZW50LCB0aGVuIHRoZSBWWExBTiBHUEUgbmV4dCBoZWFk ZXIgaGFzIHRvIGluZGljYXRlICJFdGhlcm5ldCIgcmF0aGVyIHRoYW4gIklQdjQiIG9yICJJUHY2 Ii4NCg0KVGhhbmtzLA0KQW5vb3ANCg0KT24gTW9uLCBNYXkgMjMsIDIwMTYgYXQgMTI6NDcgUE0s IEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb208bWFpbHRvOmdyZWdpbWlyc2t5QGdt YWlsLmNvbT4+IHdyb3RlOg0KK0JGRCBXRyBhbmQgUlRHV0cgT09BTSBEVA0KDQpIaSBBbm9vcCwN CnRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcgYW5kIHRoZSBxdWVzdGlvbi4gVGhlIHNjb3BlIG9m IHRoaXMgZHJhZnQgaXMgb25seSBmb3IgdGhlIFZYTEFOLiBUaGUgT3ZlcmxheSBPQU0gRGVzaW5n IFRlYW0gaXMgd29ya2luZyBvbiB0aGUgUmVxdWlyZW1lbnRzLCBHYXAgQW5hbHlzaXMgYW5kLCBp ZiB0aGVyZSB3aWxsIGJlIHJlcXVpcmVkLCBlbmhhbmNlbWVudHMgYW5kL29yIG5ldyBPQU0gcHJv dG9jb2xzIGZvciBCSUVSLCBOU0gsIFZYTEFOLUdQRSwgR0VORVZFLCBhbmQgR1VFLCBhcyBkZWZp bmVkIGluIGl0cyBjaGFydGVyLiBXb3VsZCBhcHByZWNpYXRlIHlvdSByZXZpZXcgYW5kIGNvbW1l bnRzIG9mIHRoZSB0d28gZG9jdW1lbnRzIHRoZSBPT0FNLURUIGFscmVhZHkgcHJlc2VudGVkIGlu IEJBIG1lZXRpbmc6DQoNCiAgKiAgIE9PQU0gUmVxdWlyZW1lbnRzDQogICogICBPQU0gZm9yIE92 ZXJsYXkgTmV0d29ya3M6IEdhcCBhbmFseXNpcw0KSW4gdGhlIGxhdHRlciB5b3UnbGwgZmluZCB0 aGUgZXhhbXBsZSB0byBkZW1vbnN0cmF0ZSBhcHBsaWNhYmlsaXR5IG9mIEJGRCBBc3luYyBtb2Rl IGluIEJJRVIgZG9tYWluLiBBcyB3ZSd2ZSBkaXNjdXNzZWQsIG90aGVyIEJGRCBtYXkgYmUgYXBw bGllZCB0byBvdGhlciBvdmVybGF5IG5ldHdvcmtzIHRoYXQgSSd2ZSBsaXN0ZWQgYWJvdmUgZXZl biB0aG91Z2ggdGhlaXIgbWV0aG9kIG9mIGluZGljYXRpb24gT0FNIHBheWxvYWQgbWF5IGJlIGRp ZmZlcmVudCBmcm9tIEJJRVIuIFdvdWxkIHlvdSBhZ3JlZSwgb3Igc3VnZ2VzdCB0byBoYXZlIGFu b3RoZXIgZXhhbXBsZSBvZiBCRkQ/DQoNClJlZ2FyZHMsIEdyZWcNCg0KT24gTW9uLCBNYXkgMjMs IDIwMTYgYXQgMTI6MjYgUE0sIEFub29wIEdoYW53YW5pIDxhbm9vcEBhbHVtbmkuZHVrZS5lZHU8 bWFpbHRvOmFub29wQGFsdW1uaS5kdWtlLmVkdT4+IHdyb3RlOg0KQXV0aG9ycywNCg0KSW4gc2Vj dGlvbiA0LjEsIHlvdSBoYXZlIHRoaXM6DQo+Pj4NCg0KICAgTmV4dCBQcm90b2NvbCBGaWVsZCBp biBHUEUgaGVhZGVyIE1VU1QgYmUgc2V0IHRvIElQdjQgb3IgSVB2Ni4NCg0KLi4uDQoNCiAgIFRo ZSBCRkQgcGFja2V0IE1VU1QgYmUgY2FycmllZCBpbnNpZGUgdGhlIGlubmVyIE1BQyBmcmFtZSBv ZiB0aGUNCg0KICAgVnhMQU4gcGFja2V0LiAgVGhlIGlubmVyIE1BQyBmcmFtZSBjYXJyeWluZyB0 aGUgQkZEIHBheWxvYWQgaGFzIHRoZQ0KDQogICBmb2xsb3dpbmcgZm9ybWF0Og0KPj4+DQoNClRo ZXNlIHR3byBzdGF0ZW1lbnRzIHNlZW0gdG8gY29udHJhZGljdCBlYWNoIG90aGVyLiAgSWYgdGhl IEdQRSBoZWFkZXIgaW5kaWNhdGVzIElQdjQgb3IgSVB2NiwgdGhlbiBob3cgY2FuIHRoZSBCRkQg cGFja2V0IGJlIGVuY2Fwc3VsYXRlZCB3aXRoaW4gYSBNQUMgZnJhbWU/DQoNCkNhbiB5b3UgcGxl YXNlIGNsYXJpZnk/DQoNClRoYW5rcywNCkFub29wDQoNCg0KT24gTW9uLCBNYXkgMjMsIDIwMTYg YXQgODoxNSBBTSwgQm9jY2ksIE1hdHRoZXcgKE5va2lhIC0gR0IpIDxtYXR0aGV3LmJvY2NpQG5v a2lhLmNvbTxtYWlsdG86bWF0dGhldy5ib2NjaUBub2tpYS5jb20+PiB3cm90ZToNCkZvbGtzDQoN ClBsZWFzZSBjb3VsZCB5b3UgZGlyZWN0IGFueSBkaXNjdXNzaW9uIG9uIHRoaXMgZHJhZnQgdG8g dGhlIE5WTzMgd29ya2luZw0KZ3JvdXAgbGlzdC4NCg0KUmVnYXJkcw0KDQpNYXR0aGV3DQoNCk9u IDE4LzA0LzIwMTYsIDA3OjU0LCAibnZvMyBvbiBiZWhhbGYgb2YgVmVuZ2FkYSBQcmFzYWQgR292 aW5kYW4NCih2ZW5nZ292aSkiIDxudm8zLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm52bzMtYm91 bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIHZlbmdnb3ZpQGNpc2NvLmNvbTxtYWlsdG86dmVu Z2dvdmlAY2lzY28uY29tPj4gd3JvdGU6DQoNCj5IZWxsbyBhbGwsDQo+ICBUaGUgYXV0aG9ycyBy ZXF1ZXN0IGNvbW1lbnRzIG9uIHRoZSBkcmFmdCBiZWxvdy4NCj5UaGFua3MNCj5QcmFzYWQNCj4N Cj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiBbbWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPl0NCj5TZW50OiBT YXR1cmRheSwgQXByaWwgMTYsIDIwMTYgMTE6MzMgQU0NCj5UbzogTUFMTElLIE1VRElHT05EQSAo bW11ZGlnb24pIDxtbXVkaWdvbkBjaXNjby5jb208bWFpbHRvOm1tdWRpZ29uQGNpc2NvLmNvbT4+ OyBCYXNpbCBTYWppDQo+PHNiYXNpbEBqdW5pcGVyLm5ldDxtYWlsdG86c2Jhc2lsQGp1bmlwZXIu bmV0Pj47IEdyZWcgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208bWFpbHRvOmdy ZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+OyBWZW5nYWRhDQo+UHJhc2FkIEdvdmluZGFuICh2 ZW5nZ292aSkgPHZlbmdnb3ZpQGNpc2NvLmNvbTxtYWlsdG86dmVuZ2dvdmlAY2lzY28uY29tPj47 IEp1bmlwZXIgTmV0d29ya3MNCj48c2FudG9zaHBrQGp1bmlwZXIubmV0PG1haWx0bzpzYW50b3No cGtAanVuaXBlci5uZXQ+PjsgU3VkYXJzYW4gUGFyYWdpcmkgPHNwYXJhZ2lyaUBqdW5pcGVyLm5l dDxtYWlsdG86c3BhcmFnaXJpQGp1bmlwZXIubmV0Pj47DQo+U2FudG9zaCBQYWxsYWdhdHRpIDxz YW50b3NocGtAanVuaXBlci5uZXQ8bWFpbHRvOnNhbnRvc2hwa0BqdW5pcGVyLm5ldD4+OyBzYWpp YmFzaWxAZ21haWwuY29tPG1haWx0bzpzYWppYmFzaWxAZ21haWwuY29tPg0KPjxzYmFzaWxAanVu aXBlci5uZXQ8bWFpbHRvOnNiYXNpbEBqdW5pcGVyLm5ldD4+DQo+U3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4tMDMudHh0DQo+ DQo+DQo+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXNwYWxsYWdhdHRpLWJmZC12eGxhbi0w My50eHQNCj5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFZlbmdhZGEgUHJhc2Fk IEdvdmluZGFuIGFuZCBwb3N0ZWQgdG8NCj50aGUgSUVURiByZXBvc2l0b3J5Lg0KPg0KPk5hbWU6 ICAgICAgICAgIGRyYWZ0LXNwYWxsYWdhdHRpLWJmZC12eGxhbg0KPlJldmlzaW9uOiAgICAgIDAz DQo+VGl0bGU6ICAgICAgICAgQkZEIGZvciBWWExBTg0KPkRvY3VtZW50IGRhdGU6IDIwMTYtMDQt MTUNCj5Hcm91cDogICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj5QYWdlczogICAgICAg ICA5DQo+VVJMOg0KPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1z cGFsbGFnYXR0aS1iZmQtdnhsYW4tMDMudHh0DQo+U3RhdHVzOg0KPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNwYWxsYWdhdHRpLWJmZC12eGxhbi8NCj5IdG1saXplZDog ICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNwYWxsYWdhdHRpLWJmZC12 eGxhbi0wMw0KPkRpZmY6DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LXNwYWxsYWdhdHRpLWJmZC12eGxhbi0wMw0KPg0KPkFic3RyYWN0Og0KPiAgIFRoaXMgZG9jdW1l bnQgZGVzY3JpYmVzIHVzZSBvZiBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uDQo+ ICAgKEJGRCkgcHJvdG9jb2wgZm9yIFZYTEFOIC4NCj4NCj4NCj4NCj4NCj4NCj4NCj5QbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv Zg0KPnN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdA0KPnRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQo+DQo+ VGhlIElFVEYgU2VjcmV0YXJpYXQNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPm52bzMgbWFpbGluZyBsaXN0DQo+bnZvM0BpZXRmLm9yZzxtYWls dG86bnZvM0BpZXRmLm9yZz4NCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L252bzMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cm52bzMgbWFpbGluZyBsaXN0DQpudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm52bzMgbWFpbGluZyBsaXN0 DQpudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQoNCg0KDQo= --_000_7347100B5761DC41A166AC17F22DF11221A81EFDeusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJh bGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8N CkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE0MzM3NDc1NTg7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOi0yMDU4OTk0MzM2O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDou NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSBBbm9vcCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dGhhbmsgeW91IGZv ciB0aGUgc3VnZ2VzdGlvbiwgaXQgZG9lcyBtYWtlIGxvdHMgb2Ygc2Vuc2UuIEZyYW5rbHksIG5l ZWQgdG8gcmVmcmVzaCBteSBtZW1vcnkgb24gdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+V291bGQgYXBwcmVjaWF0ZSB5b3VyIHJldmlldyBhbmQgY29tbWVudHMgb24g dGhlIHdvcmsgYnkgT09BTS1EVC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgR3JlZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gZ2hh bndhbmlAZ21haWwuY29tIFttYWlsdG86Z2hhbndhbmlAZ21haWwuY29tXQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5Bbm9vcCBHaGFud2FuaTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSAyMywg MjAxNiA0OjEyIFBNPGJyPg0KPGI+VG86PC9iPiBHcmVnb3J5IE1pcnNreTxicj4NCjxiPkNjOjwv Yj4gcnRnLWJmZEBpZXRmLm9yZzsgbnZvM0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW252bzNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNwYWxsYWdh dHRpLWJmZC12eGxhbi0wMy50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFua3MgR3JlZy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlBlcmhhcHMgd2hhdCB5b3UgbWVhbnQgdG8gc2F5IHdhcyB0aGF0IHRoZSBFdGhlcnR5cGUg aW4gdGhlIGlubmVyIE1BQyBoZWFkZXIgbXVzdCBiZSBlaXRoZXIgSVB2NCBvciBJUHY2LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bbm9vcDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBN b24sIE1heSAyMywgMjAxNiBhdCAyOjQ2IFBNLCBHcmVnb3J5IE1pcnNreSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdyZWdv cnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5IaSBBbm9vcCwgTGFycnksIFNoYWhyYW0sIGV0LiBhbCw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj50aGFuayB5b3UgZm9yIHRoZSBjb3JyZWN0aW9u LiBXZeKAmWxsIGFkZHJlc3MgaXQgaW4gdGhlIG5leHQgdXBkYXRlLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUnRnLWJmZCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGctYmZkLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Bbm9vcCBHaGFud2FuaTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWF5IDIzLCAyMDE2IDI6MzUgUE08YnI+DQo8Yj5Ubzo8 L2I+IEdyZWcgTWlyc2t5PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86cnRnd2ctb29h bS1kdEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Z3dnLW9vYW0tZHRAaWV0Zi5vcmc8L2E+ Ow0KPGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGct YmZkQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm52bzNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj4NCm52bzNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbnZv M10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3BhbGxhZ2F0dGktYmZk LXZ4bGFuLTAzLnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIEdyZWcsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayBMYXJyeSBoYXMgY292ZXJlZCB0aGUgcG9p bnRzIEkgd2FzIHRyeWluZyB0byBicmluZyB1cC4uLmlmIHRoZXJlJ3MgYSBNQUMgaGVhZGVyIHBy ZXNlbnQsIHRoZW4gdGhlIFZYTEFOIEdQRSBuZXh0IGhlYWRlciBoYXMgdG8gaW5kaWNhdGUgJnF1 b3Q7RXRoZXJuZXQmcXVvdDsgcmF0aGVyIHRoYW4gJnF1b3Q7SVB2NCZxdW90OyBvcg0KICZxdW90 O0lQdjYmcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkFub29wPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBNb24sIE1heSAyMywgMjAxNiBhdCAxMjo0NyBQ TSwgR3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiYjNDM7QkZEIFdHIGFu ZCBSVEdXRyBPT0FNIERUPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SGkgQW5vb3AsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPnRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcgYW5kIHRoZSBxdWVzdGlv bi4gVGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQgaXMgb25seSBmb3IgdGhlIFZYTEFOLiBUaGUgT3Zl cmxheSBPQU0gRGVzaW5nIFRlYW0gaXMgd29ya2luZyBvbiB0aGUgUmVxdWlyZW1lbnRzLCBHYXAg QW5hbHlzaXMgYW5kLCBpZiB0aGVyZQ0KIHdpbGwgYmUgcmVxdWlyZWQsIGVuaGFuY2VtZW50cyBh bmQvb3IgbmV3IE9BTSBwcm90b2NvbHMgZm9yJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6YmxhY2siPkJJRVIsIE5TSCwgVlhMQU4tR1BFLCBHRU5FVkUsIGFuZCBHVUUs IGFzIGRlZmluZWQgaW4gaXRzIGNoYXJ0ZXIuIFdvdWxkIGFwcHJlY2lhdGUgeW91IHJldmlldyBh bmQgY29tbWVudHMgb2YgdGhlIHR3byBkb2N1bWVudHMgdGhlIE9PQU0tRFQgYWxyZWFkeSBwcmVz ZW50ZWQNCiBpbiBCQSBtZWV0aW5nOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2si Pk9PQU0gUmVxdWlyZW1lbnRzPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOmJsYWNrIj5PQU0gZm9yIE92ZXJsYXkgTmV0d29ya3M6IEdhcCBhbmFseXNp czwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPkluIHRoZSBsYXR0ZXIgeW91 J2xsIGZpbmQgdGhlIGV4YW1wbGUgdG8gZGVtb25zdHJhdGUgYXBwbGljYWJpbGl0eSBvZiBCRkQg QXN5bmMgbW9kZSBpbiBCSUVSIGRvbWFpbi4gQXMgd2UndmUgZGlzY3Vzc2VkLCBvdGhlciBCRkQg bWF5DQogYmUgYXBwbGllZCB0byBvdGhlciBvdmVybGF5IG5ldHdvcmtzIHRoYXQgSSd2ZSBsaXN0 ZWQgYWJvdmUgZXZlbiB0aG91Z2ggdGhlaXIgbWV0aG9kIG9mIGluZGljYXRpb24gT0FNIHBheWxv YWQgbWF5IGJlIGRpZmZlcmVudCBmcm9tIEJJRVIuIFdvdWxkIHlvdSBhZ3JlZSwgb3Igc3VnZ2Vz dCB0byBoYXZlIGFub3RoZXIgZXhhbXBsZSBvZiBCRkQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlJlZ2FyZHMsIEdyZWc8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9uIE1vbiwgTWF5IDIzLCAyMDE2IGF0IDEyOjI2IFBNLCBBbm9vcCBHaGFud2FuaSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmFub29wQGFsdW1uaS5kdWtlLmVkdSIgdGFyZ2V0PSJfYmxhbmsi PmFub29wQGFsdW1uaS5kdWtlLmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXV0aG9ycyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiBzZWN0aW9uIDQuMSwgeW91IGhhdmUgdGhp czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jmd0OyZndDsmZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IE5leHQgUHJvdG9jb2wgRmllbGQg aW4gR1BFIGhlYWRlciBNVVNUIGJlIHNldCB0byBJUHY0IG9yIElQdjYuPC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Li4uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IFRoZSBCRkQgcGFja2V0IE1VU1QgYmUgY2FycmllZCBpbnNpZGUgdGhlIGlubmVyIE1BQyBmcmFt ZSBvZiB0aGU8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgVnhMQU4gcGFja2V0LiZuYnNwOyBUaGUgaW5uZXIgTUFDIGZy YW1lIGNhcnJ5aW5nIHRoZSBCRkQgcGF5bG9hZCBoYXMgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGZvbGxvd2lu ZyBmb3JtYXQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZndDsmZ3Q7Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlc2UgdHdvIHN0YXRlbWVudHMg c2VlbSB0byBjb250cmFkaWN0IGVhY2ggb3RoZXIuJm5ic3A7IElmIHRoZSBHUEUgaGVhZGVyIGlu ZGljYXRlcyBJUHY0IG9yIElQdjYsIHRoZW4gaG93IGNhbiB0aGUgQkZEIHBhY2tldCBiZSBlbmNh cHN1bGF0ZWQgd2l0aGluIGEgTUFDIGZyYW1lPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2FuIHlvdSBwbGVhc2UgY2xhcmlmeT88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRo YW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+QW5vb3A8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgTWF5IDIzLCAyMDE2IGF0IDg6MTUg QU0sIEJvY2NpLCBNYXR0aGV3IChOb2tpYSAtIEdCKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hdHRo ZXcuYm9jY2lAbm9raWEuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWF0dGhldy5ib2NjaUBub2tpYS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Rm9sa3M8YnI+DQo8YnI+DQpQbGVhc2UgY291bGQgeW91IGRpcmVjdCBhbnkgZGlzY3Vzc2lvbiBv biB0aGlzIGRyYWZ0IHRvIHRoZSBOVk8zIHdvcmtpbmc8YnI+DQpncm91cCBsaXN0Ljxicj4NCjxi cj4NClJlZ2FyZHM8YnI+DQo8YnI+DQpNYXR0aGV3PGJyPg0KPGJyPg0KT24gMTgvMDQvMjAxNiwg MDc6NTQsICZxdW90O252bzMgb24gYmVoYWxmIG9mIFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuPGJy Pg0KKHZlbmdnb3ZpKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm52bzMtYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm52bzMtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxm IG9mDQo8YSBocmVmPSJtYWlsdG86dmVuZ2dvdmlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ dmVuZ2dvdmlAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0O0hlbGxvIGFs bCw8YnI+DQomZ3Q7Jm5ic3A7IFRoZSBhdXRob3JzIHJlcXVlc3QgY29tbWVudHMgb24gdGhlIGRy YWZ0IGJlbG93Ljxicj4NCiZndDtUaGFua3M8YnI+DQomZ3Q7UHJhc2FkPGJyPg0KJmd0Ozxicj4N CiZndDstLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDtGcm9tOiA8YSBocmVmPSJt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+ XTxicj4NCiZndDtTZW50OiBTYXR1cmRheSwgQXByaWwgMTYsIDIwMTYgMTE6MzMgQU08YnI+DQom Z3Q7VG86IE1BTExJSyBNVURJR09OREEgKG1tdWRpZ29uKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1t dWRpZ29uQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1tdWRpZ29uQGNpc2NvLmNvbTwvYT4m Z3Q7OyBCYXNpbCBTYWppPGJyPg0KJmd0OyZsdDs8YSBocmVmPSJtYWlsdG86c2Jhc2lsQGp1bmlw ZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+c2Jhc2lsQGp1bmlwZXIubmV0PC9hPiZndDs7IEdyZWcg TWlyc2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tIiB0 YXJnZXQ9Il9ibGFuayI+Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPC9hPiZndDs7IFZlbmdh ZGE8YnI+DQomZ3Q7UHJhc2FkIEdvdmluZGFuICh2ZW5nZ292aSkgJmx0OzxhIGhyZWY9Im1haWx0 bzp2ZW5nZ292aUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj52ZW5nZ292aUBjaXNjby5jb208 L2E+Jmd0OzsgSnVuaXBlciBOZXR3b3Jrczxicj4NCiZndDsmbHQ7PGEgaHJlZj0ibWFpbHRvOnNh bnRvc2hwa0BqdW5pcGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnNhbnRvc2hwa0BqdW5pcGVyLm5l dDwvYT4mZ3Q7OyBTdWRhcnNhbiBQYXJhZ2lyaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwYXJhZ2ly aUBqdW5pcGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnNwYXJhZ2lyaUBqdW5pcGVyLm5ldDwvYT4m Z3Q7Ozxicj4NCiZndDtTYW50b3NoIFBhbGxhZ2F0dGkgJmx0OzxhIGhyZWY9Im1haWx0bzpzYW50 b3NocGtAanVuaXBlci5uZXQiIHRhcmdldD0iX2JsYW5rIj5zYW50b3NocGtAanVuaXBlci5uZXQ8 L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpzYWppYmFzaWxAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+c2FqaWJhc2lsQGdtYWlsLmNvbTwvYT48YnI+DQomZ3Q7Jmx0OzxhIGhyZWY9Im1haWx0 bzpzYmFzaWxAanVuaXBlci5uZXQiIHRhcmdldD0iX2JsYW5rIj5zYmFzaWxAanVuaXBlci5uZXQ8 L2E+Jmd0Ozxicj4NCiZndDtTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LXNwYWxsYWdhdHRpLWJmZC12eGxhbi0wMy50eHQ8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDtBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLTAz LnR4dDxicj4NCiZndDtoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFZlbmdhZGEg UHJhc2FkIEdvdmluZGFuIGFuZCBwb3N0ZWQgdG88YnI+DQomZ3Q7dGhlIElFVEYgcmVwb3NpdG9y eS48YnI+DQomZ3Q7PGJyPg0KJmd0O05hbWU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBkcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW48YnI+DQomZ3Q7UmV2aXNpb246Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgMDM8YnI+DQomZ3Q7VGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO0JGRCBmb3IgVlhMQU48YnI+DQomZ3Q7RG9jdW1lbnQgZGF0ZTogMjAxNi0wNC0x NTxicj4NCiZndDtHcm91cDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW5kaXZp ZHVhbCBTdWJtaXNzaW9uPGJyPg0KJmd0O1BhZ2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs5PGJyPg0KJmd0O1VSTDo8YnI+DQomZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNwYWxsYWdhdHRpLWJmZC12eGxhbi0wMy50eHQi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLTAzLnR4dDwvYT48YnI+DQomZ3Q7U3RhdHVzOjxicj4N CiZndDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zcGFs bGFnYXR0aS1iZmQtdnhsYW4vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtc3BhbGxhZ2F0dGktYmZkLXZ4bGFuLzwvYT48YnI+DQomZ3Q7SHRt bGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXNwYWxsYWdhdHRpLWJmZC12eGxhbi0wMyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhs YW4tMDM8L2E+PGJyPg0KJmd0O0RpZmY6PGJyPg0KJmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zcGFsbGFnYXR0aS1iZmQtdnhsYW4tMDMiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtc3BhbGxh Z2F0dGktYmZkLXZ4bGFuLTAzPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7QWJzdHJhY3Q6PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB1c2Ugb2YgQmlkaXJlY3Rp b25hbCBGb3J3YXJkaW5nIERldGVjdGlvbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7KEJGRCkgcHJv dG9jb2wgZm9yIFZYTEFOIC48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Y8YnI+DQomZ3Q7c3VibWlzc2lv biB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0PGJy Pg0KJmd0OzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRv b2xzLmlldGYub3JnPC9hPi48YnI+DQomZ3Q7PGJyPg0KJmd0O1RoZSBJRVRGIFNlY3JldGFyaWF0 PGJyPg0KJmd0Ozxicj4NCiZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCiZndDtudm8zIG1haWxpbmcgbGlzdDxicj4NCiZndDs8YSBocmVmPSJt YWlsdG86bnZvM0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm52bzNAaWV0Zi5vcmc8L2E+PGJy Pg0KJmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZv MyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bnZvMzwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCm52bzMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm52 bzNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5udm8zQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMzwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpudm8z IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpudm8zQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bnZvM0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7347100B5761DC41A166AC17F22DF11221A81EFDeusaamb103erics_-- From nobody Tue May 24 05:53:48 2016 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 C396E12D6EF for ; Tue, 24 May 2016 05:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-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 2OXOc3-pZtEn for ; Tue, 24 May 2016 05:53:46 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6546D12D6EE for ; Tue, 24 May 2016 05:53:46 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 4526E1E335; Tue, 24 May 2016 08:59:08 -0400 (EDT) Date: Tue, 24 May 2016 08:59:08 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: NomCom 2016-2017 Call for Volunteers Message-ID: <20160524125908.GB26704@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 24 May 2016 12:53:48 -0000 BFD, If you've ever wanted to get more involved in IETF, nomcom is an excellent way to do so. They're looking for volunteers! ------ The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the nomcom can be found in RFC 7437, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 7437, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are: IETF = 91 (Honolulu) \ 92 (Dallas) \ 93 (Prague) -*** ANY THREE! 94 (Yokohama) / 95 (Buenos Aires) / If you qualify, please volunteer. Before you decide to volunteer, please remember that anyone appointed to this Nomcom will not be considered as a candidate for any of the positions that the 2016 - 2017 Nomcom is responsible for filling. Some 229 people have already volunteered by ticking the box on the IETF 95 registration form. 131 of these have been verified as eligible. I will contact all of these shortly. Thank you for volunteering! The list of people and posts whose terms end with the March 2017 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Lou Berger IAB: Ralph Droms Russ Housley Robert Sparks Andrew Sullivan Dave Thaler Suzanne Woolf IESG: Jari Arkko (GEN) Deborah Brungard (RTG) Ben Campbell (ART) Spencer Dawkins (TSV) Stephen Farrell (SEC) Joel Jaeggli (OPS) Terry Manderson (INT) Alvaro Retana (RTG) All appointments are for 2 years. The ART and Routing areas have 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas (with the exception of GEN) have at least one continuing AD. The primary activity for this nomcom will begin in July 2016 and should be completed in January 2017. The nomcom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. While being a nomcom member does require some time commitment it is also a very rewarding experience. As a member of the nomcom it is very important that you be able to attend IETF97 (Seoul) to conduct interviews. Being at IETF96 (Berlin) is useful for orientation. Being at IETF98 is not essential. Please volunteer by sending me an email before 23:59 UTC June 20, 2016, as follows: To: nomcom-chair-2016@ietf.org Subject: Nomcom 2016-17 Volunteer Please include the following information in the email body: Your Full Name: __________ // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: _______________ // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone: _______________________ // For confirmation if selected You should expect an email response from me within 5 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2016/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next few weeks. Thank you! Lucy Lynch llynch@civil-tongue.net nomcom-chair-2016@ietf.org From nobody Wed May 25 19:31:30 2016 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 1CEA512D116; Wed, 25 May 2016 19:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 0AcUeb1Hh41B; Wed, 25 May 2016 19:31:28 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA89D12D105; Wed, 25 May 2016 19:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1466; q=dns/txt; s=iport; t=1464229887; x=1465439487; h=from:to:cc:subject:date:message-id:mime-version; bh=yFH+BMnM1jTdg3xCXZT1FmcxUM4otkWHW3TEGGNojb4=; b=FBoz5BBRYFxpqIOgTz+LJBkHXC9Rw20yTsyOAZJqClXfdBG2yIMS3FcS mnH+287+x/UxcBOhF1Nkh2i70yRlu3s4ThN3AwqZnh3UxceQA++R2V5b8 wbBS1DbmR56obTODS0xNRcMihgFCv1ym79lHQRwmUoCJqJq+agaXT7Pe1 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BQAgBFX0ZX/4gNJK1cgmxNgVm0fIR5A?= =?us-ascii?q?Q2BeIYRgTU4FAEBAQEBAQFlJ4Q6EHkSAQsBdCcEAQ2INMMDAQEBAQEBAQMBAQE?= =?us-ascii?q?BAQEBAR+GJ45lBZg3AY4fgWmET4hkj0sBHgEBQoNtigR/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,366,1459814400"; d="scan'208,217";a="111996834" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 May 2016 02:31:26 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u4Q2VQEb017737 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 26 May 2016 02:31:26 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 May 2016 21:31:26 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.009; Wed, 25 May 2016 21:31:26 -0500 From: "Reshad Rahman (rrahman)" To: "draft-ietf-bfd-multipoint@ietf.org" , "draft-ietf-bfd-multipoint-active-tail@ietf.org" , "rtg-bfd@ietf.org" Subject: BFD multipoint Thread-Topic: BFD multipoint Thread-Index: AQHRtvazR/s7t4vcT0Kkiv47as2kOg== Date: Thu, 26 May 2016 02:31:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.254.116] Content-Type: multipart/alternative; boundary="_000_D36BD83B153F21rrahmanciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 02:31:29 -0000 --_000_D36BD83B153F21rrahmanciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We would like to get implementation status for the BFD multipoint drafts wh= ich are in progress: draft-ietf-bfd-multipoint and draft-ietf-bfd-multipoint-active-tail Can the draft authors and everyone else concerned please respond with imple= mentation status? Regards, Reshad & Jeff. --_000_D36BD83B153F21rrahmanciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9D4B651EE843D5439DE9C8BFA94FA80A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

We would like to get implementation status for the BFD multipoint draf= ts which are in progress: 
draft-ietf-bfd-multipoint and draft-ietf-bfd-multipoint-active-tail

Can the draft authors and everyone else concerned please respond with = implementation status? 

Regards,
Reshad & Jeff.
--_000_D36BD83B153F21rrahmanciscocom_-- From nobody Tue May 31 08:58:54 2016 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 EA4C412D610; Tue, 31 May 2016 08:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-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 EOndqIiAB2Kl; Tue, 31 May 2016 08:58:51 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7B47712D60C; Tue, 31 May 2016 08:58:51 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CF52F1E335; Tue, 31 May 2016 12:04:23 -0400 (EDT) Date: Tue, 31 May 2016 12:04:23 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org, mpls@ietf.org Subject: De-chartering draft-ietf-bfd-mpls-mib Message-ID: <20160531160423.GL10531@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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 May 2016 15:58:53 -0000 BFD and MPLS Working Groups, Back in November of last year, BFD polled to see what should become of the chartered work for a MIB providing MPLS extensions for the base BFD MIB. At that time, we didn't find any support for bringing the MIB forward for last call. Interest in MIBs has obviously been waning as Yang has gained popularity within IETF. Additionally, the operational cases covered by the MPLS extensions to the BFD MIB apparently haven't proven compelling to the working groups or vendors. The BFD chairs, in consultation with the MPLS chairs, are minded to remove this MIB from the charter. Given that the draft is actually fairly mature and in a state largely ready to pass last call (with a few known changes likely to be recommended by the MIB doctors), we wanted to extend one last comment period to both working groups before taking this action. Please send your comments to the rtg-bfd@ietf.org mailing list if you believe this work should continue. -- Jeff and Reshad