Re: [OSPF] 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/
> 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
> > rtgwg@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtgwg
>