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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 19 Oct 2015 20:29:24 +0000

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

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 21 Oct 2015 01:16:48 +0000

Hi Acee,

I (as a co-author) feel this draft describes a useful approach for local applications to flood non-standard parameters opaquely and therefore the OSPF WG should work on it.

Best regards,
Xiaohu (Tiger)

> -----Original Message-----
> From: OSPF [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
> Sent: Tuesday, October 20, 2015 4:29 AM
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 21 Oct 2015 21:52:12 +0000

Hi Tiger, Uma, 

I agree - I just don’t want this to evolve into a standard way to
circumvent standardization of various router parameters ;^). Even if there
is no way to prevent a vendor for using the mechanism for this purpose, we
don’t want to endorse this by claiming it as a use case.

Note that the local application use case ties nicely to the transport
instance draft 
(https://tools.ietf.org/id/draft-ietf-ospf-transport-instance-11.txt).
Specifically, with the remote-neighbor capability, one can use an instance
only including the nodes running the local application and requiring
exchange of flooded information. In conjunction with transport instance,
I’d actually considered a similar encoding.

Thanks,
Acee 

On 10/20/15, 9:16 PM, "Xuxiaohu" <[email-masked]> wrote:

>Hi Acee,
>
>I (as a co-author) feel this draft describes a useful approach for local
>applications to flood non-standard parameters opaquely and therefore the
>OSPF WG should work on it.
>
>Best regards,
>Xiaohu (Tiger)
>
>>some of

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 22 Oct 2015 20:04:00 +0000

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

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

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 27 Oct 2015 03:38:50 +0000

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

> From: OSPF [mailto:[email-masked]] 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
> 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.
> 
> > (https://www.ietf.org/id/draft-
> > 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,
> > 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
> >
> >
> >
> >
> >

---

From: <[email-masked]>
Date: Tue, 27 Oct 2015 06:54:07 +0000

Hi Acee, all, 

I support this draft. (I'm co-author)

The proposed approach allows to disseminate information that is deployment-specific without overloading IANA to maintain specific registries. 

Cheers,
Med

> -----Message d'origine-----
> De : OSPF [mailto:[email-masked]] De la part de Acee Lindem (acee)
> Envoyé : lundi 19 octobre 2015 22:29
> À : OSPF WG List
> Objet : [OSPF] OSPF Operator-Defined TLVs (https://www.ietf.org/id/draft-

---

From: <[email-masked]>
Date: Tue, 27 Oct 2015 07:07:56 +0000

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

> De : OSPF [mailto:[email-masked]] 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
> 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.
> 
> some
> one could
> OSPF

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 27 Oct 2015 18:08:11 +0000

Hi Acee,

	>Note that the local application use case ties nicely to the transport instance draft (https://tools.ietf.org/id/draft-ietf-ospf-transport-instance-11.txt).
	> Specifically, with the remote-neighbor capability, one can use an instance only including the nodes running the local application and requiring 
              > exchange of flooded information. In conjunction with transport instance, I’d actually considered a similar encoding.

We have presented this point in earlier meetings. 

" It’s reasonable that non-routing information should be advertised in a non-routing instance of OSPF as defined in https://tools.ietf.org/html/draft-ietf-ospf-transport-instance-11 so as to minimize the impact on the operation of routing."

"However, since the information contained in the Operator Defined TLV may be related to the routing, whether or not using a non-routing  instance to flood the OD TLVs should be determined by operators according to the information to be conveyed by the OD  sub-TLV."

Thx!

--
Uma C.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 28 Oct 2015 00:18:45 +0000

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

> From: [email-masked]
> [mailto:[email-masked]]
> 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-
> 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.
> 
> > 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.
> >
> > > with
> > > standardized, I can see that the use case for local applications
> > > could
> > be
> > > see the reason to allow non-standard parameters to be flooded
> > > the
> > > WG should work on such a solution. If there is enough interest, we
> > > will
> > adopt
> > > it as a WG document.
> > >
> > > Thanks,
> > > Acee
> > >
> > >
> > >
> > >
> > >

---

From: <[email-masked]>
Date: Wed, 28 Oct 2015 14:23:22 +0000

Hi Les,

Please see inline. 

Cheers,
Med

> De : Les Ginsberg (ginsberg) [mailto:[email-masked]]
> Envoyé : mercredi 28 octobre 2015 01:19
> À : BOUCADAIR Mohamed IMT/OLN; Acee Lindem (acee); OSPF WG List
> Objet : RE: OSPF Operator-Defined TLVs (https://www.ietf.org/id/draft-
> The data can certainly be opaque to OSPF since OSPF is merely acting as a
> transport.

[Med] Yes, this is the intent of this draft.

 But it cannot be opaque to the application which is supposed to
> process this data.

[Med] Agree. The application that needs to consume the data is likely to implement some validation checks. We consider those as being deployment-specific. The validation may be controlled via configuration as mentioned in the draft. I do agree this is something that needs to be discussed further in the next iteration of the draft.

> "There is no need for any specification to define any operator-defined

[Med] This text is confusing. The structure of the TLV needs to be specified (follows Section 2.1 of [RFC4970]) + further data verification may be implemented either by the OSPF speaker or/and the application that will consume the data. The text will be reworded accordingly.  

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

[Med] I hear you. Still, we trust the operator to enforce policies and validation checks that will be consistent so that the data conveyed in an OD TLV can be consumed by the target application. The exact details of which checks are needed to make sure the data is appropriately formatted will depend on its use case. 

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 28 Oct 2015 19:17:03 +0000

Hi Uma, Med,

I think that the draft needs more guidance as to how this mechanism should
be used. The draft still implies it could be used in lieu of standardizing
what would appear to be parameters that, in fact, should be standardized.
For example, it is unclear why we would not want to standardize the
parameters listed under “Dissemination of dynamic information”. This
mechanism really should only be used for local applications or
non-standard commercial applications. For the latter, these applications
should allow the sub-TLV code points to be configured to prevent conflicts
between local and other commercial applications deployed in the same
routing domain. 

Thanks,
Acee 

On 10/28/15, 10:23 AM, "[email-masked]"
<[email-masked]> wrote:

>[Med] Agree. The application that needs to consume the data is likely to
>implement some validation checks. We consider those as being
>deployment-specific. The validation may be controlled via configuration
>as mentioned in the draft. I do agree this is something that needs to be
>discussed further in the next iteration of the draft.
>
>[Med] This text is confusing. The structure of the TLV needs to be
>specified (follows Section 2.1 of [RFC4970]) + further data verification
>may be implemented either by the OSPF speaker or/and the application that
>will consume the data. The text will be reworded accordingly.
>
>[Med] I hear you. Still, we trust the operator to enforce policies and
>validation checks that will be consistent so that the data conveyed in an
>OD TLV can be consumed by the target application. The exact details of
>which checks are needed to make sure the data is appropriately formatted
>will depend on its use case.
>
>> 
>>    Les
>> 
>> 
>> > The draft is not frozen. The text will be worked out for better
>>clarity
>> and a
>> > > > of the proposed use cases as these applications reference should,
>>if
>> > > fact, be
>> > > > to advertise application-specific information throughout the
>>routing
>> > > domain