On 28/02/2017 17:20, t.petch wrote:
----- Original Message -----
From: "Stewart Bryant" <[email protected]>
Sent: Tuesday, February 28, 2017 11:48 AM
Hi Tom
The intent is clear in the rest of the text.
This was an oversight in the editing.
How about "Network Wide Routing Parameter Registry"?
Stewart
I would like it to start with 'Routing ...' since that makes it appear
where I expect to find it in the (flat and very long) IANA parameter
list.
Routing Parameter Network Wide Registry perhaps
Clumsier I know but I am attached to an initial Routing which collates
it alongside RIP, RPL and such like.
Horribly clumsy! It does not scan at all.
Maybe Routing Parameter Synchronization Registry?
... but isn't this in the weeds when we are still at the adoption stag?
- Stewart
Tom Petch
- Stewart
On 28/02/2017 10:54, t.petch wrote:
Stewart
You say that this protocol is only intended to be used for the
propagation of
parameters needed to support the operation of the routing system but
the
registry you create is named
Network Wide Parameter Registry
which to me still carries the message that this is all embracing,
not
just for routing.
Tom Petch
----- Original Message -----
From: "Stewart Bryant" <[email protected]>
Sent: Monday, February 27, 2017 5:23 PM
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.tx
t
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
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
