Re: [OSPF] OSPF Operator-Defined TLVs (

Jeff Tantsura <> Mon, 19 October 2015 20:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 781231ACDA1 for <>; Mon, 19 Oct 2015 13:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kyX1kMf9f2bY for <>; Mon, 19 Oct 2015 13:47:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E3DA01A8F37 for <>; Mon, 19 Oct 2015 13:47:07 -0700 (PDT)
X-AuditID: c618062d-f79ef6d000007f54-45-5624f64803ce
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id F7.47.32596.846F4265; Mon, 19 Oct 2015 15:55:21 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Mon, 19 Oct 2015 16:47:04 -0400
From: Jeff Tantsura <>
To: "Acee Lindem (acee)" <>, OSPF WG List <>
Thread-Topic: [OSPF] OSPF Operator-Defined TLVs (
Thread-Index: AQHRCq9PrW1ep3oWb0OUXrXKrQCznA==
Date: Mon, 19 Oct 2015 20:47:03 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyuXRPiK7nN5Uwg4diFpPfzmO2aLl3j92B yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgyvh/aQdrwS2+ionNXxgbGFfwdTFyckgImEj8 WtbGCmGLSVy4t56ti5GLQ0jgKKPE+Xtn2CGc5YwSvycvZgepYhMwkPj/7TgLiC0i4C4xa+Vh ZhBbWKBaYk7XRWaIeI3E5y/bmCBsPYm3846CxVkEVCV+nXsCto1XwF5i9tJOsBpGoM3fT60B s5kFxCVuPZnPBHGRgMSSPeeZIWxRiZeP/4H1igroSpzY3gkVV5KY8/oakM0B1KspsX6XPoRp LdF2tBRioqLElO6H7BBbBSVOznzCMoFRdBaSZbMQmmchNM9C0jwLSfMCRtZVjBylxalluelG BpsYgdFxTIJNdwfjnpeWhxgFOBiVeHgX+KmECbEmlhVX5h5ilOZgURLn3b/kfqiQQHpiSWp2 ampBalF8UWlOavEhRiYOTqkGRo8vd/hvnzT+2Mm9fvnypSU6Mrkbpi12dA1ytM3Q3u10/KOQ +d0MsacvDypFmPbUtjLt/NjOy/z7t0Ljoqpan8fej+q9H+4IsCsN9TbgeyS45++WFu41dyr/ KFtVL4x6HF/+JHbrzRsN1t0c1dp7uFvTWfbvuGyaL7hQfPv5RfvPnnFzYOE6qcRSnJFoqMVc VJwIAJk9sspvAgAA
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 20:47:09 -0000

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 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.

>OSPF mailing list