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

Hannes Gredler <hannes@juniper.net> Tue, 26 August 2014 15:59 UTC

Return-Path: <hannes@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 B17531A876F for <ospf@ietfa.amsl.com>; Tue, 26 Aug 2014 08:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 YM_Lmjcb6XLB for <ospf@ietfa.amsl.com>; Tue, 26 Aug 2014 08:59:32 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29931A8747 for <ospf@ietf.org>; Tue, 26 Aug 2014 08:59:31 -0700 (PDT)
Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB428.namprd05.prod.outlook.com (10.141.74.15) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Tue, 26 Aug 2014 15:59:29 +0000
Received: from hannes-mba.local (66.129.239.14) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Tue, 26 Aug 2014 15:59:23 +0000
Received: from juniper.net (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id ACB8F25A643; Tue, 26 Aug 2014 17:59:17 +0200 (CEST)
Date: Tue, 26 Aug 2014 17:59:17 +0200
From: Hannes Gredler <hannes@juniper.net>
To: Peter Psenak <ppsenak@cisco.com>
Message-ID: <20140826155917.GA6346@juniper.net>
References: <D0212051.2116%acee@cisco.com> <53FC3FD8.1000704@cisco.com> <D022049C.2295%acee@cisco.com> <53FC9A02.4080401@cisco.com> <20140826153201.GA6179@juniper.net> <53FCAB34.7020602@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <53FCAB34.7020602@cisco.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Originating-IP: [66.129.239.14]
X-ClientProxiedBy: BY2PR03CA045.namprd03.prod.outlook.com (10.141.249.18) To CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152)
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:;
X-Forefront-PRVS: 03152A99FF
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(51444003)(24454002)(199003)(479174003)(189002)(377454003)(20776003)(23756003)(99396002)(47776003)(66066001)(230783001)(80022001)(64706001)(85306004)(93886004)(4396001)(21056001)(81542001)(81342001)(50986999)(76506005)(87976001)(19580395003)(54356999)(19580405001)(15975445006)(101416001)(83506001)(76176999)(85852003)(31966008)(95666004)(106356001)(107046002)(33656002)(74502001)(90102001)(50466002)(77096002)(83072002)(110136001)(92726001)(92566001)(83322001)(74662001)(86362001)(46102001)(77982001)(36756003)(102836001)(105586002)(79102001)(76482001)(579124003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB443; H:hannes-mba.local; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/OPwD7FyYN4SWKR9URPb3YbauQrk
Cc: "ospf@ietf.org" <ospf@ietf.org>
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: Tue, 26 Aug 2014 15:59:35 -0000

hi peter,

understood - so what about simply reserving a certain range of the tag space
for well-known applications (+IANA registry etc.) such that
for 2) we can avoid distributing policies ?

/hannes

On Tue, Aug 26, 2014 at 05:43:48PM +0200, Peter Psenak wrote:
| Hi Hannes,
| 
| On 8/26/14 17:32 , Hannes Gredler wrote:
| >hi peter,
| >
| >operators want to assign node-tags as per router function (ABR, PE, core) and then
| >the LFA-selection becomes much easier to specify. - e.g.
| >- only pick a LFA that does not cross another PE router.
| >
| >similarily it is desirable for "LFA tunnel termination"
| >to put out a constraint which says
| >- only pick a PQ neighbor which has node tag 'X'
| 
| my point is that with the above approach you have to:
| 1. On candidate PQ nodes configure the tag X
| 2. on all other nodes configure "only pick a PQ neighbor which has node tag
| 'X'"
| 
| It's (2) which makes me feel uncomfortable, as it's a config to be applied
| to many nodes.
| 
| If we instead define a capability bit which would mean "PQ candidate", we
| would avoid (2).
| 
| >
| >i found it always strange that we for TE (as an example for
| >constraining paths) we have got ways to tag links, but
| >not way to tag nodes - that draft aims to fix that.
| 
| I'm not against tagging nodes as such. What worries me if we end up using
| node tags for signalling capabilities of node.
| 
| thanks,
| Peter
| 
| >
| >HTH,
| >
| >/hannes
| >
| >On Tue, Aug 26, 2014 at 04:30:26PM +0200, Peter Psenak wrote:
| >| Hi Acee,
| >|
| >| On 8/26/14 15:45 , Acee Lindem (acee) wrote:
| >| >Hi Peter,
| >| >This is a valid concern and one that we¹ve discussed previously with
| >| >respect to routing behavior based on policies. I think that accepting this
| >| >draft as a WG document should not preclude standardization of capabilities
| >| >advertisement for popular applications.
| >|
| >| sure. Just that the draft mentions applications like "Controlling Remote LFA
| >| tunnel termination", which I'm not sure the node tag is the best approach
| >| for.
| >|
| >| thanks,
| >| Peter
| >|
| >| >Thanks,
| >| >Acee
| >| >
| >| >On 8/26/14, 4:05 AM, "Peter Psenak (ppsenak)" <ppsenak@cisco.com> 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
| >.
| >
|