IETF Logo Mail Archive

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

<mohamed.boucadair@orange.com> Wed, 28 October 2015 14:23 UTC

Return-Path: <mohamed.boucadair@orange.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 9B32B1B556C for <ospf@ietfa.amsl.com>; Wed, 28 Oct 2015 07:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 raV7pvS8_tNh for <ospf@ietfa.amsl.com>; Wed, 28 Oct 2015 07:23:25 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66B21B556B for <ospf@ietf.org>; Wed, 28 Oct 2015 07:23:24 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 211B926425A; Wed, 28 Oct 2015 15:23:23 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.58]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id F258F35C048; Wed, 28 Oct 2015 15:23:22 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0248.002; Wed, 28 Oct 2015 15:23:22 +0100
From: mohamed.boucadair@orange.com
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "Acee Lindem (acee)" <acee@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+PSKWZbDkygrQxSvdVsap538ayAgAcBl7CAASJxcIAA6PXA
Date: Wed, 28 Oct 2015 14:23:22 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008C8896D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <D24ACB18.36F88%acee@cisco.com> <1a3c0c41dfef4808aa02c34762bcbff1@XCH-ALN-001.cisco.com> <787AE7BB302AE849A7480A190F8B933008C87A3A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6d54006a312844d5a749ec5cd7fd3fdc@XCH-ALN-001.cisco.com>
In-Reply-To: <6d54006a312844d5a749ec5cd7fd3fdc@XCH-ALN-001.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.10.28.135415
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/byCyY_Gh8C7kwiDylrfsLuXOpvk>
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, 28 Oct 2015 14:23:27 -0000

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

v2.14.0 | Report a Bug | By Email