Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag
Peter Psenak <ppsenak@cisco.com> Wed, 03 September 2014 14:32 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 6FF221A033C for <ospf@ietfa.amsl.com>; Wed, 3 Sep 2014 07:32:23 -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 QGor-pJC03xq for <ospf@ietfa.amsl.com>; Wed, 3 Sep 2014 07:32:21 -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 D3D8A1A0334 for <ospf@ietf.org>; Wed, 3 Sep 2014 07:32:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8433; q=dns/txt; s=iport; t=1409754741; x=1410964341; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=oMfJNw+9KQabwa7ucr8PuBGHIuORb4dG5TOGXVb0iWs=; b=OObss7V3b3jWvRa1+IVYTxhhj/exbRu5VFuJrr5d+cqmPGayAnomxJut 7u9vpXNlqnUg3Jk14j6rcH7FnXDDlXurFEBs1tzPjWEBPzQF0j2EnmsdY 4m7keh+wBSxXMVJ457Ees36tjyqU1FawVvS6UnWSmgA24eyaRDwI3dG8g I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArQEAL4lB1StJssW/2dsb2JhbABZg2BXyEQKh0wBgSF3hAMBAQEDAQEBATU2CgEQCxUBAgkWCAcJAwIBAgEVHxETAQUCAQEXiB8IDb1+ARMEjmsRAVAHhEwBBJgahEOHN41ng2M7L4EPgUABAQE
X-IronPort-AV: E=Sophos;i="5.04,457,1406592000"; d="scan'208";a="163924970"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 03 Sep 2014 14:32:18 +0000
Received: from [10.148.128.133] ([10.148.128.133]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s83EWIj2028086; Wed, 3 Sep 2014 14:32:18 GMT
Message-ID: <54072672.4040401@cisco.com>
Date: Wed, 03 Sep 2014 16:32:18 +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: bruno.decraene@orange.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> <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> <11232_1409752229_54071CA5_11232_18273_1_53C29892C857584299CBF5D05346208A071EC7B4@PEXCVZYM11.corporate.adroot.infra.ftgroup>
In-Reply-To: <11232_1409752229_54071CA5_11232_18273_1_53C29892C857584299CBF5D05346208A071EC7B4@PEXCVZYM11.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/RPWgixmUkaKGmfrxFA0koZm3e7g
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 14:32:23 -0000
Hi Bruno, On 9/3/14 15:50 , bruno.decraene@orange.com wrote: > 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. spec can not forbid user/implementer to set a node tag and interpret it in any possible way on the receiving router. What the draft should spell though is that for advertising binary capabilities RI Capabilities TLV SHOULD be a preferred solution and why. Regarding the RFC 4970, I don't believe there is any new requirement, current spec allows you to do what you are asking for. thanks, Peter > > 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. > > . >
- [OSPF] Poll for WG adoption of draft-hegde-ospf-n… Acee Lindem (acee)
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Hannes Gredler
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Uma Chunduri
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Peter Psenak
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Acee Lindem (acee)
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Peter Psenak
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Hannes Gredler
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Peter Psenak
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Hannes Gredler
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Peter Psenak
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Anton Smirnov
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Hannes Gredler
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Les Ginsberg (ginsberg)
- [OSPF] 答复: Poll for WG adoption of draft-hegde-os… Lizhenbin
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Wunan (Eric)
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Shraddha Hegde
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Shraddha Hegde
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Uma Chunduri
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Karsten Thomann
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Dhruv Dhody
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… bruno.decraene
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Shraddha Hegde
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Rob Shakir
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Peter Psenak
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Rob Shakir
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Peter Psenak
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… bruno.decraene
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Peter Psenak
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Hannes Gredler
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Peter Psenak
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… bruno.decraene
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Peter Psenak
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… bruno.decraene
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Dhruv Dhody
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Peter Psenak
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Hannes Gredler
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Anton Smirnov
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Dhruv Dhody
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Shraddha Hegde
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Acee Lindem (acee)
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Dhruv Dhody
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Xuxiaohu
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Jeff Tantsura
- Re: [OSPF] Poll for WG adoption of draft-hegde-os… Acee Lindem (acee)