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

<bruno.decraene@orange.com> Wed, 03 September 2014 13:50 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 1AB971A02F0 for <ospf@ietfa.amsl.com>; Wed, 3 Sep 2014 06:50:36 -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 CFSIVojWuXXV for <ospf@ietfa.amsl.com>; Wed, 3 Sep 2014 06:50:32 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC5E1A030C for <ospf@ietf.org>; Wed, 3 Sep 2014 06:50:31 -0700 (PDT)
Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id B6F46C21D5; Wed, 3 Sep 2014 15:50:29 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 9B154C804F; Wed, 3 Sep 2014 15:50:29 +0200 (CEST)
Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Wed, 3 Sep 2014 15:50:29 +0200
From: <bruno.decraene@orange.com>
To: Peter Psenak <ppsenak@cisco.com>
Thread-Topic: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag
Thread-Index: AQHPx3FG1CFHXZCiDEe77DyMQAVFwZvva5ig
Date: Wed, 3 Sep 2014 13:50:28 +0000
Message-ID: <11232_1409752229_54071CA5_11232_18273_1_53C29892C857584299CBF5D05346208A071EC7B4@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> <15316_1409739908_5406EC84_15316_1787_1_53C29892C857584299CBF5D05346208A071EC421@PEXCVZYM11.corporate.adroot.infra.ftgroup> <5406EE38.2010504@cisco.com> <11709_1409746188_5407050C_11709_11179_1_53C29892C857584299CBF5D05346208A071EC5F6@PEXCVZYM11.corporate.adroot.infra.ftgroup> <54070740.4000906@cisco.com>
In-Reply-To: <54070740.4000906@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.9.3.120921
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/qavbWi2086HzNaV3TYo4V8dPF0A
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 13:50:36 -0000

Hi Peter,

> From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Wednesday, September 03, 2014 2:19 PM
> 
> Hi Bruno,
> 
> On 9/3/14 14:09 , bruno.decraene@orange.com wrote:
> > Hi Peter,
> >
> >> From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Wednesday,
> >> September 03, 2014 12:32 PM
> >>
> >> Hi Bruno,
> >>
> >> On 9/3/14 12:25 , bruno.decraene@orange.com wrote:
> >>> 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.
> >>
> >> why is "IANA registered node tag" any better then IANA registered
> >> capability bit in the above case?
> >
> > We need the value to be able to be set/cleared by configuration (by the
> network operator) in order to allow for PQ node not compliant with RLFA to
> advertise it.
> > Node-admin tag clear matches this requirement.
> > I assumed that the capability bits were controlled by the software and not
> by the network operator and hence could not be used. However, I realize
> that this is an assumption that may be incorrect as I'm not familiar with OSPF
> implementations (as we are mostly using ISIS). If all OSPF implementations
> allow the network operator to control any bits (or at least the non
> allocated/supported ones) I think I agree that such bit could equally be used.
> However, after quickly reading the RFC, I'm not seeing that those bits
> MUST/SHOULD be configurable by configuration. Hence we can't really
> guaranty that any (future) implementation would allow this.
> 
> RFC4970 does not pose any restrictions on setting of a capability bits in OSPF
> Router Informational Capabilities TLV. Some bits may be set based on the
> software capabilities of the originator but others may be set based on the
> configuration and willingness of the originator to perform certain
> functionality. The flexibility is there.

Agreed that the flexibility is there in the spec. But the feature may not be implemented hence used. So if we add a text in node-admin-tag to forbid _any_ capability advertisement, I think we should also add a text to mandate the ability for the SP to configure RFC 4970 capability bits advertisement.

Thanks,
Bruno

> 
> thanks,
> Peter
> 
> >
> >   Thanks,
> > Bruno
> >> thanks,
> >> Peter
> >>
> >>
> >>
> >>>
> >>> 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.
> >>>
> >>> .
> >>>
> >
> >
> >
> __________________________________________________________
> ____________
> > ___________________________________________________
> >
> > 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.
> >
> > .
> >


_________________________________________________________________________________________________________________________

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.