Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment"

 +1 to Peter's, Les's opinion here (as individual, no hat, not even a 
 surgical mask, Acee ;-) ...

 --- tony


 On Thu, 17 Mar 2016 08:17:55 +0100, Peter Psenak <ppsenak@cisco.com> 
 wrote:
> I agree with Les and share the same concerns.
>
> Peter
>
> On 3/17/16 05:40 , Les Ginsberg (ginsberg) wrote:
>> My opinion of the draft has not changed.
>>
>> It is defining a way to utilize OSPF to send application information 
>> - which is not something the protocol should be used to do.
>> Further, it leaves definition of the new codepoints and formats of 
>> the information advertised completely unspecified - the latest draft 
>> revision states:
>>
>> " The meaning of the operator-defined sub-TLV is totally opaque to 
>> OSPF
>>     and is defined by the network local policy and is controlled via
>>     configuration.  "
>>
>> How interoperability is achieved is not addressed at all.
>>
>> IS-IS has taken a much more stringent approach to a similar request.
>> RFC 6823 (GENAPP) requires that information sent in the generic 
>> container TLV MUST be based on a public specification - and that an 
>> application specific ID for the application using this mechanism be 
>> assigned by IANA. This addresses the interoperability issue.
>> GENAPP further specifies that such information SHOULD be advertised 
>> by a separate instance of the routing protocol (as specified in RFC 
>> 6822(MI)) so as to minimize the impact of the application information 
>> flooding on the performance of the routing protocol.
>>
>> Without addressing both of these issues I cannot support the draft.
>>
>>     Les
>>
>>
>>> -----Original Message-----
>>> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem
>>> (acee)
>>> Sent: Wednesday, March 16, 2016 7:09 PM
>>> To: OSPF WG List
>>> Subject: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs 
>>> for Agile
>>> Service Deployment"
>>>
>>> We’ve discussed this draft a number of times. In my opinion, it 
>>> seems like a
>>> useful mechanism if one envisions a generalized API between OSPF 
>>> and user
>>> and third-party applications to convey application-specific 
>>> information
>>> learned from other OSPF routers. In many respects, this has already 
>>> been
>>> envisioned for OSPF Node Tags. Please indicate your opinion on this 
>>> draft
>>> before March 31st, 2016.
>>>
>>> Thanks,
>>> Acee
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> OSPF@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ospf
>> _______________________________________________
>> OSPF mailing list
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
>>
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf