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

<bruno.decraene@orange.com> Wed, 03 September 2014 10:25 UTC

Return-Path: <bruno.decraene@orange.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 D49E71A892B for <ospf@ietfa.amsl.com>; Wed, 3 Sep 2014 03:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ukiR8-BFZqqu for <ospf@ietfa.amsl.com>; Wed, 3 Sep 2014 03:25:10 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9E61A891F for <ospf@ietf.org>; Wed, 3 Sep 2014 03:25:10 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 834E23B42D8; Wed, 3 Sep 2014 12:25:08 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 53F4027C07D; Wed, 3 Sep 2014 12:25:08 +0200 (CEST)
Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Wed, 3 Sep 2014 12:25:08 +0200
From: <bruno.decraene@orange.com>
To: Peter Psenak <ppsenak@cisco.com>, Rob Shakir <rjs@rob.sh>
Thread-Topic: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag
Thread-Index: AQHPx1AVtvZWODn3ike5gZjbZZ1ijZvvLvew
Date: Wed, 3 Sep 2014 10:25:07 +0000
Message-ID: <15316_1409739908_5406EC84_15316_1787_1_53C29892C857584299CBF5D05346208A071EC421@PEXCVZYM11.corporate.adroot.infra.ftgroup>
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> <FC891597-3AAA-498C-BA2A-179BFD0D77EC@rob.sh> <5406CD9D.2070905@cisco.com> <9F21D1DE-3DF8-4F5D-81AD-B105FA94CD49@rob.sh> <5406CF5D.7040002@cisco.com>
In-Reply-To: <5406CF5D.7040002@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.100319
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/0K3_VShfyMN57l0rAuiEutDR6JY
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: Wed, 03 Sep 2014 10:25:13 -0000

Hi Peter, Rob,

+1 on Rob's comment regarding the use of admin tag for expressing operator policy (rather than spec/feature capability)

1 point in lined below 

> From: Peter Psenak > Sent: Wednesday, September 03, 2014 10:21 AM
> 
> Hi Rob,
> 
> On 9/3/14 10:16 , Rob Shakir wrote:
> > Hi Peter,
> >
> > On 3 Sep 2014, at 09:13, Peter Psenak <ppsenak@cisco.com> wrote:
> >
> >>> As per the above, I do not think that this mechanism replaces any
> capability, it just gives an operator a means to be more granular than the
> binary "supported"/"not supported" view that a flag indicating capabilities
> does.
> >>
> >> I understand. My point was that admin tags should not be used in cases
> where only a binary capability is signaled.
> >
> > ACK, I completely agree. Perhaps we should add something into the draft that the admin-tag should not be used for such a purpose.

> I would certainly appreciate that.

I agree as a general rule. Yet IMHO we should not kill this possibility. In particular for feature allowing incremental deployment & interaction with non-compliant nodes.
One example would have been Remote LFA (RLFA):
- the PLR (FRR node) needs to be RLFA compliant. Therefore (potential) communication between PLR regarding their capabilities can be done using IANA/implemented code point.
- the PQ node (Merge Point) does not need to be RLFA compliant. And we should keep this property to ease incremental deployment. Therefore communication between PQ and PLR regarding PQ capabilities should/may be done using node tag.  RLFA spec could have defined an IANA registered node tag to be used by PQ (configured by the network operator) to exclude them as PQ candidate. e.g. for PQ node not accepting T-LDP session or nodes which should not be used as PQ per policy.

Thanks,
Bruno
 
> 
> thanks,
> Peter
> 
> >
> > Cheers,
> > r.
> >
> 
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.