Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)

Pushpasis Sarkar <pushpasis.ietf@gmail.com> Fri, 06 May 2016 08:32 UTC

Return-Path: <pushpasis.ietf@gmail.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6012126FDC; Fri, 6 May 2016 01:32:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level:
X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 M5xQmxrfQcBl; Fri, 6 May 2016 01:32:35 -0700 (PDT)
Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F58112D10E; Fri, 6 May 2016 01:32:35 -0700 (PDT)
Received: by mail-pa0-x231.google.com with SMTP id bt5so45045901pac.3; Fri, 06 May 2016 01:32:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=Tyz/mEC+VP8opv/JwDS0XVZ+csWogxB2BWqiH6A/RjU=; b=UII0DH8koiRFucA6X7097gO+qrUDKS2CiqDxWvksa0v7nOa98Vtsr/NzKvgJu/nwr9 ju/vrwPh0hlhPkONCBJ4m4C1exsqkCOuow7qWkZfjv4TUpZVG2/T9vOAu7AfTEIGs0tB zuqG4YI2QjYxsCrpbxPc4XRXpUEr63UP4UbKi8bw3fF8E4Oy1nZNmfMuFXe1M3a2+yQm R1R2JinV7I9bLfwiexRq62Zb7djMk4J2t1A4BLxKAHCowPMN5vgUjn2z4KUDwXd7bPzU mD+KDBpPWoUdHatLHduDeOfAEZGbvSPmovnkZlNDDgE8bf+RqjjHBCHDp1AsgwfqqTRi Caxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Tyz/mEC+VP8opv/JwDS0XVZ+csWogxB2BWqiH6A/RjU=; b=OtmASVth/CGOQjdIIcjOCCCnUnkmcsW6XKxAWDGOUJRdW2m/CGokwvH6/T4Ghh8U+/ WH1oPZL3nfqhFT7pAJUAcfJcbGKSJQWEoAPRSCIabcGaFz3lZS7KOttkiPUYjUyUC2g1 ZuirRRF5SnVdxEWAKgl3tCJyoWfLldM7B9gN5dieKNTXp/4UPwTkkDaNSL/H+INeuaMl sXOYR2lAL07328A6d8s1GT9/S9b01dJ28HkA+cjqvNW0r5H0wnBzraNo75rPP6AVfPiN ic86bLitV8ZrRLyBjHn2YbeRdP/U6WIyEM2qxqPDK8k9onQNtTHT3C2v8ChPLHeSUzYG dUZQ==
X-Gm-Message-State: AOPr4FVEe6mV0HlUjUNJyYXPupHpAqqa5ilihrif0fhCuop1juFrMinWhQW385bsGGmqdA==
X-Received: by 10.66.54.35 with SMTP id g3mr27436749pap.30.1462523555043; Fri, 06 May 2016 01:32:35 -0700 (PDT)
Received: from [192.168.1.235] ([103.6.157.63]) by smtp.gmail.com with ESMTPSA id 80sm19048722pfx.68.2016.05.06.01.32.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 May 2016 01:32:34 -0700 (PDT)
To: bruno.decraene@orange.com, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Alia Atlas <akatlas@gmail.com>, Jari Arkko <jari.arkko@piuha.net>, Peter Yee <peter@akayla.com>
References: <20160504211229.8272.67553.idtracker@ietfa.amsl.com> <CAG4d1re1uNPV=HnpFTToG27kr_OoYKmhzunDWYBMSnLetmkaCg@mail.gmail.com> <3a2f71ba6861400c8e556231e5e2f11d@XCH-ALN-001.cisco.com> <CAG4d1rcroAaupCzp0p9HfnP=wqf=tap-wLxZkqB0xVmauHQZZg@mail.gmail.com> <658ac2cbc94c4f6b8ccc13770eeebb39@XCH-ALN-001.cisco.com> <7C86D5FC-13CC-4F49-9D4C-D91CA79DD9F0@piuha.net> <CAG4d1rc_tDnBKRiS3m5jeEBfnd82vrGFYig3iz1HM46rV8+FEg@mail.gmail.com> <572AD0A0.9070508@gmail.com> <d23b3671be9242318af4826bcf16d04e@XCH-ALN-001.cisco.com> <20940_1462522703_572C534E_20940_1673_1_53C29892C857584299CBF5D05346208A0F89AADD@OPEXCLILM21.corporate.adroot.infra.ftgroup>
From: Pushpasis Sarkar <pushpasis.ietf@gmail.com>
Message-ID: <572C569D.9080608@gmail.com>
Date: Fri, 06 May 2016 14:02:29 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20940_1462522703_572C534E_20940_1673_1_53C29892C857584299CBF5D05346208A0F89AADD@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------050109070409030905080505"
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/qotj0yY9vhztmCOecfmxezdNGpQ>
Cc: "draft-ietf-isis-node-admin-tag@ietf.org" <draft-ietf-isis-node-admin-tag@ietf.org>, "isis-chairs@ietf.org" <isis-chairs@ietf.org>, Christian Hopps <chopps@chopps.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 May 2016 08:32:39 -0000

Hi Jari, Peter, Les, Alia et al,

I was in the process of preparing the next version.. I will greatly 
appreciate your comments on the following proposal from Bruno. :)

Thanks and Regards,
-Pushpasis

On Friday 06 May 2016 01:48 PM, bruno.decraene@orange.com wrote:
>
> Hi all,
>
> I was fine with the original text as in the context of IS-IS/OSPF, I 
> think the reader would get the picture.
>
> Yet, out of this IGP context, Peter’s comment seems reasonable to me.
>
> So, although I can live with the current proposed text, I don’t feel 
> that changing “MUST be stable” into “MUST NOT […] oscillate 
> frequently” really address the point. (Sorry to spoil the party while 
> everybody is so nice)
>
> A few questions to try to better identify the problem we want to 
> address with this sentence:
>
> - How much is this specific to admin-tag? I would expect this 
> requirement (size & stability) to apply to many/most link state IGP 
> advertisements. Can we refer to existing text?
>
> - More specifically, IMO, this equally applies to the parent TLV 
> (CAPABILITY) and any of its content. So what about moving this 
> requirement there? Especially since its spec is being revised 
> (draft-ietf-isis-rfc4971bis-01 has just passed WG last called).
>
> - Although I’m all for IGP stability,  I’m not sure to see why this 
> sub-TLV needs to be more stable than others, especially ones 
> triggering re-routing computations. So as we allow for redistributing 
> IP prefixes and even IP prefixes metric between IS-IS level, I’m not 
> sure to see the basis for a “MUST NOT be associated with […]e.g., the 
> reachability of a specific destination”.
>
> In the meantime, I would propose:
>
> - to put the normative text in draft-ietf-isis-rfc4971bis-01, possibly 
> including text to require implementation to limit the frequency of the 
> CAPABILITY TLV advertisement
>
> - to put a non normative text in node-admin. e.g.
>
> “Node administrative tags are expected to be associated with a stable
>
> attribute. In particular, node administrative tags must not  be associated
>
> with something whose state can oscillate frequently. The network 
> operator should avoid have tag dependent on states external to the 
> node, as this decrease the control of the stability and may even 
> create cycle in advertisement.
>
> While no specific limit on the number of node administrative tags that
>
> may be advertised is defined, it is expected that only a modest number
>
> of tags will be required in any deployment.”
>
> -- Bruno
>
> *From:*Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
> *Sent:* Thursday, May 05, 2016 8:00 AM
> *To:* Pushpasis Sarkar; Alia Atlas; Jari Arkko
> *Cc:* Peter Yee; isis-wg@ietf.org; Christian Hopps; 
> draft-ietf-isis-node-admin-tag@ietf.org; The IESG; isis-chairs@ietf.org
> *Subject:* RE: [Isis-wg] Jari Arkko's Discuss on 
> draft-ietf-isis-node-admin-tag-10: (with DISCUSS)
>
> Thanx to everyone for the positive feedback.
>
> Peter has been kind enough to provide some grammatical corrections – 
> and polite enough to do it privately. Here is corrected text (any 
> remaining grammatical issues are still mine):
>
> ““Node administrative tags are expected to be associated with a stable
>
> attribute. In particular, node administrative tags MUST NOT be associated
>
> with something whose state can oscillate frequently, e.g., the 
> reachability
>
> of a specific destination.
>
> While no specific limit on the number of node administrative tags that
>
> may be advertised is defined, it is expected that only a modest number
>
> of tags will be required in any deployment.”
>
>    Les
>
> *From:*Pushpasis Sarkar [mailto:pushpasis.ietf@gmail.com]
> *Sent:* Wednesday, May 04, 2016 9:49 PM
> *To:* Alia Atlas; Jari Arkko
> *Cc:* Les Ginsberg (ginsberg); Peter Yee; isis-wg@ietf.org 
> <mailto:isis-wg@ietf.org>; Christian Hopps; 
> draft-ietf-isis-node-admin-tag@ietf.org 
> <mailto:draft-ietf-isis-node-admin-tag@ietf.org>; The IESG; 
> isis-chairs@ietf.org <mailto:isis-chairs@ietf.org>
> *Subject:* Re: [Isis-wg] Jari Arkko's Discuss on 
> draft-ietf-isis-node-admin-tag-10: (with DISCUSS)
>
> Hi Les,
>
> Thanks for suggesting the text..  I was wondering how to resolve this 
> comment.. Especially since the text already appeared in RFC7777... :)
>
> Hi Alia,
>
> I will check with the other authors and come back if we are fine with 
> this text or not..
>
> Thanks and Regards,
> -Pushpasis
>
> On 5/5/16 6:24 AM, Alia Atlas wrote:
>
>     Les,
>
>     I also like this wording.  It's definitely an improvement.
>
>     Thanks for your help!  Let's see what the authors say as well.
>
>     Regards,
>
>     Alia
>
>     On Wed, May 4, 2016 at 8:49 PM, Jari Arkko <jari.arkko@piuha.net
>     <mailto:jari.arkko@piuha.net>> wrote:
>
>
>     > How about replacing the second paragraph of Section 4.2 with:
>     >
>     > “Node administrative tags are expected to be associated with a
>     stable
>     > attribute. In particular, node administrative tags MUST NOT be
>     associated
>     > with something whose state can oscillate frequently e.g., the
>     reachability
>     > to a specific destination.
>     >
>     > While no specific limit on the number of node administrative
>     tags which
>     > may be advertised is defined, it is expected that only a modest
>     number
>     > of tags will be required in any deployment.”
>     >
>
>     I’d find this an improvement, i.e., in particular more informative.
>
>     Jari
>
> _________________________________________________________________________________________________________________________
>
> 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.