[OSPF] OSPF Operator-Defined TLVs (https://www.ietf.org/id/draft-chunduri-ospf-operator-defined-tlvs-01.txt)

"Acee Lindem (acee)" <acee@cisco.com> Mon, 19 October 2015 20:29 UTC

Return-Path: <acee@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3FFC21AC3B9 for <ospf@ietfa.amsl.com>; Mon, 19 Oct 2015 13:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wa8AJOfeyC94 for <ospf@ietfa.amsl.com>; Mon, 19 Oct 2015 13:29:44 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1063A1A9104 for <ospf@ietf.org>; Mon, 19 Oct 2015 13:29:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1204; q=dns/txt; s=iport; t=1445286584; x=1446496184; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=jPGdDsMMRpAObOuIKkEIc2hK+lQl2w97lJ7pcYbKjNw=; b=SbRJKEe8OI9JRbuHitgkK919jwuEL8iV4gackixqBDYryS+GK+jANmBK 63fk7MZZ++kbXq3iepF/MW58+t9UDHt7BDoES4KIJfoLE1XMc7F1Jxtl1 1uHH6VQz89Yc7Od8qsIJsU58yGN73J5RWDZM+p7dE0SlGDrHrIUX7HVU7 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.17,703,1437436800"; d="scan'208";a="37085108"
Received: from rcdn-core-12.cisco.com ([]) by rcdn-iport-7.cisco.com with ESMTP; 19 Oct 2015 20:29:43 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com []) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t9JKTgD4027606 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <ospf@ietf.org>; Mon, 19 Oct 2015 20:29:42 GMT
Received: from xch-rcd-015.cisco.com ( by XCH-ALN-012.cisco.com ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Oct 2015 15:29:25 -0500
Received: from xch-rcd-015.cisco.com ([]) by XCH-RCD-015.cisco.com ([]) with mapi id 15.00.1104.000; Mon, 19 Oct 2015 15:29:24 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: OSPF WG List <ospf@ietf.org>
Thread-Topic: OSPF Operator-Defined TLVs (https://www.ietf.org/id/draft-chunduri-ospf-operator-defined-tlvs-01.txt)
Thread-Index: AQHRCqzYT+PSKWZbDkygrQxSvdVsag==
Date: Mon, 19 Oct 2015 20:29:24 +0000
Message-ID: <D24ACB18.36F88%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: <40EF49080344D641BAB6C588A2AB9C07@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/ZTBW-FmDOmdiUE4LKjKPkZJcFWo>
Subject: [OSPF] OSPF Operator-Defined TLVs (https://www.ietf.org/id/draft-chunduri-ospf-operator-defined-tlvs-01.txt)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
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, 19 Oct 2015 20:29:45 -0000

This draft has been presented at two IETFs and while I don’t agree with
some of the proposed use cases as these applications reference should, if
fact, be standardized, I can see that the use case for local applications
could be compelling. This is the use where OSPF provides an API for local
applications to advertise application-specific information throughout the
routing domain and receive the same parameters from other routers running
that application. Since this is to support local applications generically,
one could see the reason to allow non-standard parameters to be flooded
opaquely (i.e., OSPF is used solely as a flooding mechanism).

Please take a look at the draft and indicate whether or not you feel the
OSPF WG should work on such a solution. If there is enough interest, we
will adopt it as a WG document.