From nobody Sun Nov 1 17:25:43 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9171B3FE5 for ; Sun, 1 Nov 2015 17:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id We05na-AcPgF for ; Sun, 1 Nov 2015 17:25:40 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 404E71B3FE3 for ; Sun, 1 Nov 2015 17:25:40 -0800 (PST) Received: from [172.29.64.9] (jplon-nat14.juniper.net [193.110.55.14]) by slice.pfrc.org (Postfix) with ESMTPSA id 926ED1E506; Sun, 1 Nov 2015 20:25:50 -0500 (EST) From: Jeffrey Haas Content-Type: multipart/alternative; boundary="Apple-Mail=_B144C63C-7F20-4A4D-BFBC-6C9B09466443" Message-Id: <0C01CDBF-9B19-46A3-8FE7-85E30B05C2AC@pfrc.org> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Date: Mon, 2 Nov 2015 10:25:32 +0900 Subject: Fwd: NomCom 2015 - Second Request for feedback References: <20151101030818.29117.14633.idtracker@ietfa.amsl.com> To: rtg-bfd@ietf.org X-Mailer: Apple Mail (2.2104) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 01:25:42 -0000 --Apple-Mail=_B144C63C-7F20-4A4D-BFBC-6C9B09466443 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If you're at IETF, you can provide feedback directly to the members of = the nomcom either through the webform, their office hours or look for = people with orange dots. -- Jeff > Begin forwarded message: >=20 > From: NomCom Chair 2015 > Subject: NomCom 2015 - Second Request for feedback > Date: November 1, 2015 at 12:08:18 PM GMT+9 > To: "IETF Announcement List" > Cc: ietf@ietf.org > Reply-To: ietf@ietf.org >=20 > The 2015-16 Nominating Committee has collected a list of willing > candidates for the positions outlined below. You can see the list > at: https://datatracker.ietf.org/nomcom/2015/feedback/ >=20 > You may provide feedback using the web form there; it is secure. > All feedback goes into the datatracker using asymmetric encryption, > which is decrypted by the nomcom members as they read it. So your=20 > feedback can not be seen by the secretariat, the tools people, or any = of the > management. >=20 > Your feedback through the web form is not anonymous as you need a = login to provide it. >=20 > You may also provide feedback by emailing nomcom15@ietf.org, which = enters > the same system through email; it is as non-anonymous as email is, but = I do have=20 > to sort it out. A separate email per candidate is easier to deal = with. >=20 > If you want to give truly anonymous feedback, please contact one of = the=20 > NomCom members that you trust directly, and ask him/her to relay the=20= > feedback anonymously to the NomCom. >=20 > Here in Yokohama, you can find Nomcom members by looking for the = orange dots. >=20 > We are also accessible in room 314 at the Yokohama Nomcom office = hours: >=20 > - Tuesday at 12:45 > - Wednesday at 13:30 >=20 > Feedback is more useful to us the earlier it comes, since we can ask > the candidates about issues raised in feedback if we have it this = week. >=20 > The positions to be filled are those currently held by: >=20 > IAB > - Mary Barnes > - Joe Hildebrand > - Ted Hardie > - Erik Nordmark > - Brian Trammell > - Marc Blanchet >=20 > IESG > - Alissa Cooper (ART) > - Barry Leiba (ART) > - Brian Haberman (Internet) (*) > - Benoit Claise (Operations and Management) > - Alia Atlas (Routing) > - Kathleen Moriarty (Security) > - Martin Stiemerling (Transport) (*) >=20 > Harald Alvestrand, Nomcom chair 2015 > nomcom-chair-2015@ietf.org, hta+nomcom@alvestrand.no --Apple-Mail=_B144C63C-7F20-4A4D-BFBC-6C9B09466443 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii If you're at IETF, you can provide feedback directly to the = members of the nomcom either through the webform, their office hours or = look for people with orange dots.

-- Jeff


Begin = forwarded message:

From: = NomCom Chair 2015 <nomcom-chair-2015@ietf.org>
Subject: = NomCom 2015 - = Second Request for feedback
Date: = November 1, 2015 at 12:08:18 PM = GMT+9
To: = "IETF Announcement List" <ietf-announce@ietf.org>
Cc: ietf@ietf.org
Reply-To: = ietf@ietf.org

The 2015-16 Nominating Committee has = collected a list of willing
candidates for the positions = outlined below.  You can see the list
at: =   https://datatracker.ietf.org/nomcom/2015/feedback/

You may provide feedback using the web form = there; it is secure.
All feedback goes into the = datatracker using asymmetric encryption,
which is = decrypted by the nomcom members as they read it.  So your
feedback can not be seen by the secretariat, the tools = people, or any of the
management.

Your feedback through the web form is not anonymous as you = need a login to provide it.

You may also = provide feedback by emailing nomcom15@ietf.org, which enters
the same = system through email; it is as non-anonymous as email is, but I do have =
to sort it out.  A separate email per candidate is = easier to deal with.

If you want to give = truly anonymous feedback, please contact one of the
NomCom = members that you trust directly, and ask him/her to relay the
feedback anonymously to the NomCom.

Here in Yokohama, you can find Nomcom members by looking for = the orange dots.

We are also accessible in = room 314 at the Yokohama Nomcom office hours:

- Tuesday at 12:45
- Wednesday at 13:30

Feedback is more useful to us the earlier it = comes, since we can ask
the candidates about issues raised = in feedback if we have it this week.

The = positions to be filled are those currently held by:

IAB
- Mary Barnes
- Joe = Hildebrand
- Ted Hardie
- Erik Nordmark
- Brian Trammell
- Marc Blanchet

IESG
- Alissa Cooper (ART)
- Barry Leiba (ART)
- Brian Haberman (Internet) = (*)
- Benoit Claise (Operations and Management)
- Alia Atlas (Routing)
- Kathleen Moriarty = (Security)
- Martin Stiemerling (Transport) (*)

Harald Alvestrand, Nomcom chair 2015
nomcom-chair-2015@ietf.org, hta+nomcom@alvestrand.no

= --Apple-Mail=_B144C63C-7F20-4A4D-BFBC-6C9B09466443-- From nobody Mon Nov 2 18:26:43 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651021ACDB3 for ; Mon, 2 Nov 2015 18:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YROppv9TtubD for ; Mon, 2 Nov 2015 18:26:40 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57711ACD97 for ; Mon, 2 Nov 2015 18:26:40 -0800 (PST) X-AuditID: c6180641-f792c6d00000686a-89-5637ae0275b6 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 99.48.26730.20EA7365; Mon, 2 Nov 2015 19:40:03 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Mon, 2 Nov 2015 21:26:39 -0500 From: Gregory Mirsky To: "rtg-bfd@ietf.org" Subject: Multiple BFD sessions between the same pair of end-points Thread-Topic: Multiple BFD sessions between the same pair of end-points Thread-Index: AdEV3sMqUCCSGTiqTr+ZCWzJplyfOA== Date: Tue, 3 Nov 2015 02:26:37 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221922C58eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXSPty7zOvMwgwerBS0+/9nG6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujHm9n1kK5slUXO2/ydbAeFWii5GTQ0LAROLXsi8sELaYxIV7 69m6GLk4hASOMErMutnGDuEsY5T4/vABO0gVm4CRxIuNPWC2iICmxNo521lBbGEBJ4n3hy8x djFyAMXdJdp7HCFK9CSaN11nBrFZBFQkGuYdZASxeQV8JRa9b2ACsRmBFn8/tQbMZhYQl7j1 ZD4TxEECEkv2nGeGsEUlXj7+xwphK0nMeX2NGaI+X+LHjc1sEDMFJU7OfMIygVFoFpJRs5CU zUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxcpQWp5blphsZbmIEBv4xCTbHHYwL PlkeYhTgYFTi4TVwMg8TYk0sK67MPcQowcGsJML7kssiTIg3JbGyKrUoP76oNCe1+BCjNAeL kjjvvBn3Q4UE0hNLUrNTUwtSi2CyTBycUg2MSaab5uSK3ZHa/GpNUX/AlFlT5sn9vvsuJGDu /1U65vrMtcHL41jKZR0n+SrklZ1cp3jl9oP6sAONCkcT3u1X7bnA4XGn7/4bL2M7bveXYm5N N6Xn/ThRpJHn5TYrZdGEl23mH3Qvl2r0qRyocrow5YF85Kmul++aOr6YzGoRaUibaGK4XXCS EktxRqKhFnNRcSIASEiRb3gCAAA= Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:26:42 -0000 --_000_7347100B5761DC41A166AC17F22DF11221922C58eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, I think that this paragraph from Section 2 of RFC 5881 prohibits multiple s= ingle-hop BFD sessions between the same pair of end points: Each BFD session between a pair of systems MUST traverse a separate network-layer path in both directions. This is necessary for demultiplexing to work properly, and also because (by definition) multiple sessions would otherwise be protecting the same path. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF11221922C58eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

I think that this paragraph from Section 2 of RFC 58= 81 prohibits multiple single-hop BFD sessions between the same pair of end = points:

   Each BFD session between a pair of syst= ems MUST traverse a separate

   network-layer path in both directions.&= nbsp; This is necessary for

   demultiplexing to work properly, and al= so because (by definition)

   multiple sessions would otherwise be pr= otecting the same path.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

 

--_000_7347100B5761DC41A166AC17F22DF11221922C58eusaamb103erics_-- From nobody Mon Nov 2 18:37:56 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159C01B2B5D for ; Mon, 2 Nov 2015 18:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGBeGwqVLJyk for ; Mon, 2 Nov 2015 18:37:54 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 EE3811A8932 for ; Mon, 2 Nov 2015 18:37:53 -0800 (PST) Received: by pasz6 with SMTP id z6so4106603pas.2 for ; Mon, 02 Nov 2015 18:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=NhRe0X+W33vQ3IbcPwRMfr384c0lAVnxXSdfvWWG8vk=; b=Th1FjB803HWX6OeIV64a5WUW4h3Gw3b0ACy0ozTkEfodubdHm6u+1uZFcYbXbh+9SZ OQUSLZhRgXyaItaMqZEw8YuH58j9cJKw7xVS2j0FuyaxP/eik/hbZzt1JOPq8e9ta9lF GT/oWfjLC1bq3v2goCiTwpeu3jOZcT9k65bpEiU35qoTnRml//xsB6UVEA+5JwYjmjp7 tqxb7w287pLjJq54kRUAIKBvMTyDdJPbBZATHrPdkC7wcNx0YNlHbvn6Axv6rGa/kfhI Raxpu4SxVS4TG3EmcSpWUYG59IG8XMoF8/bIurQITkS3VSf0vjgG4VJT+zzrnfB7tlJ3 mb0g== X-Received: by 10.68.234.230 with SMTP id uh6mr31142294pbc.19.1446518273683; Mon, 02 Nov 2015 18:37:53 -0800 (PST) Received: from [192.168.1.10] (c-73-189-176-93.hsd1.ca.comcast.net. [73.189.176.93]) by smtp.gmail.com with ESMTPSA id hl2sm26437775pbb.58.2015.11.02.18.37.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Nov 2015 18:37:53 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3CEC3757-9D78-4C7C-8539-485C02000BBF" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Multiple BFD sessions between the same pair of end-points From: Sam Aldrin In-Reply-To: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> Date: Mon, 2 Nov 2015 18:37:51 -0800 Message-Id: <40871977-8A5D-47BE-B4E4-4F04F8DF41B3@gmail.com> References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> To: Gregory Mirsky X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:37:55 -0000 --Apple-Mail=_3CEC3757-9D78-4C7C-8539-485C02000BBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Does that apply to BFD for VXLAN as well? > On Nov 2, 2015, at 6:26 PM, Gregory Mirsky = wrote: >=20 > Dear All, > I think that this paragraph from Section 2 of RFC 5881 prohibits = multiple single-hop BFD sessions between the same pair of end points: > Each BFD session between a pair of systems MUST traverse a separate > network-layer path in both directions. This is necessary for > demultiplexing to work properly, and also because (by definition) > multiple sessions would otherwise be protecting the same path. > =20 > Regards, > Greg --Apple-Mail=_3CEC3757-9D78-4C7C-8539-485C02000BBF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Does that apply to BFD for VXLAN as well?

On = Nov 2, 2015, at 6:26 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Dear All,
I think that this paragraph from = Section 2 of RFC 5881 prohibits multiple single-hop BFD sessions between = the same pair of end points:
   Each BFD session between a = pair of systems MUST traverse a separate
   network-layer path in both = directions.  This is necessary for
   demultiplexing to work = properly, and also because (by definition)
   multiple sessions would = otherwise be protecting the same path.
 
          &nb= sp;     Regards,
          &nb= sp;            = ;         = Greg

= --Apple-Mail=_3CEC3757-9D78-4C7C-8539-485C02000BBF-- From nobody Mon Nov 2 19:29:01 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E441B2A11 for ; Mon, 2 Nov 2015 19:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVFZfYEcb6Qz for ; Mon, 2 Nov 2015 19:28:58 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 72C2D1B2A0D for ; Mon, 2 Nov 2015 19:28:58 -0800 (PST) Received: by ykdr3 with SMTP id r3so4152038ykd.1 for ; Mon, 02 Nov 2015 19:28:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UU4XB1/pV975X/beVY1TzCoCv+I1sZXoZxyOylQruXM=; b=QE2v291aTEiZXfcEThK5ekx1xVjjpZUvUAbi3YpNRgb2ZYG9kSABRL8pbZG3MUePzc KecAa2XJvXIWGk2MPNj0HSctj7W0weHsdMP4tkvOBYY+U65qC+kRqIZ0H2gHjJcw/iie W0J4UZuVC9OuXVeT9ooOwfx97GAYr6H6evUsxwc1nmj6tapeV7tL3vWGHWdInB1/Y9xB 7j+5URcYrUc/WGiGcsWQ2EXB+lBXxZLrA4tbEA94nT2ASDHB7XlqfA3kDWFawn+lNSE5 m+frVMmJJ8PJuQWCRyJOJdbPOmyqGbszkpRv94QRDAb7o6bNNJp33cQh8oIgnjbvDwbI wrJg== MIME-Version: 1.0 X-Received: by 10.129.104.197 with SMTP id d188mr6407216ywc.219.1446521337759; Mon, 02 Nov 2015 19:28:57 -0800 (PST) Received: by 10.129.114.4 with HTTP; Mon, 2 Nov 2015 19:28:57 -0800 (PST) In-Reply-To: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> Date: Tue, 3 Nov 2015 08:58:57 +0530 Message-ID: Subject: Re: Multiple BFD sessions between the same pair of end-points From: Manav Bhatia To: Gregory Mirsky Content-Type: multipart/alternative; boundary=001a114904a67f4fcd05239a7e0c Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 03:29:00 -0000 --001a114904a67f4fcd05239a7e0c Content-Type: text/plain; charset=UTF-8 And pray what is the context? I presume its got something to do with the BFD WG meeting. Would appreciate some details. I have a counter example of when one may need multiple BFD sessions between the same end-points, but i would like to hear the context before i muddy the waters. Cheers, Manav On Tue, Nov 3, 2015 at 7:56 AM, Gregory Mirsky wrote: > Dear All, > > I think that this paragraph from Section 2 of RFC 5881 prohibits multiple > single-hop BFD sessions between the same pair of end points: > > Each BFD session between a pair of systems MUST traverse a separate > > network-layer path in both directions. This is necessary for > > demultiplexing to work properly, and also because (by definition) > > multiple sessions would otherwise be protecting the same path. > > > > Regards, > > Greg > > > --001a114904a67f4fcd05239a7e0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And pray what is the context? I presume its got something = to do with the BFD WG meeting. Would appreciate some details.

I have a counter example of when one may need multiple BFD sessions b= etween the same end-points, but i would like to hear the context before i m= uddy the waters.

Cheers, Manav

On Tue, Nov 3, 2015 at 7:= 56 AM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Dear All,

I think that this paragraph from Section 2 of RFC 58= 81 prohibits multiple single-hop BFD sessions between the same pair of end = points:

=C2=A0=C2=A0 Each BFD session between a pair of syst= ems MUST traverse a separate

=C2=A0=C2=A0 network-layer path in both directions.= =C2=A0 This is necessary for

=C2=A0=C2=A0 demultiplexing to work properly, and al= so because (by definition)

=C2=A0=C2=A0 multiple sessions would otherwise be pr= otecting the same path.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg=

=C2=A0


--001a114904a67f4fcd05239a7e0c-- From nobody Mon Nov 2 19:50:51 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC251B2C74 for ; Mon, 2 Nov 2015 19:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M72m3iJDq0Oy for ; Mon, 2 Nov 2015 19:50:47 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 2B5501B2C7D for ; Mon, 2 Nov 2015 19:50:40 -0800 (PST) Received: by pacfv9 with SMTP id fv9so6094610pac.3 for ; Mon, 02 Nov 2015 19:50:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=S2gpBWkddSp6CINu9E9ymdpeAYCS8HVXov4NnuYus9s=; b=gRK5Jrd3Wi6Zq/cwo7JypO0tgwaok+lsuhWkaJmeJepk5i8oD6hZPzPotieU9pIZ+/ g3a5HDlImz8zZumx+DtFB5naAqLM8ZlOVVd+WHl3hSMyQUIHhCXMErpf5oik91eY0w9i jnGqo3LpKOcfBRj5IgKHZbBW20Wtc3UNGEm/t4fnQcDk9MyLurHl/FTbS/+0F7uGpOPz BJoItPDVbB7OTMqA1P61YEaiMjH6kn7rzULEnRXvcvb1TOMNWRfTVSBKrHDqkv+ZeTUl KuPFh1oh2ID/mIdJeuMdjaDOcsOuyDkuC1cSGeAno5iWWRVuSK2/xpQ8p/eTDluiSHiM LYQQ== X-Received: by 10.66.172.6 with SMTP id ay6mr31163322pac.44.1446522639785; Mon, 02 Nov 2015 19:50:39 -0800 (PST) Received: from ?IPv6:2001:420:c0c8:1006::188? ([2001:420:c0c8:1006::188]) by smtp.gmail.com with ESMTPSA id rn7sm26798223pab.23.2015.11.02.19.50.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 02 Nov 2015 19:50:39 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_6D15CA00-46D5-4F29-AE50-88B92BCF6611" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Multiple BFD sessions between the same pair of end-points From: Mahesh Jethanandani In-Reply-To: Date: Tue, 3 Nov 2015 12:50:34 +0900 Message-Id: <69FDF0F8-7B6E-4676-9AD0-BF95B182BB21@gmail.com> References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> To: Manav Bhatia X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 03:50:49 -0000 --Apple-Mail=_6D15CA00-46D5-4F29-AE50-88B92BCF6611 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The context was the discussion in the BFD WG on BFD YANG model. The BFD YANG model is struggling with the need to support multiple BFD = sessions between the same endpoints. If 5881 is clear that the BFD = session has to traverse different network-layers, then it helps. I do = not see the need for different time intervals for different applications = as a strong argument to support multiple BFD sessions between the same = endpoints. Applications can choose to ignore a DOWN notification if they = find it too aggressive.=20 > On Nov 3, 2015, at 12:28 PM, Manav Bhatia = wrote: >=20 > And pray what is the context? I presume its got something to do with = the BFD WG meeting. Would appreciate some details. >=20 > I have a counter example of when one may need multiple BFD sessions = between the same end-points, but i would like to hear the context before = i muddy the waters. >=20 > Cheers, Manav >=20 > On Tue, Nov 3, 2015 at 7:56 AM, Gregory Mirsky = > = wrote: > Dear All, >=20 > I think that this paragraph from Section 2 of RFC 5881 prohibits = multiple single-hop BFD sessions between the same pair of end points: >=20 > Each BFD session between a pair of systems MUST traverse a separate >=20 > network-layer path in both directions. This is necessary for >=20 > demultiplexing to work properly, and also because (by definition) >=20 > multiple sessions would otherwise be protecting the same path. >=20 > =20 >=20 > Regards, >=20 > Greg >=20 > =20 >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_6D15CA00-46D5-4F29-AE50-88B92BCF6611 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The context was the discussion in the BFD WG on BFD YANG = model.

The BFD YANG = model is struggling with the need to support multiple BFD sessions = between the same endpoints. If 5881 is clear that the BFD session has to = traverse different network-layers, then it helps. I do not see the need = for different time intervals for different applications as a strong = argument to support multiple BFD sessions between the same endpoints. = Applications can choose to ignore a DOWN notification if they find it = too aggressive. 

On Nov 3, 2015, at 12:28 PM, = Manav Bhatia <manavbhatia@gmail.com> wrote:

And pray what is the context? I presume its got something to = do with the BFD WG meeting. Would appreciate some details.

I have a counter example = of when one may need multiple BFD sessions between the same end-points, = but i would like to hear the context before i muddy the = waters.

Cheers, = Manav

On Tue, Nov 3, 2015 at 7:56 AM, Gregory Mirsky = <gregory.mirsky@ericsson.com> wrote:

Dear All,

I think that this paragraph = from Section 2 of RFC 5881 prohibits multiple single-hop BFD sessions = between the same pair of end points:

   Each BFD session = between a pair of systems MUST traverse a separate

   network-layer = path in both directions.  This is necessary for

   demultiplexing to = work properly, and also because (by definition)

   multiple sessions = would otherwise be protecting the same path.

 

         =        Regards,

         =             &n= bsp;          Greg

 



Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_6D15CA00-46D5-4F29-AE50-88B92BCF6611-- From nobody Mon Nov 2 20:23:06 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C411B2D17 for ; Mon, 2 Nov 2015 20:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQzv77GRfGH1 for ; Mon, 2 Nov 2015 20:23:03 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5C71B2CF3 for ; Mon, 2 Nov 2015 20:23:03 -0800 (PST) X-AuditID: c618062d-f79ef6d000007f54-69-5637d566639c Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 79.D9.32596.665D7365; Mon, 2 Nov 2015 22:28:07 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Mon, 2 Nov 2015 23:23:01 -0500 From: Gregory Mirsky To: Sam Aldrin Subject: RE: Multiple BFD sessions between the same pair of end-points Thread-Topic: Multiple BFD sessions between the same pair of end-points Thread-Index: AdEV3sMqUCCSGTiqTr+ZCWzJplyfOAAK8f2AAAbtVzA= Date: Tue, 3 Nov 2015 04:23:00 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221922D5D@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> <40871977-8A5D-47BE-B4E4-4F04F8DF41B3@gmail.com> In-Reply-To: <40871977-8A5D-47BE-B4E4-4F04F8DF41B3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221922D5Deusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyuXRPuG76VfMwg4kLOSwmtH5htPj8Zxuj A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXx68AvxoJe+4ovKx8zNTBeN+9i5OSQEDCR OHe/lRXCFpO4cG89WxcjF4eQwBFGidamXawQzjJGiU0PJzCDVLEJGEm82NjDDmKLCKhJTJ53 EyzOLKAp0XTiM1hcWMBNYlf3WaBJHEA17hLtPY4Q5VYSB+euZgKxWQRUJF5e3gPWyivgK/Hj xScWiF0NjBIbm1oZQXo5BWwl1k7WB6lhBDru+6k1TBCrxCVuPZnPBHG0gMSSPeeZIWxRiZeP /0E9oyTx8fd8dpAxzAL5Ei3HciBWCUqcnPmEZQKj6Cwkk2YhVM1CUgVRoiOxYPcnNghbW2LZ wtfMMPaZA4+ZkMUXMLKvYuQoLU4ty003MtjECIyoYxJsujsY97y0PMQowMGoxMNbUGUeJsSa WFZcmXuIUYKDWUmE9yWXRZgQb0piZVVqUX58UWlOavEhRmkOFiVx3v1L7ocKCaQnlqRmp6YW pBbBZJk4OKUaGL1FZ3e+aGc8Ulu9ifma4vPfetV3rNy2qPEnL+k1968IVVXP3nzuqKvILN5v +b7/jT6dnmf2V293QbzH/QXzyk5aub930q/6MTvuc1Gw8c+I244VxnNXcAnu+LhRw1NTu/Ge 7qs3t/R6X87USLoYGlvE16TxX+urVcEZrk6df/eOqyz4wRBlqcRSnJFoqMVcVJwIAN/kcB2k AgAA Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 04:23:04 -0000 --_000_7347100B5761DC41A166AC17F22DF11221922D5Deusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sam, if path between two VTEPs of the same VXLAN has entropy that BFD MAY exerci= se, then there MAY be multiple BFD sessions. I see this as closer to 5884cl= arification then to 5881. Regards, Greg From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] Sent: Tuesday, November 03, 2015 11:38 AM To: Gregory Mirsky Cc: rtg-bfd@ietf.org Subject: Re: Multiple BFD sessions between the same pair of end-points Does that apply to BFD for VXLAN as well? On Nov 2, 2015, at 6:26 PM, Gregory Mirsky > wrote: Dear All, I think that this paragraph from Section 2 of RFC 5881 prohibits multiple s= ingle-hop BFD sessions between the same pair of end points: Each BFD session between a pair of systems MUST traverse a separate network-layer path in both directions. This is necessary for demultiplexing to work properly, and also because (by definition) multiple sessions would otherwise be protecting the same path. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF11221922D5Deusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sam,=

if path between two VTEPs= of the same VXLAN has entropy that BFD MAY exercise, then there MAY be mul= tiple BFD sessions. I see this as closer to 5884clarification then to 5881.

 <= /p>

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

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

 <= /p>

From: Sam Aldr= in [mailto:aldrin.ietf@gmail.com]
Sent: Tuesday, November 03, 2015 11:38 AM
To: Gregory Mirsky
Cc: rtg-bfd@ietf.org
Subject: Re: Multiple BFD sessions between the same pair of end-poin= ts

 

Does that apply to BFD for VXLAN as well?=

 

On Nov 2, 2015, at 6:26 PM, Gregory Mirsky <gregory.mirsky@ericsson.com&g= t; wrote:

 

Dear All,

I think that this paragraph from Sectio= n 2 of RFC 5881 prohibits multiple single-hop BFD sessions between the same= pair of end points:

   Each BFD session between a= pair of systems MUST traverse a separate

   network-layer path in both= directions.  This is necessary for

   demultiplexing to work pro= perly, and also because (by definition)

   multiple sessions would ot= herwise be protecting the same path.

 

      &nb= sp;         Regards,

      &nb= sp;            =              Gr= eg

 

--_000_7347100B5761DC41A166AC17F22DF11221922D5Deusaamb103erics_-- From nobody Mon Nov 2 20:26:18 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BB91B2C47 for ; Mon, 2 Nov 2015 20:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51lR0HYUGQta for ; Mon, 2 Nov 2015 20:26:15 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73E71B2D2D for ; Mon, 2 Nov 2015 20:26:14 -0800 (PST) X-AuditID: c6180641-f792c6d00000686a-62-5637ca075760 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A2.B9.26730.70AC7365; Mon, 2 Nov 2015 21:39:36 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Mon, 2 Nov 2015 23:26:13 -0500 From: Gregory Mirsky To: Manav Bhatia Subject: RE: Multiple BFD sessions between the same pair of end-points Thread-Topic: Multiple BFD sessions between the same pair of end-points Thread-Index: AdEV3sMqUCCSGTiqTr+ZCWzJplyfOAAMutuAAAiR8mA= Date: Tue, 3 Nov 2015 04:26:12 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221922D6D@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221922D6Deusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyuXRPuC7HKfMwg8t/hC0uT2pjt/j8Zxuj A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVxZ+ZploJZIRVrp0U3MH4I7GLk5JAQMJG4 t34VI4QtJnHh3nq2LkYuDiGBI4wSi+8/hnKWMUps/3OaCaSKTcBI4sXGHnYQW0RAQ6L1/QFm EJtZQFOi6cRnsLiwgJvEru6zQM0cQDXuEu09jhDlVhIXV04AK2ERUJFo+z0dbCSvgK/E3Ivt LBC7pjBKdOy8AVbEKRAoMeHyLrD5jEDXfT+1hglil7jErSfzmSCuFpBYsuc8M4QtKvHy8T9W CFtJ4uPv+ewQ9fkS207fhlomKHFy5hOWCYyis5CMmoWkbBaSsllAL4C8tn6XPkSJosSU7ofs EDbQ93PmsiOLL2BkX8XIUVqcWpabbmS4iREYU8ck2Bx3MC74ZHmIUYCDUYmH18DJPEyINbGs uDL3EKMEB7OSCO9LLoswId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rzzZtwPFRJITyxJzU5NLUgt gskycXBKNTCG8tkdWxyw+snVJ2ffZyxfFtWxc+qz1DwZGy2ti6/uCLp8UxHLNj0r48Vw9ZjP gxmWBr97pB0mObKsnrimKrA4ZNKxT9f/b2/j2r8sVzyjPPu94VO3fQYfonlnPpa4nZs9g4ed 1f8l0wIWZo8TlRNYvRiWqW7T7+c4fvbIbPPAP8tmeV80Uw9WYinOSDTUYi4qTgQAzQ08rKUC AAA= Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 04:26:16 -0000 --_000_7347100B5761DC41A166AC17F22DF11221922D6Deusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFuYXYsDQpJIHRoaW5rIHRoYXQgdGhlIHF1b3RlIGZyb20gUkZDIDU4ODEgYXBwbGllcyBv bmx5IHRvIHNpbmdsZS1ob3AgKGFuZCBMQUcgdG9vKSBJUFY0L0lQdjYgQkZELCBub3QgdG8gbXVs dGktaG9wIG9yIEJGRCBvdmVyIE1QTFMgTFNQLiBJ4oCZbSB2ZXJ5IG11Y2ggaW50ZXJlc3RlZCB0 byBsZWFybiBhYm91dCB1c2UgY2FzZSB5b3UgaGF2ZSBmb3IgbXVsdGlwbGUgc2luZ2xlIGhvcCBC RkQgc2Vzc2lvbnMuDQoNCiAgICAgICAgICAgICAgICBSZWdhcmRzLA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBHcmVnDQoNCkZyb206IE1hbmF2IEJoYXRpYSBbbWFpbHRvOm1hbmF2 YmhhdGlhQGdtYWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDAzLCAyMDE1IDEyOjI5 IFBNDQpUbzogR3JlZ29yeSBNaXJza3kNCkNjOiBydGctYmZkQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogTXVsdGlwbGUgQkZEIHNlc3Npb25zIGJldHdlZW4gdGhlIHNhbWUgcGFpciBvZiBlbmQtcG9p bnRzDQoNCkFuZCBwcmF5IHdoYXQgaXMgdGhlIGNvbnRleHQ/IEkgcHJlc3VtZSBpdHMgZ290IHNv bWV0aGluZyB0byBkbyB3aXRoIHRoZSBCRkQgV0cgbWVldGluZy4gV291bGQgYXBwcmVjaWF0ZSBz b21lIGRldGFpbHMuDQoNCkkgaGF2ZSBhIGNvdW50ZXIgZXhhbXBsZSBvZiB3aGVuIG9uZSBtYXkg bmVlZCBtdWx0aXBsZSBCRkQgc2Vzc2lvbnMgYmV0d2VlbiB0aGUgc2FtZSBlbmQtcG9pbnRzLCBi dXQgaSB3b3VsZCBsaWtlIHRvIGhlYXIgdGhlIGNvbnRleHQgYmVmb3JlIGkgbXVkZHkgdGhlIHdh dGVycy4NCg0KQ2hlZXJzLCBNYW5hdg0KDQpPbiBUdWUsIE5vdiAzLCAyMDE1IGF0IDc6NTYgQU0s IEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208bWFpbHRvOmdyZWdv cnkubWlyc2t5QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KRGVhciBBbGwsDQpJIHRoaW5rIHRoYXQg dGhpcyBwYXJhZ3JhcGggZnJvbSBTZWN0aW9uIDIgb2YgUkZDIDU4ODEgcHJvaGliaXRzIG11bHRp cGxlIHNpbmdsZS1ob3AgQkZEIHNlc3Npb25zIGJldHdlZW4gdGhlIHNhbWUgcGFpciBvZiBlbmQg cG9pbnRzOg0KICAgRWFjaCBCRkQgc2Vzc2lvbiBiZXR3ZWVuIGEgcGFpciBvZiBzeXN0ZW1zIE1V U1QgdHJhdmVyc2UgYSBzZXBhcmF0ZQ0KICAgbmV0d29yay1sYXllciBwYXRoIGluIGJvdGggZGly ZWN0aW9ucy4gIFRoaXMgaXMgbmVjZXNzYXJ5IGZvcg0KICAgZGVtdWx0aXBsZXhpbmcgdG8gd29y ayBwcm9wZXJseSwgYW5kIGFsc28gYmVjYXVzZSAoYnkgZGVmaW5pdGlvbikNCiAgIG11bHRpcGxl IHNlc3Npb25zIHdvdWxkIG90aGVyd2lzZSBiZSBwcm90ZWN0aW5nIHRoZSBzYW1lIHBhdGguDQoN CiAgICAgICAgICAgICAgICBSZWdhcmRzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBHcmVnDQoNCg0K --_000_7347100B5761DC41A166AC17F22DF11221922D6Deusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTWFuYXYsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhhdCB0aGUgcXVvdGUgZnJvbSBSRkMg NTg4MSBhcHBsaWVzIG9ubHkgdG8gc2luZ2xlLWhvcCAoYW5kIExBRyB0b28pIElQVjQvSVB2NiBC RkQsIG5vdCB0byBtdWx0aS1ob3Agb3IgQkZEIG92ZXIgTVBMUyBMU1AuIEnigJltIHZlcnkgbXVj aCBpbnRlcmVzdGVkDQogdG8gbGVhcm4gYWJvdXQgdXNlIGNhc2UgeW91IGhhdmUgZm9yIG11bHRp cGxlIHNpbmdsZSBob3AgQkZEIHNlc3Npb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBHcmVnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBNYW5hdiBCaGF0aWEgW21haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gVHVlc2RheSwgTm92ZW1iZXIgMDMsIDIwMTUgMTI6MjkgUE08YnI+DQo8Yj5U bzo8L2I+IEdyZWdvcnkgTWlyc2t5PGJyPg0KPGI+Q2M6PC9iPiBydGctYmZkQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBNdWx0aXBsZSBCRkQgc2Vzc2lvbnMgYmV0d2VlbiB0aGUg c2FtZSBwYWlyIG9mIGVuZC1wb2ludHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BbmQgcHJheSB3aGF0IGlzIHRoZSBjb250ZXh0PyBJIHByZXN1bWUgaXRzIGdvdCBzb21l dGhpbmcgdG8gZG8gd2l0aCB0aGUgQkZEIFdHIG1lZXRpbmcuIFdvdWxkIGFwcHJlY2lhdGUgc29t ZSBkZXRhaWxzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBoYXZlIGEgY291bnRlciBleGFtcGxlIG9mIHdoZW4gb25lIG1heSBuZWVkIG11bHRpcGxlIEJG RCBzZXNzaW9ucyBiZXR3ZWVuIHRoZSBzYW1lIGVuZC1wb2ludHMsIGJ1dCBpIHdvdWxkIGxpa2Ug dG8gaGVhciB0aGUgY29udGV4dCBiZWZvcmUgaSBtdWRkeSB0aGUgd2F0ZXJzLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsIE1hbmF2 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFR1ZSwgTm92IDMsIDIwMTUgYXQgNzo1NiBBTSwgR3JlZ29yeSBNaXJza3kgJmx0OzxhIGhyZWY9 Im1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5ncmVn b3J5Lm1pcnNreUBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5EZWFyIEFsbCw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayB0aGF0IHRoaXMgcGFyYWdyYXBoIGZy b20gU2VjdGlvbiAyIG9mIFJGQyA1ODgxIHByb2hpYml0cyBtdWx0aXBsZSBzaW5nbGUtaG9wIEJG RCBzZXNzaW9ucyBiZXR3ZWVuIHRoZSBzYW1lIHBhaXIgb2YgZW5kIHBvaW50czo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IEVhY2ggQkZEIHNlc3Np b24gYmV0d2VlbiBhIHBhaXIgb2Ygc3lzdGVtcyBNVVNUIHRyYXZlcnNlIGEgc2VwYXJhdGU8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IG5ldHdvcmst bGF5ZXIgcGF0aCBpbiBib3RoIGRpcmVjdGlvbnMuJm5ic3A7IFRoaXMgaXMgbmVjZXNzYXJ5IGZv cjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgZGVt dWx0aXBsZXhpbmcgdG8gd29yayBwcm9wZXJseSwgYW5kIGFsc28gYmVjYXVzZSAoYnkgZGVmaW5p dGlvbik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7 IG11bHRpcGxlIHNlc3Npb25zIHdvdWxkIG90aGVyd2lzZSBiZSBwcm90ZWN0aW5nIHRoZSBzYW1l IHBhdGguPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_7347100B5761DC41A166AC17F22DF11221922D6Deusaamb103erics_-- From nobody Mon Nov 2 20:46:57 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A036F1B2DBF for ; Mon, 2 Nov 2015 20:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnHfpyz8sdkJ for ; Mon, 2 Nov 2015 20:46:56 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D076E1B2DAE for ; Mon, 2 Nov 2015 20:46:55 -0800 (PST) Received: from [172.29.64.52] (jplon-nat12.juniper.net [193.110.55.12]) by slice.pfrc.org (Postfix) with ESMTPSA id 9EF181E50A; Mon, 2 Nov 2015 23:47:09 -0500 (EST) Subject: Re: Multiple BFD sessions between the same pair of end-points Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_73A37D6F-614C-4952-AEEF-07285B33BEBA" From: Jeffrey Haas In-Reply-To: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> Date: Tue, 3 Nov 2015 13:46:47 +0900 Message-Id: References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> To: Gregory Mirsky X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 04:46:56 -0000 --Apple-Mail=_73A37D6F-614C-4952-AEEF-07285B33BEBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greg, > On Nov 3, 2015, at 11:26 AM, Gregory Mirsky = wrote: >=20 > Dear All, > I think that this paragraph from Section 2 of RFC 5881 prohibits = multiple single-hop BFD sessions between the same pair of end points: > Each BFD session between a pair of systems MUST traverse a separate > network-layer path in both directions. This is necessary for > demultiplexing to work properly, and also because (by definition) > multiple sessions would otherwise be protecting the same path. It does. It will require additional bootstrapping procedures similar to = LSPing. -- Jeff > =20 > Regards, > Greg > =20 --Apple-Mail=_73A37D6F-614C-4952-AEEF-07285B33BEBA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Greg,

On Nov 3, 2015, at 11:26 AM, = Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Dear All,

I think that this paragraph = from Section 2 of RFC 5881 prohibits multiple single-hop BFD sessions = between the same pair of end points:

   Each BFD session between a pair of = systems MUST traverse a separate

   network-layer path in both = directions.  This is necessary for

   demultiplexing to work properly, and = also because (by definition)

   multiple sessions would otherwise be = protecting the same path.


It does.  It will require additional bootstrapping = procedures similar to LSPing.

-- = Jeff

 

         =        Regards,

         =             &n= bsp;          Greg

 


= --Apple-Mail=_73A37D6F-614C-4952-AEEF-07285B33BEBA-- From nobody Mon Nov 2 20:55:51 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EF91B2DA6 for ; Mon, 2 Nov 2015 20:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIALNM2TZOe6 for ; Mon, 2 Nov 2015 20:55:48 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F9811A1BCF for ; Mon, 2 Nov 2015 20:55:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5910; q=dns/txt; s=iport; t=1446526549; x=1447736149; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=lF51SqsM1WseNh+/Y8BGX5alLk8pAYgt8i9LSLsGFxY=; b=B6ELvW7quJt/yiyd1BGbdBP9LTKN5MoVMUpN0HFjDZb/dkMbG1p3MynM Bb8+k7zD8m7TFRqMNPE7gY386GI/FnJ06o3ptNj3Gl7zBC6QduiXoUPgB J3qTz4Gx4e1N2JWm4vr2ghKhpBkhtm011FLByFVAr+JIpX75NfLYtJzOG E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D1AQCPPThW/49dJa1egm5NU28Gv0YBDYFahhkCgTg4FAEBAQEBAQGBCoQ1AQEBBC1cAgEIEQQBASgHMhQJCAEBBAESCIgowVABAQEBAQEBAQEBAQEBAQEBAQEBAQEYhneEfoUUhCwFlkMBjR2BYJZwg3EBHwEBQoQEcoR3gQcBAQE X-IronPort-AV: E=Sophos; i="5.20,237,1444694400"; d="scan'208,217"; a="43382731" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP; 03 Nov 2015 04:55:48 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id tA34tlMj011920 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Nov 2015 04:55:47 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 Nov 2015 22:55:47 -0600 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.000; Mon, 2 Nov 2015 22:55:46 -0600 From: "Les Ginsberg (ginsberg)" To: Gregory Mirsky , "rtg-bfd@ietf.org" Subject: RE: Multiple BFD sessions between the same pair of end-points Thread-Topic: Multiple BFD sessions between the same pair of end-points Thread-Index: AdEV3sMqUCCSGTiqTr+ZCWzJplyfOAAFMl0Q Date: Tue, 3 Nov 2015 04:55:46 +0000 Message-ID: <3a5269ad733a4bce8dab973ca9772e6b@XCH-ALN-001.cisco.com> References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.189.220] Content-Type: multipart/alternative; boundary="_000_3a5269ad733a4bce8dab973ca9772e6bXCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 04:55:50 -0000 --_000_3a5269ad733a4bce8dab973ca9772e6bXCHALN001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg - I agree with your characterization. I would also suggest that RFC 5883 Section 4.1 makes the same statement for= multi-hop BFD - at least from the standpoint of L3 clients. Les From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Monday, November 02, 2015 6:27 PM To: rtg-bfd@ietf.org Subject: Multiple BFD sessions between the same pair of end-points Dear All, I think that this paragraph from Section 2 of RFC 5881 prohibits multiple s= ingle-hop BFD sessions between the same pair of end points: Each BFD session between a pair of systems MUST traverse a separate network-layer path in both directions. This is necessary for demultiplexing to work properly, and also because (by definition) multiple sessions would otherwise be protecting the same path. Regards, Greg --_000_3a5269ad733a4bce8dab973ca9772e6bXCHALN001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg –

 

I agree with your char= acterization.

 

I would also suggest t= hat RFC 5883 Section 4.1 makes the same statement for multi-hop BFD  &= #8211; at least from the standpoint of L3 clients.

 

   Les<= /o:p>

 

 

From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Monday, November 02, 2015 6:27 PM
To: rtg-bfd@ietf.org
Subject: Multiple BFD sessions between the same pair of end-points

 

Dear All,

I think that this paragraph from Section 2 of RFC 58= 81 prohibits multiple single-hop BFD sessions between the same pair of end = points:

   Each BFD session between a pair of syst= ems MUST traverse a separate

   network-layer path in both directions.&= nbsp; This is necessary for

   demultiplexing to work properly, and al= so because (by definition)

   multiple sessions would otherwise be pr= otecting the same path.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

 

--_000_3a5269ad733a4bce8dab973ca9772e6bXCHALN001ciscocom_-- From nobody Mon Nov 2 21:07:01 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0671B2E30 for ; Mon, 2 Nov 2015 21:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8qDDBNuNI_x for ; Mon, 2 Nov 2015 21:06:55 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89831B2E2D for ; Mon, 2 Nov 2015 21:06:54 -0800 (PST) Received: by ykba4 with SMTP id a4so5501201ykb.3 for ; Mon, 02 Nov 2015 21:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XymA9nLUybKjoauCGFYRnZo8hBPmkI/t4/+l3bDR4n4=; b=ZbvQnCx30jjRspXnA2nMkFkj0DPb/LpRREehuJIFBc97I7N6xj099WyOfh3thnn7fS jtyeuLzePGE9C/OAxqN67R7qJk0c74GLajqrHzCVF6HzT2wGU0bbhKMqemm1ES4Ax0oy LHRZSNnbK/5wIRphFeKlN0ebFobhUt4v0a+J90QKLC6tylVEXii0bD9esH2u03l5qOUm dEj+yIyO8qS9dSE4eIhIao5VL/iwvXzQR/NBvaaMBBpAC8HIJmTNUXoWm5/MG1XHOj2E J2b44G3MBdd0UAZ/Aj1gEcdLzeNsCA8DXjsZfh8F+z1mCc4u8x1vK5b0ymgRXAdQbra7 EHDQ== MIME-Version: 1.0 X-Received: by 10.129.104.197 with SMTP id d188mr6606369ywc.219.1446527214208; Mon, 02 Nov 2015 21:06:54 -0800 (PST) Received: by 10.129.114.4 with HTTP; Mon, 2 Nov 2015 21:06:54 -0800 (PST) In-Reply-To: <7347100B5761DC41A166AC17F22DF11221922D6D@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221922D6D@eusaamb103.ericsson.se> Date: Tue, 3 Nov 2015 10:36:54 +0530 Message-ID: Subject: Re: Multiple BFD sessions between the same pair of end-points From: Manav Bhatia To: Gregory Mirsky Content-Type: multipart/alternative; boundary=001a114904a6c2cb7a05239bdc17 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 05:06:59 -0000 --001a114904a6c2cb7a05239bdc17 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I had a BFD session over an MPLS LSP in my mind, which i understand is outside the scope. Cheers, Manav On Tue, Nov 3, 2015 at 9:56 AM, Gregory Mirsky wrote: > Hi Manav, > > I think that the quote from RFC 5881 applies only to single-hop (and LAG > too) IPV4/IPv6 BFD, not to multi-hop or BFD over MPLS LSP. I=E2=80=99m ve= ry much > interested to learn about use case you have for multiple single hop BFD > sessions. > > > > Regards, > > Greg > > > > *From:* Manav Bhatia [mailto:manavbhatia@gmail.com] > *Sent:* Tuesday, November 03, 2015 12:29 PM > *To:* Gregory Mirsky > *Cc:* rtg-bfd@ietf.org > *Subject:* Re: Multiple BFD sessions between the same pair of end-points > > > > And pray what is the context? I presume its got something to do with the > BFD WG meeting. Would appreciate some details. > > > > I have a counter example of when one may need multiple BFD sessions > between the same end-points, but i would like to hear the context before = i > muddy the waters. > > > > Cheers, Manav > > > > On Tue, Nov 3, 2015 at 7:56 AM, Gregory Mirsky < > gregory.mirsky@ericsson.com> wrote: > > Dear All, > > I think that this paragraph from Section 2 of RFC 5881 prohibits multiple > single-hop BFD sessions between the same pair of end points: > > Each BFD session between a pair of systems MUST traverse a separate > > network-layer path in both directions. This is necessary for > > demultiplexing to work properly, and also because (by definition) > > multiple sessions would otherwise be protecting the same path. > > > > Regards, > > Greg > > > > > --001a114904a6c2cb7a05239bdc17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I had a BFD session over an MPLS LSP in my mind, which i u= nderstand is outside the scope.

Cheers, Manav

On Tue, Nov 3, 2= 015 at 9:56 AM, Gregory Mirsky <gregory.mirsky@ericsson.com&= gt; wrote:

Hi Manav,

I think that the quote fr= om RFC 5881 applies only to single-hop (and LAG too) IPV4/IPv6 BFD, not to = multi-hop or BFD over MPLS LSP. I=E2=80=99m very much interested to learn about use case you have for multiple single hop BFD sessions.<= /u>

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,=

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: Manav Bh= atia [mailto:man= avbhatia@gmail.com]
Sent: Tuesday, November 03, 2015 12:29 PM
To: Gregory Mirsky
Cc: rtg-bfd@ie= tf.org
Subject: Re: Multiple BFD sessions between the same pair of e= nd-points

=C2=A0

And pray what is the context? I presume its got some= thing to do with the BFD WG meeting. Would appreciate some details.<= u>

=C2=A0

I have a counter example of when one may need multip= le BFD sessions between the same end-points, but i would like to hear the c= ontext before i muddy the waters.

=C2=A0

Cheers, Manav

=C2=A0

On Tue, Nov 3, 2015 at 7:56 AM, Gregory Mirsky <<= a href=3D"mailto:gregory.mirsky@ericsson.com" target=3D"_blank">gregory.mir= sky@ericsson.com> wrote:

Dear All,

I think that this paragraph from Section 2 of RFC 58= 81 prohibits multiple single-hop BFD sessions between the same pair of end = points:

=C2=A0=C2=A0 Each BFD session between a pair of syst= ems MUST traverse a separate

=C2=A0=C2=A0 network-layer path in both directions.= =C2=A0 This is necessary for

=C2=A0=C2=A0 demultiplexing to work properly, and al= so because (by definition)

=C2=A0=C2=A0 multiple sessions would otherwise be pr= otecting the same path.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg=

=C2=A0

=C2=A0


--001a114904a6c2cb7a05239bdc17-- From nobody Mon Nov 2 21:22:33 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63E61B2E54 for ; Mon, 2 Nov 2015 21:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HjGAvDI_uxP for ; Mon, 2 Nov 2015 21:22:30 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0760.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::760]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0E91B2E31 for ; Mon, 2 Nov 2015 21:22:30 -0800 (PST) Received: from SN1PR0501MB2142.namprd05.prod.outlook.com (10.163.228.157) by SN1PR0501MB2142.namprd05.prod.outlook.com (10.163.228.157) with Microsoft SMTP Server (TLS) id 15.1.312.18; Tue, 3 Nov 2015 05:22:23 +0000 Received: from SN1PR0501MB2142.namprd05.prod.outlook.com ([10.163.228.157]) by SN1PR0501MB2142.namprd05.prod.outlook.com ([10.163.228.157]) with mapi id 15.01.0312.014; Tue, 3 Nov 2015 05:22:23 +0000 From: Santosh P K To: Gregory Mirsky , "rtg-bfd@ietf.org" Subject: RE: Multiple BFD sessions between the same pair of end-points Thread-Topic: Multiple BFD sessions between the same pair of end-points Thread-Index: AdEV3sMqUCCSGTiqTr+ZCWzJplyfOAAGH5Kg Date: Tue, 3 Nov 2015 05:22:23 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=santoshpk@juniper.net; x-originating-ip: [116.197.184.12] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB2142; 5:CmBVMYcjeuZbmSIqvrTymnAb9vgELou530og4kvY9aAngg6OAHjwnocQG1XRiKtSBRmHg6ukmkI75IWAgWJ0UIclmCQ0jItMmfGr2C25LNIApQ/E8xNMMAxjWbFEz8Uv9isM/LRHlLdcFi/EffX7sA==; 24:WCbEkMKoESB5tbDv9jRoR9KaI5z1V37ipp+WdOmLnFdDfSE48W+8vRrqjYQ3rv+6JDbLGqBgWUqeShDEzBrDRkF7lNdqp3qv1tIpBsaPy60=; 20:2vTX26tOJzveuBtoh/aewO2ZgxfynmuBuxszWgsKJL9/Rhdkfu+bu4dap1JsjMyn7UodjWY6Scvs5JSv8xrqQA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB2142; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:SN1PR0501MB2142; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2142; x-forefront-prvs: 0749DC2CE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(199003)(51444003)(16236675004)(5001960100002)(76176999)(40100003)(107886002)(2950100001)(76576001)(87936001)(99286002)(54356999)(122556002)(19580405001)(74316001)(19625215002)(19300405004)(105586002)(77096005)(5002640100001)(102836002)(66066001)(92566002)(19580395003)(106356001)(50986999)(189998001)(5003600100002)(33656002)(97736004)(5001920100001)(81156007)(101416001)(2501003)(11100500001)(5001770100001)(86362001)(15975445007)(10400500002)(5004730100002)(2900100001)(5007970100001)(5008740100001)(19609705001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2142; H:SN1PR0501MB2142.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0501MB21427BFE77B517066E295DCFB32B0SN1PR0501MB2142_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2015 05:22:23.3293 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2142 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 05:22:32 -0000 --_000_SN1PR0501MB21427BFE77B517066E295DCFB32B0SN1PR0501MB2142_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, This statement does not say multiple BFD session on the "same interface"= between two system right? It just says that we can have multiple BFD sessi= on between two systems probably on different interface who are directly con= nected. In this case you can still have interface as a key to identify init= ial BFD packet. Thanks Santosh P K From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Tuesday, November 03, 2015 7:57 AM To: rtg-bfd@ietf.org Subject: Multiple BFD sessions between the same pair of end-points Dear All, I think that this paragraph from Section 2 of RFC 5881 prohibits multiple s= ingle-hop BFD sessions between the same pair of end points: Each BFD session between a pair of systems MUST traverse a separate network-layer path in both directions. This is necessary for demultiplexing to work properly, and also because (by definition) multiple sessions would otherwise be protecting the same path. Regards, Greg --_000_SN1PR0501MB21427BFE77B517066E295DCFB32B0SN1PR0501MB2142_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg,

   This stat= ement does not say multiple BFD session on the “same interface”= between two system right? It just says that we can have multiple BFD sessi= on between two systems probably on different interface who are directly connected. In this case you can still have interface as a key= to identify initial BFD packet.

 

 

Thanks

Santosh P K

 

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.or= g] On Behalf Of Gregory Mirsky
Sent: Tuesday, November 03, 2015 7:57 AM
To: rtg-bfd@ietf.org
Subject: Multiple BFD sessions between the same pair of end-points

 

Dear All,

I think that this paragraph from Section 2 of RFC 58= 81 prohibits multiple single-hop BFD sessions between the same pair of end = points:

   Each BFD session between a pair of syst= ems MUST traverse a separate

   network-layer path in both directions.&= nbsp; This is necessary for

   demultiplexing to work properly, and al= so because (by definition)

   multiple sessions would otherwise be pr= otecting the same path.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

 

--_000_SN1PR0501MB21427BFE77B517066E295DCFB32B0SN1PR0501MB2142_-- From nobody Mon Nov 2 21:25:48 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87291A1BEF for ; Mon, 2 Nov 2015 21:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjEicPqqtpJk for ; Mon, 2 Nov 2015 21:25:45 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2FDD1A3B9B for ; Mon, 2 Nov 2015 21:25:44 -0800 (PST) Received: from SN1PR0501MB2142.namprd05.prod.outlook.com (10.163.228.157) by SN1PR0501MB2142.namprd05.prod.outlook.com (10.163.228.157) with Microsoft SMTP Server (TLS) id 15.1.312.18; Tue, 3 Nov 2015 05:25:27 +0000 Received: from SN1PR0501MB2142.namprd05.prod.outlook.com ([10.163.228.157]) by SN1PR0501MB2142.namprd05.prod.outlook.com ([10.163.228.157]) with mapi id 15.01.0312.014; Tue, 3 Nov 2015 05:25:27 +0000 From: Santosh P K To: Gregory Mirsky , "rtg-bfd@ietf.org" Subject: RE: Multiple BFD sessions between the same pair of end-points Thread-Topic: Multiple BFD sessions between the same pair of end-points Thread-Index: AdEV3sMqUCCSGTiqTr+ZCWzJplyfOAAGR8Bg Date: Tue, 3 Nov 2015 05:25:27 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=santoshpk@juniper.net; x-originating-ip: [116.197.184.12] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB2142; 5:RgOj5Ja3W6tgeISLHZISBDDTzzLGGfigSiVx6woNcbEn8KpuGSyaUsd4Xx1NR6huxLgEJ6gcZ87p0LWVcqHPHxR0L4PZKmja07EoDvKlSOgS3UI3btZ3vLCsf2HCa9gaJ4pgpMcCRv7Gc6HrQ/JtLg==; 24:NHoDGcVwnDfdS7ErveqL3GgbiCL90jm0/1127mjVRaiiArl5hkC7rFtfClFPl092T90ZQTyAbSQpyL8eAg7/Io9C2EJXmd8PvDU7L2rpRqs=; 20:mBpD0xHUExeID6Ow1Cy+M/sT2KvWmsiql6PJ5EbLevrdGwZTtiW9s/4M9j55PFK91Cr3fj96lPwwDFjDs+AJSg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB2142; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:SN1PR0501MB2142; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2142; x-forefront-prvs: 0749DC2CE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(199003)(51444003)(16236675004)(5001960100002)(76176999)(40100003)(107886002)(2950100001)(76576001)(87936001)(99286002)(54356999)(122556002)(19580405001)(74316001)(19625215002)(19300405004)(105586002)(77096005)(5002640100001)(102836002)(66066001)(92566002)(19580395003)(106356001)(50986999)(189998001)(5003600100002)(33656002)(97736004)(5001920100001)(81156007)(101416001)(2501003)(11100500001)(5001770100001)(86362001)(15975445007)(10400500002)(5004730100002)(2900100001)(5007970100001)(5008740100001)(19609705001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2142; H:SN1PR0501MB2142.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0501MB2142E591071CCFD4AE6EBE65B32B0SN1PR0501MB2142_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2015 05:25:27.6334 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2142 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 05:25:47 -0000 --_000_SN1PR0501MB2142E591071CCFD4AE6EBE65B32B0SN1PR0501MB2142_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is form RFC 5881 section 3. In this application, there will be only a single BFD session between two systems over a given interface (logical or physical) for a particular protocol. The BFD session must be bound to this interface. Which says for singlehop you will have only single BFD session for an inter= face. The case where we are struggling in Yang is for multihop BFD session= . Thanks Santosh P K From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Tuesday, November 03, 2015 7:57 AM To: rtg-bfd@ietf.org Subject: Multiple BFD sessions between the same pair of end-points Dear All, I think that this paragraph from Section 2 of RFC 5881 prohibits multiple s= ingle-hop BFD sessions between the same pair of end points: Each BFD session between a pair of systems MUST traverse a separate network-layer path in both directions. This is necessary for demultiplexing to work properly, and also because (by definition) multiple sessions would otherwise be protecting the same path. Regards, Greg --_000_SN1PR0501MB2142E591071CCFD4AE6EBE65B32B0SN1PR0501MB2142_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is form RFC 5881 = section 3.

 

In this app= lication, there will be only a single BFD session between=

  = ; two systems over a given interface (logical or physical) for a=

  = ; particular protocol.  The BFD session must be bound to this

  = ; interface.

 

Which says for singleh= op you will have only single BFD session for an interface.  The case w= here we are struggling in Yang is for multihop BFD session.

 

Thanks

Santosh P K

 

 

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.or= g] On Behalf Of Gregory Mirsky
Sent: Tuesday, November 03, 2015 7:57 AM
To: rtg-bfd@ietf.org
Subject: Multiple BFD sessions between the same pair of end-points

 

Dear All,

I think that this paragraph from Section 2 of RFC 58= 81 prohibits multiple single-hop BFD sessions between the same pair of end = points:

   Each BFD session between a pair of syst= ems MUST traverse a separate

   network-layer path in both directions.&= nbsp; This is necessary for

   demultiplexing to work properly, and al= so because (by definition)

   multiple sessions would otherwise be pr= otecting the same path.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

 

--_000_SN1PR0501MB2142E591071CCFD4AE6EBE65B32B0SN1PR0501MB2142_-- From nobody Mon Nov 2 21:30:13 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CE71ACE15 for ; Mon, 2 Nov 2015 21:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgHy_Y11jawK for ; Mon, 2 Nov 2015 21:29:58 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B031ACE08 for ; Mon, 2 Nov 2015 21:29:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10243; q=dns/txt; s=iport; t=1446528598; x=1447738198; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=/M1DYmd9mygL/ADcrsroGA4MC3PmrUp5rRed2Jjxt5k=; b=XqKD3x7JLE2uJCprRhqqdYff4jkoDDHQ+07AqKixb96EKkZVN2cVb8rZ o07E8SxMRGKXs2ecsqrTpdJQWAy1YvSUFwe2Snk6LwTEXInY1bVvH3nPy 1iI2vDm9nD7lF0wh0Hkb50wnJ3rPokLkT8SZ6bdt6eoaB34a+AIxX15Ao 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D1AQAORThW/4wNJK1egm5NU28Gv0YBDYFahhkCgTY4FAEBAQEBAQGBCoQ1AQEBBC1cAgEIEQMBAQEoBzIUCQgBAQQBEogwwUsBAQEBAQEBAQEBAQEBAQEBAQEBAQEYhneEfoR+FoQsBY1UhRKDXQGNJJw6AR8BAUKEBHKEd4EHAQEB X-IronPort-AV: E=Sophos; i="5.20,237,1444694400"; d="scan'208,217"; a="41402911" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP; 03 Nov 2015 05:29:56 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id tA35Tusd032067 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Nov 2015 05:29:56 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 Nov 2015 23:29:55 -0600 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.000; Mon, 2 Nov 2015 23:29:55 -0600 From: "Reshad Rahman (rrahman)" To: Santosh P K , Gregory Mirsky , "rtg-bfd@ietf.org" Subject: Re: Multiple BFD sessions between the same pair of end-points Thread-Topic: Multiple BFD sessions between the same pair of end-points Thread-Index: AdEV3sMqUCCSGTiqTr+ZCWzJplyfOAAGR8BgAB2IA4A= Date: Tue, 3 Nov 2015 05:29:55 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.243.140] Content-Type: multipart/alternative; boundary="_000_D25E74B4101627rrahmanciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 05:30:00 -0000 --_000_D25E74B4101627rrahmanciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Santosh, Even for single-hop we had discussions about implementations which support = the option of having multiple BFD single-hop sessions on 1 interface betwee= n 2 endpoints. That was an argument for having the BFD config in routing a= pplications. This is what was discussed today in the WG. And I think Greg's= point is that we don't have to support this in the base model, but impleme= ntations are have vendor specific model which supports this behaviour. Regards, Reshad. From: Rtg-bfd > o= n behalf of Santosh P K > Date: Tuesday, November 3, 2015 at 1:25 AM To: Gregory Mirsky >, "rtg-bfd@ietf.org" > Subject: RE: Multiple BFD sessions between the same pair of end-points This is form RFC 5881 section 3. In this application, there will be only a single BFD session between two systems over a given interface (logical or physical) for a particular protocol. The BFD session must be bound to this interface. Which says for singlehop you will have only single BFD session for an inter= face. The case where we are struggling in Yang is for multihop BFD session= . Thanks Santosh P K From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Tuesday, November 03, 2015 7:57 AM To: rtg-bfd@ietf.org Subject: Multiple BFD sessions between the same pair of end-points Dear All, I think that this paragraph from Section 2 of RFC 5881 prohibits multiple s= ingle-hop BFD sessions between the same pair of end points: Each BFD session between a pair of systems MUST traverse a separate network-layer path in both directions. This is necessary for demultiplexing to work properly, and also because (by definition) multiple sessions would otherwise be protecting the same path. Regards, Greg --_000_D25E74B4101627rrahmanciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <352D553FE6CF144DB1FA027B4EDB1832@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Santosh,

Even for single-hop we had discussions about implementations which sup= port the option of having multiple BFD single-hop sessions on 1 interface b= etween 2  endpoints. That was an argument for having the BFD config in= routing applications. This is what was discussed today in the WG. And I think Greg’s point is that we don&#= 8217;t have to support this in the base model, but implementations are have= vendor specific model which supports this behaviour.

Regards,
Reshad.


From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Sa= ntosh P K <santoshpk@juniper.ne= t>
Date: Tuesday, November 3, 2015 at = 1:25 AM
To: Gregory Mirsky <gregory.mirsky@ericsson.com>, &qu= ot;rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: Multiple BFD sessions = between the same pair of end-points

This is form RFC 5881 = section 3.

 

In this applicati= on, there will be only a single BFD session between

   two = systems over a given interface (logical or physical) for a

   part= icular protocol.  The BFD session must be bound to this

   inte= rface.

 

Which says for singleh= op you will have only single BFD session for an interface.  The case w= here we are struggling in Yang is for multihop BFD session.

 

Thanks

Santosh P K

 

 

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Tuesday, November 03, 2015 7:57 AM
To: rtg-bfd@ietf.org
Subject: Multiple BFD sessions between the same pair of end-points

 

Dear All,

I think that this paragraph from Section 2 of RFC 58= 81 prohibits multiple single-hop BFD sessions between the same pair of end = points:

   Each BFD session between a pair of syst= ems MUST traverse a separate

   network-layer path in both directions.&= nbsp; This is necessary for

   demultiplexing to work properly, and al= so because (by definition)

   multiple sessions would otherwise be pr= otecting the same path.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

 

 --_000_D25E74B4101627rrahmanciscocom_-- From nobody Mon Nov 2 22:48:24 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215831B2EC3 for ; Mon, 2 Nov 2015 22:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfUhqRCQ3pdr for ; Mon, 2 Nov 2015 22:48:20 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7CA1B2EC2 for ; Mon, 2 Nov 2015 22:48:20 -0800 (PST) Received: by pasz6 with SMTP id z6so9941635pas.2 for ; Mon, 02 Nov 2015 22:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=XJN9flEXSap37PhW/iCJlrXgjZtCUPki7TNBhe2HHA0=; b=0F7+1n88QUJkd6SvE+J4cyJEqWBVfSnsULCi8ROyg9qpdvVpwbNUfJmMuXyZX5LXmb 5UmoBKAm2RbnIvkoYM7GsPYEcOYrUKdwZd9JBQbGRS7n2qqqFoNy3uVw7xcW1vbSfTXz m2O482aggqWQtyJczqLI4/9hmGCSKrSS1z+tdZjy99W9p+5ejV3XG1OuQnPQ4Gy4XPk8 dDkO1gNYAo8gnYhpdCYA0CAOXQasvyLV/vJBryTMZEPIVZV2CTEpTP2gjbELjqbT1+lh AUp3TRYSuGWZwvMRf6Sd0d5Ez5kZBgME3yzrZABiF1qBScBzfkVnDwXRAtXVrSQP4SS4 xyEw== X-Received: by 10.69.0.71 with SMTP id aw7mr31618259pbd.60.1446533299933; Mon, 02 Nov 2015 22:48:19 -0800 (PST) Received: from [192.168.1.15] (c-73-189-176-93.hsd1.ca.comcast.net. [73.189.176.93]) by smtp.gmail.com with ESMTPSA id y3sm9429671pbt.56.2015.11.02.22.48.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Nov 2015 22:48:19 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_20D75809-115A-41BA-BA8A-766740B8AAB0" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Multiple BFD sessions between the same pair of end-points From: Sam Aldrin In-Reply-To: Date: Mon, 2 Nov 2015 22:48:18 -0800 Message-Id: <730CA9F1-B952-4E2F-A61A-B4276BDE5EF4@gmail.com> References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> To: "Reshad Rahman (rrahman)" X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 06:48:23 -0000 --Apple-Mail=_20D75809-115A-41BA-BA8A-766740B8AAB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Reshad, > On Nov 2, 2015, at 9:29 PM, Reshad Rahman (rrahman) = wrote: >=20 > Hi Santosh, >=20 > Even for single-hop we had discussions about implementations which = support the option of having multiple BFD single-hop sessions on 1 = interface between 2 endpoints. That was an argument for having the BFD = config in routing applications. This is what was discussed today in the = WG. And I think Greg=E2=80=99s point is that we don=E2=80=99t have to = support this in the base model, but implementations are have vendor = specific model which supports this behavior. Are there already vendor specific models/implementations in the single = hop case? OR did you mean, there could be vendor specific extensions? -sam >=20 > Regards, > Reshad. >=20 >=20 > From: Rtg-bfd > on behalf of Santosh P K = > > Date: Tuesday, November 3, 2015 at 1:25 AM > To: Gregory Mirsky >, "rtg-bfd@ietf.org = " > > Subject: RE: Multiple BFD sessions between the same pair of end-points >=20 > This is form RFC 5881 section 3. > =20 > In this application, there will be only a single BFD session between > two systems over a given interface (logical or physical) for a > particular protocol. The BFD session must be bound to this > interface. > =20 > Which says for singlehop you will have only single BFD session for an = interface. The case where we are struggling in Yang is for multihop BFD = session. > =20 > Thanks > Santosh P K=20 > =20 > =20 > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org = ] On Behalf Of Gregory Mirsky > Sent: Tuesday, November 03, 2015 7:57 AM > To: rtg-bfd@ietf.org > Subject: Multiple BFD sessions between the same pair of end-points > =20 > Dear All, > I think that this paragraph from Section 2 of RFC 5881 prohibits = multiple single-hop BFD sessions between the same pair of end points: > Each BFD session between a pair of systems MUST traverse a separate > network-layer path in both directions. This is necessary for > demultiplexing to work properly, and also because (by definition) > multiple sessions would otherwise be protecting the same path. > =20 > Regards, > Greg --Apple-Mail=_20D75809-115A-41BA-BA8A-766740B8AAB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Reshad,

On Nov 2, 2015, at 9:29 PM, = Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:

Hi Santosh,

Even for single-hop we had discussions about implementations = which support the option of having multiple BFD single-hop sessions on 1 = interface between 2  endpoints. That was an argument for having the = BFD config in routing applications. This is what was discussed today in = the WG. And I think Greg=E2=80=99s point is that we don=E2=80=99t have = to support this in the base model, but implementations are have vendor = specific model which supports this = behavior.
Are there already vendor = specific models/implementations in the single hop case? OR did you mean, = there could be vendor specific extensions?

-sam

Regards,
Reshad.


From: Rtg-bfd <rtg-bfd-bounces@ietf.org> = on behalf of Santosh P K <santoshpk@juniper.net>
Date: Tuesday, November 3, = 2015 at 1:25 AM
To: Gregory Mirsky = <gregory.mirsky@ericsson.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: Multiple BFD = sessions between the same pair of end-points

This is form RFC 5881 = section 3.
 
In this application, there will = be only a single BFD session between
   two systems over a given = interface (logical or physical) for a
   particular protocol.  The = BFD session must be bound to this
   interface.
 
Which says for singlehop you will have only single BFD = session for an interface.  The case where we are struggling in Yang = is for multihop BFD session.
 
Thanks
Santosh P K 
 
 
From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Gregory = Mirsky
Sent: Tuesday, November 03, 2015 = 7:57 AM
To: rtg-bfd@ietf.org
Subject: Multiple BFD sessions = between the same pair of end-points
 
Dear All,
I think that this paragraph from Section 2 of RFC 5881 = prohibits multiple single-hop BFD sessions between the same pair of end = points:
   Each BFD session between a pair of systems MUST = traverse a separate
   network-layer path in both directions.  = This is necessary for
   demultiplexing to work properly, and also = because (by definition)
   multiple sessions would otherwise be protecting = the same path.
 
          &nb= sp;     Regards,
          &nb= sp;            = ;         = Greg

= --Apple-Mail=_20D75809-115A-41BA-BA8A-766740B8AAB0-- From nobody Mon Nov 2 23:01:22 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90EED1ACD7B for ; Mon, 2 Nov 2015 23:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DATZ7sTsNlJm for ; Mon, 2 Nov 2015 23:01:07 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97D41B2EB6 for ; Mon, 2 Nov 2015 23:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18885; q=dns/txt; s=iport; t=1446534018; x=1447743618; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lbQ1jRTDKIFiXDusn4bG+WsjVDGkOH0ohgHttrNZvEk=; b=A4v3xr02W8yPvVDg3fctweG7SOTKOma/vsnHWIWzc6N4EJs8QzjlqUk1 +tAVFZ/tJO3JrwYHduW1AG/zvdCyhIk+u+FIoY7U0eVL6xoyeoW6WYu9u xncuitv7SGKRusnQatTpqZnZUmQx1OMctJf1r6v7fZBSfbfoANxQA4CV0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D1AQCcWjhW/5xdJa1egm5NU28GvzsBDYFahhkCgTA4FAEBAQEBAQGBCoQ1AQEBBHkQAgEIEQMBAQEoByERFAkIAQEEDgWIGwMSvHINhD0BAQEBAQEBAQEBAQEBAQEBAQEBAQEYhneEfoJTgisWhCwFjVSFEoNdAYsugXaUaYdRAR8BAUKCER2BVnKEd4EHAQEB X-IronPort-AV: E=Sophos;i="5.20,238,1444694400"; d="scan'208,217";a="203790184" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 03 Nov 2015 07:00:17 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tA370GiY017732 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Nov 2015 07:00:16 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 01:00:16 -0600 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.000; Tue, 3 Nov 2015 01:00:15 -0600 From: "Reshad Rahman (rrahman)" To: Sam Aldrin Subject: Re: Multiple BFD sessions between the same pair of end-points Thread-Topic: Multiple BFD sessions between the same pair of end-points Thread-Index: AdEV3sMqUCCSGTiqTr+ZCWzJplyfOAAGR8BgAB2IA4D//4/OAIAAiXAA Date: Tue, 3 Nov 2015 07:00:15 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> <730CA9F1-B952-4E2F-A61A-B4276BDE5EF4@gmail.com> In-Reply-To: <730CA9F1-B952-4E2F-A61A-B4276BDE5EF4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.243.140] Content-Type: multipart/alternative; boundary="_000_D25E87EE1016D8rrahmanciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 07:01:14 -0000 --_000_D25E87EE1016D8rrahmanciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sam, Typo in my email indeed. What I meant is that there could be vendor specifi= c extensions if needed. Also looks like there was confusion in the design team (seemingly caused by= my misinterpretation of what was said), there is no known implementation w= hich supports multiple BFD single-hop sessions for the same pair of endpoin= ts (right Santosh?). For MH it's a different story because of multiple-path= s. The DT will get together to clarify and apologies for the confusion. Regards, Reshad. From: Sam Aldrin > Date: Tuesday, November 3, 2015 at 2:48 AM To: Reshad > Cc: Santosh P K >, Greg= ory Mirsky = >, "rtg-bfd@ietf.org" > Subject: Re: Multiple BFD sessions between the same pair of end-points Reshad, On Nov 2, 2015, at 9:29 PM, Reshad Rahman (rrahman) > wrote: Hi Santosh, Even for single-hop we had discussions about implementations which support = the option of having multiple BFD single-hop sessions on 1 interface betwee= n 2 endpoints. That was an argument for having the BFD config in routing a= pplications. This is what was discussed today in the WG. And I think Greg's= point is that we don't have to support this in the base model, but impleme= ntations are have vendor specific model which supports this behavior. Are there already vendor specific models/implementations in the single hop = case? OR did you mean, there could be vendor specific extensions? -sam Regards, Reshad. From: Rtg-bfd > o= n behalf of Santosh P K > Date: Tuesday, November 3, 2015 at 1:25 AM To: Gregory Mirsky >, "rtg-bfd@ietf.org" > Subject: RE: Multiple BFD sessions between the same pair of end-points This is form RFC 5881 section 3. In this application, there will be only a single BFD session between two systems over a given interface (logical or physical) for a particular protocol. The BFD session must be bound to this interface. Which says for singlehop you will have only single BFD session for an inter= face. The case where we are struggling in Yang is for multihop BFD session= . Thanks Santosh P K From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Tuesday, November 03, 2015 7:57 AM To: rtg-bfd@ietf.org Subject: Multiple BFD sessions between the same pair of end-points Dear All, I think that this paragraph from Section 2 of RFC 5881 prohibits multiple s= ingle-hop BFD sessions between the same pair of end points: Each BFD session between a pair of systems MUST traverse a separate network-layer path in both directions. This is necessary for demultiplexing to work properly, and also because (by definition) multiple sessions would otherwise be protecting the same path. Regards, Greg --_000_D25E87EE1016D8rrahmanciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0451ACD226B92344BCC58F86BA8E6C81@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Sam,

Typo in my email indeed. What I meant is that there could be vendor sp= ecific extensions if needed.

Also looks like there was confusion in the design team (seemingly caus= ed by my misinterpretation of what was said), there is no known implementat= ion which supports multiple BFD single-hop sessions for the same pair of en= dpoints (right Santosh?). For MH it’s a different story because of multiple-paths. 

The DT will get together to clarify and apologies for the confusion.

Regards,
Reshad.

From: Sam Aldrin <aldrin.ietf@gmail.com>
Date: Tuesday, November 3, 2015 at = 2:48 AM
To: Reshad <rrahman@cisco.com>
Cc: Santosh P K <santoshpk@juniper.net>, Gregory Mirsky <= ;gregory.mirsky@ericsson.com= >, "rtg-bfd@ietf.org&qu= ot; <rtg-bfd@ietf.org>
Subject: Re: Multiple BFD sessions = between the same pair of end-points

Reshad,

On Nov 2, 2015, at 9:29 PM, Reshad Rahman (rrahman) <rrahman@cisco.com> wrot= e:

Hi Santosh,

Even for single-hop we had discussions about implementation= s which support the option of having multiple BFD single-hop sessions on 1 = interface between 2  endpoints. That was an argument for having the BF= D config in routing applications. This is what was discussed today in the WG. And I think Greg’s point is t= hat we don’t have to support this in the base model, but implementati= ons are have vendor specific model which supports this behavior.
Are there already vendor specific models/implementations in the single hop = case? OR did you mean, there could be vendor specific extensions?

-sam

Regards,
Reshad.


From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Santosh P K <santoshpk@juniper.net>
Date: Tuesday, November 3, 2015 at 1:25 AM
To: Gregory Mirsky <gregory.mirsky@ericsson.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: Multiple BFD sessions between the = same pair of end-points

This is form RFC 5881 s= ection 3.
 <= /o:p>
In = this application, there will be only a single BFD session between
&nb= sp;  two systems over a given interface (logical or physical) for a
&nb= sp;  particular protocol.  The BFD session must be bound to this<= o:p class=3D"">
&nb= sp;  interface.
 <= /o:p>
Which says for singleho= p you will have only single BFD session for an interface.  The case wh= ere we are struggling in Yang is for multihop BFD session.<= /o:p>
 <= /o:p>
Thanks<= /o:p>
Santosh P K 
 <= /o:p>
 <= /o:p>
From: R= tg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mi= rsky
Sent: T= uesday, November 03, 2015 7:57 AM
To: rtg-bfd@ietf.org
Subject: Multiple BFD sessions between the same pair of end-points=
 
Dear All,
I think that this paragraph from Section 2 of RFC 5881 prohibits multiple s= ingle-hop BFD sessions between the same pair of end points:=
   Each BFD session between a pair of systems MUST traverse a sep= arate
   network-layer path in both directions.  This is necessary= for
   demultiplexing to work properly, and also because (by definiti= on)
   multiple sessions would otherwise be protecting the same path.=
 
            &nb= sp;   Regards,
            &nb= sp;            =        Greg

 --_000_D25E87EE1016D8rrahmanciscocom_-- From nobody Mon Nov 2 23:01:51 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368341B2ED9 for ; Mon, 2 Nov 2015 23:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIvAP3c5S0NK for ; Mon, 2 Nov 2015 23:01:48 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D9F1B2A83 for ; Mon, 2 Nov 2015 23:01:47 -0800 (PST) Received: by pasz6 with SMTP id z6so10255680pas.2 for ; Mon, 02 Nov 2015 23:01:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=wLHazF2wFCMvlxUAeFtTvVdTv93Iu78IKoOOf2dwF4U=; b=QcSG3iYFd9OUCq9Ox5HNrXZZFqozfba14NoBoYghkzOg3NDeRfNIZDJ6f9WvD9ezyp Qy0+UUkoc+LiM1nZ88AQeFK+lRc8sVv8OQivxrc/SOHfHnHhOSsH2zpUoqMvKxxbX7FS 3jOoxxUezRcuHGfCb5PqfwT3Xib39UR8KIyYZJJRwaP+X/8OxYSYzVkZuGi5AeamWIhz Ht6E2eKctT8gdOr/ms9u0sK/lGfzxtu2M6h1cNdsZ4to333ioLSBLy/MFvsu544jkH0T kf9cMtgviERD0YgrPImV1epv/8c5AE652HKbOD8lz4tFSEass9hNKKKq1F0v4MgnXxac KmMw== X-Received: by 10.68.213.198 with SMTP id nu6mr31538164pbc.96.1446534107020; Mon, 02 Nov 2015 23:01:47 -0800 (PST) Received: from [192.168.1.15] (c-73-189-176-93.hsd1.ca.comcast.net. [73.189.176.93]) by smtp.gmail.com with ESMTPSA id kj3sm12738294pbc.59.2015.11.02.23.01.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Nov 2015 23:01:46 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_BF668FF5-7290-4592-ADA1-41E88F7CAC3F" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Multiple BFD sessions between the same pair of end-points From: Sam Aldrin In-Reply-To: Date: Mon, 2 Nov 2015 23:01:45 -0800 Message-Id: <169FF77E-6CFE-4C2B-A6CF-6AA8B9E3FE7F@gmail.com> References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> <730CA9F1-B952-4E2F-A61A-B4276BDE5EF4@gmail.com> To: "Reshad Rahman (rrahman)" X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 07:01:50 -0000 --Apple-Mail=_BF668FF5-7290-4592-ADA1-41E88F7CAC3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the quick clarification, Reshad. -sam > On Nov 2, 2015, at 11:00 PM, Reshad Rahman (rrahman) = wrote: >=20 > Hi Sam, >=20 > Typo in my email indeed. What I meant is that there could be vendor = specific extensions if needed. >=20 > Also looks like there was confusion in the design team (seemingly = caused by my misinterpretation of what was said), there is no known = implementation which supports multiple BFD single-hop sessions for the = same pair of endpoints (right Santosh?). For MH it=E2=80=99s a different = story because of multiple-paths.=20 >=20 > The DT will get together to clarify and apologies for the confusion. >=20 > Regards, > Reshad. >=20 > From: Sam Aldrin > > Date: Tuesday, November 3, 2015 at 2:48 AM > To: Reshad > > Cc: Santosh P K >, Gregory Mirsky = >, = "rtg-bfd@ietf.org " > > Subject: Re: Multiple BFD sessions between the same pair of end-points >=20 > Reshad, >=20 >> On Nov 2, 2015, at 9:29 PM, Reshad Rahman (rrahman) = > wrote: >>=20 >> Hi Santosh, >>=20 >> Even for single-hop we had discussions about implementations which = support the option of having multiple BFD single-hop sessions on 1 = interface between 2 endpoints. That was an argument for having the BFD = config in routing applications. This is what was discussed today in the = WG. And I think Greg=E2=80=99s point is that we don=E2=80=99t have to = support this in the base model, but implementations are have vendor = specific model which supports this behavior. > Are there already vendor specific models/implementations in the single = hop case? OR did you mean, there could be vendor specific extensions? >=20 > -sam >>=20 >> Regards, >> Reshad. >>=20 >>=20 >> From: Rtg-bfd > on behalf of Santosh P K = > >> Date: Tuesday, November 3, 2015 at 1:25 AM >> To: Gregory Mirsky >, "rtg-bfd@ietf.org = " > >> Subject: RE: Multiple BFD sessions between the same pair of = end-points >>=20 >> This is form RFC 5881 section 3. >> =20 >> In this application, there will be only a single BFD session between >> two systems over a given interface (logical or physical) for a >> particular protocol. The BFD session must be bound to this >> interface. >> =20 >> Which says for singlehop you will have only single BFD session for an = interface. The case where we are struggling in Yang is for multihop BFD = session. >> =20 >> Thanks >> Santosh P K=20 >> =20 >> =20 >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org = ] On Behalf Of Gregory Mirsky >> Sent: Tuesday, November 03, 2015 7:57 AM >> To: rtg-bfd@ietf.org >> Subject: Multiple BFD sessions between the same pair of end-points >> =20 >> Dear All, >> I think that this paragraph from Section 2 of RFC 5881 prohibits = multiple single-hop BFD sessions between the same pair of end points: >> Each BFD session between a pair of systems MUST traverse a = separate >> network-layer path in both directions. This is necessary for >> demultiplexing to work properly, and also because (by definition) >> multiple sessions would otherwise be protecting the same path. >> =20 >> Regards, >> Greg >=20 --Apple-Mail=_BF668FF5-7290-4592-ADA1-41E88F7CAC3F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the quick clarification, Reshad.

-sam
On Nov 2, 2015, at 11:00 PM, = Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:

Hi Sam,

Typo in my email indeed. What I meant is that there = could be vendor specific extensions if needed.

Also looks like there was confusion in the design team = (seemingly caused by my misinterpretation of what was said), there is no = known implementation which supports multiple BFD single-hop sessions for = the same pair of endpoints (right Santosh?). For MH it=E2=80=99s a different story because of multiple-paths. 

The DT will get together to clarify and apologies for = the confusion.

Regards,
Reshad.

From: Sam Aldrin = <aldrin.ietf@gmail.com>
Date: Tuesday, = November 3, 2015 at 2:48 AM
To: Reshad <rrahman@cisco.com>
Cc: Santosh P K = <santoshpk@juniper.net>, Gregory Mirsky <gregory.mirsky@ericsson.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: Multiple = BFD sessions between the same pair of end-points

Reshad,

On Nov 2, 2015, at 9:29 PM, Reshad Rahman (rrahman) = <rrahman@cisco.com> wrote:

Hi Santosh,

Even for single-hop we had discussions about = implementations which support the option of having multiple BFD = single-hop sessions on 1 interface between 2  endpoints. That was = an argument for having the BFD config in routing applications. This is what was discussed today in the WG. And I think Greg=E2=80=99s point = is that we don=E2=80=99t have to support this in the base model, but = implementations are have vendor specific model which supports this = behavior.
Are there already vendor specific models/implementations in the single = hop case? OR did you mean, there could be vendor specific = extensions?

-sam

Regards,
Reshad.


From: Rtg-bfd <rtg-bfd-bounces@ietf.org> = on behalf of Santosh P K <santoshpk@juniper.net>
Date: Tuesday, November 3, = 2015 at 1:25 AM
To: Gregory Mirsky = <gregory.mirsky@ericsson.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: Multiple BFD = sessions between the same pair of end-points

This is form RFC = 5881 section 3.
 
In= this application, there will be only a single BFD session between
   two systems over a given interface (logical or = physical) for a
   particular protocol.  The BFD session must = be bound to this
   interface.
 
Which says for = singlehop you will have only single BFD session for an interface. =  The case where we are struggling in Yang is for multihop BFD = session.
 
Thanks
Santosh P K 
 
 
From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory = Mirsky
Sent: Tuesday, November 03, 2015 = 7:57 AM
To: rtg-bfd@ietf.org
Subject: Multiple BFD sessions = between the same pair of end-points
 
Dear All,
I think that this paragraph from Section 2 of RFC 5881 prohibits = multiple single-hop BFD sessions between the same pair of end = points:
   Each BFD session between a pair of systems MUST traverse a = separate
   network-layer path in both directions.  This is = necessary for
   demultiplexing to work properly, and also because (by = definition)
   multiple sessions would otherwise be protecting the same = path.
 
=             &n= bsp;   Regards,
=             &n= bsp;           &nbs= p;       Greg

= --Apple-Mail=_BF668FF5-7290-4592-ADA1-41E88F7CAC3F-- From nobody Tue Nov 3 05:15:58 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082491B3353 for ; Tue, 3 Nov 2015 05:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfrjqrWVxM5w for ; Tue, 3 Nov 2015 05:15:54 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092981B3352 for ; Tue, 3 Nov 2015 05:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26257; q=dns/txt; s=iport; t=1446556554; x=1447766154; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MfpD/sUM3SKoLjlbonMg0zncAOyrhVW5aORF7Pk6CP0=; b=aYGt8vOyWVHSFWX/UNx6DA40ujz7xNz2rQLpBlKoudKit/nyX9Yh0aAI cn+JW9pf6Kn8v6TxvYTanAa97HFv/drj0idj5mqdl7lvDhBmyS+M43fqC 8WnH1TZl+fJmewjE2bcxIbXz3omJsaf97VM9qvEgC6Ru5P8jAVgb+bsGJ U=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DSAgBnszhW/4QNJK1egm5NU2APBr5SDoFbIYV1AoE8OBQBAQEBAQEBgQqENQEBAQMBI1YFCwIBCBEDAQEBASAHAwICIREUCQgBAQQOBQ6ICwMKCA2wI4w7DYQ6AQEBAQEBAQEBAQEBAQEBAQEBAQEBDwUEhmiCEIJuglOBYkYNCYJlMYEUBZJmg2ABglGBYWqGEoF0lGyHUQEfAUOCER2BVnKENUKBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,238,1444694400"; d="asc'?scan'208,217";a="204395747" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP; 03 Nov 2015 13:15:51 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tA3DFoGq016966 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Nov 2015 13:15:51 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 08:15:49 -0500 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.000; Tue, 3 Nov 2015 08:15:49 -0500 From: "Carlos Pignataro (cpignata)" To: "Reshad Rahman (rrahman)" Subject: Re: Multiple BFD sessions between the same pair of end-points Thread-Topic: Multiple BFD sessions between the same pair of end-points Thread-Index: AdEV3sMqUCCSGTiqTr+ZCWzJplyfOAAGR8BgAB2IA4D//38LAIAAA1eAgABo7IA= Date: Tue, 3 Nov 2015 13:15:49 +0000 Message-ID: <087FBA90-F5EB-4691-A5FD-96F784569F6C@cisco.com> References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> <730CA9F1-B952-4E2F-A61A-B4276BDE5EF4@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.230.219] Content-Type: multipart/signed; boundary="Apple-Mail=_564B9DBE-14A9-49A2-9D1D-551BB96C6DA2"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 13:15:57 -0000 --Apple-Mail=_564B9DBE-14A9-49A2-9D1D-551BB96C6DA2 Content-Type: multipart/alternative; boundary="Apple-Mail=_FC5432BC-BFBE-4909-9D92-917D9DC8A828" --Apple-Mail=_FC5432BC-BFBE-4909-9D92-917D9DC8A828 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Reshad, It really depends on what is considered a =E2=80=9Cpath=E2=80=9D over = which BFD detects faults, and how the initial demux can be done vs. = bootstrapped out-of-band. RFC 5881 has the text quoted by Greg, because in that case single-hop = initialization procedures can be done (by binding the interface to BFD = context) and not require out-of-band discriminator bootstrapping. However, on a single interface between two forwarding endpoints, there = could be multiple sessions in a generic application. The simplest = example is what is described in the second paragraph of = https://tools.ietf.org/html/rfc5882#section-6 = . In that case, a path is = a specific diffserv code point over IPv4 between two endpoints, and that = is the context used for initialization using single-hop procedures. In = RFC5885 we chose to allow only one, to use single-hop initialization for = example within a tunnel (PW) context. For the multi-hop case, there could also be multiple sessions between = endpoints. If there is only one session, then the initialization can be = done using single-hop procedures binding source/dst addresses. However, = is there are multiple sessions, as e.g., if there is some = ECMP-awareness, then some different and additional mechanism (e.g., = out-of-band bootstrapping) is needed. This is described in the second = paragraph of https://tools.ietf.org/html/rfc5883#section-3 = . In fact, these two = options are covered in S4.1 (limit to one session and use src/dst) and = S4.2 (allow multiple sessions and use an OOB bootstrapping). As far as the YANG models, I=E2=80=99d think that single session for = both single- and multi-hop covers vast majority of real cases, being = pragmatic. If someone wants to have for example multiple sessions = between a pair of endpoint addresses in multi-hop, then an OOB mechanism = is needed, and I do not believe there is a spec=E2=80=99ed one other = than for MPLS. Thanks, =E2=80=94 Carlos. > On Nov 3, 2015, at 4:00 PM, Reshad Rahman (rrahman) = wrote: >=20 > Hi Sam, >=20 > Typo in my email indeed. What I meant is that there could be vendor = specific extensions if needed. >=20 > Also looks like there was confusion in the design team (seemingly = caused by my misinterpretation of what was said), there is no known = implementation which supports multiple BFD single-hop sessions for the = same pair of endpoints (right Santosh?). For MH it=E2=80=99s a different = story because of multiple-paths. >=20 > The DT will get together to clarify and apologies for the confusion. >=20 > Regards, > Reshad. >=20 > From: Sam Aldrin > > Date: Tuesday, November 3, 2015 at 2:48 AM > To: Reshad > > Cc: Santosh P K >, Gregory Mirsky = >, = "rtg-bfd@ietf.org " > > Subject: Re: Multiple BFD sessions between the same pair of end-points >=20 > Reshad, >=20 >> On Nov 2, 2015, at 9:29 PM, Reshad Rahman (rrahman) = > wrote: >>=20 >> Hi Santosh, >>=20 >> Even for single-hop we had discussions about implementations which = support the option of having multiple BFD single-hop sessions on 1 = interface between 2 endpoints. That was an argument for having the BFD = config in routing applications. This is what was discussed today in the = WG. And I think Greg=E2=80=99s point is that we don=E2=80=99t have to = support this in the base model, but implementations are have vendor = specific model which supports this behavior. > Are there already vendor specific models/implementations in the single = hop case? OR did you mean, there could be vendor specific extensions? >=20 > -sam >>=20 >> Regards, >> Reshad. >>=20 >>=20 >> From: Rtg-bfd > on behalf of Santosh P K = > >> Date: Tuesday, November 3, 2015 at 1:25 AM >> To: Gregory Mirsky >, "rtg-bfd@ietf.org = " > >> Subject: RE: Multiple BFD sessions between the same pair of = end-points >>=20 >> This is form RFC 5881 section 3. >>=20 >> In this application, there will be only a single BFD session between >> two systems over a given interface (logical or physical) for a >> particular protocol. The BFD session must be bound to this >> interface. >>=20 >> Which says for singlehop you will have only single BFD session for an = interface. The case where we are struggling in Yang is for multihop BFD = session. >>=20 >> Thanks >> Santosh P K >>=20 >>=20 >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org = ] On Behalf Of Gregory Mirsky >> Sent: Tuesday, November 03, 2015 7:57 AM >> To: rtg-bfd@ietf.org >> Subject: Multiple BFD sessions between the same pair of end-points >>=20 >> Dear All, >> I think that this paragraph from Section 2 of RFC 5881 prohibits = multiple single-hop BFD sessions between the same pair of end points: >> Each BFD session between a pair of systems MUST traverse a = separate >> network-layer path in both directions. This is necessary for >> demultiplexing to work properly, and also because (by definition) >> multiple sessions would otherwise be protecting the same path. >>=20 >> Regards, >> Greg >=20 --Apple-Mail=_FC5432BC-BFBE-4909-9D92-917D9DC8A828 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Reshad,

It really depends on what is considered a =E2=80=9Cpath=E2=80=9D= over which BFD detects faults, and how the initial demux can be done = vs. bootstrapped out-of-band.

RFC 5881 has the text quoted by Greg, = because in that case single-hop initialization procedures can be done = (by binding the interface to BFD context) and not require out-of-band = discriminator bootstrapping.

However, on a single interface between = two forwarding endpoints, there could be multiple sessions in a generic = application. The simplest example is what is described in the second = paragraph of https://tools.ietf.org/html/rfc5882#section-6. In that = case, a path is a specific diffserv code point over IPv4 between two = endpoints, and that is the context used for initialization using = single-hop procedures. In RFC5885 we chose to allow only one, to use = single-hop initialization for example within a tunnel (PW) = context.

For = the multi-hop case, there could also be multiple sessions between = endpoints. If there is only one session, then the initialization can be = done using single-hop procedures binding source/dst addresses. However, = is there are multiple sessions, as e.g., if there is some = ECMP-awareness, then some different and additional mechanism (e.g., = out-of-band bootstrapping) is needed. This is described in the second = paragraph of https://tools.ietf.org/html/rfc5883#section-3. In fact, = these two options are covered in S4.1 (limit to one session and use = src/dst) and S4.2 (allow multiple sessions and use an OOB = bootstrapping).

As far as the YANG models, I=E2=80=99d think that single = session for both single- and multi-hop covers vast majority of real = cases, being pragmatic. If someone wants to have for example multiple = sessions between a pair of endpoint addresses in multi-hop, then an OOB = mechanism is needed, and I do not believe there is a spec=E2=80=99ed one = other than for MPLS.

Thanks,

=E2=80=94 Carlos.

On = Nov 3, 2015, at 4:00 PM, Reshad Rahman (rrahman) <rrahman@cisco.com> = wrote:

Hi Sam,

Typo in my email indeed. What I meant is that there = could be vendor specific extensions if needed.

Also looks like there was confusion in the design team = (seemingly caused by my misinterpretation of what was said), there is no = known implementation which supports multiple BFD single-hop sessions for = the same pair of endpoints (right Santosh?). For MH it=E2=80=99s a different story because of multiple-paths. 

The DT will get together to clarify and apologies for = the confusion.

Regards,
Reshad.

From: Sam Aldrin = <aldrin.ietf@gmail.com>
Date: Tuesday, = November 3, 2015 at 2:48 AM
To: Reshad <rrahman@cisco.com>
Cc: Santosh P K = <santoshpk@juniper.net>, Gregory Mirsky <gregory.mirsky@ericsson.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: Multiple = BFD sessions between the same pair of end-points

Reshad,

On Nov 2, 2015, at 9:29 PM, Reshad Rahman (rrahman) = <rrahman@cisco.com> wrote:

Hi Santosh,

Even for single-hop we had discussions about = implementations which support the option of having multiple BFD = single-hop sessions on 1 interface between 2  endpoints. That was = an argument for having the BFD config in routing applications. This is what was discussed today in the WG. And I think Greg=E2=80=99s point = is that we don=E2=80=99t have to support this in the base model, but = implementations are have vendor specific model which supports this = behavior.
Are there already vendor specific models/implementations in the single = hop case? OR did you mean, there could be vendor specific = extensions?

-sam

Regards,
Reshad.


From: Rtg-bfd <rtg-bfd-bounces@ietf.org> = on behalf of Santosh P K <santoshpk@juniper.net>
Date: Tuesday, November 3, = 2015 at 1:25 AM
To: Gregory Mirsky = <gregory.mirsky@ericsson.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: Multiple BFD = sessions between the same pair of end-points

This is form RFC = 5881 section 3.
 
In= this application, there will be only a single BFD session between
   two systems over a given interface (logical or = physical) for a
   particular protocol.  The BFD session must = be bound to this
   interface.
 
Which says for = singlehop you will have only single BFD session for an interface. =  The case where we are struggling in Yang is for multihop BFD = session.
 
Thanks
Santosh P K 
 
 
From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory = Mirsky
Sent: Tuesday, November 03, 2015 = 7:57 AM
To: rtg-bfd@ietf.org
Subject: Multiple BFD sessions = between the same pair of end-points
 
Dear All,
I think that this paragraph from Section 2 of RFC 5881 prohibits = multiple single-hop BFD sessions between the same pair of end = points:
   Each BFD session between a pair of systems MUST traverse a = separate
   network-layer path in both directions.  This is = necessary for
   demultiplexing to work properly, and also because (by = definition)
   multiple sessions would otherwise be protecting the same = path.
 
=             &n= bsp;   Regards,
=             &n= bsp;           &nbs= p;       Greg

= --Apple-Mail=_FC5432BC-BFBE-4909-9D92-917D9DC8A828-- --Apple-Mail=_564B9DBE-14A9-49A2-9D1D-551BB96C6DA2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWOLODAAoJEIXgpQGOZny9HGkP+gNa01W18xvKb82K1jtq1agp Ndn0r9bfKqbcoFd5inbDC7XpXeFr10rX2NGtq98QgedO6S9kgbZK3XJKuODz8Zb1 e//xQ6M10Ii4hvE1D4aMDQroFUZAd0fVkGR8lclIhhV4AfkUJK5Djrq38wBtkw/R r+zDa/oeEYNF+ntq7ZG8sfAmtsUsiBWuYplY1jZLZ+Z6Lq0Kk5yTsrhN7wk4W/k/ 7xKG06RF+0e1racHZ+umvP7Ff/BH8gErf/Kq80H6rXRxnhE0Or0lE1Or9fprqYpi KNq6lTvxDoslle/IwU5czDYGDMh8C28nnuDR3L1Z6KCf+Nz3d7lMOoFPgbwrWxLR tm60QFvmfN3rIiqHZAOFESfUkVxOFwHMhMeWUM8Mq3iTOwHOs7/WtD59MOIsTw2W neJSaE3MVM7ueWpuTxpFhZ66P9KKUoddzGWNhcAnw5zi5Xx+O5lqjHC7qx+8DGQU j9SJFQLaVcAJHBBeZLeyctYKFD5A7s9PRPYt/SDGfSqNtVO6+1ZU8JhncWrw+kTy xJOIS9n2XRS0h+bZIcmgMWk0sFqsCkMfEch3LoHoi/5sGOM9CHlUnlAKucMh+T5x XsGqR5p84i+4Tugo8ji4yDJPVqMAfryCoKwrhgIZmTf2D72UNpHtLq/gbHKk+Hzt kImHfHV12VAQes47lIWL =SzbZ -----END PGP SIGNATURE----- --Apple-Mail=_564B9DBE-14A9-49A2-9D1D-551BB96C6DA2-- From nobody Tue Nov 3 05:39:02 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9C81B339F for ; Tue, 3 Nov 2015 05:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eE9UkpSeTE8b for ; Tue, 3 Nov 2015 05:38:56 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0769.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::769]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758A91B339D for ; Tue, 3 Nov 2015 05:38:55 -0800 (PST) Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0778.eurprd03.prod.outlook.com (10.161.54.28) with Microsoft SMTP Server (TLS) id 15.1.312.18; Tue, 3 Nov 2015 13:38:35 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0318.003; Tue, 3 Nov 2015 13:38:35 +0000 From: Alexander Vainshtein To: "Carlos Pignataro (cpignata)" , "Reshad Rahman (rrahman)" Subject: RE: Multiple BFD sessions between the same pair of end-points Thread-Topic: Multiple BFD sessions between the same pair of end-points Thread-Index: AdEV3sMqUCCSGTiqTr+ZCWzJplyfOAAGR8BgAB2IA4D//38LAIAAA1eAgABo7ICAAE+kYA== Date: Tue, 3 Nov 2015 13:38:35 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> <730CA9F1-B952-4E2F-A61A-B4276BDE5EF4@gmail.com> <087FBA90-F5EB-4691-A5FD-96F784569F6C@cisco.com> In-Reply-To: <087FBA90-F5EB-4691-A5FD-96F784569F6C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [147.234.56.21] x-microsoft-exchange-diagnostics: 1; DB3PR03MB0778; 5:47m0+ioqQRhAk5a7Rqe/KjwhsHb+IA7WPWhbpcxC5ntvU1qw3ygYMdY+UcSoQeb4KcDHCzNWlnWbdWSmzlS7KkcYKWbdEMymQfs1puFfjr6Ol5f8izhvamSjNrDksYAKqEVQKM5smqMGH8RsRec2Zg==; 24:XPIsRitI7wKBjmgiOLlfsb1cDf6z1V3qxFYaFnsyHYqD6vz2S/SjDNLkPo6czsVG9SOwFGOzIij/IZZf8D0uZ/UyTYtv3MMhgzKVnJccmgE=; 20:cwTvOHdPi1is9jSao0T6lgvU3OS8a747g4cSpSFDAkGG/Bqv6SpYgaXbUN0aDhtkq7Z6s9w68QZnlI/3d6fNLw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0778; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014)(279101305709854)(108003899814671)(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB3PR03MB0778; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0778; x-forefront-prvs: 0749DC2CE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(53754006)(53824002)(164054003)(51444003)(377454003)(252514010)(24454002)(5004730100002)(76176999)(5002640100001)(105586002)(87936001)(106356001)(5008740100001)(19300405004)(19580405001)(54356999)(10400500002)(16236675004)(50986999)(74316001)(19609705001)(66066001)(19580395003)(33656002)(101416001)(15975445007)(77096005)(5007970100001)(5001960100002)(97736004)(76576001)(93886004)(2950100001)(40100003)(81156007)(102836002)(86362001)(2900100001)(19617315012)(189998001)(5003600100002)(92566002)(122556002)(11100500001)(19625215002)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0778; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB078033D8DF9ACA2113E721CD9D2B0DB3PR03MB0780eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2015 13:38:35.3867 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0778 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 13:39:00 -0000 --_000_DB3PR03MB078033D8DF9ACA2113E721CD9D2B0DB3PR03MB0780eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KSSBjb25jdXIgd2l0aCBDYXJsb3MsIG9ubHkgd2FudGVkIHRvIGFkZCB0aGF0IGlu IHRoZSBjYXNlIG9mIEJGRCBpbiBNUExTIExTUCBhYmlsaXR5IGZvciBpbi1iYW5kIGluaXRpYWxp emF0aW9uIGRvZXMgbm90IGV4aXN0IChlLmcuIGluIHRoZSBjYXNlIG9mIFBIUCwgc2VlIFNlY3Rp b24gNSBpbiBSRkMgNTg4NCksIGFuZCBzbyBhbiBPT0IgaW5pdGlhbGl6YXRpb24gcHJvY2VkdXJl IHdhcyB1bmF2b2lkYWJsZS4NCg0KSeKAmWQgc2F5IHdlIG5lZWQgYSB2ZXJ5IHN0cm9uZyB1c2Ug Y2FzZSBmb3IgbXVsdGlwbGUgQkZEIHNlc3Npb25zIGJldHdlZW4gdGhlIHNhbWUgcGFpciBvZiBl bmRwb2ludHMgdG8ganVzdGlmeSBpbnRyb2R1Y3Rpb24gb2YgeWV0IGFub3RoZXIgT09CIGluaXRp YWxpemF0aW9uIHByb2NlZHVyZS4NCg0KTXkgMiwNClNhc2hhDQoNCk9mZmljZTogKzk3Mi0zOTI2 NjMwMg0KQ2VsbDogICAgICArOTcyLTU0OTI2NjMwMg0KRW1haWw6ICAgQWxleGFuZGVyLlZhaW5z aHRlaW5AZWNpdGVsZS5jb20NCg0KRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKQ0KU2Vu dDogVHVlc2RheSwgTm92ZW1iZXIgMDMsIDIwMTUgMzoxNiBQTQ0KVG86IFJlc2hhZCBSYWhtYW4g KHJyYWhtYW4pDQpDYzogcnRnLWJmZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IE11bHRpcGxlIEJG RCBzZXNzaW9ucyBiZXR3ZWVuIHRoZSBzYW1lIHBhaXIgb2YgZW5kLXBvaW50cw0KDQpIaSBSZXNo YWQsDQoNCkl0IHJlYWxseSBkZXBlbmRzIG9uIHdoYXQgaXMgY29uc2lkZXJlZCBhIOKAnHBhdGji gJ0gb3ZlciB3aGljaCBCRkQgZGV0ZWN0cyBmYXVsdHMsIGFuZCBob3cgdGhlIGluaXRpYWwgZGVt dXggY2FuIGJlIGRvbmUgdnMuIGJvb3RzdHJhcHBlZCBvdXQtb2YtYmFuZC4NCg0KUkZDIDU4ODEg aGFzIHRoZSB0ZXh0IHF1b3RlZCBieSBHcmVnLCBiZWNhdXNlIGluIHRoYXQgY2FzZSBzaW5nbGUt aG9wIGluaXRpYWxpemF0aW9uIHByb2NlZHVyZXMgY2FuIGJlIGRvbmUgKGJ5IGJpbmRpbmcgdGhl IGludGVyZmFjZSB0byBCRkQgY29udGV4dCkgYW5kIG5vdCByZXF1aXJlIG91dC1vZi1iYW5kIGRp c2NyaW1pbmF0b3IgYm9vdHN0cmFwcGluZy4NCg0KSG93ZXZlciwgb24gYSBzaW5nbGUgaW50ZXJm YWNlIGJldHdlZW4gdHdvIGZvcndhcmRpbmcgZW5kcG9pbnRzLCB0aGVyZSBjb3VsZCBiZSBtdWx0 aXBsZSBzZXNzaW9ucyBpbiBhIGdlbmVyaWMgYXBwbGljYXRpb24uIFRoZSBzaW1wbGVzdCBleGFt cGxlIGlzIHdoYXQgaXMgZGVzY3JpYmVkIGluIHRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgyI3NlY3Rpb24tNi4gSW4gdGhhdCBjYXNlLCBh IHBhdGggaXMgYSBzcGVjaWZpYyBkaWZmc2VydiBjb2RlIHBvaW50IG92ZXIgSVB2NCBiZXR3ZWVu IHR3byBlbmRwb2ludHMsIGFuZCB0aGF0IGlzIHRoZSBjb250ZXh0IHVzZWQgZm9yIGluaXRpYWxp emF0aW9uIHVzaW5nIHNpbmdsZS1ob3AgcHJvY2VkdXJlcy4gSW4gUkZDNTg4NSB3ZSBjaG9zZSB0 byBhbGxvdyBvbmx5IG9uZSwgdG8gdXNlIHNpbmdsZS1ob3AgaW5pdGlhbGl6YXRpb24gZm9yIGV4 YW1wbGUgd2l0aGluIGEgdHVubmVsIChQVykgY29udGV4dC4NCg0KRm9yIHRoZSBtdWx0aS1ob3Ag Y2FzZSwgdGhlcmUgY291bGQgYWxzbyBiZSBtdWx0aXBsZSBzZXNzaW9ucyBiZXR3ZWVuIGVuZHBv aW50cy4gSWYgdGhlcmUgaXMgb25seSBvbmUgc2Vzc2lvbiwgdGhlbiB0aGUgaW5pdGlhbGl6YXRp b24gY2FuIGJlIGRvbmUgdXNpbmcgc2luZ2xlLWhvcCBwcm9jZWR1cmVzIGJpbmRpbmcgc291cmNl L2RzdCBhZGRyZXNzZXMuIEhvd2V2ZXIsIGlzIHRoZXJlIGFyZSBtdWx0aXBsZSBzZXNzaW9ucywg YXMgZS5nLiwgaWYgdGhlcmUgaXMgc29tZSBFQ01QLWF3YXJlbmVzcywgdGhlbiBzb21lIGRpZmZl cmVudCBhbmQgYWRkaXRpb25hbCBtZWNoYW5pc20gKGUuZy4sIG91dC1vZi1iYW5kIGJvb3RzdHJh cHBpbmcpIGlzIG5lZWRlZC4gVGhpcyBpcyBkZXNjcmliZWQgaW4gdGhlIHNlY29uZCBwYXJhZ3Jh cGggb2YgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4ODMjc2VjdGlvbi0zLiBJbiBm YWN0LCB0aGVzZSB0d28gb3B0aW9ucyBhcmUgY292ZXJlZCBpbiBTNC4xIChsaW1pdCB0byBvbmUg c2Vzc2lvbiBhbmQgdXNlIHNyYy9kc3QpIGFuZCBTNC4yIChhbGxvdyBtdWx0aXBsZSBzZXNzaW9u cyBhbmQgdXNlIGFuIE9PQiBib290c3RyYXBwaW5nKS4NCg0KQXMgZmFyIGFzIHRoZSBZQU5HIG1v ZGVscywgSeKAmWQgdGhpbmsgdGhhdCBzaW5nbGUgc2Vzc2lvbiBmb3IgYm90aCBzaW5nbGUtIGFu ZCBtdWx0aS1ob3AgY292ZXJzIHZhc3QgbWFqb3JpdHkgb2YgcmVhbCBjYXNlcywgYmVpbmcgcHJh Z21hdGljLiBJZiBzb21lb25lIHdhbnRzIHRvIGhhdmUgZm9yIGV4YW1wbGUgbXVsdGlwbGUgc2Vz c2lvbnMgYmV0d2VlbiBhIHBhaXIgb2YgZW5kcG9pbnQgYWRkcmVzc2VzIGluIG11bHRpLWhvcCwg dGhlbiBhbiBPT0IgbWVjaGFuaXNtIGlzIG5lZWRlZCwgYW5kIEkgZG8gbm90IGJlbGlldmUgdGhl cmUgaXMgYSBzcGVj4oCZZWQgb25lIG90aGVyIHRoYW4gZm9yIE1QTFMuDQoNClRoYW5rcywNCg0K 4oCUIENhcmxvcy4NCg0KT24gTm92IDMsIDIwMTUsIGF0IDQ6MDAgUE0sIFJlc2hhZCBSYWhtYW4g KHJyYWhtYW4pIDxycmFobWFuQGNpc2NvLmNvbTxtYWlsdG86cnJhaG1hbkBjaXNjby5jb20+PiB3 cm90ZToNCg0KSGkgU2FtLA0KDQpUeXBvIGluIG15IGVtYWlsIGluZGVlZC4gV2hhdCBJIG1lYW50 IGlzIHRoYXQgdGhlcmUgY291bGQgYmUgdmVuZG9yIHNwZWNpZmljIGV4dGVuc2lvbnMgaWYgbmVl ZGVkLg0KDQpBbHNvIGxvb2tzIGxpa2UgdGhlcmUgd2FzIGNvbmZ1c2lvbiBpbiB0aGUgZGVzaWdu IHRlYW0gKHNlZW1pbmdseSBjYXVzZWQgYnkgbXkgbWlzaW50ZXJwcmV0YXRpb24gb2Ygd2hhdCB3 YXMgc2FpZCksIHRoZXJlIGlzIG5vIGtub3duIGltcGxlbWVudGF0aW9uIHdoaWNoIHN1cHBvcnRz IG11bHRpcGxlIEJGRCBzaW5nbGUtaG9wIHNlc3Npb25zIGZvciB0aGUgc2FtZSBwYWlyIG9mIGVu ZHBvaW50cyAocmlnaHQgU2FudG9zaD8pLiBGb3IgTUggaXTigJlzIGEgZGlmZmVyZW50IHN0b3J5 IGJlY2F1c2Ugb2YgbXVsdGlwbGUtcGF0aHMuDQoNClRoZSBEVCB3aWxsIGdldCB0b2dldGhlciB0 byBjbGFyaWZ5IGFuZCBhcG9sb2dpZXMgZm9yIHRoZSBjb25mdXNpb24uDQoNClJlZ2FyZHMsDQpS ZXNoYWQuDQoNCkZyb206IFNhbSBBbGRyaW4gPGFsZHJpbi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86 YWxkcmluLmlldGZAZ21haWwuY29tPj4NCkRhdGU6IFR1ZXNkYXksIE5vdmVtYmVyIDMsIDIwMTUg YXQgMjo0OCBBTQ0KVG86IFJlc2hhZCA8cnJhaG1hbkBjaXNjby5jb208bWFpbHRvOnJyYWhtYW5A Y2lzY28uY29tPj4NCkNjOiBTYW50b3NoIFAgSyA8c2FudG9zaHBrQGp1bmlwZXIubmV0PG1haWx0 bzpzYW50b3NocGtAanVuaXBlci5uZXQ+PiwgR3JlZ29yeSBNaXJza3kgPGdyZWdvcnkubWlyc2t5 QGVyaWNzc29uLmNvbTxtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPj4sICJydGct YmZkQGlldGYub3JnPG1haWx0bzpydGctYmZkQGlldGYub3JnPiIgPHJ0Zy1iZmRAaWV0Zi5vcmc8 bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IE11bHRpcGxlIEJGRCBzZXNz aW9ucyBiZXR3ZWVuIHRoZSBzYW1lIHBhaXIgb2YgZW5kLXBvaW50cw0KDQpSZXNoYWQsDQoNCk9u IE5vdiAyLCAyMDE1LCBhdCA5OjI5IFBNLCBSZXNoYWQgUmFobWFuIChycmFobWFuKSA8cnJhaG1h bkBjaXNjby5jb208bWFpbHRvOnJyYWhtYW5AY2lzY28uY29tPj4gd3JvdGU6DQoNCkhpIFNhbnRv c2gsDQoNCkV2ZW4gZm9yIHNpbmdsZS1ob3Agd2UgaGFkIGRpc2N1c3Npb25zIGFib3V0IGltcGxl bWVudGF0aW9ucyB3aGljaCBzdXBwb3J0IHRoZSBvcHRpb24gb2YgaGF2aW5nIG11bHRpcGxlIEJG RCBzaW5nbGUtaG9wIHNlc3Npb25zIG9uIDEgaW50ZXJmYWNlIGJldHdlZW4gMiAgZW5kcG9pbnRz LiBUaGF0IHdhcyBhbiBhcmd1bWVudCBmb3IgaGF2aW5nIHRoZSBCRkQgY29uZmlnIGluIHJvdXRp bmcgYXBwbGljYXRpb25zLiBUaGlzIGlzIHdoYXQgd2FzIGRpc2N1c3NlZCB0b2RheSBpbiB0aGUg V0cuIEFuZCBJIHRoaW5rIEdyZWfigJlzIHBvaW50IGlzIHRoYXQgd2UgZG9u4oCZdCBoYXZlIHRv IHN1cHBvcnQgdGhpcyBpbiB0aGUgYmFzZSBtb2RlbCwgYnV0IGltcGxlbWVudGF0aW9ucyBhcmUg aGF2ZSB2ZW5kb3Igc3BlY2lmaWMgbW9kZWwgd2hpY2ggc3VwcG9ydHMgdGhpcyBiZWhhdmlvci4N CkFyZSB0aGVyZSBhbHJlYWR5IHZlbmRvciBzcGVjaWZpYyBtb2RlbHMvaW1wbGVtZW50YXRpb25z IGluIHRoZSBzaW5nbGUgaG9wIGNhc2U/IE9SIGRpZCB5b3UgbWVhbiwgdGhlcmUgY291bGQgYmUg dmVuZG9yIHNwZWNpZmljIGV4dGVuc2lvbnM/DQoNCi1zYW0NCg0KDQpSZWdhcmRzLA0KUmVzaGFk Lg0KDQoNCkZyb206IFJ0Zy1iZmQgPHJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRn LWJmZC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIFNhbnRvc2ggUCBLIDxzYW50b3No cGtAanVuaXBlci5uZXQ8bWFpbHRvOnNhbnRvc2hwa0BqdW5pcGVyLm5ldD4+DQpEYXRlOiBUdWVz ZGF5LCBOb3ZlbWJlciAzLCAyMDE1IGF0IDE6MjUgQU0NClRvOiBHcmVnb3J5IE1pcnNreSA8Z3Jl Z29yeS5taXJza3lAZXJpY3Nzb24uY29tPG1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5j b20+PiwgInJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+IiA8cnRnLWJm ZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogTXVsdGlw bGUgQkZEIHNlc3Npb25zIGJldHdlZW4gdGhlIHNhbWUgcGFpciBvZiBlbmQtcG9pbnRzDQoNClRo aXMgaXMgZm9ybSBSRkMgNTg4MSBzZWN0aW9uIDMuDQoNCkluIHRoaXMgYXBwbGljYXRpb24sIHRo ZXJlIHdpbGwgYmUgb25seSBhIHNpbmdsZSBCRkQgc2Vzc2lvbiBiZXR3ZWVuDQogICB0d28gc3lz dGVtcyBvdmVyIGEgZ2l2ZW4gaW50ZXJmYWNlIChsb2dpY2FsIG9yIHBoeXNpY2FsKSBmb3IgYQ0K ICAgcGFydGljdWxhciBwcm90b2NvbC4gIFRoZSBCRkQgc2Vzc2lvbiBtdXN0IGJlIGJvdW5kIHRv IHRoaXMNCiAgIGludGVyZmFjZS4NCg0KV2hpY2ggc2F5cyBmb3Igc2luZ2xlaG9wIHlvdSB3aWxs IGhhdmUgb25seSBzaW5nbGUgQkZEIHNlc3Npb24gZm9yIGFuIGludGVyZmFjZS4gIFRoZSBjYXNl IHdoZXJlIHdlIGFyZSBzdHJ1Z2dsaW5nIGluIFlhbmcgaXMgZm9yIG11bHRpaG9wIEJGRCBzZXNz aW9uLg0KDQpUaGFua3MNClNhbnRvc2ggUCBLDQoNCg0KRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0 Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdyZWdvcnkgTWlyc2t5DQpTZW50 OiBUdWVzZGF5LCBOb3ZlbWJlciAwMywgMjAxNSA3OjU3IEFNDQpUbzogcnRnLWJmZEBpZXRmLm9y ZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4NClN1YmplY3Q6IE11bHRpcGxlIEJGRCBzZXNzaW9u cyBiZXR3ZWVuIHRoZSBzYW1lIHBhaXIgb2YgZW5kLXBvaW50cw0KDQpEZWFyIEFsbCwNCkkgdGhp bmsgdGhhdCB0aGlzIHBhcmFncmFwaCBmcm9tIFNlY3Rpb24gMiBvZiBSRkMgNTg4MSBwcm9oaWJp dHMgbXVsdGlwbGUgc2luZ2xlLWhvcCBCRkQgc2Vzc2lvbnMgYmV0d2VlbiB0aGUgc2FtZSBwYWly IG9mIGVuZCBwb2ludHM6DQogICBFYWNoIEJGRCBzZXNzaW9uIGJldHdlZW4gYSBwYWlyIG9mIHN5 c3RlbXMgTVVTVCB0cmF2ZXJzZSBhIHNlcGFyYXRlDQogICBuZXR3b3JrLWxheWVyIHBhdGggaW4g Ym90aCBkaXJlY3Rpb25zLiAgVGhpcyBpcyBuZWNlc3NhcnkgZm9yDQogICBkZW11bHRpcGxleGlu ZyB0byB3b3JrIHByb3Blcmx5LCBhbmQgYWxzbyBiZWNhdXNlIChieSBkZWZpbml0aW9uKQ0KICAg bXVsdGlwbGUgc2Vzc2lvbnMgd291bGQgb3RoZXJ3aXNlIGJlIHByb3RlY3RpbmcgdGhlIHNhbWUg cGF0aC4NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEdyZWcNCg0KDQo= --_000_DB3PR03MB078033D8DF9ACA2113E721CD9D2B0DB3PR03MB0780eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkFoYXJvbmk7DQoJcGFub3NlLTE6MiAxIDggMyAyIDEg NCAzIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRl LCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1z dHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglm b250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29sb3I6IzFGNDk3RDsNCgl0ZXh0LXRy YW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7DQoJdmVydGljYWwtYWxp Z246YmFzZWxpbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J IGNvbmN1ciB3aXRoIENhcmxvcywgb25seSB3YW50ZWQgdG8gYWRkIHRoYXQgaW4gdGhlIGNhc2Ug b2YgQkZEIGluIE1QTFMgTFNQIGFiaWxpdHkgZm9yIGluLWJhbmQgaW5pdGlhbGl6YXRpb24gZG9l cyBub3QgZXhpc3QgKGUuZy4gaW4gdGhlIGNhc2Ugb2YgUEhQLCBzZWUNCiBTZWN0aW9uIDUgaW4g UkZDIDU4ODQpLCBhbmQgc28gYW4gT09CIGluaXRpYWxpemF0aW9uIHByb2NlZHVyZSB3YXMgdW5h dm9pZGFibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5J4oCZZCBzYXkgd2UgbmVlZCBhIHZlcnkgc3Ryb25nIHVzZSBj YXNlIGZvciBtdWx0aXBsZSBCRkQgc2Vzc2lvbnMgYmV0d2VlbiB0aGUgc2FtZSBwYWlyIG9mIGVu ZHBvaW50cyB0byBqdXN0aWZ5IGludHJvZHVjdGlvbiBvZiB5ZXQgYW5vdGhlciBPT0IgaW5pdGlh bGl6YXRpb24NCiBwcm9jZWR1cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkgMiw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+U2FzaGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9mZmljZTogJiM0Mzs5NzItMzkyNjYz MDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2VsbDombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJiM0Mzs5NzItNTQ5MjY2MzAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkVtYWlsOiZuYnNwOyZuYnNwOyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNl c0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2FybG9zIFBpZ25hdGFybyAoY3BpZ25h dGEpPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE5vdmVtYmVyIDAzLCAyMDE1IDM6MTYgUE08 YnI+DQo8Yj5Ubzo8L2I+IFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pPGJyPg0KPGI+Q2M6PC9iPiBy dGctYmZkQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBNdWx0aXBsZSBCRkQgc2Vz c2lvbnMgYmV0d2VlbiB0aGUgc2FtZSBwYWlyIG9mIGVuZC1wb2ludHM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBSZXNoYWQsPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCByZWFsbHkgZGVwZW5kcyBvbiB3aGF0 IGlzIGNvbnNpZGVyZWQgYSDigJxwYXRo4oCdIG92ZXIgd2hpY2ggQkZEIGRldGVjdHMgZmF1bHRz LCBhbmQgaG93IHRoZSBpbml0aWFsIGRlbXV4IGNhbiBiZSBkb25lIHZzLiBib290c3RyYXBwZWQg b3V0LW9mLWJhbmQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlJGQyA1ODgxIGhhcyB0aGUgdGV4dCBxdW90ZWQgYnkgR3JlZywgYmVjYXVzZSBp biB0aGF0IGNhc2Ugc2luZ2xlLWhvcCBpbml0aWFsaXphdGlvbiBwcm9jZWR1cmVzIGNhbiBiZSBk b25lIChieSBiaW5kaW5nIHRoZSBpbnRlcmZhY2UgdG8gQkZEIGNvbnRleHQpIGFuZCBub3QgcmVx dWlyZSBvdXQtb2YtYmFuZCBkaXNjcmltaW5hdG9yIGJvb3RzdHJhcHBpbmcuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIG9uIGEg c2luZ2xlIGludGVyZmFjZSBiZXR3ZWVuIHR3byBmb3J3YXJkaW5nIGVuZHBvaW50cywgdGhlcmUg Y291bGQgYmUgbXVsdGlwbGUgc2Vzc2lvbnMgaW4gYSBnZW5lcmljIGFwcGxpY2F0aW9uLiBUaGUg c2ltcGxlc3QgZXhhbXBsZSBpcyB3aGF0IGlzIGRlc2NyaWJlZCBpbiB0aGUgc2Vjb25kIHBhcmFn cmFwaCBvZiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgy I3NlY3Rpb24tNiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4ODIjc2VjdGlvbi02 PC9hPi4NCiBJbiB0aGF0IGNhc2UsIGEgcGF0aCBpcyBhIHNwZWNpZmljIGRpZmZzZXJ2IGNvZGUg cG9pbnQgb3ZlciBJUHY0IGJldHdlZW4gdHdvIGVuZHBvaW50cywgYW5kIHRoYXQgaXMgdGhlIGNv bnRleHQgdXNlZCBmb3IgaW5pdGlhbGl6YXRpb24gdXNpbmcgc2luZ2xlLWhvcCBwcm9jZWR1cmVz LiBJbiBSRkM1ODg1IHdlIGNob3NlIHRvIGFsbG93IG9ubHkgb25lLCB0byB1c2Ugc2luZ2xlLWhv cCBpbml0aWFsaXphdGlvbiBmb3IgZXhhbXBsZSB3aXRoaW4NCiBhIHR1bm5lbCAoUFcpIGNvbnRl eHQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkZvciB0aGUgbXVsdGktaG9wIGNhc2UsIHRoZXJlIGNvdWxkIGFsc28gYmUgbXVsdGlwbGUgc2Vz c2lvbnMgYmV0d2VlbiBlbmRwb2ludHMuIElmIHRoZXJlIGlzIG9ubHkgb25lIHNlc3Npb24sIHRo ZW4gdGhlIGluaXRpYWxpemF0aW9uIGNhbiBiZSBkb25lIHVzaW5nIHNpbmdsZS1ob3AgcHJvY2Vk dXJlcyBiaW5kaW5nIHNvdXJjZS9kc3QgYWRkcmVzc2VzLiBIb3dldmVyLCBpcyB0aGVyZSBhcmUg bXVsdGlwbGUNCiBzZXNzaW9ucywgYXMgZS5nLiwgaWYgdGhlcmUgaXMgc29tZSBFQ01QLWF3YXJl bmVzcywgdGhlbiBzb21lIGRpZmZlcmVudCBhbmQgYWRkaXRpb25hbCBtZWNoYW5pc20gKGUuZy4s IG91dC1vZi1iYW5kIGJvb3RzdHJhcHBpbmcpIGlzIG5lZWRlZC4gVGhpcyBpcyBkZXNjcmliZWQg aW4gdGhlIHNlY29uZCBwYXJhZ3JhcGggb2YmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNTg4MyNzZWN0aW9uLTMiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM1ODgzI3NlY3Rpb24tMzwvYT4uDQogSW4gZmFjdCwgdGhlc2UgdHdvIG9wdGlvbnMgYXJl IGNvdmVyZWQgaW4gUzQuMSAobGltaXQgdG8gb25lIHNlc3Npb24gYW5kIHVzZSBzcmMvZHN0KSBh bmQgUzQuMiAoYWxsb3cgbXVsdGlwbGUgc2Vzc2lvbnMgYW5kIHVzZSBhbiBPT0IgYm9vdHN0cmFw cGluZykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFzIGZhciBhcyB0aGUgWUFORyBtb2RlbHMsIEnigJlkIHRoaW5rIHRoYXQgc2luZ2xlIHNl c3Npb24gZm9yIGJvdGggc2luZ2xlLSBhbmQgbXVsdGktaG9wIGNvdmVycyB2YXN0IG1ham9yaXR5 IG9mIHJlYWwgY2FzZXMsIGJlaW5nIHByYWdtYXRpYy4gSWYgc29tZW9uZSB3YW50cyB0byBoYXZl IGZvciBleGFtcGxlIG11bHRpcGxlIHNlc3Npb25zIGJldHdlZW4gYSBwYWlyIG9mIGVuZHBvaW50 IGFkZHJlc3NlcyBpbg0KIG11bHRpLWhvcCwgdGhlbiBhbiBPT0IgbWVjaGFuaXNtIGlzIG5lZWRl ZCwgYW5kIEkgZG8gbm90IGJlbGlldmUgdGhlcmUgaXMgYSBzcGVj4oCZZWQgb25lIG90aGVyIHRo YW4gZm9yIE1QTFMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+4oCUIENhcmxvcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE5vdiAzLCAyMDE1LCBhdCA0OjAwIFBNLCBSZXNo YWQgUmFobWFuIChycmFobWFuKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJyYWhtYW5AY2lzY28uY29t Ij5ycmFobWFuQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5IaSBTYW0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UeXBv IGluIG15IGVtYWlsIGluZGVlZC4gV2hhdCBJIG1lYW50IGlzIHRoYXQgdGhlcmUgY291bGQgYmUg dmVuZG9yIHNwZWNpZmljIGV4dGVuc2lvbnMgaWYgbmVlZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BbHNvIGxv b2tzIGxpa2UgdGhlcmUgd2FzIGNvbmZ1c2lvbiBpbiB0aGUgZGVzaWduIHRlYW0gKHNlZW1pbmds eSBjYXVzZWQgYnkgbXkgbWlzaW50ZXJwcmV0YXRpb24gb2Ygd2hhdCB3YXMgc2FpZCksIHRoZXJl IGlzIG5vIGtub3duIGltcGxlbWVudGF0aW9uIHdoaWNoIHN1cHBvcnRzIG11bHRpcGxlDQogQkZE IHNpbmdsZS1ob3Agc2Vzc2lvbnMgZm9yIHRoZSBzYW1lIHBhaXIgb2YgZW5kcG9pbnRzIChyaWdo dCBTYW50b3NoPykuIEZvciBNSCBpdOKAmXMgYSBkaWZmZXJlbnQgc3RvcnkgYmVjYXVzZSBvZiBt dWx0aXBsZS1wYXRocy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIERUIHdpbGwgZ2V0IHRvZ2V0aGVy IHRvIGNsYXJpZnkgYW5kIGFwb2xvZ2llcyBmb3IgdGhlIGNvbmZ1c2lvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlc2hhZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlNhbSBBbGRyaW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbGRyaW4uaWV0 ZkBnbWFpbC5jb20iPmFsZHJpbi5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPlR1ZXNkYXksIE5vdmVtYmVyIDMsIDIwMTUgYXQgMjo0OCBBTTxicj4NCjxiPlRvOiA8L2I+ UmVzaGFkICZsdDs8YSBocmVmPSJtYWlsdG86cnJhaG1hbkBjaXNjby5jb20iPnJyYWhtYW5AY2lz Y28uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPlNhbnRvc2ggUCBLICZsdDs8YSBocmVmPSJt YWlsdG86c2FudG9zaHBrQGp1bmlwZXIubmV0Ij5zYW50b3NocGtAanVuaXBlci5uZXQ8L2E+Jmd0 OywgR3JlZ29yeSBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmlj c3Nvbi5jb20iPmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBo cmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyI+cnRnLWJmZEBpZXRmLm9yZzwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIj5ydGctYmZkQGlldGYub3JnPC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IE11bHRpcGxlIEJGRCBzZXNzaW9ucyBiZXR3 ZWVuIHRoZSBzYW1lIHBhaXIgb2YgZW5kLXBvaW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmVzaGFk LA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+T24gTm92IDIsIDIwMTUsIGF0IDk6MjkgUE0sIFJlc2hhZCBSYWhtYW4gKHJyYWht YW4pICZsdDs8YSBocmVmPSJtYWlsdG86cnJhaG1hbkBjaXNjby5jb20iPnJyYWhtYW5AY2lzY28u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpIFNhbnRvc2gsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkV2ZW4gZm9yIHNpbmdsZS1ob3Agd2UgaGFkIGRpc2N1c3Npb25zIGFib3V0IGltcGxlbWVu dGF0aW9ucyB3aGljaCBzdXBwb3J0IHRoZSBvcHRpb24gb2YgaGF2aW5nIG11bHRpcGxlIEJGRCBz aW5nbGUtaG9wIHNlc3Npb25zIG9uIDEgaW50ZXJmYWNlIGJldHdlZW4gMiAmbmJzcDtlbmRwb2lu dHMuIFRoYXQNCiB3YXMgYW4gYXJndW1lbnQgZm9yIGhhdmluZyB0aGUgQkZEIGNvbmZpZyBpbiBy b3V0aW5nIGFwcGxpY2F0aW9ucy4gVGhpcyBpcyB3aGF0IHdhcyBkaXNjdXNzZWQgdG9kYXkgaW4g dGhlIFdHLiBBbmQgSSB0aGluayBHcmVn4oCZcyBwb2ludCBpcyB0aGF0IHdlIGRvbuKAmXQgaGF2 ZSB0byBzdXBwb3J0IHRoaXMgaW4gdGhlIGJhc2UgbW9kZWwsIGJ1dCBpbXBsZW1lbnRhdGlvbnMg YXJlIGhhdmUgdmVuZG9yIHNwZWNpZmljIG1vZGVsIHdoaWNoIHN1cHBvcnRzDQogdGhpcyBiZWhh dmlvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+QXJlIHRoZXJlIGFscmVhZHkgdmVuZG9yIHNwZWNpZmljIG1vZGVscy9pbXBs ZW1lbnRhdGlvbnMgaW4gdGhlIHNpbmdsZSBob3AgY2FzZT8gT1IgZGlkIHlvdSBtZWFuLCB0aGVy ZSBjb3VsZCBiZSB2ZW5kb3Igc3BlY2lmaWMgZXh0ZW5zaW9ucz88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LXNhbTxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5SZXNoYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+UnRnLWJmZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cnRnLWJmZC1ib3VuY2VzQGlldGYub3Jn PC9zcGFuPjwvYT4mZ3Q7DQogb24gYmVoYWxmIG9mIFNhbnRvc2ggUCBLICZsdDs8YSBocmVmPSJt YWlsdG86c2FudG9zaHBrQGp1bmlwZXIubmV0Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5z YW50b3NocGtAanVuaXBlci5uZXQ8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+VHVlc2RheSwgTm92 ZW1iZXIgMywgMjAxNSBhdCAxOjI1IEFNPGJyPg0KPGI+VG86PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5HcmVnb3J5IE1pcnNreSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPC9zcGFuPjwvYT4mZ3Q7LCAmcXVv dDs8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+cnRnLWJmZEBpZXRmLm9yZzwvc3Bhbj48L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1h aWx0bzpydGctYmZkQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ydGctYmZk QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlJFOiBNdWx0aXBsZSBCRkQgc2Vz c2lvbnMgYmV0d2VlbiB0aGUgc2FtZSBwYWlyIG9mIGVuZC1wb2ludHM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgaXMgZm9ybSBSRkMgNTg4MSBzZWN0aW9uIDMu PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5J biB0aGlzIGFwcGxpY2F0aW9uLCB0aGVyZSB3aWxsIGJlIG9ubHkgYSBzaW5nbGUgQkZEIHNlc3Np b24gYmV0d2Vlbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJw YWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdHdvIHN5c3Rl bXMgb3ZlciBhIGdpdmVuIGludGVyZmFjZSAobG9naWNhbCBvciBwaHlzaWNhbCkgZm9yIGE8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHBhcnRpY3VsYXIgcHJvdG9jb2wuJm5i c3A7IFRoZSBCRkQgc2Vzc2lvbiBtdXN0IGJlIGJvdW5kIHRvIHRoaXM8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGludGVyZmFjZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoaWNoIHNheXMgZm9yIHNpbmdsZWhvcCB5 b3Ugd2lsbCBoYXZlIG9ubHkgc2luZ2xlIEJGRCBzZXNzaW9uIGZvciBhbiBpbnRlcmZhY2UuICZu YnNwO1RoZSBjYXNlIHdoZXJlIHdlIGFyZSBzdHJ1Z2dsaW5nIGluIFlhbmcgaXMgZm9yIG11bHRp aG9wIEJGRCBzZXNzaW9uLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VGhhbmtzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNhbnRvc2ggUCBL PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SdGctYmZkDQogWzxhIGhyZWY9Im1haWx0bzpy dGctYmZkLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0 bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5HcmVnb3J5IE1pcnNreTxi cj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5UdWVzZGF5LCBOb3ZlbWJlciAwMywgMjAxNSA3OjU3IEFNPGJyPg0KPGI+VG86PC9i PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVm PSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cnRn LWJmZEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk11bHRpcGxlIEJGRCBzZXNzaW9u cyBiZXR3ZWVuIHRoZSBzYW1lIHBhaXIgb2YgZW5kLXBvaW50czxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RGVhciBBbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIHRoaW5r IHRoYXQgdGhpcyBwYXJhZ3JhcGggZnJvbSBTZWN0aW9uIDIgb2YgUkZDIDU4ODEgcHJvaGliaXRz IG11bHRpcGxlIHNpbmdsZS1ob3AgQkZEIHNlc3Npb25zIGJldHdlZW4gdGhlIHNhbWUgcGFpciBv ZiBlbmQgcG9pbnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7 IEVhY2ggQkZEIHNlc3Npb24gYmV0d2VlbiBhIHBhaXIgb2Ygc3lzdGVtcyBNVVNUIHRyYXZlcnNl IGEgc2VwYXJhdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBu ZXR3b3JrLWxheWVyIHBhdGggaW4gYm90aCBkaXJlY3Rpb25zLiZuYnNwOyBUaGlzIGlzIG5lY2Vz c2FyeSBmb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBkZW11 bHRpcGxleGluZyB0byB3b3JrIHByb3Blcmx5LCBhbmQgYWxzbyBiZWNhdXNlIChieSBkZWZpbml0 aW9uKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7IG11bHRpcGxl IHNlc3Npb25zIHdvdWxkIG90aGVyd2lzZSBiZSBwcm90ZWN0aW5nIHRoZSBzYW1lIHBhdGguPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB3PR03MB078033D8DF9ACA2113E721CD9D2B0DB3PR03MB0780eurp_-- From nobody Tue Nov 3 05:44:19 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241C91B2E93 for ; Tue, 3 Nov 2015 05:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvQk_my-7Dfy for ; Tue, 3 Nov 2015 05:44:14 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A72F1B33BE for ; Tue, 3 Nov 2015 05:44:13 -0800 (PST) Received: from SN1PR0501MB2142.namprd05.prod.outlook.com (10.163.228.157) by SN1PR0501MB2141.namprd05.prod.outlook.com (10.163.228.156) with Microsoft SMTP Server (TLS) id 15.1.312.18; Tue, 3 Nov 2015 13:44:11 +0000 Received: from SN1PR0501MB2142.namprd05.prod.outlook.com ([10.163.228.157]) by SN1PR0501MB2142.namprd05.prod.outlook.com ([10.163.228.157]) with mapi id 15.01.0312.014; Tue, 3 Nov 2015 13:44:11 +0000 From: Santosh P K To: "Carlos Pignataro (cpignata)" , "Reshad Rahman (rrahman)" Subject: RE: Multiple BFD sessions between the same pair of end-points Thread-Topic: Multiple BFD sessions between the same pair of end-points Thread-Index: AdEV3sMqUCCSGTiqTr+ZCWzJplyfOAAGR8BgAB2IA4D//ys5AIAAA1eAgABo74D///hoMA== Date: Tue, 3 Nov 2015 13:44:11 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> <730CA9F1-B952-4E2F-A61A-B4276BDE5EF4@gmail.com> <087FBA90-F5EB-4691-A5FD-96F784569F6C@cisco.com> In-Reply-To: <087FBA90-F5EB-4691-A5FD-96F784569F6C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=santoshpk@juniper.net; x-originating-ip: [116.197.184.12] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB2141; 5:r3xKiUp518veEVZk/AWqcN8/008F1lt04agn2kXFas9uU5cl0+xyFNAh87SSrK2Ljue1QrTlQbNMYvKuiwFGfjTRwxPkrdrR98qack0ypGovI8KQ2jtPxow66CsdKT5lKwgtQxeNuL+vW4xI+DalYQ==; 24:KduJLvoNOphsZ9O3fnXBWAOrzEH7QbFarKNzlTqB+D5hcTKH01VpA4zJHRBqhBTvOOFJkl4L/7Q3hb0+q76rYcRx/Yhe09O9J+wK3F1ieko=; 20:D7Oc2vCgsPUhsCEwbnkLmiSTrhPFyYgfgW+w8gtALpVMLEyfSj/hBcZ1jE87BVTytJKPpOVnw8vs/FmU7v2bbQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB2141; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014)(108003899814671)(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:SN1PR0501MB2141; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2141; x-forefront-prvs: 0749DC2CE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(199003)(51444003)(189002)(53824002)(164054003)(24454002)(76576001)(86362001)(74316001)(92566002)(77096005)(19625215002)(19609705001)(87936001)(19580405001)(102836002)(76176999)(50986999)(15975445007)(19580395003)(19300405004)(66066001)(54356999)(19617315012)(101416001)(5007970100001)(5004730100002)(5001960100002)(5001770100001)(97736004)(93886004)(5002640100001)(11100500001)(5008740100001)(5001920100001)(81156007)(5003600100002)(189998001)(33656002)(16236675004)(40100003)(99286002)(10400500002)(2900100001)(105586002)(122556002)(2950100001)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2141; H:SN1PR0501MB2142.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0501MB21425350FAB9EAB0FCF6496DB32B0SN1PR0501MB2142_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2015 13:44:11.5590 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2141 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 13:44:18 -0000 --_000_SN1PR0501MB21425350FAB9EAB0FCF6496DB32B0SN1PR0501MB2142_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2FybG9zLA0KT09CIGZvciBtdWx0aWhvcCBpcyBub3QgdGhlcmUgYW5kIGl0IGlzIG91dCBvZiBz Y29wZSBvZiBSRkMuIEhhdmluZyBzYWlkIHRoYXQgdGhlcmUgYXJlIGJ1bmNoIG9mIGV4dGVuc2lv biB0byBJR1AgYWxyZWFkeSB3aGljaCBjYXJyaWVzIEJGRCBkaXNjcmltaW5hdG9yIHdoaWNoIGNv dWxkIGJlIGxldmVyYWdlZCBmb3IgT09CIGZvciBNSCBCRkQgc2Vzc2lvbi4NCg0KVGhhbmtzDQpT YW50b3NoIFAgSw0KDQpGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQpTZW50OiBUdWVz ZGF5LCBOb3ZlbWJlciAwMywgMjAxNSA2OjQ2IFBNDQpUbzogUmVzaGFkIFJhaG1hbiAocnJhaG1h bikgPHJyYWhtYW5AY2lzY28uY29tPg0KQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBNdWx0aXBsZSBCRkQgc2Vzc2lvbnMgYmV0d2VlbiB0aGUgc2FtZSBwYWlyIG9mIGVuZC1wb2lu dHMNCg0KSGkgUmVzaGFkLA0KDQpJdCByZWFsbHkgZGVwZW5kcyBvbiB3aGF0IGlzIGNvbnNpZGVy ZWQgYSDigJxwYXRo4oCdIG92ZXIgd2hpY2ggQkZEIGRldGVjdHMgZmF1bHRzLCBhbmQgaG93IHRo ZSBpbml0aWFsIGRlbXV4IGNhbiBiZSBkb25lIHZzLiBib290c3RyYXBwZWQgb3V0LW9mLWJhbmQu DQoNClJGQyA1ODgxIGhhcyB0aGUgdGV4dCBxdW90ZWQgYnkgR3JlZywgYmVjYXVzZSBpbiB0aGF0 IGNhc2Ugc2luZ2xlLWhvcCBpbml0aWFsaXphdGlvbiBwcm9jZWR1cmVzIGNhbiBiZSBkb25lIChi eSBiaW5kaW5nIHRoZSBpbnRlcmZhY2UgdG8gQkZEIGNvbnRleHQpIGFuZCBub3QgcmVxdWlyZSBv dXQtb2YtYmFuZCBkaXNjcmltaW5hdG9yIGJvb3RzdHJhcHBpbmcuDQoNCkhvd2V2ZXIsIG9uIGEg c2luZ2xlIGludGVyZmFjZSBiZXR3ZWVuIHR3byBmb3J3YXJkaW5nIGVuZHBvaW50cywgdGhlcmUg Y291bGQgYmUgbXVsdGlwbGUgc2Vzc2lvbnMgaW4gYSBnZW5lcmljIGFwcGxpY2F0aW9uLiBUaGUg c2ltcGxlc3QgZXhhbXBsZSBpcyB3aGF0IGlzIGRlc2NyaWJlZCBpbiB0aGUgc2Vjb25kIHBhcmFn cmFwaCBvZiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTg4MiNzZWN0aW9uLTYuIElu IHRoYXQgY2FzZSwgYSBwYXRoIGlzIGEgc3BlY2lmaWMgZGlmZnNlcnYgY29kZSBwb2ludCBvdmVy IElQdjQgYmV0d2VlbiB0d28gZW5kcG9pbnRzLCBhbmQgdGhhdCBpcyB0aGUgY29udGV4dCB1c2Vk IGZvciBpbml0aWFsaXphdGlvbiB1c2luZyBzaW5nbGUtaG9wIHByb2NlZHVyZXMuIEluIFJGQzU4 ODUgd2UgY2hvc2UgdG8gYWxsb3cgb25seSBvbmUsIHRvIHVzZSBzaW5nbGUtaG9wIGluaXRpYWxp emF0aW9uIGZvciBleGFtcGxlIHdpdGhpbiBhIHR1bm5lbCAoUFcpIGNvbnRleHQuDQoNCkZvciB0 aGUgbXVsdGktaG9wIGNhc2UsIHRoZXJlIGNvdWxkIGFsc28gYmUgbXVsdGlwbGUgc2Vzc2lvbnMg YmV0d2VlbiBlbmRwb2ludHMuIElmIHRoZXJlIGlzIG9ubHkgb25lIHNlc3Npb24sIHRoZW4gdGhl IGluaXRpYWxpemF0aW9uIGNhbiBiZSBkb25lIHVzaW5nIHNpbmdsZS1ob3AgcHJvY2VkdXJlcyBi aW5kaW5nIHNvdXJjZS9kc3QgYWRkcmVzc2VzLiBIb3dldmVyLCBpcyB0aGVyZSBhcmUgbXVsdGlw bGUgc2Vzc2lvbnMsIGFzIGUuZy4sIGlmIHRoZXJlIGlzIHNvbWUgRUNNUC1hd2FyZW5lc3MsIHRo ZW4gc29tZSBkaWZmZXJlbnQgYW5kIGFkZGl0aW9uYWwgbWVjaGFuaXNtIChlLmcuLCBvdXQtb2Yt YmFuZCBib290c3RyYXBwaW5nKSBpcyBuZWVkZWQuIFRoaXMgaXMgZGVzY3JpYmVkIGluIHRoZSBz ZWNvbmQgcGFyYWdyYXBoIG9mIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgzI3Nl Y3Rpb24tMy4gSW4gZmFjdCwgdGhlc2UgdHdvIG9wdGlvbnMgYXJlIGNvdmVyZWQgaW4gUzQuMSAo bGltaXQgdG8gb25lIHNlc3Npb24gYW5kIHVzZSBzcmMvZHN0KSBhbmQgUzQuMiAoYWxsb3cgbXVs dGlwbGUgc2Vzc2lvbnMgYW5kIHVzZSBhbiBPT0IgYm9vdHN0cmFwcGluZykuDQoNCkFzIGZhciBh cyB0aGUgWUFORyBtb2RlbHMsIEnigJlkIHRoaW5rIHRoYXQgc2luZ2xlIHNlc3Npb24gZm9yIGJv dGggc2luZ2xlLSBhbmQgbXVsdGktaG9wIGNvdmVycyB2YXN0IG1ham9yaXR5IG9mIHJlYWwgY2Fz ZXMsIGJlaW5nIHByYWdtYXRpYy4gSWYgc29tZW9uZSB3YW50cyB0byBoYXZlIGZvciBleGFtcGxl IG11bHRpcGxlIHNlc3Npb25zIGJldHdlZW4gYSBwYWlyIG9mIGVuZHBvaW50IGFkZHJlc3NlcyBp biBtdWx0aS1ob3AsIHRoZW4gYW4gT09CIG1lY2hhbmlzbSBpcyBuZWVkZWQsIGFuZCBJIGRvIG5v dCBiZWxpZXZlIHRoZXJlIGlzIGEgc3BlY+KAmWVkIG9uZSBvdGhlciB0aGFuIGZvciBNUExTLg0K DQpUaGFua3MsDQoNCuKAlCBDYXJsb3MuDQoNCk9uIE5vdiAzLCAyMDE1LCBhdCA0OjAwIFBNLCBS ZXNoYWQgUmFobWFuIChycmFobWFuKSA8cnJhaG1hbkBjaXNjby5jb208bWFpbHRvOnJyYWhtYW5A Y2lzY28uY29tPj4gd3JvdGU6DQoNCkhpIFNhbSwNCg0KVHlwbyBpbiBteSBlbWFpbCBpbmRlZWQu IFdoYXQgSSBtZWFudCBpcyB0aGF0IHRoZXJlIGNvdWxkIGJlIHZlbmRvciBzcGVjaWZpYyBleHRl bnNpb25zIGlmIG5lZWRlZC4NCg0KQWxzbyBsb29rcyBsaWtlIHRoZXJlIHdhcyBjb25mdXNpb24g aW4gdGhlIGRlc2lnbiB0ZWFtIChzZWVtaW5nbHkgY2F1c2VkIGJ5IG15IG1pc2ludGVycHJldGF0 aW9uIG9mIHdoYXQgd2FzIHNhaWQpLCB0aGVyZSBpcyBubyBrbm93biBpbXBsZW1lbnRhdGlvbiB3 aGljaCBzdXBwb3J0cyBtdWx0aXBsZSBCRkQgc2luZ2xlLWhvcCBzZXNzaW9ucyBmb3IgdGhlIHNh bWUgcGFpciBvZiBlbmRwb2ludHMgKHJpZ2h0IFNhbnRvc2g/KS4gRm9yIE1IIGl04oCZcyBhIGRp ZmZlcmVudCBzdG9yeSBiZWNhdXNlIG9mIG11bHRpcGxlLXBhdGhzLg0KDQpUaGUgRFQgd2lsbCBn ZXQgdG9nZXRoZXIgdG8gY2xhcmlmeSBhbmQgYXBvbG9naWVzIGZvciB0aGUgY29uZnVzaW9uLg0K DQpSZWdhcmRzLA0KUmVzaGFkLg0KDQpGcm9tOiBTYW0gQWxkcmluIDxhbGRyaW4uaWV0ZkBnbWFp bC5jb208bWFpbHRvOmFsZHJpbi5pZXRmQGdtYWlsLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBOb3Zl bWJlciAzLCAyMDE1IGF0IDI6NDggQU0NClRvOiBSZXNoYWQgPHJyYWhtYW5AY2lzY28uY29tPG1h aWx0bzpycmFobWFuQGNpc2NvLmNvbT4+DQpDYzogU2FudG9zaCBQIEsgPHNhbnRvc2hwa0BqdW5p cGVyLm5ldDxtYWlsdG86c2FudG9zaHBrQGp1bmlwZXIubmV0Pj4sIEdyZWdvcnkgTWlyc2t5IDxn cmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29u LmNvbT4+LCAicnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4iIDxydGct YmZkQGlldGYub3JnPG1haWx0bzpydGctYmZkQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBNdWx0 aXBsZSBCRkQgc2Vzc2lvbnMgYmV0d2VlbiB0aGUgc2FtZSBwYWlyIG9mIGVuZC1wb2ludHMNCg0K UmVzaGFkLA0KDQpPbiBOb3YgMiwgMjAxNSwgYXQgOToyOSBQTSwgUmVzaGFkIFJhaG1hbiAocnJh aG1hbikgPHJyYWhtYW5AY2lzY28uY29tPG1haWx0bzpycmFobWFuQGNpc2NvLmNvbT4+IHdyb3Rl Og0KDQpIaSBTYW50b3NoLA0KDQpFdmVuIGZvciBzaW5nbGUtaG9wIHdlIGhhZCBkaXNjdXNzaW9u cyBhYm91dCBpbXBsZW1lbnRhdGlvbnMgd2hpY2ggc3VwcG9ydCB0aGUgb3B0aW9uIG9mIGhhdmlu ZyBtdWx0aXBsZSBCRkQgc2luZ2xlLWhvcCBzZXNzaW9ucyBvbiAxIGludGVyZmFjZSBiZXR3ZWVu IDIgIGVuZHBvaW50cy4gVGhhdCB3YXMgYW4gYXJndW1lbnQgZm9yIGhhdmluZyB0aGUgQkZEIGNv bmZpZyBpbiByb3V0aW5nIGFwcGxpY2F0aW9ucy4gVGhpcyBpcyB3aGF0IHdhcyBkaXNjdXNzZWQg dG9kYXkgaW4gdGhlIFdHLiBBbmQgSSB0aGluayBHcmVn4oCZcyBwb2ludCBpcyB0aGF0IHdlIGRv buKAmXQgaGF2ZSB0byBzdXBwb3J0IHRoaXMgaW4gdGhlIGJhc2UgbW9kZWwsIGJ1dCBpbXBsZW1l bnRhdGlvbnMgYXJlIGhhdmUgdmVuZG9yIHNwZWNpZmljIG1vZGVsIHdoaWNoIHN1cHBvcnRzIHRo aXMgYmVoYXZpb3IuDQpBcmUgdGhlcmUgYWxyZWFkeSB2ZW5kb3Igc3BlY2lmaWMgbW9kZWxzL2lt cGxlbWVudGF0aW9ucyBpbiB0aGUgc2luZ2xlIGhvcCBjYXNlPyBPUiBkaWQgeW91IG1lYW4sIHRo ZXJlIGNvdWxkIGJlIHZlbmRvciBzcGVjaWZpYyBleHRlbnNpb25zPw0KDQotc2FtDQoNCg0KUmVn YXJkcywNClJlc2hhZC4NCg0KDQpGcm9tOiBSdGctYmZkIDxydGctYmZkLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBTYW50b3No IFAgSyA8c2FudG9zaHBrQGp1bmlwZXIubmV0PG1haWx0bzpzYW50b3NocGtAanVuaXBlci5uZXQ+ Pg0KRGF0ZTogVHVlc2RheSwgTm92ZW1iZXIgMywgMjAxNSBhdCAxOjI1IEFNDQpUbzogR3JlZ29y eSBNaXJza3kgPGdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTxtYWlsdG86Z3JlZ29yeS5taXJz a3lAZXJpY3Nzb24uY29tPj4sICJydGctYmZkQGlldGYub3JnPG1haWx0bzpydGctYmZkQGlldGYu b3JnPiIgPHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+Pg0KU3ViamVj dDogUkU6IE11bHRpcGxlIEJGRCBzZXNzaW9ucyBiZXR3ZWVuIHRoZSBzYW1lIHBhaXIgb2YgZW5k LXBvaW50cw0KDQpUaGlzIGlzIGZvcm0gUkZDIDU4ODEgc2VjdGlvbiAzLg0KDQpJbiB0aGlzIGFw cGxpY2F0aW9uLCB0aGVyZSB3aWxsIGJlIG9ubHkgYSBzaW5nbGUgQkZEIHNlc3Npb24gYmV0d2Vl bg0KICAgdHdvIHN5c3RlbXMgb3ZlciBhIGdpdmVuIGludGVyZmFjZSAobG9naWNhbCBvciBwaHlz aWNhbCkgZm9yIGENCiAgIHBhcnRpY3VsYXIgcHJvdG9jb2wuICBUaGUgQkZEIHNlc3Npb24gbXVz dCBiZSBib3VuZCB0byB0aGlzDQogICBpbnRlcmZhY2UuDQoNCldoaWNoIHNheXMgZm9yIHNpbmds ZWhvcCB5b3Ugd2lsbCBoYXZlIG9ubHkgc2luZ2xlIEJGRCBzZXNzaW9uIGZvciBhbiBpbnRlcmZh Y2UuICBUaGUgY2FzZSB3aGVyZSB3ZSBhcmUgc3RydWdnbGluZyBpbiBZYW5nIGlzIGZvciBtdWx0 aWhvcCBCRkQgc2Vzc2lvbi4NCg0KVGhhbmtzDQpTYW50b3NoIFAgSw0KDQoNCkZyb206IFJ0Zy1i ZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHcmVnb3J5 IE1pcnNreQ0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMDMsIDIwMTUgNzo1NyBBTQ0KVG86IHJ0 Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBNdWx0aXBs ZSBCRkQgc2Vzc2lvbnMgYmV0d2VlbiB0aGUgc2FtZSBwYWlyIG9mIGVuZC1wb2ludHMNCg0KRGVh ciBBbGwsDQpJIHRoaW5rIHRoYXQgdGhpcyBwYXJhZ3JhcGggZnJvbSBTZWN0aW9uIDIgb2YgUkZD IDU4ODEgcHJvaGliaXRzIG11bHRpcGxlIHNpbmdsZS1ob3AgQkZEIHNlc3Npb25zIGJldHdlZW4g dGhlIHNhbWUgcGFpciBvZiBlbmQgcG9pbnRzOg0KICAgRWFjaCBCRkQgc2Vzc2lvbiBiZXR3ZWVu IGEgcGFpciBvZiBzeXN0ZW1zIE1VU1QgdHJhdmVyc2UgYSBzZXBhcmF0ZQ0KICAgbmV0d29yay1s YXllciBwYXRoIGluIGJvdGggZGlyZWN0aW9ucy4gIFRoaXMgaXMgbmVjZXNzYXJ5IGZvcg0KICAg ZGVtdWx0aXBsZXhpbmcgdG8gd29yayBwcm9wZXJseSwgYW5kIGFsc28gYmVjYXVzZSAoYnkgZGVm aW5pdGlvbikNCiAgIG11bHRpcGxlIHNlc3Npb25zIHdvdWxkIG90aGVyd2lzZSBiZSBwcm90ZWN0 aW5nIHRoZSBzYW1lIHBhdGguDQoNCiAgICAgICAgICAgICAgICBSZWdhcmRzLA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCg0K --_000_SN1PR0501MB21425350FAB9EAB0FCF6496DB32B0SN1PR0501MB2142_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLWNvbnZlcnRl ZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNhcmxvcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6NS4yNXB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T09CIGZvciBtdWx0aWhvcCBpcyBub3QgdGhlcmUgYW5k IGl0IGlzIG91dCBvZiBzY29wZSBvZiBSRkMuIEhhdmluZyBzYWlkIHRoYXQgdGhlcmUgYXJlIGJ1 bmNoIG9mIGV4dGVuc2lvbiB0byBJR1AgYWxyZWFkeSB3aGljaCBjYXJyaWVzDQogQkZEIGRpc2Ny aW1pbmF0b3Igd2hpY2ggY291bGQgYmUgbGV2ZXJhZ2VkIGZvciBPT0IgZm9yIE1IIEJGRCBzZXNz aW9uLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1pbmRlbnQ6NS4yNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TYW50b3NoIFAgSw0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4gUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+Q2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpPGJyPg0KPGI+U2Vu dDo8L2I+IFR1ZXNkYXksIE5vdmVtYmVyIDAzLCAyMDE1IDY6NDYgUE08YnI+DQo8Yj5Ubzo8L2I+ IFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pICZsdDtycmFobWFuQGNpc2NvLmNvbSZndDs8YnI+DQo8 Yj5DYzo8L2I+IHJ0Zy1iZmRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IE11bHRp cGxlIEJGRCBzZXNzaW9ucyBiZXR3ZWVuIHRoZSBzYW1lIHBhaXIgb2YgZW5kLXBvaW50czxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFJlc2hhZCw8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHJlYWxseSBkZXBl bmRzIG9uIHdoYXQgaXMgY29uc2lkZXJlZCBhIOKAnHBhdGjigJ0gb3ZlciB3aGljaCBCRkQgZGV0 ZWN0cyBmYXVsdHMsIGFuZCBob3cgdGhlIGluaXRpYWwgZGVtdXggY2FuIGJlIGRvbmUgdnMuIGJv b3RzdHJhcHBlZCBvdXQtb2YtYmFuZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+UkZDIDU4ODEgaGFzIHRoZSB0ZXh0IHF1b3RlZCBieSBHcmVn LCBiZWNhdXNlIGluIHRoYXQgY2FzZSBzaW5nbGUtaG9wIGluaXRpYWxpemF0aW9uIHByb2NlZHVy ZXMgY2FuIGJlIGRvbmUgKGJ5IGJpbmRpbmcgdGhlIGludGVyZmFjZSB0byBCRkQgY29udGV4dCkg YW5kIG5vdCByZXF1aXJlIG91dC1vZi1iYW5kIGRpc2NyaW1pbmF0b3IgYm9vdHN0cmFwcGluZy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93 ZXZlciwgb24gYSBzaW5nbGUgaW50ZXJmYWNlIGJldHdlZW4gdHdvIGZvcndhcmRpbmcgZW5kcG9p bnRzLCB0aGVyZSBjb3VsZCBiZSBtdWx0aXBsZSBzZXNzaW9ucyBpbiBhIGdlbmVyaWMgYXBwbGlj YXRpb24uIFRoZSBzaW1wbGVzdCBleGFtcGxlIGlzIHdoYXQgaXMgZGVzY3JpYmVkIGluIHRoZSBz ZWNvbmQgcGFyYWdyYXBoIG9mJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzU4ODIjc2VjdGlvbi02Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTg4 MiNzZWN0aW9uLTY8L2E+Lg0KIEluIHRoYXQgY2FzZSwgYSBwYXRoIGlzIGEgc3BlY2lmaWMgZGlm ZnNlcnYgY29kZSBwb2ludCBvdmVyIElQdjQgYmV0d2VlbiB0d28gZW5kcG9pbnRzLCBhbmQgdGhh dCBpcyB0aGUgY29udGV4dCB1c2VkIGZvciBpbml0aWFsaXphdGlvbiB1c2luZyBzaW5nbGUtaG9w IHByb2NlZHVyZXMuIEluIFJGQzU4ODUgd2UgY2hvc2UgdG8gYWxsb3cgb25seSBvbmUsIHRvIHVz ZSBzaW5nbGUtaG9wIGluaXRpYWxpemF0aW9uIGZvciBleGFtcGxlIHdpdGhpbg0KIGEgdHVubmVs IChQVykgY29udGV4dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Rm9yIHRoZSBtdWx0aS1ob3AgY2FzZSwgdGhlcmUgY291bGQgYWxzbyBiZSBt dWx0aXBsZSBzZXNzaW9ucyBiZXR3ZWVuIGVuZHBvaW50cy4gSWYgdGhlcmUgaXMgb25seSBvbmUg c2Vzc2lvbiwgdGhlbiB0aGUgaW5pdGlhbGl6YXRpb24gY2FuIGJlIGRvbmUgdXNpbmcgc2luZ2xl LWhvcCBwcm9jZWR1cmVzIGJpbmRpbmcgc291cmNlL2RzdCBhZGRyZXNzZXMuIEhvd2V2ZXIsIGlz IHRoZXJlIGFyZSBtdWx0aXBsZQ0KIHNlc3Npb25zLCBhcyBlLmcuLCBpZiB0aGVyZSBpcyBzb21l IEVDTVAtYXdhcmVuZXNzLCB0aGVuIHNvbWUgZGlmZmVyZW50IGFuZCBhZGRpdGlvbmFsIG1lY2hh bmlzbSAoZS5nLiwgb3V0LW9mLWJhbmQgYm9vdHN0cmFwcGluZykgaXMgbmVlZGVkLiBUaGlzIGlz IGRlc2NyaWJlZCBpbiB0aGUgc2Vjb25kIHBhcmFncmFwaCBvZiZuYnNwOzxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgzI3NlY3Rpb24tMyI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzU4ODMjc2VjdGlvbi0zPC9hPi4NCiBJbiBmYWN0LCB0aGVzZSB0d28g b3B0aW9ucyBhcmUgY292ZXJlZCBpbiBTNC4xIChsaW1pdCB0byBvbmUgc2Vzc2lvbiBhbmQgdXNl IHNyYy9kc3QpIGFuZCBTNC4yIChhbGxvdyBtdWx0aXBsZSBzZXNzaW9ucyBhbmQgdXNlIGFuIE9P QiBib290c3RyYXBwaW5nKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QXMgZmFyIGFzIHRoZSBZQU5HIG1vZGVscywgSeKAmWQgdGhpbmsgdGhh dCBzaW5nbGUgc2Vzc2lvbiBmb3IgYm90aCBzaW5nbGUtIGFuZCBtdWx0aS1ob3AgY292ZXJzIHZh c3QgbWFqb3JpdHkgb2YgcmVhbCBjYXNlcywgYmVpbmcgcHJhZ21hdGljLiBJZiBzb21lb25lIHdh bnRzIHRvIGhhdmUgZm9yIGV4YW1wbGUgbXVsdGlwbGUgc2Vzc2lvbnMgYmV0d2VlbiBhIHBhaXIg b2YgZW5kcG9pbnQgYWRkcmVzc2VzIGluDQogbXVsdGktaG9wLCB0aGVuIGFuIE9PQiBtZWNoYW5p c20gaXMgbmVlZGVkLCBhbmQgSSBkbyBub3QgYmVsaWV2ZSB0aGVyZSBpcyBhIHNwZWPigJllZCBv bmUgb3RoZXIgdGhhbiBmb3IgTVBMUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJQgQ2FybG9zLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTm92IDMsIDIwMTUsIGF0IDQ6 MDAgUE0sIFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pICZsdDs8YSBocmVmPSJtYWlsdG86cnJhaG1h bkBjaXNjby5jb20iPnJyYWhtYW5AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkhpIFNhbSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlR5cG8gaW4gbXkgZW1haWwgaW5kZWVkLiBXaGF0 IEkgbWVhbnQgaXMgdGhhdCB0aGVyZSBjb3VsZCBiZSB2ZW5kb3Igc3BlY2lmaWMgZXh0ZW5zaW9u cyBpZiBuZWVkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkFsc28gbG9va3MgbGlrZSB0aGVyZSB3YXMgY29uZnVzaW9uIGluIHRoZSBkZXNpZ24gdGVhbSAo c2VlbWluZ2x5IGNhdXNlZCBieSBteSBtaXNpbnRlcnByZXRhdGlvbiBvZiB3aGF0IHdhcyBzYWlk KSwgdGhlcmUgaXMgbm8ga25vd24gaW1wbGVtZW50YXRpb24gd2hpY2ggc3VwcG9ydHMgbXVsdGlw bGUNCiBCRkQgc2luZ2xlLWhvcCBzZXNzaW9ucyBmb3IgdGhlIHNhbWUgcGFpciBvZiBlbmRwb2lu dHMgKHJpZ2h0IFNhbnRvc2g/KS4gRm9yIE1IIGl04oCZcyBhIGRpZmZlcmVudCBzdG9yeSBiZWNh dXNlIG9mIG11bHRpcGxlLXBhdGhzLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5UaGUgRFQgd2lsbCBnZXQgdG9nZXRoZXIgdG8gY2xhcmlmeSBhbmQg YXBvbG9naWVzIGZvciB0aGUgY29uZnVzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmVzaGFkLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2FtIEFsZHJpbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmFsZHJpbi5pZXRmQGdtYWlsLmNvbSI+YWxkcmluLmlldGZAZ21haWwu Y29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgTm92ZW1iZXIgMywgMjAxNSBh dCAyOjQ4IEFNPGJyPg0KPGI+VG86IDwvYj5SZXNoYWQgJmx0OzxhIGhyZWY9Im1haWx0bzpycmFo bWFuQGNpc2NvLmNvbSI+cnJhaG1hbkBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+ U2FudG9zaCBQIEsgJmx0OzxhIGhyZWY9Im1haWx0bzpzYW50b3NocGtAanVuaXBlci5uZXQiPnNh bnRvc2hwa0BqdW5pcGVyLm5ldDwvYT4mZ3Q7LCBHcmVnb3J5IE1pcnNreSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSI+Z3JlZ29yeS5taXJza3lAZXJpY3Nz b24uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIj5y dGctYmZkQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0 Zi5vcmciPnJ0Zy1iZmRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTog TXVsdGlwbGUgQkZEIHNlc3Npb25zIGJldHdlZW4gdGhlIHNhbWUgcGFpciBvZiBlbmQtcG9pbnRz PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZXNo YWQsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5PbiBOb3YgMiwgMjAx NSwgYXQgOToyOSBQTSwgUmVzaGFkIFJhaG1hbiAocnJhaG1hbikgJmx0OzxhIGhyZWY9Im1haWx0 bzpycmFobWFuQGNpc2NvLmNvbSI+cnJhaG1hbkBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgU2FudG9z aCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RXZlbiBmb3Ig c2luZ2xlLWhvcCB3ZSBoYWQgZGlzY3Vzc2lvbnMgYWJvdXQgaW1wbGVtZW50YXRpb25zIHdoaWNo IHN1cHBvcnQgdGhlIG9wdGlvbiBvZiBoYXZpbmcgbXVsdGlwbGUgQkZEIHNpbmdsZS1ob3Agc2Vz c2lvbnMgb24gMSBpbnRlcmZhY2UgYmV0d2VlbiAyICZuYnNwO2VuZHBvaW50cy4gVGhhdCB3YXMN CiBhbiBhcmd1bWVudCBmb3IgaGF2aW5nIHRoZSBCRkQgY29uZmlnIGluIHJvdXRpbmcgYXBwbGlj YXRpb25zLiBUaGlzIGlzIHdoYXQgd2FzIGRpc2N1c3NlZCB0b2RheSBpbiB0aGUgV0cuIEFuZCBJ IHRoaW5rIEdyZWfigJlzIHBvaW50IGlzIHRoYXQgd2UgZG9u4oCZdCBoYXZlIHRvIHN1cHBvcnQg dGhpcyBpbiB0aGUgYmFzZSBtb2RlbCwgYnV0IGltcGxlbWVudGF0aW9ucyBhcmUgaGF2ZSB2ZW5k b3Igc3BlY2lmaWMgbW9kZWwgd2hpY2ggc3VwcG9ydHMgdGhpcw0KIGJlaGF2aW9yLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BcmUgdGhlcmUgYWxy ZWFkeSB2ZW5kb3Igc3BlY2lmaWMgbW9kZWxzL2ltcGxlbWVudGF0aW9ucyBpbiB0aGUgc2luZ2xl IGhvcCBjYXNlPyBPUiBkaWQgeW91IG1lYW4sIHRoZXJlIGNvdWxkIGJlIHZlbmRvciBzcGVjaWZp YyBleHRlbnNpb25zPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4tc2FtPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmVzaGFkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJ0Zy1iZmQg Jmx0OzxhIGhyZWY9Im1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ow0K IG9uIGJlaGFsZiBvZiBTYW50b3NoIFAgSyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhbnRvc2hwa0Bq dW5pcGVyLm5ldCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+c2FudG9zaHBrQGp1bmlwZXIu bmV0PC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlR1ZXNkYXksIE5vdmVtYmVyIDMsIDIwMTUgYXQg MToyNSBBTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L2I+R3JlZ29yeSBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnb3J5 Lm1pcnNreUBlcmljc3Nvbi5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmdyZWdvcnku bWlyc2t5QGVyaWNzc29uLmNvbTwvc3Bhbj48L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRv OnJ0Zy1iZmRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJ0Zy1iZmRAaWV0 Zi5vcmc8L3NwYW4+PC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cnRnLWJmZEBpZXRmLm9yZzwvc3Bhbj48 L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjwvYj5SRTogTXVsdGlwbGUgQkZEIHNlc3Npb25zIGJldHdlZW4gdGhl IHNhbWUgcGFpciBvZiBlbmQtcG9pbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzIGlzIGZvcm0gUkZD IDU4ODEgc2VjdGlvbiAzLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SW4gdGhpcyBhcHBsaWNhdGlvbiwg dGhlcmUgd2lsbCBiZSBvbmx5IGEgc2luZ2xlIEJGRCBzZXNzaW9uIGJldHdlZW48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IHR3byBzeXN0ZW1zIG92ZXIgYSBnaXZlbiBpbnRlcmZhY2UgKGxvZ2lj YWwgb3IgcGh5c2ljYWwpIGZvciBhPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBh Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBwYXJ0aWN1bGFy IHByb3RvY29sLiZuYnNwOyBUaGUgQkZEIHNlc3Npb24gbXVzdCBiZSBib3VuZCB0byB0aGlzPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBpbnRlcmZhY2UuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaGljaCBzYXlzIGZvciBz aW5nbGVob3AgeW91IHdpbGwgaGF2ZSBvbmx5IHNpbmdsZSBCRkQgc2Vzc2lvbiBmb3IgYW4gaW50 ZXJmYWNlLiAmbmJzcDtUaGUgY2FzZSB3aGVyZSB3ZSBhcmUgc3RydWdnbGluZyBpbiBZYW5nIGlz IGZvciBtdWx0aWhvcCBCRkQgc2Vzc2lvbi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rczwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TYW50b3NoIFAgSzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UnRnLWJmZA0KIFs8YSBo cmVmPSJtYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5tYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dPHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uIEJlaGFsZiBP ZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+R3Jl Z29yeSBNaXJza3k8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwgTm92ZW1iZXIgMDMsIDIwMTUgNzo1NyBBTTxi cj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPnJ0Zy1iZmRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5NdWx0aXBs ZSBCRkQgc2Vzc2lvbnMgYmV0d2VlbiB0aGUgc2FtZSBwYWlyIG9mIGVuZC1wb2ludHM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRl YXIgQWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSB0aGluayB0aGF0IHRoaXMgcGFyYWdyYXBoIGZy b20gU2VjdGlvbiAyIG9mIFJGQyA1ODgxIHByb2hpYml0cyBtdWx0aXBsZSBzaW5nbGUtaG9wIEJG RCBzZXNzaW9ucyBiZXR3ZWVuIHRoZSBzYW1lIHBhaXIgb2YgZW5kIHBvaW50czo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOyZuYnNwOyBFYWNoIEJGRCBzZXNzaW9uIGJldHdlZW4gYSBwYWlyIG9m IHN5c3RlbXMgTVVTVCB0cmF2ZXJzZSBhIHNlcGFyYXRlPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDsmbmJzcDsgbmV0d29yay1sYXllciBwYXRoIGluIGJvdGggZGlyZWN0aW9ucy4mbmJzcDsgVGhp cyBpcyBuZWNlc3NhcnkgZm9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsgZGVtdWx0 aXBsZXhpbmcgdG8gd29yayBwcm9wZXJseSwgYW5kIGFsc28gYmVjYXVzZSAoYnkgZGVmaW5pdGlv bik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyBtdWx0aXBsZSBzZXNzaW9ucyB3b3Vs ZCBvdGhlcndpc2UgYmUgcHJvdGVjdGluZyB0aGUgc2FtZSBwYXRoLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_SN1PR0501MB21425350FAB9EAB0FCF6496DB32B0SN1PR0501MB2142_-- From nobody Tue Nov 3 16:48:50 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711731A6F3C for ; Tue, 3 Nov 2015 16:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjCfbzEGCZFZ for ; Tue, 3 Nov 2015 16:48:46 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14EC01A6F2B for ; Tue, 3 Nov 2015 16:48:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33169; q=dns/txt; s=iport; t=1446598126; x=1447807726; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tPtmK5EoqMk7DyZVEIvrqf/7QyyauCUl0aL7T8q3YUI=; b=Pc9XDmUyfSWHYdzMxjcBGLd5Ik6g9TnXfQyA/8hc2ck25Ofwc6j790EL uhJs2n8rd7uPYNLABXnSIPAR/dRWyT/XXkJ6c2cl5UZJ2SP3qujBSanTZ wi5O7puQACP04KjyA69U6Nge0tpaaDAx22VdUW5ZBgqeSlztSYj+0pEhP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D9AQAPVTlW/4QNJK1egm5NU28GvT4BDYFdIYVyAoE8OBQBAQEBAQEBgQqENQEBAQQtTA4CAgEIEQMBAQEhAQYHFgsRFAkIAgQBDQWIGQMSDb06DYQuAQEBAQEBAQEBAQEBAQEBAQEBAQEBFAQEhlGEfoJTgVcLBgEsEw0JhCcFkmaDYAGFHIYRgXSUbIdRAR8BAUKCER2BVnKDawgXI4EHAQEB X-IronPort-AV: E=Sophos;i="5.20,240,1444694400"; d="scan'208,217";a="204777049" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-8.cisco.com with ESMTP; 04 Nov 2015 00:48:45 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tA40miOe032639 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 00:48:44 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 18:48:44 -0600 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.000; Tue, 3 Nov 2015 18:48:44 -0600 From: "Reshad Rahman (rrahman)" To: Alexander Vainshtein , "Carlos Pignataro (cpignata)" Subject: Re: Multiple BFD sessions between the same pair of end-points Thread-Topic: Multiple BFD sessions between the same pair of end-points Thread-Index: AdEV3sMqUCCSGTiqTr+ZCWzJplyfOAAGR8BgAB2IA4D//4/OAIAAiXAA///i1oCAAAZcgIABUheA Date: Wed, 4 Nov 2015 00:48:44 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> <730CA9F1-B952-4E2F-A61A-B4276BDE5EF4@gmail.com> <087FBA90-F5EB-4691-A5FD-96F784569F6C@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.16.16] Content-Type: multipart/alternative; boundary="_000_D25F5ADB1018E6rrahmanciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 00:48:49 -0000 --_000_D25F5ADB1018E6rrahmanciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, Thanks Alex and Carlos. Since RFC5883 doesn=92t preclude having multiple BF= D sessions for MH, I think that the operational model for BFD IP MH should = allow for multiple sessions between 2 endpoints (same src/dst/vrf). To supp= ort this, we could e.g. add local discriminator to the key. Note that I am not pushing for another OOB mechanism. Regards, Reshad. From: Alexander Vainshtein > Date: Tuesday, November 3, 2015 at 9:38 AM To: "Carlos Pignataro (cpignata)" >, Reshad > Cc: "rtg-bfd@ietf.org" > Subject: RE: Multiple BFD sessions between the same pair of end-points Hi all, I concur with Carlos, only wanted to add that in the case of BFD in MPLS LS= P ability for in-band initialization does not exist (e.g. in the case of PH= P, see Section 5 in RFC 5884), and so an OOB initialization procedure was u= navoidable. I=92d say we need a very strong use case for multiple BFD sessions between = the same pair of endpoints to justify introduction of yet another OOB initi= alization procedure. My 2, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Carlos Pignata= ro (cpignata) Sent: Tuesday, November 03, 2015 3:16 PM To: Reshad Rahman (rrahman) Cc: rtg-bfd@ietf.org Subject: Re: Multiple BFD sessions between the same pair of end-points Hi Reshad, It really depends on what is considered a =93path=94 over which BFD detects= faults, and how the initial demux can be done vs. bootstrapped out-of-band= . RFC 5881 has the text quoted by Greg, because in that case single-hop initi= alization procedures can be done (by binding the interface to BFD context) = and not require out-of-band discriminator bootstrapping. However, on a single interface between two forwarding endpoints, there coul= d be multiple sessions in a generic application. The simplest example is wh= at is described in the second paragraph of https://tools.ietf.org/html/rfc5= 882#section-6. In that case, a path is a specific diffserv code point over = IPv4 between two endpoints, and that is the context used for initialization= using single-hop procedures. In RFC5885 we chose to allow only one, to use= single-hop initialization for example within a tunnel (PW) context. For the multi-hop case, there could also be multiple sessions between endpo= ints. If there is only one session, then the initialization can be done usi= ng single-hop procedures binding source/dst addresses. However, is there ar= e multiple sessions, as e.g., if there is some ECMP-awareness, then some di= fferent and additional mechanism (e.g., out-of-band bootstrapping) is neede= d. This is described in the second paragraph of https://tools.ietf.org/html= /rfc5883#section-3. In fact, these two options are covered in S4.1 (limit t= o one session and use src/dst) and S4.2 (allow multiple sessions and use an= OOB bootstrapping). As far as the YANG models, I=92d think that single session for both single-= and multi-hop covers vast majority of real cases, being pragmatic. If some= one wants to have for example multiple sessions between a pair of endpoint = addresses in multi-hop, then an OOB mechanism is needed, and I do not belie= ve there is a spec=92ed one other than for MPLS. Thanks, =97 Carlos. On Nov 3, 2015, at 4:00 PM, Reshad Rahman (rrahman) > wrote: Hi Sam, Typo in my email indeed. What I meant is that there could be vendor specifi= c extensions if needed. Also looks like there was confusion in the design team (seemingly caused by= my misinterpretation of what was said), there is no known implementation w= hich supports multiple BFD single-hop sessions for the same pair of endpoin= ts (right Santosh?). For MH it=92s a different story because of multiple-pa= ths. The DT will get together to clarify and apologies for the confusion. Regards, Reshad. From: Sam Aldrin > Date: Tuesday, November 3, 2015 at 2:48 AM To: Reshad > Cc: Santosh P K >, Greg= ory Mirsky = >, "rtg-bfd@ietf.org" > Subject: Re: Multiple BFD sessions between the same pair of end-points Reshad, On Nov 2, 2015, at 9:29 PM, Reshad Rahman (rrahman) > wrote: Hi Santosh, Even for single-hop we had discussions about implementations which support = the option of having multiple BFD single-hop sessions on 1 interface betwee= n 2 endpoints. That was an argument for having the BFD config in routing a= pplications. This is what was discussed today in the WG. And I think Greg= =92s point is that we don=92t have to support this in the base model, but i= mplementations are have vendor specific model which supports this behavior. Are there already vendor specific models/implementations in the single hop = case? OR did you mean, there could be vendor specific extensions? -sam Regards, Reshad. From: Rtg-bfd > o= n behalf of Santosh P K > Date: Tuesday, November 3, 2015 at 1:25 AM To: Gregory Mirsky >, "rtg-bfd@ietf.org" > Subject: RE: Multiple BFD sessions between the same pair of end-points This is form RFC 5881 section 3. In this application, there will be only a single BFD session between two systems over a given interface (logical or physical) for a particular protocol. The BFD session must be bound to this interface. Which says for singlehop you will have only single BFD session for an inter= face. The case where we are struggling in Yang is for multihop BFD session= . Thanks Santosh P K From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Tuesday, November 03, 2015 7:57 AM To: rtg-bfd@ietf.org Subject: Multiple BFD sessions between the same pair of end-points Dear All, I think that this paragraph from Section 2 of RFC 5881 prohibits multiple s= ingle-hop BFD sessions between the same pair of end points: Each BFD session between a pair of systems MUST traverse a separate network-layer path in both directions. This is necessary for demultiplexing to work properly, and also because (by definition) multiple sessions would otherwise be protecting the same path. Regards, Greg --_000_D25F5ADB1018E6rrahmanciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <202A7696E92BF248B519C69DD678D5B9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
<Speaking as individual contributor>

Hi all,

Thanks Alex and Carlos. Since RFC5883 doesn=92t preclude having multip= le BFD sessions for MH, I think that the operational model for BFD IP MH sh= ould allow for multiple sessions between 2 endpoints (same src/dst/vrf). To= support this, we could e.g. add local discriminator to the key. 

Note that I am not pushing for another OOB mechanism. 

Regards,
Reshad.

From: Alexander Vainshtein <Alexander.Vainshtein@ecitel= e.com>
Date: Tuesday, November 3, 2015 at = 9:38 AM
To: "Carlos Pignataro (cpignat= a)" <cpignata@cisco.com&g= t;, Reshad <rrahman@cisco.com&g= t;
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: Multiple BFD sessions = between the same pair of end-points

Hi all,

I concur with Carlos, only wanted t= o add that in the case of BFD in MPLS LSP ability for in-band initializatio= n does not exist (e.g. in the case of PHP, see Section 5 in RFC 5884), and so an OOB initialization procedure wa= s unavoidable.

 

I=92d say we need a very strong use= case for multiple BFD sessions between the same pair of endpoints to justi= fy introduction of yet another OOB initialization procedure.

 

My 2,

Sasha

 

Office: +972-39266302

Cell:     = +972-549266302

Email:   Alexander.Vainshtein@ec= itele.com

 

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpignata)
Sent: Tuesday, November 03, 2015 3:16 PM
To: Reshad Rahman (rrahman)
Cc: rtg-bfd@ietf.org
Subject: Re: Multiple BFD sessions between the same pair of end-poin= ts

 

Hi Reshad,

 

It really depends on what is considered a =93path=94= over which BFD detects faults, and how the initial demux can be done vs. b= ootstrapped out-of-band.

 

RFC 5881 has the text quoted by Greg, because in tha= t case single-hop initialization procedures can be done (by binding the int= erface to BFD context) and not require out-of-band discriminator bootstrapp= ing.

 

However, on a single interface between two forwardin= g endpoints, there could be multiple sessions in a generic application. The= simplest example is what is described in the second paragraph of https://tools.ietf.or= g/html/rfc5882#section-6. In that case, a path is a specific diffserv code point over IPv4 between t= wo endpoints, and that is the context used for initialization using single-= hop procedures. In RFC5885 we chose to allow only one, to use single-hop in= itialization for example within a tunnel (PW) context.

 

For the multi-hop case, there could also be multiple= sessions between endpoints. If there is only one session, then the initial= ization can be done using single-hop procedures binding source/dst addresse= s. However, is there are multiple sessions, as e.g., if there is some ECMP-awareness, then some different an= d additional mechanism (e.g., out-of-band bootstrapping) is needed. This is= described in the second paragraph of https://tools.ietf.org/html/rfc5883#section-3= . In fact, these two options are covered in S4.1 (limit to one session and u= se src/dst) and S4.2 (allow multiple sessions and use an OOB bootstrapping)= .

 

As far as the YANG models, I=92d think that single s= ession for both single- and multi-hop covers vast majority of real cases, b= eing pragmatic. If someone wants to have for example multiple sessions betw= een a pair of endpoint addresses in multi-hop, then an OOB mechanism is needed, and I do not believe there is = a spec=92ed one other than for MPLS.

 

Thanks,

 

=97 Carlos.

 

On Nov 3, 2015, at 4:00 PM, Reshad Rahman (rrahman) = <rrahman@cisco.com> wrote:

 

Hi Sam,

 

Typo in my email indeed. What I meant is that there could = be vendor specific extensions if needed.

 

Also looks like there was confusion in the design team (se= emingly caused by my misinterpretation of what was said), there is no known= implementation which supports multiple BFD single-hop sessions for the same pair of endpoints (right Santosh?). F= or MH it=92s a different story because of multiple-paths. <= /span>

 

The DT will get together to clarify and apologies for the = confusion.

 

Regards,

Reshad.

 

From: Sam Aldrin <aldrin.ietf@gmai= l.com>
Date: Tuesday, November 3, 2015 at 2:48 AM
To: Reshad <rrahman@cisco.co= m>
Cc: Santosh P K <santosh= pk@juniper.net>, Gregory Mirsky <gregory.mirsky@ericsson.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: Multiple BFD sessions between the same pair of end-poin= ts

 

Reshad,

 

On Nov 2, 2015, at 9:29 PM, Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:

 

Hi Santosh,

 

Even for single-hop we had discussions about implementatio= ns which support the option of having multiple BFD single-hop sessions on 1= interface between 2  endpoints. That was an argument for having the BFD config in routing applications. This is= what was discussed today in the WG. And I think Greg=92s point is that we = don=92t have to support this in the base model, but implementations are hav= e vendor specific model which supports this behavior.

Are there already vendor specific models/implementations i= n the single hop case? OR did you mean, there could be vendor specific exte= nsions?

 

-sam

 

Regards,

Reshad.

 

 

From: <= /span>rtg-bfd-bounces@ietf.org> on behalf of Santosh P K <santoshpk@juniper.net>
Date: Tuesday, Nov= ember 3, 2015 at 1:25 AM
To: Gregory Mirsky= <gregory.mirsky@ericsson.com>, "rtg-bfd@ietf.org&q= uot; <rtg-b= fd@ietf.org>
Subject: RE: Multi= ple BFD sessions between the same pair of end-points

 

This is form RFC 5881 section 3.

 

In this application, there will= be only a single BFD session between

   two systems over a= given interface (logical or physical) for a

   particular protoco= l.  The BFD session must be bound to this

   interface.<= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif;">

 

Which says for singlehop you will h= ave only single BFD session for an interface.  The case where we are s= truggling in Yang is for multihop BFD session.

 

Thanks

Santosh P K 

 

 

 

 

 --_000_D25F5ADB1018E6rrahmanciscocom_-- From nobody Tue Nov 3 17:09:37 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3419A1A86F0 for ; Tue, 3 Nov 2015 16:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QySXnj6gcUSW for ; Tue, 3 Nov 2015 16:51:45 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B383B1A8035 for ; Tue, 3 Nov 2015 16:51:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51133; q=dns/txt; s=iport; t=1446598305; x=1447807905; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xjkSNzeA1rwA5wtw/zP0P1ZOKlcDH826KniOFO6B2pM=; b=TYokwdgexGBb/IWj11IcQ2rWbKqmVjYxjkpqlU/5TWrewCJ2WE1P4QrJ EiphO9x3mrOkkwuUk6MPuzL6wi2Adu4P0TaA2dy4YJTc9PCzKUMu/TAW7 WdR56+NVo5f5+fxICgH7je1RSUoR9Q5TohiR8pzSQOgcbg9MknSVz0wnw g=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C7AgDVVTlW/5pdJa1egm5NU2APBr0+DoFdIYVyAoE8OBQBAQEBAQEBgQqENQEBAQMBeQUJAgIBCBEDAQEBASABBgcWCxEUCQgCBA4FDogLAwoIDb04DYQuAQEBAQEBAQEBAQEBAQEBAQEBAQEBDwUEBIZRghCCboJTgVcLBgE/DQmDE4EUBZJmg2ABglGBYWqGEYF0lGyHUQEfAUOCER2BVnKDawgXI4EHAQEB X-IronPort-AV: E=Sophos;i="5.20,240,1444694400"; d="asc'?scan'208,217";a="43689147" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 04 Nov 2015 00:51:43 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tA40pgvX013711 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 00:51:43 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 19:51:41 -0500 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.000; Tue, 3 Nov 2015 19:51:41 -0500 From: "Carlos Pignataro (cpignata)" To: "Reshad Rahman (rrahman)" Subject: Re: Multiple BFD sessions between the same pair of end-points Thread-Topic: Multiple BFD sessions between the same pair of end-points Thread-Index: AdEV3sMqUCCSGTiqTr+ZCWzJplyfOAAGR8BgAB2IA4D//38LAIAAA1eAgABo7ICAAE+kYIAAcfgAgAAAyYA= Date: Wed, 4 Nov 2015 00:51:41 +0000 Message-ID: <4EC90987-21B2-481D-9601-79FDFD487208@cisco.com> References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> <730CA9F1-B952-4E2F-A61A-B4276BDE5EF4@gmail.com> <087FBA90-F5EB-4691-A5FD-96F784569F6C@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.230.181] Content-Type: multipart/signed; boundary="Apple-Mail=_F3608B1D-FDC6-4710-846F-B72699F086AD"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 03 Nov 2015 17:09:35 -0800 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 00:51:51 -0000 --Apple-Mail=_F3608B1D-FDC6-4710-846F-B72699F086AD Content-Type: multipart/alternative; boundary="Apple-Mail=_C9169628-66A5-46DA-A5DF-02109EC8D54B" --Apple-Mail=_C9169628-66A5-46DA-A5DF-02109EC8D54B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 That makes sense to me, Reshad, Thanks, =97 Carlos. > On Nov 4, 2015, at 9:48 AM, Reshad Rahman (rrahman) = wrote: >=20 > >=20 > Hi all, >=20 > Thanks Alex and Carlos. Since RFC5883 doesn=92t preclude having = multiple BFD sessions for MH, I think that the operational model for BFD = IP MH should allow for multiple sessions between 2 endpoints (same = src/dst/vrf). To support this, we could e.g. add local discriminator to = the key. >=20 > Note that I am not pushing for another OOB mechanism. >=20 > Regards, > Reshad. >=20 > From: Alexander Vainshtein > > Date: Tuesday, November 3, 2015 at 9:38 AM > To: "Carlos Pignataro (cpignata)" >, Reshad > > Cc: "rtg-bfd@ietf.org " > > Subject: RE: Multiple BFD sessions between the same pair of end-points >=20 > Hi all, > I concur with Carlos, only wanted to add that in the case of BFD in = MPLS LSP ability for in-band initialization does not exist (e.g. in the = case of PHP, see Section 5 in RFC 5884), and so an OOB initialization = procedure was unavoidable. >=20 > I=92d say we need a very strong use case for multiple BFD sessions = between the same pair of endpoints to justify introduction of yet = another OOB initialization procedure. >=20 > My 2, > Sasha >=20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com = >=20 > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org = ] On Behalf Of Carlos Pignataro = (cpignata) > Sent: Tuesday, November 03, 2015 3:16 PM > To: Reshad Rahman (rrahman) > Cc: rtg-bfd@ietf.org > Subject: Re: Multiple BFD sessions between the same pair of end-points >=20 > Hi Reshad, >=20 > It really depends on what is considered a =93path=94 over which BFD = detects faults, and how the initial demux can be done vs. bootstrapped = out-of-band. >=20 > RFC 5881 has the text quoted by Greg, because in that case single-hop = initialization procedures can be done (by binding the interface to BFD = context) and not require out-of-band discriminator bootstrapping. >=20 > However, on a single interface between two forwarding endpoints, there = could be multiple sessions in a generic application. The simplest = example is what is described in the second paragraph of = https://tools.ietf.org/html/rfc5882#section-6 = . In that case, a path is = a specific diffserv code point over IPv4 between two endpoints, and that = is the context used for initialization using single-hop procedures. In = RFC5885 we chose to allow only one, to use single-hop initialization for = example within a tunnel (PW) context. >=20 > For the multi-hop case, there could also be multiple sessions between = endpoints. If there is only one session, then the initialization can be = done using single-hop procedures binding source/dst addresses. However, = is there are multiple sessions, as e.g., if there is some = ECMP-awareness, then some different and additional mechanism (e.g., = out-of-band bootstrapping) is needed. This is described in the second = paragraph of https://tools.ietf.org/html/rfc5883#section-3 = . In fact, these two = options are covered in S4.1 (limit to one session and use src/dst) and = S4.2 (allow multiple sessions and use an OOB bootstrapping). >=20 > As far as the YANG models, I=92d think that single session for both = single- and multi-hop covers vast majority of real cases, being = pragmatic. If someone wants to have for example multiple sessions = between a pair of endpoint addresses in multi-hop, then an OOB mechanism = is needed, and I do not believe there is a spec=92ed one other than for = MPLS. >=20 > Thanks, >=20 > =97 Carlos. >=20 >> On Nov 3, 2015, at 4:00 PM, Reshad Rahman (rrahman) = > wrote: >>=20 >> Hi Sam, >>=20 >> Typo in my email indeed. What I meant is that there could be vendor = specific extensions if needed. >>=20 >> Also looks like there was confusion in the design team (seemingly = caused by my misinterpretation of what was said), there is no known = implementation which supports multiple BFD single-hop sessions for the = same pair of endpoints (right Santosh?). For MH it=92s a different story = because of multiple-paths. >>=20 >> The DT will get together to clarify and apologies for the confusion. >>=20 >> Regards, >> Reshad. >>=20 >> From: Sam Aldrin > >> Date: Tuesday, November 3, 2015 at 2:48 AM >> To: Reshad > >> Cc: Santosh P K >, Gregory Mirsky = >, = "rtg-bfd@ietf.org " > >> Subject: Re: Multiple BFD sessions between the same pair of = end-points >>=20 >> Reshad, >>=20 >>> On Nov 2, 2015, at 9:29 PM, Reshad Rahman (rrahman) = > wrote: >>>=20 >>> Hi Santosh, >>>=20 >>> Even for single-hop we had discussions about implementations which = support the option of having multiple BFD single-hop sessions on 1 = interface between 2 endpoints. That was an argument for having the BFD = config in routing applications. This is what was discussed today in the = WG. And I think Greg=92s point is that we don=92t have to support this = in the base model, but implementations are have vendor specific model = which supports this behavior. >> Are there already vendor specific models/implementations in the = single hop case? OR did you mean, there could be vendor specific = extensions? >>=20 >> -sam >>=20 >>=20 >> Regards, >> Reshad. >>=20 >>=20 >> From: Rtg-bfd > on behalf of Santosh P K = > >> Date: Tuesday, November 3, 2015 at 1:25 AM >> To: Gregory Mirsky >, "rtg-bfd@ietf.org = " > >> Subject: RE: Multiple BFD sessions between the same pair of = end-points >>=20 >> This is form RFC 5881 section 3. >>=20 >> In this application, there will be only a single BFD session between >> two systems over a given interface (logical or physical) for a >> particular protocol. The BFD session must be bound to this >> interface. >>=20 >> Which says for singlehop you will have only single BFD session for an = interface. The case where we are struggling in Yang is for multihop BFD = session. >>=20 >> Thanks >> Santosh P K >>=20 >>=20 >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org = ] On Behalf Of Gregory Mirsky >> Sent: Tuesday, November 03, 2015 7:57 AM >> To: rtg-bfd@ietf.org >> Subject: Multiple BFD sessions between the same pair of end-points >>=20 >> Dear All, >> I think that this paragraph from Section 2 of RFC 5881 prohibits = multiple single-hop BFD sessions between the same pair of end points: >> Each BFD session between a pair of systems MUST traverse a = separate >> network-layer path in both directions. This is necessary for >> demultiplexing to work properly, and also because (by definition) >> multiple sessions would otherwise be protecting the same path. >>=20 >> Regards, >> Greg --Apple-Mail=_C9169628-66A5-46DA-A5DF-02109EC8D54B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 That makes sense to me, Reshad, Thanks,

=97 Carlos.

On = Nov 4, 2015, at 9:48 AM, Reshad Rahman (rrahman) <rrahman@cisco.com> = wrote:

<Speaking as individual contributor>

Hi = all,

Thanks Alex and Carlos. Since RFC5883 doesn=92t preclude = having multiple BFD sessions for MH, I think that the operational model = for BFD IP MH should allow for multiple sessions between 2 endpoints = (same src/dst/vrf). To support this, we could e.g. add local = discriminator to the key. 

Note that I am not pushing for another OOB = mechanism. 

Regards,
Reshad.

From: Alexander Vainshtein = <Alexander.Vainshtein@ecitele.com>
Date: Tuesday, November 3, = 2015 at 9:38 AM
To: "Carlos Pignataro = (cpignata)" <cpignata@cisco.com>, Reshad <rrahman@cisco.com>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: Multiple BFD = sessions between the same pair of end-points

Hi all,
I concur with Carlos, only wanted to add = that in the case of BFD in MPLS LSP ability for in-band initialization = does not exist (e.g. in the case of PHP, see Section 5 in RFC 5884), and = so an OOB initialization procedure was unavoidable.
 
I=92d say we need a = very strong use case for multiple BFD sessions between the same pair of = endpoints to justify introduction of yet another OOB initialization = procedure.
 
My 2,
Sasha
 
Office: = +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com
 
From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Carlos = Pignataro (cpignata)
Sent: Tuesday, November 03, 2015 = 3:16 PM
To: Reshad Rahman (rrahman)
Cc: rtg-bfd@ietf.org
Subject: Re: Multiple BFD sessions = between the same pair of end-points
 
Hi Reshad,
 
It really depends on what is considered a =93path=94 = over which BFD detects faults, and how the initial demux can be done vs. = bootstrapped out-of-band.
 
RFC 5881 has the text quoted by Greg, because in that = case single-hop initialization procedures can be done (by binding the = interface to BFD context) and not require out-of-band discriminator = bootstrapping.
 
However, on a single interface between two forwarding = endpoints, there could be multiple sessions in a generic application. = The simplest example is what is described in the second paragraph = of https://tools.ietf.org/html/rfc5882#section-6. In that = case, a path is a specific diffserv code point over IPv4 between two = endpoints, and that is the context used for initialization using = single-hop procedures. In RFC5885 we chose to allow only one, to use = single-hop initialization for example within a tunnel (PW) context.
 
For the multi-hop case, there could also = be multiple sessions between endpoints. If there is only one session, = then the initialization can be done using single-hop procedures binding = source/dst addresses. However, is there are multiple sessions, as e.g., = if there is some ECMP-awareness, then some different and additional = mechanism (e.g., out-of-band bootstrapping) is needed. This is described = in the second paragraph of https://tools.ietf.org/html/rfc5883#section-3. In fact, = these two options are covered in S4.1 (limit to one session and use = src/dst) and S4.2 (allow multiple sessions and use an OOB = bootstrapping).
 
As far as the YANG models, I=92d think that single = session for both single- and multi-hop covers vast majority of real = cases, being pragmatic. If someone wants to have for example multiple = sessions between a pair of endpoint addresses in multi-hop, then an OOB = mechanism is needed, and I do not believe there is a spec=92ed one other = than for MPLS.
 
Thanks,
 
=97 Carlos.
 
On = Nov 3, 2015, at 4:00 PM, Reshad Rahman (rrahman) <rrahman@cisco.com> = wrote:
 
Hi Sam,
 
Typo in my email indeed. = What I meant is that there could be vendor specific extensions if = needed.
 
Also looks like there was = confusion in the design team (seemingly caused by my misinterpretation = of what was said), there is no known implementation which supports = multiple BFD single-hop sessions for the same pair of endpoints (right = Santosh?). For MH it=92s a different story because of = multiple-paths. 
 
The DT will get together to clarify and apologies for the = confusion.
 
Regards,
Reshad.
 
From: Sam Aldrin <aldrin.ietf@gmail.com>
Date: Tuesday, November 3, = 2015 at 2:48 AM
To: Reshad <rrahman@cisco.com>
Cc: Santosh P K <santoshpk@juniper.net>, = Gregory Mirsky <gregory.mirsky@ericsson.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: Multiple BFD = sessions between the same pair of end-points
 
Reshad,
 
On Nov 2, 2015, at 9:29 PM, Reshad Rahman (rrahman) <rrahman@cisco.com> = wrote:
 
Hi Santosh,
 
Even for single-hop we had = discussions about implementations which support the option of having = multiple BFD single-hop sessions on 1 interface between 2 =  endpoints. That was an argument for having the BFD config in = routing applications. This is what was discussed today in the WG. And I = think Greg=92s point is that we don=92t have to support this in the base = model, but implementations are have vendor specific model which supports = this behavior.
Are there already vendor = specific models/implementations in the single hop case? OR did you mean, = there could be vendor specific extensions?
 
-sam

 
Regards,
Reshad.
 
 
From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Santosh = P K <santoshpk@juniper.net>
Date: Tuesday, November 3, = 2015 at 1:25 AM
To: Gregory Mirsky <gregory.mirsky@ericsson.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: Multiple BFD = sessions between the same pair of end-points
 
This is form RFC 5881 section = 3.
 
In this application, there = will be only a single BFD session between
   two systems = over a given interface (logical or physical) for a
   particular protocol.  The BFD session must = be bound to this
   = interface.
 
Which says for = singlehop you will have only single BFD session for an interface. =  The case where we are struggling in Yang is for multihop BFD = session.
 
Thanks
Santosh P K 
 
 
From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Gregory = Mirsky
Sent: Tuesday, November 03, 2015 = 7:57 AM
To: rtg-bfd@ietf.org
Subject: Multiple BFD sessions = between the same pair of end-points
 
Dear All,
I think that this paragraph from Section 2 of = RFC 5881 prohibits multiple single-hop BFD sessions between the same = pair of end points:
   Each BFD session between a pair of systems MUST = traverse a separate
   network-layer path in both directions.  = This is necessary for
   demultiplexing to work properly, and also = because (by definition)
   multiple sessions would otherwise be protecting = the same path.
 
          &nb= sp;     Regards,
          &nb= sp;            = ;         = Greg

= --Apple-Mail=_C9169628-66A5-46DA-A5DF-02109EC8D54B-- --Apple-Mail=_F3608B1D-FDC6-4710-846F-B72699F086AD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWOVaVAAoJEIXgpQGOZny9aQ4P/iZN5UivMAf7FLVNf5LKL4mK L8fVIX/Q9mEtLFijUcaznGhpl3R5TuOfBSAGIuYLy6SjnvQCmTPr/bHZydXIfpOZ In/vpB+ytQqpUB+mJ1UUpyLQER/D3pimFJwHO9rW0vF8hzNBBtoOdqr2aOrWcpcR 74GbEnKU+dQGOBrwRUQmEk2rm1cYX1TDEdGRzkqtcL/ey3Nz30oLSQs3USQQ+zhC v3WiuRgRS0ysyNvkJniSWB4Y7X3Xrt8OEqMP2Ct3LSCDNI3pm3nrK7TzQtJ1j70O oTlRw4dRUvZ/r7QvyfCflJGOPdsRE5Qh7lTQp+4xvw+InIUsv4TRYU/zm1iVrhHp qEBNFQPHVQO3EtsfBmHqk3UiCMbmkInpvVQUBus+Yn+1j271yadS0NLjzDxgyVQo YnQTshs/TTvrpnsYHoFBHyiljW42Z+1laKEs67iG/KDzYYan5o+EFKn97yvrJALS chc5wHqW0Zut0lZU5w73yyd3pdfHEojjoRPyIuKpIVjX3C2GydXqSCAknELhSJIB kVgR4SoM4UP2EEvDosRIX8cORBFA7UPlONQYebFH90Z5eY6JzedURjWVq08qQm6o gCXNrAYf70VUrXVjHTAQJsatV50UsyOECvL3+ZnKlunowPywJObbMPQWF6VAo+Qx tQoVRzNmdxUm9h65A6bd =RjpW -----END PGP SIGNATURE----- --Apple-Mail=_F3608B1D-FDC6-4710-846F-B72699F086AD-- From nobody Tue Nov 3 17:09:55 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695E41A013B; Sun, 25 Oct 2015 23:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFSRDzluu_rE; Sun, 25 Oct 2015 23:27:41 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FC641A0178; Sun, 25 Oct 2015 23:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1586; q=dns/txt; s=iport; t=1445840860; x=1447050460; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dk+Ks34bq1XJyawkNtZKY7x7bYfMfJxA36J2zFnfM6o=; b=k3Xxgx0SLWd/ukgOW+67NO52EFVY2vixzQWv0JFda9fwuE7gWM4HsWsj YVU2cle6MlLZJLQuJMDVPJM43QvLJYQqA4G6Ck3oCcYV3+NmZYz7FkYZV fHCuCZRlqfhnEPhteRSyoVtLKECe51l55DLdmPOrCo0ZxGU9Cxa2tjJEY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A8AgCfxi1W/4ENJK1dgzZUbwa+NwENgVohhXwCgSA4FAEBAQEBAQGBCoQzAQEEOj0CEAIBCDYQMhsBBgMCBAENBYgwDcN6AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZ3hH6FDQeELgWNGIkeAYUbiAaBWUiDd5YWAR8BAUKEA3IBhhGBBgEBAQ X-IronPort-AV: E=Sophos;i="5.20,200,1444694400"; d="scan'208";a="44453517" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP; 26 Oct 2015 06:27:39 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t9Q6RdHZ028547 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Oct 2015 06:27:39 GMT Received: from xch-rcd-003.cisco.com (173.37.102.13) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 26 Oct 2015 01:27:16 -0500 Received: from xch-rcd-003.cisco.com ([173.37.102.13]) by XCH-RCD-003.cisco.com ([173.37.102.13]) with mapi id 15.00.1104.000; Mon, 26 Oct 2015 01:27:16 -0500 From: "Nitish Gupta (nitisgup)" To: "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: FW: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUA Date: Mon, 26 Oct 2015 06:27:16 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> In-Reply-To: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.142.109.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <54322BED162EDD45BD25CE1D3053486E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 03 Nov 2015 17:09:54 -0800 Cc: "jhaas@juniper.net" , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 06:27:42 -0000 Hi, We have submitted a new version of the draft. As discussed in IETF 93 at prague. We have merged the following drafts: http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 We have also taken care of all the comments that were discussed in the RTGWG meeting. We welcome any comments and suggestions on the draft. Thanks, Nitish On 13/10/15 9:09 pm, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-nitish-vrrp-bfd-02.txt >has been successfully submitted by Nitish Gupta and posted to the >IETF repository. > >Name: draft-nitish-vrrp-bfd >Revision: 02 >Title: Fast failure detection in VRRP with BFD >Document date: 2015-10-13 >Group: Individual Submission >Pages: 10 >URL: =20 >https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-= 02 > >Abstract: > This document describes how Bidirectional Forwarding Detection (BFD) > can be used to support sub-second detection of a Master Router > failure in the Virtual Router Redundancy Protocol (VRRP). > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From nobody Tue Nov 3 17:09:56 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581E81ACD96; Mon, 2 Nov 2015 18:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Awkl7JwMcQfm; Mon, 2 Nov 2015 18:18:12 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 59DEF1ACD92; Mon, 2 Nov 2015 18:18:11 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 7079F8CCE5E8C; Tue, 3 Nov 2015 02:18:08 +0000 (GMT) Received: from cliff.eng.ascend.com (cliff.eng.ascend.com [192.207.23.55]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id tA32I6kd020417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Nov 2015 02:18:08 GMT Received: from igoyret-c1.alcatel-lucent.com (vpn-2-30.vpn.alcatel-lucent.com [135.224.2.30]) by cliff.eng.ascend.com (8.13.1/8.13.1) with ESMTP id tA32I43t019265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2015 18:18:05 -0800 Message-Id: <201511030218.tA32I43t019265@cliff.eng.ascend.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 02 Nov 2015 18:17:40 -0800 To: l2tpext@ietf.org From: Ignacio Goyret Subject: Re: [L2tpext] WGLC for draft-ietf-l2tpext-sbfd-discriminator In-Reply-To: <201510192003.t9JK3sgH010715@cliff.eng.ascend.com> References: <201510191639.t9JGdXLG004819@cliff.eng.ascend.com> <201510192003.t9JK3sgH010715@cliff.eng.ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Archived-At: X-Mailman-Approved-At: Tue, 03 Nov 2015 17:09:54 -0800 Cc: rtg-bfd@ietf.org, pals@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:18:14 -0000 Given the very low quantity of responses (1, not counting authors) and since this is a meeting week, I'll extend the WG Last Call another week until Monday Nov/9/2015. Hopefully, by then, more people may have found the time to read this very short draft and answer yeah/nay. Thanks all, -Ignacio L2tpext chair >At 09:39 10/19/2015, Ignacio Goyret wrote: >>Hi group, >> >>This email starts a two-week Working-Group Last-Call (WGLC) for >>draft-ietf-l2tpext-sbfd-discriminator-00 >>http://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/ >> >>Please send comments to the list and state whether or not you support >>progressing this document (in the later case, please also state the >>reasons). Silence is not indication of support. >> >>This poll runs until ** November 3rd, 2015 **. >> >>We are also polling for knowledge of any IPR that applies to this >>draft, to ensure that IPR has been disclosed in compliance with >>IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >> >>* If you are listed as a document author or contributor *, please >>respond only if you are aware of any changes to IPR from your >>response during the poll for adoption, at http://www.ietf.org/mail-archive/web/l2tpext/current/msg01389.html >> >>If you are *not* listed as an author or contributor, then please >>explicitly respond only if you are aware of any IPR that has not >>yet been disclosed in conformance with IETF rules. >> >>Thank you, >> >>Carlos and Ignacio >>L2tpext co-chairs >> >>_______________________________________________ >>L2tpext mailing list >>L2tpext@ietf.org >>https://www.ietf.org/mailman/listinfo/l2tpext > >_______________________________________________ >L2tpext mailing list >L2tpext@ietf.org >https://www.ietf.org/mailman/listinfo/l2tpext From nobody Wed Nov 4 01:20:38 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A264A1B2BBB for ; Wed, 4 Nov 2015 01:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zw-MYDlpiZE for ; Wed, 4 Nov 2015 01:20:22 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 733CD1B2BB5 for ; Wed, 4 Nov 2015 01:20:21 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 45DF52AA0F; Wed, 4 Nov 2015 09:20:17 +0000 (GMT) Date: Wed, 4 Nov 2015 01:20:17 -0800 From: Marc Binderberger To: Reshad Rahman (rrahman) Message-ID: <20151104012017393317.5f16d0ce@sniff.de> In-Reply-To: References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> <730CA9F1-B952-4E2F-A61A-B4276BDE5EF4@gmail.com> <087FBA90-F5EB-4691-A5FD-96F784569F6C@cisco.com> Subject: Re: Multiple BFD sessions between the same pair of end-points MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.16 Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 09:20:28 -0000 Hello Reshad and other BFD experts, I'm not too deep into YANG et al., so I apologize upfront for this email :-) . I understand YANG is about configuration but are we trying to find a common way to reflect the various (CLI-)configurations that are out in the market? Isn't this, well, a bit restricting? Should a generic "configuration" of a BFD session not contain all the variables of the particular layers? E.g. for the BFD packet itself not just timer and multiplier but "my" and "your" discriminator too? For the IP layer src/dst IP and egress interface? The various RFCs 5881, 5883, ... would be special cases that could be incorporated. E.g. a "your" discriminator of zero (or lack of this parameter) for a single-hop IP-based BFD session would mean to follow RFC5881 and it's bootstrapping mechanism. Maybe this is too generic to start the YANG endeavor. But in these days of "programmability" I would expect more than an API that replaces my CLI 1:1. Regards, Marc On Wed, 4 Nov 2015 00:48:44 +0000, Reshad Rahman (rrahman) wrote: > > > Hi all, > > Thanks Alex and Carlos. Since RFC5883 doesn$B!G(Bt preclude having multiple BFD > sessions for MH, I think that the operational model for BFD IP MH should > allow for multiple sessions between 2 endpoints (same src/dst/vrf). To > support this, we could e.g. add local discriminator to the key. > > Note that I am not pushing for another OOB mechanism. > > Regards, > Reshad. > > From: Alexander Vainshtein > Date: Tuesday, November 3, 2015 at 9:38 AM > To: "Carlos Pignataro (cpignata)" , Reshad > > Cc: "rtg-bfd@ietf.org" > Subject: RE: Multiple BFD sessions between the same pair of end-points > > Hi all, > I concur with Carlos, only wanted to add that in the case of BFD in MPLS > LSP ability for in-band initialization does not exist (e.g. in the case of > PHP, see Section 5 in RFC 5884), and so an OOB initialization procedure was > unavoidable. > > I$B!G(Bd say we need a very strong use case for multiple BFD sessions between > the same pair of endpoints to justify introduction of yet another OOB > initialization procedure. > > My 2, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Carlos > Pignataro (cpignata) > Sent: Tuesday, November 03, 2015 3:16 PM > To: Reshad Rahman (rrahman) > Cc: rtg-bfd@ietf.org > Subject: Re: Multiple BFD sessions between the same pair of end-points > > Hi Reshad, > > It really depends on what is considered a $B!H(Bpath$B!I(B over which BFD detects > faults, and how the initial demux can be done vs. bootstrapped out-of-band. > > RFC 5881 has the text quoted by Greg, because in that case single-hop > initialization procedures can be done (by binding the interface to BFD > context) and not require out-of-band discriminator bootstrapping. > > However, on a single interface between two forwarding endpoints, there > could be multiple sessions in a generic application. The simplest example > is what is described in the second paragraph of > https://tools.ietf.org/html/rfc5882#section-6. In that case, a path is a > specific diffserv code point over IPv4 between two endpoints, and that is > the context used for initialization using single-hop procedures. In RFC5885 > we chose to allow only one, to use single-hop initialization for example > within a tunnel (PW) context. > > For the multi-hop case, there could also be multiple sessions between > endpoints. If there is only one session, then the initialization can be > done using single-hop procedures binding source/dst addresses. However, is > there are multiple sessions, as e.g., if there is some ECMP-awareness, then > some different and additional mechanism (e.g., out-of-band bootstrapping) > is needed. This is described in the second paragraph of > https://tools.ietf.org/html/rfc5883#section-3. In fact, these two options > are covered in S4.1 (limit to one session and use src/dst) and S4.2 (allow > multiple sessions and use an OOB bootstrapping). > > As far as the YANG models, I$B!G(Bd think that single session for both single- > and multi-hop covers vast majority of real cases, being pragmatic. If > someone wants to have for example multiple sessions between a pair of > endpoint addresses in multi-hop, then an OOB mechanism is needed, and I do > not believe there is a spec$B!G(Bed one other than for MPLS. > > Thanks, > > $B!=(B Carlos. > >> On Nov 3, 2015, at 4:00 PM, Reshad Rahman (rrahman) >> wrote: >> >> Hi Sam, >> >> Typo in my email indeed. What I meant is that there could be vendor >> specific extensions if needed. >> >> Also looks like there was confusion in the design team (seemingly caused >> by my misinterpretation of what was said), there is no known >> implementation which supports multiple BFD single-hop sessions for the >> same pair of endpoints (right Santosh?). For MH it$B!G(Bs a different story >> because of multiple-paths. >> >> The DT will get together to clarify and apologies for the confusion. >> >> Regards, >> Reshad. >> >> From: Sam Aldrin >> Date: Tuesday, November 3, 2015 at 2:48 AM >> To: Reshad >> Cc: Santosh P K , Gregory Mirsky >> , "rtg-bfd@ietf.org" >> Subject: Re: Multiple BFD sessions between the same pair of end-points >> >> Reshad, >> >>> On Nov 2, 2015, at 9:29 PM, Reshad Rahman (rrahman) >>> wrote: >>> >>> Hi Santosh, >>> >>> Even for single-hop we had discussions about implementations which >>> support the option of having multiple BFD single-hop sessions on 1 >>> interface between 2 endpoints. That was an argument for having the BFD >>> config in routing applications. This is what was discussed today in the >>> WG. And I think Greg$B!G(Bs point is that we don$B!G(Bt have to support this in >>> the base model, but implementations are have vendor specific model which >>> supports this behavior. >> Are there already vendor specific models/implementations in the single hop >> case? OR did you mean, there could be vendor specific extensions? >> >> -sam >> >> >> >> Regards, >> Reshad. >> >> >> From: Rtg-bfd on behalf of Santosh P K >> >> Date: Tuesday, November 3, 2015 at 1:25 AM >> To: Gregory Mirsky , "rtg-bfd@ietf.org" >> >> Subject: RE: Multiple BFD sessions between the same pair of end-points >> >> This is form RFC 5881 section 3. >> >> In this application, there will be only a single BFD session between >> two systems over a given interface (logical or physical) for a >> particular protocol. The BFD session must be bound to this >> interface. >> >> Which says for singlehop you will have only single BFD session for an >> interface. The case where we are struggling in Yang is for multihop BFD >> session. >> >> Thanks >> Santosh P K >> >> >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky >> Sent: Tuesday, November 03, 2015 7:57 AM >> To: rtg-bfd@ietf.org >> Subject: Multiple BFD sessions between the same pair of end-points >> >> Dear All, >> I think that this paragraph from Section 2 of RFC 5881 prohibits multiple >> single-hop BFD sessions between the same pair of end points: >> Each BFD session between a pair of systems MUST traverse a separate >> network-layer path in both directions. This is necessary for >> demultiplexing to work properly, and also because (by definition) >> multiple sessions would otherwise be protecting the same path. >> >> Regards, >> Greg >> > > From nobody Wed Nov 4 20:27:20 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525A71B2D86 for ; Wed, 4 Nov 2015 20:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id et7Y4LEjDb0Q for ; Wed, 4 Nov 2015 20:27:16 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6BE51B29B7 for ; Wed, 4 Nov 2015 20:27:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9139; q=dns/txt; s=iport; t=1446697636; x=1447907236; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kYSLikp9ecOxfuYHChNRS5vpalS2Pu+u621D44Mf78I=; b=F/Mh4l1Jcf60LeOczfHwL8sjJGtucnyWotBPxFz5Ez+jmq9QPmW8gTVl nWEw3kvp3pa5KnsNVf2RVIM2TPnc6Rwh86Kohp2qXLKvzIdl/l7UzceNg XhTizYLJQG5SCLsZWNo0e3QXWFTzpMF3WrJBBTDkLMO4gNPf6oRo6GTa2 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D9AQD92TpW/5JdJa1egztTbwa9eQENgV4hhXECgUE4FAEBAQEBAQGBCoQ1AQEBBCEBSQ4OAgIBCBEDAQEBAQEDCxgCAwIWCxEUCQgCBA4FiBkDEg2TQZ0vAYwvDYQ8AQEBAQEBAQEBAQEBAQEBAQEBAQEBFAQEeoVWhH6CU4FXCwYBHYMZgUYFlkgBhRyGEoF0gVqTFYNgg3EBHwEBQoIRHYFWcoNWCBcjgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,246,1444694400"; d="scan'208";a="47782712" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Nov 2015 04:27:15 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tA54RFRE016167 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2015 04:27:15 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 22:27:14 -0600 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.000; Wed, 4 Nov 2015 22:27:14 -0600 From: "Reshad Rahman (rrahman)" To: Marc Binderberger Subject: Re: Multiple BFD sessions between the same pair of end-points Thread-Topic: Multiple BFD sessions between the same pair of end-points Thread-Index: AdEV3sMqUCCSGTiqTr+ZCWzJplyfOAAGR8BgAB2IA4D//4/OAIAAiXAA///i1oCAAAZcgIABUheA///4E4CAAddOgA== Date: Thu, 5 Nov 2015 04:27:14 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> <730CA9F1-B952-4E2F-A61A-B4276BDE5EF4@gmail.com> <087FBA90-F5EB-4691-A5FD-96F784569F6C@cisco.com> <20151104012017393317.5f16d0ce@sniff.de> In-Reply-To: <20151104012017393317.5f16d0ce@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.92.93] Content-Type: text/plain; charset="iso-2022-jp" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:27:19 -0000 Hi Marc, For classical BFD we are looking at matching with what=1B$B!G=1B(Bs current= ly in CLI (config, operational, =1B$B!D=1B(B). When we tackle YANG for S-BFD, that=1B$B!G=1B(Bs when we=1B$B!G=1B(Bll look= at the programmability aspect. Regards, Reshad. On 2015-11-04, 6:20 PM, "Marc Binderberger" wrote: >Hello Reshad and other BFD experts, > >I'm not too deep into YANG et al., so I apologize upfront for this email >:-)=20 >. I understand YANG is about configuration but are we trying to find a >common=20 >way to reflect the various (CLI-)configurations that are out in the >market?=20 >Isn't this, well, a bit restricting? > >Should a generic "configuration" of a BFD session not contain all the >variables of the particular layers? E.g. for the BFD packet itself not >just=20 >timer and multiplier but "my" and "your" discriminator too? For the IP >layer=20 >src/dst IP and egress interface? > >The various RFCs 5881, 5883, ... would be special cases that could be >incorporated. E.g. a "your" discriminator of zero (or lack of this >parameter)=20 >for a single-hop IP-based BFD session would mean to follow RFC5881 and >it's=20 >bootstrapping mechanism. > > >Maybe this is too generic to start the YANG endeavor. But in these days >of=20 >"programmability" I would expect more than an API that replaces my CLI >1:1. > > >Regards, Marc > > > >On Wed, 4 Nov 2015 00:48:44 +0000, Reshad Rahman (rrahman) wrote: >> >>=20 >> Hi all, >>=20 >> Thanks Alex and Carlos. Since RFC5883 doesn=1B$B!G=1B(Bt preclude having= multiple >>BFD=20 >> sessions for MH, I think that the operational model for BFD IP MH >>should=20 >> allow for multiple sessions between 2 endpoints (same src/dst/vrf). To >> support this, we could e.g. add local discriminator to the key. >>=20 >> Note that I am not pushing for another OOB mechanism. >>=20 >> Regards, >> Reshad. >>=20 >> From: Alexander Vainshtein >> Date: Tuesday, November 3, 2015 at 9:38 AM >> To: "Carlos Pignataro (cpignata)" , Reshad >> >> Cc: "rtg-bfd@ietf.org" >> Subject: RE: Multiple BFD sessions between the same pair of end-points >>=20 >> Hi all, >> I concur with Carlos, only wanted to add that in the case of BFD in >>MPLS=20 >> LSP ability for in-band initialization does not exist (e.g. in the case >>of=20 >> PHP, see Section 5 in RFC 5884), and so an OOB initialization procedure >>was=20 >> unavoidable. >> =20 >> I=1B$B!G=1B(Bd say we need a very strong use case for multiple BFD sessi= ons >>between=20 >> the same pair of endpoints to justify introduction of yet another OOB >> initialization procedure. >> =20 >> My 2, >> Sasha >> =20 >> Office: +972-39266302 >> Cell: +972-549266302 >> Email: Alexander.Vainshtein@ecitele.com >> =20 >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Carlos >> Pignataro (cpignata) >> Sent: Tuesday, November 03, 2015 3:16 PM >> To: Reshad Rahman (rrahman) >> Cc: rtg-bfd@ietf.org >> Subject: Re: Multiple BFD sessions between the same pair of end-points >> =20 >> Hi Reshad, >> =20 >> It really depends on what is considered a =1B$B!H=1B(Bpath=1B$B!I=1B(B o= ver which BFD detects >> faults, and how the initial demux can be done vs. bootstrapped >>out-of-band. >> =20 >> RFC 5881 has the text quoted by Greg, because in that case single-hop >> initialization procedures can be done (by binding the interface to BFD >> context) and not require out-of-band discriminator bootstrapping. >> =20 >> However, on a single interface between two forwarding endpoints, there >> could be multiple sessions in a generic application. The simplest >>example=20 >> is what is described in the second paragraph of >> https://tools.ietf.org/html/rfc5882#section-6. In that case, a path is >>a=20 >> specific diffserv code point over IPv4 between two endpoints, and that >>is=20 >> the context used for initialization using single-hop procedures. In >>RFC5885=20 >> we chose to allow only one, to use single-hop initialization for >>example=20 >> within a tunnel (PW) context. >> =20 >> For the multi-hop case, there could also be multiple sessions between >> endpoints. If there is only one session, then the initialization can be >> done using single-hop procedures binding source/dst addresses. However, >>is=20 >> there are multiple sessions, as e.g., if there is some ECMP-awareness, >>then=20 >> some different and additional mechanism (e.g., out-of-band >>bootstrapping)=20 >> is needed. This is described in the second paragraph of >> https://tools.ietf.org/html/rfc5883#section-3. In fact, these two >>options=20 >> are covered in S4.1 (limit to one session and use src/dst) and S4.2 >>(allow=20 >> multiple sessions and use an OOB bootstrapping). >> =20 >> As far as the YANG models, I=1B$B!G=1B(Bd think that single session for = both >>single-=20 >> and multi-hop covers vast majority of real cases, being pragmatic. If >> someone wants to have for example multiple sessions between a pair of >> endpoint addresses in multi-hop, then an OOB mechanism is needed, and I >>do=20 >> not believe there is a spec=1B$B!G=1B(Bed one other than for MPLS. >> =20 >> Thanks, >> =20 >> =1B$B!=3D=1B(B Carlos. >> =20 >>> On Nov 3, 2015, at 4:00 PM, Reshad Rahman (rrahman) >>> >>> wrote: >>> =20 >>> Hi Sam, >>> =20 >>> Typo in my email indeed. What I meant is that there could be vendor >>> specific extensions if needed. >>> =20 >>> Also looks like there was confusion in the design team (seemingly >>>caused=20 >>> by my misinterpretation of what was said), there is no known >>> implementation which supports multiple BFD single-hop sessions for the >>> same pair of endpoints (right Santosh?). For MH it=1B$B!G=1B(Bs a diffe= rent story >>> because of multiple-paths. >>> =20 >>> The DT will get together to clarify and apologies for the confusion. >>> =20 >>> Regards, >>> Reshad. >>> =20 >>> From: Sam Aldrin >>> Date: Tuesday, November 3, 2015 at 2:48 AM >>> To: Reshad >>> Cc: Santosh P K , Gregory Mirsky >>> , "rtg-bfd@ietf.org" >>> Subject: Re: Multiple BFD sessions between the same pair of end-points >>> =20 >>> Reshad,=20 >>> =20 >>>> On Nov 2, 2015, at 9:29 PM, Reshad Rahman (rrahman) >>>> >>>> wrote: >>>> =20 >>>> Hi Santosh, >>>> =20 >>>> Even for single-hop we had discussions about implementations which >>>> support the option of having multiple BFD single-hop sessions on 1 >>>> interface between 2 endpoints. That was an argument for having the >>>>BFD=20 >>>> config in routing applications. This is what was discussed today in >>>>the=20 >>>> WG. And I think Greg=1B$B!G=1B(Bs point is that we don=1B$B!G=1B(Bt ha= ve to support this in >>>> the base model, but implementations are have vendor specific model >>>>which=20 >>>> supports this behavior. >>> Are there already vendor specific models/implementations in the single >>>hop=20 >>> case? OR did you mean, there could be vendor specific extensions? >>> =20 >>> -sam >>>=20 >>>=20 >>> =20 >>> Regards, >>> Reshad. >>> =20 >>> =20 >>> From: Rtg-bfd on behalf of Santosh P K >>> >>> Date: Tuesday, November 3, 2015 at 1:25 AM >>> To: Gregory Mirsky , "rtg-bfd@ietf.org" >>> >>> Subject: RE: Multiple BFD sessions between the same pair of end-points >>> =20 >>> This is form RFC 5881 section 3. >>> =20 >>> In this application, there will be only a single BFD session between >>> two systems over a given interface (logical or physical) for a >>> particular protocol. The BFD session must be bound to this >>> interface. >>> =20 >>> Which says for singlehop you will have only single BFD session for an >>> interface. The case where we are struggling in Yang is for multihop >>>BFD=20 >>> session. >>> =20 >>> Thanks >>> Santosh P K=20 >>> =20 >>> =20 >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory >>>Mirsky >>> Sent: Tuesday, November 03, 2015 7:57 AM >>> To: rtg-bfd@ietf.org >>> Subject: Multiple BFD sessions between the same pair of end-points >>> =20 >>> Dear All, >>> I think that this paragraph from Section 2 of RFC 5881 prohibits >>>multiple=20 >>> single-hop BFD sessions between the same pair of end points: >>> Each BFD session between a pair of systems MUST traverse a separate >>> network-layer path in both directions. This is necessary for >>> demultiplexing to work properly, and also because (by definition) >>> multiple sessions would otherwise be protecting the same path. >>> =20 >>> Regards, >>> Greg >>> =20 >>=20 >> =20 From nobody Thu Nov 5 04:21:49 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE1B1AD160; Thu, 5 Nov 2015 04:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89dulCcOnD9j; Thu, 5 Nov 2015 04:21:43 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1A81AD0AC; Thu, 5 Nov 2015 04:21:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2204; q=dns/txt; s=iport; t=1446726104; x=1447935704; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+8o7FaWGyi5BlQYR3e++1kceK7gBfj9HNOEWCj6LjVw=; b=MpllhECYKIyc0/0ozjYzSN6/K2EFR3bR/axRWPBrvxMmTIjf6LS223vh LDXC5LXA/bCFHS6e9NjY6ur2SGUz1wjyilZzX9PdUy60m3cSDAoEK/yB4 8LGcYBmnQ0pgFwgYHXZLZy25dbS1i+t5OBKGwaemXA4a7caiWOGBXWo32 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANAgCGSTtW/40NJK1egztTbwa9fAENgV4XCoUnSgKBLTgUAQEBAQEBAYEKhDYBAQQBAQE3NAsQAgEIDgoeECcLJQIEAQ0FCYglDcIFAQEBAQEBAQEBAQEBAQEBAQEBAQEBGItShCoQAgFQhCwFlkgBhRyIBoFaSIN3gyWPEoNxAR8BAUKEBHIBhBeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,247,1444694400"; d="scan'208";a="47039605" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP; 05 Nov 2015 12:21:34 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tA5CLYEh028673 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2015 12:21:34 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 Nov 2015 06:21:33 -0600 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.000; Thu, 5 Nov 2015 06:21:33 -0600 From: "Nagendra Kumar Nainar (naikumar)" To: Ignacio Goyret , "l2tpext@ietf.org" Subject: Re: [Pals] [L2tpext] WGLC for draft-ietf-l2tpext-sbfd-discriminator Thread-Topic: [Pals] [L2tpext] WGLC for draft-ietf-l2tpext-sbfd-discriminator Thread-Index: AQHRFd3tDGdGYnNAQEm5OI5QwXflIJ6NbgcA Date: Thu, 5 Nov 2015 12:21:33 +0000 Message-ID: References: <201510191639.t9JGdXLG004819@cliff.eng.ascend.com> <201510192003.t9JK3sgH010715@cliff.eng.ascend.com> <201511030218.tA32I43t019265@cliff.eng.ascend.com> In-Reply-To: <201511030218.tA32I43t019265@cliff.eng.ascend.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.20.13] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" , "pals@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 12:21:45 -0000 Yes/Support. Regards, Nagendra On 11/2/15, 9:17 PM, "Pals on behalf of Ignacio Goyret" wrote: >Given the very low quantity of responses (1, not counting authors) >and since this is a meeting week, I'll extend the WG Last Call >another week until Monday Nov/9/2015. > >Hopefully, by then, more people may have found the time to read >this very short draft and answer yeah/nay. > >Thanks all, > >-Ignacio >L2tpext chair > > >>At 09:39 10/19/2015, Ignacio Goyret wrote: >>>Hi group,=20 >>> >>>This email starts a two-week Working-Group Last-Call (WGLC) for >>>draft-ietf-l2tpext-sbfd-discriminator-00 >>>http://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/ >>> >>>Please send comments to the list and state whether or not you support >>>progressing this document (in the later case, please also state the >>>reasons). Silence is not indication of support. >>> >>>This poll runs until ** November 3rd, 2015 **. >>> >>>We are also polling for knowledge of any IPR that applies to this >>>draft, to ensure that IPR has been disclosed in compliance with >>>IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >>> >>>* If you are listed as a document author or contributor *, please >>>respond only if you are aware of any changes to IPR from your >>>response during the poll for adoption, at >>>http://www.ietf.org/mail-archive/web/l2tpext/current/msg01389.html >>> >>>If you are *not* listed as an author or contributor, then please >>>explicitly respond only if you are aware of any IPR that has not >>>yet been disclosed in conformance with IETF rules. >>> >>>Thank you, >>> >>>Carlos and Ignacio >>>L2tpext co-chairs >>> >>>_______________________________________________ >>>L2tpext mailing list >>>L2tpext@ietf.org >>>https://www.ietf.org/mailman/listinfo/l2tpext >> >>_______________________________________________ >>L2tpext mailing list >>L2tpext@ietf.org >>https://www.ietf.org/mailman/listinfo/l2tpext > >_______________________________________________ >Pals mailing list >Pals@ietf.org >https://www.ietf.org/mailman/listinfo/pals From nobody Thu Nov 5 06:22:55 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5481B2D8B; Thu, 5 Nov 2015 06:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hx4OLk2tUk7T; Thu, 5 Nov 2015 06:22:48 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F0A1B2D9A; Thu, 5 Nov 2015 06:22:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1757; q=dns/txt; s=iport; t=1446733367; x=1447942967; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dhHj4lIquUZt+7RM4WhWRyLMmbli5C/VTr/GKnWjzsw=; b=jYkZMmmRVmW9EgOf+Tr4bCBxaZJGbuzSi/YCGVXhq7wqqWO7sM4ogm7+ 1jOTxozhnxDDmjFo4c4ydvBI1bG7ScyXhqx+NPBUaRCETF8NXYqN/FCno 0yggoyt2nZqwSbnD+TJQx8Ep/4N6UcKoWxJRnX88QAGg2DnX7JvjybRti A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D2AQBfZTtW/4kNJK1egztTbwa+AwENgV4XCoUlSgKBLzgUAQEBAQEBAYEKhDYBAQQBAQE3NAsQAgEIDgoeECcLJQIEAQ0FCYglDcF6AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZUhH6EKhACAVCELAWSZ4NhAYUciAaBWkiDd5I3g3EBHwEBQoQEcgGEF4EHAQEB X-IronPort-AV: E=Sophos;i="5.20,247,1444694400"; d="scan'208";a="42225794" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP; 05 Nov 2015 14:22:46 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tA5EMksv008777 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2015 14:22:46 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 Nov 2015 08:22:45 -0600 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.000; Thu, 5 Nov 2015 08:22:45 -0600 From: "Reshad Rahman (rrahman)" To: Ignacio Goyret , "l2tpext@ietf.org" Subject: Re: [Pals] WGLC for draft-ietf-l2tpext-sbfd-discriminator Thread-Topic: [Pals] WGLC for draft-ietf-l2tpext-sbfd-discriminator Thread-Index: AQHRCqmJ6KUZWu6dS0O8NznO4C8StZ6OkQEA Date: Thu, 5 Nov 2015 14:22:45 +0000 Message-ID: References: <201510191639.t9JGdXLG004819@cliff.eng.ascend.com> <201510192003.t9JK3sgH010715@cliff.eng.ascend.com> In-Reply-To: <201510192003.t9JK3sgH010715@cliff.eng.ascend.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.64.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <134A2DCB01C1724E8A8DF5E56CB7ADA4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" , "pals@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 14:22:49 -0000 Support. Regards, Reshad. On 2015-10-19, 4:03 PM, "Pals on behalf of Ignacio Goyret" wrote: >Sent again to include WGs that should also be in the loop. >-Ignacio > >At 09:39 10/19/2015, Ignacio Goyret wrote: >>Hi group,=20 >> >>This email starts a two-week Working-Group Last-Call (WGLC) for >>draft-ietf-l2tpext-sbfd-discriminator-00 >>http://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/ >> >>Please send comments to the list and state whether or not you support >>progressing this document (in the later case, please also state the >>reasons). Silence is not indication of support. >> >>This poll runs until ** November 3rd, 2015 **. >> >>We are also polling for knowledge of any IPR that applies to this >>draft, to ensure that IPR has been disclosed in compliance with >>IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >> >>* If you are listed as a document author or contributor *, please >>respond only if you are aware of any changes to IPR from your >>response during the poll for adoption, at >>http://www.ietf.org/mail-archive/web/l2tpext/current/msg01389.html >> >>If you are *not* listed as an author or contributor, then please >>explicitly respond only if you are aware of any IPR that has not >>yet been disclosed in conformance with IETF rules. >> >>Thank you, >> >>Carlos and Ignacio >>L2tpext co-chairs >> >>_______________________________________________ >>L2tpext mailing list >>L2tpext@ietf.org >>https://www.ietf.org/mailman/listinfo/l2tpext > >_______________________________________________ >Pals mailing list >Pals@ietf.org >https://www.ietf.org/mailman/listinfo/pals From nobody Thu Nov 5 09:22:18 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649E91B3170; Thu, 5 Nov 2015 09:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nr0t4SqcbXm9; Thu, 5 Nov 2015 09:22:15 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F8F1B316A; Thu, 5 Nov 2015 09:22:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2638; q=dns/txt; s=iport; t=1446744135; x=1447953735; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AQnkc6mGHWo0tI57Js1CwrAI1nLi7jcYXkhB1lnY5GI=; b=AxFnoGp1BuWWfe1AIlto1jDCgvUTXAshY5Qd+sQh/2ba1h/mdhMzp5zZ QnV0NlNr6iskW7FNKX9w67aO9Ko9pKD6uPiNJ3u9I99k5dlkYI04oRc+G ZuWrbdum0DDWFN9XAHGxgcjYN7JqvIq0+HvalNA6WkRUnAWssPRgf8/LE A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D2AQBwjztW/5tdJa1egztTbwa+AwENgV4XCoUlSgKBMzgUAQEBAQEBAYEKhDUBAQEEAQEBNzQLDAQCAQgRBAEBAR4JBycLFAkIAgQBDQUIAYglDcF/AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZUhH6EKhACAVCELAWWSAGFHId/gWFIg3eDJY8Sg3EBHwEBQoQEcgGEF4EHAQEB X-IronPort-AV: E=Sophos;i="5.20,248,1444694400"; d="scan'208";a="205432434" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 05 Nov 2015 17:22:13 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tA5HMD5i003986 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2015 17:22:13 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 Nov 2015 11:22:13 -0600 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1104.000; Thu, 5 Nov 2015 11:22:13 -0600 From: "Girija Raghavendra Rao (giraghav)" To: "Nagendra Kumar Nainar (naikumar)" , Ignacio Goyret , "l2tpext@ietf.org" Subject: RE: [Pals] [L2tpext] WGLC for draft-ietf-l2tpext-sbfd-discriminator Thread-Topic: [Pals] [L2tpext] WGLC for draft-ietf-l2tpext-sbfd-discriminator Thread-Index: AQHRFp2LwH5Y+d3FXE2W8lc6kmGx6p6NwF2A///vN+A= Date: Thu, 5 Nov 2015 17:22:13 +0000 Message-ID: <25681436917842cfba7a944dd9a006a2@XCH-ALN-015.cisco.com> References: <201510191639.t9JGdXLG004819@cliff.eng.ascend.com> <201510192003.t9JK3sgH010715@cliff.eng.ascend.com> <201511030218.tA32I43t019265@cliff.eng.ascend.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.66.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" , "pals@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 17:22:17 -0000 Yes/Support the drafts advancement. Thanks & Regards R.Girija -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nagendra Kumar= Nainar (naikumar) Sent: Thursday, November 05, 2015 5:52 PM To: Ignacio Goyret; l2tpext@ietf.org Cc: rtg-bfd@ietf.org; pals@ietf.org Subject: Re: [Pals] [L2tpext] WGLC for draft-ietf-l2tpext-sbfd-discriminato= r Yes/Support. Regards, Nagendra On 11/2/15, 9:17 PM, "Pals on behalf of Ignacio Goyret" wrote: >Given the very low quantity of responses (1, not counting authors) and=20 >since this is a meeting week, I'll extend the WG Last Call another week=20 >until Monday Nov/9/2015. > >Hopefully, by then, more people may have found the time to read this=20 >very short draft and answer yeah/nay. > >Thanks all, > >-Ignacio >L2tpext chair > > >>At 09:39 10/19/2015, Ignacio Goyret wrote: >>>Hi group, >>> >>>This email starts a two-week Working-Group Last-Call (WGLC) for >>>draft-ietf-l2tpext-sbfd-discriminator-00 >>>http://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator >>>/ >>> >>>Please send comments to the list and state whether or not you support=20 >>>progressing this document (in the later case, please also state the=20 >>>reasons). Silence is not indication of support. >>> >>>This poll runs until ** November 3rd, 2015 **. >>> >>>We are also polling for knowledge of any IPR that applies to this=20 >>>draft, to ensure that IPR has been disclosed in compliance with IETF=20 >>>IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >>> >>>* If you are listed as a document author or contributor *, please=20 >>>respond only if you are aware of any changes to IPR from your=20 >>>response during the poll for adoption, at=20 >>>http://www.ietf.org/mail-archive/web/l2tpext/current/msg01389.html >>> >>>If you are *not* listed as an author or contributor, then please=20 >>>explicitly respond only if you are aware of any IPR that has not yet=20 >>>been disclosed in conformance with IETF rules. >>> >>>Thank you, >>> >>>Carlos and Ignacio >>>L2tpext co-chairs >>> >>>_______________________________________________ >>>L2tpext mailing list >>>L2tpext@ietf.org >>>https://www.ietf.org/mailman/listinfo/l2tpext >> >>_______________________________________________ >>L2tpext mailing list >>L2tpext@ietf.org >>https://www.ietf.org/mailman/listinfo/l2tpext > >_______________________________________________ >Pals mailing list >Pals@ietf.org >https://www.ietf.org/mailman/listinfo/pals From nobody Thu Nov 5 17:17:57 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A001AD481; Thu, 5 Nov 2015 17:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWHulu4xECct; Thu, 5 Nov 2015 17:17:51 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56CC81ACEDD; Thu, 5 Nov 2015 17:17:51 -0800 (PST) Received: by pacdm15 with SMTP id dm15so79924347pac.3; Thu, 05 Nov 2015 17:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CKxMvXeUh6sy6g2lgffyzYXMKF2RcG4RiGfukURZBcE=; b=noc6weEMixQjEkDW1uLvo4I/LTUy6VQy2Z3ftO9woM4DWx+Iq00qgJWCnxYFHt60m2 anYWNlkkN9roQ3FngmRsGUCPGpv8IVysdobVtx1fuX7OIf9zIDHpvCntZOpSoInTz5ou 4B/D9elBj0nsFHk+mP4LqQsG1+3HxJCyncjHmULASETpE+ijOXYshQySQzg7iHsi+vMS /hQq3QEl6INiXqj/I237kxVdtpddr/PLGXRCzA/uCGu+Jki3hoAg+UsGLdgVi6Fbh4BT jEdUiVD3Eu2+sDguFFNLHG7uZ6lhKcPj1CXAxNe9WXF+6SmteaQcWD+HV9RH1v9LBeZ3 jgLQ== X-Received: by 10.66.160.106 with SMTP id xj10mr13396751pab.153.1446772670974; Thu, 05 Nov 2015 17:17:50 -0800 (PST) Received: from [192.168.1.10] (c-73-189-176-93.hsd1.ca.comcast.net. [73.189.176.93]) by smtp.gmail.com with ESMTPSA id ha1sm10144327pbc.54.2015.11.05.17.17.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Nov 2015 17:17:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: [Pals] [L2tpext] WGLC for draft-ietf-l2tpext-sbfd-discriminator From: Sam Aldrin In-Reply-To: <201511030218.tA32I43t019265@cliff.eng.ascend.com> Date: Thu, 5 Nov 2015 17:17:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <74266EC5-B8D1-4211-B24D-6C63D9772686@gmail.com> References: <201510191639.t9JGdXLG004819@cliff.eng.ascend.com> <201510192003.t9JK3sgH010715@cliff.eng.ascend.com> <201511030218.tA32I43t019265@cliff.eng.ascend.com> To: Ignacio Goyret X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: rtg-bfd@ietf.org, l2tpext@ietf.org, pals@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 01:17:53 -0000 It is a simple draft to extend support for SBFD. Support to advance the document. -sam > On Nov 2, 2015, at 6:17 PM, Ignacio Goyret = wrote: >=20 > Given the very low quantity of responses (1, not counting authors) > and since this is a meeting week, I'll extend the WG Last Call > another week until Monday Nov/9/2015. >=20 > Hopefully, by then, more people may have found the time to read > this very short draft and answer yeah/nay. >=20 > Thanks all, >=20 > -Ignacio > L2tpext chair >=20 >=20 >> At 09:39 10/19/2015, Ignacio Goyret wrote: >>> Hi group,=20 >>>=20 >>> This email starts a two-week Working-Group Last-Call (WGLC) for >>> draft-ietf-l2tpext-sbfd-discriminator-00 >>> = http://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/ >>>=20 >>> Please send comments to the list and state whether or not you = support >>> progressing this document (in the later case, please also state the >>> reasons). Silence is not indication of support. >>>=20 >>> This poll runs until ** November 3rd, 2015 **. >>>=20 >>> We are also polling for knowledge of any IPR that applies to this >>> draft, to ensure that IPR has been disclosed in compliance with >>> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more = details). >>>=20 >>> * If you are listed as a document author or contributor *, please >>> respond only if you are aware of any changes to IPR from your >>> response during the poll for adoption, at = http://www.ietf.org/mail-archive/web/l2tpext/current/msg01389.html >>>=20 >>> If you are *not* listed as an author or contributor, then please >>> explicitly respond only if you are aware of any IPR that has not >>> yet been disclosed in conformance with IETF rules. >>>=20 >>> Thank you, >>>=20 >>> Carlos and Ignacio >>> L2tpext co-chairs >>>=20 >>> _______________________________________________ >>> L2tpext mailing list >>> L2tpext@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2tpext >>=20 >> _______________________________________________ >> L2tpext mailing list >> L2tpext@ietf.org >> https://www.ietf.org/mailman/listinfo/l2tpext >=20 > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals From nobody Thu Nov 5 21:52:54 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A3D1A886F; Thu, 5 Nov 2015 21:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7JX4fgByqDO; Thu, 5 Nov 2015 21:52:46 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152891A8872; Thu, 5 Nov 2015 21:52:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2413; q=dns/txt; s=iport; t=1446789166; x=1447998766; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5zd5BGCEp9POCz+MNifyz3OXa2zjiD7gUI03Ci0saWw=; b=DrtQNJluQHaQeNvUFD4KONAqsjG04cYIj9QSbw53Z2Z7oPitgAylzKOa DH/69ncLloMoaaFlmowHl+FchCQBNM5TNv9Xk5VKOcNKoyN1jZ2iSb1Mc Hr3VbDACia6shxDq0aeOAwPvXwaDWxvp6R3iVcPdAnNzilptogoS262+W w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQAgDtPjxW/4cNJK1egztTbwa+BwENgWAXCoUlSgKBOjgUAQEBAQEBAYEKhDYBAQQBAQE3NAsQAgEIDgoeEB8ICyUCBAENBQmIJQ3BDQEBAQEBAQEBAQEBAQEBAQEBAQEBARiGVIR+hCoQAgFQhCwFlkgBDoUOiAaBWkiDd4MljxKDcQEfAQFChARyAYQMgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,250,1444694400"; d="scan'208";a="204301325" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP; 06 Nov 2015 05:52:34 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tA65qXWx015752 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Nov 2015 05:52:33 GMT Received: from xch-rtp-016.cisco.com (64.101.220.156) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 6 Nov 2015 00:52:32 -0500 Received: from xch-rtp-016.cisco.com ([64.101.220.156]) by XCH-RTP-016.cisco.com ([64.101.220.156]) with mapi id 15.00.1104.000; Fri, 6 Nov 2015 00:52:32 -0500 From: "MALLIK MUDIGONDA (mmudigon)" To: Ignacio Goyret , "l2tpext@ietf.org" Subject: Re: [Pals] [L2tpext] WGLC for draft-ietf-l2tpext-sbfd-discriminator Thread-Topic: [Pals] [L2tpext] WGLC for draft-ietf-l2tpext-sbfd-discriminator Thread-Index: AQHRFp2LF0XUzSYtmkuyyD+YQdEB856Nr5qAgAGCzoA= Date: Fri, 6 Nov 2015 05:52:32 +0000 Message-ID: References: <201510191639.t9JGdXLG004819@cliff.eng.ascend.com> <201510192003.t9JK3sgH010715@cliff.eng.ascend.com> <201511030218.tA32I43t019265@cliff.eng.ascend.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.143.26.81] Content-Type: text/plain; charset="us-ascii" Content-ID: <8F8499BCA4F7BA4F85A355AD231F2026@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" , "pals@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 05:52:50 -0000 I support progressing the draft Regards Mallik On 05/11/15 17:51, "Nagendra Kumar Nainar (naikumar)" wrote: >Yes/Support. > >Regards, >Nagendra > >On 11/2/15, 9:17 PM, "Pals on behalf of Ignacio Goyret" > wrote: > >>Given the very low quantity of responses (1, not counting authors) >>and since this is a meeting week, I'll extend the WG Last Call >>another week until Monday Nov/9/2015. >> >>Hopefully, by then, more people may have found the time to read >>this very short draft and answer yeah/nay. >> >>Thanks all, >> >>-Ignacio >>L2tpext chair >> >> >>>At 09:39 10/19/2015, Ignacio Goyret wrote: >>>>Hi group,=20 >>>> >>>>This email starts a two-week Working-Group Last-Call (WGLC) for >>>>draft-ietf-l2tpext-sbfd-discriminator-00 >>>>http://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/ >>>> >>>>Please send comments to the list and state whether or not you support >>>>progressing this document (in the later case, please also state the >>>>reasons). Silence is not indication of support. >>>> >>>>This poll runs until ** November 3rd, 2015 **. >>>> >>>>We are also polling for knowledge of any IPR that applies to this >>>>draft, to ensure that IPR has been disclosed in compliance with >>>>IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >>>> >>>>* If you are listed as a document author or contributor *, please >>>>respond only if you are aware of any changes to IPR from your >>>>response during the poll for adoption, at >>>>http://www.ietf.org/mail-archive/web/l2tpext/current/msg01389.html >>>> >>>>If you are *not* listed as an author or contributor, then please >>>>explicitly respond only if you are aware of any IPR that has not >>>>yet been disclosed in conformance with IETF rules. >>>> >>>>Thank you, >>>> >>>>Carlos and Ignacio >>>>L2tpext co-chairs >>>> >>>>_______________________________________________ >>>>L2tpext mailing list >>>>L2tpext@ietf.org >>>>https://www.ietf.org/mailman/listinfo/l2tpext >>> >>>_______________________________________________ >>>L2tpext mailing list >>>L2tpext@ietf.org >>>https://www.ietf.org/mailman/listinfo/l2tpext >> >>_______________________________________________ >>Pals mailing list >>Pals@ietf.org >>https://www.ietf.org/mailman/listinfo/pals > From nobody Tue Nov 17 06:23:57 2015 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 E9A4E1B32C7; Tue, 17 Nov 2015 06:23:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-multipoint-active-tail-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151117142355.19492.81926.idtracker@ietfa.amsl.com> Date: Tue, 17 Nov 2015 06:23:55 -0800 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 14:23:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD Multipoint Active Tails. Authors : Dave Katz Dave Ward Santosh Pallagatti Filename : draft-ietf-bfd-multipoint-active-tail-01.txt Pages : 17 Date : 2015-11-17 Abstract: This document describes active tail extensions to the Bidirectional Forwarding Detection (BFD) protocol for multipoint and multicast networks. Comments on this draft should be directed to rtg- bfd@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-active-tail-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 17 06:27:41 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A241B32DD for ; Tue, 17 Nov 2015 06:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqPA0WykArxs for ; Tue, 17 Nov 2015 06:27:36 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A4F1B32DB for ; Tue, 17 Nov 2015 06:27:35 -0800 (PST) Received: from SN1PR0501MB2142.namprd05.prod.outlook.com (10.163.228.157) by SN1PR0501MB2142.namprd05.prod.outlook.com (10.163.228.157) with Microsoft SMTP Server (TLS) id 15.1.318.15; Tue, 17 Nov 2015 14:27:17 +0000 Received: from SN1PR0501MB2142.namprd05.prod.outlook.com ([10.163.228.157]) by SN1PR0501MB2142.namprd05.prod.outlook.com ([10.163.228.157]) with mapi id 15.01.0318.003; Tue, 17 Nov 2015 14:27:17 +0000 From: Santosh P K To: "rtg-bfd@ietf.org" Subject: FW: I-D Action: draft-ietf-bfd-multipoint-active-tail-01.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-active-tail-01.txt Thread-Index: AQHRIUObU9ai/CYnr0qpla8pvLwzjJ6gRRIQ Date: Tue, 17 Nov 2015 14:27:16 +0000 Message-ID: References: <20151117142355.19492.81926.idtracker@ietfa.amsl.com> In-Reply-To: <20151117142355.19492.81926.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=santoshpk@juniper.net; x-originating-ip: [116.197.184.12] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB2142; 5:f6oihwZ3VPaU8d//ZI4+frorLC3u4A2ijNl4zSXhJzkPKBJJX/AN99U8/3+/x5/u9WFsjNRt9kW+0588Z49t0dxBafeY/lK9Y2jqaIWXFvFg5yryq7gSEBfFhQ5rgCEVEckbf9VkDCyJsopvhr84zQ==; 24:wOEQBlo10m7Ul0lfAJXNJ14ARRCWgmxPbpqs11O6WcmraidFobuesABeLUBhN+W0d52cLBdzgjIxwHfQGXuSifWxpnyWhJabSTIfLUNaChI=; 20:rjdO+91gtMw3CqlXiMiK+z87hZDHAPi9x6Cb/1xs+OQKQr00EKPwvOf3dTTi5/niw65HooB7Gj/qViR0RF3Bgw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB2142; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:SN1PR0501MB2142; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2142; x-forefront-prvs: 07630F72AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(199003)(377424004)(189002)(2351001)(102836002)(33656002)(122556002)(5007970100001)(2950100001)(106356001)(40100003)(76576001)(86362001)(105586002)(2900100001)(81156007)(586003)(5003600100002)(99286002)(19580405001)(50986999)(5001960100002)(5001920100001)(106116001)(230783001)(77096005)(450100001)(110136002)(10400500002)(2501003)(19580395003)(54356999)(15975445007)(11100500001)(92566002)(66066001)(189998001)(4001150100001)(76176999)(5008740100001)(5002640100001)(97736004)(87936001)(5004730100002)(74316001)(107886002)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2142; H:SN1PR0501MB2142.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2015 14:27:16.7523 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2142 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 14:27:39 -0000 TmV3IHZlcnNpb24gb2YgbXVsdGlwb2ludCB0YWlsIGRvY3VtZW50IGhhcyBiZWVuIHVwZGF0ZWQu IFRoZXJlIGhhcyBiZWVuIG5vIGNoYW5nZSBpbiB0aGUgY29udGVudCBvZiB0aGlzIGRyYWZ0LiBQ bGVhc2UgZ28gZ2V0IGJhY2sgaWYgdGhlcmUgYXJlIGFueSByZXZpZXcgY29tbWVudHMuIA0KDQpU aGFua3MNClNhbnRvc2ggUCBLIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBpbnRlcm5ldC0NCj4gZHJhZnRzQGlldGYub3JnDQo+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVy IDE3LCAyMDE1IDc6NTQgUE0NCj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiBDYzogcnRn LWJmZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWJmZC1tdWx0 aXBvaW50LWFjdGl2ZS10YWlsLTAxLnR4dA0KPiANCj4gDQo+IEEgTmV3IEludGVybmV0LURyYWZ0 IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmll cy4NCj4gIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEJpZGlyZWN0aW9uYWwgRm9y d2FyZGluZyBEZXRlY3Rpb24gV29ya2luZw0KPiBHcm91cCBvZiB0aGUgSUVURi4NCj4gDQo+ICAg ICAgICAgVGl0bGUgICAgICAgICAgIDogQkZEIE11bHRpcG9pbnQgQWN0aXZlIFRhaWxzLg0KPiAg ICAgICAgIEF1dGhvcnMgICAgICAgICA6IERhdmUgS2F0eg0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgIERhdmUgV2FyZA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIFNhbnRvc2ggUGFs bGFnYXR0aQ0KPiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludC1h Y3RpdmUtdGFpbC0wMS50eHQNCj4gCVBhZ2VzICAgICAgICAgICA6IDE3DQo+IAlEYXRlICAgICAg ICAgICAgOiAyMDE1LTExLTE3DQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBk ZXNjcmliZXMgYWN0aXZlIHRhaWwgZXh0ZW5zaW9ucyB0byB0aGUgQmlkaXJlY3Rpb25hbA0KPiAg ICBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBwcm90b2NvbCBmb3IgbXVsdGlwb2ludCBhbmQg bXVsdGljYXN0DQo+ICAgIG5ldHdvcmtzLiAgQ29tbWVudHMgb24gdGhpcyBkcmFmdCBzaG91bGQg YmUgZGlyZWN0ZWQgdG8gcnRnLQ0KPiAgICBiZmRAaWV0Zi5vcmcuDQo+IA0KPiANCj4gDQo+IFRo ZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50LWFj dGl2ZS10YWlsLw0KPiANCj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFi bGUgYXQ6DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmZC1tdWx0 aXBvaW50LWFjdGl2ZS10YWlsLTAxDQo+IA0KPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVy c2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50LWFjdGl2ZS10YWlsLTAxDQo+IA0KPiANCj4gUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzLw0KDQo= From nobody Tue Nov 17 15:28:06 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7454E1B3526 for ; Tue, 17 Nov 2015 15:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pj66DLhQzX_7 for ; Tue, 17 Nov 2015 15:28:03 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 809D41B3527 for ; Tue, 17 Nov 2015 15:28:03 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id C242D1E1D1; Tue, 17 Nov 2015 18:28:41 -0500 (EST) Date: Tue, 17 Nov 2015 18:28:41 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: WGLC BFD Multipoint (with active tail) Message-ID: <20151117232841.GF16000@pfrc.org> References: <20151005182059.GB5112@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151005182059.GB5112@pfrc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "Reshad Rahman \(rrahman\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 23:28:04 -0000 Working Group, There was no support on the mailing list for progressing these documents at this time. There was very little response during the session in Yokohama that these document should progress. Of the people who commented on having read the documents, they believe they should progress together. This last call closes with no consensus to advance the documents. We can revisit this next year. -- Jeff and Reshad On Mon, Oct 05, 2015 at 02:20:59PM -0400, Jeffrey Haas wrote: > BFD Working Group, > > This starts an extended Working Group Last Call for the following documents: > draft-ietf-bfd-multipoint > draft-ietf-bfd-multipoint-active-tail > > This Last Call will end after IETF week at the upcoming IETF-94 in Yokohama, > Japan. It gives us plenty of time to discuss any open issues with the > documents, plus also provides opportunity for in-room discussion during the > upcoming Working Group meeting if we need it. > > Please provide your feedback on the readiness of the documents to advance > for publication by the IESG. > > Authors, Editors and Contributors, this is also your call to state whether > these documents have any IPR considerations. > > -- Jeff From nobody Tue Nov 17 15:31:27 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8451B3537; Tue, 17 Nov 2015 15:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykJA2raJdgvI; Tue, 17 Nov 2015 15:31:25 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 880CD1B3535; Tue, 17 Nov 2015 15:31:25 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0A99A1E1D1; Tue, 17 Nov 2015 18:32:03 -0500 (EST) Date: Tue, 17 Nov 2015 18:32:02 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: WGLC for draft-ietf-bfd-mpls-mib Message-ID: <20151117233202.GG16000@pfrc.org> References: <20151005182631.GD5112@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151005182631.GD5112@pfrc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: mpls@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 23:31:26 -0000 Working Group, There was no on list support for advancing the BFD MPLS MIB. During the IETF session in Yokohama, there was one person who had read this draft and he was an MPLS chair. :-) There is no consensus to advance this draft. We can re-visit this next year. Authors, please note the draft has expired. -- Jeff On Mon, Oct 05, 2015 at 02:26:31PM -0400, Jeffrey Haas wrote: > BFD Working Group, > (cc'ing MPLS) > > This begins an extended Working Group Last Call for > draft-ietf-bfd-mpls-mib, BFD Management Information Base (MIB) extensions > for MPLS and MPLS-TP Networks. The authors have indicated that this > document is ready for advancement. > > Please indicate whether you believe this document is ready to proceed for > publication by the IESG. Note that since this is a MIB, a MIB Doctor review > will be requested as part of the publication process. > > Authors, please state whether this document carries any IPR considerations. > > -- Jeff From nobody Tue Nov 17 15:34:13 2015 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 49F641B3543 for ; Tue, 17 Nov 2015 15:34:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151117233412.16031.66640.idtracker@ietfa.amsl.com> Date: Tue, 17 Nov 2015 15:34:12 -0800 From: IETF Secretariat Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 23:34:12 -0000 Changed milestone "Submit the BFD MPLS extension MIB to the IESG to be considered as a Proposed Standard", set due date to April 2016 from November 2014. Changed milestone "Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard", set due date to April 2016 from March 2015. URL: https://datatracker.ietf.org/wg/bfd/charter/ From nobody Tue Nov 17 15:34:51 2015 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 F22401B3545 for ; Tue, 17 Nov 2015 15:34:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151117233450.16031.66239.idtracker@ietfa.amsl.com> Date: Tue, 17 Nov 2015 15:34:50 -0800 From: IETF Secretariat Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 23:34:51 -0000 Changed milestone "Submit the BFD Seamless Base draft to the IESG to be considered as a Proposed Standard", set due date to December 2015 from March 2015. Changed milestone "Submit the BFD Seamless IP draft to the IESG to be considered as a Proposed Standard", set due date to December 2015 from March 2015. URL: https://datatracker.ietf.org/wg/bfd/charter/ From nobody Tue Nov 17 15:50:10 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D291B3599 for ; Tue, 17 Nov 2015 15:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2_ZHrubwrEo for ; Tue, 17 Nov 2015 15:50:07 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BC0221B3593 for ; Tue, 17 Nov 2015 15:50:01 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 179491E1D1; Tue, 17 Nov 2015 18:50:40 -0500 (EST) Date: Tue, 17 Nov 2015 18:50:40 -0500 From: Jeffrey Haas To: "Reshad Rahman (rrahman)" Subject: Re: Multiple BFD sessions between the same pair of end-points Message-ID: <20151117235040.GK16000@pfrc.org> References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> <730CA9F1-B952-4E2F-A61A-B4276BDE5EF4@gmail.com> <087FBA90-F5EB-4691-A5FD-96F784569F6C@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 23:50:09 -0000 On Wed, Nov 04, 2015 at 12:48:44AM +0000, Reshad Rahman (rrahman) wrote: > > > Hi all, > > Thanks Alex and Carlos. Since RFC5883 doesn’t preclude having multiple BFD sessions for MH, I think that the operational model for BFD IP MH should allow for multiple sessions between 2 endpoints (same src/dst/vrf). To support this, we could e.g. add local discriminator to the key. I think having operational support is a good thing to have. It's a small amount of future-proofing for a case that's getting repeated, if low-grade discussion. > Note that I am not pushing for another OOB mechanism. I also think that bootstrapping a second session in the yang module is currently out of scope. -- Jeff (speaking as an individual contributor) From nobody Tue Nov 17 15:53:27 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C423A1B35AA for ; Tue, 17 Nov 2015 15:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSaLSrl9dC3b for ; Tue, 17 Nov 2015 15:53:25 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 92AF61B35A7 for ; Tue, 17 Nov 2015 15:53:25 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id E3BDD1E1D1; Tue, 17 Nov 2015 18:54:03 -0500 (EST) Date: Tue, 17 Nov 2015 18:54:03 -0500 From: Jeffrey Haas To: Marc Binderberger Subject: Re: Multiple BFD sessions between the same pair of end-points Message-ID: <20151117235403.GL16000@pfrc.org> References: <7347100B5761DC41A166AC17F22DF11221922C58@eusaamb103.ericsson.se> <730CA9F1-B952-4E2F-A61A-B4276BDE5EF4@gmail.com> <087FBA90-F5EB-4691-A5FD-96F784569F6C@cisco.com> <20151104012017393317.5f16d0ce@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151104012017393317.5f16d0ce@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Reshad Rahman , "Carlos Pignataro \(cpignata\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 23:53:26 -0000 Marc, On Wed, Nov 04, 2015 at 01:20:17AM -0800, Marc Binderberger wrote: > I'm not too deep into YANG et al., so I apologize upfront for this email :-) > . I understand YANG is about configuration but are we trying to find a common > way to reflect the various (CLI-)configurations that are out in the market? > Isn't this, well, a bit restricting? Generally, Yang modules in IETF have focused more on configuration at the start, but Yang and netconf also cover operational state as well, including notifications. > Should a generic "configuration" of a BFD session not contain all the > variables of the particular layers? E.g. for the BFD packet itself not just > timer and multiplier but "my" and "your" discriminator too? For the IP layer > src/dst IP and egress interface? For operational state, absolutely. For configuration state, reflecting constraints for provisioning the existing mechanisms is probably where we want to start. It could be easily argued that we could simply provide for completely abstract configuration of sessions, but that means that the model would fail to enforce constraints that real implementations have. The current example of this is multiple sessions between the same pair of endpoints. > The various RFCs 5881, 5883, ... would be special cases that could be > incorporated. E.g. a "your" discriminator of zero (or lack of this parameter) > for a single-hop IP-based BFD session would mean to follow RFC5881 and it's > bootstrapping mechanism. > > > Maybe this is too generic to start the YANG endeavor. But in these days of > "programmability" I would expect more than an API that replaces my CLI 1:1. Arguably, we're more at "generic CLI" than full-out API. However, this is mostly my somewhat tainted opinion as i2rs chair. :-) -- Jeff (speaking as an individual contributor) From nobody Tue Nov 17 16:01:46 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5CD1B35B4 for ; Tue, 17 Nov 2015 16:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o32ab0b8AS2Y for ; Tue, 17 Nov 2015 16:01:42 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 006AF1B35B3 for ; Tue, 17 Nov 2015 16:01:41 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 458721E1D1; Tue, 17 Nov 2015 19:02:20 -0500 (EST) Date: Tue, 17 Nov 2015 19:02:20 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: IETF 94 candiate minutes Message-ID: <20151118000220.GN16000@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 00:01:44 -0000 Thanks to Ignas and Reshad for taking minutes and to Reshad for consolidating them. Please forward addendums or corrections to the mailing list by end of day Friday. ----- Forwarded message from "Reshad Rahman (rrahman)" ----- Tuesday, November 3, 2015 10:30 - 11:30 Morning session I Chairs: Jeff Haas, Reshad Rahman Scribe: Ignas Bagdonas ibagdona@gmail.com 1) 10:30-10:40 - WG Status Update [Jeff] Thank you Nobo, welcome to Reshad. [Jeff] Document status: wiki status is current. 5884-bis is in editor queue. Santosh Pallagati is taking over editorial work for S-BFD (one open issue). [Jeff] S-BFD use case document publication status - what is the feeling of WG? Taking sense of the room. Do you think we should publish this? Not to publish this? Two people have opinion on this, one way or the other. Sense of WG is that this is not critical work, will give another chance to the authors. [Jeff] WG last-call: 2 multipoint drafts and MIB draft. 0 comments to date regarding progressing these documents. Have you read BFD multipoint document? Of you who have read the document who think that it is ready for last-call? Around two-thirds of the people have read the multi-point draft and think it should go to last-call. [Loa Andersson] I would not object the progress of the first MP doc. [Jeff] Is there anyone who has read the first MP document but not the second one and would like to progress the first one? [Answer] Sense of the room seems to be that we will progress these things together. [Jeff Haas] Who has read the MIB document? [Answer] One. [Loa] It should get MIB Doctor review too. [Jeff] Interesting BFD work going on elsewhere: use of BFD with VRRP (RTG WG) to benefit from BFD’s more aggressive timer intervals. 2) 10:40-10:50 - https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-01 BFD For VXLAN presented by Greg Mirsky [Jeff] Regarding adoption as WG doc, this draft is not intended to be in BFD WG since there are no BFD changes. [Greg] To be presented in NVO3 also. [Jeff] Concerns on multicast addressing on mailing list. [Greg] That is a generic concern of multicast in DC environment. VRRP uses well known multicast address. This is a generic problem. We need to find the right group to discuss this. [Jeff] VRRP does not use aggressive timers as BFD. There can be many sessions crossing the same link. [Greg] There was a proposal to use multipoint BFD to help convergence of VRRP [Shahram] Is the intention to have BFD packet processed up-mep or down-mep? [Greg] Up-Mep is the intent. We can enforce/check that. [Shahram] Is the intent to test VXLAN forwarding? [Greg] Yes. [Wim Hendrickx] There are VXLAN OAM proposals (OAM bit in VXLAN header). Did you consider integrating this solution into a more common NVO3 OAM protocol?[Greg] Yes. [Wim] If that mechanism would become available, would you be willing to adopt it for your proposal? [Greg] Yes. [Ilya Vershkov] Does VNI 0 address ECMP? [Greg] If we have OAM protocol, then ICMP overlay then becomes a non-issue. IP OAM has a problem ensuring that your OAM traffic is inband. If you are in a tunnel, you are guaranteed to be inband. You can have different source BFD sessions to the same target FEC to address ECMP use case. [Jeff Tantsura] The current incarnation is used to detect the liveness of receiver, not the end-to-end path. Change of UDP port to change path? [Greg] If we have ACH and OAM protocol type, then we are not subject to UDP header hashing and will follow the same path. BFD is more of CC than CV. [Jeff Haas] How many people have read the doc? [Answer] 8 people read the doc. [Jeff Haas] You need to talk to NVO3 and see how to progress OAM mechanism there. 3) 10:50-11:00 - https://tools.ietf.org/html/draft-mahesh-bfd-authentication-01 BFD Fast Authentication presented by Ashesh Mishra [Ashesh] Proposed to adopt this as WG doc. [Jeff] Requests that authors find someone to check all the state transitions. Any review from security group? [Ashesh] None at this point [Jeff] Out of those who have read the doc, how many think it is ready for adoption? 4 people say it’s ready for adoption [Shahram] How about any changes to the packet? e.g. Timer interval change [Ashesh] Poll sequence is part of the change which requires authentication [Jeff] Shahram are you happy to support this authentication mechanism? [Shahram] Yes [Jeff Haas] How many operators in the room [Answer] 3 [Jeff Haas] Out of the 3 how many have deployed BFD authentication? [Answer] 2 out of 3. [Reshad] Is it only for single-hop? [Answer] Yes. [Jeff] SHA-1 EOL is closer than expected, need to use stronger crypto mechanism, but then the rate needs to be decreased? 4) 11:00-11:10 – https://tools.ietf.org/html/draft-ietf-bfd-yang-00 BFD YANG Update presented by Reshad Rahman [Les Ginsberg] When an implementation has different sessions for same neighbour, what is the value add? Why support it? [Reshad] I don’t have the answer at this point [Greg Mirsky] I see a use case for multihop BFD. For single hop bfd I do not see possible use cases. In case of IP MPLS, you can use source port number trick to cover ECMP scenario scenario to force sessions onto different ECMP paths. [Mahesh Jethanandani] Was the question specific to MPLS, or for any routing protocols running between two endpoints? [Les] My question is for multiple clients requesting multiple sessions. [Reshad] One use case that I can see is multiple applications requiring different convergence parameters. [Jeff Haas] One application is granularity of timers. This is because of how timer negotiation works - more aggressive timers get accepted, and in case of failure of the more aggressive session may be covered by another session with less aggressive timers. [Les] That is a good summary. The question for the group whether WG wants to support it. [Reshad] What we are discussing in Design Team is not a common implementation. If this makes life for majority of implementations hard then this is not right approach. [Jeff] We can choose one or another behaviour. As an example from BGP, there may be multiple BGP sessions between the same two peers, there are a few deployments and that added a lot of complexity. [Jeff Haas] Regarding LIME - it does not define common RPC types. With S-BFD we have basically introduced ping stype functionality. [Jeff Haas] Question to Loa. Do MPLS chairs have a work item to try to look at this work and make sure that it is supporting your needs? [Loa Andersoon] We are not doing anything to coordinate. If this is needed, we can address it, but we do not do that at the moment. 5 – 11:10-11:20 - Wrap–up [Jeff Haas] Is there anybody in the room that has implenentation that supports demand mode BFD? [Answer] No-one. [Jeff Haas]: BFD has been pretty stable for several years. We potentially can take BFD to full standard then. This needs to do errata, implementation reports, etc. Question to WG - do you think that BFD should be considered to be full standard? [Answer] 0 hands. [Jeff Haas] I will take the question to the mailing list. [Shahram] Is anyone using echo mode? [Jeff Haas] Yes, there are vendors supporting echo. Attendees from Cisco (Reshad Rahman, Mahesh etc) and Ericsson (Rick Taylor) indicated that they support echo. From nobody Tue Nov 17 22:55:27 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66971AD277 for ; Tue, 17 Nov 2015 22:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnvEl2wJmP12 for ; Tue, 17 Nov 2015 22:55:23 -0800 (PST) Received: from door.sniff.de (door.sniff.de [82.212.219.2]) by ietfa.amsl.com (Postfix) with ESMTP id C0D591AD272 for ; Tue, 17 Nov 2015 22:55:22 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 964182AA0F; Wed, 18 Nov 2015 06:55:01 +0000 (GMT) Date: Tue, 17 Nov 2015 22:55:21 -0800 From: Marc Binderberger To: Jeffrey Haas Message-ID: <20151117225521123133.3640da4f@sniff.de> In-Reply-To: <20151118000220.GN16000@pfrc.org> References: <20151118000220.GN16000@pfrc.org> Subject: Re: IETF 94 candiate minutes MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: base64 X-Mailer: GyazMail version 1.5.16 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 06:55:27 -0000 SGVsbG8gSmVmZiAmIEJGRCBsaXN0LA0KDQo+IFtKZWZmIEhhYXNdOiBCRkQgaGFzIGJlZW4g cHJldHR5IHN0YWJsZSBmb3Igc2V2ZXJhbCB5ZWFycy4gV2UgcG90ZW50aWFsbHkgDQo+IGNh biB0YWtlIEJGRCB0byBmdWxsIHN0YW5kYXJkIHRoZW4uIFRoaXMgbmVlZHMgdG8gZG8gZXJy YXRhLCBpbXBsZW1lbnRhdGlvbiANCj4gcmVwb3J0cywgZXRjLiBRdWVzdGlvbiB0byBXRyAt IGRvIHlvdSB0aGluayB0aGF0IEJGRCBzaG91bGQgYmUgY29uc2lkZXJlZCANCj4gdG8gYmUg ZnVsbCBzdGFuZGFyZD8NCj4gW0Fuc3dlcl0NCj4gMCBoYW5kcy4NCj4gW0plZmYgSGFhc10N Cj4gSSB3aWxsIHRha2UgdGhlIHF1ZXN0aW9uIHRvIHRoZSBtYWlsaW5nIGxpc3QuDQoNCg0K QmVpbmcgYSBmdWxsIHN0YW5kYXJkLCBkb2VzIHRoaXMgaGFzIGFueSBpbXBsaWNhdGlvbnMg Zm9yIEJGRD8gIFdpbGwgdGhlcmUgYmUgDQptb3JlIElFVEYtaG9vcHMgdG8ganVtcCB0aHJv dWdoIGZvciBmdXR1cmUgcHJvdG9jb2wgd29yaz8gIE9yIGlzIGl0IG1vcmUgYSANCm5hdHVy YWwgc3RlcCBmb3IgYSBzdGFibGUgIlByb3Bvc2VkIFN0YW5kYXJkIiB0byBiZSByZWNvZ25p emVkIGFzIGEgU3RhbmRhcmQ/DQoNCg0KUmVnYXJkcywgTWFyYw0KDQoNCg0KDQpPbiBUdWUs IDE3IE5vdiAyMDE1IDE5OjAyOjIwIC0wNTAwLCBKZWZmcmV5IEhhYXMgd3JvdGU6DQo+IFRo YW5rcyB0byBJZ25hcyBhbmQgUmVzaGFkIGZvciB0YWtpbmcgbWludXRlcyBhbmQgdG8gUmVz aGFkIGZvcg0KPiBjb25zb2xpZGF0aW5nIHRoZW0uDQo+IA0KPiBQbGVhc2UgZm9yd2FyZCBh ZGRlbmR1bXMgb3IgY29ycmVjdGlvbnMgdG8gdGhlIG1haWxpbmcgbGlzdCBieSBlbmQgb2Yg ZGF5DQo+IEZyaWRheS4NCj4gDQo+IA0KPiAtLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSBmcm9t ICJSZXNoYWQgUmFobWFuIChycmFobWFuKSIgPHJyYWhtYW5AY2lzY28uY29tPiANCj4gLS0t LS0NCj4gDQo+IFR1ZXNkYXksIE5vdmVtYmVyIDMsIDIwMTUNCj4gICAgICAgICAxMDozMCAt IDExOjMwICBNb3JuaW5nIHNlc3Npb24gSQ0KPiAgICAgICAgIENoYWlyczogSmVmZiBIYWFz LCBSZXNoYWQgUmFobWFuDQo+ICAgICAgICAgU2NyaWJlOiBJZ25hcyBCYWdkb25hcyBpYmFn ZG9uYUBnbWFpbC5jb20NCj4gDQo+IA0KPiAxKSAxMDozMC0xMDo0MCAtIFdHIFN0YXR1cyBV cGRhdGUNCj4gDQo+IFtKZWZmXQ0KPiBUaGFuayB5b3UgTm9ibywgd2VsY29tZSB0byBSZXNo YWQuDQo+IA0KPiBbSmVmZl0NCj4gRG9jdW1lbnQgc3RhdHVzOiB3aWtpIHN0YXR1cyBpcyBj dXJyZW50LiA1ODg0LWJpcyBpcyBpbiBlZGl0b3IgcXVldWUuIA0KPiBTYW50b3NoIFBhbGxh Z2F0aSBpcyB0YWtpbmcgb3ZlciBlZGl0b3JpYWwgd29yayBmb3IgUy1CRkQgKG9uZSBvcGVu IGlzc3VlKS4NCj4gDQo+IFtKZWZmXQ0KPiBTLUJGRCB1c2UgY2FzZSBkb2N1bWVudCBwdWJs aWNhdGlvbiBzdGF0dXMgLSB3aGF0IGlzIHRoZSBmZWVsaW5nIG9mIFdHPyANCj4gVGFraW5n IHNlbnNlIG9mIHRoZSByb29tLiBEbyB5b3UgdGhpbmsgd2Ugc2hvdWxkIHB1Ymxpc2ggdGhp cz8gTm90IHRvIA0KPiBwdWJsaXNoIHRoaXM/IFR3byBwZW9wbGUgaGF2ZSBvcGluaW9uIG9u IHRoaXMsIG9uZSB3YXkgb3IgdGhlIG90aGVyLiBTZW5zZSANCj4gb2YgV0cgaXMgdGhhdCB0 aGlzIGlzIG5vdCBjcml0aWNhbCB3b3JrLCB3aWxsIGdpdmUgYW5vdGhlciBjaGFuY2UgdG8g dGhlIA0KPiBhdXRob3JzLg0KPiANCj4gW0plZmZdDQo+IFdHIGxhc3QtY2FsbDogMiBtdWx0 aXBvaW50IGRyYWZ0cyBhbmQgTUlCIGRyYWZ0LiAwIGNvbW1lbnRzIHRvIGRhdGUgDQo+IHJl Z2FyZGluZyBwcm9ncmVzc2luZyB0aGVzZSBkb2N1bWVudHMuDQo+IA0KPiBIYXZlIHlvdSBy ZWFkIEJGRCBtdWx0aXBvaW50IGRvY3VtZW50PyBPZiB5b3Ugd2hvIGhhdmUgcmVhZCB0aGUg ZG9jdW1lbnQgDQo+IHdobyB0aGluayB0aGF0IGl0IGlzIHJlYWR5IGZvciBsYXN0LWNhbGw/ IEFyb3VuZCB0d28tdGhpcmRzIG9mIHRoZSBwZW9wbGUgDQo+IGhhdmUgcmVhZCB0aGUgbXVs dGktcG9pbnQgZHJhZnQgYW5kIHRoaW5rIGl0IHNob3VsZCBnbyB0byBsYXN0LWNhbGwuDQo+ IA0KPiBbTG9hIEFuZGVyc3Nvbl0NCj4gSSB3b3VsZCBub3Qgb2JqZWN0IHRoZSBwcm9ncmVz cyBvZiB0aGUgZmlyc3QgTVAgZG9jLg0KPiANCj4gW0plZmZdDQo+IElzIHRoZXJlIGFueW9u ZSB3aG8gaGFzIHJlYWQgdGhlIGZpcnN0IE1QIGRvY3VtZW50IGJ1dCBub3QgdGhlIHNlY29u ZCBvbmUgDQo+IGFuZCB3b3VsZCBsaWtlIHRvIHByb2dyZXNzIHRoZSBmaXJzdCBvbmU/DQo+ IFtBbnN3ZXJdDQo+IFNlbnNlIG9mIHRoZSByb29tIHNlZW1zIHRvIGJlIHRoYXQgd2Ugd2ls bCBwcm9ncmVzcyB0aGVzZSB0aGluZ3MgdG9nZXRoZXIuDQo+IA0KPiBbSmVmZiBIYWFzXQ0K PiBXaG8gaGFzIHJlYWQgdGhlIE1JQiBkb2N1bWVudD8NCj4gW0Fuc3dlcl0NCj4gT25lLg0K PiBbTG9hXQ0KPiBJdCBzaG91bGQgZ2V0IE1JQiBEb2N0b3IgcmV2aWV3IHRvby4NCj4gDQo+ IFtKZWZmXQ0KPiBJbnRlcmVzdGluZyBCRkQgd29yayBnb2luZyBvbiBlbHNld2hlcmU6IHVz ZSBvZiBCRkQgd2l0aCBWUlJQIChSVEcgV0cpIHRvIA0KPiBiZW5lZml0IGZyb20gQkZEoaZz IG1vcmUgYWdncmVzc2l2ZSB0aW1lciBpbnRlcnZhbHMuDQo+IA0KPiAyKSAxMDo0MC0xMDo1 MCAtIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zcGFsbGFnYXR0aS1iZmQt dnhsYW4tMDEgDQo+IEJGRCBGb3IgVlhMQU4gcHJlc2VudGVkIGJ5IEdyZWcgTWlyc2t5DQo+ IA0KPiBbSmVmZl0NCj4gUmVnYXJkaW5nIGFkb3B0aW9uIGFzIFdHIGRvYywgdGhpcyBkcmFm dCBpcyBub3QgaW50ZW5kZWQgdG8gYmUgaW4gQkZEIFdHIA0KPiBzaW5jZSB0aGVyZSBhcmUg bm8gQkZEIGNoYW5nZXMuDQo+IFtHcmVnXQ0KPiBUbyBiZSBwcmVzZW50ZWQgaW4gTlZPMyBh bHNvLg0KPiANCj4gW0plZmZdDQo+IENvbmNlcm5zIG9uIG11bHRpY2FzdCBhZGRyZXNzaW5n IG9uIG1haWxpbmcgbGlzdC4NCj4gW0dyZWddDQo+IFRoYXQgaXMgYSBnZW5lcmljIGNvbmNl cm4gb2YgbXVsdGljYXN0IGluIERDIGVudmlyb25tZW50LiBWUlJQIHVzZXMgd2VsbCANCj4g a25vd24gbXVsdGljYXN0IGFkZHJlc3MuIFRoaXMgaXMgYSBnZW5lcmljIHByb2JsZW0uIFdl IG5lZWQgdG8gZmluZCB0aGUgDQo+IHJpZ2h0IGdyb3VwIHRvIGRpc2N1c3MgdGhpcy4NCj4g W0plZmZdDQo+IFZSUlAgZG9lcyBub3QgdXNlIGFnZ3Jlc3NpdmUgdGltZXJzIGFzIEJGRC4g VGhlcmUgY2FuIGJlIG1hbnkgc2Vzc2lvbnMgDQo+IGNyb3NzaW5nIHRoZSBzYW1lIGxpbmsu DQo+IFtHcmVnXQ0KPiBUaGVyZSB3YXMgYSBwcm9wb3NhbCB0byB1c2UgbXVsdGlwb2ludCBC RkQgdG8gaGVscCBjb252ZXJnZW5jZSBvZiBWUlJQDQo+IA0KPiBbU2hhaHJhbV0NCj4gSXMg dGhlIGludGVudGlvbiB0byBoYXZlIEJGRCBwYWNrZXQgcHJvY2Vzc2VkIHVwLW1lcCBvciBk b3duLW1lcD8NCj4gW0dyZWddDQo+IFVwLU1lcCBpcyB0aGUgaW50ZW50LiBXZSBjYW4gZW5m b3JjZS9jaGVjayB0aGF0Lg0KPiANCj4gW1NoYWhyYW1dDQo+IElzIHRoZSBpbnRlbnQgdG8g dGVzdCBWWExBTiBmb3J3YXJkaW5nPw0KPiBbR3JlZ10NCj4gWWVzLg0KPiANCj4gW1dpbSBI ZW5kcmlja3hdDQo+IFRoZXJlIGFyZSBWWExBTiBPQU0gcHJvcG9zYWxzIChPQU0gYml0IGlu IFZYTEFOIGhlYWRlcikuIERpZCB5b3UgY29uc2lkZXIgDQo+IGludGVncmF0aW5nIHRoaXMg c29sdXRpb24gaW50byBhIG1vcmUgY29tbW9uIE5WTzMgT0FNIHByb3RvY29sP1tHcmVnXSBZ ZXMuDQo+IFtXaW1dDQo+IElmIHRoYXQgbWVjaGFuaXNtIHdvdWxkIGJlY29tZSBhdmFpbGFi bGUsIHdvdWxkIHlvdSBiZSB3aWxsaW5nIHRvIGFkb3B0IGl0IA0KPiBmb3IgeW91ciBwcm9w b3NhbD8NCj4gW0dyZWddDQo+IFllcy4NCj4gDQo+IFtJbHlhIFZlcnNoa292XQ0KPiBEb2Vz IFZOSSAwIGFkZHJlc3MgRUNNUD8NCj4gW0dyZWddDQo+IElmIHdlIGhhdmUgT0FNIHByb3Rv Y29sLCB0aGVuIElDTVAgb3ZlcmxheSB0aGVuIGJlY29tZXMgYSBub24taXNzdWUuIElQIE9B TSANCj4gaGFzIGEgcHJvYmxlbSBlbnN1cmluZyB0aGF0IHlvdXIgT0FNIHRyYWZmaWMgaXMg aW5iYW5kLiBJZiB5b3UgYXJlIGluIGEgDQo+IHR1bm5lbCwgeW91IGFyZSBndWFyYW50ZWVk IHRvIGJlIGluYmFuZC4gWW91IGNhbiBoYXZlIGRpZmZlcmVudCBzb3VyY2UgQkZEIA0KPiBz ZXNzaW9ucyB0byB0aGUgc2FtZSB0YXJnZXQgRkVDIHRvIGFkZHJlc3MgRUNNUCB1c2UgY2Fz ZS4NCj4gDQo+IFtKZWZmIFRhbnRzdXJhXQ0KPiBUaGUgY3VycmVudCBpbmNhcm5hdGlvbiBp cyB1c2VkIHRvIGRldGVjdCB0aGUgbGl2ZW5lc3Mgb2YgcmVjZWl2ZXIsIG5vdCB0aGUgDQo+ IGVuZC10by1lbmQgcGF0aC4gIENoYW5nZSBvZiBVRFAgcG9ydCB0byBjaGFuZ2UgcGF0aD8N Cj4gW0dyZWddDQo+IElmIHdlIGhhdmUgQUNIIGFuZCBPQU0gcHJvdG9jb2wgdHlwZSwgdGhl biB3ZSBhcmUgbm90IHN1YmplY3QgdG8gVURQIGhlYWRlciANCj4gaGFzaGluZyBhbmQgd2ls bCBmb2xsb3cgdGhlIHNhbWUgcGF0aC4gQkZEIGlzIG1vcmUgb2YgQ0MgdGhhbiBDVi4NCj4g DQo+IFtKZWZmIEhhYXNdDQo+IEhvdyBtYW55IHBlb3BsZSBoYXZlIHJlYWQgdGhlIGRvYz8N Cj4gW0Fuc3dlcl0NCj4gOCBwZW9wbGUgcmVhZCB0aGUgZG9jLg0KPiBbSmVmZiBIYWFzXQ0K PiBZb3UgbmVlZCB0byB0YWxrIHRvIE5WTzMgYW5kIHNlZSBob3cgdG8gcHJvZ3Jlc3MgT0FN IG1lY2hhbmlzbSB0aGVyZS4NCj4gDQo+IDMpIDEwOjUwLTExOjAwIC0gDQo+IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYWhlc2gtYmZkLWF1dGhlbnRpY2F0aW9uLTAx IEJGRCBGYXN0IA0KPiBBdXRoZW50aWNhdGlvbiBwcmVzZW50ZWQgYnkgQXNoZXNoIE1pc2hy YQ0KPiANCj4gW0FzaGVzaF0NCj4gUHJvcG9zZWQgdG8gYWRvcHQgdGhpcyBhcyBXRyBkb2Mu DQo+IFtKZWZmXQ0KPiBSZXF1ZXN0cyB0aGF0IGF1dGhvcnMgZmluZCBzb21lb25lIHRvIGNo ZWNrIGFsbCB0aGUgc3RhdGUgdHJhbnNpdGlvbnMuIEFueSANCj4gcmV2aWV3IGZyb20gc2Vj dXJpdHkgZ3JvdXA/DQo+IFtBc2hlc2hdDQo+IE5vbmUgYXQgdGhpcyBwb2ludA0KPiANCj4g W0plZmZdDQo+IE91dCBvZiB0aG9zZSB3aG8gaGF2ZSByZWFkIHRoZSBkb2MsIGhvdyBtYW55 IHRoaW5rIGl0IGlzIHJlYWR5IGZvciBhZG9wdGlvbj8NCj4gDQo+IDQgcGVvcGxlIHNheSBp dKGmcyByZWFkeSBmb3IgYWRvcHRpb24NCj4gDQo+IFtTaGFocmFtXQ0KPiBIb3cgYWJvdXQg YW55IGNoYW5nZXMgdG8gdGhlIHBhY2tldD8gZS5nLiBUaW1lciBpbnRlcnZhbCBjaGFuZ2UN Cj4gW0FzaGVzaF0NCj4gUG9sbCBzZXF1ZW5jZSBpcyBwYXJ0IG9mIHRoZSBjaGFuZ2Ugd2hp Y2ggcmVxdWlyZXMgYXV0aGVudGljYXRpb24NCj4gDQo+IFtKZWZmXQ0KPiBTaGFocmFtIGFy ZSB5b3UgaGFwcHkgdG8gc3VwcG9ydCB0aGlzIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbT8N Cj4gW1NoYWhyYW1dDQo+IFllcw0KPiANCj4gW0plZmYgSGFhc10NCj4gSG93IG1hbnkgb3Bl cmF0b3JzIGluIHRoZSByb29tDQo+IFtBbnN3ZXJdDQo+IDMNCj4gDQo+IFtKZWZmIEhhYXNd DQo+IE91dCBvZiB0aGUgMyBob3cgbWFueSBoYXZlIGRlcGxveWVkIEJGRCBhdXRoZW50aWNh dGlvbj8NCj4gW0Fuc3dlcl0NCj4gMiBvdXQgb2YgMy4NCj4gDQo+IFtSZXNoYWRdDQo+IElz IGl0IG9ubHkgZm9yIHNpbmdsZS1ob3A/DQo+IFtBbnN3ZXJdDQo+IFllcy4NCj4gDQo+IFtK ZWZmXQ0KPiBTSEEtMSBFT0wgaXMgY2xvc2VyIHRoYW4gZXhwZWN0ZWQsIG5lZWQgdG8gdXNl IHN0cm9uZ2VyIGNyeXB0byBtZWNoYW5pc20sIA0KPiBidXQgdGhlbiB0aGUgcmF0ZSBuZWVk cyB0byBiZSBkZWNyZWFzZWQ/DQo+IA0KPiA0KSAxMTowMC0xMToxMCChViBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZmQteWFuZy0wMCBCRkQgDQo+IFlBTkcg VXBkYXRlIHByZXNlbnRlZCBieSBSZXNoYWQgUmFobWFuDQo+IA0KPiBbTGVzIEdpbnNiZXJn XQ0KPiBXaGVuIGFuIGltcGxlbWVudGF0aW9uIGhhcyBkaWZmZXJlbnQgc2Vzc2lvbnMgZm9y IHNhbWUgbmVpZ2hib3VyLCB3aGF0IGlzIA0KPiB0aGUgdmFsdWUgYWRkPyBXaHkgc3VwcG9y dCBpdD8NCj4gW1Jlc2hhZF0NCj4gSSBkb26hpnQgaGF2ZSB0aGUgYW5zd2VyIGF0IHRoaXMg cG9pbnQNCj4gDQo+IFtHcmVnIE1pcnNreV0NCj4gSSBzZWUgYSB1c2UgY2FzZSBmb3IgbXVs dGlob3AgQkZELiBGb3Igc2luZ2xlIGhvcCBiZmQgSSBkbyBub3Qgc2VlIHBvc3NpYmxlIA0K PiB1c2UgY2FzZXMuIEluIGNhc2Ugb2YgSVAgTVBMUywgeW91IGNhbiB1c2Ugc291cmNlIHBv cnQgbnVtYmVyIHRyaWNrIHRvIA0KPiBjb3ZlciBFQ01QIHNjZW5hcmlvIHNjZW5hcmlvIHRv IGZvcmNlIHNlc3Npb25zIG9udG8gZGlmZmVyZW50IEVDTVAgcGF0aHMuDQo+IFtNYWhlc2gg SmV0aGFuYW5kYW5pXQ0KPiBXYXMgdGhlIHF1ZXN0aW9uIHNwZWNpZmljIHRvIE1QTFMsIG9y IGZvciBhbnkgcm91dGluZyBwcm90b2NvbHMgcnVubmluZyANCj4gYmV0d2VlbiB0d28gZW5k cG9pbnRzPw0KPiBbTGVzXQ0KPiBNeSBxdWVzdGlvbiBpcyBmb3IgbXVsdGlwbGUgY2xpZW50 cyByZXF1ZXN0aW5nIG11bHRpcGxlIHNlc3Npb25zLg0KPiBbUmVzaGFkXQ0KPiBPbmUgdXNl IGNhc2UgdGhhdCBJIGNhbiBzZWUgaXMgbXVsdGlwbGUgYXBwbGljYXRpb25zIHJlcXVpcmlu ZyBkaWZmZXJlbnQgDQo+IGNvbnZlcmdlbmNlIHBhcmFtZXRlcnMuDQo+IFtKZWZmIEhhYXNd DQo+IE9uZSBhcHBsaWNhdGlvbiBpcyBncmFudWxhcml0eSBvZiB0aW1lcnMuIFRoaXMgaXMg YmVjYXVzZSBvZiBob3cgdGltZXIgDQo+IG5lZ290aWF0aW9uIHdvcmtzIC0gbW9yZSBhZ2dy ZXNzaXZlIHRpbWVycyBnZXQgYWNjZXB0ZWQsIGFuZCBpbiBjYXNlIG9mIA0KPiBmYWlsdXJl IG9mIHRoZSBtb3JlIGFnZ3Jlc3NpdmUgc2Vzc2lvbiBtYXkgYmUgY292ZXJlZCBieSBhbm90 aGVyIHNlc3Npb24gDQo+IHdpdGggbGVzcyBhZ2dyZXNzaXZlIHRpbWVycy4NCj4gW0xlc10N Cj4gVGhhdCBpcyBhIGdvb2Qgc3VtbWFyeS4gVGhlIHF1ZXN0aW9uIGZvciB0aGUgZ3JvdXAg d2hldGhlciBXRyB3YW50cyB0byANCj4gc3VwcG9ydCBpdC4NCj4gW1Jlc2hhZF0NCj4gV2hh dCB3ZSBhcmUgZGlzY3Vzc2luZyBpbiBEZXNpZ24gVGVhbSBpcyBub3QgYSBjb21tb24gaW1w bGVtZW50YXRpb24uIElmIA0KPiB0aGlzIG1ha2VzIGxpZmUgZm9yIG1ham9yaXR5IG9mIGlt cGxlbWVudGF0aW9ucyBoYXJkIHRoZW4gdGhpcyBpcyBub3QgcmlnaHQgDQo+IGFwcHJvYWNo Lg0KPiBbSmVmZl0NCj4gV2UgY2FuIGNob29zZSBvbmUgb3IgYW5vdGhlciBiZWhhdmlvdXIu IEFzIGFuIGV4YW1wbGUgZnJvbSBCR1AsIHRoZXJlIG1heSANCj4gYmUgbXVsdGlwbGUgQkdQ IHNlc3Npb25zIGJldHdlZW4gdGhlIHNhbWUgdHdvIHBlZXJzLCB0aGVyZSBhcmUgYSBmZXcg DQo+IGRlcGxveW1lbnRzIGFuZCB0aGF0IGFkZGVkIGEgbG90IG9mIGNvbXBsZXhpdHkuDQo+ IA0KPiBbSmVmZiBIYWFzXQ0KPiBSZWdhcmRpbmcgTElNRSAtIGl0IGRvZXMgbm90IGRlZmlu ZSBjb21tb24gUlBDIHR5cGVzLiBXaXRoIFMtQkZEIHdlIGhhdmUgDQo+IGJhc2ljYWxseSBp bnRyb2R1Y2VkIHBpbmcgc3R5cGUgZnVuY3Rpb25hbGl0eS4NCj4gW0plZmYgSGFhc10NCj4g UXVlc3Rpb24gdG8gTG9hLiBEbyBNUExTIGNoYWlycyBoYXZlIGEgd29yayBpdGVtIHRvIHRy eSB0byBsb29rIGF0IHRoaXMgDQo+IHdvcmsgYW5kIG1ha2Ugc3VyZSB0aGF0IGl0IGlzIHN1 cHBvcnRpbmcgeW91ciBuZWVkcz8NCj4gW0xvYSBBbmRlcnNvb25dDQo+IFdlIGFyZSBub3Qg ZG9pbmcgYW55dGhpbmcgdG8gY29vcmRpbmF0ZS4gSWYgdGhpcyBpcyBuZWVkZWQsIHdlIGNh biBhZGRyZXNzIA0KPiBpdCwgYnV0IHdlIGRvIG5vdCBkbyB0aGF0IGF0IHRoZSBtb21lbnQu DQo+IA0KPiA1IKFWIDExOjEwLTExOjIwIC0gV3JhcKFWdXANCj4gDQo+IFtKZWZmIEhhYXNd DQo+IElzIHRoZXJlIGFueWJvZHkgaW4gdGhlIHJvb20gdGhhdCBoYXMgaW1wbGVuZW50YXRp b24gdGhhdCBzdXBwb3J0cyBkZW1hbmQgDQo+IG1vZGUgQkZEPw0KPiBbQW5zd2VyXQ0KPiBO by1vbmUuDQo+IFtKZWZmIEhhYXNdOiBCRkQgaGFzIGJlZW4gcHJldHR5IHN0YWJsZSBmb3Ig c2V2ZXJhbCB5ZWFycy4gV2UgcG90ZW50aWFsbHkgDQo+IGNhbiB0YWtlIEJGRCB0byBmdWxs IHN0YW5kYXJkIHRoZW4uIFRoaXMgbmVlZHMgdG8gZG8gZXJyYXRhLCBpbXBsZW1lbnRhdGlv biANCj4gcmVwb3J0cywgZXRjLiBRdWVzdGlvbiB0byBXRyAtIGRvIHlvdSB0aGluayB0aGF0 IEJGRCBzaG91bGQgYmUgY29uc2lkZXJlZCANCj4gdG8gYmUgZnVsbCBzdGFuZGFyZD8NCj4g W0Fuc3dlcl0NCj4gMCBoYW5kcy4NCj4gW0plZmYgSGFhc10NCj4gSSB3aWxsIHRha2UgdGhl IHF1ZXN0aW9uIHRvIHRoZSBtYWlsaW5nIGxpc3QuDQo+IA0KPiBbU2hhaHJhbV0NCj4gSXMg YW55b25lIHVzaW5nIGVjaG8gbW9kZT8NCj4gW0plZmYgSGFhc10NCj4gWWVzLCB0aGVyZSBh cmUgdmVuZG9ycyBzdXBwb3J0aW5nIGVjaG8uDQo+IEF0dGVuZGVlcyBmcm9tIENpc2NvIChS ZXNoYWQgUmFobWFuLCBNYWhlc2ggZXRjKSBhbmQgRXJpY3Nzb24gKFJpY2sgVGF5bG9yKSAN Cj4gaW5kaWNhdGVkIHRoYXQgdGhleSBzdXBwb3J0IGVjaG8uDQo+IA0KPiA= From nobody Wed Nov 18 02:31:34 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1452A1B2BE6 for ; Wed, 18 Nov 2015 02:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB-G_IqzzD-7 for ; Wed, 18 Nov 2015 02:31:31 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 18EB71B2BE5 for ; Wed, 18 Nov 2015 02:31:31 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 133271E1D1; Wed, 18 Nov 2015 05:32:09 -0500 (EST) Date: Wed, 18 Nov 2015 05:32:08 -0500 From: Jeffrey Haas To: Marc Binderberger Subject: Taking BFD to full standard (was Re: IETF 94 candiate minutes) Message-ID: <20151118103208.GQ16000@pfrc.org> References: <20151118000220.GN16000@pfrc.org> <20151117225521123133.3640da4f@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151117225521123133.3640da4f@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 10:31:32 -0000 Marc, On Tue, Nov 17, 2015 at 10:55:21PM -0800, Marc Binderberger wrote: > > [Jeff Haas]: BFD has been pretty stable for several years. We potentially > > can take BFD to full standard then. This needs to do errata, implementation > > reports, etc. Question to WG - do you think that BFD should be considered > > to be full standard? > > [Answer] > > 0 hands. > > [Jeff Haas] > > I will take the question to the mailing list. > > > Being a full standard, does this has any implications for BFD? Will there be > more IETF-hoops to jump through for future protocol work? Or is it more a > natural step for a stable "Proposed Standard" to be recognized as a Standard? No additional hoops for future work. It is just recognition of stability. It should be noted that of all of the RFC series, there are less than 100 full standard document sets. But that said, part of the work of moving to full standard is taking care of any open issues in the specs. With regard to the based RFC 5880, this really covers two items: - Demand mode, no one implements this. - The M-bit, for multipoint. We're trying to get that implemented. :-) It's perhaps arguable that the fast authentication mechanism and the better cryptographic functionality drafts are part of the suite we'd want to take with us if we went to full standard. -- Jeff From nobody Wed Nov 18 04:47:42 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8641E1A1A9F for ; Wed, 18 Nov 2015 04:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UJ9658Lrkjq for ; Wed, 18 Nov 2015 04:47:40 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B451A1A98 for ; Wed, 18 Nov 2015 04:47:39 -0800 (PST) Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0778.eurprd03.prod.outlook.com (10.161.54.28) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 18 Nov 2015 12:47:18 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0331.019; Wed, 18 Nov 2015 12:47:18 +0000 From: Alexander Vainshtein To: Jeffrey Haas Subject: RE: Taking BFD to full standard (was Re: IETF 94 candidate minutes) Thread-Topic: Taking BFD to full standard (was Re: IETF 94 candidate minutes) Thread-Index: AdEh/0HACyMvO7DFRvutjEZRwnAkgA== Date: Wed, 18 Nov 2015 12:47:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [147.234.241.1] x-microsoft-exchange-diagnostics: 1; DB3PR03MB0778; 5:/abmJLBQgGjVj098y/6v/f9slmfw4IFkX6RONAGM+tGwNRcnz7DcnJirh5YnXZXJPa+e6w9jZX4I3SwMGpkVdSGqkCaZ97aDvMVYjJEHVfBfD+JH39TaZ4RD6z0XGVNF3YjZzy/QxEbASxkKPMQ5Ug==; 24:4kae1rEZyn293+cFopqLVFhsABPOIEPr8UWCJ++jpZgR2Pc7OvrvPbHSm9K5PLv4zYyZY6qkBCktrqdkUFGR0a7gUzw7mZ+3JXGdmwZmM3o= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0778; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:DB3PR03MB0778; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0778; x-forefront-prvs: 0764C4A8CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(252514010)(189002)(24454002)(13464003)(377454003)(19580405001)(50986999)(586003)(5002640100001)(19580395003)(54356999)(5003600100002)(110136002)(5001960100002)(92566002)(86362001)(2900100001)(66066001)(105586002)(11100500001)(189998001)(5008740100001)(101416001)(10400500002)(33656002)(87936001)(122556002)(77096005)(40100003)(102836002)(97736004)(81156007)(76576001)(5007970100001)(5004730100002)(74316001)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0778; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2015 12:47:18.5962 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0778 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 12:47:41 -0000 Jeff and all, Does not moving to full standard require an implementation survey and posti= ng its results as a draft (to be progressed to an Informational RFC)? The example I have in mind is with LDP progressing to Draft Standard.=20 The survey form has been issued in August 2002, and RFCs 5036 (LDP as a Dra= ft Standard) and 5038 (2002 Survey results) have been only published in 200= 7, so it took quite some time:-). =20 I know that IETYF tries to speed up the process - but does this mean that w= e can now skip the formalities of Implementation Survey? Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Wednesday, November 18, 2015 12:32 PM To: Marc Binderberger Cc: rtg-bfd@ietf.org Subject: Taking BFD to full standard (was Re: IETF 94 candiate minutes) Marc, On Tue, Nov 17, 2015 at 10:55:21PM -0800, Marc Binderberger wrote: > > [Jeff Haas]: BFD has been pretty stable for several years. We=20 > > potentially can take BFD to full standard then. This needs to do=20 > > errata, implementation reports, etc. Question to WG - do you think=20 > > that BFD should be considered to be full standard? > > [Answer] > > 0 hands. > > [Jeff Haas] > > I will take the question to the mailing list. >=20 >=20 > Being a full standard, does this has any implications for BFD? Will=20 > there be more IETF-hoops to jump through for future protocol work? Or=20 > is it more a natural step for a stable "Proposed Standard" to be recogniz= ed as a Standard? No additional hoops for future work. It is just recognition of stability. It should be noted that of all of the RFC series, there are less than 100 f= ull standard document sets. But that said, part of the work of moving to full standard is taking care o= f any open issues in the specs. With regard to the based RFC 5880, this re= ally covers two items: - Demand mode, no one implements this. - The M-bit, for multipoint. We're trying to get that implemented. :-) It's perhaps arguable that the fast authentication mechanism and the better= cryptographic functionality drafts are part of the suite we'd want to take= with us if we went to full standard. -- Jeff From nobody Wed Nov 18 06:19:45 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87ED1B2E27 for ; Wed, 18 Nov 2015 06:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcA-Cgq6WB_e for ; Wed, 18 Nov 2015 06:19:43 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F1ABB1B2E1F for ; Wed, 18 Nov 2015 06:19:42 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id F11C61E1D1; Wed, 18 Nov 2015 09:20:21 -0500 (EST) Date: Wed, 18 Nov 2015 09:20:21 -0500 From: Jeffrey Haas To: Alexander Vainshtein Subject: Re: Taking BFD to full standard (was Re: IETF 94 candidate minutes) Message-ID: <20151118142021.GC32083@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: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 14:19:44 -0000 Sasha, On Wed, Nov 18, 2015 at 12:47:18PM +0000, Alexander Vainshtein wrote: > Does not moving to full standard require an implementation survey and posting its results as a draft (to be progressed to an Informational RFC)? An implementation survey is likely still required. Whether it would be required to be published as an RFC is an open question. The IESG has been moving away from certain "process" documents needing to be published as an RFC; for example, use case documents and problem statements. > The example I have in mind is with LDP progressing to Draft Standard. > The survey form has been issued in August 2002, and RFCs 5036 (LDP as a Draft Standard) and 5038 (2002 Survey results) have been only published in 2007, so it took quite some time:-). > > I know that IETYF tries to speed up the process - but does this mean that we can now skip the formalities of Implementation Survey? The stage of Draft standard was removed by RFC 6410. Even with this reduction in process, very few RFCs have looked for a status increase. -- Jeff From nobody Wed Nov 18 09:06:15 2015 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 8F3771A8A08; Wed, 18 Nov 2015 09:06:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alvaro Retana" To: "The IESG" Subject: Alvaro Retana's Discuss on draft-ietf-isis-sbfd-discriminator-02: (with DISCUSS) X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151118170601.5815.13593.idtracker@ietfa.amsl.com> Date: Wed, 18 Nov 2015 09:06:01 -0800 Archived-At: Cc: isis-chairs@ietf.org, l2tlext@ietf.org, ospf@ietf.org, draft-ietf-isis-sbfd-discriminator@ietf.org, rtg-bfd@ietf.org, isis-wg@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 17:06:01 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-isis-sbfd-discriminator-02: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-isis-sbfd-discriminator/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- It has been pointed out during the processing of this document (and other similar ones, draft-ietf-ospf-sbfd-discriminator, for example) that the functionality provided is only the advertisement of S-BFD discriminators, but not a mechanism to map these discriminators to specific applications or use-cases in the nodes. That mapping has been declared out of scope. However, the Base S-BFD draft (draft-ietf-bfd-seamless-base) assumes that the advertisers of the multiple discriminators will in fact provide the ability for the mapping. Specifically, the base S-BFD document reads in Section 3. (Seamless BFD Overview): An S-BFD module on each network node allocates one or more S-BFD discriminators for local entities, and creates a reflector BFD session. Allocated S-BFD discriminators may be advertised by applications (e.g., OSPF/IS-IS). Required result is that applications, on other network nodes, possess the knowledge of the mapping from remote entities to S-BFD discriminators. This text reads to me that S-BFD is expecting the mapping to be somehow provided by the "applications (e.g., OSPF/IS-IS)". There's no other explicit discussion about the mapping in that document. I'm putting a DISCUSS on this document to hold its processing while the requirements from the S-BFD point of view are clarified. The answer to that question should be a discussion in the BFD WG (cc'd in this message), in coordination with the providers of the advertisements (so far the isis, ospf and l2tpext WGs have active drafts in this area). One possible outcome of this required discussion is clearly that the mapping is in fact outside the scope of advertising protocols (such as IS-IS). Other possible outcomes may require this document to be modified. From nobody Wed Nov 18 13:00:18 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1601B2EC3; Wed, 18 Nov 2015 12:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.486 X-Spam-Level: X-Spam-Status: No, score=-7.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cg1pqU6O6o2a; Wed, 18 Nov 2015 12:55:48 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95961B2EC2; Wed, 18 Nov 2015 12:55:48 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id E70E37B81616A; Wed, 18 Nov 2015 20:55:41 +0000 (GMT) Received: from cliff.eng.ascend.com (cliff.eng.ascend.com [192.207.23.55]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id tAIKthXq008949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Nov 2015 20:55:44 GMT Received: from igoyret-c1.alcatel-lucent.com (vpn-17-111.vpn.alcatel-lucent.com [135.224.17.111]) by cliff.eng.ascend.com (8.13.1/8.13.1) with ESMTP id tAIKtdPa009417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2015 12:55:41 -0800 Message-Id: <201511182055.tAIKtdPa009417@cliff.eng.ascend.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 18 Nov 2015 12:53:48 -0800 To: l2tpext@ietf.org From: Ignacio Goyret Subject: Re: [L2tpext] WGLC for draft-ietf-l2tpext-sbfd-discriminator In-Reply-To: <201510192003.t9JK3sgH010715@cliff.eng.ascend.com> References: <201510191639.t9JGdXLG004819@cliff.eng.ascend.com> <201510192003.t9JK3sgH010715@cliff.eng.ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Wed, 18 Nov 2015 13:00:17 -0800 Cc: rtg-bfd@ietf.org, pals@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 20:55:50 -0000 This email concludes the WGLC of draft-ietf-l2tpext-sbfd-discriminator-00. There was support to advance the document so I will work on the write-up to submit the document to the IESG. Thanks, =ADIgnacio >At 09:39 10/19/2015, Ignacio Goyret wrote: >>Hi group,=20 >> >>This email starts a two-week Working-Group Last-Call (WGLC) for >>draft-ietf-l2tpext-sbfd-discriminator-00 >>http://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/ >> From nobody Fri Nov 20 03:50:07 2015 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 6D5061B2E42; Fri, 20 Nov 2015 03:50:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , Subject: The BFD WG has placed draft-mahesh-bfd-authentication in state "Candidate for WG Adoption" X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151120115006.32065.14711.idtracker@ietfa.amsl.com> Date: Fri, 20 Nov 2015 03:50:06 -0800 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 11:50:06 -0000 The BFD WG has placed draft-mahesh-bfd-authentication in state Candidate for WG Adoption (entered by Reshad Rahman) The document is available at https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ Comment: As per IETf94 meeting, this draft is candidate for adoption. Adoption email will be sent shortly to BFD mailing list. From nobody Fri Nov 20 04:03:29 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1D01B2EBD; Fri, 20 Nov 2015 04:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.085 X-Spam-Level: X-Spam-Status: No, score=-15.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnJaDnDGzVjB; Fri, 20 Nov 2015 04:03:26 -0800 (PST) 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 7C8931B2EB9; Fri, 20 Nov 2015 04:03:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1621; q=dns/txt; s=iport; t=1448021006; x=1449230606; h=from:to:subject:date:message-id:mime-version; bh=5TYn3Plfct1Ql3oEraOD/hBBV55YF1jRoOOuKgtpGmQ=; b=EjXcBWx8cFylXnLh0oP4RCy1XM9shmN4a9ptWnJ3jGZis4H/OeQK48bZ MAkbfveRaBiVYwg+TcUs3N5er2eWIbAwwQT3e8yzOHWHTD5kXLzkWIy+A 4Rg6Tl01n5f8/3TvzSl7LqCXCkWWLGr40t7Nk/pgObQLpZ0SwEowrO21U c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgBOC09W/4sNJK1egm5NU3W/BgENg?= =?us-ascii?q?WUhhW6BTTgUAQEBAQEBAYEKhCsQbh0BCwF0JwQBiEANwBUBAQEBAQUBAQEBARo?= =?us-ascii?q?EhlSEfoUIhDEFlkwBfoQkiAyBXYRAiTWJCINxAR8BAUKEBIUYgQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,322,1444694400"; d="scan'208,217";a="210263490" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2015 12:03:25 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id tAKC3PTU002192 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Nov 2015 12:03:25 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 20 Nov 2015 06:03:24 -0600 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.000; Fri, 20 Nov 2015 06:03:25 -0600 From: "Reshad Rahman (rrahman)" To: "rtg-bfd@ietf.org" , "draft-mahesh-bfd-authentication@ietf.org" Subject: Request for WG adoption of draft-mahesh-bfd-authentication Thread-Topic: Request for WG adoption of draft-mahesh-bfd-authentication Thread-Index: AQHRI4t1BhxwWi4DrkqzzQbDKMhgLg== Date: Fri, 20 Nov 2015 12:03:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.252.112] Content-Type: multipart/alternative; boundary="_000_D2747638109021rrahmanciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 12:03:28 -0000 --_000_D2747638109021rrahmanciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable BFD WG members, Please indicate to the WG mailing list whether you would support or not sup= port BFD WG adoption of the following document. https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ Authors, as was mentioned at IETF94, you should get your proposal reviewed = by the security group. Regards, Jeff & Reshad. --_000_D2747638109021rrahmanciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9C392868C1E87B40B7BDEF969569A9E1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
BFD WG members,

Please indicate to the WG mailing list whether you would support or no= t support BFD WG adoption of the following document.


Authors, as was mentioned at IETF94, you should get your proposal revi= ewed by the security group.

Regards,
Jeff & Reshad.
--_000_D2747638109021rrahmanciscocom_-- From nobody Sat Nov 21 02:29:43 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D28E1B438E; Sat, 21 Nov 2015 02:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWNEZKRfWO1J; Sat, 21 Nov 2015 02:29:40 -0800 (PST) Received: from door.sniff.de (door.sniff.de [82.212.219.2]) by ietfa.amsl.com (Postfix) with ESMTP id 092201B438C; Sat, 21 Nov 2015 02:29:37 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 28A0B2AA0F; Sat, 21 Nov 2015 10:29:24 +0000 (GMT) Date: Sat, 21 Nov 2015 02:29:56 -0800 From: Marc Binderberger To: Reshad Rahman (rrahman) , "draft-mahesh-bfd-authentication@ietf.org" Message-ID: <20151121022956672568.a3e4948f@sniff.de> In-Reply-To: References: Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.16 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 10:29:42 -0000 Hello Reshad and authors (and BFD experts on the list), it's a smart idea so I support the WG support ;-) But reading the document: it's at this point mainly outlining an idea and I would expect more details to allow for interoperable implementations. Regards, Marc On Fri, 20 Nov 2015 12:03:25 +0000, Reshad Rahman (rrahman) wrote: > BFD WG members, > > Please indicate to the WG mailing list whether you would support or not > support BFD WG adoption of the following document. > > https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ > > Authors, as was mentioned at IETF94, you should get your proposal reviewed > by the security group. > > Regards, > Jeff & Reshad. From nobody Mon Nov 23 22:26:23 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450241B2E5E; Mon, 23 Nov 2015 22:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.249 X-Spam-Level: X-Spam-Status: No, score=-0.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baASwFsnIoQO; Mon, 23 Nov 2015 22:26:19 -0800 (PST) Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com [42.120.133.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3701B2E5C; Mon, 23 Nov 2015 22:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1448346378; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=6ICLufS1ZELzvtgPjKeUhnQ8WBIZVRgwI9mOdwbnqlU=; b=uJ84vGCUV9P7udB4vIpIXS3NJLatu/hYSEECvWlMV2ThbujucZKIu8pumWM0wwATufAwWGSXJ7UJ3dxZpVGh6x44wcKDGzdMsKhqugWLTxsVgFpFLjknqnM93uptFCQrYtFZWa2ebjE+mdxioVvslsXsQSbbdlF6Euf3Cp5nREw= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R141e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03308; MF=dacheng.zdc@alibaba-inc.com; NM=1; PH=DS; RN=4; SR=0; TI=SMTPD_----4FIQSlc; Received: from 10.62.54.19(mailfrom:dacheng.zdc@alibaba-inc.com ip:182.92.253.23) by smtp.aliyun-inc.com(127.0.0.1); Tue, 24 Nov 2015 14:26:15 +0800 User-Agent: Microsoft-MacOutlook/14.5.7.151005 Date: Tue, 24 Nov 2015 14:26:11 +0800 Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication From: "Dacheng Zhang" To: Marc Binderberger , "Reshad Rahman (rrahman)" , "draft-mahesh-bfd-authentication@ietf.org" Message-ID: Thread-Topic: Request for WG adoption of draft-mahesh-bfd-authentication References: <20151121022956672568.a3e4948f@sniff.de> In-Reply-To: <20151121022956672568.a3e4948f@sniff.de> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 06:26:21 -0000 Hi=A3=ACI think this is an interesting draft. It is quite common that we have make a trade off between performance and security. Support for the adoption. ^_^ Some comments and questions: 1) discuss which types of frames MUST be authenticated and which ones SHOULD be authentication. 2) There is a discussion about how the sequence number should be increased in RFC5880, maybe you could follow that one and so avoid any unnecessary confusion. 3) Q: since in this solution, only a small number of frames need to be authenticated, maybe we could consider again to use SHA-2 since the influence in the performance brought by the strong algorithms will no longer be that serious. 4) Q: do you plan to propose a negotiation mechanism for the peers to decide the frames which should be authenticated? If not, please clarify this part of work is out of scope. Cheers Dacheng =D4=DA 15-11-21 =CF=C2=CE=E76:29=A3=AC "Rtg-bfd on behalf of Marc Binderberger" =D0=B4=C8=EB: >Hello Reshad and authors (and BFD experts on the list), > >it's a smart idea so I support the WG support ;-) > >But reading the document: it's at this point mainly outlining an idea and >I=20 >would expect more details to allow for interoperable implementations. > > >Regards, Marc > > > > > >On Fri, 20 Nov 2015 12:03:25 +0000, Reshad Rahman (rrahman) wrote: >> BFD WG members, >>=20 >> Please indicate to the WG mailing list whether you would support or not >> support BFD WG adoption of the following document. >>=20 >> https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ >>=20 >> Authors, as was mentioned at IETF94, you should get your proposal >>reviewed=20 >> by the security group. >>=20 >> Regards, >> Jeff & Reshad. From nobody Mon Nov 23 22:46:46 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85571A0060; Mon, 23 Nov 2015 22:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UL7AKy6U4Cj3; Mon, 23 Nov 2015 22:46:42 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C1E1A0051; Mon, 23 Nov 2015 22:46:42 -0800 (PST) X-AuditID: c618062d-f799d6d000000ec2-9f-5653b5f474bd Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 19.AA.03778.4F5B3565; Tue, 24 Nov 2015 01:57:24 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Tue, 24 Nov 2015 01:46:41 -0500 From: Gregory Mirsky To: Dacheng Zhang , Marc Binderberger , "Reshad Rahman (rrahman)" , "draft-mahesh-bfd-authentication@ietf.org" , Stephen Farrell Subject: RE: Request for WG adoption of draft-mahesh-bfd-authentication Thread-Topic: Request for WG adoption of draft-mahesh-bfd-authentication Thread-Index: AQHRI4t1BhxwWi4DrkqzzQbDKMhgLp6mm9wAgARy5ID//66DQA== Date: Tue, 24 Nov 2015 06:46:40 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221947B4A@eusaamb103.ericsson.se> References: <20151121022956672568.a3e4948f@sniff.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyuXRPiO6XrcFhBmdfKVtMfn6W0eJG3wx2 i9lX/jNbXFvRym7x+c82Rovpe6+xO7B5THz7kcVjyu+NrB5ru6+yeSxZ8pPJo3V1N0sAaxSX TUpqTmZZapG+XQJXxv/nDYwFLxQrLp/by9jAuEG6i5GTQ0LAROLH3FfMELaYxIV769m6GLk4 hASOMErs+NDKCOEsZ5R4f/s+I0gVm4CRxIuNPewgtohAP5PE9FfuIDazgKZE04nPYHFhAXeJ Zz+2QtV4SBzbvIQNwnaS2H7mAJjNIqAqce7cAbCZvAK+EkvP/YDa3MkocePTVSaQBKeApcS9 KZ/AGhiBzvt+ag0TxDJxiVtP5jNBnC0gsWTPeagXRCVePv7HCmErSUxaeo4Vol5fYs/EUywQ trbEsoWvmSEWC0qcnPmEZQKj2CwkY2chaZmFpGUWkpYFjCyrGDlKi1PLctONDDYxAuPtmASb 7g7GPS8tDzEKcDAq8fB+0AwOE2JNLCuuzD3EKMHBrCTCu/wVUIg3JbGyKrUoP76oNCe1+BCj NAeLkjjv/iX3Q4UE0hNLUrNTUwtSi2CyTBycUg2MmpZ3Wv/Uft1yhPnbFQ2/09ufr9/3tHp+ wIWUD0kHFO7ufPukXrLTl3u/kmfmsn9HzvNY/zCaWrlphlBI+e4Q5hNOjuZ8TWYpK/KNuI/3 z8x4sme7bue6NyfWXdx+SFXx8OeQJdH525sio14bR7hua7E7K32Y3Yavcu1O5Urvmser/qRO WBOrrsRSnJFoqMVcVJwIAIOv/AezAgAA Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 06:46:44 -0000 Dear All, I'd like to share comment by Security AD Stephen Farrell on a work that is = directly related to BFD, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf (hope it= is OK to raise security awareness in BFD community): > - 2.1.1, is there any chance of moving on from the "Keyed SHA1" >=20 > from RFC5880 to e.g. HMAC-SHA256 for this? We're generally trying to=20 > get that kind of transition done as we can and moving to use of a=20 > standard integrity check rather than a more home-grown one has some=20 > benefits. The HMAC-SHA1-like thing you're doing is still probably ok,=20 > (though could maybe do with crypto eyeballs on it as there may have=20 > been relevant new results since 2010) but future-proofing would=20 > suggest moving to HMAC-SHA256 if we can. (I can imagine such a change=20 > might require a new document, but am asking anyway:-) >=20 > GIM>> The fact is that we're bound by what is defined in RFC 5880. I wonder for how long though, that's now a five year old RFC. Assuming it takes a few years for new deployments to pick up new algorithms= , isn't it time that a whole bunch of algorithm choices were revisited? > There was a proposal to strengthen BFD security BFD Generic=20 > Cryptographic Authentication but the document had expired. Pity that. > - 2.1.1, I'd recommend saying any password auth-type MUST NOT be used - w= ould that be possible? >=20 > GIM>> I think that we=1B$B!G=1B(Bll need to make changes to RFC 5880 firs= t (5880bis?).=20 I don't see any reason why that is true. This document can easily say "you = MUST NOT use the horribly weak option specified in that old RFC" with chang= ing that old RFC. The point? It may be sacrificing security for sake of performance may be no= t the better choice. I can rationalize such choice for BFD over LSP, micro-= BFD as these effectively monitor not Layer 3 but Layer 2.5 and Layer 2 enti= ties respectively. I would not support such choice for multi-hop BFD. Singl= e-hop BFD? Open for discussion. Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Dacheng Zhang Sent: Monday, November 23, 2015 10:26 PM To: Marc Binderberger; Reshad Rahman (rrahman); draft-mahesh-bfd-authentica= tion@ietf.org Cc: rtg-bfd@ietf.org Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication Hi=1B$B!$=1B(BI think this is an interesting draft. It is quite common that= we have make a trade off between performance and security. Support for the= adoption. ^_^ Some comments and questions: 1) discuss which types of frames MUST be authenticated and which ones SHOUL= D be authentication. 2) There is a discussion about how the sequence number should be increased = in RFC5880, maybe you could follow that one and so avoid any unnecessary co= nfusion. 3) Q: since in this solution, only a small number of frames need to be auth= enticated, maybe we could consider again to use SHA-2 since the influence i= n the performance brought by the strong algorithms will no longer be that s= erious. 4) Q: do you plan to propose a negotiation mechanism for the peers to decid= e the frames which should be authenticated? If not, please clarify this par= t of work is out of scope. Cheers Dacheng =1B$B:_=1B(B 15-11-21 =1B$B2<8a=1B(B6:29=1B$B!$=1B(B "Rtg-bfd on behalf of = Marc Binderberger" =1B$BHello Reshad and authors (and BFD experts on the list), > >it's a smart idea so I support the WG support ;-) > >But reading the document: it's at this point mainly outlining an idea=20 >and I would expect more details to allow for interoperable=20 >implementations. > > >Regards, Marc > > > > > >On Fri, 20 Nov 2015 12:03:25 +0000, Reshad Rahman (rrahman) wrote: >> BFD WG members, >>=20 >> Please indicate to the WG mailing list whether you would support or=20 >> not support BFD WG adoption of the following document. >>=20 >> https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ >>=20 >> Authors, as was mentioned at IETF94, you should get your proposal=20 >>reviewed by the security group. >>=20 >> Regards, >> Jeff & Reshad. From nobody Mon Nov 23 23:12:40 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311651A015D; Mon, 23 Nov 2015 23:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.249 X-Spam-Level: X-Spam-Status: No, score=-0.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8Vxn_VV74Dy; Mon, 23 Nov 2015 23:12:34 -0800 (PST) Received: from out4133-2.mail.aliyun.com (out4133-2.mail.aliyun.com [42.120.133.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0DA1A0155; Mon, 23 Nov 2015 23:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1448349151; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=g6HD0WyIZwG6yRJzMJRP7k/PMOMaeDrnjysXmQaOcNA=; b=mflGyKLzZOwPgoAEvlT2ewDu+vXBXgxwCyxkmzRNXAzTATrlWQFhQfTC+NsFWyZeKsdB2dZ76tTTpAUqU6eIDBitNQ26s3lSS0HaNU/xHi19LPyxDOjqqtYgyJqmf73pwCqu8QGpVJXzJED3/q3g5lZZpF2W8jZGpHV37TzIpLw= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R781e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03283; MF=dacheng.zdc@alibaba-inc.com; NM=1; PH=DS; RN=6; SR=0; TI=SMTPD_----4FNmK30; Received: from 10.62.54.19(mailfrom:dacheng.zdc@alibaba-inc.com ip:182.92.253.23) by smtp.aliyun-inc.com(127.0.0.1); Tue, 24 Nov 2015 15:12:24 +0800 User-Agent: Microsoft-MacOutlook/14.5.7.151005 Date: Tue, 24 Nov 2015 15:12:18 +0800 Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication From: "Dacheng Zhang" To: Gregory Mirsky , Marc Binderberger , "Reshad Rahman (rrahman)" , "draft-mahesh-bfd-authentication@ietf.org" , Stephen Farrell Message-ID: Thread-Topic: Request for WG adoption of draft-mahesh-bfd-authentication References: <20151121022956672568.a3e4948f@sniff.de> <7347100B5761DC41A166AC17F22DF11221947B4A@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221947B4A@eusaamb103.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 07:12:38 -0000 =D4=DA 15-11-24 =CF=C2=CE=E72:46=A3=AC "Gregory Mirsky" =D0=B4=C8=EB: >Dear All, >I'd like to share comment by Security AD Stephen Farrell on a work that >is directly related to BFD, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf >(hope it is OK to raise security awareness in BFD community): > >> - 2.1.1, is there any chance of moving on from the "Keyed SHA1" >>=20 >> from RFC5880 to e.g. HMAC-SHA256 for this? We're generally trying to >> get that kind of transition done as we can and moving to use of a >> standard integrity check rather than a more home-grown one has some >> benefits. The HMAC-SHA1-like thing you're doing is still probably ok, >> (though could maybe do with crypto eyeballs on it as there may have >> been relevant new results since 2010) but future-proofing would >> suggest moving to HMAC-SHA256 if we can. (I can imagine such a change >> might require a new document, but am asking anyway:-) >>=20 >> GIM>> The fact is that we're bound by what is defined in RFC 5880. > >I wonder for how long though, that's now a five year old RFC. >Assuming it takes a few years for new deployments to pick up new >algorithms, isn't it time that a whole bunch of algorithm choices were >revisited? > >> There was a proposal to strengthen BFD security BFD Generic >> Cryptographic =20 >>Authentication>> but the document had expired. > >Pity that. I am one of the co-author of that draft. We didn=A1=AFt try to update document because we got the feedback from the group that the influence on the performance is a big concern. That is why I raised the question in the last email whether it is a good time for us to re-consider the usage of aha-2 in BFD. > From nobody Tue Nov 24 17:33:16 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A7A1ACD11; Tue, 24 Nov 2015 17:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afIWCHg1EuCi; Tue, 24 Nov 2015 17:33:11 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8B61ACD0D; Tue, 24 Nov 2015 17:33:11 -0800 (PST) X-AuditID: c618062d-f799d6d000000ec2-26-5654bdf91aa8 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 12.A9.03778.9FDB4565; Tue, 24 Nov 2015 20:43:53 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Tue, 24 Nov 2015 20:33:10 -0500 From: Gregory Mirsky To: Dacheng Zhang , Marc Binderberger , "Reshad Rahman (rrahman)" , "draft-mahesh-bfd-authentication@ietf.org" , Stephen Farrell Subject: RE: Request for WG adoption of draft-mahesh-bfd-authentication Thread-Topic: Request for WG adoption of draft-mahesh-bfd-authentication Thread-Index: AQHRI4t1BhxwWi4DrkqzzQbDKMhgLp6mm9wAgARy5ID//66DQIAAXl8AgADfazA= Date: Wed, 25 Nov 2015 01:33:09 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1122194890E@eusaamb103.ericsson.se> References: <20151121022956672568.a3e4948f@sniff.de> <7347100B5761DC41A166AC17F22DF11221947B4A@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyuXRPoO7PvSFhBvuWqFpMfn6W0eJG3wx2 i9lX/jNbXFvRym7x+c82Rovpe6+xO7B5THz7kcVjyu+NrB5ru6+yeSxZ8pPJo3V1N0sAaxSX TUpqTmZZapG+XQJXxupDX9kKNghVvPv9h7GBsYW/i5GTQ0LAROLy1elsELaYxIV764FsLg4h gSOMEju+TGeBcJYzSnT9nMkCUsUmYCTxYmMPO4gtItDPJDH9lTuIzSygKdF04jNYXFjAXeLZ j61QNR4SxzYvYYOw/SQ2te1h7GLk4GARUJW4dl8EJMwr4CsxYeknVohdfxgl1u+dzAqS4BSw lDi36zfYXkag676fWsMEsUtc4taT+UwQVwtILNlznhnCFpV4+fgfK4StKLGvfzo7RL2+xJ6J p1ggbG2JZQtfM0MsFpQ4OfMJywRGsVlIxs5C0jILScssJC0LGFlWMXKUFqeW5aYbGWxiBEbb MQk23R2Me15aHmIU4GBU4uHdsDkkTIg1say4MvcQowQHs5IIr+Q7oBBvSmJlVWpRfnxRaU5q 8SFGaQ4WJXHe/UvuhwoJpCeWpGanphakFsFkmTg4pRoYhW/3twu3uvLlHmAvbHm5ad+abfs/ 8aS+5qyv3yUm9MSl5Vj1pMZVfLG/4lJlk1qff/DoPZH6YIWnaSSriYmpVYfVZfnr07rkRa9w HDy8vHLJ7bYsoxm94jLrfVddvLv8B+/lv22ZHCp7kt97Fv7RkD+Rc2nHxf7/vYwbfCZ7nK6K tz+tu+S1EktxRqKhFnNRcSIA2e2LLbICAAA= Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 01:33:13 -0000 Hi Dacheng, HW became more capable and we, one hopes, wiser. Perhaps it's time to re-vi= sit our options. Regards, Greg -----Original Message----- From: Dacheng Zhang [mailto:dacheng.zdc@alibaba-inc.com]=20 Sent: Monday, November 23, 2015 11:12 PM To: Gregory Mirsky; Marc Binderberger; Reshad Rahman (rrahman); draft-mahes= h-bfd-authentication@ietf.org; Stephen Farrell Cc: rtg-bfd@ietf.org Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication =1B$B:_=1B(B 15-11-24 =1B$B2<8a=1B(B2:46=1B$B!$=1B(B "Gregory Mirsky" =1B$BDear All, >I'd like to share comment by Security AD Stephen Farrell on a work that=20 >is directly related to BFD, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf >(hope it is OK to raise security awareness in BFD community): > >> - 2.1.1, is there any chance of moving on from the "Keyed SHA1" >>=20 >> from RFC5880 to e.g. HMAC-SHA256 for this? We're generally trying to=20 >> get that kind of transition done as we can and moving to use of a=20 >> standard integrity check rather than a more home-grown one has some=20 >> benefits. The HMAC-SHA1-like thing you're doing is still probably ok,=20 >> (though could maybe do with crypto eyeballs on it as there may have=20 >> been relevant new results since 2010) but future-proofing would=20 >> suggest moving to HMAC-SHA256 if we can. (I can imagine such a change=20 >> might require a new document, but am asking anyway:-) >>=20 >> GIM>> The fact is that we're bound by what is defined in RFC 5880. > >I wonder for how long though, that's now a five year old RFC. >Assuming it takes a few years for new deployments to pick up new=20 >algorithms, isn't it time that a whole bunch of algorithm choices were=20 >revisited? > >> There was a proposal to strengthen BFD security BFD Generic =20 >>Cryptographic >>Authentication>-03 >>> but the document had expired. > >Pity that. I am one of the co-author of that draft. We didn=1B$B!G=1B(Bt try to update= document because we got the feedback from the group that the influence on = the performance is a big concern. That is why I raised the question in the = last email whether it is a good time for us to re-consider the usage of aha-2 in BFD. > From nobody Tue Nov 24 19:26:12 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E6D1ACE32; Tue, 24 Nov 2015 19:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDmaI-nO1eOJ; Tue, 24 Nov 2015 19:26:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2861AC3CC; Tue, 24 Nov 2015 19:26:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAT65557; Wed, 25 Nov 2015 03:26:04 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 25 Nov 2015 03:26:03 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.73]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Wed, 25 Nov 2015 11:26:00 +0800 From: Mach Chen To: "Reshad Rahman (rrahman)" , "rtg-bfd@ietf.org" , "draft-mahesh-bfd-authentication@ietf.org" Subject: RE: Request for WG adoption of draft-mahesh-bfd-authentication Thread-Topic: Request for WG adoption of draft-mahesh-bfd-authentication Thread-Index: AQHRI4t1BhxwWi4DrkqzzQbDKMhgLp6sGpYw Date: Wed, 25 Nov 2015 03:26:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B670473SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.56552A4C.0119, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.73, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ded1b7647bea6261f1c6ff29c03493e5 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 03:26:10 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B670473SZXEMA510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have read the document and think it's useful, so I support the adoption. Best regards, Mach From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Reshad Rahman = (rrahman) Sent: Friday, November 20, 2015 8:03 PM To: rtg-bfd@ietf.org; draft-mahesh-bfd-authentication@ietf.org Subject: Request for WG adoption of draft-mahesh-bfd-authentication BFD WG members, Please indicate to the WG mailing list whether you would support or not sup= port BFD WG adoption of the following document. https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ Authors, as was mentioned at IETF94, you should get your proposal reviewed = by the security group. Regards, Jeff & Reshad. --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B670473SZXEMA510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

I have rea= d the document and think it’s useful, so I support the adoption.=

 = ;

Best regar= ds,

Mach<= /o:p>

 = ;

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Reshad Rahman (rrahman)
Sent: Friday, November 20, 2015 8:03 PM
To: rtg-bfd@ietf.org; draft-mahesh-bfd-authentication@ietf.org
Subject: Request for WG adoption of draft-mahesh-bfd-authentication<= o:p>

 

BFD WG members,

 

Please indicate to the WG mailing list whether you would support or= not support BFD WG adoption of the following document.

 

 

Authors, as was mentioned at IETF94, you should get your proposal r= eviewed by the security group.

 

Regards,

Jeff & Reshad.

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B670473SZXEMA510MBXchi_-- From nobody Tue Nov 24 20:04:19 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262D11ACF24; Tue, 24 Nov 2015 20:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sCLpqxgcqOQ; Tue, 24 Nov 2015 20:04:16 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 3837C1ACF54; Tue, 24 Nov 2015 20:04:16 -0800 (PST) Received: by ykfs79 with SMTP id s79so43991680ykf.1; Tue, 24 Nov 2015 20:04:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hAr7OKPjKlpDwjCUEuC7P7bt+YbTuCI0AIurIrRa3Co=; b=EnVXOcFXbuPvsBwdNNv7S1U5zo1B0ooiJIStUi2gsJcy7DbETlB5697f3KU1SYoJOv 43Zb2FhTojAh1BmmCcTqTPV5VSVKm71h+rnMjT8T03zD59eeKLrnrxBic2XAvSZsVYVC mTEhvMpul9mE7F9hGrY21WI6a19orIh+8MILvojk1es5wS6a/ANyi7am/uIKrOx0efdP q9tpPZFuvtKpT3PgdAOX3Ll2jvPkH/hNASZbIRH1YDAFdMRL52VF2itdbj3w1pkHPU6z cN+8PGDY6rFOQ0asOwoT6Lxpmy4Qtv66b8an0YbZksEx09FxVSfUtInjLjdAfXhfjI7i rANw== MIME-Version: 1.0 X-Received: by 10.129.72.10 with SMTP id v10mr30360855ywa.87.1448424255552; Tue, 24 Nov 2015 20:04:15 -0800 (PST) Received: by 10.129.98.139 with HTTP; Tue, 24 Nov 2015 20:04:15 -0800 (PST) In-Reply-To: References: Date: Wed, 25 Nov 2015 09:34:15 +0530 Message-ID: Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication From: Manav Bhatia To: Mach Chen Content-Type: multipart/alternative; boundary=001a114dcd6a3c84ba0525558d18 Archived-At: Cc: "Reshad Rahman \(rrahman\)" , "draft-mahesh-bfd-authentication@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 04:04:18 -0000 --001a114dcd6a3c84ba0525558d18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I also read the document and concur with the opinion that its pretty nifty and immensely useful ! :-) Cheers, Manav On Wed, Nov 25, 2015 at 8:56 AM, Mach Chen wrote: > Hi, > > > > I have read the document and think it=E2=80=99s useful, so I support the = adoption. > > > > Best regards, > > Mach > > > > *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] *On Behalf Of *Reshad > Rahman (rrahman) > *Sent:* Friday, November 20, 2015 8:03 PM > *To:* rtg-bfd@ietf.org; draft-mahesh-bfd-authentication@ietf.org > *Subject:* Request for WG adoption of draft-mahesh-bfd-authentication > > > > BFD WG members, > > > > Please indicate to the WG mailing list whether you would support or not > support BFD WG adoption of the following document. > > > > https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ > > > > Authors, as was mentioned at IETF94, you should get your proposal reviewe= d > by the security group. > > > > Regards, > > Jeff & Reshad. > --001a114dcd6a3c84ba0525558d18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also read the document = and concur with the opinion that its pretty nifty and immensely useful !=C2= =A0

:-)=C2=A0

Cheers, Manav

On Wed, Nov 25, 2015 at= 8:56 AM, Mach Chen <mach.chen@huawei.com> wrote:

Hi,=

=C2= =A0

I have rea= d the document and think it=E2=80=99s useful, so I support the adoption.=

=C2= =A0

Best regar= ds,

Mach

=C2= =A0

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Reshad Rahman (rrahman)
Sent: Friday, November 20, 2015 8:03 PM
To: rtg-bfd@ie= tf.org; draft-mahesh-bfd-authentication@ietf.org
Subject: Request for WG adoption of draft-mahesh-bfd-authentication<= u>

=C2=A0

BFD WG members,

=C2=A0

Please indicate to the WG mailing list whether you would support or= not support BFD WG adoption of the following document.

=C2=A0

=C2=A0

Authors, as was mentioned at IETF94, you should get your proposal r= eviewed by the security group.

=C2=A0

Regards,

Jeff & Reshad.


--001a114dcd6a3c84ba0525558d18-- From nobody Tue Nov 24 20:42:19 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18881AD277; Tue, 24 Nov 2015 20:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.085 X-Spam-Level: X-Spam-Status: No, score=-15.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98Ovb54O7B_y; Tue, 24 Nov 2015 20:42:15 -0800 (PST) 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 B142B1AD2DF; Tue, 24 Nov 2015 20:42:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5801; q=dns/txt; s=iport; t=1448426535; x=1449636135; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ZYfDfJ6QoNOEdd+Q2p7a+SqrgEhYrhMiTykQt3ibbjQ=; b=msXG+65POqsvbjSD0N5XAZ8aJZ+zCSN+IS59XzD9jCmehXPdGx2OZdZU GrhX0tpVzYHVApI6z23RMJU3aXnhzaCuiMG5t6uUaMsedBl2PmebwWuHb pRT7N0OPhc3NglTSyBEsSqJh04W9beMKjLo4/NqBUcJEtrnCj4mm8+u0n I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQAEO1VW/4cNJK1egm5NU28GvkABD?= =?us-ascii?q?YFnIYVuAoFJOBQBAQEBAQEBgQqENAEBAQRuGwIBCBEDAQIoBzIUCQgCBAESiC4?= =?us-ascii?q?NvVoBAQEBAQEBAQEBAQEBAQEBAQEXBIZUhH6Eew2EMQWNWoh7AYUkiA2BW4RBg?= =?us-ascii?q?yaGEYkTg3EBHwEBQoQEcoQlgQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,341,1444694400"; d="scan'208,217";a="211346011" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Nov 2015 04:42:13 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tAP4gDrZ001454 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 Nov 2015 04:42:13 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 24 Nov 2015 22:42:12 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.000; Tue, 24 Nov 2015 22:42:12 -0600 From: "Rajeev G Nair (rajeenai)" To: "Reshad Rahman (rrahman)" , "rtg-bfd@ietf.org" , "draft-mahesh-bfd-authentication@ietf.org" Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication Thread-Topic: Request for WG adoption of draft-mahesh-bfd-authentication Thread-Index: AQHRI4t1BhxwWi4DrkqzzQbDKMhgLp6sDquA Date: Wed, 25 Nov 2015 04:42:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.19.236] Content-Type: multipart/alternative; boundary="_000_D27A74CD10520Crajeenaiciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 04:42:18 -0000 --_000_D27A74CD10520Crajeenaiciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jeff & Reshad, Read through the document. Interesting concept. Here is my understanding:- 1) Current scheme. Both switches are configured to use same auth. Currentl= y, no packets will be accepted unless all received pkts match with configur= ed auth. 2) Proposal is to come up with a scheme to authenticate only a subset of p= ackets (those signaling a state change as mentioned). Questions:- Q1) Doesn't acceptance of non-auth packets dictates state of the session (e= .g. Keep it still up UP) ? Q2) These non-auth packets are not protected from MiM attacks, right? Q3) Doesn't mixing authenticated & non-authenticated packed make proposed s= cheme equivalent to non-authenticated mode ? I mean, unless every packet is= authenticated, isn't benefit of bfd-auth nullified ? thanks ~Rajeev From: Rtg-bfd > o= n behalf of "Reshad Rahman (rrahman)" > Date: Friday, November 20, 2015 at 4:03 AM To: "rtg-bfd@ietf.org" >, "draft-mahesh-bfd-authentication@ietf.org" > Subject: Request for WG adoption of draft-mahesh-bfd-authentication BFD WG members, Please indicate to the WG mailing list whether you would support or not sup= port BFD WG adoption of the following document. https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ Authors, as was mentioned at IETF94, you should get your proposal reviewed = by the security group. Regards, Jeff & Reshad. --_000_D27A74CD10520Crajeenaiciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <878D1AD0228EA544A1E5382F37FA15E3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Jeff & Reshad, 

 Read through the document. Interesting concept.

Here is my understanding:-
 1) Current scheme. Both switches are configured to use same auth= . Currently, no packets will be accepted unless all received pkts match wit= h configured auth.
 2) Proposal is to come up with a scheme to authenticate only a s= ubset of packets (those signaling a state change as mentioned). 

Questions:-
Q1) Doesn't acceptance of non-auth packets dictates state of the sessi= on (e.g. Keep it still up UP) ?

Q2) These non-auth packets are not protected from MiM attacks, right?<= /div>

Q3) Doesn’t mixing authenticated & non-authenticated packed = make proposed scheme equivalent to non-authenticated mode ? I mean, unless = every packet is authenticated, isn’t benefit of bfd-auth nullified ?&= nbsp;


thanks
~Rajeev

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of &q= uot;Reshad Rahman (rrahman)" <= rrahman@cisco.com>
Date: Friday, November 20, 2015 at = 4:03 AM
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-mahesh-bfd-authentication@ietf.org" <draft-mahe= sh-bfd-authentication@ietf.org>
Subject: Request for WG adoption of= draft-mahesh-bfd-authentication

BFD WG members,

Please indicate to the WG mailing list whether you would support or no= t support BFD WG adoption of the following document.


Authors, as was mentioned at IETF94, you should get your proposal revi= ewed by the security group.

Regards,
Jeff & Reshad.
 --_000_D27A74CD10520Crajeenaiciscocom_-- From nobody Tue Nov 24 21:57:56 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2121B2A21; Tue, 24 Nov 2015 21:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.249 X-Spam-Level: X-Spam-Status: No, score=-0.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjKN2kR2t5JB; Tue, 24 Nov 2015 21:57:53 -0800 (PST) Received: from out4133-2.mail.aliyun.com (out4133-2.mail.aliyun.com [42.120.133.2]) by ietfa.amsl.com (Postfix) with ESMTP id B4EF71B2A20; Tue, 24 Nov 2015 21:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1448431069; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=JH/U0xiX9mQLcGBZMAysxmLOuif4Ma8Yy3b/VQ4aXNI=; b=EbrWbH+Gh4zQJvj87LLt3pi3hN343KteG+rf0nLTNfQ5ohlEELKIEPMSEuu9es93wZKK78OgLcTLrEh4+0bay2auGnBByttM09nufFFIih3Ub+M2gpr/wehfAdUM5PxEzgVd0bShr0+iDPWk8d2hi62WIg5N8AEI8C16Kpp1z48= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R241e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03308; MF=dacheng.zdc@alibaba-inc.com; NM=1; PH=DS; RN=8; SR=0; TI=SMTPD_----4FzUCcE; Received: from 30.9.190.8(mailfrom:dacheng.zdc@alibaba-inc.com ip:42.120.74.186) by smtp.aliyun-inc.com(127.0.0.1); Wed, 25 Nov 2015 13:57:42 +0800 User-Agent: Microsoft-MacOutlook/14.5.7.151005 Date: Wed, 25 Nov 2015 13:57:36 +0800 Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication From: "Dacheng Zhang" To: Gregory Mirsky , Marc Binderberger , "Reshad Rahman (rrahman)" , "draft-mahesh-bfd-authentication@ietf.org" , Stephen Farrell Message-ID: Thread-Topic: Request for WG adoption of draft-mahesh-bfd-authentication References: <20151121022956672568.a3e4948f@sniff.de> <7347100B5761DC41A166AC17F22DF11221947B4A@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1122194890E@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1122194890E@eusaamb103.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Cc: "rtg-bfd@ietf.org" , Manav Bhatia X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 05:57:55 -0000 Great! Let us update that draft and discuss it in the next IETF meeting. ^_^ Cheers Dacheng =D4=DA 15-11-25 =C9=CF=CE=E79:33=A3=AC "Gregory Mirsky" =D0=B4=C8=EB: >Hi Dacheng, >HW became more capable and we, one hopes, wiser. Perhaps it's time to >re-visit our options. > > Regards, > Greg > >-----Original Message----- >From: Dacheng Zhang [mailto:dacheng.zdc@alibaba-inc.com] >Sent: Monday, November 23, 2015 11:12 PM >To: Gregory Mirsky; Marc Binderberger; Reshad Rahman (rrahman); >draft-mahesh-bfd-authentication@ietf.org; Stephen Farrell >Cc: rtg-bfd@ietf.org >Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication > > > >=D4=DA 15-11-24 =CF=C2=CE=E72:46=A3=AC "Gregory Mirsky" =D0=B4=C8=EB= : > >>Dear All, >>I'd like to share comment by Security AD Stephen Farrell on a work that >>is directly related to BFD, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf >>(hope it is OK to raise security awareness in BFD community): >> >>> - 2.1.1, is there any chance of moving on from the "Keyed SHA1" >>>=20 >>> from RFC5880 to e.g. HMAC-SHA256 for this? We're generally trying to >>> get that kind of transition done as we can and moving to use of a >>> standard integrity check rather than a more home-grown one has some >>> benefits. The HMAC-SHA1-like thing you're doing is still probably ok, >>> (though could maybe do with crypto eyeballs on it as there may have >>> been relevant new results since 2010) but future-proofing would >>> suggest moving to HMAC-SHA256 if we can. (I can imagine such a change >>> might require a new document, but am asking anyway:-) >>>=20 >>> GIM>> The fact is that we're bound by what is defined in RFC 5880. >> >>I wonder for how long though, that's now a five year old RFC. >>Assuming it takes a few years for new deployments to pick up new >>algorithms, isn't it time that a whole bunch of algorithm choices were >>revisited? >> >>> There was a proposal to strengthen BFD security BFD Generic >>>Cryptographic >>>Authentication>>-03 >>>> but the document had expired. >> >>Pity that. > >I am one of the co-author of that draft. We didn=A1=AFt try to update document >because we got the feedback from the group that the influence on the >performance is a big concern. That is why I raised the question in the >last email whether it is a good time for us to re-consider the usage of >aha-2 in BFD. >> > From nobody Tue Nov 24 23:22:46 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089C11A0027; Tue, 24 Nov 2015 23:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3z_x7r0cqMLi; Tue, 24 Nov 2015 23:22:42 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5117C1A0025; Tue, 24 Nov 2015 23:22:42 -0800 (PST) Received: from [192.168.1.9] (unknown [49.149.184.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 4AD15180155B; Wed, 25 Nov 2015 08:22:36 +0100 (CET) Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication To: Dacheng Zhang , Gregory Mirsky , Marc Binderberger , "Reshad Rahman (rrahman)" , "draft-mahesh-bfd-authentication@ietf.org" , Stephen Farrell References: <20151121022956672568.a3e4948f@sniff.de> <7347100B5761DC41A166AC17F22DF11221947B4A@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1122194890E@eusaamb103.ericsson.se> From: Loa Andersson Message-ID: <565561B6.8010207@pi.nu> Date: Wed, 25 Nov 2015 15:22:30 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtg-bfd@ietf.org" , Manav Bhatia X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 07:22:45 -0000 Dacheng, Maybe do it the IETF way - discuss on the mailing list how it should be updated, when we have consesnsus - update draft, and then see if there is anything that we need to take up time to do at the f2f meeting :) ! /Loa On 2015-11-25 13:57, Dacheng Zhang wrote: > Great! Let us update that draft and discuss it in the next IETF meeting. > ^_^ > > Cheers > > Dacheng > > ÔÚ 15-11-25 ÉÏÎç9:33£¬ "Gregory Mirsky" дÈë: > >> Hi Dacheng, >> HW became more capable and we, one hopes, wiser. Perhaps it's time to >> re-visit our options. >> >> Regards, >> Greg >> >> -----Original Message----- >> From: Dacheng Zhang [mailto:dacheng.zdc@alibaba-inc.com] >> Sent: Monday, November 23, 2015 11:12 PM >> To: Gregory Mirsky; Marc Binderberger; Reshad Rahman (rrahman); >> draft-mahesh-bfd-authentication@ietf.org; Stephen Farrell >> Cc: rtg-bfd@ietf.org >> Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication >> >> >> >> ÔÚ 15-11-24 ÏÂÎç2:46£¬ "Gregory Mirsky" дÈë: >> >>> Dear All, >>> I'd like to share comment by Security AD Stephen Farrell on a work that >>> is directly related to BFD, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf >>> (hope it is OK to raise security awareness in BFD community): >>> >>>> - 2.1.1, is there any chance of moving on from the "Keyed SHA1" >>>> >>>> from RFC5880 to e.g. HMAC-SHA256 for this? We're generally trying to >>>> get that kind of transition done as we can and moving to use of a >>>> standard integrity check rather than a more home-grown one has some >>>> benefits. The HMAC-SHA1-like thing you're doing is still probably ok, >>>> (though could maybe do with crypto eyeballs on it as there may have >>>> been relevant new results since 2010) but future-proofing would >>>> suggest moving to HMAC-SHA256 if we can. (I can imagine such a change >>>> might require a new document, but am asking anyway:-) >>>> >>>> GIM>> The fact is that we're bound by what is defined in RFC 5880. >>> >>> I wonder for how long though, that's now a five year old RFC. >>> Assuming it takes a few years for new deployments to pick up new >>> algorithms, isn't it time that a whole bunch of algorithm choices were >>> revisited? >>> >>>> There was a proposal to strengthen BFD security BFD Generic >>>> Cryptographic >>>> Authentication>>> -03 >>>>> but the document had expired. >>> >>> Pity that. >> >> I am one of the co-author of that draft. We didn¡¯t try to update document >> because we got the feedback from the group that the influence on the >> performance is a big concern. That is why I raised the question in the >> last email whether it is a good time for us to re-consider the usage of >> aha-2 in BFD. >>> >> > > From nobody Wed Nov 25 00:01:37 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3081A01A8; Wed, 25 Nov 2015 00:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.249 X-Spam-Level: X-Spam-Status: No, score=-0.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-iyUf7wYZBO; Wed, 25 Nov 2015 00:01:32 -0800 (PST) Received: from out4133-98.mail.aliyun.com (out4133-98.mail.aliyun.com [42.120.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 65B281A01A5; Wed, 25 Nov 2015 00:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1448438490; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=zeKFVJv+/GSyN3TbDQvXHFWuzkk6HWBBKNTIXEkl0sU=; b=AYMjJ2xgogNJVLc59GFL9NGRxRJVUEOpxwPupZf4ZflVU/4xYBp80SQxwXCwPMMr1FU+7W2VUnuwtKEbt1z4tAF1kYILfxQp33HcHXgsp2JHUNPjZPx/5faIuoX7oaIx/t/esuxrrJ68e7IHCj0DjMTW914beT37L+by5W2CbZs= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R971e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03312; MF=dacheng.zdc@alibaba-inc.com; NM=1; PH=DS; RN=8; SR=0; TI=SMTPD_----4GK--IR; Received: from 30.9.190.8(mailfrom:dacheng.zdc@alibaba-inc.com ip:42.120.74.180) by smtp.aliyun-inc.com(127.0.0.1); Wed, 25 Nov 2015 16:01:24 +0800 User-Agent: Microsoft-MacOutlook/14.5.7.151005 Date: Wed, 25 Nov 2015 16:01:20 +0800 Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication From: "Dacheng Zhang" To: Loa Andersson , Gregory Mirsky , Marc Binderberger , "Reshad Rahman (rrahman)" , "draft-mahesh-bfd-authentication@ietf.org" , Stephen Farrell Message-ID: Thread-Topic: Request for WG adoption of draft-mahesh-bfd-authentication References: <20151121022956672568.a3e4948f@sniff.de> <7347100B5761DC41A166AC17F22DF11221947B4A@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1122194890E@eusaamb103.ericsson.se> <565561B6.8010207@pi.nu> In-Reply-To: <565561B6.8010207@pi.nu> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Cc: "rtg-bfd@ietf.org" , Manav Bhatia X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 08:01:34 -0000 Hi, Loa: Thank you for the comments. No problem. Actually, there are two drafts for strengthening BFD security: https://tools.ietf.org/html/draft-ietf-bfd-generic-crypto-auth-06, which specify a generic authentication mechanism for BFD. https://tools.ietf.org/html/draft-ietf-bfd-hmac-sha-05, which discusses how to support SHA2 based on the generic authentication extension. The first draft has been adopted as a WG draft. So, it would be great for the group to review it again and let us know if you have any comments. Cheers Dacheng =D4=DA 15-11-25 =CF=C2=CE=E73:22=A3=AC "Loa Andersson" =D0=B4=C8=EB: >Dacheng, > >Maybe do it the IETF way - discuss on the mailing list how it should >be updated, when we have consesnsus - update draft, and then see if >there is anything that we need to take up time to do at the f2f >meeting :) ! > >/Loa > >On 2015-11-25 13:57, Dacheng Zhang wrote: >> Great! Let us update that draft and discuss it in the next IETF meeting. >> ^_^ >> >> Cheers >> >> Dacheng >> >> =D4=DA 15-11-25 =C9=CF=CE=E79:33=A3=AC "Gregory Mirsky" =D0=B4= =C8=EB: >> >>> Hi Dacheng, >>> HW became more capable and we, one hopes, wiser. Perhaps it's time to >>> re-visit our options. >>> >>> Regards, >>> Greg >>> >>> -----Original Message----- >>> From: Dacheng Zhang [mailto:dacheng.zdc@alibaba-inc.com] >>> Sent: Monday, November 23, 2015 11:12 PM >>> To: Gregory Mirsky; Marc Binderberger; Reshad Rahman (rrahman); >>> draft-mahesh-bfd-authentication@ietf.org; Stephen Farrell >>> Cc: rtg-bfd@ietf.org >>> Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication >>> >>> >>> >>> =D4=DA 15-11-24 =CF=C2=CE=E72:46=A3=AC "Gregory Mirsky" =D0= =B4=C8=EB: >>> >>>> Dear All, >>>> I'd like to share comment by Security AD Stephen Farrell on a work >>>>that >>>> is directly related to BFD, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf >>>> (hope it is OK to raise security awareness in BFD community): >>>> >>>>> - 2.1.1, is there any chance of moving on from the "Keyed SHA1" >>>>> >>>>> from RFC5880 to e.g. HMAC-SHA256 for this? We're generally trying to >>>>> get that kind of transition done as we can and moving to use of a >>>>> standard integrity check rather than a more home-grown one has some >>>>> benefits. The HMAC-SHA1-like thing you're doing is still probably ok, >>>>> (though could maybe do with crypto eyeballs on it as there may have >>>>> been relevant new results since 2010) but future-proofing would >>>>> suggest moving to HMAC-SHA256 if we can. (I can imagine such a change >>>>> might require a new document, but am asking anyway:-) >>>>> >>>>> GIM>> The fact is that we're bound by what is defined in RFC 5880. >>>> >>>> I wonder for how long though, that's now a five year old RFC. >>>> Assuming it takes a few years for new deployments to pick up new >>>> algorithms, isn't it time that a whole bunch of algorithm choices were >>>> revisited? >>>> >>>>> There was a proposal to strengthen BFD security BFD Generic >>>>> Cryptographic >>>>>=20 >>>>>Authentication>>>> -03 >>>>>> but the document had expired. >>>> >>>> Pity that. >>> >>> I am one of the co-author of that draft. We didn=A1=AFt try to update >>>document >>> because we got the feedback from the group that the influence on the >>> performance is a big concern. That is why I raised the question in the >>> last email whether it is a good time for us to re-consider the usage of >>> aha-2 in BFD. >>>> >>> >> >> From nobody Wed Nov 25 03:00:15 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7DC1ACF0A for ; Tue, 24 Nov 2015 20:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDygY3vfdCDi for ; Tue, 24 Nov 2015 20:00:54 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988FC1ACF08 for ; Tue, 24 Nov 2015 20:00:54 -0800 (PST) Received: by vkfr145 with SMTP id r145so27096344vkf.0 for ; Tue, 24 Nov 2015 20:00:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ionosnetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c74J4doykiDn6s+GUU04lqhgQpl1E3FzZz0A7wilO4c=; b=i/7eoFP++87PJtsS+WFntf5vkRSth8pVGBy4sXydUTfUiT8JehGnFHgyh9jZvSJgDQ GeYeBLc7w8QSytsWw2bBIzwEQHad7kYfJT0TUSeamF+YECHRTFRpWg5+floaxF+dBI4k 4QyvXIQ++1uvPxz7MpqslBSqH35zIXRMk7ieKbWKR5ZO+afFRstMlx1qjv/BQoyhDwpz uXjyAvkZDeTWk827tQat5CcZFywmtJFAF9CrysQvCMI7zBZfJ5coRxR7TpomTbhFzn4H haCYbknHvWYKWsZmyIEzgqt+c5/1zQ2oWmIxIpCLDzJgkXMqHW6/ldu3vnJvOLmLzG1s ByfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=c74J4doykiDn6s+GUU04lqhgQpl1E3FzZz0A7wilO4c=; b=JllPCv8nS4PIBM1s27dt9PXlOm/mHLHHW1nHJjf+6PGZuFKTeI5cP+5Vr0Qsi8kFas 0fDuHzp2MzNaAtxZKcrUOYwaNdF8p3PbU1jr/5eWljdbDeRlkEwzYZ0vXVP+WjsVsKPw zHZQmy4aScwV1WtY3iosNlSdLJMFvEYJhMLu/Oi3fxkm8Jq0gMfZurcD1ZMXDBHKd6TL fuiiUWAGD4wdCHyqih0T+6ue4Bs/7ryNMj6K2hZcM2UCVB0eqFEIFfYdqwNhwQl/6E+0 36aUq2G7NcO52Rz1BghNQ9eWisqtiRwx4M0/OOLIfKiQJ+qcxksy+E/mf5nvxnIDDtko IrRA== X-Gm-Message-State: ALoCoQmRXW14voumipcRUIANmPhj9swHGj1NG2oaUnm4Y+dFWKpeyS0ZULs3eXOyoEf6l9U5QCLN MIME-Version: 1.0 X-Received: by 10.31.181.13 with SMTP id e13mr29882087vkf.39.1448424053756; Tue, 24 Nov 2015 20:00:53 -0800 (PST) Received: by 10.31.138.141 with HTTP; Tue, 24 Nov 2015 20:00:53 -0800 (PST) In-Reply-To: References: Date: Wed, 25 Nov 2015 09:30:53 +0530 Message-ID: Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication From: Manav Bhatia To: Mach Chen Content-Type: multipart/alternative; boundary=001a11439c6a356a200525558160 Archived-At: X-Mailman-Approved-At: Wed, 25 Nov 2015 03:00:05 -0800 Cc: "Reshad Rahman \(rrahman\)" , "draft-mahesh-bfd-authentication@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 04:00:56 -0000 --001a11439c6a356a200525558160 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I also read the document and concur with the opinion that its pretty nifty and immensely useful ! :-) Cheers, Manav On Wed, Nov 25, 2015 at 8:56 AM, Mach Chen wrote: > Hi, > > > > I have read the document and think it=E2=80=99s useful, so I support the = adoption. > > > > Best regards, > > Mach > > > > *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] *On Behalf Of *Reshad > Rahman (rrahman) > *Sent:* Friday, November 20, 2015 8:03 PM > *To:* rtg-bfd@ietf.org; draft-mahesh-bfd-authentication@ietf.org > *Subject:* Request for WG adoption of draft-mahesh-bfd-authentication > > > > BFD WG members, > > > > Please indicate to the WG mailing list whether you would support or not > support BFD WG adoption of the following document. > > > > https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ > > > > Authors, as was mentioned at IETF94, you should get your proposal reviewe= d > by the security group. > > > > Regards, > > Jeff & Reshad. > --001a11439c6a356a200525558160 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also read the document and concur with the opinion that = its pretty nifty and immensely useful !=C2=A0

:-)=C2=A0<= div>
Cheers, Manav

On Wed, Nov 25, 2015 at 8:56 AM, Mach Chen= <mach.chen@huawei.com> wrote:

Hi,=

=C2= =A0

I have rea= d the document and think it=E2=80=99s useful, so I support the adoption.=

=C2= =A0

Best regar= ds,

Mach

=C2= =A0

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Reshad Rahman (rrahman)
Sent: Friday, November 20, 2015 8:03 PM
To: rtg-bfd@ie= tf.org; draft-mahesh-bfd-authentication@ietf.org
Subject: Request for WG adoption of draft-mahesh-bfd-authentication<= u>

=C2=A0

BFD WG members,

=C2=A0

Please indicate to the WG mailing list whether you would support or= not support BFD WG adoption of the following document.

=C2=A0

=C2=A0

Authors, as was mentioned at IETF94, you should get your proposal r= eviewed by the security group.

=C2=A0

Regards,

Jeff & Reshad.


--001a11439c6a356a200525558160-- From nobody Wed Nov 25 03:48:47 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449EE1B2BCA; Wed, 25 Nov 2015 03:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTF6NqgCL7Vm; Wed, 25 Nov 2015 03:48:44 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829311B2BC9; Wed, 25 Nov 2015 03:48:41 -0800 (PST) Received: from SN1PR0501MB2142.namprd05.prod.outlook.com (10.163.228.157) by SN1PR0501MB2142.namprd05.prod.outlook.com (10.163.228.157) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 25 Nov 2015 11:48:38 +0000 Received: from SN1PR0501MB2142.namprd05.prod.outlook.com ([10.163.228.157]) by SN1PR0501MB2142.namprd05.prod.outlook.com ([10.163.228.157]) with mapi id 15.01.0331.019; Wed, 25 Nov 2015 11:48:38 +0000 From: Santosh P K To: "Reshad Rahman (rrahman)" , "rtg-bfd@ietf.org" , "draft-mahesh-bfd-authentication@ietf.org" Subject: RE: Request for WG adoption of draft-mahesh-bfd-authentication Thread-Topic: Request for WG adoption of draft-mahesh-bfd-authentication Thread-Index: AQHRI4t1BhxwWi4DrkqzzQbDKMhgLp6spuig Date: Wed, 25 Nov 2015 11:48:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=santoshpk@juniper.net; x-originating-ip: [116.197.184.11] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB2142; 5:MyR6q4+Um0YGYn2U3u3lEd8NQKg9aGnlJmT9FMvZXOppy8ytfD2Mc5mQc6Tm91SfBYtis5AHkmzklCGCbghzCGvs53xlxoKqR9aNiUUO4D8art5wf/9dKe6kOWLmWEDLZZAuv2MRB3ZO/ZgsQD7Fvg==; 24:CqxDID8oyIhr+GN0va/M+fexm2L5JbrGypWHM+GuQ+vmmyjqk4Nw6lxBfi5lXAjbuRk23ZhfMxy0Zj/gmx4OnkfQ37QzdsyeRqxfe5a2+D4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB2142; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:SN1PR0501MB2142; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2142; x-forefront-prvs: 0771670921 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(199003)(76176999)(189998001)(19580395003)(3846002)(790700001)(19625215002)(33656002)(87936001)(106116001)(86362001)(15975445007)(2201001)(6116002)(5003600100002)(561944003)(101416001)(5001960100002)(2501003)(102836003)(19300405004)(586003)(5002640100001)(40100003)(5001770100001)(230783001)(107886002)(97736004)(106356001)(5004730100002)(11100500001)(74316001)(5008740100001)(2900100001)(19609705001)(19617315012)(54356999)(50986999)(76576001)(92566002)(16236675004)(5007970100001)(105586002)(19580405001)(66066001)(77096005)(2950100001)(122556002)(81156007)(99286002)(10400500002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2142; H:SN1PR0501MB2142.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0501MB2142F043907CF53DAFF65734B3050SN1PR0501MB2142_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2015 11:48:37.9377 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2142 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 11:48:46 -0000 --_000_SN1PR0501MB2142F043907CF53DAFF65734B3050SN1PR0501MB2142_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reshad, I have read this document and I do support this document. But I think the= re are few things to consider in this document. It needs to clearly highlig= ht how to handle interval change from non-aggressive interval to aggressive= interval. Thanks Santosh P K From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Reshad Rahman = (rrahman) Sent: Friday, November 20, 2015 5:33 PM To: rtg-bfd@ietf.org; draft-mahesh-bfd-authentication@ietf.org Subject: Request for WG adoption of draft-mahesh-bfd-authentication BFD WG members, Please indicate to the WG mailing list whether you would support or not sup= port BFD WG adoption of the following document. https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ Authors, as was mentioned at IETF94, you should get your proposal reviewed = by the security group. Regards, Jeff & Reshad. --_000_SN1PR0501MB2142F043907CF53DAFF65734B3050SN1PR0501MB2142_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reshad,

  I have read this document and = I do support this document. But I think there are few things to consider in= this document. It needs to clearly highlight how to handle interval change from non-aggressive interval to aggressive interval= .

 

Thanks

Santosh P K  <= /p>

 

From: Rtg-bfd [mailto:rtg-bfd-bounce= s@ietf.org] On Behalf Of Reshad Rahman (rrahman)
Sent: Friday, November 20, 2015 5:33 PM
To: rtg-bfd@ietf.org; draft-mahesh-bfd-authentication@ietf.org
Subject: Request for WG adoption of draft-mahesh-bfd-authentication<= o:p>

 

BFD WG = members,

&n= bsp;

Please = indicate to the WG mailing list whether you would support or not support BF= D WG adoption of the following document.

&n= bsp;

&n= bsp;

Authors= , as was mentioned at IETF94, you should get your proposal reviewed by the = security group.

&n= bsp;

Regards= ,

Jeff &a= mp; Reshad.

--_000_SN1PR0501MB2142F043907CF53DAFF65734B3050SN1PR0501MB2142_-- From nobody Wed Nov 25 09:35:05 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058EA1A6FEE; Wed, 25 Nov 2015 09:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxjuevjKJjlr; Wed, 25 Nov 2015 09:35:01 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7205E1A6FE2; Wed, 25 Nov 2015 09:35:01 -0800 (PST) Received: by obbww6 with SMTP id ww6so44244479obb.0; Wed, 25 Nov 2015 09:35:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=kv4Zz5Ps2nui6NKcsHc8QjLzEdVyW/STYzvERhJPq/M=; b=YfleYmtctw0z5GoKXg+TejcoObUBbJsPDmN4r5813vaHMwZptYb7GXRDuG1fDXY9YM Q/F+pfZYUHOSoVEeLFcAmyUIxZIh+xmhedTkqPv0nEBu7g0ZAtKwJD4nEOhfH0FLGGyO 8uaQh+X0d76wHPPnwDCuouxg5XnyvdNSruIOtNHHDRfPWJPKyxFf37iB/5umDgiZlF2G 8fpt5+jFTwxEZS7BkW3WSHmx06s83jqtOdq3MGH1qfql7SnZdaycvFjrXCrgVeDVP9U+ WjfDCxafHtgCiOYeFzWj1YpkncFpezE7SB1IjFTMmlmVtduuDwTVQ6a10P01pPUtYyYj 448Q== X-Received: by 10.182.213.7 with SMTP id no7mr11369933obc.22.1448472900813; Wed, 25 Nov 2015 09:35:00 -0800 (PST) Received: from mahesh-m-62at.attlocal.net ([2602:306:cf77:df90:58b1:d513:c0e5:2a1c]) by smtp.gmail.com with ESMTPSA id w84sm11027156oiw.22.2015.11.25.09.34.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 Nov 2015 09:34:59 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_901B0327-DB13-4981-8E24-582F12DC2840" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication From: Mahesh Jethanandani In-Reply-To: Date: Wed, 25 Nov 2015 09:34:56 -0800 Message-Id: References: To: "Rajeev G Nair (rajeenai)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "Reshad Rahman \(rrahman\)" , "draft-mahesh-bfd-authentication@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 17:35:04 -0000 --Apple-Mail=_901B0327-DB13-4981-8E24-582F12DC2840 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Rajeev, See comments inline. > On Nov 24, 2015, at 8:42 PM, Rajeev G Nair (rajeenai) = wrote: >=20 > Jeff & Reshad,=20 >=20 > Read through the document. Interesting concept. >=20 > Here is my understanding:- > 1) Current scheme. Both switches are configured to use same auth. = Currently, no packets will be accepted unless all received pkts match = with configured auth. > 2) Proposal is to come up with a scheme to authenticate only a subset = of packets (those signaling a state change as mentioned).=20 >=20 > Questions:- > Q1) Doesn't acceptance of non-auth packets dictates state of the = session (e.g. Keep it still up UP) ? There are a few aspects of the proposal that mitigate such a situation. = The scenario you are describing is that the session has actually gone = down but non-auth packets keep it up. - The authenticated packet that brings the session down would have to be = trapped and dropped by MiM. - The sequence number of the subsequent UP packets would have to = correspond to the next expected sequence number. - The occasional authentication of three UP packet would have to pass = the test by MiM. >=20 > Q2) These non-auth packets are not protected from MiM attacks, right? See above. >=20 > Q3) Doesn=92t mixing authenticated & non-authenticated packed make = proposed scheme equivalent to non-authenticated mode ? I mean, unless = every packet is authenticated, isn=92t benefit of bfd-auth nullified ?=20= Not really. The whole idea behind the proposal is that state transitions = are significant in BFD, come at a slower interval and should be = authenticated. Most other packets are liveliness check packets, and = their authentication is not significant. They come at a fast interval = (the defined interval), inundate the authentication capability of the = system, but do not affect the state of the session, other than when they = are dropped. Intentional or unintentional dropping of packets indicates = a problem, but their authentication does not convey any more = information. Even if MiM was to take over a session, it can at best replay a few of = the UP packets till it hits the next set of occasional authenticated UP = packet or it hits a authenticated state transition packet. At that point = it gets exposed. Preserving the authentication system for state transition packet and = occasional UP packets allows one to scale not only the number of BFD = sessions, but also allows us to introduce a stronger form of = authentication. >=20 >=20 > thanks > ~Rajeev >=20 > From: Rtg-bfd > on behalf of "Reshad Rahman = (rrahman)" > > Date: Friday, November 20, 2015 at 4:03 AM > To: "rtg-bfd@ietf.org " >, "draft-mahesh-bfd-authentication@ietf.org = " = > > Subject: Request for WG adoption of draft-mahesh-bfd-authentication >=20 > BFD WG members, >=20 > Please indicate to the WG mailing list whether you would support or = not support BFD WG adoption of the following document. >=20 > https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ = >=20 > Authors, as was mentioned at IETF94, you should get your proposal = reviewed by the security group. >=20 > Regards, > Jeff & Reshad. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_901B0327-DB13-4981-8E24-582F12DC2840 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Rajeev,

See= comments inline.

On Nov 24, 2015, at 8:42 PM, = Rajeev G Nair (rajeenai) <rajeenai@cisco.com> wrote:

Jeff & Reshad, 

 Read through the document. Interesting = concept.

Here is my understanding:-
 1) Current scheme. Both switches are configured to = use same auth. Currently, no packets will be accepted unless all = received pkts match with configured auth.
 2) Proposal is to come up with a scheme to = authenticate only a subset of packets (those signaling a state change as = mentioned). 

Questions:-
Q1) Doesn't acceptance of non-auth packets dictates = state of the session (e.g. Keep it still up UP) = ?

There = are a few aspects of the proposal that mitigate such a situation. The = scenario you are describing is that the session has actually gone down = but non-auth packets keep it up.

- = The authenticated packet that brings the session down would have to be = trapped and dropped by MiM.
- The sequence number of the = subsequent UP packets would have to correspond to the next expected = sequence number.
- The occasional authentication of three UP = packet would have to pass the test by MiM.


Q2) These non-auth packets are not protected from MiM = attacks, right?

See above.


Q3) Doesn=92t mixing authenticated & = non-authenticated packed make proposed scheme equivalent to = non-authenticated mode ? I mean, unless every packet is authenticated, = isn=92t benefit of bfd-auth nullified = ? 

Not = really. The whole idea behind the proposal is that state transitions are = significant in BFD, come at a slower interval and should be = authenticated. Most other packets are liveliness check packets, and = their authentication is not significant. They come at a fast interval = (the defined interval), inundate the authentication capability of the = system, but do not affect the state of the session, other than when they = are dropped. Intentional or unintentional dropping of packets indicates = a problem, but their authentication does not convey any more = information.

Even if MiM was to take = over a session, it can at best replay a few of the UP packets till it = hits the next set of occasional authenticated UP packet or it hits a = authenticated state transition packet. At that point it gets = exposed.

Preserving the = authentication system for state transition packet and occasional UP = packets allows one to scale not only the number of BFD sessions, but = also allows us to introduce a stronger form of = authentication.



thanks
~Rajeev

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of "Reshad Rahman = (rrahman)" <rrahman@cisco.com>
Date: Friday, = November 20, 2015 at 4:03 AM
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, = "draft-mahesh-bfd-authentication@ietf.org" <draft-mahesh-bfd-authentication@ietf.org>
= Subject: Request for = WG adoption of draft-mahesh-bfd-authentication

BFD WG members,

Please indicate to the WG mailing list whether you would = support or not support BFD WG adoption of the following document.

https://datatracker.ietf.org/doc/draft-mahesh-bfd-authenticatio= n/

Authors, as was mentioned at IETF94, you should get your = proposal reviewed by the security group.

Regards,
Jeff & Reshad.

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_901B0327-DB13-4981-8E24-582F12DC2840-- From nobody Wed Nov 25 09:36:13 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DD41A6FF2; Wed, 25 Nov 2015 09:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAaOGJwW0thY; Wed, 25 Nov 2015 09:36:12 -0800 (PST) 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 F38971A6EFE; Wed, 25 Nov 2015 09:36:11 -0800 (PST) Received: by oiww189 with SMTP id w189so33140855oiw.3; Wed, 25 Nov 2015 09:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=QyupzcUb9ukIiG+WT9tQg36GzHntvvV/kiBK5mX05Bw=; b=bQi5Ju0WGl98xkaNKerXMCHsg71YXNxvrhWdBIhCQ1hT328Lg74orhCNs142ikxjHi YKEH9KnJigYRjmJ+IdrcA6CrZFsdvoHgh3EGn+IngxaQUpZJqUCi6GMaSl27JX6tWibb R/NOBQUEoNrlyEWiexhNZMGyFfS1ayIA0IHstxLeQIt6EOXoCqCJhV71AbljcJD10BC2 gzCAKeZu/jNVOvnnQvytGA5PgL5Iz2HfcZqDWYVaH64dVenESpEAI9RHZXufDbEiFCay ogmWKPBLOPSQXZtPoL3PC2mdQII8yhRHuo5tpWBs6Qym8UzPSWvgA70CZtVK+t5sS4v6 3fqA== X-Received: by 10.202.77.136 with SMTP id a130mr21301034oib.123.1448472971304; Wed, 25 Nov 2015 09:36:11 -0800 (PST) Received: from mahesh-m-62at.attlocal.net ([2602:306:cf77:df90:58b1:d513:c0e5:2a1c]) by smtp.gmail.com with ESMTPSA id y9sm7213859obg.4.2015.11.25.09.36.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 Nov 2015 09:36:10 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_719F4895-C956-42DB-9C95-2368AE3717F3" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication From: Mahesh Jethanandani In-Reply-To: Date: Wed, 25 Nov 2015 09:36:08 -0800 Message-Id: <50D21CDC-88CD-471A-A0CE-C8278DC26214@gmail.com> References: To: Santosh P K X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "Reshad Rahman \(rrahman\)" , "draft-mahesh-bfd-authentication@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 17:36:13 -0000 --Apple-Mail=_719F4895-C956-42DB-9C95-2368AE3717F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 25, 2015, at 3:48 AM, Santosh P K = wrote: >=20 > But I think there are few things to consider in this document. It = needs to clearly highlight how to handle interval change from = non-aggressive interval to aggressive interval. A interval change requires a P/F sequence, which are authenticated = packets. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_719F4895-C956-42DB-9C95-2368AE3717F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Nov 25, 2015, at 3:48 AM, Santosh P K <santoshpk@juniper.net> wrote:

But I think there = are few things to consider in this document. It needs to clearly = highlight how to handle interval change from non-aggressive interval to = aggressive interval.

A = interval change requires a P/F sequence, which are authenticated = packets.

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_719F4895-C956-42DB-9C95-2368AE3717F3-- From nobody Wed Nov 25 09:42:49 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7893A1A7014; Wed, 25 Nov 2015 09:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PF7pKTlfqFVH; Wed, 25 Nov 2015 09:42:43 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0744.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:744]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 171D81A7013; Wed, 25 Nov 2015 09:42:42 -0800 (PST) Received: from SN1PR0501MB2142.namprd05.prod.outlook.com (10.163.228.157) by SN1PR0501MB2142.namprd05.prod.outlook.com (10.163.228.157) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 25 Nov 2015 17:42:21 +0000 Received: from SN1PR0501MB2142.namprd05.prod.outlook.com ([10.163.228.157]) by SN1PR0501MB2142.namprd05.prod.outlook.com ([10.163.228.157]) with mapi id 15.01.0331.019; Wed, 25 Nov 2015 17:42:21 +0000 From: Santosh P K To: Mahesh Jethanandani Subject: RE: Request for WG adoption of Thread-Topic: Request for WG adoption of Thread-Index: AdEnqJ1JY1P3qht/QZqVnplssSGb8w== Date: Wed, 25 Nov 2015 17:42:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=santoshpk@juniper.net; x-originating-ip: [116.197.184.14] x-microsoft-exchange-diagnostics: 1; SN1PR0501MB2142; 5:43shno23OXI0Q20NrCVFr0jm5SWgHhlFadsJN1aT5CbCcV5syxD8sxgNVFE1jxRIl17LbuT3sWqxbhYfIQwFXQT+fY5mLBpFdZszEzeDx8h6F686MtpqHNZQEk8b137sbqzbdlPjV1Ji5uGs1B/BSg==; 24:5RQTvSrz04hukTDCWjLAUeSWhvQdl3+lz/PXv1vA79SA3ifgKCMz4FG3xyfQw+SMxCWvBcYYO/JFGUCqxpCmRgBEJvSaVHDZPBTgIHzZPXY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB2142; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:SN1PR0501MB2142; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2142; x-forefront-prvs: 0771670921 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(24454002)(199003)(189998001)(19580395003)(19625215002)(790700001)(3846002)(33656002)(87936001)(86362001)(15975445007)(5003600100002)(6116002)(5002640100001)(5001960100002)(101416001)(19300405004)(102836003)(586003)(97736004)(5004730100002)(11100500001)(74316001)(2900100001)(5008740100001)(40100003)(50986999)(19609705001)(54356999)(1411001)(5007970100001)(76576001)(19580405001)(16236675004)(110136002)(105586002)(66066001)(81156007)(122556002)(77096005)(92566002)(99286002)(106356001)(10400500002)(1220700001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2142; H:SN1PR0501MB2142.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0501MB2142E7903231D58F569890DBB3050SN1PR0501MB2142_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2015 17:42:21.0162 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2142 Archived-At: Cc: "Reshad Rahman \(rrahman\)" , "draft-mahesh-bfd-authentication@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 17:42:48 -0000 --_000_SN1PR0501MB2142E7903231D58F569890DBB3050SN1PR0501MB2142_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mahesh, Thanks for quick reply. Please see some points from old mail. I think we = need to make document more clear bout some ambiguity with authentication en= abled. I think we need to do this randomly for few times to get rid of any attack = when BFD session is UP. Consider a case where BFD can run at interval of 3= .3 ms only if no authentication is enabled. So with initial slow packets = (>1 sec when not UP) I will be authenticating the packets and when session = goes to UP state with aggressive interval BFD will go without AUTH. If I wa= nt to send BFD packet with AUTH then I might need to change the interval fi= rst? Secondly I think we will terminate Auth once the BFD session goes to UP sta= te locally and I assume some configuration will decide how randomly to send= BFD UP packets with AUTH set. Now assume that BFD on one end is stuck in I= NIT state due to packet loss (2 packet loss if multiple is 3), so for 2 sec= onds one side which has already reach UP state might have terminated AUTH a= nd other side in INIT might have not. This could lead to time mismatch on w= hen to randomly send UP packets with Auth set. I think we need to have prop= er guidelines on when to terminate the AUTH and when to start again may be = with P/F negotiation? Thanks Santosh P K From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com] Sent: Wednesday, November 25, 2015 11:06 PM To: Santosh P K Cc: Reshad Rahman (rrahman) ; rtg-bfd@ietf.org; draft-ma= hesh-bfd-authentication@ietf.org Subject: Re: Request for WG adoption of On Nov 25, 2015, at 3:48 AM, Santosh P K > wrote: But I think there are few things to consider in this document. It needs to = clearly highlight how to handle interval change from non-aggressive interva= l to aggressive interval. A interval change requires a P/F sequence, which are authenticated packets. Mahesh Jethanandani mjethanandani@gmail.com --_000_SN1PR0501MB2142E7903231D58F569890DBB3050SN1PR0501MB2142_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mahesh,

  Thanks for quick reply. Please= see some points from old mail. I think we need to make document more clear= bout some ambiguity with authentication enabled.

 

<snip>

I think we need to do this randomly for few times= to get rid of any attack when BFD session is UP. Consider a case where BFD= can run at interval of  3.3 ms only if  no authentication is ena= bled.  So with initial slow packets (>1 sec when not UP) I will be authenticating the packets and when session goes to= UP state with aggressive interval BFD will go without AUTH. If I want to s= end BFD packet with AUTH then I might need to change the interval first?

 

Secondly I think we will terminate Auth once the = BFD session goes to UP state locally and I assume some configuration will d= ecide how randomly to send BFD UP packets with AUTH set. Now assume that BF= D on one end is stuck in INIT state due to packet loss (2 packet loss if multiple is 3), so for 2 seconds one = side which has already reach UP state might have terminated AUTH and other = side in INIT might have not. This could lead to time mismatch on when to ra= ndomly send UP packets with Auth set. I think we need to have proper guidelines on when to terminate the AU= TH and when to start again may be with P/F negotiation?

<snip>

 

Thanks

Santosh P K

 

From: Mahesh Jethanandani [mailto:mj= ethanandani@gmail.com]
Sent: Wednesday, November 25, 2015 11:06 PM
To: Santosh P K <santoshpk@juniper.net>
Cc: Reshad Rahman (rrahman) <rrahman@cisco.com>; rtg-bfd@ietf.= org; draft-mahesh-bfd-authentication@ietf.org
Subject: Re: Request for WG adoption of

 

 

On Nov 25, 2015, at 3:48 AM, Santosh P K <santoshpk@juniper.net> wrote:=

 

But I think there are few things to c= onsider in this document. It needs to clearly highlight how to handle inter= val change from non-aggressive interval to aggressive interval.

 

A interval change requires a P/F sequence, which are= authenticated packets.

 

Mahesh Jethanandani=

 =

 =

 

 

--_000_SN1PR0501MB2142E7903231D58F569890DBB3050SN1PR0501MB2142_-- From nobody Wed Nov 25 21:35:41 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDB51ACE5D; Wed, 25 Nov 2015 21:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.485 X-Spam-Level: X-Spam-Status: No, score=-14.485 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, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQATLWgiHq9i; Wed, 25 Nov 2015 21:35:34 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7579B1ACE5C; Wed, 25 Nov 2015 21:35:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18032; q=dns/txt; s=iport; t=1448516134; x=1449725734; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WTsondjuOvxe5DOk60skn/H4XvwTLuePLuDCkKxSsHk=; b=B00EkQlhs2TuFIOoBSGQPKBgsu1QPbao6Vbfa9YkiCClJDy81SRB62V4 12u2S4tLSwqmxGGCvgnleYagYYkdPrvXptC2zMEdCGN7Ldox8XwoqCo4x Vg0WoOAH+qpdxwUk42YsUCDNpxAed5qfh/4MGy5gB4ruQITV1mypojQUr M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAgAhmVZW/4QNJK1egm5NU28GvhwBD?= =?us-ascii?q?YFkIYVuAoFAOBQBAQEBAQEBgQqENAEBAQRuCxACAQgOAwMBAigHIREUCQgCBA4?= =?us-ascii?q?FiBkDEg25SA2EYwEBAQEBAQEDAQEBAQEBAQEBARUEhlSEfoJTgigNhDEFjVuFF?= =?us-ascii?q?INoAYUnhheBdoFchEGDJoYShTODZINxAR8BAUKEBHKEWYEHAQEB?= X-IronPort-AV: E=Sophos; i="5.20,345,1444694400"; d="scan'208,217"; a="50319702" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Nov 2015 05:35:32 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tAQ5ZWWm032702 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 26 Nov 2015 05:35:32 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 Nov 2015 23:35:32 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.000; Wed, 25 Nov 2015 23:35:32 -0600 From: "Rajeev G Nair (rajeenai)" To: Mahesh Jethanandani Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication Thread-Topic: Request for WG adoption of draft-mahesh-bfd-authentication Thread-Index: AQHRI4t1BhxwWi4DrkqzzQbDKMhgLp6sDquAgAFeBgCAAEMzgA== Date: Thu, 26 Nov 2015 05:35:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.92.9] Content-Type: multipart/alternative; boundary="_000_D27BD707106066rajeenaiciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Reshad Rahman \(rrahman\)" , "draft-mahesh-bfd-authentication@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 05:35:38 -0000 --_000_D27BD707106066rajeenaiciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pls see tagged Rajeev> thanks ~Rajeev From: Mahesh Jethanandani > Date: Wednesday, November 25, 2015 at 9:34 AM To: Rajeev Nair > Cc: "Reshad Rahman (rrahman)" >= , "rtg-bfd@ietf.org" >, "draft-mahesh-bfd-authentication@ietf.org" > Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication Rajeev, See comments inline. On Nov 24, 2015, at 8:42 PM, Rajeev G Nair (rajeenai) > wrote: Jeff & Reshad, Read through the document. Interesting concept. Here is my understanding:- 1) Current scheme. Both switches are configured to use same auth. Currentl= y, no packets will be accepted unless all received pkts match with configur= ed auth. 2) Proposal is to come up with a scheme to authenticate only a subset of p= ackets (those signaling a state change as mentioned). Questions:- Q1) Doesn't acceptance of non-auth packets dictates state of the session (e= .g. Keep it still up UP) ? There are a few aspects of the proposal that mitigate such a situation. The= scenario you are describing is that the session has actually gone down but= non-auth packets keep it up. - The authenticated packet that brings the session down would have to be tr= apped and dropped by MiM. Rajeev> What happens when the router indeed got disconnected from each othe= r(a legitimate failure BFD is supposed to detect), but MiM can talk to both= ? I think here you are assuming they can always talk. - The sequence number of the subsequent UP packets would have to correspond= to the next expected sequence number. - The occasional authentication of three UP packet would have to pass the t= est by MiM. Q2) These non-auth packets are not protected from MiM attacks, right? See above. Q3) Doesn't mixing authenticated & non-authenticated packed make proposed s= cheme equivalent to non-authenticated mode ? I mean, unless every packet is= authenticated, isn't benefit of bfd-auth nullified ? Not really. The whole idea behind the proposal is that state transitions ar= e significant in BFD, come at a slower interval and should be authenticated= . Most other packets are liveliness check packets, and their authentication= is not significant. They come at a fast interval (the defined interval), i= nundate the authentication capability of the system, but do not affect the = state of the session, other than when they are dropped. Intentional or unin= tentional dropping of packets indicates a problem, but their authentication= does not convey any more information. Rajeev > IMO, liveliness pkts are as important as other packet. Even if MiM was to take over a session, it can at best replay a few of the = UP packets till it hits the next set of occasional authenticated UP packet = or it hits a authenticated state transition packet. At that point it gets e= xposed. Rajeev > Again, this approach breaks BFD failure detection interval guarant= ee. MiM can theoretically delay the failure detection. Preserving the authentication system for state transition packet and occasi= onal UP packets allows one to scale not only the number of BFD sessions, bu= t also allows us to introduce a stronger form of authentication. Rajeev > I completely understand, this may relieve CPU burden. What I am wo= rried about the effectiveness of authentication. To me, if requirement for = authentication is relaxed for a subset of packets, BFD session itself is no= t authenticated. I am not saying there are no use cases for this, but draft= needs to call it out. thanks ~Rajeev From: Rtg-bfd > o= n behalf of "Reshad Rahman (rrahman)" > Date: Friday, November 20, 2015 at 4:03 AM To: "rtg-bfd@ietf.org" >, "draft-mahesh-bfd-authentication@ietf.org" > Subject: Request for WG adoption of draft-mahesh-bfd-authentication BFD WG members, Please indicate to the WG mailing list whether you would support or not sup= port BFD WG adoption of the following document. https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ Authors, as was mentioned at IETF94, you should get your proposal reviewed = by the security group. Regards, Jeff & Reshad. Mahesh Jethanandani mjethanandani@gmail.com --_000_D27BD707106066rajeenaiciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Pls see tagged Rajeev>

thanks
~Rajeev

From: Mahesh Jethanandani <mjethanandani@gmail.com>
Date: Wednesday, November 25, 2015 = at 9:34 AM
To: Rajeev Nair <rajeenai@cisco.com>
Cc: "Reshad Rahman (rrahman)&q= uot; <rrahman@cisco.com>, &q= uot;rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-mahesh-bfd-authentic= ation@ietf.org" <draft-mahe= sh-bfd-authentication@ietf.org>
Subject: Re: Request for WG adoptio= n of draft-mahesh-bfd-authentication

Rajeev,

See comments inline.

On Nov 24, 2015, at 8:42 PM, Rajeev G Nair (rajeenai) <<= a href=3D"mailto:rajeenai@cisco.com" class=3D"">rajeenai@cisco.com> = wrote:

Jeff & Reshad, 

 Read through the document. Interesting concept.

Here is my understanding:-
 1) Current scheme. Both switches are configured to us= e same auth. Currently, no packets will be accepted unless all received pkt= s match with configured auth.
 2) Proposal is to come up with a scheme to authentica= te only a subset of packets (those signaling a state change as mentioned).&= nbsp;

Questions:-
Q1) Doesn't acceptance of non-auth packets dictates state o= f the session (e.g. Keep it still up UP) ?

There are a few aspects of the proposal that mitigate such a situation. The= scenario you are describing is that the session has actually gone down but= non-auth packets keep it up.


- The authenticated packet that brings the session down would have to = be trapped and dropped by MiM.

Rajeev> What happens when the router indeed got disconnected from e= ach other(a legitimate failure BFD is supposed to detect), but MiM can talk= to both ? I think here you are assuming they can always talk.

- The sequence number of the subsequent UP packets would have to corre= spond to the next expected sequence number.
- The occasional authentication of three UP packet would have to pass = the test by MiM.


Q2) These non-auth packets are not protected from MiM attac= ks, right?

See above.


Q3) Doesn’t mixing authenticated & non-authentica= ted packed make proposed scheme equivalent to non-authenticated mode ? I me= an, unless every packet is authenticated, isn’t benefit of bfd-auth n= ullified ? 

Not really. The whole idea behind the proposal is that state transitions ar= e significant in BFD, come at a slower interval and should be authenticated= . Most other packets are liveliness check packets, and their authentication= is not significant. They come at a fast interval (the defined interval), inundate the authentication capabi= lity of the system, but do not affect the state of the session, other than = when they are dropped. Intentional or unintentional dropping of packets ind= icates a problem, but their authentication does not convey any more information.

Rajeev > IMO, liveliness pkts are as important as other packet.&nbs= p;

Even if MiM was to take over a session, it can at best replay a few of= the UP packets till it hits the next set of occasional authenticated UP pa= cket or it hits a authenticated state transition packet. At that point it g= ets exposed.

Rajeev > Again, this approach breaks BFD failure detection interval= guarantee. MiM can theoretically delay the failure detection.

Preserving the authentication system for state transition packet and o= ccasional UP packets allows one to scale not only the number of BFD session= s, but also allows us to introduce a stronger form of authentication.

Rajeev > I completely understand, this may relieve CPU burden. What= I am worried about the effectiveness of authentication. To me, if requirem= ent for authentication is relaxed for a subset of packets, BFD session itse= lf is not authenticated. I am not saying there are no use cases for this, but draft needs to call it out. 



thanks
~Rajeev

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of "Reshad Rahman (rrahman)" <rrahman@cisco.com>
Date: Friday, November 2= 0, 2015 at 4:03 AM
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-mahes= h-bfd-authentication@ietf.org" <draft-mahesh-bfd-authentication@ietf.org>
Subject: Request for WG = adoption of draft-mahesh-bfd-authentication

BFD WG members,

Please indicate to the WG mailing list whether you would su= pport or not support BFD WG adoption of the following document.

https://datatracke= r.ietf.org/doc/draft-mahesh-bfd-authentication/

Authors, as was mentioned at IETF94, you should get your pr= oposal reviewed by the security group.

Regards,
Jeff & Reshad.

Mahesh Jethanandani
mjeth= anandani@gmail.com





 --_000_D27BD707106066rajeenaiciscocom_-- From nobody Mon Nov 30 17:41:47 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A69D1B34C6; Mon, 30 Nov 2015 16:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQZF_5HLg8uA; Mon, 30 Nov 2015 16:49:59 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E76D1B3476; Mon, 30 Nov 2015 16:49:59 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-4a-565ceeb38e87 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 9D.68.32102.3BEEC565; Tue, 1 Dec 2015 01:49:56 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Mon, 30 Nov 2015 19:49:57 -0500 From: Gregory Mirsky To: Huaimo Chen , "rtorvi@juniper.net" , "draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Topic: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Index: AQHQdUsbhXhJtQ5lC02wWl3AD+NymZ1QUc6ggAeV/ACBS3mFcA== Date: Tue, 1 Dec 2015 00:49:57 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1122194BD8B@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B948347@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D44E37EE98@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B94CD49@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D44E3804B5@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D44E3804B5@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1122194BD8Beusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsUyuXSPt+6WdzFhBpuOsVhcfPiU2WLr0yuM FreWrmS1+PxnG6PF/5fL2C2a5u5ismj9sYPFgd2j5chbVo8lS34yeVxvusru8eXyZ7YAligu m5TUnMyy1CJ9uwSujEWfTjAW3H/KXDG9+S5zA+PqVcxdjJwcEgImEqemdrNC2GISF+6tZ+ti 5OIQEjjCKDHpwBQmCGc5o8Tu1n4WkCo2ASOJFxt72EESIgILmCS2b/7EDpJgFvCSuPR8GthY YQF3ia6bB8BsEQEPiRXX5rBB2E4SPyc1ga1jEVCRmHWkHayGV8BX4vY0iDlCAiuZJB43SIPY nAJhEofOHgDrZQQ67/upNUwQu8Qlbj2ZzwRxtoDEkj3nod4RlXj5+B/UO0oSk5aeY4Woz5dY uPorK8QuQYmTM5+wTGAUnYVk1CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZV jBylxQU5uelGhpsYgTF6TILNcQfj3l7PQ4wCHIxKPLwfrsSECbEmlhVX5h5ilOBgVhLhVXkC FOJNSaysSi3Kjy8qzUktPsQozcGiJM7LyMDAICSQnliSmp2aWpBaBJNl4uCUamCcaF7/rp3v UfDBAz/WVC3arXL7hErmvFuabKvFbf+VvROWylzup32V2WC2eHkH1/77IV3+/xl2r2A22ydS 7qX1urlg5oqzlqpzuE/f5Vpk9UP01Fam784G5k0FK1kL1/9m/HiFy+PuMiOVkC3/ft+1W8L/ zfuYe4z7OXexCq/vs8r5V++R/3xciaU4I9FQi7moOBEArSsHKs0CAAA= Archived-At: X-Mailman-Approved-At: Mon, 30 Nov 2015 17:41:45 -0800 Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 00:50:08 -0000 --_000_7347100B5761DC41A166AC17F22DF1122194BD8Beusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huaimo and authors, apologies for the extended period of silence. Thank you for your answers. I= 'll use this thread of discussion to review and comment on the latest versi= on of the document. I believe that we were discussing -02 version and the most current is -04. = Thus I've reviewed changes from -02 through -04 versions. Please find my co= mments and questions below: * Source Detects Failure I cannot agree with several assertions and statements made in this section: o the source node (S in Fig.1) detects failure not just of R1 but S-R1 pa= th. The text "the backup ingress MUST use a method to reliably detect the f= ailure of the primary ingress" concentrates only of failure of the R1, thus= excluding failure of S-R1 path; o Similar omission seen in the last paragraph that concentrates only on s= cenario when R1 fails and excludes scenario when path S-R1 does fail even t= hough from the perspective of S these are equally defects; o And it is not obvious why discussion of monitoring role of the backup i= ngress located in this section. * Backup and Source Detect Failure o as noted earlier, the backup ingress has no means to reliably detect fa= ilure of S-R1 path. Thus state of the LSP from S perspective and Ra may not= be the same without explicit protocol similar to Protection Switchover Coo= rdination [RFC6378]. * Failure Detection and Refresh PATH Messages o as noted earlier, the backup ingress cannot "accurately detect that the= ingress node has failed" for all the cases where the Source detects a fail= ure. o * several new places now use normative SHOULD, e.g. section Revert = to Primary Ingress: If "Revert to Primary Ingress" is desired for a protected LSP, the (primary) ingress of the LSP SHOULD re-signal the LSP that starts from the primary ingress after the primary ingress restores. Is there an alternative to re-signaling the LSP? After the LSP is re-signaled successfully, the traffic SHOULD be switche= d back to the primary ingress from the backup ingress on the source node and redirected into the LSP starting from the primary ingress. Similarly, is there alternative to switching traffic back to the primary af= ter the LSP been re-signaled successfully? * Security Considerations I believe that the Source-Detect approach introduces several security conce= rns that were not in scope of RFC 4090. For example, the Source required to= monitor S-R1 path thus increasing, if not opening possibility of DDoS atta= ck. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Tuesday, April 21, 2015 8:27 AM To: Gregory Mirsky; draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org<= mailto:draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org>; teas-chairs= @ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Hi Greg, Thanks for your comments. My answers/explanations are inline below with [Huaimo 2]. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, April 16, 2015 7:58 PM To: Huaimo Chen; draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; teas-chairs@ie= tf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Hi Huaimo, thank you for kind consideration of my comments. Please find more in-lined = and tagged GIM>> notes. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Sunday, April 12, 2015 11:04 AM To: Gregory Mirsky; draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org<= mailto:draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org>; teas-chairs= @ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Hi Greg, Thanks for your comments. My answers/explanations are inline below. Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Sunday, April 12, 2015 2:04 AM To: draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; teas-chairs@ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Dear Editors, chairs, WG community, please find my comments to the current version of your work below: * Introduction o The first paragraph may leave an impression that local protection of tr= ansit LSRs is not being already addressed, neither by RFC 4090, nor RFC 487= 5; [Huaimo] Will revise it accordingly. o I think that "global protection" is not commonly used term, "end-to-end= protection" seems to be commonly used instead. [Huaimo] It seems that "global protection" is better here since we mentione= d "local protection" here. It seems that Global Protection is used often. * Section 3.1 o Third paragraph contains the following requirement: "For a P2P LSP, after the primary ingress fails, the backup ingress must us= e a method to reliably detect the failure of the primary ingress before the= PATH message for the LSP expires at the next hop of the primary ingress." But that is not obvious that such requirement is really needed. Since this = is RSVP-TE LSP, why not to use MP2MP construct and let the Source node to c= ontrol switchover. Especially since, as noted in the last paragraph of Sect= ion 2.1, primary and backup ingress nodes must be connected by a logical li= nk, which in general case will be a tunnel. Thus this solution puts a requi= rement, implicitly though, to instantiate a tunnel per protection group, tu= nnel that would not be used to carry traffic. [Huaimo] The requirement above seems necessary. If the backup ingress does = not detect the failure of the primary ingress before the timer for the PATH= message for the LSP at the next hop of the primary ingress expires, the LS= P will be down after the primary ingress fails. If the backup ingress detec= ts the failure and sends/refreshes the PATH message to the next hop before = the timer expires after the primary egress fails, the LSP will continue bei= ng up and carry the traffic from the backup ingress via the backup LSP. For a P2P LSP, it seems that MP2MP construct is not used in RFC 4090 to pro= tect a transit node of a P2P LSP. The logical link between the primary ingr= ess and the backup ingress can be a direct link or a tunnel. It seems that = a direct link is common. GIM>> I think it is strange to cite requirement on scale of seconds if not = tens of seconds in discussion of method of local protection that supposed t= o perform protection switchover in sub-second if not sub-50msec time. [Huaimo 2] The requirement is for the control plane. More specifically, it = is for the PATH message (not to be cleaned up) for the LSP at the next hop = of the primary ingress of the LSP when the primary ingress fails. After the= primary ingress fails, the next hop will not receive any PATH message from= the primary ingress. In order to prevent the PATH message from clean up at= the next hop, the backup ingress seems required to detect the failure of t= he primary ingress and send/refresh the PATH message to the next hop before= the PATH message is cleaned up. Thus it seems reasonable for the requireme= nt to have the time for detecting the failure of the primary ingress in sec= onds or even tens of seconds instead of sub-seconds or within 50 ms. o In addition, what is importance of requirement quoted above: "... before the PATH message for the LSP expires at the next hop of the pri= mary ingress" [Huaimo] This seems very important. If the timer for the PATH message for t= he LSP at the next hop of the primary egress expires, then the LSP will be = down. So the PATH message must be refreshed before the timer for the PATH m= essage for the LSP expires at the next hop of the primary LSP. GIM>> As noted above, these seem as requirements of different scale. [Huaimo 2] See the explanation above. o Fourth paragraph makes very questionable assumption in: "After the primary ingress fails, it will not be reachable after routing co= nvergence." I believe that if OAM session is between two nodes there's no reliable way = to differentiate between node and link failure. Thus, to declare a node unr= eachable there must be N tunnels for N OAM sessions that monitor all possib= le paths between two nodes. (Note, that if there was no requirement to use = a tunnel between primary and backup ingress, multi-hop BFD could be used th= ough its detection time being limited by IGP convergence, which may be too = slow comparing with your requirement of tens milliseconds). [Huaimo] It is true that "After the primary ingress fails, it will not be r= eachable after routing convergence." From routing's point of view, there i= s no need for us to have any OAM session between two nodes. The timer for a= PATH message seems in tens of seconds. Routing convergence is not limited = to tens of milliseconds. GIM>> Routing convergence may take seconds. Is that acceptable as failure d= etection time for local protection? Protection switchover expected to be fa= st, perhaps on sub-50 msec scale. From TDM world we carry 10 msec failure d= etection, and BFD implementations can support that. but here, it appears, y= ou describe failure detection mechanism with detection time on scale of sec= onds if not tens of seconds. [Huaimo 2] The routing convergence is for the control plane. Refer to the e= xplanation above. * Section 5.1 o Regarding "Ingress local protection in use" flag As demonstrated earlier, backup ingress node has no reliable way to detect = that primary ingress node is not reachable to the Source and thus protectio= n must be activated. [Huaimo] It seems that there is no need for the backup ingress to detect wh= ether the primary ingress is reachable to the Source and the focus is on th= e failure of the primary ingress. GIM>> In that case, the text is not needed either. [Huaimo 2] Can you give more details regarding to "the text is not needed e= ither"? Which part of the text (do you think) is not needed in section 5.1? Considering that backup ingress may initiate described in the document acti= ons not when primary ingress became unavailable to Source, I believe that c= ases that may produce false positives must be removed along with extensions= that intended to support these cases. In my opinion, the only viable case = of ingress protection is Source-centric where Source monitors availability = of both primary and backup ingress nodes and controls traffic switchover. I= 'd ask WG to discuss these comments and, if agreed, ask Editors to make app= ropriate changes to the document. [Huaimo] It seems that the current version already indicates that the sourc= e-detect (i.e., Source detects the failure of the primary ingress and switc= hes traffic to the backup ingress when the primary ingress fails) is used. = There were a few of modes for detecting the failure of the primary ingress= that were proposed in the previous versions of the document. A different m= ode may have a different control on the traffic switch over and/or forwardi= ng. After discussions, the current version selects the source-detect. GIM>> If this is historical part, then it may be moved to Appendix or taken= from the document altogether. [Huaimo 2] A couple of detection modes were removed from the document. One = more will be smoothed out. Thus there will be only one mode in the document= . Can you give more details about the cases in which false positives may be p= roduced? GIM>> If current proposal is limited to Source-detect case only then possi= bility of false positive/negative depends on Source to Ingress connection a= nd OAM mechanism used. But that is deployment issue and is outside of scope= of this document Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1122194BD8Beusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Huaimo and authors,=

apologies for the exte= nded period of silence. Thank you for your answers. I’ll use this thr= ead of discussion to review and comment on the latest version of the docume= nt.

I believe that we were= discussing -02 version and the most current is -04. Thus I’ve review= ed changes from -02 through -04 versions. Please find my comments and quest= ions below:

·         Source Detects= Failure

I cannot agree with several assertions and statements made in this sec= tion:

o   the source nod= e (S in Fig.1) detects failure not just of R1 but S-R1 path. The text ̶= 0;the backup ingress MUST use a method to reliably detect the failure of th= e primary ingress” concentrates only of failure of the R1, thus excluding failure of S-R1 path;<= /p>

o   Similar omissi= on seen in the last paragraph that concentrates only on scenario when R1 fa= ils and excludes scenario when path S-R1 does fail even though from the per= spective of S these are equally defects;

o   And it is not = obvious why discussion of monitoring role of the backup ingress located in = this section.

·         Backup and Sou= rce Detect Failure

o   as noted earli= er, the backup ingress has no means to reliably detect failure of S-R1 path= . Thus state of the LSP from S perspective and Ra may not be the same witho= ut explicit protocol similar to Protection Switchover Coordination [RFC6378].

·         Failure Detect= ion and Refresh PATH Messages

o   as noted earli= er, the backup ingress cannot “accurately detect that the ingress nod= e has failed” for all the cases where the Source detects a failure.

o    

·         several new pl= aces now use normative SHOULD, e.g. section Revert to Primary Ingress:=

   If "Revert to Primary Ingress" is desired for = a protected LSP, the

   (primary) ingress of the LSP SHOULD re-signal the LSP th= at starts

   from the primary ingress after the primary ingress resto= res.

Is there an alternative to re-signaling the LSP?

   After the LSP is re-signaled successfully, the traffic S= HOULD be switched

   back to the primary ingress from the backup ingress on t= he source

   node and redirected into the LSP starting from the prima= ry ingress.

Similarly, is there alternative to switching traffic back to the prim= ary after the LSP been re-signaled successfully?

·         Security Consi= derations

I believe that the Source-Detect approach introduces several security= concerns that were not in scope of RFC 4090. For example, the Source requi= red to monitor S-R1 path thus increasing, if not opening possibility of DDoS attack.

 

 

   &nbs= p;            Regard= s,

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

 

 

From: Huaimo C= hen [mailto:hu= aimo.chen@huawei.com]
Sent: Tuesday, April 21, 2015 8:27 AM
To: Gregory Mirsky; draft-ietf-teas-rsvp-ingress-p= rotection@tools.ietf.org; teas-chairs@ietf= .org; teas@ietf.org
Cc: mpls@ietf.or= g; rtg-bfd@ietf.org
Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protect= ion

 

Hi Greg,

 

Thanks for your comments.

My answers/explanations are inline below with [Huaimo 2].<= /span>

 

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Thursday, April 16, 2015 7:58 PM
To: Huaimo Chen; draft-ietf-teas-rsvp-ingress-prot= ection@tools.ietf.org; teas-chairs@ietf= .org; teas@ietf.org
Cc: mpls@ietf.or= g; rtg-bfd@ietf.org
Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protect= ion

 

Hi Huaimo,<= /span>

thank you for kind con= sideration of my comments. Please find more in-lined and tagged GIM>>= notes.

 

   &nbs= p;            Regard= s,

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

 

From: Huaimo C= hen [mailto:hu= aimo.chen@huawei.com]
Sent: Sunday, April 12, 2015 11:04 AM
To: Gregory Mirsky; draft-ietf-teas-rsvp-ingress-p= rotection@tools.ietf.org; teas-chairs@ietf= .org; teas@ietf.org
Cc: mpls@ietf.or= g; rtg-bfd@ietf.org
Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protect= ion

 

Hi Greg,

 

Thanks for your comments.

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: mpls [mailt= o:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Sunday, April 12, 2015 2:04 AM
To: draft-ietf-teas-rsvp-ingress-protection@tools.= ietf.org; teas-chairs@ietf= .org; teas@ietf.org
Cc: mpls@ietf.or= g; rtg-bfd@ietf.org
Subject: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection<= o:p>

 

Dear Editors, chairs, WG community,

please find my comments to the current version of yo= ur work below:

·         Introduction

o   The first paragraph may leave an impression = that local protection of transit LSRs is not being already addressed, neith= er by RFC 4090, nor RFC 4875;

[Huaimo] Will revise i= t accordingly.

o   I think that “global protection”= is not commonly used term, “end-to-end protection” seems to be= commonly used instead.

[Huaimo] It seems that= “global protection” is better here since we mentioned “l= ocal protection” here. It seems that Global Protection is used often.=

·         Section 3.1

o   Third paragraph contains the following requi= rement:

“For a P2P LSP, af= ter the primary ingress fails, the backup ingress must use a method to reli= ably detect the failure of the primary ingress before the PATH message for = the LSP expires at the next hop of the primary ingress.”

But that is not obvious = that such requirement is really needed. Since this is RSVP-TE LSP, why not = to use MP2MP construct and let the Source node to control switchover. Espec= ially since, as noted in the last paragraph of Section 2.1, primary and backup ingress nodes must be connected by a lo= gical link, which in general case will be a tunnel. Thus this solution puts= a requirement, implicitly though, to instantiate a tunnel per protection g= roup, tunnel that would not be used to carry traffic.

[Huaimo] The requireme= nt above seems necessary. If the backup ingress does not detect the failure= of the primary ingress before the timer for the PATH message for the LSP a= t the next hop of the primary ingress expires, the LSP will be down after the primary ingress fails. If the back= up ingress detects the failure and sends/refreshes the PATH message to the = next hop before the timer expires after the primary egress fails, the LSP w= ill continue being up and carry the traffic from the backup ingress via the backup LSP. =

For a P2P LSP, it seem= s that MP2MP construct is not used in RFC 4090 to protect a transit node of= a P2P LSP. The logical link between the primary ingress and the backup ing= ress can be a direct link or a tunnel. It seems that a direct link is common.

GIM>> I think it= is strange to cite requirement on scale of seconds if not tens of seconds = in discussion of method of local protection that supposed to perform protec= tion switchover in sub-second if not sub-50msec time.

[Huaimo 2] The require= ment is for the control plane. More specifically, it is for the PATH messag= e (not to be cleaned up) for the LSP at the next hop of the primary ingress= of the LSP when the primary ingress fails. After the primary ingress fails, the next hop will not receive any = PATH message from the primary ingress. In order to prevent the PATH message= from clean up at the next hop, the backup ingress seems required to detect= the failure of the primary ingress and send/refresh the PATH message to the next hop before the PATH message = is cleaned up. Thus it seems reasonable for the requirement to have the tim= e for detecting the failure of the primary ingress in seconds or even tens = of seconds instead of sub-seconds or within 50 ms.

 

o   In addition, what is importance of requireme= nt quoted above:

“… before th= e PATH message for the LSP expires at the next hop of the primary ingress&#= 8221;

[Huaimo] This seems ve= ry important. If the timer for the PATH message for the LSP at the next hop= of the primary egress expires, then the LSP will be down. So the PATH mess= age must be refreshed before the timer for the PATH message for the LSP expires at the next hop of the primary LS= P.

GIM>> As noted a= bove, these seem as requirements of different scale.

[Huaimo 2] See the exp= lanation above.

 

o   Fourth paragraph makes very questionable ass= umption in:

“After the primary= ingress fails, it will not be reachable after routing convergence.”<= o:p>

I believe that if OAM se= ssion is between two nodes there’s no reliable way to differentiate b= etween node and link failure. Thus, to declare a node unreachable there mus= t be N tunnels for N OAM sessions that monitor all possible paths between two nodes. (Note, that if there was no requirem= ent to use a tunnel between primary and backup ingress, multi-hop BFD could= be used though its detection time being limited by IGP convergence, which = may be too slow comparing with your requirement of tens milliseconds).

[Huaimo] It is true th= at “After the primary ingress fails, it will not be reachable after r= outing convergence.”  From routing’s point of view, there = is no need for us to have any OAM session between two nodes. The timer for a PATH message seems in tens of seconds. Routing convergence= is not limited to tens of milliseconds.

GIM>> Routing co= nvergence may take seconds. Is that acceptable as failure detection time fo= r local protection? Protection switchover expected to be fast, perhaps on s= ub-50 msec scale. From TDM world we carry 10 msec failure detection, and BFD implementations can support that. but h= ere, it appears, you describe failure detection mechanism with detection ti= me on scale of seconds if not tens of seconds.

[Huaimo 2] The routing= convergence is for the control plane. Refer to the explanation above.=

 

·         Section 5.1

o   Regarding “Ingress local protection in= use” flag

As demonstrated earlier,= backup ingress node has no reliable way to detect that primary ingress nod= e is not reachable to the Source and thus protection must be activated.

[Huaimo] It seems that= there is no need for the backup ingress to detect whether the primary ingr= ess is reachable to the Source and the focus is on the failure of the prima= ry ingress.

GIM>> In that ca= se, the text is not needed either.

[Huaimo 2] Can you giv= e more details regarding to “the text is not needed either”? Wh= ich part of the text (do you think) is not needed in section 5.1?

 

Considering that backup ingress may initiate describ= ed in the document actions not when primary ingress became unavailable to S= ource, I believe that cases that may produce false positives must be remove= d along with extensions that intended to support these cases. In my opinion, the only viable case of ingress pro= tection is Source-centric where Source monitors availability of both primar= y and backup ingress nodes and controls traffic switchover. I’d ask W= G to discuss these comments and, if agreed, ask Editors to make appropriate changes to the document.

[Huaimo] It seems that= the current version already indicates that the source-detect (i.e., Source= detects the failure of the primary ingress and switches traffic to the bac= kup ingress when the primary ingress fails) is used.  There were a few of modes for detecting the failure = of the primary ingress that were proposed in the previous versions of the d= ocument. A different mode may have a different control on the traffic switc= h over and/or forwarding.  After discussions, the current version selects the source-detect.

GIM>> If this is= historical part, then it may be moved to Appendix or taken from the docume= nt altogether.

[Huaimo 2] A couple of= detection modes were removed from the document. One more will be smoothed = out. Thus there will be only one mode in the document.

 

Can you give more deta= ils about the cases in which false positives may be produced?

GIM>> If current= proposal is limited to Source-detect case only  then possibility of f= alse positive/negative depends on Source to Ingress connection and OAM mech= anism used. But that is deployment issue and is outside of scope of this document

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_7347100B5761DC41A166AC17F22DF1122194BD8Beusaamb103erics_--