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

From: Uma Chunduri <[email-masked]>
Date: Fri, 8 Apr 2016 03:03:07 +0000

Les,

In-line [Uma]:

--
Uma C.

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, March 16, 2016 9:41 PM
To: Acee Lindem (acee); OSPF WG List
Subject: Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment"

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.

[Uma]: The whole point of the draft is,  not to define the format for the sub-TLVs so that it can be used  as per the sub-tlv type as set by the operator (for example service attribute/Label).  Sub-TLV has set of attribute length and attribute value in NBO.

IS-IS has taken a much more stringent approach to a similar request. 	

[Uma]: .. and hence unfortunately I see no body saw using it- in fact including you. For example https://tools.ietf.org/html/draft-ietf-isis-sbfd-discriminator-02 could have used GENAPP but rather resorted to Router capabilities (Remember IETF90 discussion around this).

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.

[Uma]: As I indicated earlier [I-D.ietf-ospf-transport-instance] can be definitely used if the information related to application need to be used there. If it is used for supporting routing one can use this TLV.

Without addressing both of these issues I cannot support the draft.

   Les

> -----Original Message-----
> From: OSPF [mailto:[email-masked]] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 8 Apr 2016 03:09:48 +0000

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:[email-masked]] 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 <[email-masked]>
 wrote:
> I agree with Les and share the same concerns.
>
> Peter
>
> On 3/17/16 05:40 , Les Ginsberg (ginsberg) wrote:
>> 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:
>>
>> 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.
>>
>>> 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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 8 Apr 2016 03:39:36 +0000

Uma -

> From: Uma Chunduri [mailto:[email-masked]]
> Sent: Thursday, April 07, 2016 8:03 PM
> To: Les Ginsberg (ginsberg); Acee Lindem (acee); OSPF WG List
> Subject: RE: WG Adoption Poll for "Using Operator-defined TLVs for Agile
> Service Deployment"
> 
> Les,
> 
> In-line [Uma]:
> 
> --
> Uma C.
> 
> 
> 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:
> 
> [Uma]: The whole point of the draft is,  not to define the format for the sub-
> TLVs so that it can be used  as per the sub-tlv type as set by the operator (for
> example service attribute/Label).  Sub-TLV has set of attribute length and
> attribute value in NBO.
> 
[Les:] Yes - I know. :-)
And I think this is a "disaster waiting to happen".

On this point I think we currently have no common ground.

   Les

> [Uma]: .. and hence unfortunately I see no body saw using it- in fact including
> you. For example https://tools.ietf.org/html/draft-ietf-isis-sbfd-
> discriminator-02 could have used GENAPP but rather resorted to Router
> capabilities (Remember IETF90 discussion around this).
> 
> 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.
> 
> [Uma]: As I indicated earlier [I-D.ietf-ospf-transport-instance] can be
> definitely used if the information related to application need to be used
> there. If it is used for supporting routing one can use this TLV.
> 
> 
>

---

From: Peter Psenak <[email-masked]>
Date: Fri, 08 Apr 2016 10:24:47 +0200

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.

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

thanks,
Peter

---

From: Uma Chunduri <[email-masked]>
Date: Sun, 10 Apr 2016 16:08:02 +0000

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:[email-masked]] 
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:
>>> 6822(MI)) so as to minimize the impact of the application 
>>> information flooding on the performance of the routing protocol.
>>>
>>>> application-specific information learned from other OSPF routers. 
>>>> In many respects, this has already been envisioned for OSPF Node Tags.

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 11 Apr 2016 22:22:28 +0000

Les,

In-line [Uma]:

--
Uma C.

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Thursday, April 07, 2016 8:40 PM
To: Uma Chunduri; Acee Lindem (acee); OSPF WG List
Subject: RE: WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment"

Uma -

> Subject: RE: WG Adoption Poll for "Using Operator-defined TLVs for 
> It is defining a way to utilize OSPF to send application information - 
> which is not something the protocol should be used to do.
> [Uma]: The whole point of the draft is,  not to define the format for 
> the sub- TLVs so that it can be used  as per the sub-tlv type as set 
> by the operator (for example service attribute/Label).  Sub-TLV has 
> set of attribute length and attribute value in NBO.
> 
[Les:] Yes - I know. :-)
And I think this is a "disaster waiting to happen".
[Uma]: I am really sorry you felt that way.
There are lot of things we can further improve in this case (including restricting the size of the sub-TLV and value field itself), but..
To me it’s good to have some balance  between deployment complexity and usability (remember OSPFv3 with IPSec - amazing thing but very few deployments and now we have RFC 6506/7166). No offence meant for the technology itself..

   Les

> [Uma]: .. and hence unfortunately I see no body saw using it- in fact 
> including you. For example 
> https://tools.ietf.org/html/draft-ietf-isis-sbfd-
> GENAPP further specifies that such information SHOULD be advertised by 
> a separate instance of the routing protocol (as specified in RFC 
> [Uma]: As I indicated earlier [I-D.ietf-ospf-transport-instance] can 
> be definitely used if the information related to application need to 
> be used there. If it is used for supporting routing one can use this TLV.
> 
> 
>

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 12 Apr 2016 19:09:14 +0000

Hi Acee,

I support adoption of the draft!

Cheers,
Jeff

>From: OSPF [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
>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
>

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 14 Apr 2016 08:34:06 +0000

Support the WG adoption of this doc (as a co-author).

Best regards,
Xiaohu

> Sent: Thursday, March 17, 2016 10:09 AM
> To: OSPF WG List
> 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
>

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 14 Apr 2016 08:24:03 -0700

I cannot support this draft.

As discussed in the wg last week, the best way to do this is to have  the
generic definition (genapps) in OSPF  as in ISIS. I am in the process of
reviving the ospf service distribution draft which has that purpose
embedded.

Thanks
Padma

On Thu, Apr 14, 2016 at 1:34 AM, Xuxiaohu <[email-masked]> wrote:

> Agile
> like a

---

From: "Wunan (Eric)" <[email-masked]>
Date: Fri, 15 Apr 2016 02:05:12 +0000

Hi Acee,

I think the motivation below makes sense. Actually this is the way people had already been doing, not only operators.

"One major benefit of using administrative tags rather
   than IANA defined TLVs or sub-TLVs to indicate different services is
   to facilitate the rapid deployment of new services without any need
   for the standardization of those TLVs or sub-TLVs.  However, there
   are some special use cases where the service to be advertised has one
   or more attributes which need to be advertised as well.  In such
   case, the administrative tag is not much applicable anymore"

Personally I wish one more generalized mechanism can exist instead of one Node tag and one proprietary TLV.
Anyway, I'd like to see this I-D can go further and "lot of things we can further improve" at the same time, as Uma mentioned.

Regards
Eric

> -----邮件原件-----
> 发件人: Acee Lindem (acee) [mailto:[email-masked]]
> 发送时间: 2016年3月17日 10:09
> 收件人: OSPF WG List
> 主题: [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.