Re: WG Adoption for draft-chen-bfd-unsolicted

"Naiming Shen (naiming)" <naiming@cisco.com> Tue, 30 October 2018 22:28 UTC

Return-Path: <naiming@cisco.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820B3130DC7; Tue, 30 Oct 2018 15:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.971
X-Spam-Level:
X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPoNUri6Z8k9; Tue, 30 Oct 2018 15:28:17 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE9B12D4F0; Tue, 30 Oct 2018 15:28:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4936; q=dns/txt; s=iport; t=1540938497; x=1542148097; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FxGaZ0+uQ5gHRq4HtNhCFhXClN1qFR6ZB0G6ZKANGQU=; b=kriZ/cvolT9H4rTONvpXllMcCA/i5ayTerHDm+Xr0++ZMGM80BYMwTpx 3bSFrAzLvJM4OeGpHK1CEqWpRn6tH+o81uQlu7dBxc8pljZNhE+SbNlWt +HtSo61nvbi4vEILttbeAoS9yaU5p5lwov084CmHR3UDNyf30Qn0k55LS k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAACW2thb/5NdJa1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBggRmfxUTCoNsiBiOJpcggXoLAQEjhEkCF4MNIjQNDQEDAQECAQECbRwMhToBAQEDASMRPgcFBwQCAQgRBAEBAQICJgICAjAVCAgCBA4FG4MGAYF5CA+pMIEuhD9AhSQFgQuKXBeCAIE4H4JMgxsCAwGBR4MaMYImAohbU5VkCQKGaYodGIFThHeJf4x3igoCERSBJh04gVVwFWUBgkGCJheIXIU9AW+LIYEfAQE
X-IronPort-AV: E=Sophos;i="5.54,446,1534809600"; d="scan'208";a="193440556"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 22:28:16 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id w9UMSGh5024294 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Oct 2018 22:28:16 GMT
Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Oct 2018 17:28:16 -0500
Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1395.000; Tue, 30 Oct 2018 17:28:16 -0500
From: "Naiming Shen (naiming)" <naiming@cisco.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
CC: Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-chen-bfd-unsolicited@ietf.org" <draft-chen-bfd-unsolicited@ietf.org>
Subject: Re: WG Adoption for draft-chen-bfd-unsolicted
Thread-Topic: WG Adoption for draft-chen-bfd-unsolicted
Thread-Index: AQHUb5+E62EdVh/GO0aQbosNraNnAaU3OZaAgAAi/gCAAB0lgIABOoyA
Date: Tue, 30 Oct 2018 22:28:15 +0000
Message-ID: <9CFF62D9-2C54-4BCD-B667-8F126C3EEDC8@cisco.com>
References: <20181029155232.GN12336@pfrc.org> <75992c66b45345f59e420d832d1b54b8@XCH-ALN-001.cisco.com> <92F496D8-8260-4065-B03A-F967BC146324@cisco.com> <bb6394f856d64f8da62f9507086bd710@XCH-ALN-001.cisco.com>
In-Reply-To: <bb6394f856d64f8da62f9507086bd710@XCH-ALN-001.cisco.com>
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.156.165.87]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D7D38974D8B75E4A8F44A82462D8DF36@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/oCiz-wC2AwsCSosZQVvk8MLeNps>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Oct 2018 22:28:20 -0000

Les,

Just to clarify. There is not a “this issue”, there are multiple issues;-)

I think you are referring to the case of static routing BFD usage without requiring
the neighbor to install a bogus static route towards us.

But the main application here is in the public peering site, the BFD sessions can
be setup dynamically using this draft to avoid black hole traffic, the BGP peering
relation (needs configuration) is only with the RR server.

Regards,
- Naiming

> On Oct 29, 2018, at 8:42 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote:
> 
> Naiming -
> 
> I did not say that implementations had done exactly what you propose in this draft. I said:
> 
> " there are implementations which have addressed this issue w/o requiring any changes to their BFD implementation"
> 
> There is more than one way to solve this problem. :-)
> 
> I raise this point because an implementation which has already addressed the issue has little motivation to move to a different solution (such as you propose).
> Which is why I am OK if this is merely informational - but not otherwise.
> 
>   Les
> 
> 
>> -----Original Message-----
>> From: Naiming Shen (naiming)
>> Sent: Monday, October 29, 2018 6:58 PM
>> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
>> Cc: Jeffrey Haas <jhaas@pfrc.org>; rtg-bfd@ietf.org; draft-chen-bfd-
>> unsolicited@ietf.org
>> Subject: Re: WG Adoption for draft-chen-bfd-unsolicted
>> 
>> 
>> I’m not aware of an implementation taking in the inbound BFD packets,
>> then dynamically seting up a session to the received packet sender end-
>> point.
>> As Jeff mentioned Redback planed on this, but didn’t implement. So there
>> most
>> likely needs some BFD implementation changes.
>> 
>> Regards,
>> - Naiming
>> 
>>> On Oct 29, 2018, at 4:52 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com>
>> wrote:
>>> 
>>> The problem the draft addresses is valid and makes sense to address. But I
>> know there are implementations which have addressed this issue w/o
>> requiring any changes to their BFD implementation - so I am not sure how
>> popular this solution will be.
>>> 
>>> So long as this stays Informational I think it is fine to adopt. I would not be
>> as enthused if this is moved to Standards track.
>>> 
>>>  Les
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Rtg-bfd <rtg-bfd-bounces@ietf.org> On Behalf Of Jeffrey Haas
>>>> Sent: Monday, October 29, 2018 8:53 AM
>>>> To: rtg-bfd@ietf.org
>>>> Cc: draft-chen-bfd-unsolicited@ietf.org
>>>> Subject: WG Adoption for draft-chen-bfd-unsolicted
>>>> 
>>>> Working Group,
>>>> 
>>>> Reviewing my notes, I was remiss in sending out an adoption request for
>>>> draft-chen-bfd-unsolicted (Unsolicited BFD for Sessionless Applications).
>>>> 
>>>> https://datatracker.ietf.org/doc/draft-chen-bfd-unsolicited/
>>>> 
>>>> This relatively minor change from the RFC 5880 spec is implemented by at
>>>> least one vendor for static route configuration.  Its security
>>>> considerations already cover what I believe to be the main concern with
>> the
>>>> procedural change.
>>>> 
>>>> There's a minor point to resolve regarding the document's status -
>> currently
>>>> Informational - with our AD.
>>>> 
>>>> Please indicate whether you'd support adopting this draft as a Working
>>>> Group
>>>> document.
>>>> 
>>>> Authors, please indicate if you're aware of any applicable IPR on it.
>>>> 
>>>> This adoption request will also end on Friday, November 9, IETF 103
>> Friday.
>>>> 
>>>> -- Jeff & Reshad
>>> 
>