Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment"

Peter Psenak <ppsenak@cisco.com> Fri, 08 April 2016 08:24 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FCC12D52A for <ospf@ietfa.amsl.com>; Fri, 8 Apr 2016 01:24:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level:
X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 yzLw85hUodEE for <ospf@ietfa.amsl.com>; Fri, 8 Apr 2016 01:24:51 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7383C12D0B3 for <ospf@ietf.org>; Fri, 8 Apr 2016 01:24:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4142; q=dns/txt; s=iport; t=1460103890; x=1461313490; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dfIZRFzJ/tlCfhQQRg6649Xb6Kp8K1DHA1qCJandEDg=; b=krnnhvMVhmNGlL+Uysui2gmDl82wRWKYQeOQhciFjPAOxLBVBM0dAzAr 5HK2UoVV/duRpiUMvMwJkvQQQJ1BI/F8UpO13XA9R9mYJYd0oWZfslwbV tZ1EbA33b3rOzIRsdeC0/c6CdqbhIcjwJaR9Tql7hcL0wxyAGR/C3tCRm U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBADkaQdX/xbLJq1dhAp9vEcXCoVsA?= =?us-ascii?q?oIFAQEBAQEBZieEQQEBAQQBAQEgDwEFNgoBDAQLEQQBAQECAgUWCAMCAgkDAgE?= =?us-ascii?q?CARUfCQgGAQwBBQIBAYgjDrAnkg0BAQEBAQEBAQEBAQEBAQEBAQEBAQERBHyFJ?= =?us-ascii?q?YRLhz+CVgEEmASODIFnhE2DBYVUjyVigjKBNzowiTkBAQE?=
X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="635063072"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 08:24:48 +0000
Received: from [10.60.140.57] (ams-ppsenak-nitro8.cisco.com [10.60.140.57]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u388Olrt026037; Fri, 8 Apr 2016 08:24:47 GMT
Message-ID: <57076ACF.8070608@cisco.com>
Date: Fri, 08 Apr 2016 10:24:47 +0200
From: Peter Psenak <ppsenak@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Uma Chunduri <uma.chunduri@ericsson.com>, prz <prz@zeta2.ch>
References: <D30F89DE.51A65%acee@cisco.com> <e1c1685f2856424c939bfbea4a5d90a3@XCH-ALN-001.cisco.com> <56EA5A23.6020807@cisco.com> <3fc89c87056187cfa0908a07ed4c9850@zeta2.ch> <1B502206DFA0C544B7A604691520086358001503@eusaamb106.ericsson.se>
In-Reply-To: <1B502206DFA0C544B7A604691520086358001503@eusaamb106.ericsson.se>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/TjL3ImmqhPxJhU6NxWF-iVbitIE>
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment"
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 08 Apr 2016 08:24:53 -0000

Hi Uma,

I still have a fundamental problem with leaving the sub-TLV definition 
to the operator. If the operator really wants to do define something 
proprietary, we have plenty of experimental/reserved code points in RI 
TLV space.

I just don't see a point of standardizing a container that is used to 
advertise proprietary sub-TLVs.

thanks,
Peter


On 4/8/16 05:09 , Uma Chunduri wrote:
> Tony,  Peter,
>
> Also  please note the following changes are made per last WG Adoption call:
>
> 1.  " Dissemination of dynamic information" Information is removed like location information for Mobile OSPF routers.	
>
> 2. Section 3 - Applicability has been added
>
> 3. Section 6 Last paragraph has been added clarifying information about transport instance usage.
>
> --
> Uma C.
>
>
> -----Original Message-----
> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of prz
> Sent: Thursday, March 17, 2016 12:30 PM
> To: Peter Psenak
> Cc: OSPF WG List
> Subject: Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment"
>
>
>   +1 to Peter's, Les's opinion here (as individual, no hat, not even a  surgical mask, Acee ;-) ...
>
>   --- tony
>
>
>   On Thu, 17 Mar 2016 08:17:55 +0100, Peter Psenak <ppsenak@cisco.com>
>   wrote:
>> I agree with Les and share the same concerns.
>>
>> Peter
>>
>> On 3/17/16 05:40 , Les Ginsberg (ginsberg) wrote:
>>> My opinion of the draft has not changed.
>>>
>>> It is defining a way to utilize OSPF to send application information
>>> - which is not something the protocol should be used to do.
>>> Further, it leaves definition of the new codepoints and formats of
>>> the information advertised completely unspecified - the latest draft
>>> revision states:
>>>
>>> " The meaning of the operator-defined sub-TLV is totally opaque to
>>> OSPF
>>>      and is defined by the network local policy and is controlled via
>>>      configuration.  "
>>>
>>> How interoperability is achieved is not addressed at all.
>>>
>>> IS-IS has taken a much more stringent approach to a similar request.
>>> RFC 6823 (GENAPP) requires that information sent in the generic
>>> container TLV MUST be based on a public specification - and that an
>>> application specific ID for the application using this mechanism be
>>> assigned by IANA. This addresses the interoperability issue.
>>> GENAPP further specifies that such information SHOULD be advertised
>>> by a separate instance of the routing protocol (as specified in RFC
>>> 6822(MI)) so as to minimize the impact of the application information
>>> flooding on the performance of the routing protocol.
>>>
>>> Without addressing both of these issues I cannot support the draft.
>>>
>>>      Les
>>>
>>>
>>>> -----Original Message-----
>>>> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem
>>>> (acee)
>>>> Sent: Wednesday, March 16, 2016 7:09 PM
>>>> To: OSPF WG List
>>>> Subject: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs
>>>> for Agile Service Deployment"
>>>>
>>>> We’ve discussed this draft a number of times. In my opinion, it
>>>> seems like a useful mechanism if one envisions a generalized API
>>>> between OSPF and user and third-party applications to convey
>>>> application-specific information learned from other OSPF routers. In
>>>> many respects, this has already been envisioned for OSPF Node Tags.
>>>> Please indicate your opinion on this draft before March 31st, 2016.
>>>>
>>>> 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
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>