Re: [OSPF] OSPF Operator-Defined TLVs (

"Acee Lindem (acee)" <> Mon, 19 October 2015 21:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9C5E91B2CC6 for <>; Mon, 19 Oct 2015 14:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YGT6LyTbFt4Z for <>; Mon, 19 Oct 2015 14:29:57 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D1881ACE45 for <>; Mon, 19 Oct 2015 14:29:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2428; q=dns/txt; s=iport; t=1445290195; x=1446499795; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6tBcmYTd9QMSkF/FOolnMHYhGRtZeahZ8g/ay9H2ppo=; b=i6kEDudbmfA+p8wc2aBWJvJOtxLMtPq/FCtd0bTPsDMvP1acPftfk+i4 kuBaT7rSsEuKW55TaHyXhO5OOFCcotxZ0bOqNdp/Zqu+QzrsB9mXtkPIW B3OuFEWDadnpT7cpwzLXyWTenIdlzT8Cg+TzpjHwTdA2GzgwbXjXRr3J1 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.17,704,1437436800"; d="scan'208";a="199459697"
Received: from ([]) by with ESMTP; 19 Oct 2015 21:29:54 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t9JLTsZ1019152 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2015 21:29:54 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Oct 2015 16:29:36 -0500
Received: from ([]) by ([]) with mapi id 15.00.1104.000; Mon, 19 Oct 2015 16:29:36 -0500
From: "Acee Lindem (acee)" <>
To: Jeff Tantsura <>, OSPF WG List <>
Thread-Topic: [OSPF] OSPF Operator-Defined TLVs (
Thread-Index: AQHRCq9PrW1ep3oWb0OUXrXKrQCznJ5zZiKA
Date: Mon, 19 Oct 2015 21:29:35 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
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: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OSPF] OSPF Operator-Defined TLVs (
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Oct 2015 21:29:58 -0000

Speaking as a WG contributor,

I tend to agree as long as one envisions a flooding API for local
applications. Hence, I would support this work. I don’t agree with all the
use cases as I would think that TE parameters should be standardized.


On 10/19/15, 4:47 PM, "Jeff Tantsura" <> wrote:

>Hi Acee,
>I think the document describes a real and a valid use case, rather useful
>when opaque data needs to be distributed in an IGP domain.
>Hence support further progress.
>On 10/19/15, 23:29, "OSPF on behalf of Acee Lindem (acee)"
>< on behalf of> wrote:
>>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
>>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.
>>OSPF mailing list