IETF Logo Mail Archive

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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 22 October 2015 20:04 UTC

Return-Path: <ginsberg@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 97F071B3F44 for <ospf@ietfa.amsl.com>; Thu, 22 Oct 2015 13:04:23 -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 ylYpqOHpdtP0 for <ospf@ietfa.amsl.com>; Thu, 22 Oct 2015 13:04:22 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4CB1B3F42 for <ospf@ietf.org>; Thu, 22 Oct 2015 13:04:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3084; q=dns/txt; s=iport; t=1445544262; x=1446753862; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0MfBmDU8HPY0yaoGjr12Hn6cGKJVkCXb/QPke/vYXN0=; b=hMsdbKBmEOFjUgaXsdxuRfQdU15TcIMnKRGP/WaifhIpJcSZIlK/FPDP SfSb1Y6gZ0DpOHXVYgzl67C3xwk2ULdzk1G6sYVHUUM0ZJ7GmjY1IhmAx /T/MMr83+Gczw6ODpjsQWFXnW3zMTtwROMiQJ8u7679ni4Hzdi+Q9WSFf A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D2AQB4QClW/4MNJK1egzZUbwa+GwENgVkXDIV6AhyBMDgUAQEBAQEBAYEKhC4BAQEEAQEBIBE6FwQCAQgRBAEBAwIfBAMCAgIlCxQBCAgCBAESCBOIFQ2yUJJ0AQEBAQEBAQEBAQEBAQEBAQEBAQEBFASBIoVVhH6FFAaCY4FFBZYrAY0WgV+EP5YOAR8BAUKCRIE/cgGFPIEGAQEB
X-IronPort-AV: E=Sophos;i="5.20,184,1444694400"; d="scan'208";a="200653994"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP; 22 Oct 2015 20:04:21 +0000
Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9MK4LVr001898 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <ospf@ietf.org>; Thu, 22 Oct 2015 20:04:21 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 22 Oct 2015 15:04:00 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.000; Thu, 22 Oct 2015 15:04:00 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "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+PSKWZbDkygrQxSvdVsap538ayA
Date: Thu, 22 Oct 2015 20:04:00 +0000
Message-ID: <1a3c0c41dfef4808aa02c34762bcbff1@XCH-ALN-001.cisco.com>
References: <D24ACB18.36F88%acee@cisco.com>
In-Reply-To: <D24ACB18.36F88%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [128.107.163.31]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/e6JhtmHqsgviQ-DEpcmq3eRdTzE>
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: Thu, 22 Oct 2015 20:04:23 -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

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

v2.23.0 | Report a Bug | By Email