Re: [Isis-wg] New Version Notification for draft-bryant-rtgwg-param-sync-01.txt

Alia Atlas <akatlas@gmail.com> Wed, 01 March 2017 03:42 UTC

Return-Path: <akatlas@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 E03FC129468; Tue, 28 Feb 2017 19:42:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ydz7YiyURX89; Tue, 28 Feb 2017 19:42:46 -0800 (PST)
Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 750981293F0; Tue, 28 Feb 2017 19:42:46 -0800 (PST)
Received: by mail-wr0-x229.google.com with SMTP id u48so21375863wrc.0; Tue, 28 Feb 2017 19:42:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UtvCAFU/nOSnyXGjWOQmYnfobBMsBjcNxw4QQ8V+bJQ=; b=BOgAGHeEQI3d9phoHtw2Gd7ZfGARXjo90Gb2ro7/vT6dhsYGNAe/Atok1cV+wptfV1 DEe96h5dSlhaoUVKyAOfgIpKz/rlNflIFKp1pPbR85oyh2IWbH2Rkp+/ZJ63GJeyuzfR jSNIHvwZ0ec2hCrO61AQdzatDA0+xl9AE6o00HPEjVVpdAl6uefraT0Jq1LNzlGkYQQo 90crOvpmqkpx1iTbwx6UArta3aT+Q8QJTpLiwH5qrTnpyeoA81+fMxv4+IZhj5i50/fa TI9eaXtX0y37p8oaA3qs1j0W5VJAJwTOLoyTJnao0w/Z+gT3dUFH/GXEcR7P7+ASC4yn MytQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UtvCAFU/nOSnyXGjWOQmYnfobBMsBjcNxw4QQ8V+bJQ=; b=prX0f2+xZ9cOe/wAK550qTIJ+ZbWJEJu088RFpbN9CvQ2BiyESIQvw6O+81/t0MWga ln0Zd7qpUZL5U0yk2rBNDyxNv1dhq/YQXbLQ0MmDEAMaq0lmqeQSk51JQDgYNerajYh9 /WCeNCbp5VRwcKNNWbb0S4Q5VX8RIdASZqKly98nZIW8SfrWIENyZ2thn3Ps+C8AuRmo In66tfqqmoeDfWvkusqwEGNHXI3taJVHz5KN6xa6XlpvJ5JHNy6QOFmv64Ubm6gFwk6h D7I4HJvvvm/5xgMGIXAvQNbCp7wXUlXHOsBMW4C6j3mR0l7qOAlDa4qDO4N+P4Q8c0vi Ui7A==
X-Gm-Message-State: AMke39mXk6jfBWA5q0So/prGZ7Y2e4qRlRrEr/1CoW5dThKZ0YFcrJCIPO8KaiMR5+JWDSfyoivgXaVLuk47JA==
X-Received: by 10.223.150.110 with SMTP id c43mr4957631wra.85.1488339764535; Tue, 28 Feb 2017 19:42:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.145.5 with HTTP; Tue, 28 Feb 2017 19:42:44 -0800 (PST)
In-Reply-To: <c90b08357e00403da4b37bdefc1023ca@XCH-ALN-001.cisco.com>
References: <148821563731.21121.441798485413773688.idtracker@ietfa.amsl.com> <492085d7-d2ba-f2ac-80ea-67ffee013041@gmail.com> <c90b08357e00403da4b37bdefc1023ca@XCH-ALN-001.cisco.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Tue, 28 Feb 2017 22:42:44 -0500
Message-ID: <CAG4d1reYuTfwM7c9Hy+KxuWygb4NUCCP_oH1DFnOL5pNL90aCw@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Content-Type: multipart/alternative; boundary=001a11476a30f86c530549a31a56
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/h_xhOdaREMsKMKPHpXVbagdo0aY>
Cc: "isis-wg@ietf.org" <isis-wg@ietf.org>, "rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, "internet-drafts@ietf.org" <internet-drafts@ietf.org>, "ospf@ietf.org" <ospf@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: Re: [Isis-wg] New Version Notification for draft-bryant-rtgwg-param-sync-01.txt
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: Wed, 01 Mar 2017 03:42:49 -0000

Hi Les,

I will note that the MRT ISIS and OSPF drafts include the extension for
convergence time.
I believe this draft was motivated by a concern that those extensions would
not be seen and
realized to be generally useful.

Regards,
Alia

On Tue, Feb 28, 2017 at 10:35 PM, Les Ginsberg (ginsberg) <
ginsberg@cisco.com> wrote:

> Stewart -
>
> This draft discusses two things:
>
> 1)You propose to advertise "convergence time" so that routers utilizing a
> form of FRR can determine when it is safe to start utilizing the post
> convergence path. All this requires is advertisement of a value and
> definition of how routers in the network should make use of this value -
> specifically use the maximum advertised value as the lower bound for how
> long a repair path should continue to be used.
>
> This proposal deserves to be discussed on its own merits - something I
> will NOT do in this email.
>
> 2)Rather than simply define the new advertisement as (for example) a new
> sub-TLV in IS-IS Router Capability TLV, you have decided that there is
> "general class of problem" that needs to be addressed and so you have
> invented a "routing parameter synchronization protocol". This proposes to
> "encapsulate" the above parameter and some yet to be defined set of future
> parameters in a common container- suggesting we will have a large number of
> such parameters in the future and that they have some logical relationship.
>
> I find this proposal unnecessary and undesirable. I do not see any value
> add to encapsulating multiple parameters which are otherwise unrelated in a
> common container simply because there may be some algorithm (unique to each
> parameter) which needs to be applied when making use of each parameter.
>
> If your concern is consumption of sub-TLV codepoints in IS-IS, it is worth
> reviewing the current status. RFC 4971 which originally defined the Router
> Capability TLV was published in 2007. Over the nearly 10 years in which
> this has been available there have been 21 codepoints assigned. There are
> two or three more that I am aware of that are in the works, so in 10 years
> we will have consumed less than 10% of the available codepoints. I am quite
> comfortable with this rate of consumption.
>
> If you believe there is about to be an explosion of code point requests I
> wish you would be more forthcoming as to what you expect as it would then
> be appropriate to consider whether this set of candidates is an appropriate
> use of the routing protocol and the Router Capability TLV.
>
> My recommendation is to write a draft confined to the definition of the
> new convergence time parameter you wish to advertise and let us review that
> on its own merits.
>
>    Les
>
> > -----Original Message-----
> > From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Stewart Bryant
> > Sent: Monday, February 27, 2017 9:23 AM
> > To: internet-drafts@ietf.org; Chris Bowers; Alia Atlas; rtgwg@ietf.org;
> rtgwg-
> > chairs@ietf.org; isis-wg@ietf.org; ospf@ietf.org
> > Subject: Re: New Version Notification for draft-bryant-rtgwg-param-sync-
> > 01.txt
> >
> > Resend with correct ISIS WG email address
> >
> > Following discussion at the last IETF, I have made a number of changes
> to the
> > text to emphasis that this protocols is only to be used for the
> synchronization
> > of parameters needs by the routing system.
> >
> > As agreed at the RTGWG meeting I am notifying RTGWG, ISIS and OSPF WGs.
> >
> > The draft can be found here:
> >
> > URL:
> > https://www.ietf.org/internet-drafts/draft-bryant-rtgwg-
> param-sync-01.txt
> > Status:
> > https://datatracker.ietf.org/doc/draft-bryant-rtgwg-param-sync/
> > Htmlized:       https://tools.ietf.org/html/
> draft-bryant-rtgwg-param-sync-01
> > Diff:
> > https://www.ietf.org/rfcdiff?url2=draft-bryant-rtgwg-param-sync-01
> >
> > The following is a summary of the changed:
> >
> > I have changed the title to:
> >
> > Synchronisation of Routing Parameters
> >
> > =========
> >
> > I have added in the introduction:
> >
> > Note that this protocol is only intended to be used for the propagation
> of
> > parameters needed to support the operation of the routing system. It MUST
> > NOT be used as a general purpose parameter exchange protocol, and in
> > particular it MUST NOT be used as a parameter negotiation protocol, since
> > such use may degrade the ability of the underlying link-state routing
> protocol
> > to carry our its essential purpose.
> >
> > ========
> >
> > I have changed the IANA text to say:
> >
> > Synchronisation of Routing Parameters
> >
> > ========
> >
> > I have added to the security section:
> >
> > In specifying a new parameter, consideration must be given to the impact
> of
> > the additional parameter, and in particular the rate of change of that
> > parameter, on the dynamics of the link-state routing protocol in use. In
> the
> > specific case of the Convergence Timer, the amount of data being carried
> and
> > the rate of change of the parameter value will have a negligible impact
> on the
> > link-state routing protocol in use.
> >
> > =========
> >
> > Incorporated a number of review suggestions by Mohamed Boucadair (Mod)
> >
> > Added
> >
> > Such consistency may be ensured by deploying automated means such as
> > enforcing the new value by invoking the management interface of all
> > involved routers. For example, a central management entity may be
> > responsible for communicating the new configuration value by means of
> > vendor-specific CLI, NETCONF, etc. This approach may be attracting if all
> > involved nodes expose technology-agnostic and vendor-independent
> > interfaces to tweak a given network-wide configuration parameter.
> >
> > ======
> >
> > I would like to propose that we move this forward to become a WG draft
> and
> > refine the detail under the WG process.
> >
> > - Stewart
> >
> > _______________________________________________
> > rtgwg mailing list
> > rtgwg@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtgwg
>