Document Action: 'Link State protocols SPF trigger and delay algorithm impact on IGP micro-loops' to Informational RFC (draft-ietf-rtgwg-spf-uloop-pb-statement-10.txt)
The IESG has approved the following document: - 'Link State protocols SPF trigger and delay algorithm impact on IGP micro-loops' (draft-ietf-rtgwg-spf-uloop-pb-statement-10.txt) as Informational RFC This document is the product of the Routing Area Working Group. The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ Technical Summary Micro-loops are transient forwarding loops that can occur among routers using hop-by-hop forwarding. This document analyzes the impact of using different Link State IGP implementations in a single network with respect to micro-loops. The analysis focuses on the SPF triggers and SPF delay algorithms. Working Group Summary The final version of the document has strong consensus in the WG. Input from the WG was incorporated in the document. Document Quality The document is of high quality. Two Routing Area Directorate reviews were done. The first was done by Mike Shand around the time of working group adoption. This review pointed out some issues related to terminology and phrasing, as well as a generalization about the size of networks. These issues were addressed by the authors. The main issue raised by the second review (done by Tomonori Takeda) was the fact the document was classified as Standards Track. This was addressed by changing it to Informational. Personnel Document Shepherd: Chris Bowers Responsible Area Director: Martin Vigoureux ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
I-D Action: draft-ietf-rtgwg-spf-uloop-pb-statement-10.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group WG of the IETF. Title : Link State protocols SPF trigger and delay algorithm impact on IGP micro-loops Authors : Stephane Litkowski Bruno Decraene Martin Horneffer Filename: draft-ietf-rtgwg-spf-uloop-pb-statement-10.txt Pages : 15 Date: 2019-01-16 Abstract: A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm. In this document, we are trying to analyze the impact of using different Link State IGP (Interior Gateway Protocol) implementations in a single network, with respect to micro-loops. The analysis is focused on the SPF (Shortest Path First) delay algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-10 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-spf-uloop-pb-statement-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-spf-uloop-pb-statement-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
Re: Secdir last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-09
If the security considerations are addressed in a different document, this should be stated in the security considerations section. On Mon, Jan 7, 2019 at 12:05 PM Stewart Bryant wrote: > > On 07/01/2019 16:11, Phillip Hallam-Baker wrote: > > Reviewer: Phillip Hallam-Baker > Review result: Has Issues > > The document describes the problem and solution pretty clearly. Unfortunately, > there is no discussion of the security considerations which is not appropriate > for a document addressing an availability which is a security issue. > > While microloops can form by chance, some consideration should be given to the > possibility that an attacker could induce a loop to perform a DoS attack. > > In section 1 the text says: > > [RFC8405] defines a solution that satisfies this problem statement >and this document captures the reasoning of the provided solution. > > It is safe to assume that the reader of this text would have read > normative reference RFC8405 and thus would be fully aware of the security > issues related to the solution being analysed. > > An attacker that had access to a network such that they could induce > microloops would have the ability to do many worse things to the network. > > If they were able to attack in-band they could poison the routing system > to take it down in far more interesting ways. Operators use security at the > physical and network layer to prevent this. > > If they were operating at the physical layer then they could take circuits > down at will and cause microloops in the base protocol, traffic overloads > and application malfunction. > > Thus if the attacker could deploy either of those attacks in a network to > induce micro-loops, then any security considerations in this draft would > count for nothing. > > The draft is an analysis, and thus I think that it correctly states that > it introduces no additional matters for security consideration. > > - Stewart > > -- Website: http://hallambaker.com/ ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-08
Dan, thank you for your review. Stephane, thank you for addressing Dan’s comments. I entered a No Objection ballot. Alissa > On Dec 21, 2018, at 10:13 AM, Dan Romascanu wrote: > > Hi Stephane, > > Draft 09 addresses my (minor) concerns. Thank you for the prompt response end > for the edits. > > Regards, > > Dan > > > On Fri, Dec 21, 2018 at 3:46 PM <mailto:stephane.litkow...@orange.com>> wrote: > Hi, > > The -09 has been published and should address your comment. > > Feel free to raise any additional concern. > > Brgds, > > -Original Message- > From: Dan Romascanu [mailto:droma...@gmail.com <mailto:droma...@gmail.com>] > Sent: Tuesday, December 11, 2018 15:29 > To: gen-...@ietf.org <mailto:gen-...@ietf.org> > Cc: draft-ietf-rtgwg-spf-uloop-pb-statement@ietf.org > <mailto:draft-ietf-rtgwg-spf-uloop-pb-statement@ietf.org>; i...@ietf.org > <mailto:i...@ietf.org>; rtgwg@ietf.org <mailto:rtgwg@ietf.org>; > droma...@gmail.com <mailto:droma...@gmail.com> > Subject: Genart last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-08 > > Reviewer: Dan Romascanu > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>. > > Document: draft-ietf-rtgwg-spf-uloop-pb-statement-08 > Reviewer: Dan Romascanu > Review Date: 2018-12-11 > IETF LC End Date: 2018-12-18 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > Ready > > This document analyzes the impact of using non-standardized IGP Link State > implementations resulting in non-consistent tuning of parameters in the > network > and increased possibility of creating micro-loops. It can be viewed as a > problem statement for standardized solutions like RFC 8405. > > The document is short and clear for implementers and operators familiar with > networks running this class of protocols. Diagrams and table help in reading > and understanding the material. > > Major issues: > > none > > Minor issues: > > none > > Nits/editorial comments: > > 1. In the introduction: > > > For non standardized timers, implementations are free to implement it >in any way. > > It is not obvious what 'it' means. I guess it's about different values of > timers resulting in the possibility of micro-loops creation, but it would be > better to clarify. > > 2. It would be useful to provide short explanations that make the figures more > clear. In fig. 1 - what do the nodes represent (routers implementing the > protocols), in fig. 2, and 3 - the abbreviations on the y axis > > > > _ > > 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. > > ___ > Gen-art mailing list > gen-...@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
Warren Kumari's Yes on draft-ietf-rtgwg-spf-uloop-pb-statement-09: (with COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-rtgwg-spf-uloop-pb-statement-09: Yes 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://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ -- COMMENT: -- Thank you for writing this -- I found it a really interesting and useful read, and so I'm balloting Yes. ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
Ben Campbell's No Objection on draft-ietf-rtgwg-spf-uloop-pb-statement-09: (with COMMENT)
Ben Campbell has entered the following ballot position for draft-ietf-rtgwg-spf-uloop-pb-statement-09: No Objection 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://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ -- COMMENT: -- Thanks for using the updated RFC 8174 boilerplate instead of that from 2119. However, IDNits claims that there are no normative keywords at all, so is the boilerplate needed in the first place? ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
RE: Secdir last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-09
Hi, I fully agree with what Stewart has mentioned. The document does not introduce anything new regarding microloops. There is no way for an attacker to trigger a microloop except by creating some IGP events (link or node down for example). In addition, there will never be a guarantee that there will be a microloop. Again as Stewart has mentioned, if such an attacker can access to a router to create IGP events, it would be easier for him to bring the network down (erasing router config, changing critical parameters…) rather than trying to play with microloops. Brgds, From: Stewart Bryant [mailto:stewart.bry...@gmail.com] Sent: Monday, January 07, 2019 18:05 To: Phillip Hallam-Baker; sec...@ietf.org Cc: draft-ietf-rtgwg-spf-uloop-pb-statement@ietf.org; i...@ietf.org; rtgwg@ietf.org Subject: Re: Secdir last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-09 On 07/01/2019 16:11, Phillip Hallam-Baker wrote: Reviewer: Phillip Hallam-Baker Review result: Has Issues The document describes the problem and solution pretty clearly. Unfortunately, there is no discussion of the security considerations which is not appropriate for a document addressing an availability which is a security issue. While microloops can form by chance, some consideration should be given to the possibility that an attacker could induce a loop to perform a DoS attack. In section 1 the text says: [RFC8405] defines a solution that satisfies this problem statement and this document captures the reasoning of the provided solution. It is safe to assume that the reader of this text would have read normative reference RFC8405 and thus would be fully aware of the security issues related to the solution being analysed. An attacker that had access to a network such that they could induce microloops would have the ability to do many worse things to the network. If they were able to attack in-band they could poison the routing system to take it down in far more interesting ways. Operators use security at the physical and network layer to prevent this. If they were operating at the physical layer then they could take circuits down at will and cause microloops in the base protocol, traffic overloads and application malfunction. Thus if the attacker could deploy either of those attacks in a network to induce micro-loops, then any security considerations in this draft would count for nothing. The draft is an analysis, and thus I think that it correctly states that it introduces no additional matters for security consideration. - Stewart _ 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 rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
Re: Secdir last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-09
On 07/01/2019 16:11, Phillip Hallam-Baker wrote: Reviewer: Phillip Hallam-Baker Review result: Has Issues The document describes the problem and solution pretty clearly. Unfortunately, there is no discussion of the security considerations which is not appropriate for a document addressing an availability which is a security issue. While microloops can form by chance, some consideration should be given to the possibility that an attacker could induce a loop to perform a DoS attack. In section 1 the text says: [RFC8405] defines a solution that satisfies this problem statement and this document captures the reasoning of the provided solution. It is safe to assume that the reader of this text would have read normative reference RFC8405 and thus would be fully aware of the security issues related to the solution being analysed. An attacker that had access to a network such that they could induce microloops would have the ability to do many worse things to the network. If they were able to attack in-band they could poison the routing system to take it down in far more interesting ways. Operators use security at the physical and network layer to prevent this. If they were operating at the physical layer then they could take circuits down at will and cause microloops in the base protocol, traffic overloads and application malfunction. Thus if the attacker could deploy either of those attacks in a network to induce micro-loops, then any security considerations in this draft would count for nothing. The draft is an analysis, and thus I think that it correctly states that it introduces no additional matters for security consideration. - Stewart ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
Secdir last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-09
Reviewer: Phillip Hallam-Baker Review result: Has Issues The document describes the problem and solution pretty clearly. Unfortunately, there is no discussion of the security considerations which is not appropriate for a document addressing an availability which is a security issue. While microloops can form by chance, some consideration should be given to the possibility that an attacker could induce a loop to perform a DoS attack. ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
Re: RtgDir review: draft-ietf-rtgwg-spf-uloop-pb-statement-08.txt
Thanks! Tomo On 2018/12/21 22:46, stephane.litkow...@orange.com wrote: The -09 has been published and should address your comment. Feel free to raise any additional concern. Brgds, -Original Message- From: Tomonori Takeda [mailto:takeda.tomon...@lab.ntt.co.jp] Sent: Monday, December 17, 2018 10:13 To: rtg-...@ietf.org Cc: rtg-...@ietf.org; draft-ietf-rtgwg-spf-uloop-pb-statement@ietf.org; rtgwg@ietf.org Subject: RtgDir review: draft-ietf-rtgwg-spf-uloop-pb-statement-08.txt Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-rtgwg-spf-uloop-pb-statement-08.txt Reviewer: Tomonori Takeda Review Date: Dec. 17th, 2018 IETF LC End Date: Dec. 18th, 2018 Intended Status: Informational Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: This document analyzes the impact of SPF delay algorithm and associated triggers on IGP micro-loops. This document presents useful information on how mixing strategies may lead to longer micro-loops. The document is well organized, easy to read. Major Issues: None Minor Issues: None Nits: 1) Section 2 says "That part may be the main part for the first iteration but is not for subsequent IGP events. In addition, this part is very implementation specific and difficult/impossible to standardize, while the SPF delay algorithm may be standardized." It would be better to explain what "That part" and "this part" mean. I guess the text should look like: "The time to update the FIB may be the main part for the first iteration of IGP event but is not for subsequent IGP events. In addition, the time to update the FIB is very implementation specific and difficult/impossible to standardize, while the SPF delay algorithm may be standardized." Thanks, Tomonori Takeda _ 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. -- Tomonori Takeda NTT Network Service Systems Labs. +81-422-59-7092 ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
Re: Genart last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-08
Hi Stephane, Draft 09 addresses my (minor) concerns. Thank you for the prompt response end for the edits. Regards, Dan On Fri, Dec 21, 2018 at 3:46 PM wrote: > Hi, > > The -09 has been published and should address your comment. > > Feel free to raise any additional concern. > > Brgds, > > -Original Message- > From: Dan Romascanu [mailto:droma...@gmail.com] > Sent: Tuesday, December 11, 2018 15:29 > To: gen-...@ietf.org > Cc: draft-ietf-rtgwg-spf-uloop-pb-statement@ietf.org; i...@ietf.org; > rtgwg@ietf.org; droma...@gmail.com > Subject: Genart last call review of > draft-ietf-rtgwg-spf-uloop-pb-statement-08 > > Reviewer: Dan Romascanu > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-rtgwg-spf-uloop-pb-statement-08 > Reviewer: Dan Romascanu > Review Date: 2018-12-11 > IETF LC End Date: 2018-12-18 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > Ready > > This document analyzes the impact of using non-standardized IGP Link State > implementations resulting in non-consistent tuning of parameters in the > network > and increased possibility of creating micro-loops. It can be viewed as a > problem statement for standardized solutions like RFC 8405. > > The document is short and clear for implementers and operators familiar > with > networks running this class of protocols. Diagrams and table help in > reading > and understanding the material. > > Major issues: > > none > > Minor issues: > > none > > Nits/editorial comments: > > 1. In the introduction: > > > For non standardized timers, implementations are free to implement it >in any way. > > It is not obvious what 'it' means. I guess it's about different values of > timers resulting in the possibility of micro-loops creation, but it would > be > better to clarify. > > 2. It would be useful to provide short explanations that make the figures > more > clear. In fig. 1 - what do the nodes represent (routers implementing the > protocols), in fig. 2, and 3 - the abbreviations on the y axis > > > > > _ > > 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 rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
RE: Genart last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-08
Hi, The -09 has been published and should address your comment. Feel free to raise any additional concern. Brgds, -Original Message- From: Dan Romascanu [mailto:droma...@gmail.com] Sent: Tuesday, December 11, 2018 15:29 To: gen-...@ietf.org Cc: draft-ietf-rtgwg-spf-uloop-pb-statement@ietf.org; i...@ietf.org; rtgwg@ietf.org; droma...@gmail.com Subject: Genart last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-08 Reviewer: Dan Romascanu Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-rtgwg-spf-uloop-pb-statement-08 Reviewer: Dan Romascanu Review Date: 2018-12-11 IETF LC End Date: 2018-12-18 IESG Telechat date: Not scheduled for a telechat Summary: Ready This document analyzes the impact of using non-standardized IGP Link State implementations resulting in non-consistent tuning of parameters in the network and increased possibility of creating micro-loops. It can be viewed as a problem statement for standardized solutions like RFC 8405. The document is short and clear for implementers and operators familiar with networks running this class of protocols. Diagrams and table help in reading and understanding the material. Major issues: none Minor issues: none Nits/editorial comments: 1. In the introduction: > For non standardized timers, implementations are free to implement it in any way. It is not obvious what 'it' means. I guess it's about different values of timers resulting in the possibility of micro-loops creation, but it would be better to clarify. 2. It would be useful to provide short explanations that make the figures more clear. In fig. 1 - what do the nodes represent (routers implementing the protocols), in fig. 2, and 3 - the abbreviations on the y axis _ 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 rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
RE: RtgDir review: draft-ietf-rtgwg-spf-uloop-pb-statement-08.txt
The -09 has been published and should address your comment. Feel free to raise any additional concern. Brgds, -Original Message- From: Tomonori Takeda [mailto:takeda.tomon...@lab.ntt.co.jp] Sent: Monday, December 17, 2018 10:13 To: rtg-...@ietf.org Cc: rtg-...@ietf.org; draft-ietf-rtgwg-spf-uloop-pb-statement@ietf.org; rtgwg@ietf.org Subject: RtgDir review: draft-ietf-rtgwg-spf-uloop-pb-statement-08.txt Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-rtgwg-spf-uloop-pb-statement-08.txt Reviewer: Tomonori Takeda Review Date: Dec. 17th, 2018 IETF LC End Date: Dec. 18th, 2018 Intended Status: Informational Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: This document analyzes the impact of SPF delay algorithm and associated triggers on IGP micro-loops. This document presents useful information on how mixing strategies may lead to longer micro-loops. The document is well organized, easy to read. Major Issues: None Minor Issues: None Nits: 1) Section 2 says "That part may be the main part for the first iteration but is not for subsequent IGP events. In addition, this part is very implementation specific and difficult/impossible to standardize, while the SPF delay algorithm may be standardized." It would be better to explain what "That part" and "this part" mean. I guess the text should look like: "The time to update the FIB may be the main part for the first iteration of IGP event but is not for subsequent IGP events. In addition, the time to update the FIB is very implementation specific and difficult/impossible to standardize, while the SPF delay algorithm may be standardized." Thanks, Tomonori Takeda _ 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 rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
I-D Action: draft-ietf-rtgwg-spf-uloop-pb-statement-09.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group WG of the IETF. Title : Link State protocols SPF trigger and delay algorithm impact on IGP micro-loops Authors : Stephane Litkowski Bruno Decraene Martin Horneffer Filename: draft-ietf-rtgwg-spf-uloop-pb-statement-09.txt Pages : 15 Date: 2018-12-21 Abstract: A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm. In this document, we are trying to analyze the impact of using different Link State IGP (Interior Gateway Protocol) implementations in a single network, with respect to micro-loops. The analysis is focused on the SPF (Shortest Path First) delay algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-09 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-spf-uloop-pb-statement-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-spf-uloop-pb-statement-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
RE: RtgDir review: draft-ietf-rtgwg-spf-uloop-pb-statement-08.txt
Thanks for your valuable comment. I will add your fix as part of the next revision. -Original Message- From: Tomonori Takeda [mailto:takeda.tomon...@lab.ntt.co.jp] Sent: Monday, December 17, 2018 10:13 To: rtg-...@ietf.org Cc: rtg-...@ietf.org; draft-ietf-rtgwg-spf-uloop-pb-statement@ietf.org; rtgwg@ietf.org Subject: RtgDir review: draft-ietf-rtgwg-spf-uloop-pb-statement-08.txt Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-rtgwg-spf-uloop-pb-statement-08.txt Reviewer: Tomonori Takeda Review Date: Dec. 17th, 2018 IETF LC End Date: Dec. 18th, 2018 Intended Status: Informational Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: This document analyzes the impact of SPF delay algorithm and associated triggers on IGP micro-loops. This document presents useful information on how mixing strategies may lead to longer micro-loops. The document is well organized, easy to read. Major Issues: None Minor Issues: None Nits: 1) Section 2 says "That part may be the main part for the first iteration but is not for subsequent IGP events. In addition, this part is very implementation specific and difficult/impossible to standardize, while the SPF delay algorithm may be standardized." It would be better to explain what "That part" and "this part" mean. I guess the text should look like: "The time to update the FIB may be the main part for the first iteration of IGP event but is not for subsequent IGP events. In addition, the time to update the FIB is very implementation specific and difficult/impossible to standardize, while the SPF delay algorithm may be standardized." Thanks, Tomonori Takeda _ 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 rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
RE: Genart last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-08
Thanks. I will take care of your comments as part of the next revision. -Original Message- From: Dan Romascanu [mailto:droma...@gmail.com] Sent: Tuesday, December 11, 2018 15:29 To: gen-...@ietf.org Cc: draft-ietf-rtgwg-spf-uloop-pb-statement@ietf.org; i...@ietf.org; rtgwg@ietf.org; droma...@gmail.com Subject: Genart last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-08 Reviewer: Dan Romascanu Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-rtgwg-spf-uloop-pb-statement-08 Reviewer: Dan Romascanu Review Date: 2018-12-11 IETF LC End Date: 2018-12-18 IESG Telechat date: Not scheduled for a telechat Summary: Ready This document analyzes the impact of using non-standardized IGP Link State implementations resulting in non-consistent tuning of parameters in the network and increased possibility of creating micro-loops. It can be viewed as a problem statement for standardized solutions like RFC 8405. The document is short and clear for implementers and operators familiar with networks running this class of protocols. Diagrams and table help in reading and understanding the material. Major issues: none Minor issues: none Nits/editorial comments: 1. In the introduction: > For non standardized timers, implementations are free to implement it in any way. It is not obvious what 'it' means. I guess it's about different values of timers resulting in the possibility of micro-loops creation, but it would be better to clarify. 2. It would be useful to provide short explanations that make the figures more clear. In fig. 1 - what do the nodes represent (routers implementing the protocols), in fig. 2, and 3 - the abbreviations on the y axis _ 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 rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
RtgDir review: draft-ietf-rtgwg-spf-uloop-pb-statement-08.txt
Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-rtgwg-spf-uloop-pb-statement-08.txt Reviewer: Tomonori Takeda Review Date: Dec. 17th, 2018 IETF LC End Date: Dec. 18th, 2018 Intended Status: Informational Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: This document analyzes the impact of SPF delay algorithm and associated triggers on IGP micro-loops. This document presents useful information on how mixing strategies may lead to longer micro-loops. The document is well organized, easy to read. Major Issues: None Minor Issues: None Nits: 1) Section 2 says "That part may be the main part for the first iteration but is not for subsequent IGP events. In addition, this part is very implementation specific and difficult/impossible to standardize, while the SPF delay algorithm may be standardized." It would be better to explain what "That part" and "this part" mean. I guess the text should look like: "The time to update the FIB may be the main part for the first iteration of IGP event but is not for subsequent IGP events. In addition, the time to update the FIB is very implementation specific and difficult/impossible to standardize, while the SPF delay algorithm may be standardized." Thanks, Tomonori Takeda ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
Genart last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-08
Reviewer: Dan Romascanu Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-rtgwg-spf-uloop-pb-statement-08 Reviewer: Dan Romascanu Review Date: 2018-12-11 IETF LC End Date: 2018-12-18 IESG Telechat date: Not scheduled for a telechat Summary: Ready This document analyzes the impact of using non-standardized IGP Link State implementations resulting in non-consistent tuning of parameters in the network and increased possibility of creating micro-loops. It can be viewed as a problem statement for standardized solutions like RFC 8405. The document is short and clear for implementers and operators familiar with networks running this class of protocols. Diagrams and table help in reading and understanding the material. Major issues: none Minor issues: none Nits/editorial comments: 1. In the introduction: > For non standardized timers, implementations are free to implement it in any way. It is not obvious what 'it' means. I guess it's about different values of timers resulting in the possibility of micro-loops creation, but it would be better to clarify. 2. It would be useful to provide short explanations that make the figures more clear. In fig. 1 - what do the nodes represent (routers implementing the protocols), in fig. 2, and 3 - the abbreviations on the y axis ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
I-D Action: draft-ietf-rtgwg-spf-uloop-pb-statement-08.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group WG of the IETF. Title : Link State protocols SPF trigger and delay algorithm impact on IGP micro-loops Authors : Stephane Litkowski Bruno Decraene Martin Horneffer Filename: draft-ietf-rtgwg-spf-uloop-pb-statement-08.txt Pages : 14 Date: 2018-11-30 Abstract: A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm. In this document, we are trying to analyze the impact of using different Link State IGP (Interior Gateway Protocol) implementations in a single network, with respect to micro-loops. The analysis is focused on the SPF (Shortest Path First) delay algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-08 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-spf-uloop-pb-statement-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-spf-uloop-pb-statement-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
Publication has been requested for draft-ietf-rtgwg-spf-uloop-pb-statement-07
Chris Bowers has requested publication of draft-ietf-rtgwg-spf-uloop-pb-statement-07 as Informational on behalf of the RTGWG working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
Re: draft-ietf-rtgwg-spf-uloop-pb-statement
Thanks. The new revision addresses my comments. I have completed the shepherd write-up. It can be found at: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/shepherdwriteup/ There are a few editing items mentioned in the shepherd write-up (and copied below) to be addressed in the next revision, but I will go ahead and submit it to the IESG for publication. Thanks, Chris The following two warnings should be addresed in a future revision. == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == Outdated reference: draft-ietf-rtgwg-uloop-delay has been published as RFC 8333 All references have been identified as normative or informative. There are currently 4 normative references. Since this is an informational document, it might make sense to classify some or all of those references as in informative. On Wed, May 23, 2018 at 5:15 AM, wrote: > Hi Chris, > > > > I have uploaded a new revision. Let me know if it correctly addresses your > comments. > > > > Brgds, > > > > > > *From:* Chris Bowers [mailto:chrisbowers.i...@gmail.com] > *Sent:* Monday, April 16, 2018 22:02 > *To:* draft-ietf-rtgwg-spf-uloop-pb-statem...@ietf.org; RTGWG > *Subject:* draft-ietf-rtgwg-spf-uloop-pb-statement > > > > As part of doing the shepherd write-up for this document, I did a review > of the draft. > > > My comments are shown below as a diff on draft-ietf-rtgwg-spf-uloop-pb- > statement-06.txt. > > They can also be viewed at: > https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2018/commit/ > c1c5018f857e9c7c0f4123c3de1e87041178e387 > > Thanks, > Chris > > = > > diff --git a/draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt > b/draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt > index 353ce3c..3dff746 100644 > --- a/draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt > +++ b/draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt > @@ -21,7 +21,16 @@ Abstract > > In this document, we are trying to analyze the impact of using > different Link State IGP implementations in a single network in > - regards of micro-loops. The analysis is focused on the SPF triggers > + regards of micro-loops. > + > +=== > +[CB] > + In this document, we are trying to analyze the impact of using > + different Link State IGP implementations in a single network, with > + respect to micro-loops. > + > + > + The analysis is focused on the SPF triggers > and SPF delay algorithm. > > Requirements Language > @@ -95,13 +104,39 @@ Table of Contents > Link State IGP protocols are based on a topology database on which an > SPF (Shortest Path First) algorithm like Dijkstra is implemented to > find the optimal routing paths. > - > + > + = > + [CB] proposed modified text since the Shortest Path First algorithm and > + Djikstra algorithm are essentially synonomous. Also propose to use > + "consistent set of non-looping routing paths", since shortest path > routing > + is often not optimal from a traffic engineering perspective. > + > + [proposed text] > + Link State IGP protocols are based on a topology database on which the > + SPF (Shortest Path First) algorithm is run to > + find a consistent set of non-looping routing paths. > + > + = > + > Specifications like IS-IS ([RFC1195]) propose some optimizations of > the route computation (See Appendix C.1) but not all the > implementations are following those not mandatory optimizations. > > + > +[CB] [proposed text] > +but not all implementations follow those non-mandatory > +optimizations. > += > + > We will call "SPF trigger", the events that would lead to a new SPF > computation based on the topology. > + > + > +[CB] [proposed text] > + We will call "SPF triggers", the events that would lead to a new SPF > + computation based on the topology. > += > + > > Link State IGP protocols, like OSPF ([RFC2328]) and IS-IS > ([RFC1195]), are using multiple timers to control the router behavior > @@ -118,11 +153,27 @@ Internet-Draftspf-microloop > January 2018 > > Some of those timers are standardized in protocol specification, some > are not especially the SPF computation related timers. > + > + > +[CB] [proposed text] > + Some of those timers are standardized in protocol specification, while > some > + are not. The SPF computation related timers have generally remained > + unspecified. > += > > For non standardized timer
RE: draft-ietf-rtgwg-spf-uloop-pb-statement
Hi Chris, I have uploaded a new revision. Let me know if it correctly addresses your comments. Brgds, From: Chris Bowers [mailto:chrisbowers.i...@gmail.com] Sent: Monday, April 16, 2018 22:02 To: draft-ietf-rtgwg-spf-uloop-pb-statem...@ietf.org; RTGWG Subject: draft-ietf-rtgwg-spf-uloop-pb-statement As part of doing the shepherd write-up for this document, I did a review of the draft. My comments are shown below as a diff on draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt. They can also be viewed at: https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2018/commit/c1c5018f857e9c7c0f4123c3de1e87041178e387 Thanks, Chris = diff --git a/draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt b/draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt index 353ce3c..3dff746 100644 --- a/draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt +++ b/draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt @@ -21,7 +21,16 @@ Abstract In this document, we are trying to analyze the impact of using different Link State IGP implementations in a single network in - regards of micro-loops. The analysis is focused on the SPF triggers + regards of micro-loops. + +=== +[CB] + In this document, we are trying to analyze the impact of using + different Link State IGP implementations in a single network, with + respect to micro-loops. + + + The analysis is focused on the SPF triggers and SPF delay algorithm. Requirements Language @@ -95,13 +104,39 @@ Table of Contents Link State IGP protocols are based on a topology database on which an SPF (Shortest Path First) algorithm like Dijkstra is implemented to find the optimal routing paths. - + + = + [CB] proposed modified text since the Shortest Path First algorithm and + Djikstra algorithm are essentially synonomous. Also propose to use + "consistent set of non-looping routing paths", since shortest path routing + is often not optimal from a traffic engineering perspective. + + [proposed text] + Link State IGP protocols are based on a topology database on which the + SPF (Shortest Path First) algorithm is run to + find a consistent set of non-looping routing paths. + + = + Specifications like IS-IS ([RFC1195]) propose some optimizations of the route computation (See Appendix C.1) but not all the implementations are following those not mandatory optimizations. + +[CB] [proposed text] +but not all implementations follow those non-mandatory +optimizations. += + We will call "SPF trigger", the events that would lead to a new SPF computation based on the topology. + + +[CB] [proposed text] + We will call "SPF triggers", the events that would lead to a new SPF + computation based on the topology. += + Link State IGP protocols, like OSPF ([RFC2328]) and IS-IS ([RFC1195]), are using multiple timers to control the router behavior @@ -118,11 +153,27 @@ Internet-Draftspf-microloop January 2018 Some of those timers are standardized in protocol specification, some are not especially the SPF computation related timers. + + +[CB] [proposed text] + Some of those timers are standardized in protocol specification, while some + are not. The SPF computation related timers have generally remained + unspecified. += For non standardized timers, implementations are free to implement it in any way. For some standardized timer, we can also see that rather than using static configurable values for such timer, implementations may offer dynamically adjusted timers to help controlling the churn. + + +[CB] In the dicussion above, it is unclear about what the meaning of "timer" is. +Is it the numerical value of a timer? Is it the trigger conditions and logic +for a timer to start or be reset? Is the the action taken when the timer expires? +Perhaps the text could clarified by referring to "timer behavior" and "timer values" + += + We will call "SPF delay", the timer that exists in most implementations that specifies the required delay before running SPF @@ -138,6 +189,17 @@ Internet-Draftspf-microloop January 2018 Some micro-loop mitigation techniques have been defined by IETF (e.g. [RFC6976], [I-D.ietf-rtgwg-uloop-delay]) but are not implemented due to complexity or are not providing a complete mitigation. + +== +[CB] +This paragraph needs to be clearer. +[proposed text] + Two micro-loop mitigation techniques have been defined by the IETF. + [RFC6976] has not been widely implemented, presumably due to the complexity + of the technique. [I-D.ietf-rtgwg-uloop-delay] has been implemented. + However, it does not prevent all micro-loops that can occur + for a given topology and failure scenario. +==
I-D Action: draft-ietf-rtgwg-spf-uloop-pb-statement-07.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group WG of the IETF. Title : Link State protocols SPF trigger and delay algorithm impact on IGP micro-loops Authors : Stephane Litkowski Bruno Decraene Martin Horneffer Filename: draft-ietf-rtgwg-spf-uloop-pb-statement-07.txt Pages : 14 Date: 2018-05-23 Abstract: A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm. In this document, we are trying to analyze the impact of using different Link State IGP implementations in a single network, with respect to micro-loops. The analysis is focused on the SPF delay algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-07 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-spf-uloop-pb-statement-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-spf-uloop-pb-statement-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
draft-ietf-rtgwg-spf-uloop-pb-statement
As part of doing the shepherd write-up for this document, I did a review of the draft. My comments are shown below as a diff on draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt. They can also be viewed at: https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2018/commit/c1c5018f857e9c7c0f4123c3de1e87041178e387 Thanks, Chris = diff --git a/draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt b/draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt index 353ce3c..3dff746 100644 --- a/draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt +++ b/draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt @@ -21,7 +21,16 @@ Abstract In this document, we are trying to analyze the impact of using different Link State IGP implementations in a single network in - regards of micro-loops. The analysis is focused on the SPF triggers + regards of micro-loops. + +=== +[CB] + In this document, we are trying to analyze the impact of using + different Link State IGP implementations in a single network, with + respect to micro-loops. + + + The analysis is focused on the SPF triggers and SPF delay algorithm. Requirements Language @@ -95,13 +104,39 @@ Table of Contents Link State IGP protocols are based on a topology database on which an SPF (Shortest Path First) algorithm like Dijkstra is implemented to find the optimal routing paths. - + + = + [CB] proposed modified text since the Shortest Path First algorithm and + Djikstra algorithm are essentially synonomous. Also propose to use + "consistent set of non-looping routing paths", since shortest path routing + is often not optimal from a traffic engineering perspective. + + [proposed text] + Link State IGP protocols are based on a topology database on which the + SPF (Shortest Path First) algorithm is run to + find a consistent set of non-looping routing paths. + + = + Specifications like IS-IS ([RFC1195]) propose some optimizations of the route computation (See Appendix C.1) but not all the implementations are following those not mandatory optimizations. + +[CB] [proposed text] +but not all implementations follow those non-mandatory +optimizations. += + We will call "SPF trigger", the events that would lead to a new SPF computation based on the topology. + + +[CB] [proposed text] + We will call "SPF triggers", the events that would lead to a new SPF + computation based on the topology. += + Link State IGP protocols, like OSPF ([RFC2328]) and IS-IS ([RFC1195]), are using multiple timers to control the router behavior @@ -118,11 +153,27 @@ Internet-Draftspf-microloop January 2018 Some of those timers are standardized in protocol specification, some are not especially the SPF computation related timers. + + +[CB] [proposed text] + Some of those timers are standardized in protocol specification, while some + are not. The SPF computation related timers have generally remained + unspecified. += For non standardized timers, implementations are free to implement it in any way. For some standardized timer, we can also see that rather than using static configurable values for such timer, implementations may offer dynamically adjusted timers to help controlling the churn. + + +[CB] In the dicussion above, it is unclear about what the meaning of "timer" is. +Is it the numerical value of a timer? Is it the trigger conditions and logic +for a timer to start or be reset? Is the the action taken when the timer expires? +Perhaps the text could clarified by referring to "timer behavior" and "timer values" + += + We will call "SPF delay", the timer that exists in most implementations that specifies the required delay before running SPF @@ -138,6 +189,17 @@ Internet-Draftspf-microloop January 2018 Some micro-loop mitigation techniques have been defined by IETF (e.g. [RFC6976], [I-D.ietf-rtgwg-uloop-delay]) but are not implemented due to complexity or are not providing a complete mitigation. + +== +[CB] +This paragraph needs to be clearer. +[proposed text] + Two micro-loop mitigation techniques have been defined by the IETF. + [RFC6976] has not been widely implemented, presumably due to the complexity + of the technique. [I-D.ietf-rtgwg-uloop-delay] has been implemented. + However, it does not prevent all micro-loops that can occur + for a given topology and failure scenario. +== In multi-vendor networks, using different implementations of a link state protocol may favor micro-loops creation during the convergence @@ -185,17 +247,24 @@ Internet-Draftspf-microloop January 2018 will forward the traffic to C through B, but as B as not converged yet, B will loop back
RE: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement
Hi Uma, I have just posted the new rev that includes your change. Brgds, -Original Message- From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Uma Chunduri Sent: Thursday, January 18, 2018 02:32 To: Chris Bowers Cc: rtgwg-chairs; RTGWG Subject: RE: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement Hi Chris and Co-authors, Something to this spirit before the last bullet point in Section 2. o SPF computation order: A SPF trigger can be common to multiple IGP areas or levels (e.g., IS-IS Level1/Level2) or for multiple address families with multi-topologies. There is no specified order for SPF computation today and it is implementation dependent. In such scenarios, if the order of SPF computation done in A and B for each area/level/topology/SPF-algorithm is different, there is a possibility for a micro-loop to appear. BR, -- Uma C. -Original Message- From: Chris Bowers [mailto:chrisbowers.i...@gmail.com] Sent: Tuesday, January 16, 2018 1:49 PM To: Uma Chunduri Cc: RTGWG ; rtgwg-chairs Subject: Re: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement Uma, Could you propose some specific text to add to the document to address your comment? Thanks, Chris On Wed, Dec 6, 2017 at 1:54 PM, Uma Chunduri wrote: > Support and have a following comment and want to see this addressed. > > > > Section 2: > > > > I saw SPF computation time has been discussed, while it is true this > is relatively a smaller issue when compared to mismatch in SPF delay > with different trigger algos across various vendors; it depends on the > size of the network + mix of legacy and new nodes. > > Any ways, my comment: > > I would like to see add one more bullet point with regard to SPF > computation order impact on the micro loops for a trigger i.e., a > trigger which is common to multiple levels/areas, multiple topologies > and multiple SPF-algorithms (in extreme case). > > There is no specified order today and its implementation dependent > and IMO this too would be a significant contributor (of course, not > asking to specify the order here) and visible once the SPF > delay/trigger-algo issue is fixed across. So this is worth being listed here. > > > > > > -- > > Uma C. > > > > From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Chris Bowers > Sent: Wednesday, December 06, 2017 11:19 AM > To: RTGWG > Cc: rtgwg-chairs > Subject: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement > > > > RTGWG, > > This email starts the two week WG last call for > draft-ietf-rtgwg-spf-uloop-pb-statement. > > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-stateme > nt/ > > > Please indicate support for or opposition to the publication of this > > informational document, along with the reasoning behind that support > or > > opposition. > > > > IPR: > > If you are listed as a document author or contributor, please respond > to > > this email stating whether or not you are aware of any relevant IPR. > The > > response needs to be sent to the RTGWG mailing list. The document will > > not advance to the next stage until a response has been received from > > each author and each individual that has contributed to the document. > > > > This last call will end on Thursday, December 21st. > > > > Thanks, > > Chris and Jeff ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg _ 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 rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
I-D Action: draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group WG of the IETF. Title : Link State protocols SPF trigger and delay algorithm impact on IGP micro-loops Authors : Stephane Litkowski Bruno Decraene Martin Horneffer Filename: draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt Pages : 14 Date: 2018-01-24 Abstract: A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm. In this document, we are trying to analyze the impact of using different Link State IGP implementations in a single network in regards of micro-loops. The analysis is focused on the SPF triggers and SPF delay algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-06 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-spf-uloop-pb-statement-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-spf-uloop-pb-statement-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
RE: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement
Looks reasonable. Thanks for the proposal, I will take care of the doc update. -Original Message- From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Uma Chunduri Sent: Thursday, January 18, 2018 02:32 To: Chris Bowers Cc: rtgwg-chairs; RTGWG Subject: RE: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement Hi Chris and Co-authors, Something to this spirit before the last bullet point in Section 2. o SPF computation order: A SPF trigger can be common to multiple IGP areas or levels (e.g., IS-IS Level1/Level2) or for multiple address families with multi-topologies. There is no specified order for SPF computation today and it is implementation dependent. In such scenarios, if the order of SPF computation done in A and B for each area/level/topology/SPF-algorithm is different, there is a possibility for a micro-loop to appear. BR, -- Uma C. -Original Message- From: Chris Bowers [mailto:chrisbowers.i...@gmail.com] Sent: Tuesday, January 16, 2018 1:49 PM To: Uma Chunduri Cc: RTGWG ; rtgwg-chairs Subject: Re: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement Uma, Could you propose some specific text to add to the document to address your comment? Thanks, Chris On Wed, Dec 6, 2017 at 1:54 PM, Uma Chunduri wrote: > Support and have a following comment and want to see this addressed. > > > > Section 2: > > > > I saw SPF computation time has been discussed, while it is true this > is relatively a smaller issue when compared to mismatch in SPF delay > with different trigger algos across various vendors; it depends on the > size of the network + mix of legacy and new nodes. > > Any ways, my comment: > > I would like to see add one more bullet point with regard to SPF > computation order impact on the micro loops for a trigger i.e., a > trigger which is common to multiple levels/areas, multiple topologies > and multiple SPF-algorithms (in extreme case). > > There is no specified order today and its implementation dependent > and IMO this too would be a significant contributor (of course, not > asking to specify the order here) and visible once the SPF > delay/trigger-algo issue is fixed across. So this is worth being listed here. > > > > > > -- > > Uma C. > > > > From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Chris Bowers > Sent: Wednesday, December 06, 2017 11:19 AM > To: RTGWG > Cc: rtgwg-chairs > Subject: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement > > > > RTGWG, > > This email starts the two week WG last call for > draft-ietf-rtgwg-spf-uloop-pb-statement. > > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-stateme > nt/ > > > Please indicate support for or opposition to the publication of this > > informational document, along with the reasoning behind that support > or > > opposition. > > > > IPR: > > If you are listed as a document author or contributor, please respond > to > > this email stating whether or not you are aware of any relevant IPR. > The > > response needs to be sent to the RTGWG mailing list. The document will > > not advance to the next stage until a response has been received from > > each author and each individual that has contributed to the document. > > > > This last call will end on Thursday, December 21st. > > > > Thanks, > > Chris and Jeff ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg _ 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 rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
RE: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement
Hi Chris and Co-authors, Something to this spirit before the last bullet point in Section 2. o SPF computation order: A SPF trigger can be common to multiple IGP areas or levels (e.g., IS-IS Level1/Level2) or for multiple address families with multi-topologies. There is no specified order for SPF computation today and it is implementation dependent. In such scenarios, if the order of SPF computation done in A and B for each area/level/topology/SPF-algorithm is different, there is a possibility for a micro-loop to appear. BR, -- Uma C. -Original Message- From: Chris Bowers [mailto:chrisbowers.i...@gmail.com] Sent: Tuesday, January 16, 2018 1:49 PM To: Uma Chunduri Cc: RTGWG ; rtgwg-chairs Subject: Re: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement Uma, Could you propose some specific text to add to the document to address your comment? Thanks, Chris On Wed, Dec 6, 2017 at 1:54 PM, Uma Chunduri wrote: > Support and have a following comment and want to see this addressed. > > > > Section 2: > > > > I saw SPF computation time has been discussed, while it is true this > is relatively a smaller issue when compared to mismatch in SPF delay > with different trigger algos across various vendors; it depends on the > size of the network + mix of legacy and new nodes. > > Any ways, my comment: > > I would like to see add one more bullet point with regard to SPF > computation order impact on the micro loops for a trigger i.e., a > trigger which is common to multiple levels/areas, multiple topologies > and multiple SPF-algorithms (in extreme case). > > There is no specified order today and its implementation dependent > and IMO this too would be a significant contributor (of course, not > asking to specify the order here) and visible once the SPF > delay/trigger-algo issue is fixed across. So this is worth being listed here. > > > > > > -- > > Uma C. > > > > From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Chris Bowers > Sent: Wednesday, December 06, 2017 11:19 AM > To: RTGWG > Cc: rtgwg-chairs > Subject: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement > > > > RTGWG, > > This email starts the two week WG last call for > draft-ietf-rtgwg-spf-uloop-pb-statement. > > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-stateme > nt/ > > > Please indicate support for or opposition to the publication of this > > informational document, along with the reasoning behind that support > or > > opposition. > > > > IPR: > > If you are listed as a document author or contributor, please respond > to > > this email stating whether or not you are aware of any relevant IPR. > The > > response needs to be sent to the RTGWG mailing list. The document will > > not advance to the next stage until a response has been received from > > each author and each individual that has contributed to the document. > > > > This last call will end on Thursday, December 21st. > > > > Thanks, > > Chris and Jeff ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
Re: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement
Uma, Could you propose some specific text to add to the document to address your comment? Thanks, Chris On Wed, Dec 6, 2017 at 1:54 PM, Uma Chunduri wrote: > Support and have a following comment and want to see this addressed. > > > > Section 2: > > > > I saw SPF computation time has been discussed, while it is true this is > relatively a smaller issue when compared to mismatch in SPF delay with > different trigger algos across various vendors; it depends on the size of > the network + mix of legacy and new nodes. > > Any ways, my comment: > > I would like to see add one more bullet point with regard to SPF > computation order impact on the micro loops for a trigger i.e., a trigger > which is common to multiple levels/areas, multiple topologies and multiple > SPF-algorithms (in extreme case). > > There is no specified order today and its implementation dependent and IMO > this too would be a significant contributor (of course, not asking to > specify the order here) and visible once the SPF delay/trigger-algo issue is > fixed across. So this is worth being listed here. > > > > > > -- > > Uma C. > > > > From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Chris Bowers > Sent: Wednesday, December 06, 2017 11:19 AM > To: RTGWG > Cc: rtgwg-chairs > Subject: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement > > > > RTGWG, > > This email starts the two week WG last call for > draft-ietf-rtgwg-spf-uloop-pb-statement. > > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ > > > Please indicate support for or opposition to the publication of this > > informational document, along with the reasoning behind that support or > > opposition. > > > > IPR: > > If you are listed as a document author or contributor, please respond to > > this email stating whether or not you are aware of any relevant IPR. The > > response needs to be sent to the RTGWG mailing list. The document will > > not advance to the next stage until a response has been received from > > each author and each individual that has contributed to the document. > > > > This last call will end on Thursday, December 21st. > > > > Thanks, > > Chris and Jeff ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
Re: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement
RTGWG, Jeff and I think there is WG consensus to submit this document to the IESG for publication. The RTGWG IPR response requirements have also been met. Thanks, Chris and Jeff On Wed, Dec 6, 2017 at 1:18 PM, Chris Bowers wrote: > RTGWG, > > This email starts the two week WG last call for > draft-ietf-rtgwg-spf-uloop-pb-statement. > > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ > > > Please indicate support for or opposition to the publication of this > > informational document, along with the reasoning behind that support or > > opposition. > > > > IPR: > > If you are listed as a document author or contributor, please respond to > > this email stating whether or not you are aware of any relevant IPR. The > > response needs to be sent to the RTGWG mailing list. The document will > > not advance to the next stage until a response has been received from > > each author and each individual that has contributed to the document. > > > This last call will end on Thursday, December 21st. > > > Thanks, > > Chris and Jeff ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
Re: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement
Hello Chris, and group, I am not aware of any IPR related to this document. And, of course, I support publication of this document. Best regards, Martin Am 06.12.17 um 20:18 schrieb Chris Bowers: RTGWG, This email starts the two week WG last call fordraft-ietf-rtgwg-spf-uloop-pb-statement. https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/> <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/> <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/> Please indicate support for or opposition to the publication of this informational document, along with the reasoning behind that support or opposition. IPR: If you are listed as a document author or contributor, please respond to this email stating whether or not you are aware of any relevant IPR. The response needs to be sent to the RTGWG mailing list. The document will not advance to the next stage until a response has been received from each author and each individual that has contributed to the document. This last call will end on Thursday, December 21st. Thanks, Chris and Jeff ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
RE: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement
Hi Chris, I’m not aware of any IPR. Brgds, --Bruno From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Chris Bowers Sent: Wednesday, December 06, 2017 8:19 PM To: RTGWG Cc: rtgwg-chairs Subject: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement RTGWG, This email starts the two week WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement. https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/> Please indicate support for or opposition to the publication of this informational document, along with the reasoning behind that support or opposition. IPR: If you are listed as a document author or contributor, please respond to this email stating whether or not you are aware of any relevant IPR. The response needs to be sent to the RTGWG mailing list. The document will not advance to the next stage until a response has been received from each author and each individual that has contributed to the document. This last call will end on Thursday, December 21st. Thanks, Chris and Jeff _ 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 rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
RE: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement
Hi Chris, I’m not aware of any IPR. Brgds, From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Chris Bowers Sent: Wednesday, December 06, 2017 20:19 To: RTGWG Cc: rtgwg-chairs Subject: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement RTGWG, This email starts the two week WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement. https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/> Please indicate support for or opposition to the publication of this informational document, along with the reasoning behind that support or opposition. IPR: If you are listed as a document author or contributor, please respond to this email stating whether or not you are aware of any relevant IPR. The response needs to be sent to the RTGWG mailing list. The document will not advance to the next stage until a response has been received from each author and each individual that has contributed to the document. This last call will end on Thursday, December 21st. Thanks, Chris and Jeff _ 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 rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
Re: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement
I support publication. Thanks, Acee From: rtgwg mailto:rtgwg-boun...@ietf.org>> on behalf of Chris Bowers mailto:chrisbowers.i...@gmail.com>> Date: Wednesday, December 6, 2017 at 2:18 PM To: Routing WG mailto:rtgwg@ietf.org>> Cc: rtgwg-chairs mailto:rtgwg-cha...@ietf.org>> Subject: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement RTGWG, This email starts the two week WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement. https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/> <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/> Please indicate support for or opposition to the publication of this informational document, along with the reasoning behind that support or opposition. IPR: If you are listed as a document author or contributor, please respond to this email stating whether or not you are aware of any relevant IPR. The response needs to be sent to the RTGWG mailing list. The document will not advance to the next stage until a response has been received from each author and each individual that has contributed to the document. This last call will end on Thursday, December 21st. Thanks, Chris and Jeff ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
RE: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement
Support and have a following comment and want to see this addressed. Section 2: I saw SPF computation time has been discussed, while it is true this is relatively a smaller issue when compared to mismatch in SPF delay with different trigger algos across various vendors; it depends on the size of the network + mix of legacy and new nodes. Any ways, my comment: I would like to see add one more bullet point with regard to SPF computation order impact on the micro loops for a trigger i.e., a trigger which is common to multiple levels/areas, multiple topologies and multiple SPF-algorithms (in extreme case). There is no specified order today and its implementation dependent and IMO this too would be a significant contributor (of course, not asking to specify the order here) and visible once the SPF delay/trigger-algo issue is fixed across. So this is worth being listed here. -- Uma C. From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Chris Bowers Sent: Wednesday, December 06, 2017 11:19 AM To: RTGWG Cc: rtgwg-chairs Subject: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement RTGWG, This email starts the two week WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement. https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/> Please indicate support for or opposition to the publication of this informational document, along with the reasoning behind that support or opposition. IPR: If you are listed as a document author or contributor, please respond to this email stating whether or not you are aware of any relevant IPR. The response needs to be sent to the RTGWG mailing list. The document will not advance to the next stage until a response has been received from each author and each individual that has contributed to the document. This last call will end on Thursday, December 21st. Thanks, Chris and Jeff ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement
RTGWG, This email starts the two week WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement. https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/> <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/> Please indicate support for or opposition to the publication of this informational document, along with the reasoning behind that support or opposition. IPR: If you are listed as a document author or contributor, please respond to this email stating whether or not you are aware of any relevant IPR. The response needs to be sent to the RTGWG mailing list. The document will not advance to the next stage until a response has been received from each author and each individual that has contributed to the document. This last call will end on Thursday, December 21st. Thanks, Chris and Jeff ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
I-D Action: draft-ietf-rtgwg-spf-uloop-pb-statement-05.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group WG of the IETF. Title : Link State protocols SPF trigger and delay algorithm impact on IGP micro-loops Authors : Stephane Litkowski Bruno Decraene Martin Horneffer Filename: draft-ietf-rtgwg-spf-uloop-pb-statement-05.txt Pages : 14 Date: 2017-12-06 Abstract: A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm. In this document, we are trying to analyze the impact of using different Link State IGP implementations in a single network in regards of micro-loops. The analysis is focused on the SPF triggers and SPF delay algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-05 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-spf-uloop-pb-statement-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-spf-uloop-pb-statement-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
I-D Action: draft-ietf-rtgwg-spf-uloop-pb-statement-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : Link State protocols SPF trigger and delay algorithm impact on IGP micro-loops Authors : Stephane Litkowski Bruno Decraene Martin Horneffer Filename: draft-ietf-rtgwg-spf-uloop-pb-statement-04.txt Pages : 14 Date: 2017-05-23 Abstract: A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm. In this document, we are trying to analyze the impact of using different Link State IGP implementations in a single network in regards of micro-loops. The analysis is focused on the SPF triggers and SPF delay algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-04 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-spf-uloop-pb-statement-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-spf-uloop-pb-statement-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
RE: RTG-DIR QA review: draft-ietf-rtgwg-spf-uloop-pb-statement-03.txt
# Resend since it seems my previous email was not delivered correctly... Hi, I have been selected as the Routing Directorate QA reviewer for this draft. Document: draft-ietf-rtgwg-spf-uloop-pb-statement-03.txt Reviewer: Tomonori Takeda Review Date: April 29, 2017 Intended Status: Standards Track Here are my comments. Overall, the document is well organized and clear about problem statement and analysis of SPF triggers and SPF delays impact on micro-loops. Some specific comments. 1) The document is intended to be Standards Track. I do not think it is common for such analysis document to be Standards Track. 2) Just a nits, but in page 12, it says "In the figure 5", but it seems figures are not numbered. 3) In Section 4.2. Exponential backoff, it is not clear what is a condition (or conditions) to move from FM to BM. Thanks, Tomonori Takeda ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
RTG-DIR QA review: draft-ietf-rtgwg-spf-uloop-pb-statement-03.txt
Hi, I have been selected as the Routing Directorate QA reviewer for this draft. Document: draft-ietf-rtgwg-spf-uloop-pb-statement-03.txt Reviewer: Tomonori Takeda Review Date: April 29, 2017 Intended Status: Standards Track Here are my comments. Overall, the document is well organized and clear about problem statement and analysis of SPF triggers and SPF delays impact on micro-loops. Some specific comments. 1) The document is intended to be Standards Track. I do not think it is common for such analysis document to be Standards Track. 2) Just a nits, but in page 12, it says "In the figure 5", but it seems figures are not numbered. 3) In Section 4.2. Exponential backoff, it is not clear what is a condition (or conditions) to move from FM to BM. Thanks, Tomonori Takeda ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
RE: draft-ietf-rtgwg-spf-uloop-pb-statement
Bruno - We have no disagreement regarding the content of draft-ietf-rtgwg-backoff-algo - what I am concerned about is the intent of the draft. I see two possibilities. 1)This is an Informational draft which provides a discussion of what is needed to achieve both fast convergence and stability - and defines an example set of configuration parameters and the method to use them in order to achieve the goal. This is non-normative and allows that other means of achieving the same result are both possible and allowed. If that were the case I would have no further concerns. 2)This is a Standards track draft whose intent is to - over time - require all implementations to use the exact mechanisms defined in the draft. As the draft is positioned as a Standards track document I assume your intent is the latter. In which case we have to consider the existence of multiple long-lived implementations which are using a different set of parameters/implementation (e.g. exponential backoff) to achieve the fast convergence behavior described in the paper you reference below. These implementations have been proven successful. Before we require them to be changed I think it is prudent to demonstrate empirically - not merely by analysis - that a deployment where some implementations use the mechanisms defined in the draft and some use a proven alternative will result in significantly degraded convergence in real world failure scenarios. If we do not do this then we are imposing requirements on vendors and customers alike which are not proven to yield improvement. I therefore have suggested testing involving: o Timers in the range recommended by the draft - but also consistent with fast convergence (INITIAL delay sub 50 ms, SHORT_DELAY on the order of 100 ms or less) o Scenarios with multiple topology changes which trigger multiple SPFs in a short period of time o A mixture of routers with varying forwarding plane update speeds on the affected nodes in the network o Comparison of results using all standardized algorithm and a mixture of vendor specific algorithms and standard algorithm This is not an argument against the content of the draft - just a request to do due diligence. Does anyone have such data? Les > -Original Message- > From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of > bruno.decra...@orange.com > Sent: Tuesday, April 18, 2017 9:41 AM > To: Les Ginsberg (ginsberg) > Cc: RTGWG > Subject: RE: draft-ietf-rtgwg-spf-uloop-pb-statement > > Les, > > > From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] > Sent: > Tuesday, April 18, 2017 5:56 PM > > > > Bruno - > > > > The discussion here is a pragmatic one. > > That would be good indeed. > > > > As draft-ietf-rtgwg-backoff-algo is a Standards track document the > implication of it becoming > > an RFC is that everyone SHOULD/MUST implement it. > > No. > I'm not aware that everyone SHOULD/MUST implement all IETF standard > track RFC. > > > > Given that today vendors have implemented their own variations of SPF > backoff, in order to > > justify requiring the use of a standardized algorithm it MUST be > demonstrated that it makes > > a significant difference when used in real world deployments with timer > values that are > > consistent with existing deployments. > > You are mixing implementation consideration with IETF considerations. > >From an IETF standpoint, in order to maximize the chance to have all (link > state) IGP node to compute their SPF at the same time and using the same > LSDB, we need nodes to have a consistent SPF delay algo. > >From an implementation standpoint, we this draft has 3 implementations. > > > I think we agree on the following: > > > > 1)For a single topology change only the initial delay comes into play, so > no > benefits are > > expected from having a standardized algorithm > > I agree for a single link failure. > I disagree for other single failure, e.g. node failures and SRLG failures > where > multiple link state messages are involved from multiple nodes. Depending on > differences in detection time, distance from the failure, flooding > implementations long the way, SPF delay timers (..) multiple SPF may be > involved for a single topological change. > > (by "topology change" I assume that you mean the real/physical topology of > the network, note the possibly N topological change that the IGP can see, > depending on the configured SPF delays) > > > > 2)For multiple topology changes in a short period of time (i.e. within > SHORT_SPF_DELAY as > > defined in the draft) the benefits of syncing the start of a second SPF in > the control plane > > may be dwarfed by the
RE: draft-ietf-rtgwg-spf-uloop-pb-statement
ave not answered so far: - Do we agree that having different SPF delay algo across one network, is not a feature but a bug? --Bruno > >Les > > > > -----Original Message- > > From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com] > > Sent: Tuesday, April 18, 2017 7:43 AM > > To: Les Ginsberg (ginsberg) > > Cc: RTGWG > > Subject: draft-ietf-rtgwg-spf-uloop-pb-statement > > > > Changing the subject of the thread. > > > > Hi Les, > > > > As a follow up on the discussion > > > > > From: Les Ginsberg (ginsberg) > Sent: Tuesday, April 18, 2017 2:56 AM > > > > > > In regards to the discussion regarding " draft-ietf-rtgwg-spf-uloop-pb- > > statement" I am > quoted as saying: > > > > > > " Les: most of the analysis that I am aware of - > the largest > > contributor is > > the control plane." > > > > > > In actuality what I said (or at least intended to say :-) ) was that > > the largest > > contributor is the > data plane (NOT the control plane). > > > > > > The point of the exchange between Bruno and myself was to emphaisze > > the point that > demonstrating the real world benefits of the standardized > > backoff algorithm should include > cases where forwarding plane update > > speeds are different on different nodes in the > topology. It is possible > > that > > better synchronization of the control plane execution times > (which is > > what > > use of a consistent backoff algorithm is likely to provide) may not mean > > much > > > in cases where forwarding plane update speeds are significantly different > > on different > nodes and/or when forwarding plane update speeds > > consume much more time than the > control plane SPF/RIB updates. The > > latter case is quite common. > > > > A few points/comments, > > > > - IMHO, your request seems more related to the problem statement draft. > > https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-03 If > > you could comment the draft in order to improve it, this would probably > > speed up the discussion. > > - You are right that the IGP fast convergence, following a single failure, > > is > > mostly due to the time needed to update the FIB on line cards. However, as > > the SPF back-off algo kicks in, this is changing, and differences in spf > > delay > > algo brings a significant delta. cf slide 6 of the slides presented in > > IETF 90 > > https://www.ietf.org/proceedings/90/slides/slides-90-rtgwg-2.pdf You may > > also review the whole presentation; not because you would learn anything, > > but may be to ease the identification of the parts where we may have a > > different opinion. (at this point, I'm not seeing real disagreement). > > - Do we agree that having different SPF delay algo across one network, is > > not > > a feature but a bug? IOW, there is value in standardizing one. > > > > Regards, > > --Bruno > > > > > > >Les > > > > > > > > > > -Original Message- > > > > From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Jeff Tantsura > > > > Sent: Thursday, April 13, 2017 4:09 PM > > To: RTGWG > > Cc: rtgwg- > > chairs > > Subject: RTGWG minutes IETF98 > > > > Hi, > > > > The > > minutes > > have been published at: > > > > https://datatracker.ietf.org/doc/minutes-98-rtgwg/ > > > > Please provide your comments. > > > > > > > > Thanks! > > > > Jeff & Chris > > > > > > > > > > > > > > > > ___ > > > > rtgwg mailing list > > > > rtgwg@ietf.org > > > > https://www.ietf.org/mailman/listinfo/rtgwg > > > > > > ___ > > > rtgwg mailing list > > > rtgwg@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtgwg > > > > __ > > __ > > _ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites > > ou copies sans
RE: draft-ietf-rtgwg-spf-uloop-pb-statement
Bruno - The discussion here is a pragmatic one. As draft-ietf-rtgwg-backoff-algo is a Standards track document the implication of it becoming an RFC is that everyone SHOULD/MUST implement it. Given that today vendors have implemented their own variations of SPF backoff, in order to justify requiring the use of a standardized algorithm it MUST be demonstrated that it makes a significant difference when used in real world deployments with timer values that are consistent with existing deployments. I think we agree on the following: 1)For a single topology change only the initial delay comes into play, so no benefits are expected from having a standardized algorithm 2)For multiple topology changes in a short period of time (i.e. within SHORT_SPF_DELAY as defined in the draft) the benefits of syncing the start of a second SPF in the control plane may be dwarfed by the time it takes to update the forwarding. In all the studies I am familiar with, the contribution of control plane work (routing update processing, SPF, RIB update) is under 30% of the total time required for convergence. The remainder is the time it takes to actually update the forwarding plane. So, what I am asking is that BEFORE the draft becomes an RFC that real world data be gathered demonstrating the benefits of the standardized algorithm in the cases where it might matter. I think the right set of test cases would include: o Timers in the range recommended by the draft - but also consistent with fast convergence (INITIAL delay sub 50 ms, SHORT_DELAY on the order of 100 ms or less) o Multiple topology changes which trigger multiple SPFs o A mixture of forwarding plane updates speeds in the affected nodes in the network o Comparison of results using all standardized algorithm and a mixture of vendor specific algorithms Based on these results we can then determine whether it is beneficial to progress the draft. Les > -Original Message- > From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com] > Sent: Tuesday, April 18, 2017 7:43 AM > To: Les Ginsberg (ginsberg) > Cc: RTGWG > Subject: draft-ietf-rtgwg-spf-uloop-pb-statement > > Changing the subject of the thread. > > Hi Les, > > As a follow up on the discussion > > > From: Les Ginsberg (ginsberg) > Sent: Tuesday, April 18, 2017 2:56 AM > > > > In regards to the discussion regarding " draft-ietf-rtgwg-spf-uloop-pb- > statement" I am > quoted as saying: > > > > " Les: most of the analysis that I am aware of - > the largest > contributor is > the control plane." > > > > In actuality what I said (or at least intended to say :-) ) was that the > largest > contributor is the > data plane (NOT the control plane). > > > > The point of the exchange between Bruno and myself was to emphaisze > the point that > demonstrating the real world benefits of the standardized > backoff algorithm should include > cases where forwarding plane update > speeds are different on different nodes in the > topology. It is possible > that > better synchronization of the control plane execution times > (which is what > use of a consistent backoff algorithm is likely to provide) may not mean much > > in cases where forwarding plane update speeds are significantly different > on different > nodes and/or when forwarding plane update speeds > consume much more time than the > control plane SPF/RIB updates. The > latter case is quite common. > > A few points/comments, > > - IMHO, your request seems more related to the problem statement draft. > https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-03 If > you could comment the draft in order to improve it, this would probably > speed up the discussion. > - You are right that the IGP fast convergence, following a single failure, is > mostly due to the time needed to update the FIB on line cards. However, as > the SPF back-off algo kicks in, this is changing, and differences in spf delay > algo brings a significant delta. cf slide 6 of the slides presented in IETF 90 > https://www.ietf.org/proceedings/90/slides/slides-90-rtgwg-2.pdf You may > also review the whole presentation; not because you would learn anything, > but may be to ease the identification of the parts where we may have a > different opinion. (at this point, I'm not seeing real disagreement). > - Do we agree that having different SPF delay algo across one network, is not > a feature but a bug? IOW, there is value in standardizing one. > > Regards, > --Bruno > > > >Les > > > > > > > -Original Message- > > > From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Jeff Tantsura > > > Sent:
draft-ietf-rtgwg-spf-uloop-pb-statement
Changing the subject of the thread. Hi Les, As a follow up on the discussion > From: Les Ginsberg (ginsberg) > Sent: Tuesday, April 18, 2017 2:56 AM > > In regards to the discussion regarding " > draft-ietf-rtgwg-spf-uloop-pb-statement" I am > quoted as saying: > > " Les: most of the analysis that I am aware of - > the largest contributor is the control plane." > > In actuality what I said (or at least intended to say :-) ) was that the > largest contributor is the > data plane (NOT the control plane). > > The point of the exchange between Bruno and myself was to emphaisze the > point that > demonstrating the real world benefits of the standardized backoff algorithm > should include > cases where forwarding plane update speeds are different on different nodes > in the > topology. It is possible that better synchronization of the control plane > execution times > (which is what use of a consistent backoff algorithm is likely to provide) > may not mean much > in cases where forwarding plane update speeds are significantly different on > different > nodes and/or when forwarding plane update speeds consume much more time than > the > control plane SPF/RIB updates. The latter case is quite common. A few points/comments, - IMHO, your request seems more related to the problem statement draft. https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-03 If you could comment the draft in order to improve it, this would probably speed up the discussion. - You are right that the IGP fast convergence, following a single failure, is mostly due to the time needed to update the FIB on line cards. However, as the SPF back-off algo kicks in, this is changing, and differences in spf delay algo brings a significant delta. cf slide 6 of the slides presented in IETF 90 https://www.ietf.org/proceedings/90/slides/slides-90-rtgwg-2.pdf You may also review the whole presentation; not because you would learn anything, but may be to ease the identification of the parts where we may have a different opinion. (at this point, I'm not seeing real disagreement). - Do we agree that having different SPF delay algo across one network, is not a feature but a bug? IOW, there is value in standardizing one. Regards, --Bruno >Les > > > > -Original Message- > > From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Jeff Tantsura > > Sent: Thursday, April 13, 2017 4:09 PM > > To: RTGWG > > Cc: rtgwg-chairs > > Subject: RTGWG minutes IETF98 > > > > Hi, > > > > The minutes have been published at: > > https://datatracker.ietf.org/doc/minutes-98-rtgwg/ > > Please provide your comments. > > > > Thanks! > > Jeff & Chris > > > > > > > > ___ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg > > ___ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg _ 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 rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
I-D Action: draft-ietf-rtgwg-spf-uloop-pb-statement-03.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : Link State protocols SPF trigger and delay algorithm impact on IGP micro-loops Authors : Stephane Litkowski Bruno Decraene Martin Horneffer Filename: draft-ietf-rtgwg-spf-uloop-pb-statement-03.txt Pages : 14 Date: 2017-03-27 Abstract: A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm. In this document, we are trying to analyze the impact of using different Link State IGP implementations in a single network in regards of micro-loops. The analysis is focused on the SPF triggers and SPF delay algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-03 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-spf-uloop-pb-statement-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-spf-uloop-pb-statement-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
I-D Action: draft-ietf-rtgwg-spf-uloop-pb-statement-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group Working Group of the IETF. Title : Link State protocols SPF trigger and delay algorithm impact on IGP micro-loops Authors : Stephane Litkowski Bruno Decraene Martin Horneffer Filename: draft-ietf-rtgwg-spf-uloop-pb-statement-02.txt Pages : 14 Date: 2015-12-14 Abstract: A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm. In this document, we are trying to analyze the impact of using different Link State IGP implementations in a single network in regards of micro-loops. The analysis is focused on the SPF triggers and SPF delay algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-spf-uloop-pb-statement-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
I-D Action: draft-ietf-rtgwg-spf-uloop-pb-statement-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group Working Group of the IETF. Title : Link State protocols SPF trigger and delay algorithm impact on IGP micro-loops Authors : Stephane Litkowski Bruno Decraene Martin Horneffer Filename: draft-ietf-rtgwg-spf-uloop-pb-statement-01.txt Pages : 14 Date: 2015-06-23 Abstract: A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm. In this document, we are trying to analyze the impact of using different Link State IGP implementations in a single network in regards of micro-loops. The analysis is focused on the SPF triggers and SPF delay algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-spf-uloop-pb-statement-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
I-D Action: draft-ietf-rtgwg-spf-uloop-pb-statement-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group Working Group of the IETF. Title : Link State protocols SPF trigger and delay algorithm impact on IGP microloops Author : Stephane Litkowski Filename: draft-ietf-rtgwg-spf-uloop-pb-statement-00.txt Pages : 13 Date: 2015-05-04 Abstract: A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm. In this document, we are trying to analyze the impact of using different Link State IGP implementations in a single network in regards of microloops. The analysis is focused on the SPF triggers and SPF delay algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-spf-uloop-pb-statement/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
