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

Stewart Bryant <stewart.bryant@gmail.com> Mon, 27 February 2017 17:21 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD78012A270; Mon, 27 Feb 2017 09:21:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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 FbsRhTEaQS4h; Mon, 27 Feb 2017 09:21:00 -0800 (PST)
Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 6049012A272; Mon, 27 Feb 2017 09:20:56 -0800 (PST)
Received: by mail-wr0-x242.google.com with SMTP id q39so11209505wrb.2; Mon, 27 Feb 2017 09:20:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=SodGcG92NAskIPPM74D0mZ+LAJwxz/a9RSw+povv4XI=; b=D/QQHOFQ1KJyVKi/AqMH4w+FWkSaPP7cKepuwNb1SiB3GB2//3YBYARLi09Dhg1BXh mdu/qAJIFnVYFqMDQ/fbJSxXqNV+CnJd/uR2CXDYRLI7IxB24mBma2FG0dEsp17cH8x+ wiXQaO3QsBuXqzpLY/Qk0u+uNqtDRl20sZtdKhU/wzBWjB7KwRcH2YLJmpY20V3+XLkE 6RwRu8pkGm+zel1BjpC7LwlZ8djz2yKQoHO6S4/BkyMBqqo0g/5LZ/XH3KBiZZJkNaSx H6EotMSqFFf2MTlBSEiMTmSwg+K3way7JM68usYBtiN/2IQUzCY/97B/1q8xJWFtZfT9 ciIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=SodGcG92NAskIPPM74D0mZ+LAJwxz/a9RSw+povv4XI=; b=J/5AQ38e52Lo5Shk9YXAUvl4YFs1K9GgGd3gow6pSh6H4wQJGA8zOZAEDGcXQygUbP Y5aTnynRiBX0WT6vlcb6Rl6EoPhpJsAkylOcGnM2DporOeulAf4GJyQ540pdXQVH4P2H 9rvnTQLTBcaJGUU+hNO5FEKA7NCj88mIL4s63DKvt8QX7G0qAAPgxC2B/bpySC80M224 eBEyrVDZ/DXm2jozKbkmmUpXpnpjX4Df3NAkd6CNoYzOEceB7WdDvaNG44wkqlzExP8b NjlxcIns7Vwk0+vXN4WLUim1vp7SzbS3vdsRrW9l9qeo8PyGA1JzXyZkNTz87p8HULiX lXFg==
X-Gm-Message-State: AMke39kIIHqz0C+bN5W6pHxtBRhWplFVWb/2AZ30alap3hZ35Ixul0xWr19SYdGt/fPsMA==
X-Received: by 10.223.133.164 with SMTP id 33mr16286486wrt.39.1488216054793; Mon, 27 Feb 2017 09:20:54 -0800 (PST)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id l10sm14490997wrb.3.2017.02.27.09.20.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2017 09:20:54 -0800 (PST)
To: internet-drafts@ietf.org, Chris Bowers <cbowers@juniper.net>, Alia Atlas <akatlas@gmail.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, isis@ietf.org, ospf@ietf.org
References: <148821563731.21121.441798485413773688.idtracker@ietfa.amsl.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <1de39f4c-e8c2-06aa-37cf-4d2ed2649fa1@gmail.com>
Date: Mon, 27 Feb 2017 17:20:51 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <148821563731.21121.441798485413773688.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/Fi4s-9WU2qqhgZtjZtlwW-v5qEw>
Subject: Re: [OSPF] New Version Notification for draft-bryant-rtgwg-param-sync-01.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 27 Feb 2017 17:21:02 -0000

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