[OSPF] "OSPF Link Overhead" - draft-ietf-ospf-link-overload-01

"Acee Lindem (acee)" <acee@cisco.com> Mon, 27 June 2016 14:00 UTC

Return-Path: <acee@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6521212D14F; Mon, 27 Jun 2016 07:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id N48f2d6GHyCv; Mon, 27 Jun 2016 07:00:33 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB42412B04D; Mon, 27 Jun 2016 07:00:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1142; q=dns/txt; s=iport; t=1467036032; x=1468245632; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=WOXnUfYl5FmyW6MHaoGXRyD3OAz6LwjYbdcScv44g6c=; b=McICvDFknBP5KTV0A2s41/j/PKckibX5O7bZ52KaMzixjb0xUVSXWhtI a1zHyywMkQtyHGjFrJKP35RS97G522oc8ZcDOy1mJmr7961urtqKm8Pxa FYne5aY/+ap/4f6U3dRQ/QVx+T4WVxRKBF2xoECDs9iQXYGaDC/8rPyMe 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.26,536,1459814400"; d="scan'208";a="117333058"
Received: from alln-core-1.cisco.com ([]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jun 2016 14:00:31 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com []) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5RE0VMS026639 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jun 2016 14:00:31 GMT
Received: from xch-rtp-015.cisco.com ( by XCH-RTP-015.cisco.com ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Jun 2016 10:00:30 -0400
Received: from xch-rtp-015.cisco.com ([]) by XCH-RTP-015.cisco.com ([]) with mapi id 15.00.1210.000; Mon, 27 Jun 2016 10:00:30 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "draft-ietf-ospf-link-overload@ietf.org" <draft-ietf-ospf-link-overload@ietf.org>
Thread-Topic: "OSPF Link Overhead" - draft-ietf-ospf-link-overload-01
Thread-Index: AQHR0HxE7KebqyJD1EGc17C2dKix0Q==
Date: Mon, 27 Jun 2016 14:00:30 +0000
Message-ID: <D396A9BF.66CD8%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <81316835CD3025459A5576EE57EC0584@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/j0YFlD01_G7wTU7XFMQZ88Ht8Nc>
Cc: OSPF WG List <ospf@ietf.org>
Subject: [OSPF] "OSPF Link Overhead" - draft-ietf-ospf-link-overload-01
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2016 14:00:35 -0000

Speaking as WG member:

One area of mild contention with this draft has been whether the
advertisement that the link is being taken out of service needs to be
advertised beyond the link endpoint router (which will take the
appropriate action of advertising the maximum link metric in the reverse
direction). We have gotten somewhat entangled into use case discussions
and whether or not this is really necessary.

What I’d like to propose is that offer the alternative of advertising the
OSPF RI LSA with link-scope (fully supported by RFC 7770). This way, the
advertisement could be restricted to the local link in situations where
the knowledge doesn’t really need to go anywhere else. Note that the
current text doesn’t prevent this so this is merely a matter of describing
the use case.