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

Peter Psenak <ppsenak@cisco.com> Tue, 26 August 2014 16:40 UTC

Return-Path: <ppsenak@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 690951A00EA for <ospf@ietfa.amsl.com>; Tue, 26 Aug 2014 09:40:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level:
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 ig5elxiZE-fS for <ospf@ietfa.amsl.com>; Tue, 26 Aug 2014 09:40:26 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21CD1A000A for <ospf@ietf.org>; Tue, 26 Aug 2014 09:40:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4036; q=dns/txt; s=iport; t=1409071226; x=1410280826; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=QDK0u8Bvx14G1oCoCBUp7VSJDAdnjwPHYnFQvSvXMlk=; b=bmTlaSobtaq8/zNm8kzgGx1mW+j8iWoCRTufZGzZQHW+LKboLUiwgwIo geW9KNhXB7k0/ebEFv5eyF75Z0r+kUzTfagSpboPzLsJo8CLzcjkvmGTV TmWFlCJnT0KO1J0VMeuxSQcAGMP806WQUq+HsQu3/xG7IgqPh8nfj1L5y U=;
X-IronPort-AV: E=Sophos;i="5.04,405,1406592000"; d="scan'208";a="153773205"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 26 Aug 2014 16:40:23 +0000
Received: from [10.55.51.206] (ams-ppsenak-87113.cisco.com [10.55.51.206]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s7QGeNXG019888; Tue, 26 Aug 2014 16:40:23 GMT
Message-ID: <53FCB876.7030408@cisco.com>
Date: Tue, 26 Aug 2014 18:40:22 +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: Hannes Gredler <hannes@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> <20140826155917.GA6346@juniper.net>
In-Reply-To: <20140826155917.GA6346@juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/HjvSRynplRayXmP4jJIbClnGwNQ
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 16:40:30 -0000

Hi Hannes,

On 8/26/14 17:59 , Hannes Gredler wrote:
> 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 ?

we have an existing mechanism for advertising capabilities - RFC4970, 
section 2.3 and 2.4. We can reserve a bit for each well-known application.

thanks,
Peter

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