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

Uma Chunduri <uma.chunduri@ericsson.com> Wed, 06 January 2016 20:44 UTC

Return-Path: <uma.chunduri@ericsson.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70D71A0389 for <ospf@ietfa.amsl.com>; Wed, 6 Jan 2016 12:44:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJkapEanKfag for <ospf@ietfa.amsl.com>; Wed, 6 Jan 2016 12:44:50 -0800 (PST)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CBD71A03FF for <ospf@ietf.org>; Wed, 6 Jan 2016 12:44:50 -0800 (PST)
X-AuditID: c618062d-f79d16d000001b1c-af-568d7af168ee
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 9E.D2.06940.1FA7D865; Wed, 6 Jan 2016 21:37:05 +0100 (CET)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Wed, 6 Jan 2016 15:44:49 -0500
From: Uma Chunduri <uma.chunduri@ericsson.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, OSPF WG List <ospf@ietf.org>
Thread-Topic: OSPF Operator-Defined TLVs (https://www.ietf.org/id/draft-chunduri-ospf-operator-defined-tlvs-01.txt)
Thread-Index: AQHRCqzYT+PSKWZbDkygrQxSvdVsap538ayAgAcBl7CAASJxcIAA6PXAgABnSwCAbgovwA==
Date: Wed, 6 Jan 2016 20:44:48 +0000
Message-ID: <1B502206DFA0C544B7A60469152008635145BD46@eusaamb105.ericsson.se>
References: <D24ACB18.36F88%acee@cisco.com> <1a3c0c41dfef4808aa02c34762bcbff1@XCH-ALN-001.cisco.com> <787AE7BB302AE849A7480A190F8B933008C87A3A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6d54006a312844d5a749ec5cd7fd3fdc@XCH-ALN-001.cisco.com> <787AE7BB302AE849A7480A190F8B933008C8896D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <D25693F4.39AC6%acee@cisco.com>
In-Reply-To: <D25693F4.39AC6%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.9]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyuXRPiO7Hqt4wg9MdshaT385jttjwZyO7 xeG3T9ktWu7dY3dg8ZjyeyOrx5IlP5k8Wp6dZAtgjuKySUnNySxLLdK3S+DKmLHnC1vBo7CK 5UvesjYwHgnpYuTgkBAwkTh1QaCLkRPIFJO4cG89WxcjF4eQwBFGiY/TTjFDOMsYJVpb+hlB qtgE9CQ+Tv3JDpIQEdjFKNG9aRsTSEJYoESic8oSdpCpIgKlEv0/7EDCIgJhEueXz2IECbMI qEgcfhAFEuYV8JXY1DSHBWL+ZyaJva+/MYMkOAV0JLZOXwA2khHoou+n1oDZzALiEreezGeC uFRAYsme88wQtqjEy8f/WCFsRYl9/dPBTmAW0JRYv0sfolVRYkr3Q3aIvYISJ2c+YZnAKDoL ydRZCB2zkHTMQtKxgJFlFSNHaXFBTm66kcEmRmCcHJNg093BeH+65yFGAQ5GJR7eD149YUKs iWXFlbmHGCU4mJVEeDWEe8OEeFMSK6tSi/Lji0pzUosPMUpzsCiJ8wpKN4YJCaQnlqRmp6YW pBbBZJk4OKUaGA+9P3ns9UObr3tXs54+Hs95v3m1Y9/uy3eKLN6qBp2y+vdBfI3Z/Hj+RrVk fe0ZHfb3LvxR/B5XeyfzSI/ouxkS698t9P1U8p9x9/ES/uM3q3qsCnfee37+7cOebdtvzfB0 +3zJk088Iqxpx/d5j9Uf6MZe/XxWjfGITRl/ltiOn0u3vanXOX9XiaU4I9FQi7moOBEActpm 4o8CAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/vV2DisVgmPG7c8mDZxrQ_L0fRy0>
Subject: Re: [OSPF] OSPF Operator-Defined TLVs (https://www.ietf.org/id/draft-chunduri-ospf-operator-defined-tlvs-01.txt)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jan 2016 20:44:52 -0000

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