Re: [OSPF] 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".

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