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

Les,

In-line [Uma]:

--
Uma C.

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] 
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 -

> -----Original Message-----
> From: Uma Chunduri [mailto:uma.chunduri@ericsson.com]
> 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.
> 
> 
> -----Original Message-----
> From: OSPF [mailto:ospf-bounces@ietf.org] 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.
> 
[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..

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

   Les

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