IETF Logo Mail Archive

Re: Mirja Kühlewind's Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS)

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Tue, 03 May 2016 13:40 UTC

Return-Path: <cpignata@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 C2FBB12B010; Tue, 3 May 2016 06:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level:
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MlA_830ZrQi; Tue, 3 May 2016 06:40:42 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A21128874; Tue, 3 May 2016 06:40:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3731; q=dns/txt; s=iport; t=1462282841; x=1463492441; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IaxUS6IpgqTF5BNpoE20rAp603m4Y2RJ8M3bd0TZjsg=; b=J9axzQ+yx/5kbS+j8XC0L2otDLpx192rIHQOXWcX18l2DlmWHLeoNQzm v8PnCPPcBMv3JsOVN6BkiVgJB+o98iv1/1coefVyJ9tSVlXeIMZIkwB00 BAA0OLvftZlAiSsIDqs1/kcVkqR+fvYz7+rXqPCWGkmIzpz5wJtgrZssi E=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BOBAA4qShX/4cNJK1fgzhTfQa1XoIfgg8OgXUihW4CgUE4FAEBAQEBAQFlJ4RBAQEBAwEjVgULAgEIDgoqAgIyGgsCBA4FDogUCA6qS5EXAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQQEhiCBdoJXhBERAQZIgk6CWQWHeJAeAYMngWdtiBwKgV6ETYhdiUCFcQEeAUOCNoE1bAGHBjZ/AQEB
X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="asc'?scan'208";a="103921650"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 May 2016 13:40:40 +0000
Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u43DeeK7005254 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 13:40:40 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 09:40:39 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 3 May 2016 09:40:39 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS)
Thread-Topic: Mirja Kühlewind's Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS)
Thread-Index: AQHRpR8YB75iFhnPVECZQ0i//enE0Z+ne5KA
Date: Tue, 03 May 2016 13:40:39 +0000
Message-ID: <EC687254-EEDA-4EFF-B01B-757449183CED@cisco.com>
References: <20160503093512.7446.68991.idtracker@ietfa.amsl.com>
In-Reply-To: <20160503093512.7446.68991.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.150.48.199]
Content-Type: multipart/signed; boundary="Apple-Mail=_33A1349A-E6FC-445C-9658-EDE894D54844"; protocol="application/pgp-signature"; micalg="pgp-sha256"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-bfd/te4u8isI_wdXicgXYGNIlCE4q6k>
Cc: The IESG <iesg@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-seamless-base@ietf.org" <draft-ietf-bfd-seamless-base@ietf.org>, "bfd-chairs@ietf.org" <bfd-chairs@ietf.org>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <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, 03 May 2016 13:40:44 -0000

Hi, Mirja,

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

More seriously, please see inline.

> On May 3, 2016, at 5:35 AM, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-bfd-seamless-base-09: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> As S-BFD has no initiation process anymore it is not guarenteed that the
> receiver/responder actually exists. That means that packets could float
> (uncontrolled) in the network or even outside of the adminstrative domain
> (e.g. due to configuration mistakes). From my point of view this document
> should recommend/require two things:
> 

We have called out the misconfiguration — however:

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

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

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

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

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

Thoughts?

Thanks,

— Carlos.

> 
> 
>

v2.23.0 | Report a Bug | By Email