Hi Deborah,
On 2/24/18, 4:07 PM, "BRUNGARD, DEBORAH A" <[email protected]> wrote:
Hi Acee,
Sorry for not responding earlier, I had an unexpected disruption to my
schedule these last days.
I was concerned as the document itself says "Optionally, implementations
may also offer alternative algorithms." So it is not clear if it is the
algorithm or the parameters which are intended PS.
This is the reality that IGP implementations that have been using their
proprietary SPF backoff algorithms for decades are not going to move to the
standard mechanisms as their default overnight.
And especially concerning is section 7 on partial deployment. It states the
algorithm is only effective if it is deployed on all routers, and partial
deployment will increase the frequency and duration of micro-loops. It does go
on to say operators have progressively replaced an implementation of a given
algorithm by a different one.
If this is to be PS, then you need to provide guidance on how an operator
is to do the upgrade to this new algorithm on a network. I understand there are
prototype implementations, but I'm concerned on field grade deployments in
existing networks.
The IETF can't just mandate that vendors implement the new standard SPF backoff
algorithm, make it the default SPF Backoff, or that operators deploy it. I
believe we have provided ample guidance by indicating that the full benefit is
only obtained when the same algorithm is deployed over the IGP domain (or at
least an area). The standardization of the SPF Backoff algorithm is the start
of the journey, not the destination.
Thanks,
Deborah
-----Original Message-----
From: Acee Lindem (acee) [mailto:[email protected]]
Sent: Wednesday, February 21, 2018 7:53 PM
To: BRUNGARD, DEBORAH A <[email protected]>; The IESG <[email protected]>
Cc: [email protected]; Uma Chunduri
<[email protected]>; [email protected]; [email protected]
Subject: Re: Deborah Brungard's Discuss on
draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS)
Hi Deborah,
Given that the goal of RFC 6976 was much more ambitious and the mechanisms
are much more complex, I don't think this draft should be put in the same
category.
What we have done is precisely specify a standard algorithm for IGP SPF
back-off. When deployed, this standard algorithm will greatly improve (but not
eliminate) micro-loops in IGP routing domains currently utilizing disparate SPF
back-off algorithms. The problem statement draft best articulates the impact of
differing SPF back-off algorithms:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Drtgwg-2Dspf-2Duloop-2Dpb-2Dstatement-2D06.txt&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=lB8O9Nd8E9rpRoJj0YX-mV3Tpp8iWGOSIp_fkDPkMuA&s=Vtva23qDNV_XHrGXH4C87wmfZuLcxGEDJAXqVihSSPw&e=
. Finally, there have been several prototype implementations validating the
algorithm specification's completeness and clarity.
Thanks,
Acee
Deborah Brungard has entered the following ballot position for
draft-ietf-rtgwg-backoff-algo-07: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=lB8O9Nd8E9rpRoJj0YX-mV3Tpp8iWGOSIp_fkDPkMuA&s=LvqOOWwzZ-3P6mF9xQUGj2HWklodlOlWO94fprhgwc8&e=
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Drtgwg-2Dbackoff-2Dalgo_&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=lB8O9Nd8E9rpRoJj0YX-mV3Tpp8iWGOSIp_fkDPkMuA&s=YnZA5VGqF0T8BAOlFKka0ckWFUhUDHd0sILBbPRRaeU&e=
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
While I agree with Alvaro's concerns, my concern is the appropriateness
of this document as PS.
This document should have a similar status as RFC6976 (Informational)
which also provided a
mechanism that prevented transient loops saying "the mechanisms
described in this
document are purely illustrative of the general approach and do not
constitute a protocol
specification". Especially as this document compares itself to RFC6976,
saying RFC6976 is a
"full solution".
With a change of status to Informational, this document would be better
scoped as providing guidance vs. a specification.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
