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

"Acee Lindem (acee)" <acee@cisco.com> Wed, 28 October 2015 19:17 UTC

Return-Path: <acee@cisco.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 1C2FD1A03C7 for <ospf@ietfa.amsl.com>; Wed, 28 Oct 2015 12:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 27H3YvBcUT_C for <ospf@ietfa.amsl.com>; Wed, 28 Oct 2015 12:17:30 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2B091A0161 for <ospf@ietf.org>; Wed, 28 Oct 2015 12:17:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10186; q=dns/txt; s=iport; t=1446059850; x=1447269450; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8QBfhn/wwhKVQKoWCLSrcVhBwKAmjhEMluSWrRIoL9E=; b=fGDDi50LicXF4L7/yRdriwRBce4yzW88c0/Gi5zPQr6ONRNiVPiA+GYS FDZpGJzHHUiRqCyXy3YiUfhTzvh3OPLpDf5WPbB6Wv5ZvvUOwEyd/nTC4 hXZteYx5xlpCAh6xb/nEMiaakv8DHXg/gLYl2WwKd17ESKjgtw0qdGbCp 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D2AQAJHjFW/4UNJK1egzZUbwa/FAENgVoXDIV4AhyBITgUAQEBAQEBAYEKhDUBAQEEAQEBIBE6FwQCAQgRBAEBAwIfBAMCAgIlCxQBCAgCBAESG4gVDbQTkg0BAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIEiilOEXRgiBoJjgUUFlj0BiAuFGIFZhD+WGwEfAQFCgkSBQHIBhDUlHIEGAQEB
X-IronPort-AV: E=Sophos;i="5.20,211,1444694400"; d="scan'208";a="45452190"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP; 28 Oct 2015 19:17:28 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t9SJHSSN020625 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Oct 2015 19:17:28 GMT
Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 28 Oct 2015 14:17:03 -0500
Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.000; Wed, 28 Oct 2015 14:17:03 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "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+PSKWZbDkygrQxSvdVsap538ayAgAcBl7CAASJxcIAA6PXAgABnSwA=
Date: Wed, 28 Oct 2015 19:17:03 +0000
Message-ID: <D25693F4.39AC6%acee@cisco.com>
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>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933008C8896D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.199]
Content-Type: text/plain; charset="utf-8"
Content-ID: <41F42A62C5B1FA49BA8EA95E7A5C83E1@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/VLPmpTGqGBzHK63hGTUCn9twLzY>
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 19:17:32 -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, "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