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)

2019-01-21 Thread The IESG
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

2019-01-16 Thread internet-drafts


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

2019-01-11 Thread Phillip Hallam-Baker
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

2019-01-10 Thread Alissa Cooper
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)

2019-01-09 Thread Warren Kumari
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)

2019-01-09 Thread Ben Campbell
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

2019-01-08 Thread stephane.litkowski
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

2019-01-07 Thread Stewart Bryant


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

2019-01-07 Thread Phillip Hallam-Baker
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

2018-12-25 Thread Tomonori Takeda

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

2018-12-21 Thread Dan Romascanu
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

2018-12-21 Thread stephane.litkowski
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

2018-12-21 Thread stephane.litkowski
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

2018-12-21 Thread internet-drafts


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

2018-12-18 Thread stephane.litkowski
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

2018-12-18 Thread stephane.litkowski
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

2018-12-17 Thread Tomonori Takeda

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

2018-12-11 Thread Dan Romascanu
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

2018-11-30 Thread internet-drafts


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

2018-05-28 Thread Chris Bowers
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

2018-05-28 Thread Chris Bowers
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

2018-05-23 Thread stephane.litkowski
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

2018-05-23 Thread internet-drafts

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

2018-04-16 Thread Chris Bowers
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

2018-01-24 Thread stephane.litkowski
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

2018-01-24 Thread internet-drafts

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

2018-01-18 Thread stephane.litkowski
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

2018-01-17 Thread Uma Chunduri
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

2018-01-16 Thread Chris Bowers
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

2018-01-16 Thread Chris Bowers
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

2018-01-11 Thread Martin Horneffer

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

2017-12-07 Thread bruno.decraene
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

2017-12-07 Thread stephane.litkowski
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

2017-12-06 Thread Acee Lindem (acee)
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

2017-12-06 Thread Uma Chunduri
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

2017-12-06 Thread Chris Bowers
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

2017-12-06 Thread internet-drafts

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

2017-05-23 Thread internet-drafts

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

2017-04-30 Thread Tomonori Takeda
# 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

2017-04-29 Thread Tomonori Takeda
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

2017-04-18 Thread Les Ginsberg (ginsberg)
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

2017-04-18 Thread bruno.decraene
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

2017-04-18 Thread Les Ginsberg (ginsberg)
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

2017-04-18 Thread bruno.decraene
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

2017-03-27 Thread internet-drafts

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

2015-12-14 Thread internet-drafts

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

2015-06-23 Thread internet-drafts

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

2015-05-04 Thread internet-drafts

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