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 protected]> 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:[email protected]] On Behalf Of Stewart Bryant > > Sent: Monday, February 27, 2017 9:23 AM > > To: [email protected]; Chris Bowers; Alia Atlas; [email protected]; > rtgwg- > > [email protected]; [email protected]; [email protected] > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/rtgwg >
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
