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

Hi Les,

IMHO, there are some fundamental differences between the usage of the Operator-defined Sub-TLV Container TLV and the usage of the GENEINFO TLV as defined in RFC6823:

1)	In the former approach, the application data is conveyed in the form of Operator-defined Sub-TLVs contained in the Operator-defined Sub-TLV Container TLV. In the latter approach, the application data is conveyed in form of an < Application ID, Application IP Address Info, Additional Application-Specific Info> tuple contained in the GENEINFO TLV. The use of sub-TLV within the GENE-INFO TLV is optional according to RFC6823.

2)	In the former approach, applications are indicated by the codepoints of the Operator-defined Sub-TLVs. In the latter approach, applications are indicated by the application-IDs. Furthermore, codepoints of Operator-defined Sub-TLVs are assigned by operators themselves rather than IANA. In contrast, application IDs must be assigned by IANA.

Best regards,
Xiaohu

> -----Original Message-----
> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
> Sent: Friday, October 23, 2015 4:04 AM
> To: Acee Lindem (acee); OSPF WG List
> Subject: 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