IETF Logo Mail Archive

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

"Acee Lindem (acee)" <acee@cisco.com> Wed, 11 May 2016 21:08 UTC

Return-Path: <acee@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 2FC8D12D824 for <ospf@ietfa.amsl.com>; Wed, 11 May 2016 14:08:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level:
X-Spam-Status: No, score=-15.517 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, 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 BoJXUDBL4wb4 for <ospf@ietfa.amsl.com>; Wed, 11 May 2016 14:08:03 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8978B12D147 for <ospf@ietf.org>; Wed, 11 May 2016 14:08:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2690; q=dns/txt; s=iport; t=1463000883; x=1464210483; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=++OGiBbGXtPz4SuOafvaELgMmhk8p9hJoTrkDuaQbYQ=; b=GN+jKOY/BHbJNU3aOLQeyMq9hMgWh0x86X+yby/fTjeGNIB2oPwo70kp 4QCLAqYyo7TGHZVbfXA7NpSulkdZfqXFDBcygcNJkE0OOB/vdA/ltZ+V5 9JYvEZkcywoiUGPXCCHEc+OYuVbMvDG95pky0rE3RRRFEQAQ0lMWdE/lg o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BHAgDLnjNX/4wNJK1egziBUga3I4IPAQ2BdoYUAhyBIjgUAQEBAQEBAWUnhEMBAQQjEUUQAgEGAhoCIwMCAgIwFAEQAgQOBYgvjFidHZBlAQEBAQEBAQEBAQEBAQEBAQEBARd8iXCEP4MAglkBBJgnAY4dgWmET4hhj0ABHgEBQoI2gTVuiAt/AQEB
X-IronPort-AV: E=Sophos;i="5.24,609,1454976000"; d="scan'208";a="106193172"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2016 21:08:02 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u4BL81ft013379 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 May 2016 21:08:02 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 11 May 2016 17:08:01 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 11 May 2016 17:08:01 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Wunan (Eric)" <eric.wu@huawei.com>
Thread-Topic: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment"
Thread-Index: AQHRf/Ho6WRxQA5zQE2bUJRokiTbP5+KuacAgCnY2AA=
Date: Wed, 11 May 2016 21:08:01 +0000
Message-ID: <D359167D.60950%acee@cisco.com>
References: <D30F89DE.51A65%acee@cisco.com> <0F26584357FD124DB93F1535E4B0A650841024E2@szxema508-mbx.china.huawei.com>
In-Reply-To: <0F26584357FD124DB93F1535E4B0A650841024E2@szxema508-mbx.china.huawei.com>
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.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <0B97FD42BEDBE849947414163EF81209@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/6lcLhRTI7By4Mys14yaIzCwSUj8>
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: Wed, 11 May 2016 21:08:05 -0000

Hi Eric, 
We discussed this both on the list and at IETF 95. In summary, there is no
general agreement on either whether there is an OSPF third-party
application info distribution use case or, if there is one, whether this
draft meets the requirements.
Thanks,
Acee 

On 4/14/16, 10:05 PM, "Wunan (Eric)" <eric.wu@huawei.com> wrote:

>Hi Acee,
>
>I think the motivation below makes sense. Actually this is the way people
>had already been doing, not only operators.
>
>"One major benefit of using administrative tags rather
>   than IANA defined TLVs or sub-TLVs to indicate different services is
>   to facilitate the rapid deployment of new services without any need
>   for the standardization of those TLVs or sub-TLVs.  However, there
>   are some special use cases where the service to be advertised has one
>   or more attributes which need to be advertised as well.  In such
>   case, the administrative tag is not much applicable anymore"
>
>Personally I wish one more generalized mechanism can exist instead of one
>Node tag and one proprietary TLV.
>Anyway, I'd like to see this I-D can go further and "lot of things we can
>further improve" at the same time, as Uma mentioned.
>
>Regards
>Eric
>
>> -----邮件原件-----
>> 发件人: Acee Lindem (acee) [mailto:acee@cisco.com]
>> 发送时间: 2016年3月17日 10:09
>> 收件人: OSPF WG List
>> 主题: [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
>

v2.23.0 | Report a Bug | By Email