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

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

Return-Path: <akatlas@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 7AC911295C9; Wed, 1 Mar 2017 08:33:34 -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 yqmQCsyyejC1; Wed, 1 Mar 2017 08:33:32 -0800 (PST)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 9A3FB1294CF; Wed, 1 Mar 2017 08:33:31 -0800 (PST)
Received: by mail-wr0-x233.google.com with SMTP id g10so34042672wrg.2; Wed, 01 Mar 2017 08:33:31 -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=Z05CVFSbxb+LESuE3c8uxldkIXBMe6QaY5W8hF+plrI=; b=HO2hYDD77MPML0LwhblFNxp6+/rXmt6dhzsrDMp2g2uBUYY/EoCLO5LGdFiBp+UuQc w5kcXvI6aCI/FWv/yd9xqO1PbtoYV1YHLc63eeWuvMUm8XP0OgatcsR+IuNTcW/691vX EfK1IzcdMCOXnbF5DP54d9LSjpLJgWDEyDpRw4n58O0W/G1tciqthEYM3XumkXw1y5EN Pb6pew/EwI/PXQk1sYfsiACHswKYqvABglJXEzW1HF2lzqQPD/CPLk7T4Unb7TF1WtBt 5b9gMKffMV5Io2Z+4c7CHV/oh8yV0cSGROsYD/YV/iaZDn7neTnr5GMPHmsKLiPdjF5z eBKA==
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=Z05CVFSbxb+LESuE3c8uxldkIXBMe6QaY5W8hF+plrI=; b=GUF0+Qez74s2tkxIYsi3wvRnmZ7nDIcQKyzITRiA21zNoiCma0FQUI7k4nb6wscAJJ v9RxW4GLWSpFVrd9LDumKbVtITuLR7lgffoUIghrQpMcvCXSI5jYFgoXqr/229ZrZizV bSHaIWpebyP3Y6o3p2Nc3MoyAKJ0EGEQlVWBSXYLSYbLVaiAjy7fTJ82PCOc8C8VJZmY kQ4xf57Dsd1JPX9m3sPHlMbLUw9KI3ce1Mo38UzRUKMlxloWS8wmqn/NM0tgSI8mVwEG RAAW8wOuURzUz/MLZRuJB6SVpbe7XjoFbxvqqQE6S4hZsMSe3c61IaEhRwbS9QBN0zTL D/WQ==
X-Gm-Message-State: AMke39kBlO5iFtecctmMoZTADplFSBw/THFomIe4a0TTSc8KteWFINKe4AX0lFhSFjF1qk383odklRbIfqGWSA==
X-Received: by 10.223.136.4 with SMTP id d4mr8193452wrd.44.1488386009765; Wed, 01 Mar 2017 08:33:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.145.5 with HTTP; Wed, 1 Mar 2017 08:33:29 -0800 (PST)
In-Reply-To: <b179b85300e1459f90e1b57fea11849c@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> <CAG4d1reYuTfwM7c9Hy+KxuWygb4NUCCP_oH1DFnOL5pNL90aCw@mail.gmail.com> <b179b85300e1459f90e1b57fea11849c@XCH-ALN-001.cisco.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Wed, 01 Mar 2017 11:33:29 -0500
Message-ID: <CAG4d1rfrDn+=ucR-fFv1zQJq3P6NNdwj3DOJ6-LPoW9=Yo+gAQ@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Content-Type: multipart/alternative; boundary="001a11461d1866baf30549addfaa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/lOwLC5is2qX4l8Rknt-SSDfDFeY>
Cc: OSPF List <ospf@ietf.org>, "rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: Re: [OSPF] [Isis-wg] 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: Wed, 01 Mar 2017 16:33:34 -0000

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

Alia –



Thanx for reminding about the MRT drafts (and so quickly J). Both seem to
have expired.


:-)   The base MRT drafts have been published as RFCs.  The MRT LDP
extensions is past WGLC now.
The ISIS and OSPF MRT drafts have been waiting for the outcome of this
discussion.

I don’t see the connection between extending the use cases for a
convergence time advertisement beyond MRT and the need for encapsulating
other unrelated parameters into a single container.


Right - it's not clear to me whether there is going to be a finding/use
issue with the convergence time advertisement if published as part of the
MRT drafts.  I am interested to see if there are additional parameters that
would make sense to be in the single container.

Regards,
Alia



   Les



*From:* Isis-wg [mailto:isis-wg-bounces@ietf.org] *On Behalf Of *Alia Atlas
*Sent:* Tuesday, February 28, 2017 7:43 PM
*To:* Les Ginsberg (ginsberg)
*Cc:* isis-wg@ietf.org; rtgwg-chairs@ietf.org; internet-drafts@ietf.org;
ospf@ietf.org; rtgwg@ietf.org
*Subject:* Re: [Isis-wg] New Version Notification for
draft-bryant-rtgwg-param-sync-01.txt



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/d
raft-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