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

<bruno.decraene@orange.com> Mon, 09 May 2016 09:00 UTC

Return-Path: <bruno.decraene@orange.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 3660512D0FB; Mon, 9 May 2016 02:00:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Level:
X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 9jvN3aYCe27j; Mon, 9 May 2016 02:00:41 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86B3312D0A6; Mon, 9 May 2016 02:00:40 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 4E6152DC20C; Mon, 9 May 2016 11:00:39 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.72]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DE39C35C07E; Mon, 9 May 2016 11:00:38 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0294.000; Mon, 9 May 2016 11:00:38 +0200
From: bruno.decraene@orange.com
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>
Thread-Topic: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)
Thread-Index: AQHRpkmw5Pluqt5k70GYTWPyRTx7ep+ptLKA//+8JwCAAF6/gP//rWKQgABaNYCAAAGJgIAAQUYA//+/UkAAQbRFgAAGGC5QAADCBdAAhv6V0A==
Date: Mon, 09 May 2016 09:00:37 +0000
Message-ID: <4395_1462784439_573051B6_4395_5653_1_53C29892C857584299CBF5D05346208A0F89EB52@OPEXCLILM21.corporate.adroot.infra.ftgroup>
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> <e39f7a2b04ef47ec86ce8ffa5370b9cd@XCH-ALN-001.cisco.com> <9b412f134528404c944ef62fe4383e85@XCH-ALN-001.cisco.com>
In-Reply-To: <9b412f134528404c944ef62fe4383e85@XCH-ALN-001.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F89EB52OPEXCLILM21corp_"
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.9.73615
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/XY0LK4Kf26RLCDjk-dfljDjy2pk>
Cc: Peter Yee <peter@akayla.com>, "isis-chairs@ietf.org" <isis-chairs@ietf.org>, Christian Hopps <chopps@chopps.org>, "draft-ietf-isis-node-admin-tag@ietf.org" <draft-ietf-isis-node-admin-tag@ietf.org>, The IESG <iesg@ietf.org>, "isis-wg@ietf.org" <isis-wg@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: Mon, 09 May 2016 09:00:44 -0000

Les,

Thanks for the additional info.
Your text works for me.

Thanks,
-- Bruno

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Friday, May 06, 2016 6:36 PM
To: DECRAENE Bruno IMT/OLN; Pushpasis Sarkar; Alia Atlas; Jari Arkko; Peter Yee
Cc: draft-ietf-isis-node-admin-tag@ietf.org; isis-chairs@ietf.org; Christian Hopps; isis-wg@ietf.org; The IESG
Subject: RE: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)

Ohhh…forgot to reply to one point.

I prefer the normative text

“node administrative tags MUST NOT be associated
with something whose state can oscillate frequently”

This is something we really do want to forbid.

   Les


From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, May 06, 2016 9:25 AM
To: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>; Pushpasis Sarkar; Alia Atlas; Jari Arkko; Peter Yee
Cc: draft-ietf-isis-node-admin-tag@ietf.org<mailto:draft-ietf-isis-node-admin-tag@ietf.org>; isis-chairs@ietf.org<mailto:isis-chairs@ietf.org>; Christian Hopps; isis-wg@ietf.org<mailto:isis-wg@ietf.org>; The IESG
Subject: Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)

Bruno –

I am sympathetic to the concerns you have raised.

The issue has arisen in the context of two different IGP drafts recently - this one and the OSPF S-BFD draft.  In the case of the OSPF S-BFD draft I find the concern inappropriate since there has been much discussion that we have no idea how to deal with 2 S-BFD discriminators per node – let alone a larger number – and S-BFD discriminators are as likely to change as the address assigned to a node. However, in the case of admin tags, the use cases for tags is much more open – in theory a tag could be used to represent almost anything – so it does seem prudent to emphasize that we don’t want tags to be used to represent states that may change frequently.

The base protocol specifications do not discuss equivalent concerns regarding objects like neighbors and prefixes – so it does give me pause as to why there now seems to be an assumption that any new advertisement requires text on this point. It is important to note that the base IGP specs do define mechanisms to insure that flooding of information is rate limited in a number of ways because we do not want routing updates to overwhelm forwarding – so it isn’t that the issue has not been carefully considered.

In principle I am not averse to adding some generic text to RFC 4971-bis to discuss stability (my co-authors would need to weigh in as well). However I am not convinced this would eliminate the perceived need to add specific text to drafts like the node-admin tag draft. So while it may still be a good idea I suspect we still need to resolve the changes desired in the node-admin tag draft. If we do choose to modify RFC 4971-bis in this way I think RFC 7770 should be updated as well.

   Les


From: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> [mailto:bruno.decraene@orange.com]
Sent: Friday, May 06, 2016 1:18 AM
To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Alia Atlas; Jari Arkko; Peter Yee
Cc: 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 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<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)

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.

_________________________________________________________________________________________________________________________

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.