From arssraj2208@gmail.com Wed May 3 04:03:21 2017 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 6E022126579 for ; Wed, 3 May 2017 04:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 m8ERpzZyO2xf for ; Wed, 3 May 2017 04:03:20 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 BCE5D129504 for ; Wed, 3 May 2017 04:00:43 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id b204so17368660oii.1 for ; Wed, 03 May 2017 04:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nWXHuSSY9qDVmpC356uhIrN9hNFaioZI5YNbQsTssgA=; b=hVB3DBbuOyYkURmts9hjRXrNhLFIms/Z/NVHDP31u+/Z8eE6+859PgUEsfaIalAOgg H8JhdcvTWkdbyJnJShfZO7BNWJEKQbSlSBuggpPthOBjJU6v2yk+G92SJOYNLFoPYrD9 EVPZrkM8+epbqn2BGeqzzSdinsQbxqDuaU/mNl/FVi4HEoVdtijYzdRDtXWnvYjXvqQs m80+jBVQ5mzIvZRcfWvZTjtgkw0gX3EOHGUmDqY6JrNTtztmhR/WL5dImi5pu4iUddzq qXf0kNSn1NHapNNWpJMZ/16/mNNvWTBs+QPFsxzSA6BfW8h9tkC9+luYK3jRbPEcMQZ1 jAWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nWXHuSSY9qDVmpC356uhIrN9hNFaioZI5YNbQsTssgA=; b=ZvD43fElMusKlESygBzRXf/NHRi8q6hQ+urSFK3eSQaKfdrJKXFXeS8cpxq0OfPoXP e9pIhzorwrap6r78HSQWfKyef3otB37D0yVRpvHhpAwLmZYYm3K3AFipTwjMD6NNbYCl 5CvdUWfXOtFVfhR+m1zCAsb7hbTSINZIj67JHh+GqPfLFHaqVeHRv5bCz+GC8czML4Dk Q3+T2Q3NMFNtUDxIWmoA7Hhm3/jY8WjysorKtIxBKAr/VqtMcmg3ICYZ8zHmRDUxhO8v iw7972C9JAESQk+jpuAyLDgl4Pfva/CJQmhAB7W8gU5R9MjaNIVuRj0vabHm+HHeM/Vx MMvQ== X-Gm-Message-State: AN3rC/6V9MbhcEQjMVO5u04uTcTGi23MZQ7qMqGz7SHuBDAS+6tXyFgL eVKMWn6BaeeW/W2E67lkGnJxBPrDDq7+hshxTA== X-Received: by 10.202.77.149 with SMTP id a143mr12586368oib.90.1493809243041; Wed, 03 May 2017 04:00:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.244.137 with HTTP; Wed, 3 May 2017 04:00:42 -0700 (PDT) From: arch 25 Date: Wed, 3 May 2017 16:30:42 +0530 Message-ID: Subject: RFC7130 - IPv6 To: rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=001a11c15f5a4b379f054e9c916d Archived-At: X-Mailman-Approved-At: Wed, 03 May 2017 06:36:19 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 03 May 2017 11:10:43 -0000 --001a11c15f5a4b379f054e9c916d Content-Type: text/plain; charset=UTF-8 Hello WG, Problem Statement: =============== IPv6 DAD detection prevents bringing up of BFD-over-LAG session. Description: ======== If BFD-over-LAG feature with IPv6 address family is provisioned on LAG interface before the aggregated member link is active, BFD session fails to come UP, since IPv6 global unicast address remains invalid as DAD detection is not triggered on LAG interface. I have few clarifications on RFC7130 to address this issue. 1) Can the BFD packet sent to UDP port 6784 with a source IPv6 address set to 0::0 ? 2a) Can destination IPv6 address be set to loopback ::1/128 ? 2b) Should destination address mandatorily be a global unicast address configured on peer interface? Thanks & Regards --001a11c15f5a4b379f054e9c916d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello WG,

Problem Statement:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=C2=A0

IP<= span style=3D"font-size:10pt">v6 DAD detection prevents bringing up of BFD-= over-LAG session.

=C2=A0

= Description:

=3D=3D=3D=3D=3D=3D=3D= =3D

If BFD-over-LAG feature with IPv6 address family i= s provisioned on LAG interface before the aggregated member link is active,= BFD session fails to=C2=A0come UP,= =C2=A0since IPv6 global unicast addr= ess remains invalid as DAD detection is not triggered on LAG interface.

=C2=A0

I h= ave few clarifications on RFC7130 to address this issue.

=C2=A0

1)=C2=A0Can=C2=A0= the BFD packet sent to UDP port 6784 = with a=C2=A0source IPv6 address=C2= =A0set to=C2=A00::0 ?

2a)=C2=A0Can des= tination=C2=A0IPv6=C2=A0address be=C2=A0set to loopback=C2=A0::1/128 ?

2b)=C2=A0Should destination address mandatorily be a global unicast address con= figured on peer interface?


Thanks & Regards


--001a11c15f5a4b379f054e9c916d-- From nobody Thu May 4 00:31:00 2017 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 EDAF4129BC5 for ; Thu, 4 May 2017 00:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.809 X-Spam-Level: X-Spam-Status: No, score=0.809 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, T_SPF_PERMERROR=0.01] 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 g9fp7oWCLckp for ; Thu, 4 May 2017 00:30:50 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [82.212.219.2]) by ietfa.amsl.com (Postfix) with ESMTP id E29B9129BAA for ; Thu, 4 May 2017 00:30:49 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 99FE74BD009; Thu, 4 May 2017 07:30:47 +0000 (UTC) Date: Thu, 4 May 2017 00:30:46 -0700 From: Marc Binderberger To: arch 25 Cc: rtg-bfd@ietf.org Message-ID: <20170504003046962225.d99a1c00@sniff.de> In-Reply-To: References: Subject: Re: RFC7130 - IPv6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.17 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 04 May 2017 07:30:52 -0000 Hello, grey area (deliberately). The main problem seems to be that you don't have a valid IP(v6) address. This is on many implementations not different for IPv4: 1 or N micro BFD sessions must be Up before the LAG is declared Up in layer-2 and only then layer-3 and the IP address is activated. This is why the destination MAC is defined, it allows to accept the BFD packets while ignoring (at this stage) the IP address. Relying on the defined destination MAC may also solve your DAD problem. > 2a) Can destination IPv6 address be set to loopback ::1/128 ? RFC 4291 ("IP Version 6 Addressing Architecture") states: 2.5.3. The Loopback Address The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. It may be used by a node to send an IPv6 packet to itself. It must not be assigned to any physical interface. It is treated as having Link-Local scope, and may be thought of as the Link-Local unicast address of a virtual interface (typically called the "loopback interface") to an imaginary link that goes nowhere. The loopback address must not be used as the source address in IPv6 packets that are sent outside of a single node. An IPv6 packet with a destination address of loopback must never be sent outside of a single node and must never be forwarded by an IPv6 router. A packet received on an interface with a destination address of loopback must be dropped. Unless you find another RFC stating the opposite (quite possible ;-) you cannot send a packet with ::1 as destination address onto a wire. > 2b) Should destination address mandatorily be a global unicast address > configured on peer interface? The RFC 7130 says: Control packets use a destination IP address that is configured on the peer system and can be reached via the LAG interface. Implementations may range from explicitly configuring IP addresses for the BFD sessions to out-of-band methods for learning the destination IP address. The details are outside the scope of this document. The "on peer interface" in your "2b" question is a bit too strict; an unnumbered LAG "borrowing" from a loopback interface should be supported too. But the "[...] address configured" comes close to the intention from authors/implementors/users. So practically the assumption is one side knows the IP address of the other side upfront and uses it. Remember, this is before an IGP can even detect the other side. I would not rule out link-local addresses assigned by a central controller but again the micro BFD sessions would learn the IP of the peer upfront, from the controller. Regards, Marc On Wed, 3 May 2017 16:30:42 +0530, arch 25 wrote: > Hello WG, > > Problem Statement: > =============== > IPv6 DAD detection prevents bringing up of BFD-over-LAG session. > > Description: > ======== > If BFD-over-LAG feature with IPv6 address family is provisioned on LAG > interface before the aggregated member link is active, BFD session fails to > come UP, since IPv6 global unicast address remains invalid as DAD detection > is not triggered on LAG interface. > > I have few clarifications on RFC7130 to address this issue. > > 1) Can the BFD packet sent to UDP port 6784 with a source IPv6 address set > to 0::0 ? > 2a) Can destination IPv6 address be set to loopback ::1/128 ? > 2b) Should destination address mandatorily be a global unicast address > configured on peer interface? > > > Thanks & Regards > > From nobody Thu May 4 14:53:49 2017 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 1DBA8129601; Thu, 4 May 2017 14:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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.001, SPF_HELO_PASS=-0.001, 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 7I5sk55SuKKG; Thu, 4 May 2017 14:53:45 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5511B129535; Thu, 4 May 2017 14:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=637; q=dns/txt; s=iport; t=1493934824; x=1495144424; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8PYjuwD+ZxgkMH2/xZyDZ1LwiPpaLEoG6Ylub8Tm2pI=; b=K14tY3tpXkxBFN5qM0mbqHvypfSvUmQNz6Lp7WWgltldVO/G0nn9Pao6 EuBiu629U6sgjr2cFrl+12TNhpM02cJoJR5GIrEr/uAqdRzU7nSMC85qe rN0/Gsz+chfP7dsT7JsW3LUcoXAfk6nkqieyj2+s4Qi0rX2BVWL50Np9L w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAABNogtZ/51dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHjXmnRIIPLIV4AoRNPxgBAgEBAQEBAQFrHQuFFgYdHTQ?= =?us-ascii?q?LEAIBCDYQMiUCBA4FiiAOs26KZwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhl+Ee?= =?us-ascii?q?YE8iQwBBJ1lAYcai3qBbBiFOYoqlDQBHziBCm8VRoR/gXN2h3SBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,289,1491264000"; d="scan'208";a="416986352" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 May 2017 21:53:43 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v44LrhH8000863 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 May 2017 21:53:43 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.1210.3; Thu, 4 May 2017 16:53:42 -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.1210.000; Thu, 4 May 2017 16:53:42 -0500 From: "Reshad Rahman (rrahman)" To: "draft-ashesh-bfd-stability@ietf.org" CC: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: Adoption call for draft-ashesh-bfd-stability (ends April 30, 2017) Thread-Topic: Adoption call for draft-ashesh-bfd-stability (ends April 30, 2017) Thread-Index: AQHSt8Iq7Q6HpdyNfU27jSXtAbcD1KHk4wWA Date: Thu, 4 May 2017 21:53:42 +0000 Message-ID: References: <20170417213947.GC18219@pfrc.org> In-Reply-To: <20170417213947.GC18219@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.247.84] 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.22 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, 04 May 2017 21:53:47 -0000 Hi authors, This document has passed adoption as BFD WG document. Please re-submit your draft as draft-ietf-bfd-stability. Regards, Reshad & Jeff. On 2017-04-17, 5:39 PM, "Rtg-bfd on behalf of Jeffrey Haas" wrote: >Working Group, > >https://tools.ietf.org/html/draft-ashesh-bfd-stability-05 > >The authors of BFD Stability (draft-ashesh-bfd-stability), presented their >latest changes at IETF 98 in Chicago and have requested working group >adoption. > >Please indicate your support or lack of support to the mailing list. > >-- Jeff and Reshad > From nobody Thu May 4 14:54:15 2017 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 226A1129503; Thu, 4 May 2017 14:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.123 X-Spam-Level: X-Spam-Status: No, score=-13.123 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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.001, SPF_HELO_PASS=-0.001, 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 bTZSegCqU2dk; Thu, 4 May 2017 14:54:11 -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 7EEFE129508; Thu, 4 May 2017 14:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1283; q=dns/txt; s=iport; t=1493934851; x=1495144451; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=W1Io7fhpWtD9PfpaGuR6Do4CQ2k6KFCzvk7jKMfpgk4=; b=NCsEa/Hz5/G5DrNxGBVc+2fFcmnW7P0EWN5WNYh3TwzL3PAix8Zw+7JB Vjs7j/icEiQ5lxYETUO7KXfppPw0tTiFhP92Q5Z8IA7/tvkK+V8K0XhHt NT36f/tnGxfk+Izd72g3pLTpNYTIWLC+nUt/+6HguZHsOyjY0ECPiQqJe A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AAANogtZ/4UNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1WBbgeNeadEgg+GJAKETT8YAQIBAQEBAQEBax0LhRYGHR00CxACAQg?= =?us-ascii?q?2EDIlAgQOBRuKBbN6imcBAQEBAQEBAQEBAQEBAQEBAQEBAR6GX4R5gTyJDAEEn?= =?us-ascii?q?WUBkxSCBIU5iiqUNAEfOIEKbxVGhH8pgUp2h3SBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,289,1491264000"; d="scan'208";a="421329904" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 May 2017 21:54:10 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v44LsA0F001006 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 May 2017 21:54:10 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 4 May 2017 16:54:10 -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.1210.000; Thu, 4 May 2017 16:54:10 -0500 From: "Reshad Rahman (rrahman)" To: "draft-sonal-bfd-secure-sequence-numbers@ietf.org" CC: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: Adoption call for draft-sonal-bfd-secure-sequence-numbers (ending April 30, 2017) Thread-Topic: Adoption call for draft-sonal-bfd-secure-sequence-numbers (ending April 30, 2017) Thread-Index: AQHSt8GOym0WvtZ2iE2jKJQ4DD+/I6Hk4yQA Date: Thu, 4 May 2017 21:54:10 +0000 Message-ID: References: <20170417213533.GB18219@pfrc.org> In-Reply-To: <20170417213533.GB18219@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.247.84] Content-Type: text/plain; charset="us-ascii" Content-ID: <3F1C30CBA0960047BE90C291CA67A94C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 04 May 2017 21:54:14 -0000 Hi authors, This document has passed adoption as BFD WG document. Please re-submit your draft as draft-ietf-bfd-secure-sequence-numbers. Regards, Reshad & Jeff. On 2017-04-17, 5:35 PM, "Jeffrey Haas" wrote: >Working Group, > >As part of our discussion at the Working Group session at IETF 98 in >Chicago, Sonal Agarwal presented "Secure BFD Sequence Numbers" >(draft-sonal-bfd-secure-sequence-numbers-00). This work complements a >problem space the Security area had asked us to address as part of the >work >on optimizing BFD authentication, our adopted >draft-ietf-bfd-optimizing-authentication. > >The discussion on the implementation implictions of the optimizing >authentication draft was energetic this last IETF. To drive that solution >further along, we will need a technology similar to the one in the >proposal. > >This starts a 2 week adoption call for >draft-sonal-bfd-secure-sequence-numbers. >Please indicate your support or lack of support for the proposal to the >mailing list. > >Note that part of the discussion was that optimizing BFD is not ready to >proceed to Last CAll until we've adopted such a proposal and have >properly integrated it into the optimization procedures. > >-- Jeff and Reshad From nobody Thu May 4 14:54:38 2017 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 71DC5129508; Thu, 4 May 2017 14:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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.001, SPF_HELO_PASS=-0.001, 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 288ZkisEgIkU; Thu, 4 May 2017 14:54:35 -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 D1EAC129535; Thu, 4 May 2017 14:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=837; q=dns/txt; s=iport; t=1493934874; x=1495144474; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ta06O3ducs826Pjxb5ehfoQ07swshHesnAXKIGNGq08=; b=FDEARa0f58dFKYg96740pRJq0zLngoAq27fNr/YH3ia9b3IX5r2n1NFL wjknaR7NuObErHyOCd5X0pvMcg+N5hBQmuu0fJVyUlE4+vL91Y2dCI4mO I9KOA7VLxvlLcspJdTGnbsNrS0V8FOvpt69dJbN/bpBMq12QvL/gSSiJd E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAADQogtZ/40NJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHjXmnRIIPLIV4AoRNPxgBAgEBAQEBAQFrKIUWBh0dNAs?= =?us-ascii?q?QAgEINhAyJQIEAQ0FiiAOs2+KZwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhl+BX?= =?us-ascii?q?oMbgTyJDAEEnWUBhxqLeoIEhTmKKpQ0AR84gQpvFUaEf4Fzdod0gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.38,289,1491264000"; d="scan'208";a="422015476" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 May 2017 21:54:34 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v44LsYTO005675 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 May 2017 21:54:34 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 4 May 2017 16:54:33 -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.1210.000; Thu, 4 May 2017 16:54:33 -0500 From: "Reshad Rahman (rrahman)" To: "draft-tanmir-rtgwg-bfd-mc-lag-mpls@ietf.org" , "draft-tanmir-rtgwg-bfd-mc-lag-ip@ietf.org" CC: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: Adoption call for draft-tanmir-rtgwg-bfd-mc-lag-* (ends April 30, 2017) Thread-Topic: Adoption call for draft-tanmir-rtgwg-bfd-mc-lag-* (ends April 30, 2017) Thread-Index: AQHSt8zIDbp3spReDUOK920TbxCi4qHk4yyA Date: Thu, 4 May 2017 21:54:33 +0000 Message-ID: References: <20170417225539.GE18219@pfrc.org> In-Reply-To: <20170417225539.GE18219@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.247.84] Content-Type: text/plain; charset="us-ascii" Content-ID: <0719CC68D3B67E488133C88C5FF30BA1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 04 May 2017 21:54:36 -0000 Hi authors, We do not yet have consensus to adopt these 2 drafts as BFD WG documents. Regards, Reshad. On 2017-04-17, 6:55 PM, "Rtg-bfd on behalf of Jeffrey Haas" wrote: >Working Group, > >https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-ip-00 >https://datatracker.ietf.org/doc/draft-tanmir-rtgwg-bfd-mc-lag-mpls/ > >The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for IP >and MPLS have requested BFD working group adoption for their drafts. > >These drafts were previously presented at IETF-96. > >Please note that IPR has been declare against these drafts. The IPR >declaration may be found from the datatracker links. > >Please indicate your support/lack of support to the mailing list. > >-- Jeff and Reshad > > From nobody Fri May 5 11:53:49 2017 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 DD3671293EE for ; Fri, 5 May 2017 11:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, 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 0lGPgjUM4F9a for ; Fri, 5 May 2017 11:53:46 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 73B021286B2 for ; Fri, 5 May 2017 11:53:46 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 085EE1E377; Fri, 5 May 2017 15:01:21 -0400 (EDT) Date: Fri, 5 May 2017 15:01:21 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Draft of interest to BFD WG - draft-li-idr-bgp-ls-sbfd-extensions Message-ID: <20170505190121.GN22975@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.22 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, 05 May 2017 18:53:48 -0000 The following draft is of interest to the BFD group. It carries S-BFD discriminators in BGP-LS. Quick note to the authors: You did well in avoiding code point squatting, but left one artifact in there. Type - S-BFD Discriminator TLV Type (11) :-) -- Jeff ----- Forwarded message from IETF Secretariat ----- Date: Mon, 24 Apr 2017 23:29:50 -0700 From: IETF Secretariat To: jhaas@pfrc.org Subject: Personal ID list of jhaas@pfrc.org notification: Changes to draft-li-idr-bgp-ls-sbfd-extensions Hello, This is a notification from the Personal ID list of jhaas@pfrc.org. Document: draft-li-idr-bgp-ls-sbfd-extensions, https://datatracker.ietf.org/doc/draft-li-idr-bgp-ls-sbfd-extensions/ Change: Uploaded new revision Best regards, The Datatracker draft tracking service (for the IETF Secretariat) ----- End forwarded message ----- From nobody Mon May 8 20:33:21 2017 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 B39301293F9; Mon, 8 May 2017 20:33:11 -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 TUt8-0Ec83B6; Mon, 8 May 2017 20:33:09 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 9EAFD126C2F; Mon, 8 May 2017 20:33:09 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id l18so73367945oig.2; Mon, 08 May 2017 20:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=OA+/AoIVq22yNANfyGt50aie02oIvPaFlKvYBAbRgS0=; b=kb1KueaYL4Z/IlDaylIujRHjx+GuT78nw+EX/tvq/DWRdw00pkkpj46sGCspl8IWty V90IpOEP7pesrxkz6I1gz7cj0mobtKk0Dl+/NkUK2PQ6Cpvsi5hz4I2/g0OPmFU+Y6gG shF/Rpx9eWd9VoWDBkalqTE7o1waywbGwCejunF5fESq9kZ+GYAKAXr/pnvNYpG2FknS OWU16NEtf/W5Sy3IpUT2mzTA2U42zGwelgrILAKcnnCSLCi3X3v5lqkbpP0m2JF85Lu+ j42ktCpTYOcpOV1KWaO5dPD3LpCgGdNhbCEONmdTShHaqV4FqMwWWhLP36woSwozKEJV W/6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=OA+/AoIVq22yNANfyGt50aie02oIvPaFlKvYBAbRgS0=; b=lA5nJ8MRAieQ4CR6Ff6WyCm0UeRrAQCz1lcjuC1fOL4fxENlsp1Z4r1LmQZGD+kJB1 x36rrnoi9DQ7AuiYm+MhADp2BHjXJjDBhyFVOhsIu+5kKVYkn4AyIGxWqGYEzr3UEqLc bbL9f93n0jdsMhwDjiwSK22u6hdYd4YEr+y+pkD12NpvWinqW1ubPcsYMq8OxRSanbeS WQ0ah3U0W4bIN69R19+D+ARaIL5OyS5s1Lof4EFYHKweiH2gsTlxKeUMMQLSLAvSSqcd l61yWj2LdAOoFOcCJUFuEaVGz41ECd+hjStYuhGjXplWVc9Ggkftst9nFefTK/SrfzkX 83Tg== X-Gm-Message-State: AN3rC/6pkz1qAhl8tdIMkvTlbAgAlaaXKyrfyWhy6EghStQ6rhOPoJQK q8n33mZx0wx+tCmS3BlZBxvhaNdhR15o X-Received: by 10.202.60.11 with SMTP id j11mr24252108oia.161.1494300788849; Mon, 08 May 2017 20:33:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.246 with HTTP; Mon, 8 May 2017 20:33:08 -0700 (PDT) In-Reply-To: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Mon, 8 May 2017 20:33:08 -0700 Message-ID: Subject: Fwd: New Version Notification for draft-mirsky-spring-bfd-00.txt To: spring@ietf.org, "rtg-bfd@ietf.org" , "mpls@ietf.org" Content-Type: multipart/alternative; boundary=001a113ccb38b506f3054f0f0318 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 09 May 2017 03:33:12 -0000 --001a113ccb38b506f3054f0f0318 Content-Type: text/plain; charset=UTF-8 Dear All, perhaps this new draft may is of interest to you. Your comments, suggestions are most welcome and greatly appreciated. Regards, Greg ---------- Forwarded message ---------- From: Date: Mon, May 8, 2017 at 8:29 PM Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt To: Gregory Mirsky A new version of I-D, draft-mirsky-spring-bfd-00.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-spring-bfd Revision: 00 Title: Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPLS Dataplane Document date: 2017-05-08 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-mirsky-spring-bfd -00.txt Status: https://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/ Htmlized: https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-mirsky-spring-b fd-00 Abstract: Segment Routing architecture leverages the paradigm of source routing. It can be realized in the Multiprotocol Label Switching (MPLS) network without any change to the data plane. A segment is encoded as an MPLS label and an ordered list of segments is encoded as a stack of labels. Bidirectional Forwarding Detection (BFD) is expected to monitor any kind of paths between systems. This document defines how to use Label Switched Path Ping to bootstrap and control path in reverse direction of a BFD session on the Segment Routing network over MPLS dataplane. 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 --001a113ccb38b506f3054f0f0318 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,
perhaps this new draft may is of interest to= you.
Your comments, suggestions are most welcome and greatly app= reciated.

Regards,
Greg

---------- Forwarded message ----------
From: <= b class=3D"gmail_sendername"> <internet-drafts@ietf.org>=
Date: Mon, May 8, 2017 at 8:29 PM
Subject: New Version Notifi= cation for draft-mirsky-spring-bfd-00.txt
To: Gregory Mirsky <gregimirsky@gmail.com>



A new version of I-D, draft-mirsky-spring-bfd-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-spring-bfd
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bidirectional Forwarding Detection= (BFD) in Segment Routing Networks Using MPLS Dataplane
Document date:=C2=A0 2017-05-08
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky-spring-= bfd-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-mirsky-spring-bfd-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-mirsky-spring-bfd-00<= /a>


Abstract:
=C2=A0 =C2=A0Segment Routing architecture leverages the paradigm of source<= br> =C2=A0 =C2=A0routing.=C2=A0 It can be realized in the Multiprotocol Label S= witching
=C2=A0 =C2=A0(MPLS) network without any change to the data plane.=C2=A0 A s= egment is
=C2=A0 =C2=A0encoded as an MPLS label and an ordered list of segments is en= coded
=C2=A0 =C2=A0as a stack of labels.=C2=A0 Bidirectional Forwarding Detection= (BFD) is
=C2=A0 =C2=A0expected to monitor any kind of paths between systems.=C2=A0 T= his document
=C2=A0 =C2=A0defines how to use Label Switched Path Ping to bootstrap and c= ontrol
=C2=A0 =C2=A0path in reverse direction of a BFD session on the Segment Rout= ing
=C2=A0 =C2=A0network over MPLS dataplane.




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

The IETF Secretariat


--001a113ccb38b506f3054f0f0318-- From nobody Tue May 9 08:51:43 2017 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 8557212E049; Tue, 9 May 2017 08:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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.001, SPF_HELO_PASS=-0.001, 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 iSyUAheispVh; Tue, 9 May 2017 08:51:40 -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 7A42C12E057; Tue, 9 May 2017 08:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11404; q=dns/txt; s=iport; t=1494345100; x=1495554700; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=b9PUXgYXDwJtNTK18p1PTl3sMYCbt09BDD9/rWOEAoo=; b=UVapUp/FRWzXKwKWzCk8GGmG9nKyQYBk0tmTD1cq+rI3kOu8ym4hkvhf gZM3/22lD0HvwQv2a11gO1913TpvuqdBVxWQZpkMttFhic4+lSv8xL3mh c8k0T3q9wNYw/pZGW6+QPy0pGW8EziDiNYa/v59YIoj1UVsbCphHRNTMn I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AAD35BFZ/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHg2KKGJFWiCOIF4U4gg8hAQqFeAIahFI/GAECAQEBAQE?= =?us-ascii?q?BAWsohRUBAQEBAwEBIUsJAhACAQgRAQIBAigDAgICHwYLFAMGCAIEDgWKCQMVD?= =?us-ascii?q?rJWgiaHLg2DOAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GX4FeK4JwglSBcgEBOxY?= =?us-ascii?q?IgkwugjEFiUSGXo0oOwGHG4cqhFOCBFWEZoosiyqEdyiDdgEPEDiBCnAVHCoSA?= =?us-ascii?q?YQoORyBY3YBhkWBIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.38,315,1491264000"; d="scan'208,217";a="422173887" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 May 2017 15:51:39 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v49FpdtO013839 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 May 2017 15:51:39 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.1210.3; Tue, 9 May 2017 11:51: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.1210.000; Tue, 9 May 2017 11:51:38 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: "spring@ietf.org" , "rtg-bfd@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt Thread-Topic: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt Thread-Index: AQHSyNwkwOl2lp11iEyR0ciJiuUUKQ== Date: Tue, 9 May 2017 15:51:38 +0000 Message-ID: <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> References: <149430058880.24107.8628199428997673992.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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.52] Content-Type: multipart/alternative; boundary="_000_1C12E1626B5C4EF2A3CB3621C72BCFE9ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 09 May 2017 15:51:42 -0000 --_000_1C12E1626B5C4EF2A3CB3621C72BCFE9ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBHcmVnLA0KDQpDdXJzb3JpbHkgc2Nhbm5pbmcgdGhyb3VnaCB0aGlzLCBpdCBzZWVtcyB0 aGF0IG1vc3QgY29uY2VybnMgcmFpc2VkIGFuZCBjb21tZW50cyBtYWRlIGFib3V0IHRoZSBTUiBz ZWN0aW9ucyBvZiBkcmFmdC1pZXRmLW1wbHMtYmZkLWRpcmVjdGVkLTBOICh3aXRoIE4gPCA1KSBh cHBseSB0byB5b3VyIG5ldyBkcmFmdC4NCg0KVGhpcyBpcyBvbmUgb2YgdGhvc2U6IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50L21zZzE1ODYwLmh0bWwg 4oCUIHRoZSBsaXN0IGFyY2hpdmUgc2hvd3MgYSBmZXcgbW9yZS4gVGhlIGNvcHkvcGFzdGUgZGlk IG5vdCBhZGRyZXNzIHRoZSBjb21tZW50cy4NCg0KQmVzdCwNCg0K4oCUIENhcmxvcy4NCg0KT24g TWF5IDgsIDIwMTcsIGF0IDExOjMzIFBNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwu Y29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiB3cm90ZToNCg0KRGVhciBBbGwsDQpw ZXJoYXBzIHRoaXMgbmV3IGRyYWZ0IG1heSBpcyBvZiBpbnRlcmVzdCB0byB5b3UuDQpZb3VyIGNv bW1lbnRzLCBzdWdnZXN0aW9ucyBhcmUgbW9zdCB3ZWxjb21lIGFuZCBncmVhdGx5IGFwcHJlY2lh dGVkLg0KDQpSZWdhcmRzLA0KR3JlZw0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0t LS0tLS0tLS0NCkZyb206IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZz4+DQpEYXRlOiBNb24sIE1heSA4LCAyMDE3IGF0IDg6MjkgUE0NClN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWlyc2t5LXNwcmluZy1i ZmQtMDAudHh0DQpUbzogR3JlZ29yeSBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWls dG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4NCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1taXJza3ktc3ByaW5nLWJmZC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgR3JlZyBNaXJza3kgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4N Cg0KTmFtZTogICAgICAgICAgIGRyYWZ0LW1pcnNreS1zcHJpbmctYmZkDQpSZXZpc2lvbjogICAg ICAgMDANClRpdGxlOiAgICAgICAgICBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9u IChCRkQpIGluIFNlZ21lbnQgUm91dGluZyBOZXR3b3JrcyBVc2luZyBNUExTIERhdGFwbGFuZQ0K RG9jdW1lbnQgZGF0ZTogIDIwMTctMDUtMDgNCkdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICA3DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1pcnNreS1zcHJpbmctYmZkLTAwLnR4dA0K U3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1p cnNreS1zcHJpbmctYmZkLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1taXJza3ktc3ByaW5nLWJmZC0wMA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDAN Cg0KDQpBYnN0cmFjdDoNCiAgIFNlZ21lbnQgUm91dGluZyBhcmNoaXRlY3R1cmUgbGV2ZXJhZ2Vz IHRoZSBwYXJhZGlnbSBvZiBzb3VyY2UNCiAgIHJvdXRpbmcuICBJdCBjYW4gYmUgcmVhbGl6ZWQg aW4gdGhlIE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nDQogICAoTVBMUykgbmV0d29yayB3 aXRob3V0IGFueSBjaGFuZ2UgdG8gdGhlIGRhdGEgcGxhbmUuICBBIHNlZ21lbnQgaXMNCiAgIGVu Y29kZWQgYXMgYW4gTVBMUyBsYWJlbCBhbmQgYW4gb3JkZXJlZCBsaXN0IG9mIHNlZ21lbnRzIGlz IGVuY29kZWQNCiAgIGFzIGEgc3RhY2sgb2YgbGFiZWxzLiAgQmlkaXJlY3Rpb25hbCBGb3J3YXJk aW5nIERldGVjdGlvbiAoQkZEKSBpcw0KICAgZXhwZWN0ZWQgdG8gbW9uaXRvciBhbnkga2luZCBv ZiBwYXRocyBiZXR3ZWVuIHN5c3RlbXMuICBUaGlzIGRvY3VtZW50DQogICBkZWZpbmVzIGhvdyB0 byB1c2UgTGFiZWwgU3dpdGNoZWQgUGF0aCBQaW5nIHRvIGJvb3RzdHJhcCBhbmQgY29udHJvbA0K ICAgcGF0aCBpbiByZXZlcnNlIGRpcmVjdGlvbiBvZiBhIEJGRCBzZXNzaW9uIG9uIHRoZSBTZWdt ZW50IFJvdXRpbmcNCiAgIG5ldHdvcmsgb3ZlciBNUExTIGRhdGFwbGFuZS4NCg0KDQoNCg0KUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvPi4NCg0K VGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRv Om1wbHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMNCg0K --_000_1C12E1626B5C4EF2A3CB3621C72BCFE9ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <342CA9F64BCFEF44826344A6A2AF8B9D@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRGVhciBHcmVnLA0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q3Vyc29yaWx5IHNjYW5u aW5nIHRocm91Z2ggdGhpcywgaXQgc2VlbXMgdGhhdCBtb3N0IGNvbmNlcm5zIHJhaXNlZCBhbmQg Y29tbWVudHMgbWFkZSBhYm91dCB0aGUgU1Igc2VjdGlvbnMgb2YmbmJzcDtkcmFmdC1pZXRmLW1w bHMtYmZkLWRpcmVjdGVkLTBOICh3aXRoIE4gJmx0OyA1KSBhcHBseSB0byB5b3VyIG5ldyBkcmFm dC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlRoaXMgaXMgb25lIG9mIHRob3NlOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50L21zZzE1ODYwLmh0bWwiIGNsYXNzPSIi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50L21zZzE1 ODYwLmh0bWw8L2E+IOKAlCB0aGUgbGlzdCBhcmNoaXZlIHNob3dzIGEgZmV3IG1vcmUuIFRoZSBj b3B5L3Bhc3RlIGRpZCBub3QgYWRkcmVzcw0KIHRoZSBjb21tZW50cy48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJlc3QsPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJQgQ2Fy bG9zLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE1heSA4LCAyMDE3LCBh dCAxMTozMyBQTSwgR3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBn bWFpbC5jb20iIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwv ZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5EZWFyIEFsbCwNCjxkaXYgY2xhc3M9IiI+cGVy aGFwcyB0aGlzIG5ldyBkcmFmdCBtYXkgaXMgb2YgaW50ZXJlc3QgdG8geW91LjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5Zb3VyIGNvbW1lbnRzLCBzdWdnZXN0aW9ucyBhcmUgbW9zdCB3ZWxjb21lIGFu ZCBncmVhdGx5IGFwcHJlY2lhdGVkLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UmVnYXJkcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+R3Jl ZzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+LS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyIGNsYXNzPSIi Pg0KRnJvbTogPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPjwvYj48c3BhbiBkaXI9Imx0ciIg Y2xhc3M9IiI+Jmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIiBjbGFzcz0iIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0Ozwv c3Bhbj48YnIgY2xhc3M9IiI+DQpEYXRlOiBNb24sIE1heSA4LCAyMDE3IGF0IDg6MjkgUE08YnIg Y2xhc3M9IiI+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1p cnNreS1zcHJpbmctYmZkLTAwLnR4dDxiciBjbGFzcz0iIj4NClRvOiBHcmVnb3J5IE1pcnNreSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LW1pcnNreS1zcHJpbmctYmZkLTAwLnR4dDxiciBjbGFzcz0iIj4NCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR3JlZyBNaXJza3kgYW5kIHBvc3RlZCB0byB0 aGU8YnIgY2xhc3M9IiI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KTmFtZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0 LW1pcnNreS1zcHJpbmctYmZkPGJyIGNsYXNzPSIiPg0KUmV2aXNpb246Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7MDA8YnIgY2xhc3M9IiI+DQpUaXRsZTombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaW4g U2VnbWVudCBSb3V0aW5nIE5ldHdvcmtzIFVzaW5nIE1QTFMgRGF0YXBsYW5lPGJyIGNsYXNzPSIi Pg0KRG9jdW1lbnQgZGF0ZTombmJzcDsgMjAxNy0wNS0wODxiciBjbGFzcz0iIj4NCkdyb3VwOiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJy IGNsYXNzPSIiPg0KUGFnZXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA3PGJy IGNsYXNzPSIiPg0KVVJMOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1taXJz a3ktc3ByaW5nLWJmZC0wMC50eHQiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNs YXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtPHdiciBjbGFzcz0iIj5kcmFm dHMvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQ8d2JyIGNsYXNzPSIiPi0wMC50eHQ8L2E+PGJyIGNs YXNzPSIiPg0KU3RhdHVzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXJza3ktc3ByaW5nLWJm ZC8iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvPHdiciBjbGFzcz0iIj5kb2MvZHJhZnQtbWlyc2t5LXNwcmluZy1i ZmQvPC9hPjxiciBjbGFzcz0iIj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1taXJza3ktc3ByaW5n LWJmZC0wMCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2Q8d2JyIGNsYXNzPSIiPnJhZnQtbWlyc2t5LXNwcmluZy1i ZmQtMDA8L2E+PGJyIGNsYXNzPSIiPg0KSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1t aXJza3ktc3ByaW5nLWJmZC0wMCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xh c3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy88d2JyIGNsYXNzPSIiPmRvYy9odG1s L2RyYWZ0LW1pcnNreS1zcHJpbmctYjx3YnIgY2xhc3M9IiI+ZmQtMDA8L2E+PGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQWJzdHJhY3Q6PGJyIGNsYXNzPSIiPg0K Jm5ic3A7ICZuYnNwO1NlZ21lbnQgUm91dGluZyBhcmNoaXRlY3R1cmUgbGV2ZXJhZ2VzIHRoZSBw YXJhZGlnbSBvZiBzb3VyY2U8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7cm91dGluZy4mbmJz cDsgSXQgY2FuIGJlIHJlYWxpemVkIGluIHRoZSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGlu ZzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsoTVBMUykgbmV0d29yayB3aXRob3V0IGFueSBj aGFuZ2UgdG8gdGhlIGRhdGEgcGxhbmUuJm5ic3A7IEEgc2VnbWVudCBpczxiciBjbGFzcz0iIj4N CiZuYnNwOyAmbmJzcDtlbmNvZGVkIGFzIGFuIE1QTFMgbGFiZWwgYW5kIGFuIG9yZGVyZWQgbGlz dCBvZiBzZWdtZW50cyBpcyBlbmNvZGVkPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2FzIGEg c3RhY2sgb2YgbGFiZWxzLiZuYnNwOyBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9u IChCRkQpIGlzPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2V4cGVjdGVkIHRvIG1vbml0b3Ig YW55IGtpbmQgb2YgcGF0aHMgYmV0d2VlbiBzeXN0ZW1zLiZuYnNwOyBUaGlzIGRvY3VtZW50PGJy IGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2RlZmluZXMgaG93IHRvIHVzZSBMYWJlbCBTd2l0Y2hl ZCBQYXRoIFBpbmcgdG8gYm9vdHN0cmFwIGFuZCBjb250cm9sPGJyIGNsYXNzPSIiPg0KJm5ic3A7 ICZuYnNwO3BhdGggaW4gcmV2ZXJzZSBkaXJlY3Rpb24gb2YgYSBCRkQgc2Vzc2lvbiBvbiB0aGUg U2VnbWVudCBSb3V0aW5nPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO25ldHdvcmsgb3ZlciBN UExTIGRhdGFwbGFuZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyIGNs YXNzPSIiPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvIiByZWw9Im5vcmVmZXJyZXIiIHRh cmdldD0iX2JsYW5rIiBjbGFzcz0iIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KbXBs cyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9y ZyIgY2xhc3M9IiI+bXBsc0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIGNsYXNzPSIiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvYT48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_1C12E1626B5C4EF2A3CB3621C72BCFE9ciscocom_-- From nobody Tue May 9 09:00:40 2017 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 6CF8412E76A; Tue, 9 May 2017 09:00:31 -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 ryj0stNX5sp0; Tue, 9 May 2017 09:00:28 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::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 B2C1C12EA42; Tue, 9 May 2017 09:00:23 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id h4so4948772oib.3; Tue, 09 May 2017 09:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LNIPH7txEl3b07ZBRj/kYGT05RcZ1GhC7ydfir+4nVM=; b=E3olA8MDKx2thgOriN2m/fQmanvc5pT1zVW048efx1nWkInSzbaKAZh3/s/HNTL3SS PZ9pLwm7jI6PmZGWIVYexndeiVeFNSuhtDC7s/qqKfQtgzhONijuOheeE+eMkWzLyVWp 6m+UiSAm6NGF+gNfKlsemt/8UA0iqozmorfr7DiYLDctbnyFwtkRZWLRG9socbqni9VE PD9GPYC1xodkWFIaVoyAU7/2Lco+qN/1uL7M289fJgwdXHMBenAQQTtceMLWWmlauEU7 5B3xsLWH7YiICDmvxWERH9ZFw8tVIsDjRfAX8vZrpiKLRn4YvPlsfh8sR3Dv21tD1Nl2 I6rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LNIPH7txEl3b07ZBRj/kYGT05RcZ1GhC7ydfir+4nVM=; b=APktbC/fdoRA0PFX13uXt2cBe0l5eGD1I2RYAnlHCRFzDmQDdcW7ccDnT9U4MFnhCy uMTLVxGlw27vhpJK7Yq+DV74tEsMIbTy3+nkHgAUMnkib3l2GmsUbOz4O7HnejuVyAI1 VKVS6Us5+/I05QEBfgDOihxaZX3IwfDp5zB/1qL+PqpkYjmGPwk6qKlSN0+F78D7U5NH yHGEB8vAUTpzyY9EeS6x0LSbL/M4ucZftpXuBuuZMxqLTdC5e7U5Gvg0t2BE7WHlOuwK WBu8dJZor0cf7CRNcpUceqcZ9Npu1Wez1E+PbBfcyYIH9IP7ik73zxTz7gmv3kL8CCNK CsCQ== X-Gm-Message-State: AODbwcBL+3Bql3UWgqb4ocseE/GulkAaGDbdhSDg+tqJrTvtXxNT1F5o OsZkUspBzUbZjL42J2psP4NUSkw7YndM X-Received: by 10.202.206.139 with SMTP id e133mr293393oig.168.1494345623081; Tue, 09 May 2017 09:00:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.246 with HTTP; Tue, 9 May 2017 09:00:22 -0700 (PDT) In-Reply-To: <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> From: Greg Mirsky Date: Tue, 9 May 2017 09:00:22 -0700 Message-ID: Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt To: "Carlos Pignataro (cpignata)" Cc: "spring@ietf.org" , "rtg-bfd@ietf.org" , "mpls@ietf.org" Content-Type: multipart/alternative; boundary=001a113d3ccc0918cc054f1974f7 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 09 May 2017 16:00:31 -0000 --001a113d3ccc0918cc054f1974f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Carlos, I've decided to re-start the discussion and am interested to hear technical comments to the proposed solution. Regards, Greg On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Dear Greg, > > Cursorily scanning through this, it seems that most concerns raised and > comments made about the SR sections of draft-ietf-mpls-bfd-directed-0N > (with N < 5) apply to your new draft. > > This is one of those: https://www.ietf.org/mail-archive/web/mpls/current/ > msg15860.html =E2=80=94 the list archive shows a few more. The copy/paste= did not > address the comments. > > Best, > > =E2=80=94 Carlos. > > On May 8, 2017, at 11:33 PM, Greg Mirsky wrote: > > Dear All, > perhaps this new draft may is of interest to you. > Your comments, suggestions are most welcome and greatly appreciated. > > Regards, > Greg > > ---------- Forwarded message ---------- > From: > Date: Mon, May 8, 2017 at 8:29 PM > Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt > To: Gregory Mirsky > > > > A new version of I-D, draft-mirsky-spring-bfd-00.txt > has been successfully submitted by Greg Mirsky and posted to the > IETF repository. > > Name: draft-mirsky-spring-bfd > Revision: 00 > Title: Bidirectional Forwarding Detection (BFD) in Segment > Routing Networks Using MPLS Dataplane > Document date: 2017-05-08 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet- > drafts/draft-mirsky-spring-bfd-00.txt > Status: https://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/ > Htmlized: https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-mirsky-spring-bfd-00 > > > Abstract: > Segment Routing architecture leverages the paradigm of source > routing. It can be realized in the Multiprotocol Label Switching > (MPLS) network without any change to the data plane. A segment is > encoded as an MPLS label and an ordered list of segments is encoded > as a stack of labels. Bidirectional Forwarding Detection (BFD) is > expected to monitor any kind of paths between systems. This document > defines how to use Label Switched Path Ping to bootstrap and control > path in reverse direction of a BFD session on the Segment Routing > network over MPLS dataplane. > > > > > 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 > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > --001a113d3ccc0918cc054f1974f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Carlos,
I've decided to re-start the discussi= on and am interested to hear technical comments to the proposed solution.= =C2=A0

Regards,
Greg

On Tue, May 9, 2017 at 8:= 51 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wro= te:
Dear Greg,

Cursorily scanning through this, it seems that most concerns raised an= d comments made about the SR sections of=C2=A0draft-ietf-mpls-bfd-dire= cted-0N (with N < 5) apply to your new draft.

This is one of those:=C2=A0https://www.ietf.org/mail-archive/web/mpls/current/msg15860.html =E2=80=94 the list = archive shows a few more. The copy/paste did not address the comments.

Best,

=E2=80=94 Carlos.

On May 8, 2017, at 11:33 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear All,
perhaps this new draft may is of interest to you.
Your comments, suggestions are most welcome and greatly appreciated.

Regards,
Greg

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, May 8, 2017 at 8:29 PM
Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt
To: Gregory Mirsky <gregimirsky@gmail.com>



A new version of I-D, draft-mirsky-spring-bfd-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-spring-bfd
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bidirectional Forwarding Detection= (BFD) in Segment Routing Networks Using MPLS Dataplane
Document date:=C2=A0 2017-05-08
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky-spring-bfd-00.t= xt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-mirsky-spring-bfd-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-mirsky-spring-bfd-00<= /a>


Abstract:
=C2=A0 =C2=A0Segment Routing architecture leverages the paradigm of source<= br> =C2=A0 =C2=A0routing.=C2=A0 It can be realized in the Multiprotocol Label S= witching
=C2=A0 =C2=A0(MPLS) network without any change to the data plane.=C2=A0 A s= egment is
=C2=A0 =C2=A0encoded as an MPLS label and an ordered list of segments is en= coded
=C2=A0 =C2=A0as a stack of labels.=C2=A0 Bidirectional Forwarding Detection= (BFD) is
=C2=A0 =C2=A0expected to monitor any kind of paths between systems.=C2=A0 T= his document
=C2=A0 =C2=A0defines how to use Label Switched Path Ping to bootstrap and c= ontrol
=C2=A0 =C2=A0path in reverse direction of a BFD session on the Segment Rout= ing
=C2=A0 =C2=A0network over MPLS dataplane.




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

The IETF Secretariat


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


--001a113d3ccc0918cc054f1974f7-- From nobody Tue May 9 09:07:28 2017 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 47FCC1294AC; Tue, 9 May 2017 09:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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.001, SPF_HELO_PASS=-0.001, 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 YFdLccWn6s2N; Tue, 9 May 2017 09:07:25 -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 2E92212420B; Tue, 9 May 2017 09:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15804; q=dns/txt; s=iport; t=1494346045; x=1495555645; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=z4kC/A4y1mfoT95b1XbYLX+H3rYIWFJpJ288HrXZ1QM=; b=gblv3Wg+qL95b0gVGi6OEQ2k2q6WmNFQyK9rW5+z3OXx23MYo4KWKg4I ZZorJmebo6pIqqqUFHMFA5ZFvjmxzfeK/igdCIgmNyJGPX4MYo9bb9V4b nBQgYXGyH3GG+Ks5pm5AzR0ep1x4RevNHS+WSUmarwAxZ1KAsq4Ua2Dx3 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AACA6BFZ/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHg2KKGJFWiCOIF4U4gg8hAQqFeAIahFI/GAECAQEBAQE?= =?us-ascii?q?BAWsohRUBAQEBAwEBIUsJAhACAQgRAQIBAigDAgICHwYLFAMGCAIEDgUbiW4DF?= =?us-ascii?q?Q6yVoImhy4NgzgBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhl+BXiuCcIJUTYElAQE?= =?us-ascii?q?7FgiCTC6CMQWJRIZehkuGXTsBhxuHKoRTggRVhGaKLIsqhHcog3YBDxA4gQpwF?= =?us-ascii?q?RwqEgGEKDkcgWN2AYZFgSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,315,1491264000"; d="scan'208,217";a="232756573" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 May 2017 16:07:23 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v49G7NWB019458 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 May 2017 16:07:23 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 9 May 2017 12:07: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.1210.000; Tue, 9 May 2017 12:07:22 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: "spring@ietf.org" , "rtg-bfd@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt Thread-Topic: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt Thread-Index: AQHSyNwl4f82jzKO5Eq8Ccd1kzJOwKHsbA8AgAAB9QA= Date: Tue, 9 May 2017 16:07:22 +0000 Message-ID: References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.52] Content-Type: multipart/alternative; boundary="_000_F3C093E0FE4E41C0B9EB0CA1CB52DBE7ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 09 May 2017 16:07:27 -0000 --_000_F3C093E0FE4E41C0B9EB0CA1CB52DBE7ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IEdyZWchDQoNClNpbmNlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1taXJza3ktc3ByaW5nLWJmZC0wMCBzZWVtcyBxdWl0ZSBzaW1pbGFyIHRvIHRoZSB0ZXh0IHJl bW92ZWQgYXQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1t cGxzLWJmZC1kaXJlY3RlZC0wNS50eHQsIHRoZW4gdGhlIGNvbXBsZXRlIHNldCBvZiBvdXRzdGFu ZGluZyB0ZWNobmljYWwgY29tbWVudHMgdGhhdCB0cmlnZ2VyZWQgdGhlIHJlbW92YWwgb2YgdGhh dCB0ZXh0IGZyb20gZHJhZnQtaWV0Zi1tcGxzLWJmZC1kaXJlY3RlZC0wNS50eHQgbWlnaHQgcGVl ayB5b3VyIGludGVyZXN0IDotKQ0KDQpPbmUgdGhhdCBJIHJlY2FsbCBpczogd2h5IHVzZSBsYWJl bCB2YWx1ZXMgd2hlbiBldmVyeSBvdGhlciByZXR1cm4tcGF0aCBzdWItVExWIGZvciBCRkQgYW5k IGZvciBMU1AtUGluZywgaW5jbHVkaW5nIGRyYWZ0LWlldGYtbXBscy1iZmQtZGlyZWN0ZWQsIHVz ZXMgVEZTcz8NCg0KQmVzdCwNCg0K4oCUIENhcmxvcy4NCg0KT24gTWF5IDksIDIwMTcsIGF0IDEy OjAwIFBNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1p cnNreUBnbWFpbC5jb20+PiB3cm90ZToNCg0KRGVhciBDYXJsb3MsDQpJJ3ZlIGRlY2lkZWQgdG8g cmUtc3RhcnQgdGhlIGRpc2N1c3Npb24gYW5kIGFtIGludGVyZXN0ZWQgdG8gaGVhciB0ZWNobmlj YWwgY29tbWVudHMgdG8gdGhlIHByb3Bvc2VkIHNvbHV0aW9uLg0KDQpSZWdhcmRzLA0KR3JlZw0K DQpPbiBUdWUsIE1heSA5LCAyMDE3IGF0IDg6NTEgQU0sIENhcmxvcyBQaWduYXRhcm8gKGNwaWdu YXRhKSA8Y3BpZ25hdGFAY2lzY28uY29tPG1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20+PiB3cm90 ZToNCkRlYXIgR3JlZywNCg0KQ3Vyc29yaWx5IHNjYW5uaW5nIHRocm91Z2ggdGhpcywgaXQgc2Vl bXMgdGhhdCBtb3N0IGNvbmNlcm5zIHJhaXNlZCBhbmQgY29tbWVudHMgbWFkZSBhYm91dCB0aGUg U1Igc2VjdGlvbnMgb2YgZHJhZnQtaWV0Zi1tcGxzLWJmZC1kaXJlY3RlZC0wTiAod2l0aCBOIDwg NSkgYXBwbHkgdG8geW91ciBuZXcgZHJhZnQuDQoNClRoaXMgaXMgb25lIG9mIHRob3NlOiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21wbHMvY3VycmVudC9tc2cxNTg2MC5o dG1sIOKAlCB0aGUgbGlzdCBhcmNoaXZlIHNob3dzIGEgZmV3IG1vcmUuIFRoZSBjb3B5L3Bhc3Rl IGRpZCBub3QgYWRkcmVzcyB0aGUgY29tbWVudHMuDQoNCkJlc3QsDQoNCuKAlCBDYXJsb3MuDQoN Ck9uIE1heSA4LCAyMDE3LCBhdCAxMTozMyBQTSwgR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdt YWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4gd3JvdGU6DQoNCkRlYXIgQWxs LA0KcGVyaGFwcyB0aGlzIG5ldyBkcmFmdCBtYXkgaXMgb2YgaW50ZXJlc3QgdG8geW91Lg0KWW91 ciBjb21tZW50cywgc3VnZ2VzdGlvbnMgYXJlIG1vc3Qgd2VsY29tZSBhbmQgZ3JlYXRseSBhcHBy ZWNpYXRlZC4NCg0KUmVnYXJkcywNCkdyZWcNCg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2Fn ZSAtLS0tLS0tLS0tDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0KRGF0ZTogTW9uLCBNYXkgOCwgMjAxNyBhdCA4OjI5IFBN DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1pcnNreS1zcHJp bmctYmZkLTAwLnR4dA0KVG86IEdyZWdvcnkgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb208 bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IEdyZWcgTWlyc2t5IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRv cnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1taXJza3ktc3ByaW5nLWJmZA0KUmV2aXNpb246 ICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVj dGlvbiAoQkZEKSBpbiBTZWdtZW50IFJvdXRpbmcgTmV0d29ya3MgVXNpbmcgTVBMUyBEYXRhcGxh bmUNCkRvY3VtZW50IGRhdGU6ICAyMDE3LTA1LTA4DQpHcm91cDogICAgICAgICAgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgNw0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1taXJza3ktc3ByaW5nLWJmZC0wMC50 eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1taXJza3ktc3ByaW5nLWJmZC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDANCkh0bWxpemVkOiAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LW1pcnNreS1zcHJpbmctYmZk LTAwDQoNCg0KQWJzdHJhY3Q6DQogICBTZWdtZW50IFJvdXRpbmcgYXJjaGl0ZWN0dXJlIGxldmVy YWdlcyB0aGUgcGFyYWRpZ20gb2Ygc291cmNlDQogICByb3V0aW5nLiAgSXQgY2FuIGJlIHJlYWxp emVkIGluIHRoZSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZw0KICAgKE1QTFMpIG5ldHdv cmsgd2l0aG91dCBhbnkgY2hhbmdlIHRvIHRoZSBkYXRhIHBsYW5lLiAgQSBzZWdtZW50IGlzDQog ICBlbmNvZGVkIGFzIGFuIE1QTFMgbGFiZWwgYW5kIGFuIG9yZGVyZWQgbGlzdCBvZiBzZWdtZW50 cyBpcyBlbmNvZGVkDQogICBhcyBhIHN0YWNrIG9mIGxhYmVscy4gIEJpZGlyZWN0aW9uYWwgRm9y d2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaXMNCiAgIGV4cGVjdGVkIHRvIG1vbml0b3IgYW55IGtp bmQgb2YgcGF0aHMgYmV0d2VlbiBzeXN0ZW1zLiAgVGhpcyBkb2N1bWVudA0KICAgZGVmaW5lcyBo b3cgdG8gdXNlIExhYmVsIFN3aXRjaGVkIFBhdGggUGluZyB0byBib290c3RyYXAgYW5kIGNvbnRy b2wNCiAgIHBhdGggaW4gcmV2ZXJzZSBkaXJlY3Rpb24gb2YgYSBCRkQgc2Vzc2lvbiBvbiB0aGUg U2VnbWVudCBSb3V0aW5nDQogICBuZXR3b3JrIG92ZXIgTVBMUyBkYXRhcGxhbmUuDQoNCg0KDQoN ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnLz4u DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1h aWx0bzptcGxzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzDQoNCg0KDQo= --_000_F3C093E0FE4E41C0B9EB0CA1CB52DBE7ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <9F15CA7F15AE9241B8FCFE110D7EACC6@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhhbmsgeW91IEdyZWchDQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5TaW5jZSA8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQt MDAiIGNsYXNzPSIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1pcnNreS1z cHJpbmctYmZkLTAwPC9hPiBzZWVtcyBxdWl0ZSBzaW1pbGFyIHRvIHRoZSB0ZXh0IHJlbW92ZWQg YXQNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtbXBscy1iZmQtZGlyZWN0ZWQtMDUudHh0IiBjbGFzcz0iIj4NCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbXBscy1iZmQtZGlyZWN0ZWQtMDUudHh0PC9h PiwgdGhlbiB0aGUgY29tcGxldGUgc2V0IG9mIG91dHN0YW5kaW5nIHRlY2huaWNhbCBjb21tZW50 cyB0aGF0IHRyaWdnZXJlZCB0aGUgcmVtb3ZhbCBvZiB0aGF0IHRleHQgZnJvbSBkcmFmdC1pZXRm LW1wbHMtYmZkLWRpcmVjdGVkLTA1LnR4dCBtaWdodCBwZWVrIHlvdXIgaW50ZXJlc3QgOi0pPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5P bmUgdGhhdCBJIHJlY2FsbCBpczogd2h5IHVzZSBsYWJlbCB2YWx1ZXMgd2hlbiBldmVyeSBvdGhl ciByZXR1cm4tcGF0aCBzdWItVExWIGZvciBCRkQgYW5kIGZvciBMU1AtUGluZywgaW5jbHVkaW5n IGRyYWZ0LWlldGYtbXBscy1iZmQtZGlyZWN0ZWQsIHVzZXMgVEZTcz8mbmJzcDs8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJlc3QsPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7i gJQgQ2FybG9zLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE1heSA5LCAy MDE3LCBhdCAxMjowMCBQTSwgR3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1p cnNreUBnbWFpbC5jb20iIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7IHdy b3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5EZWFyIENhcmxvcywNCjxkaXYgY2xh c3M9IiI+SSd2ZSBkZWNpZGVkIHRvIHJlLXN0YXJ0IHRoZSBkaXNjdXNzaW9uIGFuZCBhbSBpbnRl cmVzdGVkIHRvIGhlYXIgdGVjaG5pY2FsIGNvbW1lbnRzIHRvIHRoZSBwcm9wb3NlZCBzb2x1dGlv bi4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPlJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkdyZWc8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj5PbiBUdWUsIE1heSA5LCAyMDE3IGF0IDg6NTEgQU0sIENhcmxvcyBQaWduYXRh cm8gKGNwaWduYXRhKQ0KPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPiZsdDs8YSBocmVmPSJtYWls dG86Y3BpZ25hdGFAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+Y3BpZ25hdGFA Y2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0 OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFw OmJyZWFrLXdvcmQiIGNsYXNzPSIiPkRlYXIgR3JlZywNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkN1cnNvcmlseSBzY2FubmluZyB0aHJvdWdoIHRo aXMsIGl0IHNlZW1zIHRoYXQgbW9zdCBjb25jZXJucyByYWlzZWQgYW5kIGNvbW1lbnRzIG1hZGUg YWJvdXQgdGhlIFNSIHNlY3Rpb25zIG9mJm5ic3A7ZHJhZnQtaWV0Zi1tcGxzLWJmZC08d2JyIGNs YXNzPSIiPmRpcmVjdGVkLTBOICh3aXRoIE4gJmx0OyA1KSBhcHBseSB0byB5b3VyIG5ldyBkcmFm dC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlRoaXMgaXMgb25lIG9mIHRob3NlOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50L21zZzE1ODYwLmh0bWwiIHRhcmdldD0i X2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy88d2JyIGNsYXNzPSIiPm1haWwt YXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50Lzx3YnIgY2xhc3M9IiI+bXNnMTU4NjAuaHRtbDwvYT4g 4oCUIHRoZSBsaXN0IGFyY2hpdmUgc2hvd3MNCiBhIGZldyBtb3JlLiBUaGUgY29weS9wYXN0ZSBk aWQgbm90IGFkZHJlc3MgdGhlIGNvbW1lbnRzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QmVzdCw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlCBDYXJsb3MuPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJoNSI+DQo8 ZGl2IGNsYXNzPSIiPk9uIE1heSA4LCAyMDE3LCBhdCAxMTozMyBQTSwgR3JlZyBNaXJza3kgJmx0 OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBj bGFzcz0iIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBj bGFzcz0ibV80MTg3ODE3MTU1MzM0NjA3ODE3QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSJoNSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5EZWFyIEFsbCwNCjxkaXYgY2xhc3M9IiI+ cGVyaGFwcyB0aGlzIG5ldyBkcmFmdCBtYXkgaXMgb2YgaW50ZXJlc3QgdG8geW91LjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5Zb3VyIGNvbW1lbnRzLCBzdWdnZXN0aW9ucyBhcmUgbW9zdCB3ZWxjb21l IGFuZCBncmVhdGx5IGFwcHJlY2lhdGVkLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UmVnYXJkcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ R3JlZzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+LS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyIGNsYXNz PSIiPg0KRnJvbTogPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPjwvYj48c3BhbiBkaXI9Imx0 ciIgY2xhc3M9IiI+Jmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0 Ozwvc3Bhbj48YnIgY2xhc3M9IiI+DQpEYXRlOiBNb24sIE1heSA4LCAyMDE3IGF0IDg6MjkgUE08 YnIgY2xhc3M9IiI+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LW1pcnNreS1zcHJpbmctYmZkLTAwLnR4dDxiciBjbGFzcz0iIj4NClRvOiBHcmVnb3J5IE1pcnNr eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LW1pcnNreS1zcHJpbmctYmZkLTAwLnR4dDxiciBjbGFzcz0iIj4NCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR3JlZyBNaXJza3kgYW5kIHBvc3RlZCB0 byB0aGU8YnIgY2xhc3M9IiI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KTmFtZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Ry YWZ0LW1pcnNreS1zcHJpbmctYmZkPGJyIGNsYXNzPSIiPg0KUmV2aXNpb246Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7MDA8YnIgY2xhc3M9IiI+DQpUaXRsZTombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkg aW4gU2VnbWVudCBSb3V0aW5nIE5ldHdvcmtzIFVzaW5nIE1QTFMgRGF0YXBsYW5lPGJyIGNsYXNz PSIiPg0KRG9jdW1lbnQgZGF0ZTombmJzcDsgMjAxNy0wNS0wODxiciBjbGFzcz0iIj4NCkdyb3Vw OiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9u PGJyIGNsYXNzPSIiPg0KUGFnZXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA3 PGJyIGNsYXNzPSIiPg0KVVJMOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1t aXJza3ktc3ByaW5nLWJmZC0wMC50eHQiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtPHdiciBjbGFzcz0iIj5k cmFmdHMvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQ8d2JyIGNsYXNzPSIiPi0wMC50eHQ8L2E+PGJy IGNsYXNzPSIiPg0KU3RhdHVzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXJza3ktc3ByaW5n LWJmZC8iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvPHdiciBjbGFzcz0iIj5kb2MvZHJhZnQtbWlyc2t5LXNwcmlu Zy1iZmQvPC9hPjxiciBjbGFzcz0iIj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1taXJza3ktc3By aW5nLWJmZC0wMCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Q8d2JyIGNsYXNzPSIiPnJhZnQtbWlyc2t5LXNwcmlu Zy1iZmQtMDA8L2E+PGJyIGNsYXNzPSIiPg0KSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1taXJza3ktc3ByaW5nLWJmZC0wMCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy88d2JyIGNsYXNzPSIiPmRvYy9o dG1sL2RyYWZ0LW1pcnNreS1zcHJpbmctYjx3YnIgY2xhc3M9IiI+ZmQtMDA8L2E+PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQWJzdHJhY3Q6PGJyIGNsYXNzPSIi Pg0KJm5ic3A7ICZuYnNwO1NlZ21lbnQgUm91dGluZyBhcmNoaXRlY3R1cmUgbGV2ZXJhZ2VzIHRo ZSBwYXJhZGlnbSBvZiBzb3VyY2U8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7cm91dGluZy4m bmJzcDsgSXQgY2FuIGJlIHJlYWxpemVkIGluIHRoZSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRj aGluZzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsoTVBMUykgbmV0d29yayB3aXRob3V0IGFu eSBjaGFuZ2UgdG8gdGhlIGRhdGEgcGxhbmUuJm5ic3A7IEEgc2VnbWVudCBpczxiciBjbGFzcz0i Ij4NCiZuYnNwOyAmbmJzcDtlbmNvZGVkIGFzIGFuIE1QTFMgbGFiZWwgYW5kIGFuIG9yZGVyZWQg bGlzdCBvZiBzZWdtZW50cyBpcyBlbmNvZGVkPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2Fz IGEgc3RhY2sgb2YgbGFiZWxzLiZuYnNwOyBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0 aW9uIChCRkQpIGlzPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2V4cGVjdGVkIHRvIG1vbml0 b3IgYW55IGtpbmQgb2YgcGF0aHMgYmV0d2VlbiBzeXN0ZW1zLiZuYnNwOyBUaGlzIGRvY3VtZW50 PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2RlZmluZXMgaG93IHRvIHVzZSBMYWJlbCBTd2l0 Y2hlZCBQYXRoIFBpbmcgdG8gYm9vdHN0cmFwIGFuZCBjb250cm9sPGJyIGNsYXNzPSIiPg0KJm5i c3A7ICZuYnNwO3BhdGggaW4gcmV2ZXJzZSBkaXJlY3Rpb24gb2YgYSBCRkQgc2Vzc2lvbiBvbiB0 aGUgU2VnbWVudCBSb3V0aW5nPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO25ldHdvcmsgb3Zl ciBNUExTIGRhdGFwbGFuZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJy IGNsYXNzPSIiPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvIiByZWw9Im5vcmVmZXJyZXIi IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX188d2JyIGNsYXNzPSIiPl9f X19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KbXBscyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9 IiI+DQo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNz PSIiPm1wbHNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyIGNsYXNzPSIiPmxpc3RpbmZvL21wbHM8 L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F3C093E0FE4E41C0B9EB0CA1CB52DBE7ciscocom_-- From nobody Tue May 9 12:43:59 2017 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 25C1A1295A0; Tue, 9 May 2017 12:43: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, 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 ye9bWEJv03xO; Tue, 9 May 2017 12:43:55 -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 9C79D129477; Tue, 9 May 2017 12:43:55 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id l18so12511189oig.2; Tue, 09 May 2017 12:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HfyriXuk6qw3zG8RgGrsFjfIh4fDS3nL7fTX9iZc1Sw=; b=X+Syb4gHHVzNyfs4UZWIX7jx0oajICpwjq80hQHnIAsQcaEtLIy7p1L8bffnv3OqTO xfgwIGIS6rBtNRVlw/+vcVfmYNWPuaYqzgy6nnsoGjEcYunPhVkZCIDx8CEblpGuaN4G IZd4n4k0h8EMhKG9DBBjfgG7s2E/PgHHjicWvvib6suUrJ2w7t+/OnyhAs62OSniFjzv MriMpqdu2f/WHRT2cizbEWyUrqabiv5kbheTWmSCYeuwqRxb5c7eTHMJMh9YoGlKIJ8B A2VxKn3TtIlb00pvJA6ZLuXAzItODp45/CBMSMjLRyYU+w/LVNLXwnPprlRMFrNHx2Pc KDsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HfyriXuk6qw3zG8RgGrsFjfIh4fDS3nL7fTX9iZc1Sw=; b=lotx8monuhdUj0vmICRQjW0r3Lufrzc3da1K5+i+2rE0soohl1PEVerHZ4iIOk9Aol wkRSCQ0QoUf64ZrS9rn+ilp+hxjPE28MPKQq3yajtzXi/OF+ehnpmzuBefsGFcZYCwxZ Act+pfPGKBhXQQkEUHI5BvYSL9FPqpS1lq4PaLrUwPZkOiLaRoSVzrprMDCRaXucoaV4 BPa/djTlVhhwrMwXh4NbQZU85FZxnOC1k8E7cKqkxE7kmtv4gTQmnBBNkNH/K+DzmsIE gkexet8nrGieAfNQyr6treX9NQnFE8jmSwPSq9fYqKp78GMBDj504D+rqZ6GQOOnYK95 /Flw== X-Gm-Message-State: AODbwcAhctKVefbI4VxF/050WzLeAdX/1Sa9F3JqT2lM2oYnor4OlNT0 y93gxtF9NmAhGgzTDgyeKqjiI9f98g== X-Received: by 10.202.198.208 with SMTP id w199mr708191oif.115.1494359034868; Tue, 09 May 2017 12:43:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.246 with HTTP; Tue, 9 May 2017 12:43:54 -0700 (PDT) In-Reply-To: References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> From: Greg Mirsky Date: Tue, 9 May 2017 12:43:54 -0700 Message-ID: Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt To: "Carlos Pignataro (cpignata)" Cc: "spring@ietf.org" , "rtg-bfd@ietf.org" , "mpls@ietf.org" Content-Type: multipart/alternative; boundary=001a1134fbb470c137054f1c9329 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 09 May 2017 19:43:58 -0000 --001a1134fbb470c137054f1c9329 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, I probably would characterize anything that starts with Why not as a technical comment but rather as a question. According to draft-ietf-spring-segment-routing-mpls, "In the MPLS dataplane= ,the SR header is instantiated through a label stack". At the same time, one of advantages of SR is that "per-flow state only [maintained] at the ingress node to the SR domain". Thus, for the case of monitoring unidirectional SR tunnels, I consider that there's no need to create any additional state on the egress node. Of course, if there were bidirectional SR tunnels, then control of the reverse direction of the BFD session would not require use of the Return Path sub-TLV. As for LSP-Ping, I just propose that the Segment Routing MPLS Tunnel sub-TLV MAY be used Reply Path TLV defined in RFC 7110. I viewed the proposal as invitation to technical discussion. Regards, Greg On Tue, May 9, 2017 at 9:07 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Thank you Greg! > > Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems quite > similar to the text removed at https://tools.ietf.org/ > rfcdiff?url2=3Ddraft-ietf-mpls-bfd-directed-05.txt, then the complete set > of outstanding technical comments that triggered the removal of that text > from draft-ietf-mpls-bfd-directed-05.txt might peek your interest :-) > > One that I recall is: why use label values when every other return-path > sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-directed, > uses TFSs? > > Best, > > =E2=80=94 Carlos. > > On May 9, 2017, at 12:00 PM, Greg Mirsky wrote: > > Dear Carlos, > I've decided to re-start the discussion and am interested to hear > technical comments to the proposed solution. > > Regards, > Greg > > On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Dear Greg, >> >> Cursorily scanning through this, it seems that most concerns raised and >> comments made about the SR sections of draft-ietf-mpls-bfd-directed-0N >> (with N < 5) apply to your new draft. >> >> This is one of those: https://www.ietf.org/ma >> il-archive/web/mpls/current/msg15860.html =E2=80=94 the list archive sho= ws a few >> more. The copy/paste did not address the comments. >> >> Best, >> >> =E2=80=94 Carlos. >> >> On May 8, 2017, at 11:33 PM, Greg Mirsky wrote: >> >> Dear All, >> perhaps this new draft may is of interest to you. >> Your comments, suggestions are most welcome and greatly appreciated. >> >> Regards, >> Greg >> >> ---------- Forwarded message ---------- >> From: >> Date: Mon, May 8, 2017 at 8:29 PM >> Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt >> To: Gregory Mirsky >> >> >> >> A new version of I-D, draft-mirsky-spring-bfd-00.txt >> has been successfully submitted by Greg Mirsky and posted to the >> IETF repository. >> >> Name: draft-mirsky-spring-bfd >> Revision: 00 >> Title: Bidirectional Forwarding Detection (BFD) in Segment >> Routing Networks Using MPLS Dataplane >> Document date: 2017-05-08 >> Group: Individual Submission >> Pages: 7 >> URL: https://www.ietf.org/internet- >> drafts/draft-mirsky-spring-bfd-00.txt >> Status: https://datatracker.ietf.org/doc/draft-mirsky-spring-bfd= / >> Htmlized: https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 >> Htmlized: https://datatracker.ietf.org/ >> doc/html/draft-mirsky-spring-bfd-00 >> >> >> Abstract: >> Segment Routing architecture leverages the paradigm of source >> routing. It can be realized in the Multiprotocol Label Switching >> (MPLS) network without any change to the data plane. A segment is >> encoded as an MPLS label and an ordered list of segments is encoded >> as a stack of labels. Bidirectional Forwarding Detection (BFD) is >> expected to monitor any kind of paths between systems. This document >> defines how to use Label Switched Path Ping to bootstrap and control >> path in reverse direction of a BFD session on the Segment Routing >> network over MPLS dataplane. >> >> >> >> >> 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 >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> > > --001a1134fbb470c137054f1c9329 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carlos,
I probably would characterize anything that= starts with Why not as a technical comment but rather as a question.
=
According to=C2=A0draft-ietf-spring= -segment-routing-mpls, "In the MPLS=C2=A0dataplane,the SR header is insta= ntiated through a label stack".
At the same time, one of advantages of SR is that &qu= ot;per-flow state only [maintained] at the ingress node to th= e SR=C2=A0domain".
Thus, for the case of monitoring unid= irectional SR tunnels, I consider that there's no need to create any ad= ditional state on the egress node.
Of course, if there were bidirectional S= R tunnels, then control of the reverse direction of the BFD session would n= ot require use of the Return Path sub-TLV.
As for LSP-Ping, I just propose = that the Segment Routing MPLS Tunnel sub-TLV MAY be used Reply Path TLV def= ined in RFC 7110. I viewed the proposal as invitation to technical discussi= on.

Regards,
Greg
=
On Tue, May 9, 2017 at 9:07 AM, Carlos Pigna= taro (cpignata) <cpignata@cisco.com> wrote:
Thank you Greg!

Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems quite= similar to the text removed at https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-bfd-directe= d-05.txt, then the complete set of outstanding technical comments that = triggered the removal of that text from draft-ietf-mpls-bfd-directed-0= 5.txt might peek your interest :-)

One that I recall is: why use label values when every other return-pat= h sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-directed,= uses TFSs?=C2=A0

Best,

=E2=80=94 Carlos.

On May 9, 2017, at 12:00 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear Carlos,
I've decided to re-start the discussion and am interested to hear = technical comments to the proposed solution.=C2=A0

Regards,
Greg

On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro= (cpignata) <cpignata@cisco.com> wrote:
Dear Greg,

Cursorily scanning through this, it seems that most concerns raised an= d comments made about the SR sections of=C2=A0draft-ietf-mpls-bfd-directed-0N (with N < 5) apply to your new draft.

This is one of those:=C2=A0https://www.ietf.org/ma= il-archive/web/mpls/current/msg15860.html =E2=80=94 the list = archive shows a few more. The copy/paste did not address the comments.

Best,

=E2=80=94 Carlos.

On May 8, 2017, at 11:33 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear All,
perhaps this new draft may is of interest to you.
Your comments, suggestions are most welcome and greatly appreciated.

Regards,
Greg

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, May 8, 2017 at 8:29 PM
Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt
To: Gregory Mirsky <gregimirsky@gmail.com>



A new version of I-D, draft-mirsky-spring-bfd-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-spring-bfd
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bidirectional Forwarding Detection= (BFD) in Segment Routing Networks Using MPLS Dataplane
Document date:=C2=A0 2017-05-08
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky-spring-bfd-00.t= xt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-mirsky-spring-bfd-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-mirsky-spring-bfd-00<= /a>


Abstract:
=C2=A0 =C2=A0Segment Routing architecture leverages the paradigm of source<= br> =C2=A0 =C2=A0routing.=C2=A0 It can be realized in the Multiprotocol Label S= witching
=C2=A0 =C2=A0(MPLS) network without any change to the data plane.=C2=A0 A s= egment is
=C2=A0 =C2=A0encoded as an MPLS label and an ordered list of segments is en= coded
=C2=A0 =C2=A0as a stack of labels.=C2=A0 Bidirectional Forwarding Detection= (BFD) is
=C2=A0 =C2=A0expected to monitor any kind of paths between systems.=C2=A0 T= his document
=C2=A0 =C2=A0defines how to use Label Switched Path Ping to bootstrap and c= ontrol
=C2=A0 =C2=A0path in reverse direction of a BFD session on the Segment Rout= ing
=C2=A0 =C2=A0network over MPLS dataplane.




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

The IETF Secretariat


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




--001a1134fbb470c137054f1c9329-- From nobody Wed May 10 12:25:09 2017 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 A37E412EA74; Wed, 10 May 2017 12:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 E2Z4OsZlgIrf; Wed, 10 May 2017 12:25:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF1512EA6A; Wed, 10 May 2017 12:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23734; q=dns/txt; s=iport; t=1494444305; x=1495653905; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3D8DG/LRuhURy/OPI+AudnyFtFyljp+M1x7zxnWErYI=; b=FQXwhcAII5q1wD1SGe51vDoBEeiUogbmvoWCKehc4oB8qMfgm9+JDkuW 7z9zno/Gazp5ZVVD54i6l+TwmG54Ion+1g9soP9R1SyTd1bldKlHi/LDS sBN232QN9LNi8/6quNGDNT3sIUrfhvDXkA1p4C1+PN1Uf7nfRNlqYuaZD 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BUAQC4aBNZ/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoEMB4NiihiRNyGII4gXhTiCDyEBCoV4AhqEZj8YAQIBAQE?= =?us-ascii?q?BAQEBayiFFQEBAQEDAQEhSwkCEAIBCBEBAgECKAMCAgIfBgsUAwYIAgQOBRuJb?= =?us-ascii?q?gMVDrJVgiaHMA2DOAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GX4FeKwuCZYJUTYE?= =?us-ascii?q?lAQE7FgiCUC+CMQWJRIZehk2GYDsBhxuHLIRTggRVhGaKLIsthHcog3YBDxA4g?= =?us-ascii?q?QpwFRwqEgGEKjkcgWN2AYZqgSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,320,1491264000"; d="scan'208,217";a="243726006" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 May 2017 19:24:53 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v4AJOrxW014129 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 May 2017 19:24:53 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 10 May 2017 15:24: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.1210.000; Wed, 10 May 2017 15:24:52 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: "spring@ietf.org" , "rtg-bfd@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt Thread-Topic: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt Thread-Index: AQHSyNwl4f82jzKO5Eq8Ccd1kzJOwKHsbA8AgAAB9QCAADyAAIABjQKA Date: Wed, 10 May 2017 19:24:52 +0000 Message-ID: <9D886964-6C21-427C-8733-7731D5A996D3@cisco.com> References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.52] Content-Type: multipart/alternative; boundary="_000_9D8869646C21427C87337731D5A996D3ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 10 May 2017 19:25:09 -0000 --_000_9D8869646C21427C87337731D5A996D3ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZywNCg0KSW4gdGhlIE1QTFMgZGF0YSBwbGFuZSwgRkVDcyBhcmUgYWxzbyBpbnN0YW50aWF0 ZWQgdGhyb3VnaCBhIGxhYmVsIHN0YWNrLiBCdXQgUkZDIDcxMTAgZG9lcyBub3QgdXNlIG51bWVy aWMgbGFiZWwgdmFsdWVzLCBpdCB1c2VzIFRGU3MuIFRoYXQgZG9lcyBub3QgY3JlYXRlIGFueSBh ZGRpdGlvbmFsIHN0YXRlLiBFLmcuLDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9tcGxzL2N1cnJlbnQvbXNnMTYwOTEuaHRtbA0KDQpUaGFua3MsDQoNCuKAlCBDYXJsb3Mu DQoNCg0KDQpPbiBNYXkgOSwgMjAxNywgYXQgMzo0MyBQTSwgR3JlZyBNaXJza3kgPGdyZWdpbWly c2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4gd3JvdGU6DQoNCkhp IENhcmxvcywNCkkgcHJvYmFibHkgd291bGQgY2hhcmFjdGVyaXplIGFueXRoaW5nIHRoYXQgc3Rh cnRzIHdpdGggV2h5IG5vdCBhcyBhIHRlY2huaWNhbCBjb21tZW50IGJ1dCByYXRoZXIgYXMgYSBx dWVzdGlvbi4NCkFjY29yZGluZyB0byBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmct bXBscywgIkluIHRoZSBNUExTIGRhdGFwbGFuZSx0aGUgU1IgaGVhZGVyIGlzIGluc3RhbnRpYXRl ZCB0aHJvdWdoIGEgbGFiZWwgc3RhY2siLg0KQXQgdGhlIHNhbWUgdGltZSwgb25lIG9mIGFkdmFu dGFnZXMgb2YgU1IgaXMgdGhhdCAicGVyLWZsb3cgc3RhdGUgb25seSBbbWFpbnRhaW5lZF0gYXQg dGhlIGluZ3Jlc3Mgbm9kZSB0byB0aGUgU1IgZG9tYWluIi4NClRodXMsIGZvciB0aGUgY2FzZSBv ZiBtb25pdG9yaW5nIHVuaWRpcmVjdGlvbmFsIFNSIHR1bm5lbHMsIEkgY29uc2lkZXIgdGhhdCB0 aGVyZSdzIG5vIG5lZWQgdG8gY3JlYXRlIGFueSBhZGRpdGlvbmFsIHN0YXRlIG9uIHRoZSBlZ3Jl c3Mgbm9kZS4NCk9mIGNvdXJzZSwgaWYgdGhlcmUgd2VyZSBiaWRpcmVjdGlvbmFsIFNSIHR1bm5l bHMsIHRoZW4gY29udHJvbCBvZiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24gb2YgdGhlIEJGRCBzZXNz aW9uIHdvdWxkIG5vdCByZXF1aXJlIHVzZSBvZiB0aGUgUmV0dXJuIFBhdGggc3ViLVRMVi4NCkFz IGZvciBMU1AtUGluZywgSSBqdXN0IHByb3Bvc2UgdGhhdCB0aGUgU2VnbWVudCBSb3V0aW5nIE1Q TFMgVHVubmVsIHN1Yi1UTFYgTUFZIGJlIHVzZWQgUmVwbHkgUGF0aCBUTFYgZGVmaW5lZCBpbiBS RkMgNzExMC4gSSB2aWV3ZWQgdGhlIHByb3Bvc2FsIGFzIGludml0YXRpb24gdG8gdGVjaG5pY2Fs IGRpc2N1c3Npb24uDQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIFR1ZSwgTWF5IDksIDIwMTcgYXQg OTowNyBBTSwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIDxjcGlnbmF0YUBjaXNjby5jb208 bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+IHdyb3RlOg0KVGhhbmsgeW91IEdyZWchDQoNClNp bmNlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1taXJza3ktc3ByaW5nLWJmZC0w MCBzZWVtcyBxdWl0ZSBzaW1pbGFyIHRvIHRoZSB0ZXh0IHJlbW92ZWQgYXQgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tcGxzLWJmZC1kaXJlY3RlZC0wNS50 eHQsIHRoZW4gdGhlIGNvbXBsZXRlIHNldCBvZiBvdXRzdGFuZGluZyB0ZWNobmljYWwgY29tbWVu dHMgdGhhdCB0cmlnZ2VyZWQgdGhlIHJlbW92YWwgb2YgdGhhdCB0ZXh0IGZyb20gZHJhZnQtaWV0 Zi1tcGxzLWJmZC1kaXJlY3RlZC0wNS50eHQgbWlnaHQgcGVlayB5b3VyIGludGVyZXN0IDotKQ0K DQpPbmUgdGhhdCBJIHJlY2FsbCBpczogd2h5IHVzZSBsYWJlbCB2YWx1ZXMgd2hlbiBldmVyeSBv dGhlciByZXR1cm4tcGF0aCBzdWItVExWIGZvciBCRkQgYW5kIGZvciBMU1AtUGluZywgaW5jbHVk aW5nIGRyYWZ0LWlldGYtbXBscy1iZmQtZGlyZWN0ZWQsIHVzZXMgVEZTcz8NCg0KQmVzdCwNCg0K 4oCUIENhcmxvcy4NCg0KT24gTWF5IDksIDIwMTcsIGF0IDEyOjAwIFBNLCBHcmVnIE1pcnNreSA8 Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiB3cm90 ZToNCg0KRGVhciBDYXJsb3MsDQpJJ3ZlIGRlY2lkZWQgdG8gcmUtc3RhcnQgdGhlIGRpc2N1c3Np b24gYW5kIGFtIGludGVyZXN0ZWQgdG8gaGVhciB0ZWNobmljYWwgY29tbWVudHMgdG8gdGhlIHBy b3Bvc2VkIHNvbHV0aW9uLg0KDQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBUdWUsIE1heSA5LCAyMDE3 IGF0IDg6NTEgQU0sIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lzY28u Y29tPG1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20+PiB3cm90ZToNCkRlYXIgR3JlZywNCg0KQ3Vy c29yaWx5IHNjYW5uaW5nIHRocm91Z2ggdGhpcywgaXQgc2VlbXMgdGhhdCBtb3N0IGNvbmNlcm5z IHJhaXNlZCBhbmQgY29tbWVudHMgbWFkZSBhYm91dCB0aGUgU1Igc2VjdGlvbnMgb2YgZHJhZnQt aWV0Zi1tcGxzLWJmZC1kaXJlY3RlZC0wTiAod2l0aCBOIDwgNSkgYXBwbHkgdG8geW91ciBuZXcg ZHJhZnQuDQoNClRoaXMgaXMgb25lIG9mIHRob3NlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL21wbHMvY3VycmVudC9tc2cxNTg2MC5odG1sIOKAlCB0aGUgbGlzdCBhcmNo aXZlIHNob3dzIGEgZmV3IG1vcmUuIFRoZSBjb3B5L3Bhc3RlIGRpZCBub3QgYWRkcmVzcyB0aGUg Y29tbWVudHMuDQoNCkJlc3QsDQoNCuKAlCBDYXJsb3MuDQoNCk9uIE1heSA4LCAyMDE3LCBhdCAx MTozMyBQTSwgR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2lt aXJza3lAZ21haWwuY29tPj4gd3JvdGU6DQoNCkRlYXIgQWxsLA0KcGVyaGFwcyB0aGlzIG5ldyBk cmFmdCBtYXkgaXMgb2YgaW50ZXJlc3QgdG8geW91Lg0KWW91ciBjb21tZW50cywgc3VnZ2VzdGlv bnMgYXJlIG1vc3Qgd2VsY29tZSBhbmQgZ3JlYXRseSBhcHByZWNpYXRlZC4NCg0KUmVnYXJkcywN CkdyZWcNCg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQpGcm9tOiA8 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+ Pg0KRGF0ZTogTW9uLCBNYXkgOCwgMjAxNyBhdCA4OjI5IFBNDQpTdWJqZWN0OiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1pcnNreS1zcHJpbmctYmZkLTAwLnR4dA0KVG86IEdy ZWdvcnkgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb208bWFpbHRvOmdyZWdpbWlyc2t5QGdt YWlsLmNvbT4+DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWlyc2t5LXNwcmlu Zy1iZmQtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEdyZWcgTWly c2t5IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAg ICBkcmFmdC1taXJza3ktc3ByaW5nLWJmZA0KUmV2aXNpb246ICAgICAgIDAwDQpUaXRsZTogICAg ICAgICAgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBpbiBTZWdtZW50 IFJvdXRpbmcgTmV0d29ya3MgVXNpbmcgTVBMUyBEYXRhcGxhbmUNCkRvY3VtZW50IGRhdGU6ICAy MDE3LTA1LTA4DQpHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczog ICAgICAgICAgNw0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1taXJza3ktc3ByaW5nLWJmZC0wMC50eHQNClN0YXR1czogICAgICAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXJza3ktc3ByaW5nLWJmZC8N Ckh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWlyc2t5 LXNwcmluZy1iZmQtMDANCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL2RyYWZ0LW1pcnNreS1zcHJpbmctYmZkLTAwDQoNCg0KQWJzdHJhY3Q6DQog ICBTZWdtZW50IFJvdXRpbmcgYXJjaGl0ZWN0dXJlIGxldmVyYWdlcyB0aGUgcGFyYWRpZ20gb2Yg c291cmNlDQogICByb3V0aW5nLiAgSXQgY2FuIGJlIHJlYWxpemVkIGluIHRoZSBNdWx0aXByb3Rv Y29sIExhYmVsIFN3aXRjaGluZw0KICAgKE1QTFMpIG5ldHdvcmsgd2l0aG91dCBhbnkgY2hhbmdl IHRvIHRoZSBkYXRhIHBsYW5lLiAgQSBzZWdtZW50IGlzDQogICBlbmNvZGVkIGFzIGFuIE1QTFMg bGFiZWwgYW5kIGFuIG9yZGVyZWQgbGlzdCBvZiBzZWdtZW50cyBpcyBlbmNvZGVkDQogICBhcyBh IHN0YWNrIG9mIGxhYmVscy4gIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJG RCkgaXMNCiAgIGV4cGVjdGVkIHRvIG1vbml0b3IgYW55IGtpbmQgb2YgcGF0aHMgYmV0d2VlbiBz eXN0ZW1zLiAgVGhpcyBkb2N1bWVudA0KICAgZGVmaW5lcyBob3cgdG8gdXNlIExhYmVsIFN3aXRj aGVkIFBhdGggUGluZyB0byBib290c3RyYXAgYW5kIGNvbnRyb2wNCiAgIHBhdGggaW4gcmV2ZXJz ZSBkaXJlY3Rpb24gb2YgYSBCRkQgc2Vzc2lvbiBvbiB0aGUgU2VnbWVudCBSb3V0aW5nDQogICBu ZXR3b3JrIG92ZXIgTVBMUyBkYXRhcGxhbmUuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24N CnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v bHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnLz4uDQoNClRoZSBJRVRGIFNlY3JldGFy aWF0DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0KDQoNCg0K --_000_9D8869646C21427C87337731D5A996D3ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <92AE4598DFBA884C87A8535A0FE5500B@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KR3JlZywNCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkluIHRoZSBNUExTIGRhdGEgcGxh bmUsIEZFQ3MgYXJlIGFsc28gaW5zdGFudGlhdGVkIHRocm91Z2ggYSBsYWJlbCBzdGFjay4gQnV0 IFJGQyA3MTEwIGRvZXMgbm90IHVzZSBudW1lcmljIGxhYmVsIHZhbHVlcywgaXQgdXNlcyBURlNz LiBUaGF0IGRvZXMgbm90IGNyZWF0ZSBhbnkgYWRkaXRpb25hbCBzdGF0ZS4gRS5nLiw6Jm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tcGxzL2N1cnJl bnQvbXNnMTYwOTEuaHRtbCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9tcGxzL2N1cnJlbnQvbXNnMTYwOTEuaHRtbDwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyw8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlCBDYXJs b3MuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5P biBNYXkgOSwgMjAxNywgYXQgMzo0MyBQTSwgR3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0 bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5l Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5IaSBDYXJsb3MsDQo8 ZGl2IGNsYXNzPSIiPkkgcHJvYmFibHkgd291bGQgY2hhcmFjdGVyaXplIGFueXRoaW5nIHRoYXQg c3RhcnRzIHdpdGggV2h5IG5vdCBhcyBhIHRlY2huaWNhbCBjb21tZW50IGJ1dCByYXRoZXIgYXMg YSBxdWVzdGlvbi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QWNjb3JkaW5nIHRvJm5ic3A7PGZvbnQg ZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9 ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1MywgMjQ1KTsiIGNsYXNzPSIiPmQ8L3NwYW4+ PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1MywgMjQ1KTsiIGNsYXNz PSIiPnJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMsICZxdW90Ozwvc3Bhbj48 c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyIgY2xhc3M9 IiI+SW4NCiB0aGUgTVBMUyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogcmdiKDI1NSwgMjUzLCAyNDUpOyIgY2xhc3M9IiI+ZGF0YXBsYW5lLDwvc3Bhbj48c3BhbiBz dHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyIgY2xhc3M9IiI+dGhl IFNSIGhlYWRlciBpcyBpbnN0YW50aWF0ZWQgdGhyb3VnaCBhIGxhYmVsIHN0YWNrJnF1b3Q7Ljwv c3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9ImFyaWFsLCBoZWx2 ZXRpY2EsIHNhbnMtc2VyaWYiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9y OiByZ2IoMjU1LCAyNTMsIDI0NSk7IiBjbGFzcz0iIj5BdCB0aGUgc2FtZSB0aW1lLCBvbmUgb2Yg YWR2YW50YWdlcyBvZiBTUiBpcyB0aGF0ICZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iYmFja2dy b3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyBmb250LXNpemU6IDE0cHg7IiBjbGFzcz0i Ij5wZXItZmxvdw0KIHN0YXRlIG9ubHkgW21haW50YWluZWRdIGF0IHRoZSBpbmdyZXNzIG5vZGUg dG8gdGhlIFNSJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2Io MjU1LCAyNTMsIDI0NSk7IGZvbnQtc2l6ZTogMTRweDsiIGNsYXNzPSIiPmRvbWFpbiZxdW90Oy48 L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJhcmlhbCwgaGVs dmV0aWNhLCBzYW5zLXNlcmlmIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogcmdiKDI1NSwgMjUzLCAyNDUpOyBmb250LXNpemU6IDE0cHg7IiBjbGFzcz0iIj5UaHVzLCBm b3IgdGhlIGNhc2Ugb2YgbW9uaXRvcmluZyB1bmlkaXJlY3Rpb25hbCBTUiB0dW5uZWxzLCBJIGNv bnNpZGVyIHRoYXQgdGhlcmUncyBubyBuZWVkIHRvIGNyZWF0ZSBhbnkgYWRkaXRpb25hbA0KIHN0 YXRlIG9uIHRoZSBlZ3Jlc3Mgbm9kZS48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBjbGFzcz0iIj48c3Bh biBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyBmb250LXNpemU6 IDE0cHg7IiBjbGFzcz0iIj5PZiBjb3Vyc2UsIGlmIHRoZXJlIHdlcmUgYmlkaXJlY3Rpb25hbCBT UiB0dW5uZWxzLCB0aGVuIGNvbnRyb2wgb2YgdGhlIHJldmVyc2UgZGlyZWN0aW9uIG9mIHRoZSBC RkQgc2Vzc2lvbiB3b3VsZA0KIG5vdCByZXF1aXJlIHVzZSBvZiB0aGUgUmV0dXJuIFBhdGggc3Vi LVRMVi48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJhcmlh bCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyBmb250LXNpemU6IDE0cHg7IiBjbGFzcz0iIj5B cyBmb3IgTFNQLVBpbmcsIEkganVzdCBwcm9wb3NlIHRoYXQgdGhlIFNlZ21lbnQgUm91dGluZyBN UExTIFR1bm5lbCBzdWItVExWIE1BWSBiZSB1c2VkIFJlcGx5IFBhdGggVExWIGRlZmluZWQgaW4N CiBSRkMgNzExMC4gSSB2aWV3ZWQgdGhlIHByb3Bvc2FsIGFzIGludml0YXRpb24gdG8gdGVjaG5p Y2FsIGRpc2N1c3Npb24uPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQg ZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9 ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1MywgMjQ1KTsgZm9udC1zaXplOiAxNHB4OyIg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiIgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1MywgMjQ1KTsgZm9udC1zaXpl OiAxNHB4OyIgY2xhc3M9IiI+UmVnYXJkcyw8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBjbGFzcz0iIj48 c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyBmb250LXNp emU6IDE0cHg7IiBjbGFzcz0iIj5HcmVnPC9zcGFuPjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iZ21haWxfZXh0cmEiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj5PbiBUdWUsIE1heSA5LCAyMDE3IGF0IDk6MDcgQU0sIENhcmxvcyBQaWduYXRhcm8gKGNw aWduYXRhKQ0KPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPiZsdDs8YSBocmVmPSJtYWlsdG86Y3Bp Z25hdGFAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+Y3BpZ25hdGFAY2lzY28u Y29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNz PSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAj Y2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFr LXdvcmQiIGNsYXNzPSIiPlRoYW5rIHlvdSBHcmVnIQ0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U2luY2UgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LW1pcnNreS1zcHJpbmctYmZkLTAwIiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9IiI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvPHdiciBjbGFzcz0iIj5kcmFm dC1taXJza3ktc3ByaW5nLWJmZC0wMDwvYT4gc2VlbXMgcXVpdGUgc2ltaWxhciB0byB0aGUgdGV4 dCByZW1vdmVkIGF0DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLW1wbHMtYmZkLWRpcmVjdGVkLTA1LnR4dCIgdGFyZ2V0PSJfYmxhbmsiIGNs YXNzPSIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy88d2JyIGNsYXNzPSIiPnJmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLW1wbHMtPHdiciBjbGFzcz0iIj5iZmQtZGlyZWN0ZWQtMDUudHh0PC9hPiwg dGhlbiB0aGUgY29tcGxldGUgc2V0IG9mIG91dHN0YW5kaW5nIHRlY2huaWNhbCBjb21tZW50cyB0 aGF0IHRyaWdnZXJlZCB0aGUgcmVtb3ZhbCBvZiB0aGF0IHRleHQgZnJvbSBkcmFmdC1pZXRmLW1w bHMtYmZkLWRpcmVjdGVkLTx3YnIgY2xhc3M9IiI+MDUudHh0IG1pZ2h0DQogcGVlayB5b3VyIGlu dGVyZXN0IDotKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+T25lIHRoYXQgSSByZWNhbGwgaXM6IHdoeSB1c2UgbGFiZWwgdmFsdWVzIHdo ZW4gZXZlcnkgb3RoZXIgcmV0dXJuLXBhdGggc3ViLVRMViBmb3IgQkZEIGFuZCBmb3IgTFNQLVBp bmcsIGluY2x1ZGluZyBkcmFmdC1pZXRmLW1wbHMtYmZkLWRpcmVjdGVkLCB1c2VzIFRGU3M/Jm5i c3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5CZXN0LDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+4oCUIENhcmxvcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSJoNSI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gTWF5IDksIDIw MTcsIGF0IDEyOjAwIFBNLCBHcmVnIE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWly c2t5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJtXy00MjgwMjc0MTcwMDM4OTk4 OTAyQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9 Imx0ciIgY2xhc3M9IiI+RGVhciBDYXJsb3MsDQo8ZGl2IGNsYXNzPSIiPkkndmUgZGVjaWRlZCB0 byByZS1zdGFydCB0aGUgZGlzY3Vzc2lvbiBhbmQgYW0gaW50ZXJlc3RlZCB0byBoZWFyIHRlY2hu aWNhbCBjb21tZW50cyB0byB0aGUgcHJvcG9zZWQgc29sdXRpb24uJm5ic3A7PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5SZWdhcmRzLDwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5HcmVnPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWls X2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVHVlLCBN YXkgOSwgMjAxNyBhdCA4OjUxIEFNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkNCjxzcGFu IGRpcj0ibHRyIiBjbGFzcz0iIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmNwaWduYXRhQGNpc2NvLmNv bSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmNwaWduYXRhQGNpc2NvLmNvbTwvYT4mZ3Q7PC9z cGFuPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRk aW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIiBjbGFzcz0i Ij5EZWFyIEdyZWcsDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5DdXJzb3JpbHkgc2Nhbm5pbmcgdGhyb3VnaCB0aGlzLCBpdCBzZWVtcyB0aGF0IG1v c3QgY29uY2VybnMgcmFpc2VkIGFuZCBjb21tZW50cyBtYWRlIGFib3V0IHRoZSBTUiBzZWN0aW9u cyBvZiZuYnNwO2RyYWZ0LWlldGYtbXBscy1iZmQtZGlyZWN0ZTx3YnIgY2xhc3M9IiI+ZC0wTiAo d2l0aCBOICZsdDsgNSkgYXBwbHkgdG8geW91ciBuZXcgZHJhZnQuPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGlzIGlzIG9uZSBvZiB0 aG9zZTombmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L21wbHMvY3VycmVudC9tc2cxNTg2MC5odG1sIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWE8d2JyIGNsYXNzPSIiPmlsLWFyY2hpdmUvd2ViL21wbHMvY3Vy cmVudC9tczx3YnIgY2xhc3M9IiI+ZzE1ODYwLmh0bWw8L2E+IOKAlCB0aGUgbGlzdCBhcmNoaXZl IHNob3dzDQogYSBmZXcgbW9yZS4gVGhlIGNvcHkvcGFzdGUgZGlkIG5vdCBhZGRyZXNzIHRoZSBj b21tZW50cy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkJlc3QsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj7igJQgQ2FybG9zLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0ibV8tNDI4MDI3NDE3MDAzODk5ODkwMmg1Ij4N CjxkaXYgY2xhc3M9IiI+T24gTWF5IDgsIDIwMTcsIGF0IDExOjMzIFBNLCBHcmVnIE1pcnNreSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJy IGNsYXNzPSJtXy00MjgwMjc0MTcwMDM4OTk4OTAybV80MTg3ODE3MTU1MzM0NjA3ODE3QXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJtXy00MjgwMjc0MTcwMDM4OTk4OTAyaDUiPg0KPGRp diBkaXI9Imx0ciIgY2xhc3M9IiI+RGVhciBBbGwsDQo8ZGl2IGNsYXNzPSIiPnBlcmhhcHMgdGhp cyBuZXcgZHJhZnQgbWF5IGlzIG9mIGludGVyZXN0IHRvIHlvdS48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+WW91ciBjb21tZW50cywgc3VnZ2VzdGlvbnMgYXJlIG1vc3Qgd2VsY29tZSBhbmQgZ3JlYXRs eSBhcHByZWNpYXRlZC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPlJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkdyZWc8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPi0t LS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCkZyb206 IDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj48L2I+PHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIi PiZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDs8L3NwYW4+PGJy IGNsYXNzPSIiPg0KRGF0ZTogTW9uLCBNYXkgOCwgMjAxNyBhdCA4OjI5IFBNPGJyIGNsYXNzPSIi Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1taXJza3ktc3By aW5nLWJmZC0wMC50eHQ8YnIgY2xhc3M9IiI+DQpUbzogR3JlZ29yeSBNaXJza3kgJmx0OzxhIGhy ZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1taXJza3ktc3ByaW5nLWJmZC0wMC50eHQ8YnIgY2xhc3M9IiI+DQpoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEdyZWcgTWlyc2t5IGFuZCBwb3N0ZWQgdG8gdGhlPGJyIGNs YXNzPSIiPg0KSUVURiByZXBvc2l0b3J5LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5h bWU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1taXJza3kt c3ByaW5nLWJmZDxiciBjbGFzcz0iIj4NClJldmlzaW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzAwPGJyIGNsYXNzPSIiPg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIGluIFNlZ21lbnQg Um91dGluZyBOZXR3b3JrcyBVc2luZyBNUExTIERhdGFwbGFuZTxiciBjbGFzcz0iIj4NCkRvY3Vt ZW50IGRhdGU6Jm5ic3A7IDIwMTctMDUtMDg8YnIgY2xhc3M9IiI+DQpHcm91cDombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxiciBjbGFzcz0i Ij4NClBhZ2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgNzxiciBjbGFzcz0i Ij4NClVSTDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWlyc2t5LXNwcmlu Zy1iZmQtMDAudHh0IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LTx3YnIgY2xhc3M9IiI+ZHJhZnRzL2RyYWZ0 LW1pcnNreS1zcHJpbmctYmZkPHdiciBjbGFzcz0iIj4tMDAudHh0PC9hPjxiciBjbGFzcz0iIj4N ClN0YXR1czombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQvIiByZWw9 Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnLzx3YnIgY2xhc3M9IiI+ZG9jL2RyYWZ0LW1pcnNreS1zcHJpbmctYmZkLzwvYT48 YnIgY2xhc3M9IiI+DQpIdG1saXplZDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDAi IHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kPHdiciBjbGFzcz0iIj5yYWZ0LW1pcnNreS1zcHJpbmctYmZkLTAwPC9h PjxiciBjbGFzcz0iIj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbWlyc2t5LXNw cmluZy1iZmQtMDAiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvPHdiciBjbGFzcz0iIj5kb2MvaHRtbC9kcmFmdC1t aXJza3ktc3ByaW5nLWI8d2JyIGNsYXNzPSIiPmZkLTAwPC9hPjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFic3RyYWN0OjxiciBjbGFzcz0iIj4NCiZuYnNwOyAm bmJzcDtTZWdtZW50IFJvdXRpbmcgYXJjaGl0ZWN0dXJlIGxldmVyYWdlcyB0aGUgcGFyYWRpZ20g b2Ygc291cmNlPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO3JvdXRpbmcuJm5ic3A7IEl0IGNh biBiZSByZWFsaXplZCBpbiB0aGUgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmc8YnIgY2xh c3M9IiI+DQombmJzcDsgJm5ic3A7KE1QTFMpIG5ldHdvcmsgd2l0aG91dCBhbnkgY2hhbmdlIHRv IHRoZSBkYXRhIHBsYW5lLiZuYnNwOyBBIHNlZ21lbnQgaXM8YnIgY2xhc3M9IiI+DQombmJzcDsg Jm5ic3A7ZW5jb2RlZCBhcyBhbiBNUExTIGxhYmVsIGFuZCBhbiBvcmRlcmVkIGxpc3Qgb2Ygc2Vn bWVudHMgaXMgZW5jb2RlZDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDthcyBhIHN0YWNrIG9m IGxhYmVscy4mbmJzcDsgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBp czxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtleHBlY3RlZCB0byBtb25pdG9yIGFueSBraW5k IG9mIHBhdGhzIGJldHdlZW4gc3lzdGVtcy4mbmJzcDsgVGhpcyBkb2N1bWVudDxiciBjbGFzcz0i Ij4NCiZuYnNwOyAmbmJzcDtkZWZpbmVzIGhvdyB0byB1c2UgTGFiZWwgU3dpdGNoZWQgUGF0aCBQ aW5nIHRvIGJvb3RzdHJhcCBhbmQgY29udHJvbDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtw YXRoIGluIHJldmVyc2UgZGlyZWN0aW9uIG9mIGEgQkZEIHNlc3Npb24gb24gdGhlIFNlZ21lbnQg Um91dGluZzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtuZXR3b3JrIG92ZXIgTVBMUyBkYXRh cGxhbmUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxiciBjbGFzcz0iIj4N CnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnLyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+DQp0b29scy5pZXRmLm9yZzwvYT4uPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdiciBjbGFzcz0iIj5fX19fX19fX19fX19f X19fXzxiciBjbGFzcz0iIj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJl Zj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5tcGxzQGll dGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbDx3YnIgY2xhc3M9IiI+aXN0aW5mby9tcGxzPC9hPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9D8869646C21427C87337731D5A996D3ciscocom_-- From nobody Wed May 10 12:40:06 2017 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 6C03212EAA9; Wed, 10 May 2017 12:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXqbqfTtI3zp; Wed, 10 May 2017 12:40:01 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001: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 75846128AB0; Wed, 10 May 2017 12:40:01 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id p24so8470949ioi.0; Wed, 10 May 2017 12:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qKK7klzpm+jnKD+cec9LqksoIPnUCyWGgItAqrfhbsk=; b=ZRhjgC/gZjqYCe9XeHX2R4WlFbWOV0tH72jP8Vl2siuki5IJEUFEXFBgXsa8GjdSQz Rgpt6w+NbL3T5+CAEHbdEhWD6Afpij2fUKPY1ucU0qhmiGivE/byCQNTzGJGE6QzVGyb 3CUMg04ViAzw1bGoOp5a/WwgntZlXPhVUwwI0A67q/tbyJdsUEjw6Wl/M2g72sfzonto GVfE7/8KRPn8Wvv3sbTyCBbF6uPpE2h2KtYRaR1o8jfZJomnJq2YBnn264fKd6lqzoz4 oPg3uR0KUoHGYi7SrJMGZX9qTBNvFTOMHRO+8OT9IU9iZ9X5LXvSqo78JaX1FuLsU8ai y1gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=qKK7klzpm+jnKD+cec9LqksoIPnUCyWGgItAqrfhbsk=; b=r2javusmoOBpkIoS8Y2tFKemotHipk4hseNjC0YKqO9a4oP6+xUPDFfjPdzcRmh0w8 j491VJ+HDfbCALJPxzAsbOdmWm2hLIcXOvl/Cxc3CXlHEbRS+3agg3M1fVr0bCYTQJDS 1bV2Hh77Q2SJThvflm1DfRq4+0avOhoXCmmox4IlzAXbhDzNEZQZG+pTs8yv6IK2mwYa JK+sr63PuPlVkNkiLjgc7gFKxcicOZFL14X5kHMK6fokdCU0b+qaCkz9BuH72K/cNwuo z/JdmN2Utoua8VKWJvzb1yy5JXsI56gQU9mPHX2UBNb/szHQ2JN1YTTGE5QuXGUvaMoE Gmjw== X-Gm-Message-State: AODbwcCJCJ/OM/ashqL16ZThZGtbgsuPqpkVyEsUmBjXLzOiZcAtj4Yl WHFmiN6ymCtMxpus9i5mOCB6OuzDyQ== X-Received: by 10.107.205.132 with SMTP id d126mr5071044iog.155.1494445200753; Wed, 10 May 2017 12:40:00 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.62.24 with HTTP; Wed, 10 May 2017 12:40:00 -0700 (PDT) In-Reply-To: <9D886964-6C21-427C-8733-7731D5A996D3@cisco.com> References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> <9D886964-6C21-427C-8733-7731D5A996D3@cisco.com> From: Robert Raszuk Date: Wed, 10 May 2017 21:40:00 +0200 X-Google-Sender-Auth: x_PauMqsKG4nRRs352gzM0YQgdI Message-ID: Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt To: "Carlos Pignataro (cpignata)" Cc: Greg Mirsky , "mpls@ietf.org" , "spring@ietf.org" , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c18871853f0c7054f30a3b7 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 10 May 2017 19:40:04 -0000 --94eb2c18871853f0c7054f30a3b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, Sorry what is "TFS" ? RFC 7110 does not even use such abbreviation neither do draft-ietf-mpls-bfd-directed :) Google also seems to be pretty clueless about it. Just curious as you keep using this term in each email :) Thx, R. On Wed, May 10, 2017 at 9:24 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Greg, > > In the MPLS data plane, FECs are also instantiated through a label stack. > But RFC 7110 does not use numeric label values, it uses TFSs. That does n= ot > create any additional state. E.g.,: https://www.ietf.org/ > mail-archive/web/mpls/current/msg16091.html > > Thanks, > > =E2=80=94 Carlos. > > > > On May 9, 2017, at 3:43 PM, Greg Mirsky wrote: > > Hi Carlos, > I probably would characterize anything that starts with Why not as a > technical comment but rather as a question. > According to draft-ietf-spring-segment-routing-mpls, "In the MPLS > dataplane,the SR header is instantiated through a label stack". > At the same time, one of advantages of SR is that "per-flow state only > [maintained] at the ingress node to the SR domain". > Thus, for the case of monitoring unidirectional SR tunnels, I consider > that there's no need to create any additional state on the egress node. > Of course, if there were bidirectional SR tunnels, then control of the > reverse direction of the BFD session would not require use of the Return > Path sub-TLV. > As for LSP-Ping, I just propose that the Segment Routing MPLS Tunnel > sub-TLV MAY be used Reply Path TLV defined in RFC 7110. I viewed the > proposal as invitation to technical discussion. > > Regards, > Greg > > On Tue, May 9, 2017 at 9:07 AM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Thank you Greg! >> >> Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems quite >> similar to the text removed at https://tools.ietf.org/rfcdiff >> ?url2=3Ddraft-ietf-mpls-bfd-directed-05.txt, then the complete set of >> outstanding technical comments that triggered the removal of that text f= rom >> draft-ietf-mpls-bfd-directed-05.txt might peek your interest :-) >> >> One that I recall is: why use label values when every other return-path >> sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-directed= , >> uses TFSs? >> >> Best, >> >> =E2=80=94 Carlos. >> >> On May 9, 2017, at 12:00 PM, Greg Mirsky wrote: >> >> Dear Carlos, >> I've decided to re-start the discussion and am interested to hear >> technical comments to the proposed solution. >> >> Regards, >> Greg >> >> On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro (cpignata) < >> cpignata@cisco.com> wrote: >> >>> Dear Greg, >>> >>> Cursorily scanning through this, it seems that most concerns raised and >>> comments made about the SR sections of draft-ietf-mpls-bfd-directed-0N >>> (with N < 5) apply to your new draft. >>> >>> This is one of those: https://www.ietf.org/ma >>> il-archive/web/mpls/current/msg15860.html =E2=80=94 the list archive sh= ows a >>> few more. The copy/paste did not address the comments. >>> >>> Best, >>> >>> =E2=80=94 Carlos. >>> >>> On May 8, 2017, at 11:33 PM, Greg Mirsky wrote: >>> >>> Dear All, >>> perhaps this new draft may is of interest to you. >>> Your comments, suggestions are most welcome and greatly appreciated. >>> >>> Regards, >>> Greg >>> >>> ---------- Forwarded message ---------- >>> From: >>> Date: Mon, May 8, 2017 at 8:29 PM >>> Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt >>> To: Gregory Mirsky >>> >>> >>> >>> A new version of I-D, draft-mirsky-spring-bfd-00.txt >>> has been successfully submitted by Greg Mirsky and posted to the >>> IETF repository. >>> >>> Name: draft-mirsky-spring-bfd >>> Revision: 00 >>> Title: Bidirectional Forwarding Detection (BFD) in Segment >>> Routing Networks Using MPLS Dataplane >>> Document date: 2017-05-08 >>> Group: Individual Submission >>> Pages: 7 >>> URL: https://www.ietf.org/internet- >>> drafts/draft-mirsky-spring-bfd-00.txt >>> Status: https://datatracker.ietf.org/ >>> doc/draft-mirsky-spring-bfd/ >>> Htmlized: https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 >>> Htmlized: https://datatracker.ietf.org/ >>> doc/html/draft-mirsky-spring-bfd-00 >>> >>> >>> Abstract: >>> Segment Routing architecture leverages the paradigm of source >>> routing. It can be realized in the Multiprotocol Label Switching >>> (MPLS) network without any change to the data plane. A segment is >>> encoded as an MPLS label and an ordered list of segments is encoded >>> as a stack of labels. Bidirectional Forwarding Detection (BFD) is >>> expected to monitor any kind of paths between systems. This documen= t >>> defines how to use Label Switched Path Ping to bootstrap and control >>> path in reverse direction of a BFD session on the Segment Routing >>> network over MPLS dataplane. >>> >>> >>> >>> >>> 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 >>> >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> >>> >> >> > > --94eb2c18871853f0c7054f30a3b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carlos,

=
Sorry what is "TFS" ?=C2=A0

RFC 7110 does not even use such ab= breviation neither do=C2=A0draft-ietf-mpls-bfd-directed=C2=A0:) Google also seems to= be pretty clueless about it.=C2=A0

Just curious as you keep using this term in each email :)=C2= =A0

Thx,
R.

On Wed, May 1= 0, 2017 at 9:24 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com&g= t; wrote:
Greg,

In the MPLS data plane, FECs are also instantiated through a label sta= ck. But RFC 7110 does not use numeric label values, it uses TFSs. That does= not create any additional state. E.g.,:=C2=A0https://w= ww.ietf.org/mail-archive/web/mpls/current/msg16091.html

Thanks,

=E2=80=94 Carlos.



On May 9, 2017, at 3:43 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Carlos,
I probably would characterize anything that starts with Why not as a t= echnical comment but rather as a question.
According to=C2=A0draft-ietf-spring-segment-routing-mpls, "= In the MPLS=C2=A0dat= aplane,the SR head= er is instantiated through a label stack".
At the same time, one of advantages of SR is that &= quot;per-flow state only [maintained] at the ingress node to the SR=C2=A0domain".
Thus, for the case of monitoring uni= directional SR tunnels, I consider that there's no need to create any a= dditional state on the egress node.
Of course, if there were bidirection= al SR tunnels, then control of the reverse direction of the BFD session wou= ld not require use of the Return Path sub-TLV.
As for LSP-Ping, I just propose that= the Segment Routing MPLS Tunnel sub-TLV MAY be used Reply Path TLV defined= in RFC 7110. I viewed the proposal as invitation to technical discussion.

Regards,
Greg

On Tue, May 9, 2017 at 9:07 AM, Carlos Pignataro= (cpignata) <cpignata@cisco.com> wrote:
Thank you Greg!

Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems quite= similar to the text removed at https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-bfd-directe= d-05.txt, then the complete set of outstanding technical comments that = triggered the removal of that text from draft-ietf-mpls-bfd-directed-0= 5.txt might peek your interest :-)

One that I recall is: why use label values when every other return-pat= h sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-directed,= uses TFSs?=C2=A0

Best,

=E2=80=94 Carlos.

On May 9, 2017, at 12:00 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear Carlos,
I've decided to re-start the discussion and am interested to hear = technical comments to the proposed solution.=C2=A0

Regards,
Greg

On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro= (cpignata) <cpignata@cisco.com> wrote:
Dear Greg,

Cursorily scanning through this, it seems that most concerns raised an= d comments made about the SR sections of=C2=A0draft-ietf-mpls-bfd-directed-0N (with N < 5) apply to your new draft.

This is one of those:=C2=A0https://www.ietf.org/ma= il-archive/web/mpls/current/msg15860.html =E2=80=94 the list = archive shows a few more. The copy/paste did not address the comments.

Best,

=E2=80=94 Carlos.

On May 8, 2017, at 11:33 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear All,
perhaps this new draft may is of interest to you.
Your comments, suggestions are most welcome and greatly appreciated.

Regards,
Greg

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, May 8, 2017 at 8:29 PM
Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt
To: Gregory Mirsky <gregimirsky@gmail.com>



A new version of I-D, draft-mirsky-spring-bfd-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-spring-bfd
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bidirectional Forwarding Detection= (BFD) in Segment Routing Networks Using MPLS Dataplane
Document date:=C2=A0 2017-05-08
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky-spring-bfd-00.t= xt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-mirsky-spring-bfd-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-mirsky-spring-bfd-00<= /a>


Abstract:
=C2=A0 =C2=A0Segment Routing architecture leverages the paradigm of source<= br> =C2=A0 =C2=A0routing.=C2=A0 It can be realized in the Multiprotocol Label S= witching
=C2=A0 =C2=A0(MPLS) network without any change to the data plane.=C2=A0 A s= egment is
=C2=A0 =C2=A0encoded as an MPLS label and an ordered list of segments is en= coded
=C2=A0 =C2=A0as a stack of labels.=C2=A0 Bidirectional Forwarding Detection= (BFD) is
=C2=A0 =C2=A0expected to monitor any kind of paths between systems.=C2=A0 T= his document
=C2=A0 =C2=A0defines how to use Label Switched Path Ping to bootstrap and c= ontrol
=C2=A0 =C2=A0path in reverse direction of a BFD session on the Segment Rout= ing
=C2=A0 =C2=A0network over MPLS dataplane.




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

The IETF Secretariat


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






--94eb2c18871853f0c7054f30a3b7-- From nobody Wed May 10 12:42:05 2017 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 A7B2E12EAA9; Wed, 10 May 2017 12:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lllpogR1dOFy; Wed, 10 May 2017 12:42:01 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 090C6128AB0; Wed, 10 May 2017 12:42:01 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id e65so8022369ita.1; Wed, 10 May 2017 12:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=TEdy2bHd6L1ahTmEy06UhWRMlZCCotYRPJMjLgjKEJo=; b=UaenTSAALvQUyF3UJBal2YaGaapBUJlfECkV3jsw3nc1hfq9P4a2ZxKl5SfXr2gXON kDHnT5V0xiRVuGDKUoiQUG9kE0t+QUk4tlJYfZSAkzzLq6C+DoS7s8L0bXNsnzAEZash abWmB7JLGEemrnvVG6w76A3JYpfSXshfklYlIzhVtOke0kFlHo238YdKB7sZef0KLWIy S1QoxeEhrgNAQZAx2d0sTOE/dKSz1YDGDNpaMBpzcwGQ5JBqAq7zcfB6I2ONnXwFk0aC 1yFY1E9N3SCQFHsSJA6fOem/qVwGSFoAQfCdxCIVKjqnFA4w+CnNWQANd/fwzgpdgsMH OWpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=TEdy2bHd6L1ahTmEy06UhWRMlZCCotYRPJMjLgjKEJo=; b=QUVu4Cgim5lNObwoiU30/bHXMPN+XcUAMgzskXLKK9qBg+a24uPGOnSGt6pcnzX5yS hJnKzE/MMV79RYKCgzb6XkZU4H2gTSA6wXwQtxlH69eLVGAbEQv2BTWDzrIWHiLev7qN jW5ngOQ/fs/SAyasL3u4L6ZvjoASOtGK+UfQ/2Fp83lXYuJJ69EF8Pgr0rgbzjq0rT7H uPnNmAT3xtyfvI5orVeAKhidPndvL4PtkDcSd0OI7yXYFph5uMTIfKNYw7ZIs7/wYXob RM2hSelp8IdebQ6pkIQMYO58kA1ZKpk1R7My3lEaUmxQ6CI7pjyb6q2sFhRa18Oa6Xze c9OQ== X-Gm-Message-State: AODbwcC6eNm4zADE5aFBEDPSPHWEKdt3ufQL22adOWOoOt7txkwuIrzl gZKM/TWJb7kfEBkVdN2To0Kw5AHAX0Oot8w= X-Received: by 10.36.125.197 with SMTP id b188mr7099939itc.59.1494445320238; Wed, 10 May 2017 12:42:00 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.62.24 with HTTP; Wed, 10 May 2017 12:41:59 -0700 (PDT) In-Reply-To: References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> <9D886964-6C21-427C-8733-7731D5A996D3@cisco.com> From: Robert Raszuk Date: Wed, 10 May 2017 21:41:59 +0200 X-Google-Sender-Auth: rgwSCYFZFs41rD-zSR4UiCp2kpA Message-ID: Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt To: "Carlos Pignataro (cpignata)" Cc: Greg Mirsky , "mpls@ietf.org" , "spring@ietf.org" , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary=001a114043b0731de7054f30aa83 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 10 May 2017 19:42:03 -0000 --001a114043b0731de7054f30aa83 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Never mind .. I guess you made it up from "Target FEC Stack" :) On Wed, May 10, 2017 at 9:40 PM, Robert Raszuk wrote: > Hi Carlos, > > Sorry what is "TFS" ? > > RFC 7110 does not even use such abbreviation neither do > draft-ietf-mpls-bfd-directed :) Google also seems to be pretty clueless > about it. > > Just curious as you keep using this term in each email :) > > Thx, > R. > > On Wed, May 10, 2017 at 9:24 PM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Greg, >> >> In the MPLS data plane, FECs are also instantiated through a label stack= . >> But RFC 7110 does not use numeric label values, it uses TFSs. That does = not >> create any additional state. E.g.,: https://www.ietf.org/ma >> il-archive/web/mpls/current/msg16091.html >> >> Thanks, >> >> =E2=80=94 Carlos. >> >> >> >> On May 9, 2017, at 3:43 PM, Greg Mirsky wrote: >> >> Hi Carlos, >> I probably would characterize anything that starts with Why not as a >> technical comment but rather as a question. >> According to draft-ietf-spring-segment-routing-mpls, "In the MPLS >> dataplane,the SR header is instantiated through a label stack". >> At the same time, one of advantages of SR is that "per-flow state only >> [maintained] at the ingress node to the SR domain". >> Thus, for the case of monitoring unidirectional SR tunnels, I consider >> that there's no need to create any additional state on the egress node. >> Of course, if there were bidirectional SR tunnels, then control of the >> reverse direction of the BFD session would not require use of the Return >> Path sub-TLV. >> As for LSP-Ping, I just propose that the Segment Routing MPLS Tunnel >> sub-TLV MAY be used Reply Path TLV defined in RFC 7110. I viewed the >> proposal as invitation to technical discussion. >> >> Regards, >> Greg >> >> On Tue, May 9, 2017 at 9:07 AM, Carlos Pignataro (cpignata) < >> cpignata@cisco.com> wrote: >> >>> Thank you Greg! >>> >>> Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems >>> quite similar to the text removed at https://tools.ietf.org/rfcdiff >>> ?url2=3Ddraft-ietf-mpls-bfd-directed-05.txt, then the complete set of >>> outstanding technical comments that triggered the removal of that text = from >>> draft-ietf-mpls-bfd-directed-05.txt might peek your interest :-) >>> >>> One that I recall is: why use label values when every other return-path >>> sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-directe= d, >>> uses TFSs? >>> >>> Best, >>> >>> =E2=80=94 Carlos. >>> >>> On May 9, 2017, at 12:00 PM, Greg Mirsky wrote: >>> >>> Dear Carlos, >>> I've decided to re-start the discussion and am interested to hear >>> technical comments to the proposed solution. >>> >>> Regards, >>> Greg >>> >>> On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro (cpignata) < >>> cpignata@cisco.com> wrote: >>> >>>> Dear Greg, >>>> >>>> Cursorily scanning through this, it seems that most concerns raised an= d >>>> comments made about the SR sections of draft-ietf-mpls-bfd-directed-0N >>>> (with N < 5) apply to your new draft. >>>> >>>> This is one of those: https://www.ietf.org/ma >>>> il-archive/web/mpls/current/msg15860.html =E2=80=94 the list archive s= hows a >>>> few more. The copy/paste did not address the comments. >>>> >>>> Best, >>>> >>>> =E2=80=94 Carlos. >>>> >>>> On May 8, 2017, at 11:33 PM, Greg Mirsky wrote= : >>>> >>>> Dear All, >>>> perhaps this new draft may is of interest to you. >>>> Your comments, suggestions are most welcome and greatly appreciated. >>>> >>>> Regards, >>>> Greg >>>> >>>> ---------- Forwarded message ---------- >>>> From: >>>> Date: Mon, May 8, 2017 at 8:29 PM >>>> Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt >>>> To: Gregory Mirsky >>>> >>>> >>>> >>>> A new version of I-D, draft-mirsky-spring-bfd-00.txt >>>> has been successfully submitted by Greg Mirsky and posted to the >>>> IETF repository. >>>> >>>> Name: draft-mirsky-spring-bfd >>>> Revision: 00 >>>> Title: Bidirectional Forwarding Detection (BFD) in Segment >>>> Routing Networks Using MPLS Dataplane >>>> Document date: 2017-05-08 >>>> Group: Individual Submission >>>> Pages: 7 >>>> URL: https://www.ietf.org/internet- >>>> drafts/draft-mirsky-spring-bfd-00.txt >>>> Status: https://datatracker.ietf.org/ >>>> doc/draft-mirsky-spring-bfd/ >>>> Htmlized: https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 >>>> Htmlized: https://datatracker.ietf.org/ >>>> doc/html/draft-mirsky-spring-bfd-00 >>>> >>>> >>>> Abstract: >>>> Segment Routing architecture leverages the paradigm of source >>>> routing. It can be realized in the Multiprotocol Label Switching >>>> (MPLS) network without any change to the data plane. A segment is >>>> encoded as an MPLS label and an ordered list of segments is encoded >>>> as a stack of labels. Bidirectional Forwarding Detection (BFD) is >>>> expected to monitor any kind of paths between systems. This docume= nt >>>> defines how to use Label Switched Path Ping to bootstrap and contro= l >>>> path in reverse direction of a BFD session on the Segment Routing >>>> network over MPLS dataplane. >>>> >>>> >>>> >>>> >>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >>>> >>>> >>> >>> >> >> > --001a114043b0731de7054f30aa83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Never mind= .. I guess you made it up from "Target FEC Stack"= :)



On Wed, May 10, 2017 at 9:40 PM, Robert Ras= zuk <robert@raszuk.net> wrote:
Hi Carlos,

Sorry what is "TFS" ?=C2=A0

RFC 7110 does not even use su= ch abbreviation neither do=C2=A0draft-ietf-mpls-bfd-directed=C2=A0:) Google als= o seems to be pretty clueless about it.=C2=A0

<= /div>
Just curious as you keep using this term in each em= ail :)=C2=A0

Thx,
R= .

On Wed, May 10, 2017 at 9:24 PM, Carlos= Pignataro (cpignata) <cpignata@cisco.com> wrote:
Greg,

In the MPLS data plane, FECs are also instantiated through a label sta= ck. But RFC 7110 does not use numeric label values, it uses TFSs. That does= not create any additional state. E.g.,:=C2=A0https://w= ww.ietf.org/mail-archive/web/mpls/current/msg16091.html

Thanks,

=E2=80=94 Carlos.



On May 9, 2017, at 3:43 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Carlos,
I probably would characterize anything that starts with Why not as a t= echnical comment but rather as a question.
According to=C2=A0draft-ietf-spring-segment-routing-mpls, "= In the MPLS=C2=A0dat= aplane,the SR head= er is instantiated through a label stack".
At the same time, one of advantages of SR is that &= quot;per-flow state only [maintained] at the ingress node to the SR=C2=A0domain".
Thus, for the case of monitoring uni= directional SR tunnels, I consider that there's no need to create any a= dditional state on the egress node.
Of course, if there were bidirection= al SR tunnels, then control of the reverse direction of the BFD session wou= ld not require use of the Return Path sub-TLV.
As for LSP-Ping, I just propose that= the Segment Routing MPLS Tunnel sub-TLV MAY be used Reply Path TLV defined= in RFC 7110. I viewed the proposal as invitation to technical discussion.

Regards,
Greg

On Tue, May 9, 2017 at 9:07 AM, Carlos Pignataro= (cpignata) <cpignata@cisco.com> wrote:
Thank you Greg!

Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems quite= similar to the text removed at https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-bfd-directe= d-05.txt, then the complete set of outstanding technical comments that = triggered the removal of that text from draft-ietf-mpls-bfd-directed-0= 5.txt might peek your interest :-)

One that I recall is: why use label values when every other return-pat= h sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-directed,= uses TFSs?=C2=A0

Best,

=E2=80=94 Carlos.

On May 9, 2017, at 12:00 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear Carlos,
I've decided to re-start the discussion and am interested to hear = technical comments to the proposed solution.=C2=A0

Regards,
Greg

On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro= (cpignata) <cpignata@cisco.com> wrote:
Dear Greg,

Cursorily scanning through this, it seems that most concerns raised an= d comments made about the SR sections of=C2=A0draft-ietf-mpls-bfd-directed-0N (with N < 5) apply to your new draft.

This is one of those:=C2=A0https://www.ietf.org/ma= il-archive/web/mpls/current/msg15860.html =E2=80=94 the list = archive shows a few more. The copy/paste did not address the comments.

Best,

=E2=80=94 Carlos.

On May 8, 2017, at 11:33 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear All,
perhaps this new draft may is of interest to you.
Your comments, suggestions are most welcome and greatly appreciated.

Regards,
Greg

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, May 8, 2017 at 8:29 PM
Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt
To: Gregory Mirsky <gregimirsky@gmail.com>



A new version of I-D, draft-mirsky-spring-bfd-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-spring-bfd
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bidirectional Forwarding Detection= (BFD) in Segment Routing Networks Using MPLS Dataplane
Document date:=C2=A0 2017-05-08
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky-spring-bfd-00.t= xt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-mirsky-spring-bfd-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-mirsky-spring-bfd-00<= /a>


Abstract:
=C2=A0 =C2=A0Segment Routing architecture leverages the paradigm of source<= br> =C2=A0 =C2=A0routing.=C2=A0 It can be realized in the Multiprotocol Label S= witching
=C2=A0 =C2=A0(MPLS) network without any change to the data plane.=C2=A0 A s= egment is
=C2=A0 =C2=A0encoded as an MPLS label and an ordered list of segments is en= coded
=C2=A0 =C2=A0as a stack of labels.=C2=A0 Bidirectional Forwarding Detection= (BFD) is
=C2=A0 =C2=A0expected to monitor any kind of paths between systems.=C2=A0 T= his document
=C2=A0 =C2=A0defines how to use Label Switched Path Ping to bootstrap and c= ontrol
=C2=A0 =C2=A0path in reverse direction of a BFD session on the Segment Rout= ing
=C2=A0 =C2=A0network over MPLS dataplane.




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

The IETF Secretariat


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







--001a114043b0731de7054f30aa83-- From nobody Wed May 10 13:01:58 2017 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 51B76129B2F; Wed, 10 May 2017 13:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 pErYYZ-QPBSJ; Wed, 10 May 2017 13:01:55 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC611250B8; Wed, 10 May 2017 13:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30672; q=dns/txt; s=iport; t=1494446514; x=1495656114; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4SC3vMbhU7xgrg/Gn955pEEGM4uUGPqg8hnNhQ8338E=; b=NEY6v53HdUJ4Ss3+gBpaVV5bh4yS5+VN0u8t3lBIEl7oDlfCzCIW5MPF T5QlStHyfrGA/WDPb/S1hyuyI1d1cBb+tlu553+1KPYPCaCtYKCTURunz igRxvWIihSPJWwyjvG8NA0Xdk9uxK+LzKzpNMxD01wX1mQ4w76va4iEVE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAQDxcBNZ/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoEMB4NiihiRNyFyhzGNT4IPIQEKhXgCGoRoPxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUVAQEBAQMBASFLCQIQAgEIEQECAQIhBwMCAgIfBgsUAwYIAgQOBRuJb?= =?us-ascii?q?gMVDrJCgiaHLg2DOAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GX4FeKwuCMTSCVE2?= =?us-ascii?q?BExECATsWCIJQL4IxBYlEhl6GTYZgOwGHG4cshFOCBFWEZoosiy2EdyiDdgEPE?= =?us-ascii?q?DhMMwtwFRwqEgGEKjkcgWN2AYgLgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.38,320,1491264000"; d="scan'208,217";a="243738630" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2017 20:01:53 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v4AK1qK4015515 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 May 2017 20:01:53 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 10 May 2017 16:01:51 -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.1210.000; Wed, 10 May 2017 16:01:52 -0400 From: "Carlos Pignataro (cpignata)" To: Robert Raszuk CC: "spring@ietf.org" , "rtg-bfd@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt Thread-Topic: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt Thread-Index: AQHSyNwl4f82jzKO5Eq8Ccd1kzJOwKHsbA8AgAAB9QCAADyAAIABjQKAgAAEOwCAAACOgIAABY2A Date: Wed, 10 May 2017 20:01:52 +0000 Message-ID: References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> <9D886964-6C21-427C-8733-7731D5A996D3@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.52] Content-Type: multipart/alternative; boundary="_000_F1E0BFDF70724B2696BC4F47FE8FEDCBciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 10 May 2017 20:01:57 -0000 --_000_F1E0BFDF70724B2696BC4F47FE8FEDCBciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IGFyZSByaWdodCDigJQgc29ycnkgYWJvdXQgdGhhdCEg4oCcVEZT4oCdIGlzIG5vdCB1c2Vk IGluIGFueSBvZiB0aG9zZSBSRkNzIG9yIGRyYWZ0cywgYWx0aG91Z2ggaXQgaXMgdXNlZCBvbiBl bWFpbCBkaXNjdXNzaW9ucyBhYm91dCBMU1AgUGluZy4NCg0KSW5kZWVkLCBURlMgZm9yIOKAnFRh cmdldCBGRUMgU3RhY2vigJ0gZnJvbSBTZWN0aW9uIDMuMiBvZiBSRkMgODAyOS4NCg0KVGhhbmtz LA0KDQrigJQgQ2FybG9zLg0KDQpPbiBNYXkgMTAsIDIwMTcsIGF0IDM6NDEgUE0sIFJvYmVydCBS YXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+IHdyb3Rl Og0KDQoNCk5ldmVyIG1pbmQgLi4gSSBndWVzcyB5b3UgbWFkZSBpdCB1cCBmcm9tICJUYXJnZXQg RkVDIFN0YWNrIiA6KQ0KDQoNCg0KT24gV2VkLCBNYXkgMTAsIDIwMTcgYXQgOTo0MCBQTSwgUm9i ZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4g d3JvdGU6DQpIaSBDYXJsb3MsDQoNClNvcnJ5IHdoYXQgaXMgIlRGUyIgPw0KDQpSRkMgNzExMCBk b2VzIG5vdCBldmVuIHVzZSBzdWNoIGFiYnJldmlhdGlvbiBuZWl0aGVyIGRvIGRyYWZ0LWlldGYt bXBscy1iZmQtZGlyZWN0ZWQgOikgR29vZ2xlIGFsc28gc2VlbXMgdG8gYmUgcHJldHR5IGNsdWVs ZXNzIGFib3V0IGl0Lg0KDQpKdXN0IGN1cmlvdXMgYXMgeW91IGtlZXAgdXNpbmcgdGhpcyB0ZXJt IGluIGVhY2ggZW1haWwgOikNCg0KVGh4LA0KUi4NCg0KT24gV2VkLCBNYXkgMTAsIDIwMTcgYXQg OToyNCBQTSwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIDxjcGlnbmF0YUBjaXNjby5jb208 bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+IHdyb3RlOg0KR3JlZywNCg0KSW4gdGhlIE1QTFMg ZGF0YSBwbGFuZSwgRkVDcyBhcmUgYWxzbyBpbnN0YW50aWF0ZWQgdGhyb3VnaCBhIGxhYmVsIHN0 YWNrLiBCdXQgUkZDIDcxMTAgZG9lcyBub3QgdXNlIG51bWVyaWMgbGFiZWwgdmFsdWVzLCBpdCB1 c2VzIFRGU3MuIFRoYXQgZG9lcyBub3QgY3JlYXRlIGFueSBhZGRpdGlvbmFsIHN0YXRlLiBFLmcu LDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tcGxzL2N1cnJlbnQvbXNn MTYwOTEuaHRtbA0KDQpUaGFua3MsDQoNCuKAlCBDYXJsb3MuDQoNCg0KDQpPbiBNYXkgOSwgMjAx NywgYXQgMzo0MyBQTSwgR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86 Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4gd3JvdGU6DQoNCkhpIENhcmxvcywNCkkgcHJvYmFibHkg d291bGQgY2hhcmFjdGVyaXplIGFueXRoaW5nIHRoYXQgc3RhcnRzIHdpdGggV2h5IG5vdCBhcyBh IHRlY2huaWNhbCBjb21tZW50IGJ1dCByYXRoZXIgYXMgYSBxdWVzdGlvbi4NCkFjY29yZGluZyB0 byBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscywgIkluIHRoZSBNUExTIGRh dGFwbGFuZSx0aGUgU1IgaGVhZGVyIGlzIGluc3RhbnRpYXRlZCB0aHJvdWdoIGEgbGFiZWwgc3Rh Y2siLg0KQXQgdGhlIHNhbWUgdGltZSwgb25lIG9mIGFkdmFudGFnZXMgb2YgU1IgaXMgdGhhdCAi cGVyLWZsb3cgc3RhdGUgb25seSBbbWFpbnRhaW5lZF0gYXQgdGhlIGluZ3Jlc3Mgbm9kZSB0byB0 aGUgU1IgZG9tYWluIi4NClRodXMsIGZvciB0aGUgY2FzZSBvZiBtb25pdG9yaW5nIHVuaWRpcmVj dGlvbmFsIFNSIHR1bm5lbHMsIEkgY29uc2lkZXIgdGhhdCB0aGVyZSdzIG5vIG5lZWQgdG8gY3Jl YXRlIGFueSBhZGRpdGlvbmFsIHN0YXRlIG9uIHRoZSBlZ3Jlc3Mgbm9kZS4NCk9mIGNvdXJzZSwg aWYgdGhlcmUgd2VyZSBiaWRpcmVjdGlvbmFsIFNSIHR1bm5lbHMsIHRoZW4gY29udHJvbCBvZiB0 aGUgcmV2ZXJzZSBkaXJlY3Rpb24gb2YgdGhlIEJGRCBzZXNzaW9uIHdvdWxkIG5vdCByZXF1aXJl IHVzZSBvZiB0aGUgUmV0dXJuIFBhdGggc3ViLVRMVi4NCkFzIGZvciBMU1AtUGluZywgSSBqdXN0 IHByb3Bvc2UgdGhhdCB0aGUgU2VnbWVudCBSb3V0aW5nIE1QTFMgVHVubmVsIHN1Yi1UTFYgTUFZ IGJlIHVzZWQgUmVwbHkgUGF0aCBUTFYgZGVmaW5lZCBpbiBSRkMgNzExMC4gSSB2aWV3ZWQgdGhl IHByb3Bvc2FsIGFzIGludml0YXRpb24gdG8gdGVjaG5pY2FsIGRpc2N1c3Npb24uDQoNClJlZ2Fy ZHMsDQpHcmVnDQoNCk9uIFR1ZSwgTWF5IDksIDIwMTcgYXQgOTowNyBBTSwgQ2FybG9zIFBpZ25h dGFybyAoY3BpZ25hdGEpIDxjcGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNwaWduYXRhQGNpc2Nv LmNvbT4+IHdyb3RlOg0KVGhhbmsgeW91IEdyZWchDQoNClNpbmNlIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1taXJza3ktc3ByaW5nLWJmZC0wMCBzZWVtcyBxdWl0ZSBzaW1pbGFy IHRvIHRoZSB0ZXh0IHJlbW92ZWQgYXQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtaWV0Zi1tcGxzLWJmZC1kaXJlY3RlZC0wNS50eHQsIHRoZW4gdGhlIGNvbXBsZXRl IHNldCBvZiBvdXRzdGFuZGluZyB0ZWNobmljYWwgY29tbWVudHMgdGhhdCB0cmlnZ2VyZWQgdGhl IHJlbW92YWwgb2YgdGhhdCB0ZXh0IGZyb20gZHJhZnQtaWV0Zi1tcGxzLWJmZC1kaXJlY3RlZC0w NS50eHQgbWlnaHQgcGVlayB5b3VyIGludGVyZXN0IDotKQ0KDQpPbmUgdGhhdCBJIHJlY2FsbCBp czogd2h5IHVzZSBsYWJlbCB2YWx1ZXMgd2hlbiBldmVyeSBvdGhlciByZXR1cm4tcGF0aCBzdWIt VExWIGZvciBCRkQgYW5kIGZvciBMU1AtUGluZywgaW5jbHVkaW5nIGRyYWZ0LWlldGYtbXBscy1i ZmQtZGlyZWN0ZWQsIHVzZXMgVEZTcz8NCg0KQmVzdCwNCg0K4oCUIENhcmxvcy4NCg0KT24gTWF5 IDksIDIwMTcsIGF0IDEyOjAwIFBNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29t PG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiB3cm90ZToNCg0KRGVhciBDYXJsb3MsDQpJ J3ZlIGRlY2lkZWQgdG8gcmUtc3RhcnQgdGhlIGRpc2N1c3Npb24gYW5kIGFtIGludGVyZXN0ZWQg dG8gaGVhciB0ZWNobmljYWwgY29tbWVudHMgdG8gdGhlIHByb3Bvc2VkIHNvbHV0aW9uLg0KDQpS ZWdhcmRzLA0KR3JlZw0KDQpPbiBUdWUsIE1heSA5LCAyMDE3IGF0IDg6NTEgQU0sIENhcmxvcyBQ aWduYXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lzY28uY29tPG1haWx0bzpjcGlnbmF0YUBj aXNjby5jb20+PiB3cm90ZToNCkRlYXIgR3JlZywNCg0KQ3Vyc29yaWx5IHNjYW5uaW5nIHRocm91 Z2ggdGhpcywgaXQgc2VlbXMgdGhhdCBtb3N0IGNvbmNlcm5zIHJhaXNlZCBhbmQgY29tbWVudHMg bWFkZSBhYm91dCB0aGUgU1Igc2VjdGlvbnMgb2YgZHJhZnQtaWV0Zi1tcGxzLWJmZC1kaXJlY3Rl ZC0wTiAod2l0aCBOIDwgNSkgYXBwbHkgdG8geW91ciBuZXcgZHJhZnQuDQoNClRoaXMgaXMgb25l IG9mIHRob3NlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21wbHMvY3Vy cmVudC9tc2cxNTg2MC5odG1sIOKAlCB0aGUgbGlzdCBhcmNoaXZlIHNob3dzIGEgZmV3IG1vcmUu IFRoZSBjb3B5L3Bhc3RlIGRpZCBub3QgYWRkcmVzcyB0aGUgY29tbWVudHMuDQoNCkJlc3QsDQoN CuKAlCBDYXJsb3MuDQoNCk9uIE1heSA4LCAyMDE3LCBhdCAxMTozMyBQTSwgR3JlZyBNaXJza3kg PGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4gd3Jv dGU6DQoNCkRlYXIgQWxsLA0KcGVyaGFwcyB0aGlzIG5ldyBkcmFmdCBtYXkgaXMgb2YgaW50ZXJl c3QgdG8geW91Lg0KWW91ciBjb21tZW50cywgc3VnZ2VzdGlvbnMgYXJlIG1vc3Qgd2VsY29tZSBh bmQgZ3JlYXRseSBhcHByZWNpYXRlZC4NCg0KUmVnYXJkcywNCkdyZWcNCg0KLS0tLS0tLS0tLSBG b3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0KRGF0ZTogTW9uLCBNYXkgOCwg MjAxNyBhdCA4OjI5IFBNDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LW1pcnNreS1zcHJpbmctYmZkLTAwLnR4dA0KVG86IEdyZWdvcnkgTWlyc2t5IDxncmVnaW1p cnNreUBnbWFpbC5jb208bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+DQoNCg0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDAudHh0DQpoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEdyZWcgTWlyc2t5IGFuZCBwb3N0ZWQgdG8gdGhl DQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1taXJza3ktc3ByaW5n LWJmZA0KUmV2aXNpb246ICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgQmlkaXJlY3Rpb25hbCBG b3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBpbiBTZWdtZW50IFJvdXRpbmcgTmV0d29ya3MgVXNp bmcgTVBMUyBEYXRhcGxhbmUNCkRvY3VtZW50IGRhdGU6ICAyMDE3LTA1LTA4DQpHcm91cDogICAg ICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgNw0KVVJMOiAgICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1taXJza3kt c3ByaW5nLWJmZC0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1taXJza3ktc3ByaW5nLWJmZC8NCkh0bWxpemVkOiAgICAgICBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDANCkh0bWxp emVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LW1p cnNreS1zcHJpbmctYmZkLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBTZWdtZW50IFJvdXRpbmcgYXJj aGl0ZWN0dXJlIGxldmVyYWdlcyB0aGUgcGFyYWRpZ20gb2Ygc291cmNlDQogICByb3V0aW5nLiAg SXQgY2FuIGJlIHJlYWxpemVkIGluIHRoZSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZw0K ICAgKE1QTFMpIG5ldHdvcmsgd2l0aG91dCBhbnkgY2hhbmdlIHRvIHRoZSBkYXRhIHBsYW5lLiAg QSBzZWdtZW50IGlzDQogICBlbmNvZGVkIGFzIGFuIE1QTFMgbGFiZWwgYW5kIGFuIG9yZGVyZWQg bGlzdCBvZiBzZWdtZW50cyBpcyBlbmNvZGVkDQogICBhcyBhIHN0YWNrIG9mIGxhYmVscy4gIEJp ZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaXMNCiAgIGV4cGVjdGVkIHRv IG1vbml0b3IgYW55IGtpbmQgb2YgcGF0aHMgYmV0d2VlbiBzeXN0ZW1zLiAgVGhpcyBkb2N1bWVu dA0KICAgZGVmaW5lcyBob3cgdG8gdXNlIExhYmVsIFN3aXRjaGVkIFBhdGggUGluZyB0byBib290 c3RyYXAgYW5kIGNvbnRyb2wNCiAgIHBhdGggaW4gcmV2ZXJzZSBkaXJlY3Rpb24gb2YgYSBCRkQg c2Vzc2lvbiBvbiB0aGUgU2VnbWVudCBSb3V0aW5nDQogICBuZXR3b3JrIG92ZXIgTVBMUyBkYXRh cGxhbmUuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rv b2xzLmlldGYub3JnLz4uDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQpt cGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0KDQoNCg0KDQoNCg0K --_000_F1E0BFDF70724B2696BC4F47FE8FEDCBciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <86A7300BB8B04C4D8ABEE15686C0C1E4@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KWW91IGFyZSByaWdodCDigJQgc29y cnkgYWJvdXQgdGhhdCEg4oCcVEZT4oCdIGlzIG5vdCB1c2VkIGluIGFueSBvZiB0aG9zZSBSRkNz IG9yIGRyYWZ0cywgYWx0aG91Z2ggaXQgaXMgdXNlZCBvbiBlbWFpbCBkaXNjdXNzaW9ucyBhYm91 dCBMU1AgUGluZy4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5J bmRlZWQsIFRGUyBmb3Ig4oCcVGFyZ2V0IEZFQyBTdGFja+KAnSBmcm9tIFNlY3Rpb24gMy4yIG9m IFJGQyZuYnNwOzgwMjkuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5UaGFua3MsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJQgQ2FybG9zLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPk9uIE1heSAxMCwgMjAxNywgYXQgMzo0MSBQTSwgUm9iZXJ0IFJhc3p1ayAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiBjbGFzcz0iIj5yb2JlcnRAcmFzenVr Lm5ldDwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1u ZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Es c2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCk5ldmVyIG1pbmQgLi4gSSBndWVzcyB5b3Ug bWFkZSBpdCB1cCBmcm9tICZxdW90OzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ3RpbWVzIG5l dyByb21hbic7IGZvbnQtc2l6ZTogMTJweDsiIGNsYXNzPSIiPlRhcmdldCBGRUMgU3RhY2smcXVv dDsgOik8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9u dC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogJ3RpbWVzIG5ldyByb21hbic7IGZvbnQtc2l6ZTogMTJw eDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9Imdt YWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJp Zjtmb250LXNpemU6c21hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAndGltZXMgbmV3 IHJvbWFuJzsgZm9udC1zaXplOiAxMnB4OyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFu PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFdlZCwgTWF5IDEwLCAyMDE3IGF0IDk6NDAgUE0s IFJvYmVydCBSYXN6dWsgPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1h aWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnJvYmVydEBy YXN6dWsubmV0PC9hPiZndDs8L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0 OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWws aGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCkhpIENhcmxvcyw8L2Rpdj4N CjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2 ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVs dmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NClNvcnJ5IHdoYXQgaXMgJnF1b3Q7 VEZTJnF1b3Q7ID8mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxl PSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwi Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHls ZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxs Ij4NClJGQyA3MTEwIGRvZXMgbm90IGV2ZW4gdXNlIHN1Y2ggYWJicmV2aWF0aW9uIG5laXRoZXIg ZG8mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjFlbTtmb250LWZhbWlseTphcmlhbCxzYW5z LXNlcmlmIiBjbGFzcz0iIj5kcmFmdC1pZXRmLW1wbHMtYmZkLTx3YnIgY2xhc3M9IiI+ZGlyZWN0 ZWQ8L3NwYW4+Jm5ic3A7OikgR29vZ2xlIGFsc28gc2VlbXMgdG8gYmUgcHJldHR5IGNsdWVsZXNz IGFib3V0IGl0LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9 ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+ DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxl PSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwi Pg0KSnVzdCBjdXJpb3VzIGFzIHlvdSBrZWVwIHVzaW5nIHRoaXMgdGVybSBpbiBlYWNoIGVtYWls IDopJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1m YW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQt ZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpUaHgs PGJyIGNsYXNzPSIiPg0KUi48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iSE9FblpiIj4NCjxk aXYgY2xhc3M9Img1Ij4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBNYXkgMTAsIDIwMTcgYXQgOToyNCBQTSwg Q2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQo8c3BhbiBkaXI9Imx0ciIgY2xhc3M9IiI+Jmx0 OzxhIGhyZWY9Im1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFz cz0iIj5jcGlnbmF0YUBjaXNjby5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0 eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCIgY2xhc3M9IiI+R3JlZywNCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkluIHRoZSBNUExTIGRhdGEgcGxh bmUsIEZFQ3MgYXJlIGFsc28gaW5zdGFudGlhdGVkIHRocm91Z2ggYSBsYWJlbCBzdGFjay4gQnV0 IFJGQyA3MTEwIGRvZXMgbm90IHVzZSBudW1lcmljIGxhYmVsIHZhbHVlcywgaXQgdXNlcyBURlNz LiBUaGF0IGRvZXMgbm90IGNyZWF0ZSBhbnkgYWRkaXRpb25hbCBzdGF0ZS4gRS5nLiw6Jm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tcGxzL2N1cnJl bnQvbXNnMTYwOTEuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21hPHdiciBjbGFzcz0iIj5pbC1hcmNoaXZlL3dlYi9tcGxzL2N1cnJlbnQvbXM8d2Jy IGNsYXNzPSIiPmcxNjA5MS5odG1sPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+4oCUIENhcmxvcy48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJtXzU0MzE0NTgxMjE5Mjg2ODEzMDJoNSI+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBNYXkg OSwgMjAxNywgYXQgMzo0MyBQTSwgR3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVn aW1pcnNreUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5ncmVnaW1pcnNreUBn bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0ibV81NDMxNDU4MTIxOTI4 NjgxMzAybV8tMjM4ODg0ODEzOTcwODEyMjI3OEFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPkhpIENhcmxvcywNCjxkaXYg Y2xhc3M9IiI+SSBwcm9iYWJseSB3b3VsZCBjaGFyYWN0ZXJpemUgYW55dGhpbmcgdGhhdCBzdGFy dHMgd2l0aCBXaHkgbm90IGFzIGEgdGVjaG5pY2FsIGNvbW1lbnQgYnV0IHJhdGhlciBhcyBhIHF1 ZXN0aW9uLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BY2NvcmRpbmcgdG8mbmJzcDs8Zm9udCBmYWNl PSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iYmFj a2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1MywyNDUpIiBjbGFzcz0iIj5kPC9zcGFuPjxzcGFuIHN0 eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjUzLDI0NSkiIGNsYXNzPSIiPnJhZnQtaWV0 Zi1zcHJpbmctc2VnbWVudC1yPHdiciBjbGFzcz0iIj5vdXRpbmctbXBscywgJnF1b3Q7PC9zcGFu PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjUzLDI0NSkiIGNsYXNzPSIi PkluDQogdGhlIE1QTFMmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6 cmdiKDI1NSwyNTMsMjQ1KSIgY2xhc3M9IiI+ZGF0YXBsYW5lLDwvc3Bhbj48c3BhbiBzdHlsZT0i YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1MywyNDUpIiBjbGFzcz0iIj50aGUgU1IgaGVhZGVy IGlzIGluc3RhbnRpYXRlZCB0aHJvdWdoIGEgbGFiZWwgc3RhY2smcXVvdDsuPC9zcGFuPjwvZm9u dD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fu cy1zZXJpZiIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwy NTMsMjQ1KSIgY2xhc3M9IiI+QXQgdGhlIHNhbWUgdGltZSwgb25lIG9mIGFkdmFudGFnZXMgb2Yg U1IgaXMgdGhhdCAmcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdi KDI1NSwyNTMsMjQ1KTtmb250LXNpemU6MTRweCIgY2xhc3M9IiI+cGVyLWZsb3cNCiBzdGF0ZSBv bmx5IFttYWludGFpbmVkXSBhdCB0aGUgaW5ncmVzcyBub2RlIHRvIHRoZSBTUiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1MywyNDUpO2ZvbnQtc2l6 ZToxNHB4IiBjbGFzcz0iIj5kb21haW4mcXVvdDsuPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiIgY2xhc3M9 IiI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTMsMjQ1KTtmb250LXNp emU6MTRweCIgY2xhc3M9IiI+VGh1cywgZm9yIHRoZSBjYXNlIG9mIG1vbml0b3JpbmcgdW5pZGly ZWN0aW9uYWwgU1IgdHVubmVscywgSSBjb25zaWRlciB0aGF0IHRoZXJlJ3Mgbm8gbmVlZCB0byBj cmVhdGUgYW55IGFkZGl0aW9uYWwgc3RhdGUNCiBvbiB0aGUgZWdyZXNzIG5vZGUuPC9zcGFuPjwv Zm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwg c2Fucy1zZXJpZiIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiKDI1 NSwyNTMsMjQ1KTtmb250LXNpemU6MTRweCIgY2xhc3M9IiI+T2YgY291cnNlLCBpZiB0aGVyZSB3 ZXJlIGJpZGlyZWN0aW9uYWwgU1IgdHVubmVscywgdGhlbiBjb250cm9sIG9mIHRoZSByZXZlcnNl IGRpcmVjdGlvbiBvZiB0aGUgQkZEIHNlc3Npb24gd291bGQgbm90IHJlcXVpcmUNCiB1c2Ugb2Yg dGhlIFJldHVybiBQYXRoIHN1Yi1UTFYuPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiIgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTMsMjQ1KTtmb250LXNpemU6MTRw eCIgY2xhc3M9IiI+QXMgZm9yIExTUC1QaW5nLCBJIGp1c3QgcHJvcG9zZSB0aGF0IHRoZSBTZWdt ZW50IFJvdXRpbmcgTVBMUyBUdW5uZWwgc3ViLVRMViBNQVkgYmUgdXNlZCBSZXBseSBQYXRoIFRM ViBkZWZpbmVkIGluIFJGQyA3MTEwLg0KIEkgdmlld2VkIHRoZSBwcm9wb3NhbCBhcyBpbnZpdGF0 aW9uIHRvIHRlY2huaWNhbCBkaXNjdXNzaW9uLjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIGNsYXNzPSIi PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjUzLDI0NSk7Zm9udC1zaXpl OjE0cHgiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjUzLDI0NSk7Zm9udC1z aXplOjE0cHgiIGNsYXNzPSIiPlJlZ2FyZHMsPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiIgY2xhc3M9IiI+ PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTMsMjQ1KTtmb250LXNpemU6 MTRweCIgY2xhc3M9IiI+R3JlZzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+ T24gVHVlLCBNYXkgOSwgMjAxNyBhdCA5OjA3IEFNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0 YSkNCjxzcGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmNwaWduYXRh QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmNwaWduYXRhQGNpc2NvLmNvbTwv YT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3Jk IiBjbGFzcz0iIj5UaGFuayB5b3UgR3JlZyENCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNpbmNlIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1taXJza3ktc3ByaW5nLWJmZC0wMCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNz PSIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyPHdiciBjbGFzcz0iIj5hZnQtbWly c2t5LXNwcmluZy1iZmQtMDA8L2E+IHNlZW1zIHF1aXRlIHNpbWlsYXIgdG8gdGhlIHRleHQgcmVt b3ZlZCBhdA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtaWV0Zi1tcGxzLWJmZC1kaXJlY3RlZC0wNS50eHQiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZjx3YnIgY2xhc3M9IiI+P3VybDI9ZHJh ZnQtaWV0Zi1tcGxzLWJmZC1kaXJlPHdiciBjbGFzcz0iIj5jdGVkLTA1LnR4dDwvYT4sIHRoZW4g dGhlIGNvbXBsZXRlIHNldCBvZiBvdXRzdGFuZGluZyB0ZWNobmljYWwgY29tbWVudHMgdGhhdCB0 cmlnZ2VyZWQgdGhlIHJlbW92YWwgb2YgdGhhdCB0ZXh0IGZyb20gZHJhZnQtaWV0Zi1tcGxzLWJm ZC1kaXJlY3RlZC0wPHdiciBjbGFzcz0iIj41LnR4dCBtaWdodA0KIHBlZWsgeW91ciBpbnRlcmVz dCA6LSk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPk9uZSB0aGF0IEkgcmVjYWxsIGlzOiB3aHkgdXNlIGxhYmVsIHZhbHVlcyB3aGVuIGV2 ZXJ5IG90aGVyIHJldHVybi1wYXRoIHN1Yi1UTFYgZm9yIEJGRCBhbmQgZm9yIExTUC1QaW5nLCBp bmNsdWRpbmcgZHJhZnQtaWV0Zi1tcGxzLWJmZC1kaXJlY3RlZCwgdXNlcyBURlNzPyZuYnNwOzwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ QmVzdCw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPuKAlCBDYXJsb3MuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0ibV81 NDMxNDU4MTIxOTI4NjgxMzAybV8tMjM4ODg0ODEzOTcwODEyMjI3OGg1Ij4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBNYXkgOSwgMjAxNywgYXQgMTI6MDAgUE0sIEdy ZWcgTWlyc2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayIgY2xhc3M9IiI+Z3JlZ2ltaXJza3lAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6 PC9kaXY+DQo8YnIgY2xhc3M9Im1fNTQzMTQ1ODEyMTkyODY4MTMwMm1fLTIzODg4NDgxMzk3MDgx MjIyNzhtXy00MjgwMjc0MTcwMDM4OTk4OTAyQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+RGVhciBDYXJsb3MsDQo8ZGl2 IGNsYXNzPSIiPkkndmUgZGVjaWRlZCB0byByZS1zdGFydCB0aGUgZGlzY3Vzc2lvbiBhbmQgYW0g aW50ZXJlc3RlZCB0byBoZWFyIHRlY2huaWNhbCBjb21tZW50cyB0byB0aGUgcHJvcG9zZWQgc29s dXRpb24uJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5SZWdhcmRzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5HcmVnPC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSJnbWFpbF9xdW90ZSI+T24gVHVlLCBNYXkgOSwgMjAxNyBhdCA4OjUxIEFNLCBDYXJsb3MgUGln bmF0YXJvIChjcGlnbmF0YSkNCjxzcGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4mbHQ7PGEgaHJlZj0i bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmNwaWdu YXRhQGNpc2NvLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXIt bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQt d3JhcDpicmVhay13b3JkIiBjbGFzcz0iIj5EZWFyIEdyZWcsDQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DdXJzb3JpbHkgc2Nhbm5pbmcgdGhyb3Vn aCB0aGlzLCBpdCBzZWVtcyB0aGF0IG1vc3QgY29uY2VybnMgcmFpc2VkIGFuZCBjb21tZW50cyBt YWRlIGFib3V0IHRoZSBTUiBzZWN0aW9ucyBvZiZuYnNwO2RyYWZ0LWlldGYtbXBscy1iZmQtZGly ZWN0ZTx3YnIgY2xhc3M9IiI+ZC0wTiAod2l0aCBOICZsdDsgNSkgYXBwbHkgdG8geW91ciBuZXcg ZHJhZnQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5UaGlzIGlzIG9uZSBvZiB0aG9zZTombmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21wbHMvY3VycmVudC9tc2cxNTg2MC5odG1sIiB0YXJn ZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWE8d2JyIGNsYXNzPSIi PmlsLWFyY2hpdmUvd2ViL21wbHMvY3VycmVudC9tczx3YnIgY2xhc3M9IiI+ZzE1ODYwLmh0bWw8 L2E+IOKAlCB0aGUgbGlzdCBhcmNoaXZlIHNob3dzDQogYSBmZXcgbW9yZS4gVGhlIGNvcHkvcGFz dGUgZGlkIG5vdCBhZGRyZXNzIHRoZSBjb21tZW50cy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJlc3QsPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJQgQ2FybG9zLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0ibV81 NDMxNDU4MTIxOTI4NjgxMzAybV8tMjM4ODg0ODEzOTcwODEyMjI3OG1fLTQyODAyNzQxNzAwMzg5 OTg5MDJoNSI+DQo8ZGl2IGNsYXNzPSIiPk9uIE1heSA4LCAyMDE3LCBhdCAxMTozMyBQTSwgR3Jl ZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIiBjbGFzcz0iIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8 L2Rpdj4NCjxiciBjbGFzcz0ibV81NDMxNDU4MTIxOTI4NjgxMzAybV8tMjM4ODg0ODEzOTcwODEy MjI3OG1fLTQyODAyNzQxNzAwMzg5OTg5MDJtXzQxODc4MTcxNTUzMzQ2MDc4MTdBcHBsZS1pbnRl cmNoYW5nZS1uZXdsaW5lIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9Im1fNTQzMTQ1ODEyMTkyODY4MTMwMm1fLTIzODg4NDgxMzk3 MDgxMjIyNzhtXy00MjgwMjc0MTcwMDM4OTk4OTAyaDUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9 IiI+RGVhciBBbGwsDQo8ZGl2IGNsYXNzPSIiPnBlcmhhcHMgdGhpcyBuZXcgZHJhZnQgbWF5IGlz IG9mIGludGVyZXN0IHRvIHlvdS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+WW91ciBjb21tZW50cywg c3VnZ2VzdGlvbnMgYXJlIG1vc3Qgd2VsY29tZSBhbmQgZ3JlYXRseSBhcHByZWNpYXRlZC48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJl Z2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkdyZWc8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPi0tLS0tLS0tLS0gRm9yd2FyZGVk IG1lc3NhZ2UgLS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCkZyb206IDxiIGNsYXNzPSJnbWFpbF9z ZW5kZXJuYW1lIj48L2I+PHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPiZsdDs8YSBocmVmPSJtYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KRGF0ZTog TW9uLCBNYXkgOCwgMjAxNyBhdCA4OjI5IFBNPGJyIGNsYXNzPSIiPg0KU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1taXJza3ktc3ByaW5nLWJmZC0wMC50eHQ8YnIg Y2xhc3M9IiI+DQpUbzogR3JlZ29yeSBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1p cnNreUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5ncmVnaW1pcnNreUBnbWFp bC5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1taXJza3ktc3ByaW5n LWJmZC0wMC50eHQ8YnIgY2xhc3M9IiI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IEdyZWcgTWlyc2t5IGFuZCBwb3N0ZWQgdG8gdGhlPGJyIGNsYXNzPSIiPg0KSUVURiByZXBv c2l0b3J5LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5hbWU6Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1taXJza3ktc3ByaW5nLWJmZDxiciBjbGFz cz0iIj4NClJldmlzaW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAwPGJyIGNsYXNzPSIi Pg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBCaWRpcmVjdGlvbmFs IEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIGluIFNlZ21lbnQgUm91dGluZyBOZXR3b3JrcyBV c2luZyBNUExTIERhdGFwbGFuZTxiciBjbGFzcz0iIj4NCkRvY3VtZW50IGRhdGU6Jm5ic3A7IDIw MTctMDUtMDg8YnIgY2xhc3M9IiI+DQpHcm91cDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxiciBjbGFzcz0iIj4NClBhZ2VzOiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgNzxiciBjbGFzcz0iIj4NClVSTDombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDAudHh0IiByZWw9 Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LTx3YnIgY2xhc3M9IiI+ZHJhZnRzL2RyYWZ0LW1pcnNreS1zcHJpbmctYmZk PHdiciBjbGFzcz0iIj4tMDAudHh0PC9hPjxiciBjbGFzcz0iIj4NClN0YXR1czombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQvIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdl dD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnLzx3YnIgY2xh c3M9IiI+ZG9jL2RyYWZ0LW1pcnNreS1zcHJpbmctYmZkLzwvYT48YnIgY2xhc3M9IiI+DQpIdG1s aXplZDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDAiIHJlbD0ibm9yZWZlcnJlciIg dGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kPHdi ciBjbGFzcz0iIj5yYWZ0LW1pcnNreS1zcHJpbmctYmZkLTAwPC9hPjxiciBjbGFzcz0iIj4NCkh0 bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDAiIHJlbD0i bm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvPHdiciBjbGFzcz0iIj5kb2MvaHRtbC9kcmFmdC1taXJza3ktc3ByaW5nLWI8d2Jy IGNsYXNzPSIiPmZkLTAwPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCkFic3RyYWN0OjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtTZWdtZW50IFJvdXRp bmcgYXJjaGl0ZWN0dXJlIGxldmVyYWdlcyB0aGUgcGFyYWRpZ20gb2Ygc291cmNlPGJyIGNsYXNz PSIiPg0KJm5ic3A7ICZuYnNwO3JvdXRpbmcuJm5ic3A7IEl0IGNhbiBiZSByZWFsaXplZCBpbiB0 aGUgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmc8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5i c3A7KE1QTFMpIG5ldHdvcmsgd2l0aG91dCBhbnkgY2hhbmdlIHRvIHRoZSBkYXRhIHBsYW5lLiZu YnNwOyBBIHNlZ21lbnQgaXM8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ZW5jb2RlZCBhcyBh biBNUExTIGxhYmVsIGFuZCBhbiBvcmRlcmVkIGxpc3Qgb2Ygc2VnbWVudHMgaXMgZW5jb2RlZDxi ciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDthcyBhIHN0YWNrIG9mIGxhYmVscy4mbmJzcDsgQmlk aXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBpczxiciBjbGFzcz0iIj4NCiZu YnNwOyAmbmJzcDtleHBlY3RlZCB0byBtb25pdG9yIGFueSBraW5kIG9mIHBhdGhzIGJldHdlZW4g c3lzdGVtcy4mbmJzcDsgVGhpcyBkb2N1bWVudDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtk ZWZpbmVzIGhvdyB0byB1c2UgTGFiZWwgU3dpdGNoZWQgUGF0aCBQaW5nIHRvIGJvb3RzdHJhcCBh bmQgY29udHJvbDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtwYXRoIGluIHJldmVyc2UgZGly ZWN0aW9uIG9mIGEgQkZEIHNlc3Npb24gb24gdGhlIFNlZ21lbnQgUm91dGluZzxiciBjbGFzcz0i Ij4NCiZuYnNwOyAmbmJzcDtuZXR3b3JrIG92ZXIgTVBMUyBkYXRhcGxhbmUuPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxiciBjbGFzcz0iIj4NCnVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnLyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQp0 b29scy5pZXRmLm9yZzwvYT4uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIElFVEYg U2VjcmV0YXJpYXQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPHdiciBjbGFzcz0iIj5fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4N Cm1wbHMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5tcGxzQGlldGYub3JnPC9hPjxiciBjbGFz cz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bDx3YnIgY2xhc3M9IiI+aXN0aW5mby9tcGxzPC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F1E0BFDF70724B2696BC4F47FE8FEDCBciscocom_-- From nobody Wed May 10 14:24:09 2017 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 5228B12969E; Wed, 10 May 2017 14:23:51 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yllkkmvxjcs6; Wed, 10 May 2017 14:23:49 -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 3CD80128616; Wed, 10 May 2017 14:23:49 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id h4so9668819oib.3; Wed, 10 May 2017 14:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XmLmZFClzQl4W5En6nXjPzagHeKL0YyYwY/lRSR2smM=; b=DXpuEcSS0evaG1oIdEzzT2DsqoPkzukQuW5Kj2g+ClitogZZ0WL/SmuxofSC01g12B e9hbDaxqDiqTaTp6yrP3HstY7K5cYoJUTHSvwf1A4o3PiblnNNTIZubbgKrOTkLaJiQh Kd8fxs4FZ33K0S/3GRvqjubuFjzH4i7yHEcOnrnnlqCStaDK4PbqEBRDYpluQah/DLt+ L8WNXiIAKZdXAEXkCCRO/LDjHwYIBzW+EgasQwvkbKWe7vaViuO/fikUcaL7dT3zwvJC R3JaOnfPp0x6yl3rqWbHDBT+9OSqd+ZYGeg4RKK0Nz4L2UO2XY1iUoVMKarRMXmL+QKK JvNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XmLmZFClzQl4W5En6nXjPzagHeKL0YyYwY/lRSR2smM=; b=iXB5HrCN9cYIjGA915j0Ck1U5QPyCWRTmV2zsnTLTrQ7JYopFVmg0/RjMdiIpM3ujV iLwAInu8CMgn69cmfRh7OKaAvRqWzeDLs0c9teHBAgfzATXLaUTwOtN0QbtGo76LC1cN 4qeA08/MUOFjAgj97oyqzQs8guXeA9s2k7LGOnUAwzkUiaWkJ3PP/EAowfNIG//4cLea zp6Q+hyJ8UkTKfZ3hlGWc8jh+a1DYAu41Oba6XTVG3r0ggB8n2/gh4Zg/5iD80Z6J7kb KDalOM7hmOLNzNKAsSHRpVpq95+iZMECy5YxSmODg7K3WlUTZFZEI6H1oAH8qN5ZEefB c7wg== X-Gm-Message-State: AODbwcAYWur589ELpMPazCuIdW44fONZ7qszcvOAUK9e/VUZx9wRhrOK wLxdvLEqOm9rwkygwx66GY5rx/WmEw== X-Received: by 10.157.47.70 with SMTP id h64mr3909430otb.23.1494451428547; Wed, 10 May 2017 14:23:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.246 with HTTP; Wed, 10 May 2017 14:23:48 -0700 (PDT) In-Reply-To: References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> <9D886964-6C21-427C-8733-7731D5A996D3@cisco.com> From: Greg Mirsky Date: Wed, 10 May 2017 14:23:48 -0700 Message-ID: Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt To: "Carlos Pignataro (cpignata)" Cc: Robert Raszuk , "mpls@ietf.org" , "spring@ietf.org" , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c04713888651a054f32160f Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 10 May 2017 21:23:51 -0000 --94eb2c04713888651a054f32160f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, RFC 7110 defined sub-TLVs by extensively re-using TFS sub-TLVs. Even more, they've referenced explanations of fields to the TFS-defining RFCs. I guess only Flags field was introduced in RFC 7110 with Primary and Secondary bit flag fields being defined. As, I've said in the discussion on BFD directed, this is proposal, it make sense to me as the head-end has all the information already. I always welcome technical comments and appreciate well-argumented discussion. What would be the reason not to use the proposed approach but do it TFS-like style? Regards, Greg On Wed, May 10, 2017 at 1:01 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > You are right =E2=80=94 sorry about that! =E2=80=9CTFS=E2=80=9D is not us= ed in any of those RFCs > or drafts, although it is used on email discussions about LSP Ping. > > Indeed, TFS for =E2=80=9CTarget FEC Stack=E2=80=9D from Section 3.2 of RF= C 8029. > > Thanks, > > =E2=80=94 Carlos. > > On May 10, 2017, at 3:41 PM, Robert Raszuk wrote: > > > Never mind .. I guess you made it up from "Target FEC Stack" :) > > > > On Wed, May 10, 2017 at 9:40 PM, Robert Raszuk wrote: > >> Hi Carlos, >> >> Sorry what is "TFS" ? >> >> RFC 7110 does not even use such abbreviation neither do >> draft-ietf-mpls-bfd-directed :) Google also seems to be pretty clueless >> about it. >> >> Just curious as you keep using this term in each email :) >> >> Thx, >> R. >> >> On Wed, May 10, 2017 at 9:24 PM, Carlos Pignataro (cpignata) < >> cpignata@cisco.com> wrote: >> >>> Greg, >>> >>> In the MPLS data plane, FECs are also instantiated through a label >>> stack. But RFC 7110 does not use numeric label values, it uses TFSs. Th= at >>> does not create any additional state. E.g.,: https://www.ietf.org/ma >>> il-archive/web/mpls/current/msg16091.html >>> >>> Thanks, >>> >>> =E2=80=94 Carlos. >>> >>> >>> >>> On May 9, 2017, at 3:43 PM, Greg Mirsky wrote: >>> >>> Hi Carlos, >>> I probably would characterize anything that starts with Why not as a >>> technical comment but rather as a question. >>> According to draft-ietf-spring-segment-routing-mpls, "In the MPLS >>> dataplane,the SR header is instantiated through a label stack". >>> At the same time, one of advantages of SR is that "per-flow state only >>> [maintained] at the ingress node to the SR domain". >>> Thus, for the case of monitoring unidirectional SR tunnels, I consider >>> that there's no need to create any additional state on the egress node. >>> Of course, if there were bidirectional SR tunnels, then control of the >>> reverse direction of the BFD session would not require use of the Retur= n >>> Path sub-TLV. >>> As for LSP-Ping, I just propose that the Segment Routing MPLS Tunnel >>> sub-TLV MAY be used Reply Path TLV defined in RFC 7110. I viewed the >>> proposal as invitation to technical discussion. >>> >>> Regards, >>> Greg >>> >>> On Tue, May 9, 2017 at 9:07 AM, Carlos Pignataro (cpignata) < >>> cpignata@cisco.com> wrote: >>> >>>> Thank you Greg! >>>> >>>> Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems >>>> quite similar to the text removed at https://tools.ietf.org/rfcdiff >>>> ?url2=3Ddraft-ietf-mpls-bfd-directed-05.txt, then the complete set of >>>> outstanding technical comments that triggered the removal of that text= from >>>> draft-ietf-mpls-bfd-directed-05.txt might peek your interest :-) >>>> >>>> One that I recall is: why use label values when every other return-pat= h >>>> sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-direct= ed, >>>> uses TFSs? >>>> >>>> Best, >>>> >>>> =E2=80=94 Carlos. >>>> >>>> On May 9, 2017, at 12:00 PM, Greg Mirsky wrote= : >>>> >>>> Dear Carlos, >>>> I've decided to re-start the discussion and am interested to hear >>>> technical comments to the proposed solution. >>>> >>>> Regards, >>>> Greg >>>> >>>> On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro (cpignata) < >>>> cpignata@cisco.com> wrote: >>>> >>>>> Dear Greg, >>>>> >>>>> Cursorily scanning through this, it seems that most concerns raised >>>>> and comments made about the SR sections of draft-ietf-mpls-bfd-direct= ed-0N >>>>> (with N < 5) apply to your new draft. >>>>> >>>>> This is one of those: https://www.ietf.org/ma >>>>> il-archive/web/mpls/current/msg15860.html =E2=80=94 the list archive = shows a >>>>> few more. The copy/paste did not address the comments. >>>>> >>>>> Best, >>>>> >>>>> =E2=80=94 Carlos. >>>>> >>>>> On May 8, 2017, at 11:33 PM, Greg Mirsky >>>>> wrote: >>>>> >>>>> Dear All, >>>>> perhaps this new draft may is of interest to you. >>>>> Your comments, suggestions are most welcome and greatly appreciated. >>>>> >>>>> Regards, >>>>> Greg >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: >>>>> Date: Mon, May 8, 2017 at 8:29 PM >>>>> Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt >>>>> To: Gregory Mirsky >>>>> >>>>> >>>>> >>>>> A new version of I-D, draft-mirsky-spring-bfd-00.txt >>>>> has been successfully submitted by Greg Mirsky and posted to the >>>>> IETF repository. >>>>> >>>>> Name: draft-mirsky-spring-bfd >>>>> Revision: 00 >>>>> Title: Bidirectional Forwarding Detection (BFD) in Segment >>>>> Routing Networks Using MPLS Dataplane >>>>> Document date: 2017-05-08 >>>>> Group: Individual Submission >>>>> Pages: 7 >>>>> URL: https://www.ietf.org/internet- >>>>> drafts/draft-mirsky-spring-bfd-00.txt >>>>> Status: https://datatracker.ietf.org/ >>>>> doc/draft-mirsky-spring-bfd/ >>>>> Htmlized: https://tools.ietf.org/html/draft-mirsky-spring-bfd-0= 0 >>>>> Htmlized: https://datatracker.ietf.org/ >>>>> doc/html/draft-mirsky-spring-bfd-00 >>>>> >>>>> >>>>> Abstract: >>>>> Segment Routing architecture leverages the paradigm of source >>>>> routing. It can be realized in the Multiprotocol Label Switching >>>>> (MPLS) network without any change to the data plane. A segment is >>>>> encoded as an MPLS label and an ordered list of segments is encode= d >>>>> as a stack of labels. Bidirectional Forwarding Detection (BFD) is >>>>> expected to monitor any kind of paths between systems. This >>>>> document >>>>> defines how to use Label Switched Path Ping to bootstrap and contr= ol >>>>> path in reverse direction of a BFD session on the Segment Routing >>>>> network over MPLS dataplane. >>>>> >>>>> >>>>> >>>>> >>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > --94eb2c04713888651a054f32160f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carlos,
RFC 7110 defined sub-TLVs by extensively re= -using TFS sub-TLVs. Even more, they've referenced explanations of fiel= ds to the TFS-defining RFCs. I guess only Flags field was introduced in RFC= 7110 with Primary and Secondary bit flag fields being defined.
<= br>
As, I've said in the discussion on BFD directed, this is = proposal, it make sense to me as the head-end has all the information alrea= dy. I always welcome technical comments and appreciate well-argumented disc= ussion. What would be the reason not to use the proposed approach but do it= TFS-like style?

Regards,
Greg

On Wed, May 10,= 2017 at 1:01 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com>= wrote:
You are right =E2=80=94 sorry about that! =E2=80=9CTFS=E2=80=9D is not used= in any of those RFCs or drafts, although it is used on email discussions a= bout LSP Ping.

Indeed, TFS for =E2=80=9CTarget FEC Stack=E2=80=9D from Section 3.2 of= RFC=C2=A08029.

Thanks,

=E2=80=94 Carlos.

On May 10, 2017, at 3:41 PM, Robert Raszuk <robert@raszuk.net> wrote:


Never mind .. I guess you made it up from "Target FEC Stack" :)<= /div>



On Wed, May 10, 2017 at 9:40 PM, Robert Raszuk <= span dir=3D"ltr"> <robert@raszuk.ne= t> wrote:
Hi Carlos,

Sorry what is "TFS" ?=C2=A0

RFC 7110 does not even use such abbreviation neither do=C2=A0draft-ietf-mpls-bfd-directed=C2=A0:) Google also seems to be pretty clueless about it.=C2=A0<= /div>

Just curious as you keep using this term in each email :)=C2=A0

Thx,
R.

On Wed, May 10, 2017 at 9:24 PM, Carlos Pignatar= o (cpignata) <cpignata@cisco.com> wrote:
Greg,

In the MPLS data plane, FECs are also instantiated through a label sta= ck. But RFC 7110 does not use numeric label values, it uses TFSs. That does= not create any additional state. E.g.,:=C2=A0https://w= ww.ietf.org/mail-archive/web/mpls/current/msg16091.html

Thanks,

=E2=80=94 Carlos.



On May 9, 2017, at 3:43 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Carlos,
I probably would characterize anything that starts with Why not as a t= echnical comment but rather as a question.
According to=C2=A0draft-ietf-spring-segment-routing-mpls, "= In the MPLS=C2=A0dat= aplane,the SR head= er is instantiated through a label stack".
At the same time, one of advantages of SR is that &= quot;per-flow state only [maintained] at the ingress node to the SR=C2=A0domain".
Thus, for the case of monitoring uni= directional SR tunnels, I consider that there's no need to create any a= dditional state on the egress node.
Of course, if there were bidirection= al SR tunnels, then control of the reverse direction of the BFD session wou= ld not require use of the Return Path sub-TLV.
As for LSP-Ping, I just propose that= the Segment Routing MPLS Tunnel sub-TLV MAY be used Reply Path TLV defined= in RFC 7110. I viewed the proposal as invitation to technical discussion.=

Regards,
Greg

On Tue, May 9, 2017 at 9:07 AM, Carlos Pignataro= (cpignata) <cpignata@cisco.com> wrote:
Thank you Greg!

Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems quite= similar to the text removed at https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-bfd-directe= d-05.txt, then the complete set of outstanding technical comments that = triggered the removal of that text from draft-ietf-mpls-bfd-directed-0= 5.txt might peek your interest :-)

One that I recall is: why use label values when every other return-pat= h sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-directed,= uses TFSs?=C2=A0

Best,

=E2=80=94 Carlos.

On May 9, 2017, at 12:00 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear Carlos,
I've decided to re-start the discussion and am interested to hear = technical comments to the proposed solution.=C2=A0

Regards,
Greg

On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro= (cpignata) <cpignata@cisco.com> wrote:
Dear Greg,

Cursorily scanning through this, it seems that most concerns raised an= d comments made about the SR sections of=C2=A0draft-ietf-mpls-bfd-directed-0N (with N < 5) apply to your new draft.

This is one of those:=C2=A0https://www.ietf.org/ma= il-archive/web/mpls/current/msg15860.html =E2=80=94 the list = archive shows a few more. The copy/paste did not address the comments.

Best,

=E2=80=94 Carlos.

On May 8, 2017, at 11:33 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear All,
perhaps this new draft may is of interest to you.
Your comments, suggestions are most welcome and greatly appreciated.

Regards,
Greg

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, May 8, 2017 at 8:29 PM
Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt
To: Gregory Mirsky <gregimirsky@gmail.com>



A new version of I-D, draft-mirsky-spring-bfd-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-spring-bfd
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bidirectional Forwarding Detection= (BFD) in Segment Routing Networks Using MPLS Dataplane
Document date:=C2=A0 2017-05-08
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky-spring-bfd-00.t= xt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-mirsky-spring-bfd-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-mirsky-spring-bfd-00<= /a>


Abstract:
=C2=A0 =C2=A0Segment Routing architecture leverages the paradigm of source<= br> =C2=A0 =C2=A0routing.=C2=A0 It can be realized in the Multiprotocol Label S= witching
=C2=A0 =C2=A0(MPLS) network without any change to the data plane.=C2=A0 A s= egment is
=C2=A0 =C2=A0encoded as an MPLS label and an ordered list of segments is en= coded
=C2=A0 =C2=A0as a stack of labels.=C2=A0 Bidirectional Forwarding Detection= (BFD) is
=C2=A0 =C2=A0expected to monitor any kind of paths between systems.=C2=A0 T= his document
=C2=A0 =C2=A0defines how to use Label Switched Path Ping to bootstrap and c= ontrol
=C2=A0 =C2=A0path in reverse direction of a BFD session on the Segment Rout= ing
=C2=A0 =C2=A0network over MPLS dataplane.




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

The IETF Secretariat


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









--94eb2c04713888651a054f32160f-- From nobody Wed May 10 14:47:05 2017 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 76CB412EAF8; Wed, 10 May 2017 14:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 7wOx3NkFB9O8; Wed, 10 May 2017 14:47:01 -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 EC75A12EAF7; Wed, 10 May 2017 14:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12580; q=dns/txt; s=iport; t=1494452821; x=1495662421; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CZZz7Qo6X3DWhaUoCU9P1AhjSzYq80VtFiZavCivxvI=; b=hAmFCtsAum6v6Ekg+WIOSx87/AZHu6Vtp9+EZJ1zbHTiyT7uvaBPp2AX TXNhzNoRGxdMC0N3l8nw19NJI+Kqfs+huUdI63e6BFNjTHirP5GR6a+pW 0SOhFDsWb9S/kzQIh/Tc5bGhXe8CH6GMqoXwr96wnQCSMxgDiFU26vTcZ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAQBziRNZ/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHg2KKGJE3IXKHMY1Pgg8hC4V4AhqEaD8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQECAQEBIRE6CQIFCwIBCBEBAgECAQICJgICAh8GCxUCBggCBA4FG?= =?us-ascii?q?4luAw0IDrIugiaHLw2DOAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4VUgV4rC4I?= =?us-ascii?q?xNIJUTYETEQIBG4MOL4IxBYlEhl6GTYZgOwGHG4cshFOCBFWEZoNmhkaLLYR3K?= =?us-ascii?q?IN2AR84TDMLcBUcKhIBhGMcgWN2AYZdK4EDgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.38,321,1491264000"; d="scan'208";a="241919226" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 May 2017 21:46:59 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v4ALkx00009723 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 May 2017 21:46:59 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.1210.3; Wed, 10 May 2017 17:46:58 -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.1210.000; Wed, 10 May 2017 17:46:58 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: Robert Raszuk , "mpls@ietf.org" , "spring@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt Thread-Topic: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt Thread-Index: AQHSyNwl4f82jzKO5Eq8Ccd1kzJOwKHsbA8AgAAB9QCAADyAAIABjQKAgAAEOwCAAACOgIAABY2AgAAW5gCAAAZ4gA== Date: Wed, 10 May 2017 21:46:58 +0000 Message-ID: <5AFE9872-1C3D-4FF1-8136-0074CBD7AB65@cisco.com> References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> <9D886964-6C21-427C-8733-7731D5A996D3@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.52] Content-Type: text/plain; charset="utf-8" Content-ID: <87381B06DDDDEE43A40CAD31C4E2C7C2@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 10 May 2017 21:47:03 -0000 R3JlZywNCg0KPiBPbiBNYXkgMTAsIDIwMTcsIGF0IDU6MjMgUE0sIEdyZWcgTWlyc2t5IDxncmVn aW1pcnNreUBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSGkgQ2FybG9zLA0KPiBSRkMgNzExMCBk ZWZpbmVkIHN1Yi1UTFZzIGJ5IGV4dGVuc2l2ZWx5IHJlLXVzaW5nIFRGUyBzdWItVExWcy4gRXZl biBtb3JlLCB0aGV5J3ZlIHJlZmVyZW5jZWQgZXhwbGFuYXRpb25zIG9mIGZpZWxkcyB0byB0aGUg VEZTLWRlZmluaW5nIFJGQ3MuIEkgZ3Vlc3Mgb25seSBGbGFncyBmaWVsZCB3YXMgaW50cm9kdWNl ZCBpbiBSRkMgNzExMCB3aXRoIFByaW1hcnkgYW5kIFNlY29uZGFyeSBiaXQgZmxhZyBmaWVsZHMg YmVpbmcgZGVmaW5lZC4NCj4gDQo+IEFzLCBJJ3ZlIHNhaWQgaW4gdGhlIGRpc2N1c3Npb24gb24g QkZEIGRpcmVjdGVkLCB0aGlzIGlzIHByb3Bvc2FsLCBpdCBtYWtlIHNlbnNlIHRvIG1lIGFzIHRo ZSBoZWFkLWVuZCBoYXMgYWxsIHRoZSBpbmZvcm1hdGlvbiBhbHJlYWR5LiBJIGFsd2F5cyB3ZWxj b21lIHRlY2huaWNhbCBjb21tZW50cyBhbmQgYXBwcmVjaWF0ZSB3ZWxsLWFyZ3VtZW50ZWQgZGlz Y3Vzc2lvbi4NCg0KRnJvbSBteSBwZXJzcGVjdGl2ZSwgdGhlIHdlbGwgYXJndW1lbnQgZGlzY3Vz c2lvbiBhbHJlYWR5IGhhcHBlbmVkIG9uIHRoaXMgZXhhY3QgdGV4dCBhbmQgdGhpcyBwcm9wb3Nl ZCBhcHByb2FjaC4gVGhleSBoYXBwZW5lZCBhbHJlYWR5IHR3aWNlIG9uIG11bHRpcGxlIFdHTENz IGluIEJGRCwgYW5kIHRoYXQgdGV4dCB3YXMgcmVtb3ZlZC4gQXNraW5nIGFnYWluIHVuZGVyIGEg ZGlmZmVyZW50IGRyYWZ0IGZpbGVuYW1lIGRvZXMgbm90IGNoYW5nZSB0aGUgYXJndW1lbnRzIGFs cmVhZHkgcHJlc2VudGVkLg0KDQpUaGUgcHJvcG9zYWwgaXMgYnJva2VuLg0KDQo+IFdoYXQgd291 bGQgYmUgdGhlIHJlYXNvbiBub3QgdG8gdXNlIHRoZSBwcm9wb3NlZCBhcHByb2FjaCBidXQgZG8g aXQgVEZTLWxpa2Ugc3R5bGU/DQo+IA0KDQpZb3UgY2FuIHJlYWQgdGhlc2UgcmVhc29ucyBvbiB0 aGUgbGlzdCBhcmNoaXZlcyBvbiB0aGUgcHJldmlvdXMgZGlzY3Vzc2lvbi4gSSBhbnN3ZXJlZCB0 aGlzIHF1ZXN0aW9uIGFscmVhZHkuIEJ1dCwgZm9yIGNvbXBsZXRlbmVzczoNCg0KTGFiZWwgdmFs dWVzIGNhbiBjaGFuZ2UuIFdpdGggbGFiZWxzIHRoZXJlIGlzIG5vIHZhbGlkYXRpb24gcG9zc2li bGUgdGhhdCB3aGF0IGRpc3RyaWJ1dGVkIGJ5IGEgZ2l2ZW4gbGFiZWwgZGlzdHJpYnV0aW9uIHBy b3RvY29sIGlzIHdoYXQgaXMgbWVhbnQgaW4gdGhlIGRhdGEgcGxhbmUuIA0KDQpNb3JlIGltcG9y dGFudGx5LCBhZ2FpbiwgYSB0ZWNobmljYWwgZXhhbXBsZSBvZiB3aHkgdGhpcyBpcyBicm9rZW4g YW5kIGJhY2t3YXJkczoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1pcnNr eS1zcHJpbmctYmZkLTAwI3NlY3Rpb24tNCBzYXlzOg0KDQogICBUaGUgSUFOQSBpcyByZXF1ZXN0 ZWQgdG8gYXNzaWduIG5ldyBzdWItVExWIHR5cGUgZnJvbSAiTXVsdGlwcm90b2NvbA0KICAgTGFi ZWwgU3dpdGNoaW5nIEFyY2hpdGVjdHVyZSAoTVBMUykgTGFiZWwgU3dpdGNoZWQgUGF0aHMgKExT UHMpIFBpbmcNCiAgIFBhcmFtZXRlcnMgLSBUTFZzIiByZWdpc3RyeSwgIlN1Yi1UTFZzIGZvciBU TFYgVHlwZXMgMSwgMTYsIGFuZCAyMSINCiAgIHN1Yi1yZWdpc3RyeS4NCg0KICAgICArLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t Kw0KICAgICB8IFZhbHVlICAgfCBEZXNjcmlwdGlvbiAgICAgICAgICAgICAgICAgICAgICAgICB8 IFJlZmVyZW5jZSAgICAgfA0KICAgICArLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KICAgICB8IFggKFRCRCkgfCBTZWdtZW50 IFJvdXRpbmcgTVBMUyBUdW5uZWwgc3ViLVRMViB8IFRoaXMgZG9jdW1lbnQgfA0KICAgICArLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tKw0KDQoNCk5vdywgVExWIFR5cGVzIDEsIDE2LCBhbmQgMjEgZm9yIE1QTFMgTFNQIFBpbmcg YXJlIA0KDQogICAgICAgICAxICAgVGFyZ2V0IEZFQyBTdGFjaw0KICAgICAgMTYgICAgUmV2ZXJz ZS1wYXRoIFRhcmdldCBGRUMgU3RhY2sNCiAgICAgIDIxICAgIFJlcGx5IFBhdGggDQoNCk1QTFMg TFNQIFBpbmcgVExWcyAxLCAxNiwgYW5kIDIxIG5lZWQgYSBzdWItVExWIHdpdGggYSBGRUMuIE5v dCB3aXRoIGEgTGFiZWwgdmFsdWUuIFRoYXQgaXMgd2h5LCBUTFYgMSBpcyBjYWxsZWQg4oCcVGFy Z2V0IEZFQyBTdGFja+KAnSAoc29tZXRpbWVzIHJlZmVycmVkIHRvIGluZm9ybWFsbHkgYXMgVEZT KQ0KDQpIb3dldmVyLCB5b3UgYXJlIGRlZmluaW5nIGEgcHJvdG9jb2wgc3RydWN0dXJlIHRoYXQg aG9sZHMgbnVtZXJpYyBMYWJlbCB2YWx1ZXMsIGFuZCB5b3Ugc29tZWhvdyB3YW50IHRoYXQgdG8g YmUgdXNlZCBpbiBUTFYgMSBmb3IgTVBMUyBMU1AgUGluZ+KApg0KDQpIb3cgZG8geW91IGVudmlz aW9uIHRoaXMgdG8gd29yayB3aXRoIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MDI5 I3NlY3Rpb24tMy4yPyANCg0KVGhhdCBpcyB5ZXQgYW5vdGhlciByZWFzb24gd2h5IEZFQ3MgYXJl IGJlaW5nIGRlZmluZWQgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1tcGxzLXNwcmluZy1sc3AtcGluZy0wMg0KDQpIb3BlIHRoYXQgaGVscHMsDQoNCuKAlCBDYXJs b3MuDQpQUzogQXMgSSBmaW5kIHRoaXMgcmVwZXRpdGl2ZSwgdGhpcyBpcyBteSBsYXN0IGVtYWls IG9uIHRoZSBzdWJqZWN0Lg0KDQoNCg0KPiBSZWdhcmRzLA0KPiBHcmVnDQo+IA0KPiBPbiBXZWQs IE1heSAxMCwgMjAxNyBhdCAxOjAxIFBNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgPGNw aWduYXRhQGNpc2NvLmNvbT4gd3JvdGU6DQo+IFlvdSBhcmUgcmlnaHQg4oCUIHNvcnJ5IGFib3V0 IHRoYXQhIOKAnFRGU+KAnSBpcyBub3QgdXNlZCBpbiBhbnkgb2YgdGhvc2UgUkZDcyBvciBkcmFm dHMsIGFsdGhvdWdoIGl0IGlzIHVzZWQgb24gZW1haWwgZGlzY3Vzc2lvbnMgYWJvdXQgTFNQIFBp bmcuDQo+IA0KPiBJbmRlZWQsIFRGUyBmb3Ig4oCcVGFyZ2V0IEZFQyBTdGFja+KAnSBmcm9tIFNl Y3Rpb24gMy4yIG9mIFJGQyA4MDI5Lg0KPiANCj4gVGhhbmtzLA0KPiANCj4g4oCUIENhcmxvcy4N Cj4gDQo+PiBPbiBNYXkgMTAsIDIwMTcsIGF0IDM6NDEgUE0sIFJvYmVydCBSYXN6dWsgPHJvYmVy dEByYXN6dWsubmV0PiB3cm90ZToNCj4+IA0KPj4gDQo+PiBOZXZlciBtaW5kIC4uIEkgZ3Vlc3Mg eW91IG1hZGUgaXQgdXAgZnJvbSAiVGFyZ2V0IEZFQyBTdGFjayIgOikNCj4+IA0KPj4gDQo+PiAN Cj4+IE9uIFdlZCwgTWF5IDEwLCAyMDE3IGF0IDk6NDAgUE0sIFJvYmVydCBSYXN6dWsgPHJvYmVy dEByYXN6dWsubmV0PiB3cm90ZToNCj4+IEhpIENhcmxvcywNCj4+IA0KPj4gU29ycnkgd2hhdCBp cyAiVEZTIiA/IA0KPj4gDQo+PiBSRkMgNzExMCBkb2VzIG5vdCBldmVuIHVzZSBzdWNoIGFiYnJl dmlhdGlvbiBuZWl0aGVyIGRvIGRyYWZ0LWlldGYtbXBscy1iZmQtZGlyZWN0ZWQgOikgR29vZ2xl IGFsc28gc2VlbXMgdG8gYmUgcHJldHR5IGNsdWVsZXNzIGFib3V0IGl0LiANCj4+IA0KPj4gSnVz dCBjdXJpb3VzIGFzIHlvdSBrZWVwIHVzaW5nIHRoaXMgdGVybSBpbiBlYWNoIGVtYWlsIDopIA0K Pj4gDQo+PiBUaHgsDQo+PiBSLg0KPj4gDQo+PiBPbiBXZWQsIE1heSAxMCwgMjAxNyBhdCA5OjI0 IFBNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhQGNpc2NvLmNvbT4gd3Jv dGU6DQo+PiBHcmVnLA0KPj4gDQo+PiBJbiB0aGUgTVBMUyBkYXRhIHBsYW5lLCBGRUNzIGFyZSBh bHNvIGluc3RhbnRpYXRlZCB0aHJvdWdoIGEgbGFiZWwgc3RhY2suIEJ1dCBSRkMgNzExMCBkb2Vz IG5vdCB1c2UgbnVtZXJpYyBsYWJlbCB2YWx1ZXMsIGl0IHVzZXMgVEZTcy4gVGhhdCBkb2VzIG5v dCBjcmVhdGUgYW55IGFkZGl0aW9uYWwgc3RhdGUuIEUuZy4sOiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL21wbHMvY3VycmVudC9tc2cxNjA5MS5odG1sDQo+PiANCj4+IFRo YW5rcywNCj4+IA0KPj4g4oCUIENhcmxvcy4NCj4+IA0KPj4gDQo+PiANCj4+PiBPbiBNYXkgOSwg MjAxNywgYXQgMzo0MyBQTSwgR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbT4gd3Jv dGU6DQo+Pj4gDQo+Pj4gSGkgQ2FybG9zLA0KPj4+IEkgcHJvYmFibHkgd291bGQgY2hhcmFjdGVy aXplIGFueXRoaW5nIHRoYXQgc3RhcnRzIHdpdGggV2h5IG5vdCBhcyBhIHRlY2huaWNhbCBjb21t ZW50IGJ1dCByYXRoZXIgYXMgYSBxdWVzdGlvbi4NCj4+PiBBY2NvcmRpbmcgdG8gZHJhZnQtaWV0 Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMsICJJbiB0aGUgTVBMUyBkYXRhcGxhbmUsdGhl IFNSIGhlYWRlciBpcyBpbnN0YW50aWF0ZWQgdGhyb3VnaCBhIGxhYmVsIHN0YWNrIi4NCj4+PiBB dCB0aGUgc2FtZSB0aW1lLCBvbmUgb2YgYWR2YW50YWdlcyBvZiBTUiBpcyB0aGF0ICJwZXItZmxv dyBzdGF0ZSBvbmx5IFttYWludGFpbmVkXSBhdCB0aGUgaW5ncmVzcyBub2RlIHRvIHRoZSBTUiBk b21haW4iLg0KPj4+IFRodXMsIGZvciB0aGUgY2FzZSBvZiBtb25pdG9yaW5nIHVuaWRpcmVjdGlv bmFsIFNSIHR1bm5lbHMsIEkgY29uc2lkZXIgdGhhdCB0aGVyZSdzIG5vIG5lZWQgdG8gY3JlYXRl IGFueSBhZGRpdGlvbmFsIHN0YXRlIG9uIHRoZSBlZ3Jlc3Mgbm9kZS4NCj4+PiBPZiBjb3Vyc2Us IGlmIHRoZXJlIHdlcmUgYmlkaXJlY3Rpb25hbCBTUiB0dW5uZWxzLCB0aGVuIGNvbnRyb2wgb2Yg dGhlIHJldmVyc2UgZGlyZWN0aW9uIG9mIHRoZSBCRkQgc2Vzc2lvbiB3b3VsZCBub3QgcmVxdWly ZSB1c2Ugb2YgdGhlIFJldHVybiBQYXRoIHN1Yi1UTFYuDQo+Pj4gQXMgZm9yIExTUC1QaW5nLCBJ IGp1c3QgcHJvcG9zZSB0aGF0IHRoZSBTZWdtZW50IFJvdXRpbmcgTVBMUyBUdW5uZWwgc3ViLVRM ViBNQVkgYmUgdXNlZCBSZXBseSBQYXRoIFRMViBkZWZpbmVkIGluIFJGQyA3MTEwLiBJIHZpZXdl ZCB0aGUgcHJvcG9zYWwgYXMgaW52aXRhdGlvbiB0byB0ZWNobmljYWwgZGlzY3Vzc2lvbi4NCj4+ PiANCj4+PiBSZWdhcmRzLA0KPj4+IEdyZWcNCj4+PiANCj4+PiBPbiBUdWUsIE1heSA5LCAyMDE3 IGF0IDk6MDcgQU0sIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lzY28u Y29tPiB3cm90ZToNCj4+PiBUaGFuayB5b3UgR3JlZyENCj4+PiANCj4+PiBTaW5jZSBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDAgc2VlbXMgcXVp dGUgc2ltaWxhciB0byB0aGUgdGV4dCByZW1vdmVkIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbXBscy1iZmQtZGlyZWN0ZWQtMDUudHh0LCB0aGVuIHRo ZSBjb21wbGV0ZSBzZXQgb2Ygb3V0c3RhbmRpbmcgdGVjaG5pY2FsIGNvbW1lbnRzIHRoYXQgdHJp Z2dlcmVkIHRoZSByZW1vdmFsIG9mIHRoYXQgdGV4dCBmcm9tIGRyYWZ0LWlldGYtbXBscy1iZmQt ZGlyZWN0ZWQtMDUudHh0IG1pZ2h0IHBlZWsgeW91ciBpbnRlcmVzdCA6LSkNCj4+PiANCj4+PiBP bmUgdGhhdCBJIHJlY2FsbCBpczogd2h5IHVzZSBsYWJlbCB2YWx1ZXMgd2hlbiBldmVyeSBvdGhl ciByZXR1cm4tcGF0aCBzdWItVExWIGZvciBCRkQgYW5kIGZvciBMU1AtUGluZywgaW5jbHVkaW5n IGRyYWZ0LWlldGYtbXBscy1iZmQtZGlyZWN0ZWQsIHVzZXMgVEZTcz8gDQo+Pj4gDQo+Pj4gQmVz dCwNCj4+PiANCj4+PiDigJQgQ2FybG9zLg0KPj4+IA0KPj4+PiBPbiBNYXkgOSwgMjAxNywgYXQg MTI6MDAgUE0sIEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb20+IHdyb3RlOg0KPj4+ PiANCj4+Pj4gRGVhciBDYXJsb3MsDQo+Pj4+IEkndmUgZGVjaWRlZCB0byByZS1zdGFydCB0aGUg ZGlzY3Vzc2lvbiBhbmQgYW0gaW50ZXJlc3RlZCB0byBoZWFyIHRlY2huaWNhbCBjb21tZW50cyB0 byB0aGUgcHJvcG9zZWQgc29sdXRpb24uIA0KPj4+PiANCj4+Pj4gUmVnYXJkcywNCj4+Pj4gR3Jl Zw0KPj4+PiANCj4+Pj4gT24gVHVlLCBNYXkgOSwgMjAxNyBhdCA4OjUxIEFNLCBDYXJsb3MgUGln bmF0YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4+IERlYXIg R3JlZywNCj4+Pj4gDQo+Pj4+IEN1cnNvcmlseSBzY2FubmluZyB0aHJvdWdoIHRoaXMsIGl0IHNl ZW1zIHRoYXQgbW9zdCBjb25jZXJucyByYWlzZWQgYW5kIGNvbW1lbnRzIG1hZGUgYWJvdXQgdGhl IFNSIHNlY3Rpb25zIG9mIGRyYWZ0LWlldGYtbXBscy1iZmQtZGlyZWN0ZWQtME4gKHdpdGggTiA8 IDUpIGFwcGx5IHRvIHlvdXIgbmV3IGRyYWZ0Lg0KPj4+PiANCj4+Pj4gVGhpcyBpcyBvbmUgb2Yg dGhvc2U6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50 L21zZzE1ODYwLmh0bWwg4oCUIHRoZSBsaXN0IGFyY2hpdmUgc2hvd3MgYSBmZXcgbW9yZS4gVGhl IGNvcHkvcGFzdGUgZGlkIG5vdCBhZGRyZXNzIHRoZSBjb21tZW50cy4NCj4+Pj4gDQo+Pj4+IEJl c3QsDQo+Pj4+IA0KPj4+PiDigJQgQ2FybG9zLg0KPj4+PiANCj4+Pj4+IE9uIE1heSA4LCAyMDE3 LCBhdCAxMTozMyBQTSwgR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbT4gd3JvdGU6 DQo+Pj4+PiANCj4+Pj4+IERlYXIgQWxsLA0KPj4+Pj4gcGVyaGFwcyB0aGlzIG5ldyBkcmFmdCBt YXkgaXMgb2YgaW50ZXJlc3QgdG8geW91Lg0KPj4+Pj4gWW91ciBjb21tZW50cywgc3VnZ2VzdGlv bnMgYXJlIG1vc3Qgd2VsY29tZSBhbmQgZ3JlYXRseSBhcHByZWNpYXRlZC4NCj4+Pj4+IA0KPj4+ Pj4gUmVnYXJkcywNCj4+Pj4+IEdyZWcNCj4+Pj4+IA0KPj4+Pj4gLS0tLS0tLS0tLSBGb3J3YXJk ZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQo+Pj4+PiBGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPg0KPj4+Pj4gRGF0ZTogTW9uLCBNYXkgOCwgMjAxNyBhdCA4OjI5IFBNDQo+Pj4+PiBTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1pcnNreS1zcHJpbmctYmZk LTAwLnR4dA0KPj4+Pj4gVG86IEdyZWdvcnkgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb20+ DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtbWlyc2t5LXNwcmluZy1iZmQtMDAudHh0DQo+Pj4+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IEdyZWcgTWlyc2t5IGFuZCBwb3N0ZWQgdG8gdGhlDQo+Pj4+PiBJRVRGIHJl cG9zaXRvcnkuDQo+Pj4+PiANCj4+Pj4+IE5hbWU6ICAgICAgICAgICBkcmFmdC1taXJza3ktc3By aW5nLWJmZA0KPj4+Pj4gUmV2aXNpb246ICAgICAgIDAwDQo+Pj4+PiBUaXRsZTogICAgICAgICAg QmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBpbiBTZWdtZW50IFJvdXRp bmcgTmV0d29ya3MgVXNpbmcgTVBMUyBEYXRhcGxhbmUNCj4+Pj4+IERvY3VtZW50IGRhdGU6ICAy MDE3LTA1LTA4DQo+Pj4+PiBHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ Pj4+PiBQYWdlczogICAgICAgICAgNw0KPj4+Pj4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1taXJza3ktc3ByaW5nLWJmZC0wMC50eHQN Cj4+Pj4+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1taXJza3ktc3ByaW5nLWJmZC8NCj4+Pj4+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDANCj4+Pj4+IEh0bWxp emVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LW1p cnNreS1zcHJpbmctYmZkLTAwDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+ PiAgICBTZWdtZW50IFJvdXRpbmcgYXJjaGl0ZWN0dXJlIGxldmVyYWdlcyB0aGUgcGFyYWRpZ20g b2Ygc291cmNlDQo+Pj4+PiAgICByb3V0aW5nLiAgSXQgY2FuIGJlIHJlYWxpemVkIGluIHRoZSBN dWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZw0KPj4+Pj4gICAgKE1QTFMpIG5ldHdvcmsgd2l0 aG91dCBhbnkgY2hhbmdlIHRvIHRoZSBkYXRhIHBsYW5lLiAgQSBzZWdtZW50IGlzDQo+Pj4+PiAg ICBlbmNvZGVkIGFzIGFuIE1QTFMgbGFiZWwgYW5kIGFuIG9yZGVyZWQgbGlzdCBvZiBzZWdtZW50 cyBpcyBlbmNvZGVkDQo+Pj4+PiAgICBhcyBhIHN0YWNrIG9mIGxhYmVscy4gIEJpZGlyZWN0aW9u YWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaXMNCj4+Pj4+ICAgIGV4cGVjdGVkIHRvIG1v bml0b3IgYW55IGtpbmQgb2YgcGF0aHMgYmV0d2VlbiBzeXN0ZW1zLiAgVGhpcyBkb2N1bWVudA0K Pj4+Pj4gICAgZGVmaW5lcyBob3cgdG8gdXNlIExhYmVsIFN3aXRjaGVkIFBhdGggUGluZyB0byBi b290c3RyYXAgYW5kIGNvbnRyb2wNCj4+Pj4+ICAgIHBhdGggaW4gcmV2ZXJzZSBkaXJlY3Rpb24g b2YgYSBCRkQgc2Vzc2lvbiBvbiB0aGUgU2VnbWVudCBSb3V0aW5nDQo+Pj4+PiAgICBuZXR3b3Jr IG92ZXIgTVBMUyBkYXRhcGxhbmUuDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+ Pj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4+Pj4+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+Pj4+PiANCj4+Pj4+ IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IG1wbHMgbWFpbGluZyBs aXN0DQo+Pj4+PiBtcGxzQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCj4+Pj4gDQo+Pj4+IA0KPj4+IA0KPj4+IA0KPj4gDQo+PiANCj4+ IA0KPiANCj4gDQoNCg== From nobody Thu May 11 13:00:37 2017 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 80E301314B6; Thu, 11 May 2017 13:00:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-stability-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149453283548.16727.4084669114683231310@ietfa.amsl.com> Date: Thu, 11 May 2017 13:00:35 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 20:00:36 -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 Stability Authors : Ashesh Mishra Mahesh Jethanandani Ankur Saxena Santosh Pallagatti Mach Chen Peng Fan Filename : draft-ietf-bfd-stability-00.txt Pages : 5 Date : 2017-05-11 Abstract: This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD stability. Specifically, it describes a mechanism for detection of BFD frame loss. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-stability/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-stability-00 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-stability-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 18 07:25:55 2017 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 7FBE7129AC7 for ; Thu, 18 May 2017 07:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.59 X-Spam-Level: X-Spam-Status: No, score=-4.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.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 NehYy86qFIjc for ; Thu, 18 May 2017 07:25:52 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.138]) (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 8A2F71292FD for ; Thu, 18 May 2017 07:20:27 -0700 (PDT) Received: from [85.158.139.163] by server-2.bemta-5.messagelabs.com id 4C/0B-02006-72CAD195; Thu, 18 May 2017 14:13:59 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0hTYRjHe89tR9uJt3l7mkq4MKNSjG4zKIo Q7ENU0BcrybM8brNtjp0Zq0+mFrgl3UuHpZKZlxWlFYGrvGQXESy7QWVJppVagl3MGdI5Hi17 P/3f5/d/n/f/wMOSmnZGywoup+Cw8RYdE0ytiFmfFr/QF52a+O5epL68qJnSN139ifTfft9E6 8mUU+PX6JTKyjEi5WXec9VWcgdtthmyXem06fxRL2F/eBy5Ct19RC5yH0RuFMxS+DAJgV81hH zR4FME+PwBWrn0ILjT0k+6URDL4LVQX9fNyDoUb4In9ScZ2UTiIgIqmmtoGYTgJLjrLZwyrYP WpjyVG7GSTgB31SK5TOFYKOxvpWTN4V3Q2VY72R/hcBht9xGyJnEEvPpQNqkBY6j0d5KKDoPP vROT4RA+isBfl0cpIAaK35aqFB0NXWWeydkAHyHhTcHIFNgMJzpHKTkQ4AVw/VOa4vEgaCz1T dX3QouHVuw74XnnIZXiGSeg8uIZRgFRUFdyhVbAZRr6qidIZXotdD8rRIqOgk9vbtNyUxLb4H 0gXZl4Ljwq+UBN9/nSVkoeQ7HeGUN7/73wznihWJZCeeMIo+glUFUxSE7rjqZeYma9HKlqUZw oOPYJjnh9gsFhNpqcVt5siV+WuDLBKogibxQsvEFM2JNtrUfSXs2Szi3UnL+xBc1jCV0Y12qP TtXMMWRn7Dfxomm3I8ciiC0oimV1wHXXSmyuQzAKrkyzRVrOaQysWhfKaeokzIl23iqajQpqR /Fs18Ufw4SGsmXbBG0EB7IJyyZTju1vi+kV70LR2hAOSaE0arvgsJqd//MBFMEiXQh3Q06iNt ucf38akEIQUoj8nkg5hJP/h7S5aLt9rPfYquKYc3EZ8/wnk9uyir9GBC0ve1DlyXVqWNvBHvL 7kOfC8FCH6emlOdyWI2FBDamRZ8cDZwq2nmZGx1Yb3e9vxKpd9TmbP1YkZ87+Hb6hoTtQMv/+ 66Tyhsf+sLQDVYZe0xoIz3nB6Is+b9uWpvYMJvsTq31PtA1md9YJHSWa+GWLSYfI/wHZJfZR3 QMAAA== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-5.tower-188.messagelabs.com!1495116833!108732956!1 X-Originating-IP: [52.33.64.93] X-StarScan-Received: X-StarScan-Version: 9.4.12; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 19953 invoked from network); 18 May 2017 14:13:56 -0000 Received: from ec2-52-33-64-93.us-west-2.compute.amazonaws.com (HELO EUR03-AM5-obe.outbound.protection.outlook.com) (52.33.64.93) by server-5.tower-188.messagelabs.com with AES256-SHA256 encrypted SMTP; 18 May 2017 14:13:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rixmje0ctjrDoI9xRb3sj6qt9sExbDFmkNj/CvUp9Rg=; b=W8kBRFeJEFKBziNpy11tGgy5iCmMuAs2UUEF2n272wbjS+vP+Fi/fFggJdkrLXqlbZW5TOE/6VIOtqoGfNtjAxlOIxFvTxoEEwyr6RAFNvve6dLFlhGbu2G5HnO9nYwdfSs4Mh4Nha1/BdUjGrI8N4lQWpeJxU1l5rVBmUuK7tU= Received: from AM4PR03MB1713.eurprd03.prod.outlook.com (10.167.88.15) by AM4PR03MB1585.eurprd03.prod.outlook.com (10.165.243.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Thu, 18 May 2017 14:13:51 +0000 Received: from AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::21f9:af8d:c7ff:3e13]) by AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::21f9:af8d:c7ff:3e13%14]) with mapi id 15.01.1084.030; Thu, 18 May 2017 14:13:51 +0000 From: Alexander Vainshtein To: "dkatz@juniper.net" , David Ward CC: Michael Gorokhovsky , Alexander Ferdman , Shigang Wang , Natalie Rogozovsky , James Lian , BFD WG Subject: Questions related to single-hop IP BFD over IPv6 Thread-Topic: Questions related to single-hop IP BFD over IPv6 Thread-Index: AdLP27i72+NIRcUiTFm1+2kgKRo89Q== Date: Thu, 18 May 2017 14:13:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR03MB1585; 7:iznQDrNaQk33V0M+0cy4fSqjaiQtU/UATJQ9llOdmKGyh80X6Rc4vkIJsqhqo8MkLLYbDOI2bh7w8koNAupa+3dzYXRGWwIjHD8dnibazZQjgvfnhLG42P/icDi/zNDRRwWGfirhTlBzJsFGxlReNrBZB7kNU/3XU4BEKLKE1fp/VKw3v7qrr1zKjkfAwb/QV8rRX/zhy7+/VXphRTxVpxAFoJTYfSlnBWFX3Vih+fH05YnmI8vgZHe2a1W09zwhcOTVuWJ7o/Mjt08T9mil2wN5zL9ZXkd9X5Qr0f8hN9sNSd9CL6HhxH9t6r/g0Hph7osetxdFzn5jAVzfbooPcg== x-ms-office365-filtering-correlation-id: 2a5cfadd-9456-437c-fbd2-08d49df81c2a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM4PR03MB1585; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(72170088055959)(21748063052155)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(20161123562025)(6072148); SRVR:AM4PR03MB1585; BCL:0; PCL:0; RULEID:; SRVR:AM4PR03MB1585; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39850400002)(39450400003)(39840400002)(39860400002)(51874003)(252514010)(81166006)(8676002)(4326008)(189998001)(54356999)(7736002)(74316002)(50986999)(7906003)(5660300001)(25786009)(8936002)(33656002)(5250100002)(2501003)(7696004)(6506006)(54906002)(8666007)(99286003)(55016002)(66066001)(6436002)(606005)(53936002)(102836003)(6306002)(54896002)(9686003)(38730400002)(236005)(2900100001)(413944005)(72206003)(790700001)(6116002)(3660700001)(3280700002)(3846002)(86362001)(2906002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1585; H:AM4PR03MB1713.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR03MB17134BD800C0E072C4ECE6249DE40AM4PR03MB1713eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2017 14:13:51.5251 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1585 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 18 May 2017 14:25:54 -0000 --_000_AM4PR03MB17134BD800C0E072C4ECE6249DE40AM4PR03MB1713eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear colleagues, I have several questions dealing with single-hop IP BFD sessions over IPv6= . So far I have failed to find clear answers to these questions in RFC 588= 1. 1. Is it possible to use link-local source and destination IPv6 addr= esses in encapsulation of single-hop IP BFD Control packets? For the refer= ence: a. Section 4 of RFC 5881 explicitly states that link-local addresses= SHOULD NOT be used in encapsulation of BFD Echo packets, but it does not = say anything about BFD Control packets b. OSPFv3 for IPv6 always uses link-local IPv6 addresses as the Next = Hop addresses of the routes it computes (see RFC 5340, Section 4.8.2). Therefore it looks reasonable to me to u= se single-hop IPv6 BFD sessions with link-local addresses at least for mon= itoring OSPFv3 adjacencies 2. Section 3 of RFC 5881 states that "there will be only a single BF= D session between two systems over a given interface (logical or physical= ) for a particular protocol". I would like to understand how this requirem= ent can be addressed in the following scenario: a. Let us assume that the answer to the question 1 above is positive= . b. Let's further assume that: i. Rou= ter A and Router B are connected across a single IPv6 hop (an IPv6 link) ii. A si= ngle-hop IPv6 BFD session using link-local addresses of the corresponding = interfaces has been successfully established iii. Glob= ally unique IPv6 addresses have been configured on the interfaces terminat= ing this link in Router A and Router B and have successfully passed the DA= D check, i.e., these addresses are assigned and preferred addresses in the= terminology of RFC 4862 iv. The us= er (or some application) now tries to set up a single-hop IPv6 BFD session= bound to the same interfaces but using globally unique IPv6 addresses ass= igned to these interfaces c. Should, under the assumptions above, the implementation prevent = formation of an additional single-hop IPv6 BFD session between A and B run= ning across the same link but using assigned globally unique IPv6 addresse= s of the corresponding interfaces? If yes, how can this be achieved? d. Similar to above, but: i. The= interfaces connecting Router A and Router B have been assigned with multi= ple globally unique IPv6 addresses ii. A si= ngle-hop IPv6 BFD session using one pair of assigned IP addresses of these= interfaces has been successfully established iii. Shou= ld the implementation prevent formation of an additional single-hop IPv6 B= FD session between A and B running on the same link but using a different = pair of assigned globally unique IP addresses? If yes, how can this be ach= ieved? Your inputs would be highly appreciated. Regards, and lots of thanks in advance, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM4PR03MB17134BD800C0E072C4ECE6249DE40AM4PR03MB1713eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear colleagues,

I have several questions dealing with single-hop IP= BFD sessions over IPv6. So far I have failed to find clear answers to the= se questions in RFC 5881.

 

1.    &nbs= p;  Is it possible to use lin= k-local source and destination IPv6 addresses in encapsulation of single-h= op IP BFD Control packets? For the reference:

a.       Section 4 of RFC 5881 exp= licitly states that link-local addresses SHOULD NOT be used in encapsulati= on of BFD Echo packets, but it does not say anything about BFD Control pac= kets

b.      OSPFv3 for IPv6 always us= es link-local IPv6 addresses as the Next Hop addresses of the routes it co= mputes (see RFC 5340, Section 4.8.= 2). Therefore it looks reasonable to me to use single-hop IPv6 BFD session= s with link-local addresses at least for monitoring OSPFv3 adjacencies

2.    &nbs= p;  Section 3 of RFC 5881 sta= tes that “there will be only a single BFD session between  two = systems over a given interface (logical or physical) for a particular prot= ocol”. I would like to understand how this requirement can be addressed in the following scenario:

a.       Let us assume that the an= swer to the question 1 above is positive.

b.      Let’s further assum= e that:

      &nbs= p;            =             &n= bsp;           &nbs= p;            =        i. &nbs= p;    Rout= er A and Router B are connected across a single IPv6 hop (an IPv6 link)

      &nbs= p;            =             &n= bsp;           &nbs= p;            =      ii. &nb= sp;    A s= ingle-hop IPv6 BFD session using link-local addresses of the corresponding= interfaces has been successfully established

      &nbs= p;            =             &n= bsp;           &nbs= p;            =     iii. &n= bsp;    Gl= obally unique IPv6 addresses have been configured on the interfaces termin= ating this link in Router A and Router B and have successfully passed the DAD check, i.e., these addresses are assigned and preferred addresses in = the terminology of RFC 4862

      &nbs= p;            =             &n= bsp;           &nbs= p;            =    iv. &nb= sp;    The= user (or some application) now tries to set up a single-hop IPv6 BFD sess= ion bound to the same interfaces but using globally unique IPv6 addresses assigned to these interfaces

c.       Should, under the assumpt= ions above,  the implementation prevent formation of an additional si= ngle-hop IPv6 BFD session between A and B running across the same link but= using assigned globally unique IPv6 addresses of the corresponding interfaces? If yes, how can this be achieved?

d.      Similar to above, but:

      &nbs= p;            =             &n= bsp;           &nbs= p;            =        i. &nbs= p;    The = interfaces connecting Router A and Router B have been assigned with multip= le globally unique IPv6 addresses

      &nbs= p;            =             &n= bsp;           &nbs= p;            =      ii. &nb= sp;    A s= ingle-hop IPv6 BFD session using one pair of assigned IP addresses of thes= e interfaces has been successfully established

      &nbs= p;            =             &n= bsp;           &nbs= p;            =     iii. &n= bsp;    Sh= ould the implementation prevent formation of an additional single-hop IPv6= BFD session between A and B running on the same link but using a differen= t pair of assigned globally unique IP addresses? If yes, how can this be ac= hieved?

 

Your inputs would be highly appreciated.=

 

Regards, and lots of thanks in advance,<= /p>

Sasha

 

Office: +972-39266302

Cell:      +972-549266= 302

Email:   Alexander.Vainshtein@ecitele.com=

 


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM4PR03MB17134BD800C0E072C4ECE6249DE40AM4PR03MB1713eurp_-- From nobody Thu May 18 14:40:35 2017 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 8CC52129B79; Thu, 18 May 2017 14:40:26 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFm7CE4xAp-P; Thu, 18 May 2017 14:40:25 -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 DAA90129B2D; Thu, 18 May 2017 14:34:17 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id l18so71093940oig.2; Thu, 18 May 2017 14:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=M8JPZV+okP8CPchk4k3ob49bosSzhV+EU6O0q9WbTXc=; b=reqEctYPa/tPgSrlG+CJUQQNBzeZT17s5vWidj53+3fPYabwDSvA3NzzzmFtVIvt36 YebwATUckPLZlLgMDzIGG+a+6Ze1tDipdehqgFDwX2GTIsBlxitdZ7XgT36z0OfBJexP 8IRAvGXY/J3q9C1FFzoLxjKhaH96knol0/iAUK76ofu47PFkqHO3K9DxMdnFRsOHG7// gOOoLW0DdG22jm6Zbj3olQqL6zoEAEaBCC6fgyqoDkeFqvelIXgwXWZqlyPZdAsZ1eTu Oujpz6XCR/CDDw2m9oqHs9+fTnpoi1pTiWZUnO5adfv6UAveglweMsVRIT7HkvE/M2Sa 1sdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=M8JPZV+okP8CPchk4k3ob49bosSzhV+EU6O0q9WbTXc=; b=izzKSDAC28viB8lKe9LRt1QV+If19PWLXbaele/DffsqZl3SvbxdeYLkbWr0cZd0YA UyF5ylLJGKViVkLMxizDgoI86BBw8m5HdkwzrcC3hs195m4Nm8Fak/Qd/nbnmxecpz5T JJhmFlBJiET54FUySp2ZBF5MPwShcBvUs0hrfvwCd+bXsMCYFPW2Pu/qxD+zyE7KmH+y yzffj6IEtPh5NqgiUYBBT0rp/PwGkQfTNgkVriLgN0DbdCqRDXTns0lZDyW7EpTWqaFx hCdaVpKUzYxWAi2NAO2rXweleLHPRCiMN1/vy20zPJUmVHe69+vLDV9cCzloRZPOf3Lb bmTg== X-Gm-Message-State: AODbwcD8LDA+tO6MLrDQ3DWTvf8eFhlrA6WfsZC0kUWB2JBj3LCkBrAJ KsVRnQPKIlidSA== X-Received: by 10.202.230.20 with SMTP id d20mr3892856oih.65.1495143257283; Thu, 18 May 2017 14:34:17 -0700 (PDT) Received: from ?IPv6:2001:420:30d:1320:9cd1:5396:73dc:f0b0? ([2001:420:30d:1320:9cd1:5396:73dc:f0b0]) by smtp.gmail.com with ESMTPSA id c50sm3215257ote.29.2017.05.18.14.34.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 May 2017 14:34:16 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_EE85511B-9142-417A-A5E0-D0ECCE09868B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: IETF OSPF YANG and BFD Configuration From: Mahesh Jethanandani In-Reply-To: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> Date: Thu, 18 May 2017 14:34:20 -0700 Cc: Jeffrey Haas , OSPF WG List , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" , "rtg-bfd@ietf. org" Message-Id: <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> References: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 18 May 2017 21:40:27 -0000 --Apple-Mail=_EE85511B-9142-417A-A5E0-D0ECCE09868B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Resending with correct BFD WG address. > On May 18, 2017, at 2:33 PM, Mahesh Jethanandani = wrote: >=20 > Agree with Acee=E2=80=99s assessment. After much debate, we decided = that we should leave BFD parameter configuration in the BFD model = itself, and have any IGP protocol reference the BFD instance in BFD = itself. This makes sense specially if multiple protocols fate-share the = BFD session. >=20 > Cheers. >=20 >> On May 18, 2017, at 12:27 PM, Acee Lindem (acee) > wrote: >>=20 >> Hi Jeff,=20 >>=20 >> At the OSPF WG Meeting in Chicago, you suggested that we may want to = provide configuration of BFD parameters within the OSPF model = (ietf-ospf.yang). We originally did have this configuration. However, = after much discussion and coordination with the BFD YANG design team, we = agreed to leave the BFD session parameters in BFD and only enable BFD = within the OSPF and IS-IS models.=20 >>=20 >> We did discuss the fact that vendors (notably Cisco IOS-XR and = Juniper JUNOS) do allow configuration within the IGPs. However, the = consensus was to leave the BFD configuration in the BFD model. The = heuristics to determine what parameters to use when the same BFD = endpoint was configured with different parameters in different protocols = were proprietary and somewhat of a hack.=20 >>=20 >> I may have not remembered all the details so I=E2=80=99d encourage = others to chime in.=20 >>=20 >> Thanks, >> Acee=20 >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_EE85511B-9142-417A-A5E0-D0ECCE09868B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Resending with correct BFD WG address.

On = May 18, 2017, at 2:33 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

Agree with = Acee=E2=80=99s assessment. After much debate, we decided that we should = leave BFD parameter configuration in the BFD model itself, and have any = IGP protocol reference the BFD instance in BFD itself. This makes sense = specially if multiple protocols fate-share the BFD session.

Cheers.

On May 18, 2017, at 12:27 PM, Acee Lindem = (acee) <acee@cisco.com> wrote:

Hi Jeff, 

At the OSPF WG Meeting in Chicago, you suggested that we = may want to provide configuration of BFD parameters within the OSPF = model (ietf-ospf.yang). We originally did have this configuration. = However, after much discussion and coordination with the BFD YANG design team, we agreed to leave the BFD session parameters in BFD = and only enable BFD within the OSPF and IS-IS models. 

We did discuss the fact that vendors (notably Cisco = IOS-XR and Juniper JUNOS) do allow configuration within the IGPs. = However, the consensus was to leave the BFD configuration in the BFD = model. The heuristics to determine what parameters to use when the same BFD endpoint was configured with different parameters in different = protocols were proprietary and somewhat of a hack. 

I may have not remembered all the details so I=E2=80=99d = encourage others to chime in. 

Thanks,
Acee 

Mahesh Jethanandani
mjethanandani@gmail.com




Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_EE85511B-9142-417A-A5E0-D0ECCE09868B-- From nobody Thu May 18 19:36:36 2017 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 822081293EB; Thu, 18 May 2017 19:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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.001, SPF_HELO_PASS=-0.001, 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 TCh4rr04vwZd; Thu, 18 May 2017 19:36:32 -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 9F25812940F; Thu, 18 May 2017 19:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11012; q=dns/txt; s=iport; t=1495161100; x=1496370700; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sV1z6ySG6zZBJ7knkjb45+MxVcetM1ku5YPmUjuy0iQ=; b=V4+qnCDd7Uag4ca1xYHgwNv/iWBqcIQsciO+vidgGJzaeqtkXK5Gq5vu w//aXSFkyxb+DFBlrCVcdUnoB4YFH9OY6wYKiFH1Zqc+r/kkvn2jOPKCE +Ee5tdSZZVY0mzKMR+yclYCIzZZrGt22veNcFzA2FAYmWGtpy7Pacm/SS Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAADHWB5Z/4gNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5ngW4HjX+RbogniBeFOIIPhiQChXA/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBA3kQAgEIDgMDAQIoByERFAkIAgQBDQWKCwMVsH2HNA2DWgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR2GX4FdgxyCVIIvBoVMBZBqhgqGZDsBjkiEU5Fuiy+JFgE?= =?us-ascii?q?fOIEKcBVGhHccgWN2hyWBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,361,1491264000"; d="scan'208,217";a="427935104" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 May 2017 02:31:39 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v4J2VdcK020230 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 May 2017 02:31:39 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 18 May 2017 21:31:38 -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.1210.000; Thu, 18 May 2017 21:31:38 -0500 From: "Reshad Rahman (rrahman)" To: Mahesh Jethanandani , "Acee Lindem (acee)" CC: Jeffrey Haas , OSPF WG List , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" , "rtg-bfd@ietf. org" Subject: Re: IETF OSPF YANG and BFD Configuration Thread-Topic: IETF OSPF YANG and BFD Configuration Thread-Index: AQHS0B8wmci/wURKg06fgHPFpmH9rqH68JcAgAAP/gA= Date: Fri, 19 May 2017 02:31:38 +0000 Message-ID: References: <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> In-Reply-To: <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.247.144] Content-Type: multipart/alternative; boundary="_000_D5438DD9298FE6rrahmanciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 19 May 2017 02:36:34 -0000 --_000_D5438DD9298FE6rrahmanciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We started off with the intent of having BFD parameters in the applications= /protocols which make use of BFD. For timer/multiplier this is pretty strai= ght-forward, although the discussion of what to do when not all application= s have the same BFD parameters for the same session (e.g. Go with most aggr= essive etc). Then we started looking at authentication parameters and havin= g BFD authentication parms in OSPF/ISIS etc is not intuitive. And what do w= e do if applications have different BFD authentication parms. We concluded = that the BFD authentication parms were better off in BFD. And once we did t= hat, the timer/multiplier followed.... I may not recall all the details/discussons, but I do recall that we went b= ack and forth on this and it took some time to make the decision. Regards, Reshad (as individual contributor). From: Mahesh Jethanandani > Date: Thursday, May 18, 2017 at 5:34 PM To: "Acee Lindem (acee)" > Cc: Jeffrey Haas >, OSPF WG Lis= t >, "draft-ietf-bfd-yang@ietf.org" >, "draft-ietf-ospf-yang@ietf.org" >, "rtg-bfd@ietf.org" > Subject: Re: IETF OSPF YANG and BFD Configuration Resent-From: > Resent-To: >, Reshad >, >, >, = > Resent-Date: Thursday, May 18, 2017 at 5:40 PM Resending with correct BFD WG address. On May 18, 2017, at 2:33 PM, Mahesh Jethanandani > wrote: Agree with Acee's assessment. After much debate, we decided that we should = leave BFD parameter configuration in the BFD model itself, and have any IGP= protocol reference the BFD instance in BFD itself. This makes sense specia= lly if multiple protocols fate-share the BFD session. Cheers. On May 18, 2017, at 12:27 PM, Acee Lindem (acee) > wrote: Hi Jeff, At the OSPF WG Meeting in Chicago, you suggested that we may want to provid= e configuration of BFD parameters within the OSPF model (ietf-ospf.yang). W= e originally did have this configuration. However, after much discussion an= d coordination with the BFD YANG design team, we agreed to leave the BFD se= ssion parameters in BFD and only enable BFD within the OSPF and IS-IS model= s. We did discuss the fact that vendors (notably Cisco IOS-XR and Juniper JUNO= S) do allow configuration within the IGPs. However, the consensus was to le= ave the BFD configuration in the BFD model. The heuristics to determine wha= t parameters to use when the same BFD endpoint was configured with differen= t parameters in different protocols were proprietary and somewhat of a hack= . I may have not remembered all the details so I'd encourage others to chime = in. Thanks, Acee Mahesh Jethanandani mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --_000_D5438DD9298FE6rrahmanciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <4C051A06D98A1444BD92B6786FDCED19@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
We started off with the intent of having BFD parameters in the applica= tions/protocols which make use of BFD. For timer/multiplier this is pretty = straight-forward, although the discussion of what to do when not all applic= ations have the same BFD parameters for the same session (e.g. Go with most aggressive etc). Then we started l= ooking at authentication parameters and having BFD authentication parms in = OSPF/ISIS etc is not intuitive. And what do we do if applications have diff= erent BFD authentication parms. We concluded that the BFD authentication parms were better off in BFD. And= once we did that, the timer/multiplier followed….

I may not recall all the details/discussons, but I do recall that we w= ent back and forth on this and it took some time to make the decision.

Regards,
Reshad (as individual contributor). 

From: Mahesh Jethanandani <mjethanandani@gmail.com>
Date: Thursday, May 18, 2017 at 5:3= 4 PM
To: "Acee Lindem (acee)" = <acee@cisco.com>
Cc: Jeffrey Haas <jhaas@juniper.net>, OSPF WG List <ospf@ietf.org>, "draft-ietf-bfd-yang@ietf.org" <draft-ietf-bfd-yang@ie= tf.org>, "draf= t-ietf-ospf-yang@ietf.org" <draft-ietf-ospf-yang@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: IETF OSPF YANG and BFD= Configuration
Resent-From: <alias-bounces@ietf.org>
Resent-To: <vero.zheng@huawei.com>, Reshad <rrahman@cisco.com>, <mjethanandani@gmail.com>, <santosh.pallagatti@gmail.com>, <gregimirsky@gmail.com>=
Resent-Date: Thursday, May 18, 2017= at 5:40 PM

Resending with correct BFD WG address.

On May 18, 2017, at 2:33 PM, Mahesh Jethanandani <mjethanandani@gmail.com= > wrote:

Agree with Acee’s assessment. After much debate, we decided that we s= hould leave BFD parameter configuration in the BFD model itself, and have a= ny IGP protocol reference the BFD instance in BFD itself. This makes sense = specially if multiple protocols fate-share the BFD session.

Cheers.

On May 18, 2017, at 12:27 PM, Acee Lindem (acee) <acee@cisco.com> wrote:

Hi Jeff, 

At the OSPF WG Meeting in Chicago, you suggested that we ma= y want to provide configuration of BFD parameters within the OSPF model (ie= tf-ospf.yang). We originally did have this configuration. However, after mu= ch discussion and coordination with the BFD YANG design team, we agreed to leave the BFD session parameters in= BFD and only enable BFD within the OSPF and IS-IS models. 

We did discuss the fact that vendors (notably Cisco IOS-XR = and Juniper JUNOS) do allow configuration within the IGPs. However, the con= sensus was to leave the BFD configuration in the BFD model. The heuristics = to determine what parameters to use when the same BFD endpoint was configured with different parameters in dif= ferent protocols were proprietary and somewhat of a hack. 

I may have not remembered all the details so I’d enco= urage others to chime in. 

Thanks,
Acee 

Mahesh Jethanandani
mjeth= anandani@gmail.com




Mahesh Jethanandani
mjeth= anandani@gmail.com



 --_000_D5438DD9298FE6rrahmanciscocom_-- From nobody Tue May 23 06:21:23 2017 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 12EF1129B41; Tue, 23 May 2017 06:21:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-secure-sequence-numbers-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149554567500.31769.9536749030098632445@ietfa.amsl.com> Date: Tue, 23 May 2017 06:21:15 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 13:21:15 -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 : Secure BFD Sequence Numbers Authors : Mahesh Jethanandani Sonal Agarwal Ashesh Mishra Ankur Saxena Alan DeKok Filename : draft-ietf-bfd-secure-sequence-numbers-00.txt Pages : 5 Date : 2017-05-22 Abstract: This document describes a security enhancements for the BFD packet's sequence number. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-secure-sequence-numbers-00 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-secure-sequence-numbers-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 25 07:41:43 2017 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 3CA941296CD for ; Thu, 25 May 2017 07:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.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 nzzsBVwzdXCZ for ; Thu, 25 May 2017 07:41:40 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.169]) (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 1377C1200FC for ; Thu, 25 May 2017 07:41:39 -0700 (PDT) Received: from [85.158.138.179] by server-9.bemta-3.messagelabs.com id 0E/78-26749-22DE6295; Thu, 25 May 2017 14:41:38 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSaUgUYRjH951jdxLHxlXzadHArSxMRUtEgkI K0+j80IGh1FiTu7SH7Ky1QaAphWlWUFZauZuKVhrYZnZYeX3RtMu01FIqK2zt0syyy3b21bJv v/f9/ec5hpchlS1yFSNYzILJwOvUcjcqIiA6MSTgfWB82OmsiChbbj0VVVc5gqI+/6xG0WTcs R+X6LiSklEi7klGh2ItuYnWGpKMli205kSpnUx5cA5ZalrtVDoqPo6ykRtDcftJcFxtlEsHJX eMgOyuUgIfniPI/HHPGZvCyLlFYC/vkUvszS2Hh/ajri9ILpeAs/XnaUl4SSFHE41Di6GxLkO BeT60nBtyFaK42fCydszZgWFYLgGsrd7SNeKmwdc7FYTEJOcL3a+sLgaOg5Kb90nMPvC27zct 9UXcYQQ3yzMoLALgZO9pBWZ/aLPmuHYD7iAJZU1F4yIIBpvfkFJj4FZBR7cK40yo6k/EiRwEt SWxmHdAde+78Rn2wKH67wpcsoUGxwPbuPCDk0MfCSwaaLiYfoPCP0IFPe0HEGY/6H92i8abGe Dx6DdXhuU8oTn/FXUEBRZMWrpgUqxgUgzfB4OtZkiOeR6Unh0gJ7i1ro+YfG9DigtojiiYdgq mkMjQJJM2WWPW81pdSHjYglC9IIp8sqDjk8TQrUa9HTkfVppMhq6h9v1LG9B0hlD7sL5nAuOV HknGbbs1vKjZbErVCWID8mMYNbBT3zmdp0lIFizbtTrn65zQwLirvVkfSbNiCq8XtclY3UEhj K2qaphQUgajQVD5sjOkECeFNKmGvyUm3ngb8ld5sUgmkyndUwSTXmv+3zuQL4PUXuybAWcVd6 3B/LeTwzkE4RwipmemNISZ/6dU6ag6rah+BTE264tHWmX+5bmpmatvk427P1GBzPV4x+eKXcV 1589cedu/d3B9amTWKeVI3uvC/kXGXD52bHDfWPqa6OEu+YZNS36t3FhmvFtaNtJXOPgh2K3z 1F5rm+VoZ1D46ysxefAoZmcsSzxNWJhQ5pNPiS86131cs2wG0yW33RpWU6KGDw8iTSL/B3zEO lTeAwAA X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-169.messagelabs.com!1495723294!99837447!1 X-Originating-IP: [52.33.64.93] X-StarScan-Received: X-StarScan-Version: 9.4.12; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 27755 invoked from network); 25 May 2017 14:41:36 -0000 Received: from ec2-52-33-64-93.us-west-2.compute.amazonaws.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-12.tower-169.messagelabs.com with AES256-SHA256 encrypted SMTP; 25 May 2017 14:41:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZsDY0kD2P0qrH9gKQ1MRkfNXAKzeW/sOWQq3K2TUCDk=; b=kufCW35cWiQ9N98bx+MKfrevsWZMfK3YBcHeMHe2vZhq2lxjkMv73Ra6f4F7WprM02BoGelAnPlzl/AdlswfFc5XtMukpaYbgWRh1Y6MbGydYmDO9dVIswptPasW3CTPgo27jWIIY+U1zGGD+oR/74GTA4BiPcc566V4k8vR7Qo= Received: from AM4PR03MB1713.eurprd03.prod.outlook.com (10.167.88.15) by AM4PR03MB1586.eurprd03.prod.outlook.com (10.165.243.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.14; Thu, 25 May 2017 14:41:26 +0000 Received: from AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::21f9:af8d:c7ff:3e13]) by AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::21f9:af8d:c7ff:3e13%14]) with mapi id 15.01.1101.022; Thu, 25 May 2017 14:41:26 +0000 From: Alexander Vainshtein To: "dkatz@juniper.net" , David Ward CC: Michael Gorokhovsky , Alexander Ferdman , Shigang Wang , Natalie Rogozovsky , James Lian , BFD WG Subject: RE: Questions related to single-hop IP BFD over IPv6 Thread-Topic: Questions related to single-hop IP BFD over IPv6 Thread-Index: AdLP27i72+NIRcUiTFm1+2kgKRo89QFiQ8Rw Date: Thu, 25 May 2017 14:41:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR03MB1586; 7:OEusQP2x720gzTGS6+jSMRO1c3kf/cKkWXsVPeItTa3OehESfsiJymiMO8REM2UCkuVRtqB9P5rNYDpXTs2uD1m8Saz+INr39sKOf3hLmddeAv3t+8T2hxlVZiNB33Y+Av+0Y91BQvjszIfg+LRqzCk5NouzWcU1vyBWc4N5X6DCVaD6Yi+a1uH6tUUJ5bSXk6ZzzxgFelHM8aIGS3IpfsTSRaPZ+5xgoJNw0dJHOqRVsdISeLFx8FzZ2Cf/ZzNHeDqfB2sjGSLHHd/dJgbI6ajftTCyCfgxqpJD6rgNk40ovp8Qe/AfDYf38n86uvS4hKePHfJljAr/vFMKzPa+HA== x-ms-traffictypediagnostic: AM4PR03MB1586: x-ms-office365-filtering-correlation-id: 525985f1-8f21-44ac-541d-08d4a37c1f5c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM4PR03MB1586; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(72170088055959)(138986009662008)(95692535739014)(21748063052155)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700054)(100105000095)(100000701054)(100105300095)(100000702054)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703054)(100105400095)(6055026)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(6072148)(100000704054)(100105200095)(100000705054)(100105500095); SRVR:AM4PR03MB1586; BCL:0; PCL:0; RULEID:(100000800054)(100110000095)(100000801054)(100110300095)(100000802054)(100110100095)(100000803054)(100110400095)(100000804054)(100110200095)(100000805047)(100110500095); SRVR:AM4PR03MB1586; x-forefront-prvs: 0318501FAE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39450400003)(39410400002)(39850400002)(39840400002)(39860400002)(252514010)(377454003)(790700001)(102836003)(6116002)(3846002)(99286003)(6306002)(9686003)(54896002)(55016002)(53936002)(7736002)(236005)(478600001)(413944005)(5250100002)(2501003)(72206003)(53546009)(66066001)(38730400002)(6246003)(25786009)(189998001)(86362001)(50986999)(8936002)(3280700002)(3660700001)(2900100001)(81166006)(8676002)(54356999)(4326008)(8666007)(229853002)(6436002)(5660300001)(606005)(2906002)(6506006)(74316002)(33656002)(7696004)(7906003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1586; H:AM4PR03MB1713.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR03MB1713FB65AD7CD28E71556B979DFF0AM4PR03MB1713eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2017 14:41:26.1107 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1586 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 25 May 2017 14:41:42 -0000 --_000_AM4PR03MB1713FB65AD7CD28E71556B979DFF0AM4PR03MB1713eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear colleagues, This is a gentle reminder about questions I've asked exactly 1 week ago. Your help would be highly appreciated. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Alexander Vainshtein Sent: Thursday, May 18, 2017 5:14 PM To: 'dkatz@juniper.net' ; David Ward Cc: Michael Gorokhovsky ; Alexander Ferdm= an ; Shigang Wang ; Natalie Rogozovsky (Natalie.Rogozovsky@ecitele.com) ; James Lian ; BFD WG Subject: Questions related to single-hop IP BFD over IPv6 Dear colleagues, I have several questions dealing with single-hop IP BFD sessions over IPv6= . So far I have failed to find clear answers to these questions in RFC 588= 1. 1. Is it possible to use link-local source and destination IPv6 addr= esses in encapsulation of single-hop IP BFD Control packets? For the refer= ence: a. Section 4 of RFC 5881 explicitly states that link-local addresses= SHOULD NOT be used in encapsulation of BFD Echo packets, but it does not = say anything about BFD Control packets b. OSPFv3 for IPv6 always uses link-local IPv6 addresses as the Next = Hop addresses of the routes it computes (see RFC 5340, Section 4.8.2). Therefore it looks reasonable to me to u= se single-hop IPv6 BFD sessions with link-local addresses at least for mon= itoring OSPFv3 adjacencies 2. Section 3 of RFC 5881 states that "there will be only a single BF= D session between two systems over a given interface (logical or physical= ) for a particular protocol". I would like to understand how this requirem= ent can be addressed in the following scenario: a. Let us assume that the answer to the question 1 above is positive= . b. Let's further assume that: =20 i. R= outer A and Router B are connected across a single IPv6 hop (an IPv6 link)= ii. A si= ngle-hop IPv6 BFD session using link-local addresses of the corresponding = interfaces has been successfully established iii. Glob= ally unique IPv6 addresses have been configured on the interfaces terminat= ing this link in Router A and Router B and have successfully passed the DA= D check, i.e., these addresses are assigned and preferred addresses in the= terminology of RFC 4862 iv. The us= er (or some application) now tries to set up a single-hop IPv6 BFD session= bound to the same interfaces but using globally unique IPv6 addresses ass= igned to these interfaces c. Should, under the assumptions above, the implementation prevent = formation of an additional single-hop IPv6 BFD session between A and B run= ning across the same link but using assigned globally unique IPv6 addresse= s of the corresponding interfaces? If yes, how can this be achieved? d. Similar to above, but: i. The= interfaces connecting Router A and Router B have been assigned with multi= ple globally unique IPv6 addresses ii. A si= ngle-hop IPv6 BFD session using one pair of assigned IP addresses of these= interfaces has been successfully established iii. Shou= ld the implementation prevent formation of an additional single-hop IPv6 B= FD session between A and B running on the same link but using a different = pair of assigned globally unique IP addresses? If yes, how can this be ach= ieved? Your inputs would be highly appreciated. Regards, and lots of thanks in advance, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM4PR03MB1713FB65AD7CD28E71556B979DFF0AM4PR03MB1713eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear colleagues,=

This is a gentle remi= nder about questions I’ve asked exactly 1 week ago.

Your help would be hi= ghly appreciated.

 

Regards,

Sasha

 

Office: +972-3926= 6302

Cell:  &nbs= p;   +972-549266302

Email:   Al= exander.Vainshtein@ecitele.com

 

From: Alexander Vainshtein
Sent: Thursday, May 18, 2017 5:14 PM
To: 'dkatz@juniper.net' <dkatz@juniper.net>; David Ward <d= ward@cisco.com>
Cc: Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>; Al= exander Ferdman <Alexander.Ferdman@ecitele.com>; Shigang Wang <Sh= igang.Wang@ecitele.com>; Natalie Rogozovsky (Natalie.Rogozovsky@ecitele= .com) <Natalie.Rogozovsky@ecitele.com>; James Lian <James.Lian@ec= itele.com>; BFD WG <rtg-bfd@ietf.org>
Subject: Questions related to single-hop IP BFD over IPv6

 

Dear colleagues,

I have several questions dealing with single-hop IP= BFD sessions over IPv6. So far I have failed to find clear answers to the= se questions in RFC 5881.

 

1.    &nbs= p;  Is it possible to use lin= k-local source and destination IPv6 addresses in encapsulation of single-h= op IP BFD Control packets? For the reference:

a.       Section 4 of RFC 5881 exp= licitly states that link-local addresses SHOULD NOT be used in encapsulati= on of BFD Echo packets, but it does not say anything about BFD Control pac= kets

b.      OSPFv3 for IPv6 always us= es link-local IPv6 addresses as the Next Hop addresses of the routes it co= mputes (see RFC 5340, Section 4.8.= 2). Therefore it looks reasonable to me to use single-hop IPv6 BFD session= s with link-local addresses at least for monitoring OSPFv3 adjacencies

2.    &nbs= p;  Section 3 of RFC 5881 sta= tes that “there will be only a single BFD session between  two = systems over a given interface (logical or physical) for a particular prot= ocol”. I would like to understand how this requirement can be addressed in the following scenario:

a.       Let us assume that the an= swer to the question 1 above is positive.

b.      Let’s further assum= e that:

      &nbs= p;            =             &n= bsp;           &nbs= p;            =        i. &nbs= p;    Rout= er A and Router B are connected across a single IPv6 hop (an IPv6 link)

      &nbs= p;            =             &n= bsp;           &nbs= p;            =      ii. &nb= sp;    A s= ingle-hop IPv6 BFD session using link-local addresses of the corresponding= interfaces has been successfully established

      &nbs= p;            =             &n= bsp;           &nbs= p;            =     iii. &n= bsp;    Gl= obally unique IPv6 addresses have been configured on the interfaces termin= ating this link in Router A and Router B and have successfully passed the DAD check, i.e., these addresses are assigned and preferred addresses in = the terminology of RFC 4862

      &nbs= p;            =             &n= bsp;           &nbs= p;            =    iv. &nb= sp;    The= user (or some application) now tries to set up a single-hop IPv6 BFD sess= ion bound to the same interfaces but using globally unique IPv6 addresses assigned to these interfaces

c.       Should, under the assumpt= ions above,  the implementation prevent formation of an additional si= ngle-hop IPv6 BFD session between A and B running across the same link but= using assigned globally unique IPv6 addresses of the corresponding interfaces? If yes, how can this be achieved?

d.      Similar to above, but:

      &nbs= p;            =             &n= bsp;           &nbs= p;            =        i. &nbs= p;    The = interfaces connecting Router A and Router B have been assigned with multip= le globally unique IPv6 addresses

      &nbs= p;            =             &n= bsp;           &nbs= p;            =      ii. &nb= sp;    A s= ingle-hop IPv6 BFD session using one pair of assigned IP addresses of thes= e interfaces has been successfully established

      &nbs= p;            =             &n= bsp;           &nbs= p;            =     iii. &n= bsp;    Sh= ould the implementation prevent formation of an additional single-hop IPv6= BFD session between A and B running on the same link but using a differen= t pair of assigned globally unique IP addresses? If yes, how can this be ac= hieved?

 

Your inputs would be highly appreciated.=

 

Regards, and lots of thanks in advance,<= /p>

Sasha

 

Office: +972-39266302

Cell:      +972-549266= 302

Email:   Alexander.Vainshtein@ecitele.com

 


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM4PR03MB1713FB65AD7CD28E71556B979DFF0AM4PR03MB1713eurp_-- From nobody Thu May 25 07:56:49 2017 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 B279A129432 for ; Thu, 25 May 2017 07:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001, 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 1yIBdIyUqG8D for ; Thu, 25 May 2017 07:56:46 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CF1481200FC for ; Thu, 25 May 2017 07:56:46 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7A27C1E37B; Thu, 25 May 2017 11:04:54 -0400 (EDT) Date: Thu, 25 May 2017 11:04:54 -0400 From: Jeffrey Haas To: Alexander Vainshtein Cc: "dkatz@juniper.net" , David Ward , Shigang Wang , Michael Gorokhovsky , Natalie Rogozovsky , James Lian , BFD WG , Alexander Ferdman Subject: Re: Questions related to single-hop IP BFD over IPv6 Message-ID: <20170525150454.GA19117@pfrc.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 25 May 2017 14:56:49 -0000 Sasha, On Thu, May 18, 2017 at 02:13:51PM +0000, Alexander Vainshtein wrote: > I have several questions dealing with single-hop IP BFD sessions over IPv6. So far I have failed to find clear answers to these questions in RFC 5881. > > > 1. Is it possible to use link-local source and destination IPv6 addresses in encapsulation of single-hop IP BFD Control packets? For the reference: > > a. Section 4 of RFC 5881 explicitly states that link-local addresses SHOULD NOT be used in encapsulation of BFD Echo packets, but it does not say anything about BFD Control packets In the case of echo, there's no guarantee that the traffic will pass through exactly one end system. It's likely that you *could* do this using link locals with appropriate discipline, but Echo packet contents are out of scope for BFD. For async single-hop sessions, you can do this. The BFD implementation obviously needs to take great care to send and receive on the same interface. Some socket implementations made such things a bit tricky in years past. > > b. OSPFv3 for IPv6 always uses link-local IPv6 addresses as the Next Hop addresses of the routes it computes (see RFC 5340, Section 4.8.2). Therefore it looks reasonable to me to use single-hop IPv6 BFD sessions with link-local addresses at least for monitoring OSPFv3 adjacencies > > 2. Section 3 of RFC 5881 states that "there will be only a single BFD session between two systems over a given interface (logical or physical) for a particular protocol". I would like to understand how this requirement can be addressed in the following scenario: > > a. Let us assume that the answer to the question 1 above is positive. > > b. Let's further assume that: > > i. Router A and Router B are connected across a single IPv6 hop (an IPv6 link) > > ii. A single-hop IPv6 BFD session using link-local addresses of the corresponding interfaces has been successfully established > > iii. Globally unique IPv6 addresses have been configured on the interfaces terminating this link in Router A and Router B and have successfully passed the DAD check, i.e., these addresses are assigned and preferred addresses in the terminology of RFC 4862 > > iv. The user (or some application) now tries to set up a single-hop IPv6 BFD session bound to the same interfaces but using globally unique IPv6 addresses assigned to these interfaces FWIW, the implementations I'm familiar with utilize the IP endpoints for the session uniqueness requirements. This means the global addresses would be potentially on a different session than the link locals. > c. Should, under the assumptions above, the implementation prevent formation of an additional single-hop IPv6 BFD session between A and B running across the same link but using assigned globally unique IPv6 addresses of the corresponding interfaces? If yes, how can this be achieved? The difficulty in achieving this is the reason for my comment. One could make a similar observation even in IPv4 when multiple addresses are configured on the same interface. > d. Similar to above, but: > > i. The interfaces connecting Router A and Router B have been assigned with multiple globally unique IPv6 addresses > > ii. A single-hop IPv6 BFD session using one pair of assigned IP addresses of these interfaces has been successfully established > > iii. Should the implementation prevent formation of an additional single-hop IPv6 BFD session between A and B running on the same link but using a different pair of assigned globally unique IP addresses? If yes, how can this be achieved? Same as the IPv4. I wouldn't expect this. This arguably suggests the requirement in 5881 is excessively strict. -- Jeff