Re: [OSPF] OSPF Operator-Defined TLVs (

Uma Chunduri <> Mon, 19 October 2015 22:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 290EC1AD358 for <>; Mon, 19 Oct 2015 15:42:49 -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 zy5BRHcMXAx5 for <>; Mon, 19 Oct 2015 15:42:47 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 35F9C1B2C95 for <>; Mon, 19 Oct 2015 15:42:47 -0700 (PDT)
X-AuditID: c618062d-f79ef6d000007f54-0b-56251162256c
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 7C.AC.32596.26115265; Mon, 19 Oct 2015 17:50:59 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Mon, 19 Oct 2015 18:42:45 -0400
From: Uma Chunduri <>
To: "Acee Lindem (acee)" <>, Jeff Tantsura <>, OSPF WG List <>
Thread-Topic: [OSPF] OSPF Operator-Defined TLVs (
Thread-Index: AQHRCq9PrW1ep3oWb0OUXrXKrQCznJ5zZiKAgAAA3QA=
Date: Mon, 19 Oct 2015 22:42:44 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyuXRPlG6yoGqYwcpV3BaT385jtlizawKj Rcu9e+wOzB5Tfm9k9Viy5CeTx5fLn9kCmKO4bFJSczLLUov07RK4Mi63JRQckq14dvg8awPj A5kuRk4OCQETie4jjYwQtpjEhXvr2boYuTiEBI4ySrT8fMgK4SxnlNj/7AQLSBWbgJ7Ex6k/ 2UFsEYFSiUkrb4DFmQWqJRp7+8DiwkD248+v2SBqaiQ+f9nGBGFbSVzt6WIFsVkEVCUWXd8L Vs8r4Ctxc8dasDlCAokSe5pngfVyCuhIbFt5FqyGEei676fWMEHsEpe49WQ+E8TVAhJL9pxn hrBFJV4+/scKYStK7OufDtTLAVSvKbF+lz5Eq6LElO6HUGsFJU7OfMIygVFsFpKpsxA6ZiHp mIWkYwEjyypGjtLi1LLcdCODTYzAqDkmwaa7g3HPS8tDjAIcjEo8vAv8VMKEWBPLiitzDzFK c7AoifPuX3I/VEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjXM5dDeGvH/gWXD4/kbdkzvn5 bGqdTzLkvYGRzTw/6NfS5dcTS5zUP/5a8a9v8Ryl6LsrP8t5zrr1btOeS0Vtc2Nyj84UKX3/ /Nxnhqo9AbvLpj6riAwyENbbM68szNP65ZWUBdY3tx84sjhCaleMM1+Pe25T+caNv5pCmN48 FfV8/+nBQYZtSizFGYmGWsxFxYkAU9m5bHsCAAA=
Archived-At: <>
Cc: "" <>
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 22:42:49 -0000

Hi Acee,

Plz see in-line [Uma]:

Uma C.

-----Original Message-----
From: OSPF [] On Behalf Of Acee Lindem (acee)
Sent: Monday, October 19, 2015 2:30 PM
To: Jeff Tantsura; OSPF WG List
Subject: Re: [OSPF] OSPF Operator-Defined TLVs (

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. 

[Uma]: Thanks Acee for your views and the support.

I don’t agree with all the use cases as I would think that TE parameters should be standardized.

[Uma]: I see (from offline discussion), you were talking about the particular use case of location information to change the TE metrics by the controller. 
We have added that use case (came from one of the operators) in the 01 version while describing the elaborate use cases.  
We can remove this and add it as TE TLV (as a separate document) with your specific inputs later, if we have WG consensus on the rest of the document.


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

OSPF mailing list