Re: [OSPF] 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:ospf-bounces@ietf.org] 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:ospf-bounces@ietf.org] 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
> > OSPF@ietf.org
> > https://www.ietf.org/mailman/listinfo/ospf
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf