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

Hi Acee,

Thanks for your suggestions. 
Took care of the comments below and other in WG and Posted the new version.

--
Uma C.

-----Original Message-----
From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, October 28, 2015 12:17 PM
To: mohamed.boucadair@orange.com; Les Ginsberg (ginsberg); OSPF WG List
Subject: Re: [OSPF] OSPF Operator-Defined TLVs (https://www.ietf.org/id/draft-chunduri-ospf-operator-defined-tlvs-01.txt)

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, "mohamed.boucadair@orange.com"
<mohamed.boucadair@orange.com> wrote:

>Hi Les,
>
>Please see inline.
>
>Cheers,
>Med
>
>> -----Message d'origine-----
>> De : Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] 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-
>> chunduri-ospf-operator-defined-tlvs-01.txt)
>> 
>> Mohamed -
>> 
>> 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.
>
> The draft currently says:
>> 
>> "There is no need for any specification to define any operator-defined
>>    sub-TLV.  "
>> 
>
>[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.
>
>> 
>>    Les
>> 
>> 
>> > -----Original Message-----
>> > From: mohamed.boucadair@orange.com
>> > [mailto:mohamed.boucadair@orange.com]
>> > 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: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

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf