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