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

From: Jeff Tantsura <[email-masked]>
Date: Mon, 19 Oct 2015 20:47:03 +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.

Cheers,
Jeff

On 10/19/15, 23:29, "OSPF on behalf of Acee Lindem (acee)" <[email-masked] on behalf of [email-masked]> 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.
>
>Thanks,

Thanks!
>Acee 
>
>
>
>       
>
>_______________________________________________
>OSPF mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ospf

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 19 Oct 2015 21:29:35 +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.

Thanks,
Acee 

On 10/19/15, 4:47 PM, "Jeff Tantsura" <[email-masked]> 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.
>On 10/19/15, 23:29, "OSPF on behalf of Acee Lindem (acee)"
><[email-masked] on behalf of [email-masked]> wrote:
>

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 19 Oct 2015 22:42:44 +0000

Hi Acee,

Plz see in-line [Uma]:

--
Uma C.

-----Original Message-----
From: OSPF [mailto:[email-masked]] 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 (https://www.ietf.org/id/draft-chunduri-ospf-operator-defined-tlvs-01.txt)

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.

Thanks,
Acee 

On 10/19/15, 4:47 PM, "Jeff Tantsura" <[email-masked]> 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.
>>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.
>>
>>Thanks,
>
>Thanks!
>>Acee
>>
>>
>>
>>       
>>