Re: [OSPF] OSPF Operator-Defined TLVs (https://www.ietf.org/id/draft-chunduri-ospf-operator-defined-tlvs-01.txt)

["Les Ginsberg (ginsberg)" <[e-mail]>]

Mohamed -

The data can certainly be opaque to OSPF since OSPF is merely acting as a transport. But it cannot be opaque to the application which is supposed to process this data. The draft currently says:

"There is no need for any specification to define any operator-defined
   sub-TLV.  "

This is what causes me to comment about the need for "clairvoyance". In order for interoperability to occur there MUST be a common understanding of the format of the data by the originator and the receiver. To say that this does not need to be specified anywhere makes this completely non-functional. The specification is certainly not an OSPF specification - but there clearly needs to be one.

   Les


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Tuesday, October 27, 2015 12:08 AM
> To: Les Ginsberg (ginsberg); Acee Lindem (acee); OSPF WG List
> Subject: RE: OSPF Operator-Defined TLVs (https://www.ietf.org/id/draft-
> chunduri-ospf-operator-defined-tlvs-01.txt)
> 
> Hi Les,
> 
> Thank you for raising these points, especially the one about abuse (misuse).
> 
> The data is sent as an opaque value. The data may be validated by a receiver
> but this is deployment-specific. Likewise, the specification does not assume
> an order of the TLVs as this is also left to the taste of the operator.
> 
> The draft is not frozen. The text will be worked out for better clarity and a
> discussion (including some recommendation to avoid misuse of the proposal)
> will be considered.
> 
> The issues you raised will be part of our list of issues to handle once the draft
> is adopted as a WG document.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : OSPF [mailto:[e-mail]] De la part de Les Ginsberg
> > (ginsberg)
> > Envoyé : jeudi 22 octobre 2015 22:04
> > À : Acee Lindem (acee); OSPF WG List
> > Objet : Re: [OSPF] OSPF Operator-Defined TLVs
> > (https://www.ietf.org/id/draft-chunduri-ospf-operator-defined-tlvs-01.
> > txt)
> >
> > I have two major issues w the draft as it currently stands:
> >
> > 1)It seems to depend upon clairvoyance for interoperability since it
> > claims that no standardization of the format of the values associated
> > w an operator defined TLV is necessary.  Note that here I am NOT
> > talking about what specific code point is assigned to a particular use
> > case - I am talking about the format of the data sent.
> >
> > 2)As it opens the door to use/abuse of the protocol to send
> > information which is not used by the protocol it does not in any way
> > address the impact this could have on the operation of the protocol.
> > This is a major omission.
> >
> > As an example, IS-IS has provided similar  functionality in RFC 6823 -
> > but the document discusses restrictions  restrictions on the use of
> > this extension - notable in Section 7.
> >
> > Unless the authors are prepared to address these issues I cannot
> > support the document.
> >
> >    Les
> >
> > > -----Original Message-----
> > > From: OSPF [mailto:[e-mail]] On Behalf Of Acee Lindem
> > > (acee)
> > > Sent: Monday, October 19, 2015 1:29 PM
> > > To: OSPF WG List
> > > Subject: [OSPF] OSPF Operator-Defined TLVs
> > (https://www.ietf.org/id/draft-
> > > chunduri-ospf-operator-defined-tlvs-01.txt)
> > >
> > > This draft has been presented at two IETFs and while I don’t agree
> > > with
> > some
> > > of the proposed use cases as these applications reference should, if
> > fact, be
> > > standardized, I can see that the use case for local applications
> > > could
> > be
> > > compelling. This is the use where OSPF provides an API for local
> > applications
> > > to advertise application-specific information throughout the routing
> > domain
> > > and receive the same parameters from other routers running that
> > > application. Since this is to support local applications
> > > generically,
> > one could
> > > see the reason to allow non-standard parameters to be flooded
> > > opaquely (i.e., OSPF is used solely as a flooding mechanism).
> > >
> > > Please take a look at the draft and indicate whether or not you feel
> > > the
> > OSPF
> > > WG should work on such a solution. If there is enough interest, we
> > > will
> > adopt
> > > it as a WG document.
> > >
> > > 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