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

From: Stewart Bryant <[email-masked]>
Date: Mon, 27 Feb 2017 17:20:51 +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

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 27 Feb 2017 17:23:28 +0000

Resend with correct ISIS WG email address

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

=========

========

========

=========

Added

======

- Stewart

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 1 Mar 2017 03:35:08 +0000

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:[email-masked]] On Behalf Of Stewart Bryant
> Sent: Monday, February 27, 2017 9:23 AM
> To: [email-masked]; Chris Bowers; Alia Atlas; [email-masked]; rtgwg-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: New Version Notification for draft-bryant-rtgwg-param-sync-
> 01.txt
> 
> 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.
> 
> 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.
> 
> ========
> 
> 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.
> 
> =========
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Alia Atlas <[email-masked]>
Date: Tue, 28 Feb 2017 22:42:44 -0500

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) <
[email-masked]> wrote:

> 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.
>
> 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
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 1 Mar 2017 03:55:20 +0000

Alia –

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

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.

   Les

From: Isis-wg [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Tuesday, February 28, 2017 7:43 PM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> wrote:
Stewart -

   Les

> From: rtgwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Stewart Bryant
> To: [email-masked]<mailto:[email-masked]>; Chris Bowers; Alia Atlas; [email-masked]<mailto:[email-masked]>; rtgwg-
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>