Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

Shraddha Hegde <shraddha@juniper.net> Wed, 27 August 2014 08:04 UTC

Return-Path: <shraddha@juniper.net>
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 598A81A048C for <ospf@ietfa.amsl.com>; Wed, 27 Aug 2014 01:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-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 tNa26T37POOA for <ospf@ietfa.amsl.com>; Wed, 27 Aug 2014 01:04:47 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9FEC1A0472 for <ospf@ietf.org>; Wed, 27 Aug 2014 01:04:47 -0700 (PDT)
Received: from BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) by BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Wed, 27 Aug 2014 08:04:46 +0000
Received: from BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.18]) by BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.80]) with mapi id 15.00.1015.018; Wed, 27 Aug 2014 08:04:46 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: Anton Smirnov <asmirnov@cisco.com>, Peter Psenak <ppsenak@cisco.com>, "ospf@ietf.org" <ospf@ietf.org>
Thread-Topic: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag
Thread-Index: AQHPwKoSGbQFoOONyUaUf4QhM2C3GJvih70AgACWOQCAAPpmEA==
Date: Wed, 27 Aug 2014 08:04:46 +0000
Message-ID: <263b8130ebc249ccbbe81e3390a00823@BY2PR05MB127.namprd05.prod.outlook.com>
References: <D0212051.2116%acee@cisco.com> <53FC3FD8.1000704@cisco.com> <53FCBDDC.6000902@cisco.com>
In-Reply-To: <53FCBDDC.6000902@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: [116.197.184.19]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;
x-forefront-prvs: 0316567485
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(164054003)(51704005)(479174003)(377454003)(24454002)(199003)(13464003)(92566001)(46102001)(86362001)(81542001)(77096002)(90102001)(77982001)(81342001)(87936001)(4396001)(99396002)(83072002)(15975445006)(85852003)(79102001)(2656002)(76576001)(76482001)(33646002)(20776003)(107046002)(80022001)(66066001)(101416001)(85306004)(107886001)(108616004)(106356001)(21056001)(50986999)(83322001)(19580395003)(19580405001)(64706001)(74662001)(106116001)(31966008)(76176999)(230783001)(74502001)(99286002)(105586002)(74316001)(95666004)(54356999)(2501001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB127; H:BY2PR05MB127.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/YkodJ1eFEAamhl5s2FnhzS81lC8
Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag
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: <http://www.ietf.org/mail-archive/web/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, 27 Aug 2014 08:04:50 -0000

Agree with Anton that defining capability bits for each and every use-case that the operator comes up with and getting it
Standardized and get it implemented by each vendor is going to be a slow process. And we need a generic way of carrying node tags in protocols.

Rgds
Shraddha

-----Original Message-----
From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Anton Smirnov
Sent: Tuesday, August 26, 2014 10:33 PM
To: Peter Psenak; ospf@ietf.org
Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

    Hi Peter,
    the draft lists about 5 different *example* applications which COULD be addressed by node admin tags. So if you take 1 particular possible scenario out of the draft - you still have 4 possible applications. 
Examples are there to demonstrate that admin tags is useful general tool, not to require the solution.
    Sure, each of possible scenarios can be solved by tailored solution. 
But each tailored solution is required to go via IETF adoption and implementation by vendors. And indeed, in cases where tailored solution brings so much operational benefit that it warrants slow path of IETF adoption, feature development by multiple vendors and network deployment
- it will be used and will kill desire to solve the problem with admin tags.
   And vice verse - tags (when widely supported) will facilitate rapid development and deployment of services which we otherwise can't (or
slow) to offer.


    As for your particular example - operator still has to go to each and every device and enable Remote LFA on it. But we are not trying to solve this operational complexity with OSPF autoconfiguration. So it shouldn't be that complex to enable acceptable node tag at the same time as enabling rLFA itself.

Anton


On 08/26/2014 10:05 AM, Peter Psenak wrote:
> On 8/25/14 23:18 , Acee Lindem (acee) wrote:
>> There are situations where node level policy is required and an OSPF 
>> advertised admin tag simplifies this. For example, advertisement of 
>> remote-LFA eligibility.
>
> my concern with the generic use of admin tags for signaling capability 
> is that it's operationally unfriendly compared to explicit signaling 
> of the capability (e.g. using a bit or a TLV). The reason is that you 
> have to configure the tag meaning on all receiving routers.
>
> thanks,
> Peter
>
>>
>> Please indicate your support or objections to adopting this draft as 
>> an OSPF 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

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf