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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Tue, 26 August 2014 21:50 UTC

Return-Path: <ginsberg@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 13F1E1A01F2 for <ospf@ietfa.amsl.com>; Tue, 26 Aug 2014 14:50:51 -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 sDhlCnFFR-Wh for <ospf@ietfa.amsl.com>; Tue, 26 Aug 2014 14:50:49 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B5201A01EB for <ospf@ietf.org>; Tue, 26 Aug 2014 14:50:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5364; q=dns/txt; s=iport; t=1409089849; x=1410299449; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OpLFNttkpdn2aW5+RjayAe4gaj2Lz7O4NxEvmrg+Hrw=; b=KbYFMjOdJfYGkd/VTO4yXmCl8pZddNjDaBRf8u4mKMK5Y9KeybvFh0Xi juuLCWQunLne8sotN4MDOdlV8pO1IcmDBSrBKrnexWOOXlAMd27WKYBd8 e3OvqwUkg5pX3BcrQeMNbkknFaxEZ8Rx5Nhb4ARf8Kr8FBPmJ/0Nqr6vE k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisFALL//FOtJV2Q/2dsb2JhbABbgmojU1cEzFAKh0wBgRoWd4QDAQEBBAEBAWsLDAQCAQgRBAEBAQodBycLFAkIAgQBDQUIiDoBDL9MEwSPGzEHBoMpgR0FimyGQaA7g15sgUiBBwEBAQ
X-IronPort-AV: E=Sophos;i="5.04,406,1406592000"; d="scan'208";a="350488111"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP; 26 Aug 2014 21:50:48 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s7QLomEn024299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 21:50:48 GMT
Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 16:50:48 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, Hannes Gredler <hannes@juniper.net>
Thread-Topic: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag
Thread-Index: AQHPwKoSGbQFoOONyUaUf4QhM2C3GJvi248AgAAb4ACAAE+cAIAAETWAgAADSwCAAARTgIAAC3sAgAABCuA=
Date: Tue, 26 Aug 2014 21:50:47 +0000
Message-ID: <F3ADE4747C9E124B89F0ED2180CC814F23EFDB61@xmb-aln-x02.cisco.com>
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> <53FCB876.7030408@cisco.com>
In-Reply-To: <53FCB876.7030408@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [128.107.163.140]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/cLIi5fEdMD2wOf0QB99e1WCVRdw
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 21:50:51 -0000

I support making this draft a WG item - but I do think a much more complete discussion regarding the tradeoffs between using node tags vs capability identifiers needs to be included - if for no other reason than if/when this draft were to become an RFC we would have two mechanisms and it  is not so clear when it is more appropriate to use one over another.

We don't have to come to a conclusion on that issue in this thread - nor should it preclude making this a WG item - but it is definitely an important issue to be discussed.

   Les


> -----Original Message-----
> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Peter Psenak
> (ppsenak)
> Sent: Tuesday, August 26, 2014 9:40 AM
> To: Hannes Gredler
> Cc: ospf@ietf.org
> Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-
> tag
> 
> 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
> > | >.
> > | >
> > |
> > .
> >
> 
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf