Ok for me - if Alvaro's comments are resolved- Thanks- Deborah
-----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Wednesday, February 28, 2018 1:42 PM To: BRUNGARD, DEBORAH A <[email protected]> Cc: [email protected]; [email protected]; Uma Chunduri <[email protected]>; [email protected]; Acee Lindem (acee) <[email protected]>; The IESG <[email protected]>; Alvaro Retana <[email protected]> Subject: RE: Deborah Brungard's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS) Hi Deborah, > From: BRUNGARD, DEBORAH A [mailto:[email protected]] > Sent: Wednesday, February 28, 2018 6:23 PM > Hi Bruno, > > Inline- > > Quick summary - thanks for the proposed changes. You do need to pick "one" > algorithm name for > this document. I will wait to clear once Alvaro's concerns are addressed. OK. Name uniformly changed to "SPF Back-off Delay algorithm". (note that we are open to a different name if needed) I've uploaded a new version so that you can check and that we can close this thread Htmlized: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Drtgwg-2Dbackoff-2Dalgo-2D09&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=o-3Cw0NaTHiAwueJLvH42YSvIvCS5ykWzfDqg0e0bq4&s=b7qB1gMCWU-sOTiC3fxI0QFjNp1bkvJmJ7yKs2Z8o2c&e= Diff: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Drtgwg-2Dbackoff-2Dalgo-2D09&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=o-3Cw0NaTHiAwueJLvH42YSvIvCS5ykWzfDqg0e0bq4&s=elXNFgvb4fTgqLv83tf2MQ7UesF0BMoirNRe4vdWSuE&e= Thanks --Bruno > > Thanks, > Deborah > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Wednesday, February 28, 2018 10:45 AM > To: BRUNGARD, DEBORAH A <[email protected]> > Cc: [email protected]; [email protected]; Uma Chunduri > <[email protected]>; draft- > [email protected]; Acee Lindem (acee) <[email protected]>; The > IESG > <[email protected]>; Alvaro Retana <[email protected]> > Subject: RE: Deborah Brungard's Discuss on draft-ietf-rtgwg-backoff-algo-07: > (with DISCUSS) > > Hi Deborah, > > Please see inline > > > -----Original Message----- > > > From: BRUNGARD, DEBORAH A [mailto:[email protected]] > > > Sent: Wednesday, February 28, 2018 12:48 PM > > > > > > > > > Hi Acee, > > > > > > I think Alvaro is on vacation this week without email access. As I noted > in my Discuss, I support > > > Alvaro's concerns on incompleteness and vagueness. I am interested in > Alvaro's response on > the > > > update if it addresses his concerns. > > 1) Regarding Alvaro's DISCUSS, > > We have engaged the discussion on his points. Thanks for the info that he is > on vacation this week. > No problem, we'll obviously wait for this return. > > 2) Regarding your DISCUSS, > > Can we work on resolving your point and hopefully your DISCUSS even in the > absence of Alvaro? > > As a reminder, your DISCUSS is the following: > > "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." > > So in summary your DISCUSS is about the status of this document: STD track > vs informational. > > Acee has replied on this point in the following thread, and ultimately you > did not follow up. So I > though the point was closed. > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__mailarchive.ietf.org_arch_msg_rtgwg_pqGrmtI7MYVqU8tSNwId- > 2DQEROYs&d=DwIGaQ&c=LFYZ- > o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=A2tvhbHEsp1wnyVMHQNQQZif9dyJ > asSzHeKs92fsD8Y&s=lSwLlzGBRCELFV0V0oBnY2bQ-A4OuduzADebFkfZG0A&e= > > [deborah] Considering Acee's reply, I was hoping the updated draft would > take into consideration > my concerns. > > So could you please follow up on this thread so that we can advance on this > point? > > I'll also contribute below in this email in reply to your specific comments. > > Regarding STD status, a distributed Link State IGP, requires, in order to > produce consistent routing > table across the network, to perfom the same computation (SPF), using the > same info/database, at > the same time. > > Given that all implementations use SPF back off delay algorithms (by > default), in order to fulfill this > routing consistency across the network, one STD SPF back off delay algo > needs to be specific. By > doing so, this document helps addressing the above two latest points (same > time, same LSDB). > > Also, in case you missed it as the email was in a different thread, Alia has > also stated that this > needs to be standard track. > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__mailarchive.ietf.org_arch_msg_rtgwg_EDpT9lvKVDaBjI8g- > 5FQHznZMdTNI&d=DwIGaQ&c=LFYZ- > o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=A2tvhbHEsp1wnyVMHQNQQZif9dyJ > asSzHeKs92fsD8Y&s=0D6i-TImKbNbK7b5xVr2UMjpZxd_fof-ni909q3UpYA&e= > > [deborah] Several ADs supported my concern on the status of this document. I > noted Alia supports > PS. Your suggestions below do help with some of the vagueness. Before > clearing my Discuss, I > would like to see how Alvaro's concerns are addressed. > > 3) Regarding your new additional comments below > > It's not clear to me whether they are additional points in your DISCUSS or > just regular comments. > > Reading the discuss criteria, they really likes non-blocking comments to me. > > 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=A2tvhbHEsp1wnyVMHQNQQZif9dyJ > asSzHeKs92fsD8Y&s=pfjoFgZh4KBKpX7h8rBXNvSDwNhHAjoRrBE_LB231To&e= > > So you could please clarify the status of those comments? > > [deborah] > My mail below (and to Acee) was identifying specific sentences in the > document which I > interpreted as illustrative of a general approach vs. a specific solution > (my Discuss). On the > Discuss criteria, refer to point 10, "Standards Track document that > contains only informational > guidance". Plus, I endorsed Alvaro's (point 1, 2, 3). > > > > > > I don't see any changes for my noted concerns on vagueness. > > Acee replied to your email and you did not reply. > > As previously noted, I'll also reply on your points in this email, below. > > > The confusing sentence remains in > > > the introduction "Optionally, implementations may also offer alternative > algorithms." > > - I'm personally not sure to see what is confusing in this sentence. > > - As Acee replied, this is just a statement about the reality of existing > implementations and > deployments. > > - That being said, that sentence does not really add anything to the > specification. Hence if this is a > blocking point to you, I've just removed it. Problem solved. > > [deborah] Good. > > >And later in > > > section 5 saying it "describes the abstract finite state machine". > > I'm not sure to see the issue but changed to > > OLD: This section describes the abstract finite state machine (FSM) > > NEW: This section specifies the finite state machine (FSM) > > [deborah] Good. > > Also changed (*3): > > OLD: FSM abstract timer > > NEW: FSM timer > > [deborah] Good. > > > So to me, it still is not clear if this document is a PS for the > algorithm or for the parameters > > The document is a PS for the algorithm. > > We have initiated a discussion with Alvaro regarding the additional > specification of default > parameters for the specific cases where they are useful. > > > e.g. any > > > SPF delay algorithm that supports the IETF parameters can be used so long > as it derives the > same > > > results of the "abstract" state machine. > > I'm not sure how this question is specific to this document. > > Personally, I'd tend to generally reply "yes". i.e., considering the node as > a black box, if it's behavior > conforms to the behavior defined in the IETF document, I'd say that the node > is compliant with the > IETF document. > > e.g., if the IETF document defines a timer of 3 seconds, it looks ok for me > if an implementation > waits for 3 consecutive 1 second timers. > > But any general answer from the IETF works for me. It seemed to me that the > IETF does not give > position regarding conformance. > > [deborah] So as not to go backwards on the discussion, I'll accept this > document is for this specific > algorithm (PS) vs. guidance for any algorithm (Info). Let's focus on making > this PS quality. > > [deborah] <cut text - no questions> > > > The naming of the algorithm is also vague. > > I guess that the discussion on the name is not a DISCUSS/blocking-issue. Is > this? > > [deborah] It is if the PS uses two different names in the document itself > for the algorithm being > proposed as PS. > > > There are only two uses of "backoff", in the title and in the abstract. > The document uses "SPF > > > delay algorithm". > > The document defines a "backoff" procedure for the IGP SPF, by introducing a > delay and a delay > which is increasing as the IGP keeps computing SPFs. > > This document defines the algorithm/procedure computing this delay. > > > Looking at the ospf-yang document, it doesn't reference this document or > use the feature name > > > "backoff algorithm". It refers to an "SPF delay algorithm" and lists the > parameters. Either > "backoff" > > > or "SPF delay" naming should be used consistently if it is the titled > algorithm which is PS. > > Good comments. But those are for the YANG documents. Not this one. > > [deborah] Several words were cut in your response, I commented this document > (not the YANG > document) uses two names for the algorithm: "backoff algorithm" and "SPF > delay algorithm". Pick > one. > > Thanks > > --Bruno > > > > > Thanks, > > > Deborah > > > > > > > > > -----Original Message----- > > > From: iesg [mailto:[email protected]] On Behalf Of Acee Lindem (acee) > > > Sent: Tuesday, February 27, 2018 2:36 PM > > > To: BRUNGARD, DEBORAH A <[email protected]>; The IESG <[email protected]>; Alvaro > Retana > > > <[email protected]> > > > Cc: [email protected]; [email protected]; Uma Chunduri > <[email protected]>; draft- > > > [email protected] > > > Subject: Re: Deborah Brungard's Discuss on > draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS) > > > > > > Hi Deborah, Alvaro, > > > > > > > > > > > > Bruno has posted -08 version addressing Alvaro's default timer value > request. Can you clear > your > > > DISCUSSES? > > > > > > > > > > > > > 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=EanJBdMh8ViXUpOAcuGDU3_m4R > > > EU12AjmiAeQh4TZ5o&s=nNjJEE9Ft49chxnM3q347Q6JACjZaUR3XaoDmZkyXJA&e= > > > > > > > > > > > > Thanks, > > > > > > Acee > > > > > > > > > > > > On 2/24/18, 8:52 PM, "Acee Lindem (acee)" <[email protected]> wrote: > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________________________________________________ > _________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees > et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, > veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant > susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be > protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its > attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or > falsified. > Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
