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

[Uma Chunduri <[e-mail]>]

Hi Peter,

I would re-clarify on the point you raised below.
My response in-line [Uma]:

--
Uma C.

-----Original Message-----
From: Peter Psenak [mailto:[e-mail]] 
Sent: Friday, April 08, 2016 1:25 AM
To: Uma Chunduri; prz
Cc: OSPF WG List
Subject: Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment"

Hi Uma,

I still have a fundamental problem with leaving the sub-TLV definition to the operator. If the operator really wants to do define something proprietary, we have plenty of experimental/reserved code points in RI TLV space.

[Uma]: This would enable vendor agnostic approach to provision a local policy ( sub-tlv code point & associated data in NBO) to advertise in OSPF domain. I don't think this can be achieved in a structured fashion with experimental TLV.  So this would help give a structured information for the data which is deployment specific but vendor neutral implementation.

I just don't see a point of standardizing a container that is used to advertise proprietary sub-TLVs.

thanks,
Peter


On 4/8/16 05:09 , Uma Chunduri wrote:
> Tony,  Peter,
>
> Also  please note the following changes are made per last WG Adoption call:
>
> 1.  " Dissemination of dynamic information" Information is removed like location information for Mobile OSPF routers.	
>
> 2. Section 3 - Applicability has been added
>
> 3. Section 6 Last paragraph has been added clarifying information about transport instance usage.
>
> --
> Uma C.
>
>
> -----Original Message-----
> From: OSPF [mailto:[e-mail]] On Behalf Of prz
> Sent: Thursday, March 17, 2016 12:30 PM
> To: Peter Psenak
> Cc: OSPF WG List
> Subject: 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 <[e-mail]>
>   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:[e-mail]] 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ospf
>>> _______________________________________________
>>> OSPF mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ospf
>>>
>>
>> _______________________________________________
>> OSPF mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ospf
>
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf
>