RE: Comments on draft-bashandy-rtgwg-segment-routing-ti-lfa

[stephane.litkowski]

Hi Shraddha,

Thanks for your comments. The document is under RTGWG, then I'm adding rtgwg 
list.
Please find some replies inline


From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: Monday, July 22, 2019 22:50
To: draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org; SPRING WG List
Subject: Comments on draft-bashandy-rtgwg-segment-routing-ti-lfa

Dear Authors

I have the below comments on the draft.

1. Section 1.Introduction

   "This provides a major improvment compared to LFA
   ([RFC5286]) and remote LFA ([RFC7490]) which cannot be applicable in
   some topologies ([RFC6571])."

   Change to

   This provides a major improvement compared to LFA
   ([RFC5286]) and remote LFA ([RFC7490]) which cannot provide
   complete protection coverage in
   some topologies ([RFC6571]).

[SLI] Agree, will fix it


  2. I suggest to add a new section for building repair segments .
The text appears randomly and it is not very readable.
Suggest to re-arrange as below

  
---
  5. Building Repair lists
  The repair list consist of node segments and adjacency segments 
which represents the
  protection path from PLR to the destination.


   o The active adjacency segments MUST be popped and the repair-list MUST be 
inserted
 at the head of the list.
   o The active node segments MUST be popped and repair-list inserted as the 
last segment ofrepair list,
  If the repair list ends with an adjacency segment terminating on 
the tail-end of the
   active segment, and if the active segment has been signalled 
with penultimate hop popping.
   o The active node segment MUST be retained as the last segment in the 
repair-list if the
 active node segment has been signaled with ultimate hop popping.

   o  If the SRGB at the Q node is different from the SRGB at the PLR,
  then the active segment (before the insertion of the repair list)
  MUST be updated to fit the SRGB of the Q node.


  
---
  3. Protecting segments

  It is not clear what do the section 5.2.1 and 5.2.2 represent.
  Are these for link-protection cases? You don't have to look into next label 
for link-protection cases.
  The mid-point node failure section 5.3 addresses node as well adjacency SID 
cases so 5.2.1 and 5.2.2 need not talk about node protection.

[SLI] §5.2 represents a link protection case , I agree that we don't have to 
look at the next segment and the text does not require it. However the current 
structure could make think that we need.
I will propose a new text to address this.


  4.

  Modern routing architectures have separate control plane and data plane.
  section 5.3 language seem to suggest a lot of contol plane like processing in 
the forwarding plane.
The entire description has a MUST term which mandates implementing expensive
operation in forwarding plane.Suggest to add below text in section 5.3 and also 
change all MUST in 5.3.1 and 5.3.2
 to non-normative should.
I have copied the entire 5.3 section with suggested changes highlighted in bold

-
5.3
 Section 5.3.1 and 5.3.2 describe the processing for incoming Node and 
Adjacency SIDs
 when the next label in the packet is either a node/adj-sid.

The description below is intended to specify the forwarding behavior required 
for node protection.
The description should not be interpreted as limiting the possible 
implementations of this forwarding behavior.
An implementation complies with the description below as long as the externally 
visible forwarding behavior produced
by the implementation is the same as that described below.

[SLI] The goal is to provide an expected result and not how the implementation 
is done. Your text proposal looks reasonable and I will have a look on how to 
provide a better wording for the text below.

  5.3.1.  Protecting {F, T, D} or {S->F, T, D}

   This section describes the protection behavior of S when all of the
   following conditions are true:

   1.  the active segment is a prefix SID for a neighbor F, or an
   adjacency segment S->F

   2.  the primary interface used to forward the packet failed


   3.  the segment following the active segment is a prefix SID (for
   node T)

   4.  node protection is active for that interface.

   In such a case, the PLR should:Change to non-normative should

   1.  apply a NEXT operation; the segment F or S->F is removed

   2.  Confirm that the next segment is in the SRGB of F, meaning that
   the next segment is a prefix segment, e.g. for node T

   3.  Retrieve the segment ID of T (as per the SRGB of F)

   4.  Apply a NEXT operation followed by a PUSH operation of T's
   segment based on the SRGB of node S.

   5.  Look up T's segment (based on

RE: draft-ietf-rtgwg-segment-routing-ti-lfa Table 1 questions

[stephane.litkowski]

Hi Jeff,

We have additional updates to put in the draft.
We will publish it as soon as it is done.

Brgds,


From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Wednesday, July 24, 2019 13:52
To: Stewart Bryant; rtgwg@ietf.org; 
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org; Francois Clad (fclad)
Subject: Re: draft-ietf-rtgwg-segment-routing-ti-lfa Table 1 questions

Francois/co-authors,

Thanks for addressing the comments.
Please update and publish the updated draft.

Thanks!

Cheers,
Jeff
On Jul 24, 2019, 1:22 PM -0400, Francois Clad (fclad) , wrote:

Hi Stewart,

Thank you for pointing that out.

The term circuits in the third column refers to bi-directional links. For the 
sake of clarity, we propose to replace it with “links” and multiply all values 
in the third column by 2.

It also appears that a glitch occurred when the link/node ratios were reported 
in this table 1.

Below is the updated table.

+-+++++
| Network | Nodes | Links |Link-to-Node| SRLG info? |
| | | | Ratio | |
+-+++++
| T1 | 408 | 1330 | 3.26 | Yes |
+-+++++
| T2 | 587 | 2166 | 3.69 | No |
+-+++++
| T3 | 93 | 802 | 8.62 | Yes |
+-+++++
| T4 | 247 | 786 | 3.18 | Yes |
+-+++++
| T5 | 34 | 192 | 5.65 | Yes |
+-+++++
| T6 | 50 | 156 | 3.12 | No |
+-+++++
| T7 | 82 | 586 | 7.15 | No |
+-+++++
| T8 | 35 | 82 | 2.34 | Yes |
+-+++++
| T9 | 177 | 2742 | 15.49 | Yes |
+-+++++

Regards,
Francois

On 22/07/2019 12:00, "Stewart Bryant"  wrote:

I would like to understand what Table 1 in
draft-ietf-rtgwg-segment-routing-ti-lfa is telling us.

It uses the terms links and circuits without distinguishing between the
two. I could speculate that a circuit is a group of links, but then the
ratio of nodes to circuits in T1 seems far too low at less than 1:1 in
network T1.

Then the node to link ratio sounds quite high with fan outs of 84:1 in T2.

Please could you explain what you mean by circuits and links in this table.

What I would like to know is the average ratio of nodes to neighbours,
and the number of parallel links per neighbour.

Best regards

Stewart




___
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

FW: I-D Action: draft-ietf-rtgwg-segment-routing-ti-lfa-01.txt

[stephane.litkowski]

Hi,

Here is a new version of the TI-LFA draft, we tried to incorporate the comments 
that have been received.
Feel free to comment this new revision.

Brgds,


-Original Message-
From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Tuesday, March 05, 2019 09:30
To: i-d-annou...@ietf.org
Cc: rtgwg@ietf.org
Subject: I-D Action: draft-ietf-rtgwg-segment-routing-ti-lfa-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Area Working Group WG of the IETF.

Title   : Topology Independent Fast Reroute using Segment 
Routing
Authors : Stephane Litkowski
  Ahmed Bashandy
  Clarence Filsfils
  Bruno Decraene
  Pierre Francois
  Daniel Voyer
  Francois Clad
  Pablo Camarillo
Filename: draft-ietf-rtgwg-segment-routing-ti-lfa-01.txt
Pages   : 24
Date: 2019-03-05

Abstract:
   This document presents Topology Independent Loop-free Alternate Fast
   Re-route (TI-LFA), aimed at providing protection of node and
   adjacency segments within the Segment Routing (SR) framework.  This
   Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being
   LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding
   (DLFA).  It extends these concepts to provide guaranteed coverage in
   any IGP network.  A key aspect of TI-LFA is the FRR path selection
   approach establishing protection over the expected post-convergence
   paths from the point of local repair, dramatically reducing the
   operational need to control the tie-breaks among various FRR options.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-segment-routing-ti-lfa/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rtgwg-segment-routing-ti-lfa-01
https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-segment-routing-ti-lfa-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

_

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

[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: Genart last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-08

[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

.

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

[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

RE: RtgDir review: draft-ietf-rtgwg-spf-uloop-pb-statement-08.txt

[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

[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

.

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: Expired draft-ietf-rtgwg-ipfrr-ip-mib

[stephane.litkowski]

Hi Sasha,

Currently TILFA is part of the SR IGP Yang models and there is an augmentation 
of the existing fast-reroute container.

Consistency between YANG models is a valid concern ! for IS-IS and OSPF 
(including SR extensions) we are working very closely together to ensure 
consistency. However there is still a chance that we've missed something.


From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Thursday, November 29, 2018 13:42
To: LITKOWSKI Stephane OBS/OINIS
Cc: Michael Gorokhovsky; rtgwg@ietf.org; akat...@juniper.net; 
chrisbowers.i...@gmail.com; Jeff Tantsura
Subject: RE: Expired draft-ietf-rtgwg-ipfrr-ip-mib

Stephane,
Lots of thanks for a prompt response.

I think that a proposal to extract FRR-related things from the IGP YANG data 
models and to move them to a new document in a different WG would be rejected 
at this stage - and justly so.

On the other hand, I wonder what is supposed to happen with YANG for TI-LFA:

-  I would expect substantial overlap with YANG definitions for 
LFA-based FRR in IS-IS and OSPF

-  Since these  definitions are in two different documents handled by 
the LSR WG, and TI-LFA is handled by the RTGWG, this would probably mean yet 
another draft, with its own lifecycle etc.
Keeping all these documents consistent (at least in their overlapping parts) 
can be quite non-trivial IMHO.

One practical (and easy to implement) step should be removal of the milestone 
"Submit MIB for IP Fast-Reroute for publication as Proposed Standard" (with the 
target date two years behind us already) from the RTGWG 
charter. Chris/Jeff?

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: stephane.litkow...@orange.com 
Sent: Thursday, November 29, 2018 2:22 PM
To: Alexander Vainshtein 
Cc: Michael Gorokhovsky ; rtgwg@ietf.org; 
akat...@juniper.net; kkous...@cisco.com
Subject: RE: Expired draft-ietf-rtgwg-ipfrr-ip-mib

That's a possibility. However for now, we have taken the approach to add FRR 
into the IGP models.
You could propose your view to the LSR list. ISIS and OSPF yang are in 
Shepherd's review state.


From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Wednesday, November 28, 2018 13:42
To: LITKOWSKI Stephane OBS/OINIS
Cc: Michael Gorokhovsky; rtgwg@ietf.org; 
akat...@juniper.net; 
kkous...@cisco.com
Subject: RE: Expired draft-ietf-rtgwg-ipfrr-ip-mib

Stephane,
Lots of thanks for a prompt response.

I have guessed that the reason for dropping the MIB draft for IP FRR was 
transition to YANG data models.
And it seems that the current versions of the OSPF and IS-IS Yang data model 
drafts cover not just FRR-related counters but also FRR-related configuration 
and state attributes.

However, this looks as duplicated definitions (with some protocol-specific 
variations). Doesn't it make more sense to place all these definitions into a 
single document?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com

From: stephane.litkow...@orange.com 
mailto:stephane.litkow...@orange.com>>
Sent: Monday, November 26, 2018 12:20 PM
To: Alexander Vainshtein 
mailto:alexander..vainsht...@ecitele.com>>; 
akat...@juniper.net; 
kkous...@cisco.com
Cc: Michael Gorokhovsky 
mailto:michael.gorokhov...@ecitele.com>>; 
rtgwg@ietf.org
Subject: RE: Expired draft-ietf-rtgwg-ipfrr-ip-mib

Hi Sasha,

It was decided to stop the work on this document and focus on YANG. The IPFRR 
MIB counters are part of the OSPF and ISIS yang models.

Brgds,

From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Sunday, November 25, 2018 12:46
To: akat...@juniper.net; 
kkous...@cisco.com; LITKOWSKI Stephane OBS/OINIS
Cc: Michael Gorokhovsky; rtgwg@ietf.org
Subject: Expired draft-ietf-rtgwg-ipfrr-ip-mib

Dear colleagues,
I have noticed that  IP FRR MIB draft (that appears as one of the WG milestones 
with November-2015 as the target date) has expired more than 2 years ago.  At 
the same time I have not seen any YANG draft that could be considered as its 
replacement.

I wonder if there are any plans to resuscitate this draft or to replace it by a 
YANG one.

Your timely feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com


___

This e-mail message is intended for the recipient only and contains information 
wh

RE: Expired draft-ietf-rtgwg-ipfrr-ip-mib

[stephane.litkowski]

That's a possibility. However for now, we have taken the approach to add FRR 
into the IGP models.
You could propose your view to the LSR list. ISIS and OSPF yang are in 
Shepherd's review state.


From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Wednesday, November 28, 2018 13:42
To: LITKOWSKI Stephane OBS/OINIS
Cc: Michael Gorokhovsky; rtgwg@ietf.org; akat...@juniper.net; kkous...@cisco.com
Subject: RE: Expired draft-ietf-rtgwg-ipfrr-ip-mib

Stephane,
Lots of thanks for a prompt response.

I have guessed that the reason for dropping the MIB draft for IP FRR was 
transition to YANG data models.
And it seems that the current versions of the OSPF and IS-IS Yang data model 
drafts cover not just FRR-related counters but also FRR-related configuration 
and state attributes.

However, this looks as duplicated definitions (with some protocol-specific 
variations). Doesn't it make more sense to place all these definitions into a 
single document?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: stephane.litkow...@orange.com 
Sent: Monday, November 26, 2018 12:20 PM
To: Alexander Vainshtein ; 
akat...@juniper.net; kkous...@cisco.com
Cc: Michael Gorokhovsky ; rtgwg@ietf.org
Subject: RE: Expired draft-ietf-rtgwg-ipfrr-ip-mib

Hi Sasha,

It was decided to stop the work on this document and focus on YANG. The IPFRR 
MIB counters are part of the OSPF and ISIS yang models.

Brgds,

From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Sunday, November 25, 2018 12:46
To: akat...@juniper.net; 
kkous...@cisco.com; LITKOWSKI Stephane OBS/OINIS
Cc: Michael Gorokhovsky; rtgwg@ietf.org
Subject: Expired draft-ietf-rtgwg-ipfrr-ip-mib

Dear colleagues,
I have noticed that  IP FRR MIB draft (that appears as one of the WG milestones 
with November-2015 as the target date) has expired more than 2 years ago.  At 
the same time I have not seen any YANG draft that could be considered as its 
replacement.

I wonder if there are any plans to resuscitate this draft or to replace it by a 
YANG one.

Your timely feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com


___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___

_



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.

___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___

_

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 pr

RE: Expired draft-ietf-rtgwg-ipfrr-ip-mib

[stephane.litkowski]

Hi Sasha,

It was decided to stop the work on this document and focus on YANG. The IPFRR 
MIB counters are part of the OSPF and ISIS yang models.

Brgds,

From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Sunday, November 25, 2018 12:46
To: akat...@juniper.net; kkous...@cisco.com; LITKOWSKI Stephane OBS/OINIS
Cc: Michael Gorokhovsky; rtgwg@ietf.org
Subject: Expired draft-ietf-rtgwg-ipfrr-ip-mib

Dear colleagues,
I have noticed that  IP FRR MIB draft (that appears as one of the WG milestones 
with November-2015 as the target date) has expired more than 2 years ago.  At 
the same time I have not seen any YANG draft that could be considered as its 
replacement.

I wonder if there are any plans to resuscitate this draft or to replace it by a 
YANG one.

Your timely feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com


___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___

_

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 adoption poll for draft-bashandy-rtgwg-segment-routing-ti-lfa

[stephane.litkowski]

Support as co-author.
I'm not aware of any IPR except the one already disclosed.


From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Chris Bowers
Sent: Thursday, August 09, 2018 16:30
To: rtgwg@ietf.org
Subject: WG adoption poll for draft-bashandy-rtgwg-segment-routing-ti-lfa

RTGWG,

Jeff and I think it makes sense to adopt 
draft-bashandy-rtgwg-segment-routing-ti-lfa
as a working group document.

There has been a lot of useful discussion about this draft on the list..  
However, the text of the
draft has not been modified to reflect a good deal of valid feedback from 
reviewers.
We intend to address this issue if and when the draft becomes a working group 
document.

Please indicate your support or opposition to the adoption of this draft.

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.

At this point, the document has the following IPR disclosure associated with it.
https://datatracker.ietf.org/ipr/3068/

This adoption poll will end on August 24th.

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: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

[stephane.litkowski]

Agree

From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Monday, July 16, 2018 10:58
To: LITKOWSKI Stephane OBS/OINIS
Cc: Robert Raszuk; rtgwg-cha...@ietf.org; pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org; rtgwg@ietf.org; 
daniel.vo...@bell.ca; DECRAENE Bruno IMT/OLN
Subject: Re: Request for RTGWG Working Group adoption for 
draft-bashandy-rtgwg-segment-routing-ti-lfa

Stephane,
Lots of thanks for a promot response.
It wiuld be nice to see this in the draft.
Thumb typed by Sasha Vainshtein


From: stephane.litkow...@orange.com 
Sent: Monday, July 16, 2018 10:46:56 AM
To: Alexander Vainshtein
Cc: Robert Raszuk; rtgwg-cha...@ietf.org; pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org; rtgwg@ietf.org; 
daniel.vo...@bell.ca; DECRAENE Bruno IMT/OLN
Subject: RE: Request for RTGWG Working Group adoption for 
draft-bashandy-rtgwg-segment-routing-ti-lfa

Hi,

> would it be correct to assume that using the post-convergence path in TI-LFA 
> resolves some of operational issues with LFA selection that are mentioned in 
> Section 3 of RFC 7916 because these issues presumably have been taken by the 
> network operator as part of its original network engineering? E.g., using PE 
> routers to protect against core failures, or selecting links with low BW 
> while links with high BW are available?

Exactly !

Brgds,

Stephane

From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Sunday, July 15, 2018 10:01
To: LITKOWSKI Stephane OBS/OINIS
Cc: Robert Raszuk; rtgwg-cha...@ietf.org; pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org; rtgwg@ietf.org; 
daniel.vo...@bell.ca; DECRAENE Bruno IMT/OLN
Subject: RE: Request for RTGWG Working Group adoption for 
draft-bashandy-rtgwg-segment-routing-ti-lfa

Stephane,
Lots of thanks for a highly informative response.

Leaving aside the potential to use repair paths theoretically provided by SR 
but not available for IP FRR, would it be correct to assume that using the 
post-convergence path in TI-LFA resolves some of operational issues with LFA 
selection that are mentioned in Section 3 of RFC 7916 because these issues 
presumably have been taken by the network operator as part of its original 
network engineering? E.g., using PE routers to protect against core failures, 
or selecting links with low BW while links with high BW are available?

Such a claim looks reasonable to me - especially since, as you have written, 
"TILFA perfectly fits the criteria: lowest IGP metric"  that is one of the 
mandatory criteria in 7916.

I admit that I did not understand that from just reading TI-LFA draft, not in 
the least because RFC 7916 is neither mentioned nor referenced there.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Friday, July 13, 2018 3:54 PM
To: Alexander Vainshtein 
Cc: Robert Raszuk ; rtgwg-cha...@ietf.org; pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org; rtgwg@ietf.org; 
daniel.vo...@bell.ca; DECRAENE Bruno IMT/OLN 
Subject: RE: Request for RTGWG Working Group adoption for 
draft-bashandy-rtgwg-segment-routing-ti-lfa

RFC7916 was written at a time when TILFA did not exist. LFA and RLFA provide a 
set of candidate paths where we need to pick one or more to be installed.

With segment routing, we bring the ability to use any alternate path compared 
to LFA and RLFA which have a limited amount of candidate paths. As a 
consequence, we are not exactly in the same backup path selection logic as for 
LFA and RLFA. If we try to mimic RFC7916 logic with SR, we need to consider the 
list of candidate paths to be all alternate paths available through the network 
(so many many !) which may provide some scaling concern especially if we try to 
involve path attribute collection for the candidate paths. That's why the logic 
of TILFA is to focus on the postconvergence path.

To answer your question, IMO, TILFA perfectly fits the criteria: lowest IGP 
metric.

We could think (as a theoretical exercice) of TILFA using other criterias than 
the lowest IGP metric. Note that if we think of TILFA in the context of 
flexalgo, the backup path may require to fit the constraint defined by the 
flexalgo.



From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Thursday, July 12, 2018 15:16
To: LITKOWSKI Stephane OBS/OINIS
Cc: Robert Raszuk; rtgwg-cha...@ietf.org; 
pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org;
 rtgwg@ietf.org; 
daniel.vo...@bell.ca; DECRAENE Bruno IMT/OLN
Subject: RE: Request for RTGWG Working Group adoption for 
draft-bashandy-rtgwg-segment-routing-ti-lfa

Stephane,
Lot

RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

[stephane.litkowski]

Hi,

> would it be correct to assume that using the post-convergence path in TI-LFA 
> resolves some of operational issues with LFA selection that are mentioned in 
> Section 3 of RFC 7916 because these issues presumably have been taken by the 
> network operator as part of its original network engineering? E.g., using PE 
> routers to protect against core failures, or selecting links with low BW 
> while links with high BW are available?

Exactly !

Brgds,

Stephane

From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Sunday, July 15, 2018 10:01
To: LITKOWSKI Stephane OBS/OINIS
Cc: Robert Raszuk; rtgwg-cha...@ietf.org; pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org; rtgwg@ietf.org; 
daniel.vo...@bell.ca; DECRAENE Bruno IMT/OLN
Subject: RE: Request for RTGWG Working Group adoption for 
draft-bashandy-rtgwg-segment-routing-ti-lfa

Stephane,
Lots of thanks for a highly informative response.

Leaving aside the potential to use repair paths theoretically provided by SR 
but not available for IP FRR, would it be correct to assume that using the 
post-convergence path in TI-LFA resolves some of operational issues with LFA 
selection that are mentioned in Section 3 of RFC 7916 because these issues 
presumably have been taken by the network operator as part of its original 
network engineering? E.g., using PE routers to protect against core failures, 
or selecting links with low BW while links with high BW are available?

Such a claim looks reasonable to me – especially since, as you have written, 
“TILFA perfectly fits the criteria: lowest IGP metric”  that is one of the 
mandatory criteria in 7916.

I admit that I did not understand that from just reading TI-LFA draft, not in 
the least because RFC 7916 is neither mentioned nor referenced there.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Friday, July 13, 2018 3:54 PM
To: Alexander Vainshtein 
Cc: Robert Raszuk ; rtgwg-cha...@ietf.org; pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org; rtgwg@ietf.org; 
daniel.vo...@bell.ca; DECRAENE Bruno IMT/OLN 
Subject: RE: Request for RTGWG Working Group adoption for 
draft-bashandy-rtgwg-segment-routing-ti-lfa

RFC7916 was written at a time when TILFA did not exist. LFA and RLFA provide a 
set of candidate paths where we need to pick one or more to be installed.

With segment routing, we bring the ability to use any alternate path compared 
to LFA and RLFA which have a limited amount of candidate paths. As a 
consequence, we are not exactly in the same backup path selection logic as for 
LFA and RLFA. If we try to mimic RFC7916 logic with SR, we need to consider the 
list of candidate paths to be all alternate paths available through the network 
(so many many !) which may provide some scaling concern especially if we try to 
involve path attribute collection for the candidate paths. That’s why the logic 
of TILFA is to focus on the postconvergence path.

To answer your question, IMO, TILFA perfectly fits the criteria: lowest IGP 
metric.

We could think (as a theoretical exercice) of TILFA using other criterias than 
the lowest IGP metric. Note that if we think of TILFA in the context of 
flexalgo, the backup path may require to fit the constraint defined by the 
flexalgo.



From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Thursday, July 12, 2018 15:16
To: LITKOWSKI Stephane OBS/OINIS
Cc: Robert Raszuk; rtgwg-cha...@ietf.org; 
pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org;
 rtgwg@ietf.org; 
daniel.vo...@bell.ca; DECRAENE Bruno IMT/OLN
Subject: RE: Request for RTGWG Working Group adoption for 
draft-bashandy-rtgwg-segment-routing-ti-lfa

Stephane,
Lots of thanks for a prompt response.

We seem to agree on at least one of my objections and the need to remove the 
associated text from the draft.

Regarding the other one:

1.   Lots of thanks for pointing to RFC 7916 that describes problems with 
LFA/RLFA selection. BTW, this RFC is not referenced by the TI-LFA draft

2.   One of the mandatory criteria in RFC 7916 is lowest IGP metric used to 
reach the destination:

a.   Is this equivalent to giving precedence to post-convergence paths?

b.   This is just one of mandatory criteria in RFC 7916 with some 
recommended criteria as well. These criteria should be evaluated based on their 
preferences.

3.   One modification of the draft that I can think about could be:

a.   Provide a Normative reference to 7916. In particular, clarify that all 
mandatory criteria listed in this RFC MUST  be supported

b.   RECOMMEND giving highest preference to the criteria of lowest IGP 
met

RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

[stephane.litkowski]

RFC7916 was written at a time when TILFA did not exist. LFA and RLFA provide a 
set of candidate paths where we need to pick one or more to be installed.

With segment routing, we bring the ability to use any alternate path compared 
to LFA and RLFA which have a limited amount of candidate paths. As a 
consequence, we are not exactly in the same backup path selection logic as for 
LFA and RLFA. If we try to mimic RFC7916 logic with SR, we need to consider the 
list of candidate paths to be all alternate paths available through the network 
(so many many !) which may provide some scaling concern especially if we try to 
involve path attribute collection for the candidate paths. That’s why the logic 
of TILFA is to focus on the postconvergence path.

To answer your question, IMO, TILFA perfectly fits the criteria: lowest IGP 
metric.

We could think (as a theoretical exercice) of TILFA using other criterias than 
the lowest IGP metric. Note that if we think of TILFA in the context of 
flexalgo, the backup path may require to fit the constraint defined by the 
flexalgo.



From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Thursday, July 12, 2018 15:16
To: LITKOWSKI Stephane OBS/OINIS
Cc: Robert Raszuk; rtgwg-cha...@ietf.org; pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org; rtgwg@ietf.org; 
daniel.vo...@bell.ca; DECRAENE Bruno IMT/OLN
Subject: RE: Request for RTGWG Working Group adoption for 
draft-bashandy-rtgwg-segment-routing-ti-lfa

Stephane,
Lots of thanks for a prompt response.

We seem to agree on at least one of my objections and the need to remove the 
associated text from the draft.

Regarding the other one:

1.   Lots of thanks for pointing to RFC 7916 that describes problems with 
LFA/RLFA selection. BTW, this RFC is not referenced by the TI-LFA draft

2.   One of the mandatory criteria in RFC 7916 is lowest IGP metric used to 
reach the destination:

a.   Is this equivalent to giving precedence to post-convergence paths?

b.   This is just one of mandatory criteria in RFC 7916 with some 
recommended criteria as well. These criteria should be evaluated based on their 
preferences.

3.   One modification of the draft that I can think about could be:

a.   Provide a Normative reference to 7916. In particular, clarify that all 
mandatory criteria listed in this RFC MUST  be supported

b.   RECOMMEND giving highest preference to the criteria of lowest IGP 
metric to the destination.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Thursday, July 12, 2018 3:48 PM
To: Alexander Vainshtein ; DECRAENE Bruno 
IMT/OLN 
Cc: Robert Raszuk ; rtgwg-cha...@ietf.org; pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org; rtgwg@ietf.org; 
daniel.vo...@bell.ca
Subject: RE: Request for RTGWG Working Group adoption for 
draft-bashandy-rtgwg-segment-routing-ti-lfa

Hi Sasha,

> This flow will experience two path changes (pre-convergence--> FRR and FRR 
> --> post-convergence
+1, I think that the current  statement in the draft is more a “marketing” one 
rather than a reality and IMO it may be worth removing it.
As Stewart and you pointed, from an end-to-end point of view the path may 
change (so the statement is wrong), a node upstream from the failure may 
reroute the traffic out of the FRR path. And in anyway, the label stack used 
will change (except in one case) even if the hop by hop logical path does not.

> Post-convergence path is taken into account in the operator’s panning (e.g., 
> by allocating sufficient resources for traffic flows on both pre-convergence 
> and post-convergence paths).

This argument is worth to mention. First of all, the draft does not say that 
TILFA is magic and prevents the requirement of additional tuning. It says : 
“there is much less need for the operator
   to tune the decision among which protection path to choose.”.
This statement is perfectly true. With LFA and rLFA, you have high chance to 
pick a P-PE to protect a core link and depending on your topology, a lot of 
tuning and policies is required (see RFC7916) to ensure you get a good backup 
(or sometimes we prefer not having a backup).
TILFA helps here as it can use a loopfree IGP metric optimized path which 
requires less tuning. I do not say that there will never be a requirement for 
tuning but it is unlikely.

Brgds,

Stephane



From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Thursday, July 12, 2018 13:26
To: DECRAENE Bruno IMT/OLN
Cc: Robert Raszuk; rtgwg-cha...@ietf.org; 
pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org;
 rtgwg@ietf.org; 
daniel.vo...@bell.ca
Sub

RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

[stephane.litkowski]

Hi Stewart,

TILFA is not intended to provide a loop free path at all phases of the 
convergence process. As any FRR technique (or most), it may suffer from 
micro-looping when the PLR has converged and rewrites the path out of the 
computed FRR path.
TILFA just encodes the postconvergence path seen from the PLR point of view in 
a loop free manner and the resulting label stack is used only during the FRR.

Global microloop avoidance is also doable using similar mechanism as TILFA, but 
that’s another story.
RFC8333 (local delay) can also be used in conjunction with TILFA to protect 
against local microloops that are caused by a link down.

From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
Sent: Thursday, July 12, 2018 15:47
To: LITKOWSKI Stephane OBS/OINIS; Alexander Vainshtein; DECRAENE Bruno IMT/OLN
Cc: Robert Raszuk; rtgwg-cha...@ietf.org; pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org; rtgwg@ietf.org; 
daniel.vo...@bell.ca
Subject: Re: Request for RTGWG Working Group adoption for 
draft-bashandy-rtgwg-segment-routing-ti-lfa




On 12/07/2018 13:47, 
stephane.litkow...@orange.com wrote:
TILFA helps here as it can use a loopfree IGP metric optimized path

All IPFRR paths are loop free against the number of failures that they set out 
to guard against.

However not all techniques are loop-free at all phases of convergence, and you 
now recognize that to be the case with this method.

Some methods are unconditionally stable against any degree of failure (down 
stream repair), although this is achieved at a cost of reduced coverage. All 
other methods are potentially looping and need a method of retrieving the 
situation which I did not see documented in this draft.

- 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: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

[stephane.litkowski]

Hi,

From a pure theoretical perspective, nothing prevents to do TILFA with Adj-SIDs 
only and this requires only the postfailure SPF to compute. From an 
implementation point of view, I would agree with everyone that this may cause 
some issues for existing HWs ☺, so optimizing the stack size is required. I do 
not think that the optimization algorithm is far from an SRTE algorithm which 
also tries to optimize the label stack size. So the optimization could be seen 
as outside of TILFA specification.

However, where I could agree with Sasha is that the current draft tries to 
propose an optimization of the label stack size as it tells about intersection 
of P space and Q space without giving the full details and especially the 
potential scaling points that implementations need to take care of.

I think what we need to agree on is if the label stack optimization is in scope 
of the draft or out of scope. If in scope, do we standardize one option, do we 
just give some guidelines/clues with pros/cons ?


Brgds,



From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
Sent: Thursday, July 12, 2018 14:35
To: Alexander Vainshtein
Cc: rtgwg-cha...@ietf.org; pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org; daniel.vo...@bell.ca; 
rtgwg@ietf.org; Ahmed Bashandy; Robert Raszuk; Chris Bowers; Stewart Bryant
Subject: RE: Request for RTGWG Working Group adoption for 
draft-bashandy-rtgwg-segment-routing-ti-lfa

Sasha,

Please see inline [Bruno]

From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Thursday, July 12, 2018 1:59 PM
To: DECRAENE Bruno IMT/OLN
Cc: rtgwg-cha...@ietf.org; pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org; daniel.vo...@bell.ca; 
rtgwg@ietf.org; Ahmed Bashandy; Robert Raszuk; Chris Bowers; Stewart Bryant
Subject: RE: Request for RTGWG Working Group adoption for 
draft-bashandy-rtgwg-segment-routing-ti-lfa

Bruno,
The other issue I’ve raised with regard to usage of post-convergence paths is 
scalability.

The draft says (in section 3.2):

   We want to determine which nodes on the post-convergence path from
   the PLR to the destination D are in the Q-Space of destination D
   w.r.t. link S-F.
   This can be found by intersecting the post-convergence path to D,
   assuming the failure of S-F, with Q(D, S-F).
My reading of this text says that  Q(D, S-F) MUST be computed for each 
destination D that is affected by failure of link S-F (I am not aware of any 
other method – do I miss something?).  And this is exactly what RFC 7490 warns 
against in Section 5.2.1:
   Note that the Q-space calculation could be conducted for each
   individual destination and a per-destination repair tunnel end point
   determined.  However, this would, in the worst case, require an SPF
   computation per destination that is not currently considered to be
   scalable.

“Currently” in 7490 presumably refers to 2015, but I am not aware of drastic 
improvements in the computational power of the CPUs of modern routers that 
allow computation of hundreds of reverse SPF computations following every 
topology change.

Again, did I miss something?

[Bruno] First, as you quoted, your comment applies to RLFA. And in general, the 
answer is to restrict yourself to the Q space of E with respect to the link S-E.
Second,
- if you limit yourself to link protection, especially in network with 
symmetric link cost, some shortcut may be found. One could say it’s an 
implementation issue. One could argue that the draft should at least describe 
one algo, while stating that this choice is non-normative.
- if you want node/SRLG protection [RFC 8102] and/or LFA manageability 
[RFC7916] to pick an acceptable path, it’s not clear to me that the 
alternatives scale better. TI-LFA has the benefit of computing the alternate 
path in one easy step (1 SPF), leaving the computation cost to the minimization 
of the list of segments when needed (and this is rarely needed, especially for 
link protection). It’s not clear to me that computing 10s of RLFA and then 
trying to pick the “best” / an acceptable one (e.g. by computing a SPF rooted 
on the PQ of each candidate) is a better way. But we don’t even need to compare 
as this did not stop the publication of RFC 8102.

Regards,
--Bruno

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: Alexander Vainshtein
Sent: Thursday, July 12, 2018 2:26 PM
To: 'bruno.decra...@orange.com' 
Cc: rtgwg-cha...@ietf.org; pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org; daniel.vo...@bell.ca; 
rtgwg@ietf.org; Ahmed Bashandy ; Robert Raszuk 
; Chris Bowers ; Stewart Bryant 

Subject: RE: Request for RTGWG Working Group adoption for 
draft-bashandy-rtgwg-segment-routing-ti-lfa

Bruno,
It seems there is some misunderstanding, and I will try to clarify it.

To the best of my understanding, the following text in Section 1 of the draft 
presents the benefits 

RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

[stephane.litkowski]

Hi Sasha,

> This flow will experience two path changes (pre-convergence--> FRR and FRR 
> --> post-convergence
+1, I think that the current  statement in the draft is more a “marketing” one 
rather than a reality and IMO it may be worth removing it.
As Stewart and you pointed, from an end-to-end point of view the path may 
change (so the statement is wrong), a node upstream from the failure may 
reroute the traffic out of the FRR path. And in anyway, the label stack used 
will change (except in one case) even if the hop by hop logical path does not.

> Post-convergence path is taken into account in the operator’s panning (e.g., 
> by allocating sufficient resources for traffic flows on both pre-convergence 
> and post-convergence paths).

This argument is worth to mention. First of all, the draft does not say that 
TILFA is magic and prevents the requirement of additional tuning. It says : 
“there is much less need for the operator
   to tune the decision among which protection path to choose.”.
This statement is perfectly true. With LFA and rLFA, you have high chance to 
pick a P-PE to protect a core link and depending on your topology, a lot of 
tuning and policies is required (see RFC7916) to ensure you get a good backup 
(or sometimes we prefer not having a backup).
TILFA helps here as it can use a loopfree IGP metric optimized path which 
requires less tuning. I do not say that there will never be a requirement for 
tuning but it is unlikely.

Brgds,

Stephane



From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Thursday, July 12, 2018 13:26
To: DECRAENE Bruno IMT/OLN
Cc: Robert Raszuk; rtgwg-cha...@ietf.org; pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org; rtgwg@ietf.org; 
daniel.vo...@bell.ca
Subject: RE: Request for RTGWG Working Group adoption for 
draft-bashandy-rtgwg-segment-routing-ti-lfa

Bruno,
It seems there is some misunderstanding, and I will try to clarify it.

To the best of my understanding, the following text in Section 1 of the draft 
presents the benefits of using post-convergence path for FRR:

   As the capacity of the post-convergence path is typically planned by
   the operator to support the post-convergence routing of the traffic
   for any expected failure, there is much less need for the operator
   to tune the decision among which protection path to choose.  The
   protection path will automatically follow the natural backup path
   that would be used after local convergence.  This also helps to
   reduce the amount of path changes and hence service transients: one
   transition (pre-convergence to post-convergence) instead of two
   (pre-convergence to FRR and then post-convergence).

I see two different claims of benefits from using post-convergence path in this 
test fragment

1.   One path change and therefore one service transient instead of two

2.   Post-convergence path is taken into account in the operator’s panning 
(e.g., by allocating sufficient resources for traffic flows on both 
pre-convergence and post-convergence paths).


Speaking just for myself, I think that neither of these claims is justified for 
traffic flows that do not originate at the PLR.

E.g., consider Stewart’s example and the traffic flow from A to E

1.   This flow will experience two path changes (pre-convergence--> FRR and 
FRR --> post-convergence

2.   The network operator will not take links C-F, F-G and G-D for 
consideration in its planning of pre-convergence and post-convergence paths for 
this flow.

Did I miss something substantial?

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
Sent: Thursday, July 12, 2018 12:49 PM
To: Stewart Bryant 
Cc: rtgwg-cha...@ietf.org; pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org; daniel.vo...@bell.ca; 
rtgwg@ietf.org; Ahmed Bashandy ; Alexander Vainshtein 
; Robert Raszuk ; Chris 
Bowers 
Subject: RE: Request for RTGWG Working Group adoption for 
draft-bashandy-rtgwg-segment-routing-ti-lfa

Stewart,

Please see 1 comment inline [Bruno]
Trimming the text to ease the focus on this point

From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
Sent: Tuesday, July 10, 2018 2:40 PM


On 09/07/2018 20:53, Ahmed Bashandy wrote:
[…]


b.   Selecting the post-convergence path (inheritance from draft-francois) 
does not provide for any benefits for traffic that will not pass via the PLR 
after convergence.

   i.  The 
authors claim to have addressed this issue by stating that “Protection applies 
to traffic which traverses the Point of Local Repair (PLR). Traffic which does 
NOT traverse the PLR remains unaffected.”

SB> It is not as simple as that, and I think that the draft needs to provide 
greater clarity.

I think there will be better examples, but consider

RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

[stephane.litkowski]

Bruno,

Stewart’s example is right. TILFA is not targeted to provide the 
post-convergence path from an end to end point of view (any source to any dest) 
but rather provides the post-convergence path starting at the PLR (from the PLR 
point of view).
I think we all agree on that.

What I do not see is where could we improve the text as we already mention this 
in the intro:

“Building on such an easier forwarding environment, the FRR behavior
   suggested in this document tailors the repair paths over the post-
   convergence path from the PLR to the protected destination, given
   the enabled protection mode for the interface.”


Brgds,


From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
Sent: Thursday, July 12, 2018 11:49
To: Stewart Bryant
Cc: rtgwg-cha...@ietf.org; pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org; daniel.vo...@bell.ca; 
rtgwg@ietf.org; Ahmed Bashandy; Alexander Vainshtein; Robert Raszuk; Chris 
Bowers
Subject: RE: Request for RTGWG Working Group adoption for 
draft-bashandy-rtgwg-segment-routing-ti-lfa

Stewart,

Please see 1 comment inline [Bruno]
Trimming the text to ease the focus on this point

From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
Sent: Tuesday, July 10, 2018 2:40 PM

On 09/07/2018 20:53, Ahmed Bashandy wrote:
[…]

b.   Selecting the post-convergence path (inheritance from draft-francois) 
does not provide for any benefits for traffic that will not pass via the PLR 
after convergence.

   i.  The 
authors claim to have addressed this issue by stating that “Protection applies 
to traffic which traverses the Point of Local Repair (PLR). Traffic which does 
NOT traverse the PLR remains unaffected.”

SB> It is not as simple as that, and I think that the draft needs to provide 
greater clarity.

I think there will be better examples, but consider

  12
  +--+
  |  |
A-B-C---//---DE
10  ||
FG

Traffic injected at C will initially go C-D-E at cost 2, will be repaired 
C-F-G-D-E at cost 4 and will remain on that path post convergence. This 
congruence of path is what TI-LFA claims.

However, a long standing concern about traffic starting further back in the 
network needs to be more clearly addressed in the draft to clearly demonstrate 
the scope of applicability.

For traffic starting at A, before failure the path is A-B-C-D-E cost 13

TI-LFA will repair to make the path A-B-C-F-G-D-E cost 15 because TI-LFA 
optimises based on local repairs computed at C.

After repair the path will be A-B-D-E cost 14.

[Bruno] The draft is about IP Fast ReRoute (FRR).
FRR is a local reaction to failure, so by hypothesis, all nodes but the PLR are 
not aware about the failure. This includes all upstream nodes which do keep 
forwarding traffic through the same path, i.e. via the PLR.
The argument that the path would have been shorter if upstream node were aware 
of the failure to reroute before (or that the PLR should send the packet back 
in time) is not relevant.
The only question which matter is: from the PLR to the destination, which is 
the best path to use?
I, and the draft, argue that the best path in IP routing, is the IGP shortest 
path. Whichever type of metric you choose (e.g. bandwidth, latency, cost…). Do 
you disagree on this?


Now, eventually we can narrow down the discussion to the choice of terms. We 
can discuss about the term “post-convergence paths from the point of local 
repair », which you don’t think to like. Although, the term seems technically 
true to me, I would also be fine with changing from  “post-convergence path” to 
“optimal IGP shortest path”



So the draft needs to make it clear to the reader that TI-LFA only provides 
benefit to traffic which traverses the PLR before and after failure.

[Bruno] No, that is not true. cf above.
--Bruno

Traffic which does not pass through the PLR after the failure will need to be 
traffic engineered separately from traffic that passes though the PLR in both 
cases.




_



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 i

RE: Is TI-LFA compatible with the default SR algorithm?

[stephane.litkowski]

Hi Sasha,

Could you elaborate on :" I strongly suspect that it is not so, and that these 
mechanisms are only compatible with the Strict-SPF. (Actually, I can provide an 
example that confirms this suspicion.)" ?

Thanks,


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Wednesday, June 13, 2018 17:00
To: draft-bashandy-rtgwg-segment-routing-ti-lfa.auth...@ietf.org
Cc: Stewart Bryant; Michael Gorokhovsky; 
draft-ietf-spring-segment-routing.auth...@ietf.org; spr...@ietf.org; 
rtgwg@ietf.org
Subject: [spring] Is TI-LFA compatible with the default SR algorithm?

Hi all,
I have looked up Section 3.1.1 "Prefix-SID Algorithm" of the Segment Routing 
Architecture 
draft (already In the RFC Editor queue) and found there the following statement 
(the relevant part is highlighted):

This document defines two algorithms:

   o  "Shortest Path": this algorithm is the default behavior.  The
  packet is forwarded along the well-known ECMP-aware SPF algorithm
  employed by the IGPs.  However it is explicitly allowed for a
  midpoint to implement another forwarding based on local policy.
  The "Shortest Path" algorithm is in fact the default and current
  behavior of most of the networks where local policies may override
  the SPF decision.

   o  "Strict Shortest Path (Strict-SPF)": This algorithm mandates that
  the packet is forwarded according to ECMP-aware SPF algorithm and
  instructs any router in the path to ignore any possible local
  policy overriding the SPF decision.  The SID advertised with
  Strict-SPF algorithm ensures that the path the packet is going to
  take is the expected, and not altered, SPF path.  Note that Fast
  Reroute (FRR) [RFC5714] mechanisms 
are still compliant with the
  Strict Shortest Path.  In other words, a packet received with a
  Strict-SPF SID may be rerouted through a FRR mechanism.

At the same time, the TI-LFA 
draft
 discusses protection of active Prefix-SIDs (e.g., in Section 3 that discusses 
P-Space and Q-space) but, to the best of my understanding, does not mention 
algorithms that form the context of these SIDs.

My question to the authors of the TI-LFA draft is:

Are the mechanisms defined in the draft (and examples discussed in Section 4) 
applicable to Prefix-SIDs associated with the default forwarding algorithm as 
defined in the Segment Routing Architecture draft?

I strongly suspect that it is not so, and that these mechanisms are only 
compatible with the Strict-SPF. (Actually, I can provide an example that 
confirms this suspicion.)

Do I miss something substantial here?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com


___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___

_

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: draft-ietf-rtgwg-spf-uloop-pb-statement

[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.
+==

In multi-vendor networks, using different implementations of 

RE: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement

[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

RE: WG last call for draft-ietf-rtgwg-spf-uloop-pb-statement

[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

[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/




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: RTGWG WGLC draft-ietf-rtgwg-backoff-algo

[stephane.litkowski]

Hi,

As a co-author, I’m not aware of any IPR.

-Original Message-
From: Jeff Tantsura [mailto:jefftant.i...@gmail.com] 
Sent: Wednesday, November 29, 2017 16:41
To: RTGWG
Cc: rtgwg-chairs; draft-ietf-rtgwg-backoff-a...@ietf.org
Subject: RTGWG WGLC draft-ietf-rtgwg-backoff-algo

Dear RTGWG,

The authors have requested the RTGWG to last call draft-ietf-rtgwg-backoff-algo.

There was consensus that document is ready for the last call and the authors 
have addressed all the comments from RTGDIR review. 
Please indicate support or no-support by December 14, 2017.

IPR:
If you are listed as a document author or contributor, please respond to this 
email of 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.

Cheers,
Jeff & Chris



_

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: Alvaro Retana's Discuss on draft-ietf-rtgwg-uloop-delay-07: (with DISCUSS and COMMENT)

[stephane.litkowski]

Hi Alvaro,

I just posted a v9 which fixes the definition of LSP_GEN_TIMER as follows:
LSP_GEN_TIMER: The delay between two consecutives local LSP/LSA
  generation.  From an operational point of view, this delay is
  usually tuned to batch multiple local events in one single local
  LSP/LSA update.  In IS-IS, this timer is defined as
  minimumLSPGenerationInterval in [ISO10589].  In OSPF version 2,
  this timer is defined as MinLSInterval in [RFC2328].  It is often
  associated with a vendor specific damping mechanism to slow down
  reactions by incrementing the timer when multiple consecutive
  events are detected.

I hope it addresses your comment, otherwise let me know.

Brgds,


From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Thursday, October 12, 2017 23:36
To: Alvaro Retana
Cc: The IESG; draft-ietf-rtgwg-uloop-de...@ietf.org; rtgwg-cha...@ietf.org; 
chrisbowers.i...@gmail.com; rtgwg@ietf.org; Acee Lindem (acee) (a...@cisco.com)
Subject: RE: Alvaro Retana's Discuss on draft-ietf-rtgwg-uloop-delay-07: (with 
DISCUSS and COMMENT)

Hi Alvaro,

Maybe the definition we gave for the LSP_GEN_TIMER is wrong (I think we defined 
more the usage rather than giving the exact definition), because we are talking 
about the local LSA/LSP regeneration.
We usually slowdown the generation in case of flaps to aggregate events and to 
prevent propagation of all topology changes.


From: Alvaro Retana [mailto:aretana.i...@gmail.com]
Sent: Thursday, October 12, 2017 15:57
To: LITKOWSKI Stephane OBS/OINIS
Cc: The IESG; 
draft-ietf-rtgwg-uloop-de...@ietf.org;
 rtgwg-cha...@ietf.org; 
chrisbowers.i...@gmail.com; 
rtgwg@ietf.org; Acee Lindem (acee) 
(a...@cisco.com)
Subject: Re: Alvaro Retana's Discuss on draft-ietf-rtgwg-uloop-delay-07: (with 
DISCUSS and COMMENT)

On Thu, Oct 12, 2017 at 2:47 AM, 
mailto:stephane.litkow...@orange.com>> wrote:
Hi!

The minimumLSPGenerationInterval is IMO the LSP_GEN_TIMER we are describing. It 
controls the pacing of the local LSP generation. In ISO 10589, it is a fixed 
timer value while now implementations are often using a damping mechanism 
associated with this timer rather than a fixed value.

The MinLSInterval seems to be the equivalent in OSPF (I’m not an expert in 
OSPF, but Acee pointed this one to me). Again the backoff/damping is not 
defined as a standard. There is a BCP RFC 4222 but it does seem to address the 
MinLSInterval backoff.

The I-D.ietf-rtgwg-backoff-algo only controls the SPF delay, not the 
LSP_GEN_TIMER.

Do you agree ?

No, I don't agree that LSP_GEN_TIMER is the same as 
minimumLSPGenerationInterval or MinLSInterval.

LSP_GEN_TIMER is described to "batch multiple local events in one single local 
LSP/LSA update", but both minimumLSPGenerationInterval/MinLSInterval are about 
regeneration of LSP/LSAs.  IOW, the description in 5.2

"2.  The IGP processes the notification and postpones the reaction for
   LSP_GEN_TIMER msec."

Is not right because minimumLSPGenerationInterval/MinLSInterval would not delay 
the initial generation of an LSP/LSA.  That was my initial point, I don't know 
where a timer like LSP_GEN_TIMER is defined for ISIS/OSPF -- one that delays 
the initial generation of an LSP/LSA.




About SPF_DELAY...  Yes, I-D.ietf-rtgwg-backoff-algo is the only place where I 
see SPF_DELAY defined -- which makes it an existing (documented) timer.  I 
think that I-D.ietf-rtgwg-backoff-algo should then be a Normative reference.

Note also that I-D.ietf-rtgwg-backoff-algo does define something that sounds to 
me just like LSP_GEN_TIMER:


   TIME_TO_LEARN_INTERVAL: This is the maximum duration typically needed

   to learn all the IGP events related to a single component failure

   (e.g., router failure, SRLG failure), e.g., 1 second.  It's mostly

   dependent on failure detection time variation between all routers

   that are adjacent to the failure.  Additionally, it may depend on the

   different IGP implementations across the network, related to

   origination and flooding of their link state advertisements.



It seems that it should be the right reference.

Thanks!

Alvaro.


Brgds,

From: Alvaro Retana 
[mailto:aretana.i...@gmail.com]
Sent: Thursday, October 12, 2017 02:59
To: LITKOWSKI Stephane OBS/OINIS
Cc: The IESG; 
draft-ietf-rtgwg-uloop-de...@ietf.org;
 rtgwg-cha...@ietf.org; 
chrisbowers.i...@gmail.com; 
rtgwg@ietf.org
Subject: Re: Alvaro Retana's Discuss on draft-ietf-rtgwg-uloop-delay-07: (with 
DISCUSS and COMMENT)

On Wed, Oct 11, 2017 at 5:07 AM, 
mailto:stephane.litkow...@orange.com>> wrote:
Stephane:
Hi!

...
---

RE: Ben Campbell's No Objection on draft-ietf-rtgwg-uloop-delay-07: (with COMMENT)

[stephane.litkowski]

Hi Ben,

Thanks for your review, I will publish a revision soon addressing your comment.
The RFC type (BGP vs info vs STD) has been discussed in the WG, and we are 
following the way of LFA,rLFA... that are standard track RFCs. Please see the 
email attached.

Brgds,


-Original Message-
From: Ben Campbell [mailto:b...@nostrum.com] 
Sent: Thursday, October 12, 2017 06:13
To: The IESG
Cc: draft-ietf-rtgwg-uloop-de...@ietf.org; rtgwg-cha...@ietf.org; 
chrisbowers.i...@gmail.com; rtgwg@ietf.org
Subject: Ben Campbell's No Objection on draft-ietf-rtgwg-uloop-delay-07: (with 
COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-rtgwg-uloop-delay-07: 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-uloop-delay/



--
COMMENT:
--

(Oops, sorry, I entered the bit about addressing my comments for the wrong
draft.)

- General: Do I undertand correctly that this is a black-box implementation 
detail? I note that section 4 explicitly says that it is a local-only feature 
that does not require interoperability. If so, then standards track seems 
inappropriate. BCP or informational seems to make more sense. Since there are 
recommendations here, I think BCP is the right choice.  (I note Adam made a 
similar comment.)

-11: Do you expect this section to stay in the RFC? It is likely to become 
outdated rather quickly.

Editorial Comments:

- General: Please number the tables.

- sections 2 and 3 and their child sections have quite a few grammar errors.
Please proofread it again. I mention a few specifics below, but doubt I caught 
everything.

- 2, first paragraph: " That means that all non-D neighbors of S on the 
topology will send to S any traffic destined to D if a neighbor did not, then 
that neighbor would be loop-free." I can't parse that sentence. Is it a run-on 
sentence, or are there missing words? -- S / "can be work" / "can work"

-3: " may cause high damages for a network."
I suggest " may cause significant network damage".

-4, last paragraph: "This benefit comes at the expense of eliminating transient 
forwarding loops involving the local router. " How is that an "expense"? Isn't 
it the whole point?

-5.3, first paragraph and paragraph before figure 4:
The MUST is stated twice. Please avoid redundant normative statements. Even if 
they agree now, they can cause maintenance issues down the road.



_

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.

--- Begin Message ---



I will accept whatever the consensus is.

- Stewart


On 05/06/2017 16:22, Chris Bowers wrote:


   Stewart,



   It seems to me that this document is not qualitatively different from the 
LFA, RLFA, and

   node-protecting LFA RFCs which were all published as standards track.  The 
behavior of the PLR

   in those documents is also a local matter, and in principle can be deployed 
on a single router without

   the knowledge of the rest of the network (except for allowing establishment 
of targeted LDP

   sessions in the case of remote LFA).



   Publishing this draft as standards track seems to be consistent with the 
decision made on those drafts.



   Chris





   From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
   Sent: Monday, June 5, 2017 4:48 AM
   To: Chris Bowers ; Acee 
Lindem (acee) ; RTGWG 

   Subject: Re: WG last call for draft-ietf-rtgwg-uloop-delay



   Hi Chris

   An RFC is surely sufficient to specify the behaviour of the router, and 
communicate

RE: Eric Rescorla's No Objection on draft-ietf-rtgwg-uloop-delay-07: (with COMMENT)

[stephane.litkowski]

Hi Eric,

Thanks for your review, I will take care of your comments.

" Line 136
   When S-D fails, a transient forwarding loop may appear between S and
   B if S updates its forwarding entry to D before B.
Something seems to have gone badly wrong with this paragraph. Are these lines 
supposed to be in the previous paragraph."

[SLI] This is the postamble of the figure and not really a paragraph.


" Figure 7
Is this the same as the previous figure with T running CEAB?
"

[SLI] What figure are you talking about when saying "the previous" ?
I think there is a copy/paste issue. The tunnel T is not used here.


Brgds,


-Original Message-
From: Eric Rescorla [mailto:e...@rtfm.com] 
Sent: Wednesday, October 11, 2017 23:43
To: The IESG
Cc: draft-ietf-rtgwg-uloop-de...@ietf.org; rtgwg-cha...@ietf.org; 
chrisbowers.i...@gmail.com; rtgwg@ietf.org
Subject: Eric Rescorla's No Objection on draft-ietf-rtgwg-uloop-delay-07: (with 
COMMENT)

Eric Rescorla has entered the following ballot position for
draft-ietf-rtgwg-uloop-delay-07: 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-uloop-delay/



--
COMMENT:
--

Line 115
   Consider the case in Figure 1 where S does not have an LFA to protect
   its traffic to D.  That means that all non-D neighbors of S on the You need 
to define LFA.

Line 118
   topology will send to S any traffic destined to D if a neighbor did
   not, then that neighbor would be loop-free.  Regardless of the
   advanced fast-reroute (FRR) technique used, when S converges to the This is 
not a grammatical sentence.

Line 132
S -- B
 1
Figure 1
What do the numbers in this box mean? I assume they are route metrics, but you 
need to say so.

Line 136
   When S-D fails, a transient forwarding loop may appear between S and
   B if S updates its forwarding entry to D before B.
Something seems to have gone badly wrong with this paragraph. Are these lines 
supposed to be in the previous paragraph.

Line 326
  unstable.  As an example, [I-D.ietf-rtgwg-backoff-algo] defines a
  standard SPF delay algorithm.
You need to define SPF here.

Line 338
   1.  The Up/Down event is notified to the IGP.
Usually, one would say that the IGP is notified of...

Line 552
   S

 Figure 7
Is this the same as the previous figure with T running CEAB?



_

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: Warren Kumari's No Objection on draft-ietf-rtgwg-uloop-delay-07: (with COMMENT)

[stephane.litkowski]

Hi Warren,

Thanks for your review.

I will fix it in the next revision.

Brgds,


-Original Message-
From: Warren Kumari [mailto:war...@kumari.net] 
Sent: Wednesday, October 11, 2017 23:30
To: The IESG
Cc: draft-ietf-rtgwg-uloop-de...@ietf.org; rtgwg-cha...@ietf.org; 
chrisbowers.i...@gmail.com; rtgwg@ietf.org
Subject: Warren Kumari's No Objection on draft-ietf-rtgwg-uloop-delay-07: (with 
COMMENT)

Warren Kumari has entered the following ballot position for
draft-ietf-rtgwg-uloop-delay-07: 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-uloop-delay/



--
COMMENT:
--

Section 1.  Introduction:
"That means that all non-D neighbors of S on the
   topology will send to S any traffic destined to D if a neighbor did
   not, then that neighbor would be loop-free."
 -- I was unable to parse the above. I may just be overtired, but it feels like 
 there are some missing words.

Nits:
" When S-D fails, a transient forwarding loop may appear between S and
   B if S updates its forwarding entry to D before B."
 -- Perhaps "... entry to D before B does." or "... before B updates its  
forwarding entry"?

Section 2.1.  Fast reroute inefficiency
"On the  router C, the nexthop to D is the tunnel T thanks to the IGP 
shortcut." s/the//

"On C, the tail-end of the TE tunnel (router B) is no more on the shortest-path 
tree (SPT) to D, ..." s/is no more on/is no longer on/ (related) "... so C does 
not encapsulate anymore the traffic to D..." s/does not encapsulate anymore/no 
longer encapsulates/

Section 3.  Overview of the solution
"This ordered convergence, is similar to the ordered FIB ..."
s/,/ (superfluous).



_

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: Alvaro Retana's Discuss on draft-ietf-rtgwg-uloop-delay-07: (with DISCUSS and COMMENT)

[stephane.litkowski]

Hi Alvaro,

The minimumLSPGenerationInterval is IMO the LSP_GEN_TIMER we are describing. It 
controls the pacing of the local LSP generation. In ISO 10589, it is a fixed 
timer value while now implementations are often using a damping mechanism 
associated with this timer rather than a fixed value.

The MinLSInterval seems to be the equivalent in OSPF (I’m not an expert in 
OSPF, but Acee pointed this one to me). Again the backoff/damping is not 
defined as a standard. There is a BCP RFC 4222 but it does seem to address the 
MinLSInterval backoff.

The I-D.ietf-rtgwg-backoff-algo only controls the SPF delay, not the 
LSP_GEN_TIMER.

Do you agree ?

Brgds,

From: Alvaro Retana [mailto:aretana.i...@gmail.com]
Sent: Thursday, October 12, 2017 02:59
To: LITKOWSKI Stephane OBS/OINIS
Cc: The IESG; draft-ietf-rtgwg-uloop-de...@ietf.org; rtgwg-cha...@ietf.org; 
chrisbowers.i...@gmail.com; rtgwg@ietf.org
Subject: Re: Alvaro Retana's Discuss on draft-ietf-rtgwg-uloop-delay-07: (with 
DISCUSS and COMMENT)

On Wed, Oct 11, 2017 at 5:07 AM, 
mailto:stephane.litkow...@orange.com>> wrote:
Stephane:
Hi!

...
--
DISCUSS:
--

Section 5.1. (Definitions) refers to a couple of “existing IGP timers”.  I 
understand the concepts, but can you please reference the IGP documents where 
these timers are defined?  I quickly checked rfc2328 and couldn’t find a 
specific place that talked about LSP_GEN_TIMER (or LSA, of course!), or a 
similar concept.  SPF_DELAY seems to be introduced by 
I-D.ietf-rtgwg-backoff-algo.  Given that the rest of Section 5. (Specification) 
is built on these “existing IGP timers”, I think that the references should be 
Normative.

[SLI] ISIS does have the minimumLSPGenerationInterval defined in the ISO 
specification. I will add it. For OSPF, I do not see the equivalent in the base 
spec. I will check with Acee if he knows some references or if it's purely 
local features that have been implemented.

This is the definition from 10589:

minimumLSPGenerationInterval – This is the minimum time interval between 
generation of Link State PDUs. A source Intermediate system shall wait at least 
this long before re-generating one of its own Link State PDUs.


That is not the same as LSP_GEN_TIMER.

I get the impression that the only place where  that documents it might be 
I-D.ietf-rtgwg-backoff-algo.


Note also that the description in Section 5.2. (Current IGP reactions) is 
described (in 5.3) as the “standard IP convergence” and carries a “MUST”
associated with it.  It was mentioned (in 5.1) that the timers in question are 
“often associated with a damping mechanism”, which is not part of the base IGP 
specifications.

[SLI] I agree with your point. I think that the "standard" word is badly used 
it and "regular" may be more appropriate.
The behavior defined in 5.2 cannot be defined as a standard, as it clearly 
depends on the implementation and additional timers may be involved.
My proposal is to:
- change the word "standard" to "regular" in section 5.3
- change the title of Section 5.2 to "Regular IGP reaction" to accommodate the 
change in 5.3
- In 5.2, modify slightly the text as follows:
" Upon a change of the status of an adjacency/link, the regular IGP convergence
   behavior of the router advertising the event involves the following main 
steps: "

It's important to keep the "MUST" in section 5.3, as applying the delay timer 
to complex outages is dangerous and may lead to side effects.

Yes, the changes are fine.  The MUST being there is needed (I agree) -- that is 
what makes the reference needed to be Normative.





I’m putting this comment in as a DISCUSS given that understanding the 
definitions (and having then Normative references) is necessary for the 
implementation of the mechanism described.  I think it should be easy to 
resolve by just adding the appropriate references.


--
COMMENT:
--

...
(2) Section 5.4. (Local delay for link down) specifies that “update of the RIB 
and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER msecs.  Otherwise, the 
RIB and FIB SHOULD be updated immediately.”  When would ULOOP_DELAY_DOWN_TIMER 
not be applied?
[SLI] The text states " If the
  condition of a single local link-down event has been met ". The 
"otherwise" is linked to this statement. This means that the FIB/RIB SHOULD be 
updated immediately when this condition is not met.

Sorry, that question was for the first "SHOULD":

In "update of the RIB and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER 
msecs", when would you not delay?  Why is that not a "MUST"?

(2)Along the same lines, if there’s no delay mentioned in Step 5 of 5.3, when 
would the RIB/FIB not be updated immediately?  IOW, why are these “SHOULDs” not 
“MUS

RE: Adam Roach's No Objection on draft-ietf-rtgwg-uloop-delay-07: (with COMMENT)

[stephane.litkowski]

Ack will fix it

Thanks


-Original Message-
From: Adam Roach [mailto:a...@nostrum.com] 
Sent: Wednesday, October 11, 2017 17:30
To: LITKOWSKI Stephane OBS/OINIS; The IESG
Cc: chrisbowers.i...@gmail.com; rtgwg-cha...@ietf.org; 
draft-ietf-rtgwg-uloop-de...@ietf.org; rtgwg@ietf.org
Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-uloop-delay-07: 
(with COMMENT)



On 10/11/17 4:18 AM, stephane.litkow...@orange.com wrote:
> Hi Adam,
>
> Thanks for your review.
> Some comments inline
>

Your proposals all look good to me. One additional comment, below.

>
> Section 4 begins:
>
> This document defines a two-step convergence initiated by the router
> detecting a failure and advertising the topological changes in the
> IGP.  This introduces a delay between the convergence of the local
> router and the network wide convergence.
>
> This reads backwards to me. With this technique, the network converges first, 
> followed by an introduced delay, followed by router convergence. Right?
> [SLI] The network converges first, then the local router thanks to the 
> introduced local delay.

Yes, so I would suggest rephrasing the above as:

This document defines a two-step convergence initiated by the router
detecting a failure and advertising the topological changes in the
IGP.  This introduces a delay between network-wide convergence and
the convergence of the local router.


/a


_

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: Adam Roach's No Objection on draft-ietf-rtgwg-uloop-delay-07: (with COMMENT)

[stephane.litkowski]

Hi Adam,

Thanks for your review.
Some comments inline

-Original Message-
From: Adam Roach [mailto:a...@nostrum.com] 
Sent: Wednesday, October 11, 2017 00:44
To: The IESG
Cc: draft-ietf-rtgwg-uloop-de...@ietf.org; rtgwg-cha...@ietf.org; 
chrisbowers.i...@gmail.com; rtgwg@ietf.org
Subject: Adam Roach's No Objection on draft-ietf-rtgwg-uloop-delay-07: (with 
COMMENT)

Adam Roach has entered the following ballot position for
draft-ietf-rtgwg-uloop-delay-07: 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-uloop-delay/



--
COMMENT:
--

This document doesn't really define any new on-the-wire protocol. Was 
publication as a BCP rather than a standards track document considered?

The Introduction contains the following text:

   That means that all non-D
   neighbors of S on the topology will send to S any traffic destined to
   D if a neighbor did not, then that neighbor would be loop-free.

I can't parse this sentence. Is there supposed to be a sentence break somewhere 
in there?

[SLI] Good catch, Alvaro saw it also. A break is necessary between "D" and "if 
a neighbor".

The introduction starts talking about post-failure events (e.g., "when S 
converges to the new topology") before mentioning a failure of the S-D link.
This makes it very hard to follow. Would suggest mentioning the failure being 
considered before talking about the ensuing events.

[SLI] Right, I propose:
" Consider the case in Figure 1 where S does not have an LFA (Loop Free 
Alternate) to protect its traffic to D when the S-D link fails.  "


Section 4 begins:

   This document defines a two-step convergence initiated by the router
   detecting a failure and advertising the topological changes in the
   IGP.  This introduces a delay between the convergence of the local
   router and the network wide convergence.

This reads backwards to me. With this technique, the network converges first, 
followed by an introduced delay, followed by router convergence. Right?
[SLI] The network converges first, then the local router thanks to the 
introduced local delay.

Further on in that section:

   This benefit comes at the
   expense of eliminating transient forwarding loops involving the local
   router.

I can't make sense of this. Eliminating transient forwarding loops is a good 
thing, right? Not an expense?

[SLI] I think there is a missing word as we mean :" at the expense of 
eliminating the transient forwarding loops involving the local router ONLY".
I also agree that it's not really an expense , but more a limitation.
Here is a proposed rewording:
" This benefit comes with the limitation of eliminating transient forwarding 
loops involving the local router only"


I agree with Alvaro that the lack of a recommended default for 
ULOOP_DELAY_DOWN_TIMER is an issue, especially as the values configured in the 
examples seem to change arbitrarily from 1 second to 2 seconds.
[SLI] We cannot propose a default value that would fit all the situations. I 
agree that a statement is required in the Deployment Section to drive how the 
timer should be configured.

" The ULOOP_DELAY_DOWN_TIMER value should be set according to the maximum IGP 
convergence time observed in the network (usually observed in the slowest 
node)."


_

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: Alvaro Retana's Discuss on draft-ietf-rtgwg-uloop-delay-07: (with DISCUSS and COMMENT)

[stephane.litkowski]

Hi Alvaro

Thanks for your review.
Please find some comments below

-Original Message-
From: Alvaro Retana [mailto:aretana.i...@gmail.com] 
Sent: Tuesday, October 10, 2017 22:51
To: The IESG
Cc: draft-ietf-rtgwg-uloop-de...@ietf.org; rtgwg-cha...@ietf.org; 
chrisbowers.i...@gmail.com; rtgwg@ietf.org
Subject: Alvaro Retana's Discuss on draft-ietf-rtgwg-uloop-delay-07: (with 
DISCUSS and COMMENT)

Alvaro Retana has entered the following ballot position for
draft-ietf-rtgwg-uloop-delay-07: Discuss

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://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-uloop-delay/



--
DISCUSS:
--

Section 5.1. (Definitions) refers to a couple of “existing IGP timers”.  I 
understand the concepts, but can you please reference the IGP documents where 
these timers are defined?  I quickly checked rfc2328 and couldn’t find a 
specific place that talked about LSP_GEN_TIMER (or LSA, of course!), or a 
similar concept.  SPF_DELAY seems to be introduced by 
I-D.ietf-rtgwg-backoff-algo.  Given that the rest of Section 5. (Specification) 
is built on these “existing IGP timers”, I think that the references should be 
Normative.

[SLI] ISIS does have the minimumLSPGenerationInterval defined in the ISO 
specification. I will add it. For OSPF, I do not see the equivalent in the base 
spec. I will check with Acee if he knows some references or if it's purely 
local features that have been implemented.


Note also that the description in Section 5.2. (Current IGP reactions) is 
described (in 5.3) as the “standard IP convergence” and carries a “MUST”
associated with it.  It was mentioned (in 5.1) that the timers in question are 
“often associated with a damping mechanism”, which is not part of the base IGP 
specifications.

[SLI] I agree with your point. I think that the "standard" word is badly used 
it and "regular" may be more appropriate.
The behavior defined in 5.2 cannot be defined as a standard, as it clearly 
depends on the implementation and additional timers may be involved.
My proposal is to:
- change the word "standard" to "regular" in section 5.3
- change the title of Section 5.2 to "Regular IGP reaction" to accommodate the 
change in 5.3
- In 5.2, modify slightly the text as follows:
" Upon a change of the status of an adjacency/link, the regular IGP convergence
   behavior of the router advertising the event involves the following main 
steps: "

It's important to keep the "MUST" in section 5.3, as applying the delay timer 
to complex outages is dangerous and may lead to side effects.




I’m putting this comment in as a DISCUSS given that understanding the 
definitions (and having then Normative references) is necessary for the 
implementation of the mechanism described.  I think it should be easy to 
resolve by just adding the appropriate references.


--
COMMENT:
--

(1) Where do the numbers in the “Route computation event time scale” table come 
from?  Please put a reference or at least some guidance to the origin of the 
information.  If it's just for informational purposes, then please say so. 
BTW, please also put a number on the table.  [I have the same question for the 
tables in Section 9.]

[SLI] That's purely an example. I'm adding some statements before each table to 
make it clear.
" The table 1 below describes a theorical sequence of events happening when the 
B-C link fails. This theorical sequence of events should only be read as an 
example."
" The table 5 is based on a theorical sequence of event that should only been 
read as an example."


(2) Section 5.4. (Local delay for link down) specifies that “update of the RIB 
and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER msecs.  Otherwise, the 
RIB and FIB SHOULD be updated immediately.”  When would ULOOP_DELAY_DOWN_TIMER 
not be applied?  
[SLI] The text states " If the
  condition of a single local link-down event has been met ". The 
"otherwise" is linked to this statement. This means that the FIB/RIB SHOULD be 
updated immediately when this condition is not met.

(2)Along the same lines, if there’s no delay mentioned in Step 5 of 5.3, when 
would the RIB/FIB not be updated immediately?  IOW, why are these “SHOULDs” not 
“MUSTs”?
[SLI] Do you refer to 5.2 (and not 5.3) as there is no Step 5 in 5.3. In 5.2, 
the RIB/FIB are updated immediately after the SPF computation.


(3) What should be the 

RE: Secdir last call review of draft-ietf-rtgwg-uloop-delay-06

[stephane.litkowski]

Hi,

Thanks for your review.
The v07 I just posted addresses your comments.

Brgds,


-Original Message-
From: Melinda Shore [mailto:melinda.sh...@gmail.com] 
Sent: Thursday, October 05, 2017 00:09
To: sec...@ietf.org
Cc: draft-ietf-rtgwg-uloop-delay@ietf.org; i...@ietf.org; rtgwg@ietf.org
Subject: Secdir last call review of draft-ietf-rtgwg-uloop-delay-06

Reviewer: Melinda Shore
Review result: Has Nits

This document describes a mechanism to mitigate against failures stemming from 
the formation of "microloops" during a re-routing convergence, as described in 
RFC 5715.  Modulo some mechanical problems with language usage (i.e.
grammatical errors) and some missing definitions, the document clearly 
describes the problem it is addressing and the proposed solution.

The security considerations section is very clear about why the authors believe 
no new attacks are introduced by this mechanism, and it is credible

Sections 4 and 5 represent the core of the document and are very clear - a very 
nice piece of specification.

It would be helpful to have a terminology section, or to expand some of the 
acronyms in-line (LFA, for example).

For some reason the grammatical errors are clustered towards the front of the 
document but there are many scattered throughout:

Section 1, first paragraph singular/plural mismatch: "Based on network 
analysis, local failure make up a significant portion of the micro-forwarding 
loops"

Section 1, second paragraph unidiomatic use of "the topology"

Section 2, first paragraph unidiomatic use of "high damages"

Section 2.1, first paragraph needs an article on "IGP shortcut"

Same paragraph, doesn't need an article on "the router C"

Same paragraph, "nexthop" should be two words

Item 1 in 2.1, needs an article before "preprogrammed FRR path", also run-on 
sentence needs to be split or a conjunction inserted

Item 3 in 2.1, "no more" should be "no longer", and "encapsulate anymore"
should be "does not continue to encapsulate"

Section 2.1, last paragraph: "The protection enabled by fast-reroute is working 
perfectly, but ensures a protection, by definition, only until the PLR has 
converged." is somewhat unclear

Section 3, third paragraph: first comma is unnecessary.  Also, "local only"
should be "local-only"

Section 8.2, first paragraph: "associating timing" should be "associated 
timing".

Also in section 8.2, the message chart header is separated from the actual 
contents by a page break, and that should be remedied

Section 8.3, first paragraph: "that happens" should be "that happen".  Also, 
"without further delaying route insertion" would be more idiomatic than 
"without delaying route insertion anymore"

Section 9.1, throughout: "nexthop" should be "next hop"

Section 9.1, first bullet item: "only have one" should be "only has one" (or 
"has only one")

Section 10: "a good behavior" should be "good behavior"


_

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: Mirja Kühlewind's No Objection on draft-ietf-rtgwg-uloop-delay-06: (with COMMENT)

[stephane.litkowski]

Thanks Mirja.

I will fix this in the next revision.

Brgds,

-Original Message-
From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Mirja Kühlewind
Sent: Monday, October 09, 2017 13:34
To: The IESG
Cc: rtgwg-cha...@ietf.org; draft-ietf-rtgwg-uloop-de...@ietf.org; rtgwg@ietf.org
Subject: Mirja Kühlewind's No Objection on draft-ietf-rtgwg-uloop-delay-06: 
(with COMMENT)

Mirja Kühlewind has entered the following ballot position for
draft-ietf-rtgwg-uloop-delay-06: 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-uloop-delay/



--
COMMENT:
--

Nit in section 9:
You should probably not talk about 'our' solution or mechanism in an RFC:
s/our/this/ or s/our X/the X described in this document/ This appears multiple 
times in section 9.


___
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: Last Call: (Micro-loop prevention by introducing a local convergence delay) to Proposed Standard

[stephane.litkowski]

I'm fine with that. It could fit in the deployment considerations section.
Do you want to propose a short text ?

-Original Message-
From: Stewart Bryant [mailto:stewart.bry...@gmail.com] 
Sent: Wednesday, September 27, 2017 12:15
To: LITKOWSKI Stephane OBS/OINIS; i...@ietf.org
Cc: rtgwg-cha...@ietf.org; akat...@gmail.com; 
draft-ietf-rtgwg-uloop-de...@ietf.org; rtgwg@ietf.org
Subject: Re: Last Call:  (Micro-loop 
prevention by introducing a local convergence delay) to Proposed Standard


Yes, I admit it is tricky, but I think that we have to be honest with the 
reader, since as we both agree this only solves part of the problem.

Incremental metrics is certainly one local solution that can be deployed, and 
if the metric of the link is low that need not take many cycles to complete.

The key point for me is that the text needs to describe the shortfall of the 
solution, and whilst ideally it should provide mitigation if it cannot do that, 
it needs to be clear on the consequences of not providing it so that those not 
schooled in the detail of IPFRR understand what will happen to their network 
when they deploy this.

Something that Benoit has been encouraging people to write for a while is an 
Operational  Considerations section, which would be an ideal place to put this 
discussion.

- Stewart



On 27/09/2017 09:19, stephane.litkow...@orange.com wrote:
> Hi Stewart,
>
> Thanks for your comment.
> Managing the link up is more tricky than the link down. We had a proposal to 
> tweak the flooding in the first versions of the draft but there was not a 
> good support of that as it touches an important component of the protocol, so 
> it was removed to keep the solution simple but yes it reduces the benefit.
>
> There is nothing that we can really do to prevent the impact of the link up. 
> Even if the operator implements an interface dampening mechanism to ensure 
> that the link is stable, the link will eventually goes up and may create a 
> microloop.
> Now keeping the link down until a quiet time is theorically doable but 
> practically it is not. When a link is down, there are two situations: the 
> operator has lost some capacity that leads to a congestion somewhere or if 
> there is no congestion, the network becomes at risk as if another component 
> fails, there will be not enough capacity. So practically, we want the link to 
> go back up as soon as possible.
>
> Other approaches like using "incremental" metrics may be used for the up case 
> to prevent the uloop.
>
>
> Brgds,
>
> -Original Message-
> From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
> Sent: Thursday, September 21, 2017 10:21
> To: i...@ietf.org
> Cc: rtgwg-cha...@ietf.org; akat...@gmail.com; 
> draft-ietf-rtgwg-uloop-de...@ietf.org; rtgwg@ietf.org
> Subject: Re: Last Call:  
> (Micro-loop prevention by introducing a local convergence delay) to 
> Proposed Standard
>
>
> The draft states that
>
> " The proposed mechanism is limited to the link down event in order to keep 
> the mechanism simple."
>
> Since a link that goes down will normally also come up again, the draft ought 
> to provide some guidance to the operator on how they should handle that 
> situation. Applications that care about the disruption caused by microloops 
> presumably have no care as to whether they are cause by link up or link down, 
> and so would prefer a complete elimination of that disruption. However I 
> accept that complete elimination has wider network impact and that this 
> approach which is really microloop mitigation has utility.
>
> The advice might be as simple as keeping the link out of service until a 
> quiet time, or the loss of connectivity has moved to the network to a state 
> of fragility such that disruption is acceptable.
>
> - Stewart
>
>
> On 20/09/2017 19:44, The IESG wrote:
>> The IESG has received a request from the Routing Area Working Group 
>> WG
>> (rtgwg) to consider the following document: - 'Micro-loop prevention 
>> by introducing a local convergence delay'
>>  as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits 
>> final comments on this action. Please send substantive comments to 
>> the i...@ietf.org mailing lists by 2017-10-04. Exceptionally, 
>> comments may be sent to i...@ietf.org instead. In either case, please 
>> retain the beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>  This document describes a mechanism for link-state routing protocols
>>  to prevent local transient forwarding loops in case of link failure.
>>  This mechanism proposes a two-step convergence by introducing a delay
>>  between the convergence of the node adjacent to the topology change
>>  and the network wide convergence.
>>
>>  As this mechanism delays the IGP convergence it may only be used for
>>  planned maintenance or when fast reroute protects the traffic between
>>  the link failure time and the IGP 

RE: Genart last call review of draft-ietf-rtgwg-uloop-delay-06

[stephane.litkowski]

Thanks I will fix it in the next revision


-Original Message-
From: Roni Even [mailto:ron.even@gmail.com] 
Sent: Wednesday, September 27, 2017 11:00
To: gen-...@ietf.org
Cc: draft-ietf-rtgwg-uloop-delay@ietf.org; i...@ietf.org; rtgwg@ietf.org
Subject: Genart last call review of draft-ietf-rtgwg-uloop-delay-06

Reviewer: Roni Even
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

.

Document: draft-ietf-rtgwg-uloop-delay-??
Reviewer: Roni Even
Review Date: 2017-09-27
IETF LC End Date: 2017-10-04
IESG Telechat date: 2017-10-12

Summary:
The document is ready for publication as a standard track RFC with nits

Major issues:

Minor issues:

Nits/editorial comments:

1. Abbreviation like RIB and FIB are not expanded 2. In section 9.1 "more 
simple" should be "simpler"
3. In section 9.1 " does not enough provide enough bandwidth"  to " does not 
provide enough bandwidth" 4. In section 9.2 "a mechanism where the convergence 
of the  network upon a topology change is made ordered to prevent transient 
forwarding loops"  is difficult to read maybe "a mechanism where the 
convergence of the network upon a topology change is ordered in order to 
prevent transient forwarding loops"



_

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: Last Call: (Micro-loop prevention by introducing a local convergence delay) to Proposed Standard

[stephane.litkowski]

Hi Stewart,

Thanks for your comment.
Managing the link up is more tricky than the link down. We had a proposal to 
tweak the flooding in the first versions of the draft but there was not a good 
support of that as it touches an important component of the protocol, so it was 
removed to keep the solution simple but yes it reduces the benefit.

There is nothing that we can really do to prevent the impact of the link up. 
Even if the operator implements an interface dampening mechanism to ensure that 
the link is stable, the link will eventually goes up and may create a microloop.
Now keeping the link down until a quiet time is theorically doable but 
practically it is not. When a link is down, there are two situations: the 
operator has lost some capacity that leads to a congestion somewhere or if 
there is no congestion, the network becomes at risk as if another component 
fails, there will be not enough capacity. So practically, we want the link to 
go back up as soon as possible.

Other approaches like using "incremental" metrics may be used for the up case 
to prevent the uloop. 


Brgds,

-Original Message-
From: Stewart Bryant [mailto:stewart.bry...@gmail.com] 
Sent: Thursday, September 21, 2017 10:21
To: i...@ietf.org
Cc: rtgwg-cha...@ietf.org; akat...@gmail.com; 
draft-ietf-rtgwg-uloop-de...@ietf.org; rtgwg@ietf.org
Subject: Re: Last Call:  (Micro-loop 
prevention by introducing a local convergence delay) to Proposed Standard


The draft states that

" The proposed mechanism is limited to the link down event in order to keep the 
mechanism simple."

Since a link that goes down will normally also come up again, the draft ought 
to provide some guidance to the operator on how they should handle that 
situation. Applications that care about the disruption caused by microloops 
presumably have no care as to whether they are cause by link up or link down, 
and so would prefer a complete elimination of that disruption. However I accept 
that complete elimination has wider network impact and that this approach which 
is really microloop mitigation has utility.

The advice might be as simple as keeping the link out of service until a quiet 
time, or the loss of connectivity has moved to the network to a state of 
fragility such that disruption is acceptable.

- Stewart


On 20/09/2017 19:44, The IESG wrote:
> The IESG has received a request from the Routing Area Working Group WG
> (rtgwg) to consider the following document: - 'Micro-loop prevention 
> by introducing a local convergence delay'
> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits 
> final comments on this action. Please send substantive comments to the 
> i...@ietf.org mailing lists by 2017-10-04. Exceptionally, comments may 
> be sent to i...@ietf.org instead. In either case, please retain the 
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
> This document describes a mechanism for link-state routing protocols
> to prevent local transient forwarding loops in case of link failure.
> This mechanism proposes a two-step convergence by introducing a delay
> between the convergence of the node adjacent to the topology change
> and the network wide convergence.
>
> As this mechanism delays the IGP convergence it may only be used for
> planned maintenance or when fast reroute protects the traffic between
> the link failure time and the IGP convergence.
>
> The proposed mechanism is limited to the link down event in order to
> keep the mechanism simple.
>
> Simulations using real network topologies have been performed and
> show that local loops are a significant portion (>50%) of the total
> forwarding loops.
>
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-uloop-delay/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-uloop-delay/ballot/
>
> The following IPR Declarations may be related to this I-D:
>
> https://datatracker.ietf.org/ipr/2565/
>
>
>
>
>


_

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

RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

[stephane.litkowski]

Hi,

Thanks for your feedback, please find some comments inline.

Brgds,

Stephane


From: Sikhivahan Gundu [mailto:sikhivahan.gu...@ericsson.com]
Sent: Wednesday, August 09, 2017 12:19
To: LITKOWSKI Stephane OBS/OINIS; Chris Bowers
Cc: draft-ietf-rtgwg-uloop-de...@tools.ietf.org; RTGWG
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

Hi,

Requesting a couple of clarifications.

>> If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, 
>> ULOOP_DELAY_DOWN_TIMER is stopped

Do we stop the timer if  "new convergence" is a result only of links coming
up, i.e, no links have failed?  My interpretation of the old text,  as well as 
the
revision, is that we don't, but in the light of the discussion that this passage
triggered, it seems better to have the interpretation validated, as below:

[SLI] Let's that you have a convergence triggered by a local link down, this 
convergence will apply the ULOOP_DELAY_DOWN_TIMER.
If during the timer run, a new topology change occurs (metric change, link up 
or down whatever it is local or remote), we need to update the FIB without 
anymore delaying with the latest topology.
If we do not do so, the local router will use an N-2 FIB version while the 
other routers will start to use the latest version N this could cause side 
effects.


Imagining the IGP router to be in one of two states:
-- NORMAL-UPDATE state (FIB updated "normally"), also the initial state,
-- and DELAYED-UPDATE state (FIB updated after ULOOP_DELAY_TIMER units of time),

the draft seems to suggest the following state transitions. I'd greatly 
appreciate
validation.



---+--+-+

 current state|  event  
   | next state  |

---+--+-+

NORMAL-UPDATE|  
  | DELAYED-UPDATE |

---+  one local link failure
  +-+

DELAYED-UPDATE| 
   | NORMAL-UPDATE |

---+--+-+

NORMAL-UPDATE|  one remote link failure |   
|

---+OR  
 | NORMAL-UPDATE |

DELAYED-UPDATE|  two or more (any kind of) link failures   |
  |

---+--+-+

NORMAL-UPDATE|  
  | NORMAL-UPDATE |

---+   no link failures (only link-up's)   
+--+

DELAYED-UPDATE| 
   | DELAYED-UPDATE |

---+--+-+



[SLI] The last line should be current state DELAYED-UPDATE , next state 
NORMAL-UPDATE.





Second: remote loops are illustrated as a non-applicable scenario for this

solution. How about local link failures that do not lead to (local) loops?

Applying the delay in such a case may result in packet loss if there is no

FRR backup.  OTOH, detecting that a local loop will form  involves more

computation.



[SLI] I agree with you, that's why the draft encourages to use the mechanism in 
combination with FRR. The draft does not prevent an implementation to detect if 
a loop exists or not before applying the mechanism.





Thanks,

Sikhi


From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: 08 August 2017 20:50
To: Chris Bowers mailto:cbow...@juniper.net>>
Cc: 
draft-ietf-rtgwg-uloop-de...@tools.ietf.org;
 RTGWG mailto:rtgwg@ietf.org>>
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

Thanks Chris, I will post a new revision with those changes.


From: Chris Bowers [mailto:cbow...@juniper.net]
Sent: Tuesday, August 08, 2017 16:05
To: LITKOWSKI Stephane OBS/OINIS
Cc: RTGWG; 
draft-ietf-rtgwg-uloop-de...@tools.ietf.org
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

Stephane,

See responses inline with [CB].

Chris

From: stephane.litkow...@orange.com 
[mailto:stephane.litkow...@orange.com]
Sent: Tuesday, August 8, 2017 8:25 AM
To: Chris Bowers mailto:cbow...@juniper.ne

RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

[stephane.litkowski]

Thanks Chris, I will post a new revision with those changes.


From: Chris Bowers [mailto:cbow...@juniper.net]
Sent: Tuesday, August 08, 2017 16:05
To: LITKOWSKI Stephane OBS/OINIS
Cc: RTGWG; draft-ietf-rtgwg-uloop-de...@tools.ietf.org
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

Stephane,

See responses inline with [CB].

Chris

From: stephane.litkow...@orange.com 
[mailto:stephane.litkow...@orange.com]
Sent: Tuesday, August 8, 2017 8:25 AM
To: Chris Bowers mailto:cbow...@juniper.net>>
Cc: RTGWG mailto:rtgwg@ietf.org>>; 
draft-ietf-rtgwg-uloop-de...@tools.ietf.org
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

Hi Chris,

Thanks for the review. I'm updating the document to reflect your proposals.
Couple of comments:

-  s/"otherwise the standard IP convergence MUST be used."/ "otherwise 
the standard IP convergence MUST used". It does not sound good to me but may be 
because of an English grammar issue on my side. Could you confirm the change ?

[CB]  You are correct.  That proposed change is a mistake on my part.



-  Regarding your main comment on section 1 and 2.1, I do not agree 
about your statement on RSVP-FRR. First there are multiple deployment styles of 
RSVP FRR:

o   LDP tunneling

o   RSVP with no strict ERO

o   RSVP with CSPF at head end (strict ERO)
Your statement is true only for the third case where an RSVP tunnel between S 
and D exists with its path computed by S => no uloop in that case for sure. But 
as soon as you rely on distributed convergence, you will fall into a loop even 
if you use RSVP-FRR. I will precise in the text that we are in an LDP scenario 
for example. Here is a text proposal:
"In the Figure 2, we consider an IP/LDP routed network. An RSVP-TE tunnel T, 
provisioned on C and terminating on B, is used to protect the traffic against 
C-B link failure (IGP shortcut is activated on C)."
"The issue described here is completely independent of the fast-reroute 
mechanism involved (TE FRR, LFA/rLFA, MRT ...) when the primary path is an hop 
by hop defined path."


[CB] "when the primary path is an hop by hop defined path"  is somewhat 
ambiguous.
How about "when the primary path uses hop-by-hop routing" ?


For the LFA case, yes, there are some cases where there is no loop, but it is 
topology dependent. I'm not sure that we need to give such precision as if the 
LFA is on the postconvergence path, this means that the postconvergence is 
loopfree, so there will be no local microloop in any case.

[CB]  OK.


-  Regarding your comment on section 4.4, here is my new text proposal 
to fit your comment:

"Upon an adjacency/link down event, this document introduces a change
   in step 5 () in order to delay the local 
convergence compared to the
   network wide convergence. The new step 5 is described below:"
   5. Upon SPF_DELAY timer expiration, the SPF is computed. If the 
condition of a single local link-down event has been met and if the new 
convergence did not trigger a stop of the ULOOP_DELAY_DOWN_TIMER , then an 
update of the RIB and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER 
msecs. Otherwise, the RIB and FIB SHOULD be updated immediately.

If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, 
ULOOP_DELAY_DOWN_TIMER is stopped and the RIB/FIB SHOULD be updated as part of 
the new convergence event."

[CB]  This text seems clearer.

Brgds,

Stephane


From: Chris Bowers [mailto:cbow...@juniper.net]
Sent: Tuesday, August 08, 2017 03:01
To: LITKOWSKI Stephane OBS/OINIS; 
draft-ietf-rtgwg-uloop-de...@ietf.org
Cc: rtgwg@ietf.org
Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

Authors,

I'm in the process of doing the Shepherd write-up for 
draft-ietf-rtgwg-uloop-delay-05.txt.

In reading the latest version of the document, I wrote down some feedback.
A diff can be found at:
https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2017/commit/70f3fc5b2c89dc65f813b992921d685049a4a4bd

http://bit.ly/2vJqoq2

Most of the feedback is related to clarifying language and typos.  However there
are few comments that I think are more substantive so I am
reproducing them below since they should probably discussed on the list.

===
[CB]  I find the examples presented in section 1 and section 2.1 to
be confusing.  The conclusion drawn in the last paragraph of section
2.1 does not seem to follow from these examples.

Section 1 (figure 1) shows an example of micro-loops occuring when shortest
path forwarding is used and the metrics are such that LFA and rLFA
produce no backup paths from the PLR.

Section 2.1 (figure 2) also shows an example of micro-loops occuring when
shortest path forwarding is used and the metrics are such that LFA and rLFA
produce no backup paths

RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

[stephane.litkowski]

Hi Chris,

Thanks for the review. I'm updating the document to reflect your proposals.
Couple of comments:

-  s/"otherwise the standard IP convergence MUST be used."/ "otherwise 
the standard IP convergence MUST used". It does not sound good to me but may be 
because of an English grammar issue on my side. Could you confirm the change ?



-  Regarding your main comment on section 1 and 2.1, I do not agree 
about your statement on RSVP-FRR. First there are multiple deployment styles of 
RSVP FRR:

o   LDP tunneling

o   RSVP with no strict ERO

o   RSVP with CSPF at head end (strict ERO)
Your statement is true only for the third case where an RSVP tunnel between S 
and D exists with its path computed by S => no uloop in that case for sure. But 
as soon as you rely on distributed convergence, you will fall into a loop even 
if you use RSVP-FRR. I will precise in the text that we are in an LDP scenario 
for example. Here is a text proposal:
"In the Figure 2, we consider an IP/LDP routed network. An RSVP-TE tunnel T, 
provisioned on C and terminating on B, is used to protect the traffic against 
C-B link failure (IGP shortcut is activated on C)."
"The issue described here is completely independent of the fast-reroute 
mechanism involved (TE FRR, LFA/rLFA, MRT ...) when the primary path is an hop 
by hop defined path."

For the LFA case, yes, there are some cases where there is no loop, but it is 
topology dependent. I'm not sure that we need to give such precision as if the 
LFA is on the postconvergence path, this means that the postconvergence is 
loopfree, so there will be no local microloop in any case.




-  Regarding your comment on section 4.4, here is my new text proposal 
to fit your comment:

"Upon an adjacency/link down event, this document introduces a change
   in step 5 () in order to delay the local 
convergence compared to the
   network wide convergence. The new step 5 is described below:"
   5. Upon SPF_DELAY timer expiration, the SPF is computed. If the 
condition of a single local link-down event has been met and if the new 
convergence did not trigger a stop of the ULOOP_DELAY_DOWN_TIMER , then an 
update of the RIB and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER 
msecs. Otherwise, the RIB and FIB SHOULD be updated immediately.

If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, 
ULOOP_DELAY_DOWN_TIMER is stopped and the RIB/FIB SHOULD be updated as part of 
the new convergence event."

Brgds,

Stephane


From: Chris Bowers [mailto:cbow...@juniper.net]
Sent: Tuesday, August 08, 2017 03:01
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-rtgwg-uloop-de...@ietf.org
Cc: rtgwg@ietf.org
Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

Authors,

I'm in the process of doing the Shepherd write-up for 
draft-ietf-rtgwg-uloop-delay-05.txt.

In reading the latest version of the document, I wrote down some feedback.
A diff can be found at:
https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2017/commit/70f3fc5b2c89dc65f813b992921d685049a4a4bd

http://bit.ly/2vJqoq2

Most of the feedback is related to clarifying language and typos.  However there
are few comments that I think are more substantive so I am
reproducing them below since they should probably discussed on the list.

===
[CB]  I find the examples presented in section 1 and section 2.1 to
be confusing.  The conclusion drawn in the last paragraph of section
2.1 does not seem to follow from these examples.

Section 1 (figure 1) shows an example of micro-loops occuring when shortest
path forwarding is used and the metrics are such that LFA and rLFA
produce no backup paths from the PLR.

Section 2.1 (figure 2) also shows an example of micro-loops occuring when
shortest path forwarding is used and the metrics are such that LFA and rLFA
produce no backup paths from the PLR.  However, in this example,
a one-hop RSVP tunnel is provisioned to provide link protection for one of
the links.  However, even with this one-hop RSVP tunnel the example
demonstrates that micro-loops can occur.

The last paragraph asserts that:
"The issue described here is completely independent of the fast-
reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...)."

There are two problems with this assertion.

Problem 1) I don't think that the assertion is correct for RSVP TE-FRR in 
general.

For classical RSVP TE-FRR, there would be an RSVP-signaled LSP from S to D.
Before the failure of the link C-B, this LSP would follow the path
S-E-C-B-A-D.  Immediately after the failure of link C-B, the LSP would
follow the path S-E-C-E-A-B-A-D using the bypass LSP at C.  Once S is
made aware of the failure.  S will resignal the LSP to take the path S-E-A-D.
At no time would looping occur.

I assume that it wasn't the initial intention to claim that RSVP TE-FRR suffers 
from
micro-looping, but the text currently reads that way.  The assertion of the last
paragraph should be qualified to ta

RE: WG last call for draft-ietf-rtgwg-uloop-delay

[stephane.litkowski]

In addition, I'm not aware of any non disclosed IPR.


From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, June 06, 2017 08:53
To: Chris Bowers; RTGWG
Subject: RE: WG last call for draft-ietf-rtgwg-uloop-delay

Support as author

From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Chris Bowers
Sent: Friday, June 02, 2017 22:43
To: RTGWG
Subject: WG last call for draft-ietf-rtgwg-uloop-delay

RTGWG,

This email starts the two week WG last call for draft-ietf-rtgwg-uloop-delay.

https://datatracker.ietf.org/doc/draft-ietf-rtgwg-uloop-delay/

Please indicate support for or opposition to the publication of this
standards track document, along with the reasoning for 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.

The document currently has the following IPR disclosure associated
with it.
https://datatracker.ietf.org/ipr/2565/

This last call will end on Friday June 16th.

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.

_

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-uloop-delay

[stephane.litkowski]

Support as author

From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Chris Bowers
Sent: Friday, June 02, 2017 22:43
To: RTGWG
Subject: WG last call for draft-ietf-rtgwg-uloop-delay

RTGWG,

This email starts the two week WG last call for draft-ietf-rtgwg-uloop-delay.

https://datatracker.ietf.org/doc/draft-ietf-rtgwg-uloop-delay/

Please indicate support for or opposition to the publication of this
standards track document, along with the reasoning for 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.

The document currently has the following IPR disclosure associated
with it.
https://datatracker.ietf.org/ipr/2565/

This last call will end on Friday June 16th.

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: RTGWG adoption of draft-rtgyangdt-rtgwg-routing-types

[stephane.litkowski]

Support

From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Wednesday, November 30, 2016 23:15
To: RTGWG
Cc: draft-rtgyangdt-rtgwg-routing-ty...@tools.ietf.org; 'rtgwg-chairs'
Subject: RTGWG adoption of draft-rtgyangdt-rtgwg-routing-types

Dear RTGWG,

The authors have requested the RTGWG to adopt 
draft-rtgyangdt-rtgwg-routing-types.
The draft has been presented in Seoul, and found of interest for wg.

Please indicate support or no-support by December 15, 2016.

IPR:
If you are listed as a document author or contributor, please respond to this 
email.
of 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.


Thanks,
Jeff & Chris

_

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: I-D Action: draft-ietf-rtgwg-uloop-delay-03.txt

[stephane.litkowski]

Hi,

This is mostly a refresh of the draft due to pending expiration.
I fixed some nits, typos... also.

Brgds,

-Original Message-
From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Tuesday, November 29, 2016 11:37
To: i-d-annou...@ietf.org
Cc: rtgwg@ietf.org
Subject: I-D Action: draft-ietf-rtgwg-uloop-delay-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Area Working Group of the IETF.

Title   : Micro-loop prevention by introducing a local 
convergence delay
Authors : Stephane Litkowski
  Bruno Decraene
  Clarence Filsfils
  Pierre Francois
Filename: draft-ietf-rtgwg-uloop-delay-03.txt
Pages   : 22
Date: 2016-11-29

Abstract:
   This document describes a mechanism for link-state routing protocols
   to prevent local transient forwarding loops in case of link failure.
   This mechanism proposes a two-steps convergence by introducing a
   delay between the convergence of the node adjacent to the topology
   change and the network wide convergence.

   As this mechanism delays the IGP convergence it may only be used for
   planned maintenance or when fast reroute protects the traffic between
   the link failure time and the IGP convergence.

   The proposed mechanism will be limited to the link down event in
   order to keep simplicity.

   Simulations using real network topologies have been performed and
   show that local loops are a significant portion (>50%) of the total
   forwarding loops.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-uloop-delay/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtgwg-uloop-delay-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-uloop-delay-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

_

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: question about draft-ietf-rtgwg-uloop-delay-02

[stephane.litkowski]

Hi Stewart,

For link down, we easily see the improvement as uloops were breaking FRR 
sometimes and now we do not see anymore breakage (traffic initiated from a 
probe connected to PLR).
For link up, we observed some traffic disruption in some cases but there is no 
tool to ensure that it comes from a microloop or something else: but the 
affected paths were subject to microloops (from theorical point of view) upon 
link up event of the failed link.
There is a clear lack of accurate tools today to identity microloops in live 
networks: having probes sending traffic at high rate is not enough, on labs we 
have analyzers to check packet TTL, but it's impossible to use in a live 
network for unplanned events ...

Brgds,

Stephane

From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
Sent: Thursday, October 20, 2016 14:52
To: LITKOWSKI Stephane OBS/OINIS; peng.sha...@zte.com.cn
Cc: chen.mi...@zte.com.cn; rtgwg@ietf.org
Subject: Re: question about draft-ietf-rtgwg-uloop-delay-02




On 20/10/2016 13:33, 
stephane.litkow...@orange.com wrote:
Hi,

Achieving link up microloop avoidance with a local mechanism is only achievable 
by tweaking flooding (we need to converge locally, then flood local LSP update) 
which was not well received by the WG, that's why it was removed. The draft 
focus now on what has already been implemented by vendors and deployed in live 
networks.

If it is in live networks, can you share with us how well it works, and what, 
if any, disruption you see under link up.



Some other solutions like SR microloop avoidance will provide link up case at 
the "price" of having a SR-enabled network.

You can do link up with SR, but SR is not required by all methods.

Stewart



Brgds,

From: peng.sha...@zte.com.cn 
[mailto:peng.sha...@zte.com.cn]
Sent: Thursday, October 20, 2016 11:03
To: LITKOWSKI Stephane OBS/OINIS
Cc: rtgwg@ietf.org; 
chen.mi...@zte.com.cn
Subject: question about draft-ietf-rtgwg-uloop-delay-02

Hi Stephane,

I find that section "4.4.2.  Link up event" of 
draft-litkowski-rtgwg-uloop-delay-04 has been removed.
Does it mean that there is no need for this?

Thanks,
Deccan

_



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


_

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: question about draft-ietf-rtgwg-uloop-delay-02

[stephane.litkowski]

Hi,

Achieving link up microloop avoidance with a local mechanism is only achievable 
by tweaking flooding (we need to converge locally, then flood local LSP update) 
which was not well received by the WG, that's why it was removed. The draft 
focus now on what has already been implemented by vendors and deployed in live 
networks.

Some other solutions like SR microloop avoidance will provide link up case at 
the "price" of having a SR-enabled network.

Brgds,

From: peng.sha...@zte.com.cn [mailto:peng.sha...@zte.com.cn]
Sent: Thursday, October 20, 2016 11:03
To: LITKOWSKI Stephane OBS/OINIS
Cc: rtgwg@ietf.org; chen.mi...@zte.com.cn
Subject: question about draft-ietf-rtgwg-uloop-delay-02

Hi Stephane,

I find that section "4.4.2.  Link up event" of 
draft-litkowski-rtgwg-uloop-delay-04 has been removed.
Does it mean that there is no need for this?

Thanks,
Deccan

_

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: Rtg Area Directorate QA review of draft-ietf-rtwg-uloop-delay-02.txt

[stephane.litkowski]

Hi Matthew,

I will take care of your comments as soon as possible.

Thanks,


From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia 
- GB)
Sent: Wednesday, September 28, 2016 12:23
To: draft-ietf-rtgwg-uloop-de...@tools.ietf.org
Cc: rtgwg-cha...@tools.ietf.org; rtgwg@ietf.org
Subject: Rtg Area Directorate QA review of draft-ietf-rtwg-uloop-delay-02.txt

Authors,

I have been asked to do a Routing Area Directorate QA review of 
draft-ietf-rtwg-uloop-delay-02.txt



Summary:

The rationale for this document is clear and the mechanism seems reasonably 
straight forward. However, one major comment that I have is that the English 
grammar is poor in some sections, and it is missing normal English articles in 
some places (a, an, the,…), making it hard to read. I would suggest that the 
authors go through the draft with a native English speaker to help resolve 
these nits.


Comments:

Minor Issues:

Section 2.1 Fast reroute unefficiency
s/unefficiency/inefficiency

Section 4.1 Definitions, 2nd bullet:
…by incrementing the timer vape when the IGP is instable.
s/instable/unstable

4.3 Local Events
The draft states that it assumes that only a single link failure has been seen 
by the IGP area. However, its not clear how you distinguish a single local 
failure from consecutive (non-simultaneous) failure that occurs within a given 
short timespan e.g. during the initial re-convergence period. It would help to 
clarify this.

Regards

Matthew

_

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

REMINDER : Shepherd's review of draft-ietf-spring-resiliency-use-cases

[stephane.litkowski]

Hi Authors,

Could you please check the comment's below so we can continue to progress the 
document ?

Thanks !

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, August 22, 2016 15:14
To: draft-ietf-spring-resiliency-use-ca...@ietf.org
Cc: spr...@ietf.org; rtgwg@ietf.org
Subject: [spring] Shepherd review of draft-oetf-spring-resiliency-use-cases

Hi,

I have been selected as Shepherd for this document, and as part of my review I 
have several comments that you will find below :

General :
Is it a requirement document ? If yes, it would be good to mention it. The 
document states requirements multiple times.


Abstract :
The abstract is really short, would be good to enhance it with what is exactly 
described.

In Section 1, there should be an issue with the XML file as the hypertext link 
is missing at : "We discuss two different approaches to provide ..., in Section 
3". Hyperlink missing for "Section 3".

In Section 2,
It would be good to state in the example that the paths must not be protected 
by any local repair techniques. Example : "The two paths are made disjoint 
using the SPRING architecture and must not be protected by any local repair 
techniques".

As a requirement, the two paths must be disjoint (link or node, or srlg), this 
has some impacts on the path expression : using a node-SID would be a bad idea 
as there is no guarantee. It would be good to mention that the solution must 
take care of this.

It would be easier to state that path T1 is primary and T2 is backup instead of 
: "When T1 is  up, the packets of the PW are sent on T1".
Why not using the following text :
"T1 is programmed as primary forwarding entry while T2 is a backup entry. In 
nominal state, PW traffic is carried over T1. When T1 fails, the PW traffic is 
switched on T2".
Before telling that the solution for end-to-end liveness is out of scope, it 
would be good to state that it is mandatory to have such mechanism to make the 
solution work. Is it a SPRING path liveness check or service liveness check ?  
It would be good to tell who is in charge of the detection and path switchover 
? is it LSP ingress, is it a node outside SPRING network ? If there are 
multiple options, please tell it.

I would propose to change the last sentence to highlight the two requirements 
in case we need SPRING path liveness check :
"From a SPRING viewpoint, the SPRING architecture MUST provide end-to-end 
liveness check of SPRING based LSPs. In addition, it MUST provide a way to 
create LSPs that must not be protected by local repair techniques."

Globally this section looks confusing to me. End to end protection could be 
achieved in multiple ways, for example :
- Having a dumb network that only provides disjoint non protected path and 
having end-to-end probes at service level that would help an external component 
to switchover traffic. Provider network is not aware of the protection done. In 
your figure we can add A' and Z', and we establish two disjoint LSPs (A->Z and 
A'->Z'). Customer is dual meshed to A/A' and Z/Z' and is managing liveness 
check and switchover (network is not involved).
- Having primary/backup like approach : two disjoint LSPs from A->Z , A 
programs one in FIB. A provides OAM on the LSP. When primary LSP fails, the 
second one is installed in FIB.
- Having FRR like approach : two disjoint LSPs from A->Z , A programs both in 
FIB in a FRR like fashion. A provides aggressive OAM on the LSPs to enable 
traffic switchover in a very short time.

The current text is not really clear on the proposed approach. Maybe another 
one ?


Section 3
s/the backup path computation should/the backup path computation SHOULD/
s/in any topology/in any topology./
s/by the IGP/by the IGP./

Section 3.1
"ending at the protected nexthop", that's true only for link protection, but 
not possible in case of node protection. This sentence is a generic one and is 
not specific to link protection case.
I cannot parse : "so as to bypass the failed component ..."
I would propose something like :
"One way to provide local repair is to enforce a failover along the shortest 
path around the protected component. In case of link protection,  the point of 
local repair will create a bypass avoiding the protected link and merging back 
to primary path at the nexthop. In case of node protection, the bypass will 
avoid the protected node and merge back to primary path at the next-nexthop."
What about SRLG case ?

"In our example, C protects Z", protects for what ? link / node /srlg failure ? 
proposed text : "In our example, C protects destination Z for a failure CD link"

"that it initially reaches via CD", yes and also using CH because of ECMP, it 
would be better to change the example to disable ECMP. There are multiple ECMPs 
that would not help the reading. Even A as ECMP to Z.


Section 3.2
"providing a repair for the destination based on shortest path state for that 
destination". Why using "s

Shepherd review of draft-oetf-spring-resiliency-use-cases

[stephane.litkowski]

Hi,

I have been selected as Shepherd for this document, and as part of my review I 
have several comments that you will find below :

General :
Is it a requirement document ? If yes, it would be good to mention it. The 
document states requirements multiple times.


Abstract :
The abstract is really short, would be good to enhance it with what is exactly 
described.

In Section 1, there should be an issue with the XML file as the hypertext link 
is missing at : "We discuss two different approaches to provide ..., in Section 
3". Hyperlink missing for "Section 3".

In Section 2,
It would be good to state in the example that the paths must not be protected 
by any local repair techniques. Example : "The two paths are made disjoint 
using the SPRING architecture and must not be protected by any local repair 
techniques".

As a requirement, the two paths must be disjoint (link or node, or srlg), this 
has some impacts on the path expression : using a node-SID would be a bad idea 
as there is no guarantee. It would be good to mention that the solution must 
take care of this.

It would be easier to state that path T1 is primary and T2 is backup instead of 
: "When T1 is  up, the packets of the PW are sent on T1".
Why not using the following text :
"T1 is programmed as primary forwarding entry while T2 is a backup entry. In 
nominal state, PW traffic is carried over T1. When T1 fails, the PW traffic is 
switched on T2".
Before telling that the solution for end-to-end liveness is out of scope, it 
would be good to state that it is mandatory to have such mechanism to make the 
solution work. Is it a SPRING path liveness check or service liveness check ?  
It would be good to tell who is in charge of the detection and path switchover 
? is it LSP ingress, is it a node outside SPRING network ? If there are 
multiple options, please tell it.

I would propose to change the last sentence to highlight the two requirements 
in case we need SPRING path liveness check :
"From a SPRING viewpoint, the SPRING architecture MUST provide end-to-end 
liveness check of SPRING based LSPs. In addition, it MUST provide a way to 
create LSPs that must not be protected by local repair techniques."

Globally this section looks confusing to me. End to end protection could be 
achieved in multiple ways, for example :
- Having a dumb network that only provides disjoint non protected path and 
having end-to-end probes at service level that would help an external component 
to switchover traffic. Provider network is not aware of the protection done. In 
your figure we can add A' and Z', and we establish two disjoint LSPs (A->Z and 
A'->Z'). Customer is dual meshed to A/A' and Z/Z' and is managing liveness 
check and switchover (network is not involved).
- Having primary/backup like approach : two disjoint LSPs from A->Z , A 
programs one in FIB. A provides OAM on the LSP. When primary LSP fails, the 
second one is installed in FIB.
- Having FRR like approach : two disjoint LSPs from A->Z , A programs both in 
FIB in a FRR like fashion. A provides aggressive OAM on the LSPs to enable 
traffic switchover in a very short time.

The current text is not really clear on the proposed approach. Maybe another 
one ?


Section 3
s/the backup path computation should/the backup path computation SHOULD/
s/in any topology/in any topology./
s/by the IGP/by the IGP./

Section 3.1
"ending at the protected nexthop", that's true only for link protection, but 
not possible in case of node protection. This sentence is a generic one and is 
not specific to link protection case.
I cannot parse : "so as to bypass the failed component ..."
I would propose something like :
"One way to provide local repair is to enforce a failover along the shortest 
path around the protected component. In case of link protection,  the point of 
local repair will create a bypass avoiding the protected link and merging back 
to primary path at the nexthop. In case of node protection, the bypass will 
avoid the protected node and merge back to primary path at the next-nexthop."
What about SRLG case ?

"In our example, C protects Z", protects for what ? link / node /srlg failure ? 
proposed text : "In our example, C protects destination Z for a failure CD link"

"that it initially reaches via CD", yes and also using CH because of ECMP, it 
would be better to change the example to disable ECMP. There are multiple ECMPs 
that would not help the reading. Even A as ECMP to Z.


Section 3.2
"providing a repair for the destination based on shortest path state for that 
destination". Why using "state" ?
Again : "In our example, C protects Z", protects for what ? link / node /srlg 
failure ?

You have again ECMP starting from A, and at other nodes that complexifies the 
example.

Why not talking about pros/cons between approaches ?


Section 4.
SRLG was mentioned as a requirement in Section 3. So why considering it as a 
more high level constraint ?
If SRLG is management-free, please change you

RE: working group adoption call for draft-liu-rtgwg-yang-vrrp

[stephane.litkowski]

support

From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, June 10, 2016 17:12
To: RTGWG
Cc: rtgwg-chairs; draft-liu-rtgwg-yang-v...@ietf.org
Subject: working group adoption call for draft-liu-rtgwg-yang-vrrp

Dear RTGWG,

The authors have requested the RTGWG to adopt:
draft-liu-rtgwg-yang-vrrp as working group document.

There was good support during the last IETF meeting.
Please indicate support or no-support by June 24th, 2016.

If you are listed as a document author or contributor, please respond to this 
email stating of 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.

Thanks,
Jeff & Chris


_

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: working group adoption call for draft-rtgyangdt-rtgwg-device-model; draft-rtgyangdt-rtgwg-lne-model and draft-rtgyangdt-rtgwg-ni-model

[stephane.litkowski]

+1

From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Tuesday, June 07, 2016 23:13
To: RTGWG
Subject: working group adoption call for draft-rtgyangdt-rtgwg-device-model; 
draft-rtgyangdt-rtgwg-lne-model and draft-rtgyangdt-rtgwg-ni-model

Dear RTGWG,

The authors have requested the RTGWG to adopt:
draft-rtgyangdt-rtgwg-device-model;  draft-rtgyangdt-rtgwg-lne-model and 
draft-rtgyangdt-rtgwg-ni-model as working group documents.

There was good support during the last IETF meeting.
Please indicate support or no-support by June 22nd, 2016.

If you are listed as a document author or contributor please respond to this 
email stating of 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.

Thanks,

Jeff & Chris


_

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: WGLC on draft-ietf-rtgwg-rlfa-node-protection

[stephane.litkowski]

+1

From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Tuesday, May 03, 2016 05:10
To: RTGWG
Cc: rtgwg-chairs
Subject: WGLC on draft-ietf-rtgwg-rlfa-node-protection

Dear RTGWG,

The authors of draft-ietf-rtgwg-rlfa-node-protection have told us that the
draft is ready for working group last call (WGLC).

This email is to start  the Working Group Last Call (WGLC) for 
draft-ietf-rtgwg-rlfa-node-protection.
This call will close by Monday, May 16.
Please provide your feedback whether you support (or not) the advancement of 
this draft.

Thanks,
Jeff and Chris

_

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: WGLC on draft-ietf-rtgwg-rlfa-node-protection

[stephane.litkowski]

I am not aware of IPR other than those in the two disclosures below.


From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Thursday, April 21, 2016 09:42
To: rtgwg@ietf.org
Cc: rtgwg-chairs
Subject: WGLC on draft-ietf-rtgwg-rlfa-node-protection

Dear RTGWG,

The authors of draft-ietf-rtgwg-rlfa-node-protection have told us that the
draft is ready for working group last call (WGLC).

Before we do the WGLC we want to do an IPR poll on the document.

This mail starts that IPR poll.

Are you aware of any IPR that applies to draft-ietf-rtgwg-rlfa-node-protection?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

Currently there are two IPR disclosures on 
draft-psarkar-rtgwg-rlfa-node-protection
(which was the pre-working group version of 
draft-ietf-rtgwg-rlfa-node-protection):
https://datatracker.ietf.org/ipr/2334/
https://datatracker.ietf.org/ipr/2346/

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. *The response needs to be sent to the MPLS wg mailing list.* The
document will not advance to the next stage until a response has been
received from each author and contributor.

If you are on the RTGWG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any
IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Jeff and Chris

_

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: progressing draft-ietf-rtgwg-backoff-algo

[stephane.litkowski]

Hi Chairs,

Can we move forward at least the associated problem statement draft ?

Best Regards,

Stephane

From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Chris Bowers
Sent: Wednesday, March 02, 2016 00:34
To: rtgwg@ietf.org
Subject: progressing draft-ietf-rtgwg-backoff-algo

RTGWG,

Jeff and I wanted to get a sense of how the working group would like to proceed 
regarding draft-ietf-rtgwg-backoff-algo.

The basic question for the working group is:   Should we proceed towards 
publication of the draft more or less as is, or should we wait to incorporate 
feedback from one or more implementations of the SPF back-off algorithm?

As far as we know, there haven't been any implementations of the proposed SPF 
back-off algorithm.  It would be good to get an understanding if any 
implementations are in progress or planned.

The common SPF back-off algorithm proposed in the document seems quite 
reasonable.  However, it is also quite possible that a single implementation 
would uncover some unforeseen issues or suggest improvements for the 
functioning of the algorithm in a single vendor network.  Testing with two or 
more implementations may provide feedback to improve the algorithm with respect 
to the goal of having common SPF delays in a multi-vendor network.  But we 
won't know until that work is done.

If there are implementations in progress or planned, then we think it would be 
worth waiting to incorporate feedback from those implementations before 
publishing.

Instead, if there are no implementations planned, we have several options.  We 
can proceed towards publication more or less as is, with WG last call in the 
near future.  Or we can explicitly decide to wait to publish the document, 
leaving it either as an active WG document or as a parked WG document, and wait 
for one or more implementations.  With the last option, we could leave open the 
option of publishing at some point in the future, even if no implementations 
appear.

Personally, I am quite hopeful that there will be at least prototype 
implementations in the not too distant future.  While it is very unlikely that 
a vendor would change their default SPF back-off algorithm to this new 
algorithm, it can easily be implemented with a knob to activate this algorithm. 
  This gives a simple way to try out the new algorithm incrementally, lowering 
the bar significantly for at least a prototype implementation.

We look forward to hearing feedback from the WG on how to proceed with the 
draft.

Thanks,
Chris



_

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: progress of draft-ietf-rtgwg-uloop-delay

[stephane.litkowski]

Hi,

Incremental cost change works fine (it has some drawbacks also => takes time), 
but is a completely different solution (not local delay based) which is already 
described (partially) in RFC5715.
If we go to remove the current link up proposal (delaying flooding), we can 
point to proposed solution in RFC5715 without redescribing them or pushing one 
or the other.

Best Regards,

Stephane

From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
Sent: Thursday, March 03, 2016 13:00
To: LITKOWSKI Stephane OBS/OINIS; Jeff Tantsura; Routing WG
Subject: Re: progress of draft-ietf-rtgwg-uloop-delay

Stephane

Would some coarse increment version of incremental cost change
be an appropriate compromise approach for link up?

Stewart
On 03/03/2016 10:57, 
stephane.litkow...@orange.com wrote:
Hi Jeff,

There is two existing implementations of the link down.
Based on the feedback from my testing, I need to update the draft to be more 
clear on the behavior when remote LSP is received before local detection 
happens. That's on my task list.

For the link up , there was some feedback that tweaking the flooding machinery 
as a bad idea.

One option may be to remove the link up.

Best Regards,


From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Wednesday, March 02, 2016 20:06
To: Routing WG
Subject: progress of draft-ietf-rtgwg-uloop-delay

Hi RTGWG,

Chris and I wanted to get a sense of how the working group would like to 
proceed regarding  draft-ietf-rtgwg-uloop-delay
For sake of simplicity - anyplace further in the email - any changes to  
proposed to the existing IGP timers behavior by uloop-delay draft will be 
called - "uloop-delay algorithm"

The basic question for the working group is:   Should we proceed towards 
publication of the draft more or less as is, or should we wait to incorporate 
feedback from one or more implementations of the uloop-delay algorithm?

As far as we know, there haven't been any implementations of the proposed 
uloop-delay algorithm.  It would be good to get an understanding if any 
implementations are in progress or planned.

The uloop-delay algorithm proposed in the document seems quite reasonable.  
However, it is also quite possible that a single implementation would uncover 
some unforeseen issues or suggest improvements for the functioning of the 
algorithm in a single vendor network.  Testing with two or more implementations 
may provide feedback to improve the algorithm with respect to the goal of 
having common uloop-delay timers in a multi-vendor network.  But we won't know 
until that work is done.

If there are implementations in progress or planned, then we think it would be 
worth waiting to incorporate feedback from those implementations before 
publishing.

Instead, if there are no implementations planned, we have several options.  We 
can proceed towards publication more or less as is, with WG last call in the 
near future.  Or we can explicitly decide to wait to publish the document, 
leaving it either as an active WG document or as a parked WG document, and wait 
for one or more implementations.  With the last option, we could leave open the 
option of publishing at some point in the future, even if no implementations 
appear.

Personally, I am quite hopeful that there will be at least prototype 
implementations in the not too distant future.  While it is very unlikely that 
a vendor would change their defaults, it can easily be implemented with a knob 
to activate this algorithm.   This gives a simple way to try out the new 
algorithm incrementally, lowering the bar significantly for at least a 
prototype implementation.

We look forward to hearing feedback from the WG on how to proceed with the 
draft.

Cheers,
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: progress of draft-ietf-rtgwg-uloop-delay

[stephane.litkowski]

Hi Jeff,

There is two existing implementations of the link down.
Based on the feedback from my testing, I need to update the draft to be more 
clear on the behavior when remote LSP is received before local detection 
happens. That’s on my task list.

For the link up , there was some feedback that tweaking the flooding machinery 
as a bad idea.

One option may be to remove the link up.

Best Regards,


From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Wednesday, March 02, 2016 20:06
To: Routing WG
Subject: progress of draft-ietf-rtgwg-uloop-delay

Hi RTGWG,

Chris and I wanted to get a sense of how the working group would like to 
proceed regarding  draft-ietf-rtgwg-uloop-delay
For sake of simplicity – anyplace further in the email - any changes to  
proposed to the existing IGP timers behavior by uloop–delay draft will be 
called - "uloop–delay algorithm"

The basic question for the working group is:   Should we proceed towards 
publication of the draft more or less as is, or should we wait to incorporate 
feedback from one or more implementations of the uloop-delay algorithm?

As far as we know, there haven't been any implementations of the proposed 
uloop-delay algorithm.  It would be good to get an understanding if any 
implementations are in progress or planned.

The uloop-delay algorithm proposed in the document seems quite reasonable.  
However, it is also quite possible that a single implementation would uncover 
some unforeseen issues or suggest improvements for the functioning of the 
algorithm in a single vendor network.  Testing with two or more implementations 
may provide feedback to improve the algorithm with respect to the goal of 
having common uloop-delay timers in a multi-vendor network.  But we won't know 
until that work is done.

If there are implementations in progress or planned, then we think it would be 
worth waiting to incorporate feedback from those implementations before 
publishing.

Instead, if there are no implementations planned, we have several options.  We 
can proceed towards publication more or less as is, with WG last call in the 
near future.  Or we can explicitly decide to wait to publish the document, 
leaving it either as an active WG document or as a parked WG document, and wait 
for one or more implementations.  With the last option, we could leave open the 
option of publishing at some point in the future, even if no implementations 
appear.

Personally, I am quite hopeful that there will be at least prototype 
implementations in the not too distant future.  While it is very unlikely that 
a vendor would change their defaults, it can easily be implemented with a knob 
to activate this algorithm.   This gives a simple way to try out the new 
algorithm incrementally, lowering the bar significantly for at least a 
prototype implementation.

We look forward to hearing feedback from the WG on how to proceed with the 
draft.

Cheers,
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: [Rtg-dt-yang-arch] Fwd: I-D Action: draft-rtgyangdt-rtgwg-device-model-03.txt

[stephane.litkowski]

Hi Lou,

>From a high level perspective, schema mount looks really good in term of 
>simplification. I went to the draft quickly (very quickly), and I may see an 
>issue.
Let's take the example of LNE, LNE may not have the exact same configuration 
statements as the physical host, as example some HW specific parameters that 
can only be configured on the physical host. In this case, when you mount the 
model into LNE, we need the ability to prune some subtree of the mounted tree. 
This pruning capacity does not seem to be taken into account yet.

Thoughts ?

Best Regards,

Stephane



-Original Message-
From: Rtg-dt-yang-arch [mailto:rtg-dt-yang-arch-boun...@ietf.org] On Behalf Of 
Lou Berger
Sent: Wednesday, February 24, 2016 03:40
To: Routing WG
Cc: Routing Area YANG Architecture DT
Subject: [Rtg-dt-yang-arch] Fwd: I-D Action: 
draft-rtgyangdt-rtgwg-device-model-03.txt


Hello,
This draft has been updated to use an emerging yang  capability called 
'schema-mount' [1] which translates to a significant simplification.  To quote 
the draft:

   Schema Mount enables a dramatic simplification of the presented
   device model, particularly for "lower-end" devices which are unlikely
   to support multiple network instances or logical network elements.
   Should structural-mount/YSDL not be available, the more explicit tree
   structure presented in earlier versions of this document will need to
   be utilized.

As it looks like there will soon be a netmod WG draft on schema mount, we think 
it's time to ask the WG to consider adopting our draft as a RTG WG draft.

[1] There was a netmod interim on schema mount on Monday, see
http://etherpad.tools.ietf.org:9000/p/netmod-interim-20160222

Our slides from that meeting are available at 
https://www.ietf.org/proceedings/interim/2016/02/22/netmod/slides/slides-interim-2016-netmod-1-1.pptx
and it gives a brief overview of the current draft.

Lou (and co-authors)
 Forwarded Message 
Subject:I-D Action: draft-rtgyangdt-rtgwg-device-model-03.txt
Date:   Tue, 23 Feb 2016 18:29:51 -0800
From:   internet-dra...@ietf.org
Reply-To:   internet-dra...@ietf.org
To: i-d-annou...@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Network Device YANG Organizational Models
Authors : Acee Lindem
  Lou Berger
  Dean Bogdanovic
  Christan Hopps
Filename: draft-rtgyangdt-rtgwg-device-model-03.txt
Pages   : 36
Date: 2016-02-23

Abstract:
   This document presents an approach for organizing YANG models in a
   comprehensive structure that may be used to configure and operate
   network devices.  The structure is itself represented as a YANG
   model, with all of the related component models logically organized
   in a way that is operationally intuitive, but this model is not
   expected to be implemented.  The identified component modules are
   expected to be defined and implemented on common network devices.

   This document also defines two modules that can be used to model the
   logical and virtual resource representations that may be present on a
   network device.  Examples of common industry terms for logical
   resource representations are Logical Systems or Routers.  Examples of
   of common industry terms for virtual resource representations are
   Virtual Routing and Forwarding (VRF) instances and Virtual Switch
   Instances (VSIs).

   This document is derived from work submitted to the IETF by members
   of the informal OpenConfig working group of network operators and is
   a product of the Routing Area YANG Architecture design team.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-rtgyangdt-rtgwg-device-model/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-rtgyangdt-rtgwg-device-model-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/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or 
ftp://ftp.ietf.org/ietf/1shadow-sites.txt




___
Rtg-dt-yang-arch mailing list
rtg-dt-yang-a...@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch

_

Ce message et ses pieces jointes peuvent contenir des informations 
con

RE: poll on draft-ietf-rtgwg-ipfrr-ip-mib-08

[stephane.litkowski]

Hi,

I’m personally fine with progressing the work if WG think this is useful. The 
content is there, but there was no real discussion on bits and bytes to adjust. 
IMHO, we’re almost done in term of content.
Regarding the writable items (read-create),IMO,  they would never be used , we 
can drop them from the MIB.

Stephane


From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Monday, February 22, 2016 13:53
To: Acee Lindem (acee); LITKOWSKI Stephane SCE/OINIS; Jeff Tantsura; 
rtgwg@ietf.org
Subject: Re: poll on draft-ietf-rtgwg-ipfrr-ip-mib-08

Hi Stephane,

I neglected to note that you are an author on the document ;^). Clearly, we 
should drop it if the authors do not want to complete it or believe there is 
significant work remaining to complete it. BTW, here is a URL to the IESG 
statement I referenced below:

https://www.ietf.org/iesg/statement/writable-mib-module.html

Thanks,
Acee


From: rtgwg mailto:rtgwg-boun...@ietf.org>> on behalf 
of Acee Lindem mailto:a...@cisco.com>>
Date: Monday, February 22, 2016 at 7:46 AM
To: Stephane Litkowski 
mailto:stephane.litkow...@orange.com>>, Jeff 
Tantsura mailto:jeff.tants...@ericsson.com>>, 
Routing WG mailto:rtgwg@ietf.org>>
Subject: Re: poll on draft-ietf-rtgwg-ipfrr-ip-mib-08

Hi Stephane,

From: Stephane Litkowski 
mailto:stephane.litkow...@orange.com>>
Date: Monday, February 22, 2016 at 6:17 AM
To: Acee Lindem mailto:a...@cisco.com>>, Jeff Tantsura 
mailto:jeff.tants...@ericsson.com>>, Routing WG 
mailto:rtgwg@ietf.org>>
Subject: RE: poll on draft-ietf-rtgwg-ipfrr-ip-mib-08

Hi Acee,

The main question behind : is there any interest for vendors to implement it 
and operators to use it ?
Or : Are people more focused now on YANG and so it’s better to convert this 
work into a YANG work ? (note that we already embed some FRR informations in 
IGP models but it’s not 100% mapped to this MIB proposal).

YANG is clearly the direction to replace MIBs as formally stated by the IESG at 
1-2 years ago.  The argument for completion is that we started the work many 
years ago and, if it is ready for publication, why not go ahead. OTH, if there 
are no implementations or plans for implementation then maybe it is best to 
simply drop it.

Thanks,
Acee



Best Regards,

Stephane

From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Friday, February 12, 2016 19:17
To: Jeff Tantsura; rtgwg@ietf.org
Subject: Re: poll on draft-ietf-rtgwg-ipfrr-ip-mib-08

Hey Jeff,
I say that if the authors are committed, we go ahead and complete it. If not, 
we drop it.
Thanks,
Acee

From: rtgwg mailto:rtgwg-boun...@ietf.org>> on behalf 
of Jeff Tantsura mailto:jeff.tants...@ericsson.com>>
Date: Friday, February 12, 2016 at 1:12 PM
To: Routing WG mailto:rtgwg@ietf.org>>
Subject: poll on draft-ietf-rtgwg-ipfrr-ip-mib-08

Dear RTGWG,

We are considering further progress of draft-ietf-rtgwg-ipfrr-ip-mib-08 and 
would like to poll the wg to see whether there’s enough interest to proceed 
with this work, i.e. WGLC.
Please respond, especially if you feel this work has to continue, also - please 
let us know if there are any existing implementations.

Many thanks and see you in Buenos Aires.

Jeff & Chris

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.

RE: poll on draft-ietf-rtgwg-ipfrr-ip-mib-08

[stephane.litkowski]

Hi Acee,

The main question behind : is there any interest for vendors to implement it 
and operators to use it ?
Or : Are people more focused now on YANG and so it’s better to convert this 
work into a YANG work ? (note that we already embed some FRR informations in 
IGP models but it’s not 100% mapped to this MIB proposal).

Best Regards,

Stephane

From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Friday, February 12, 2016 19:17
To: Jeff Tantsura; rtgwg@ietf.org
Subject: Re: poll on draft-ietf-rtgwg-ipfrr-ip-mib-08

Hey Jeff,
I say that if the authors are committed, we go ahead and complete it. If not, 
we drop it.
Thanks,
Acee

From: rtgwg mailto:rtgwg-boun...@ietf.org>> on behalf 
of Jeff Tantsura mailto:jeff.tants...@ericsson.com>>
Date: Friday, February 12, 2016 at 1:12 PM
To: Routing WG mailto:rtgwg@ietf.org>>
Subject: poll on draft-ietf-rtgwg-ipfrr-ip-mib-08

Dear RTGWG,

We are considering further progress of draft-ietf-rtgwg-ipfrr-ip-mib-08 and 
would like to poll the wg to see whether there’s enough interest to proceed 
with this work, i.e. WGLC.
Please respond, especially if you feel this work has to continue, also - please 
let us know if there are any existing implementations.

Many thanks and see you in Buenos Aires.

Jeff & Chris

_

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: I-D Action: draft-ietf-rtgwg-ipfrr-ip-mib-08.txt

[stephane.litkowski]

Just a refresh

-Original Message-
From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Tuesday, February 09, 2016 09:29
To: i-d-annou...@ietf.org
Cc: rtgwg@ietf.org
Subject: I-D Action: draft-ietf-rtgwg-ipfrr-ip-mib-08.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Area Working Group of the IETF.

Title   : IP MIB for IP Fast-Reroute
Authors : Alia Atlas
  A S Kiran Koushik
  Stephane Litkowski
Filename: draft-ietf-rtgwg-ipfrr-ip-mib-08.txt
Pages   : 28
Date: 2016-02-09

Abstract:
   This draft defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects relevant for IP routes
   using IP Fast-Reroute [RFC5714]



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ipfrr-ip-mib/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtgwg-ipfrr-ip-mib-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-ipfrr-ip-mib-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

_

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: RTGWG adoption call for draft-acee-rtg-yang-key-chain

[stephane.litkowski]

Support


From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Tuesday, November 10, 2015 18:53
To: rtgwg@ietf.org
Cc: rtgwg-chairs; draft-acee-rtg-yang-key-ch...@tools.ietf.org
Subject: RTGWG adoption call for draft-acee-rtg-yang-key-chain

Dear RTGWG,

The authors have requested the RTGWG to adopt draft-acee-rtg-yang-key-chain as 
the working group document.
Please indicate support or no-support by November 16, 2015.

If you are listed as a document author or contributor please respond to this 
email stating of 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.

Cheers,
Jeff and Chris

_

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: Comments on draft-shaikh-rtgwg-policy-model

[stephane.litkowski]

I have no issue to have two tags as long as I can have dynamic copy of the one 
the other (copying local tag to protocol tag, or reverse, or a protocol tag 
between two different protocols …).


From: Rob Shakir [mailto:r...@rob.sh]
Sent: Wednesday, July 22, 2015 10:18
To: Jon Mitchell; LITKOWSKI Stephane SCE/IBNF
Cc: Jeffrey Haas; rtgwg@ietf.org
Subject: Re: Comments on draft-shaikh-rtgwg-policy-model

The way that we have tried to approach these things with the OpenConfig 
initiated models is “what is the way that we use this feature” - and then try 
and design the way that the model works around this.

To me, it seems like I want to be able to explicitly control whether something 
that I am using as a local route marker (‘colour’) is propagated to any of my 
neighbours via a particular routing protocol - otherwise, it takes on other 
semantics that I might not intend it to do.

In the local-routing [0] module, we use ‘tag’ as a protocol-agnostic way to 
mark particular routes — and then when these locally generated routes are 
imported into other protocols, then attributes for those protocols can be set 
(e.g., BGP community etc.). It strikes me that we should have something similar 
in each protocol export policy that says match on the local ‘tag’/‘colour’ and 
set protocol-tag value X (or even a switch that says ‘propagate tag’ assuming 
that the colour type can be mapped to the protocol tag type).

I’d really like to separate local ‘tag’/‘colour’ from ‘tag’ within any 
particular protocol.

Cheers,
r.

[0]: 
https://github.com/YangModels/yang/blob/master/experimental/openconfig/local-routing/local-routing.yang


On 22 July 2015 at 08:39:55, Jon Mitchell 
(jrmit...@puck.nether.net) wrote:
On 22/07/15 07:32 +, 
stephane.litkow...@orange.com wrote:
> Hi Rob,
>
> Agree with the case you presented, IMO, we may provide some guidance to 
> implementation on the behavior to use when a local-tag is translated to a 
> protocol-tag and translation is not possible due to protocol-tag constraint 
> (for example “do not copy tag”).

I'd also point out that some implementations (even from the same
vendor!) have different behavior on whether to default copy up from
lcoal tag to protocol tag even when it is possible when redistribution
is configured.

-Jon

_

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: Comments on draft-shaikh-rtgwg-policy-model

[stephane.litkowski]

Hi Rob,

Agree with the case you presented, IMO, we may provide some guidance to 
implementation on the behavior to use when a local-tag is translated to a 
protocol-tag and translation is not possible due to protocol-tag constraint 
(for example “do not copy tag”).


From: Rob Shakir [mailto:r...@rob.sh]
Sent: Tuesday, July 21, 2015 20:30
To: LITKOWSKI Stephane SCE/IBNF; Jeffrey Haas
Cc: rtgwg@ietf.org
Subject: RE: Comments on draft-shaikh-rtgwg-policy-model

Hi Stephane,

Thanks for the clarification.

The challenge that we might have here is that there are cases where I may want 
to match/set the ‘colour’ as well as an IGP tag. For instance, if I want to 
mark something in the RIB to say that it should be propagated to neighbour sets 
Amber, Blue and Cyan - which each have their own colour value - but these 
values also have an associated IGP tag. Given that we can have both, it seems 
to me that we should prefer to look at something that is like Option B.

IMHO, the intent of the tag we have today [0] is really to be the ‘generic 
colour’ type of tag, since we did not model IGP policies yet I don’t think that 
we examined this issue in too much detail — although Jeff and others have 
pointed it out before, and we marked it as something we did need to look at!

Best,
r.

[0]: I’d recommend using the latest version of the YANG, which is  at 
https://github.com/YangModels/yang/tree/master/experimental/openconfig/policy


On 21 July 2015 at 16:53:15, 
stephane.litkow...@orange.com 
(stephane.litkow...@orange.com) wrote:
Sure ...

In the current version of the doc, option A is : single ‘tag’ type which can 
represent a protocol tag (it's only related to IGP tags in the draft)

So I would be in favor of option C :) (slight variation of option A) which is 
really single ‘tag’ type which can represent a protocol tag, or some purely 
local ‘colour’ attribute.


-Original Message-
From: Rob Shakir [mailto:r...@rob.sh]
Sent: Tuesday, July 21, 2015 16:30
To: LITKOWSKI Stephane SCE/IBNF; Jeffrey Haas
Cc: rtgwg@ietf.org
Subject: RE: Comments on draft-shaikh-rtgwg-policy-model


Folks,

There’s some ambiguity in the discussion here, from my perspective:

Option A: single ‘tag’ type which can represent a protocol tag, or some 
‘colour’ attribute.
Option B: multiple ‘tag’ types, a generic ‘colour’ and then per-protocol tags.

Right now, oc-policy uses option A. I can see arguments for either - but 
Stephane I was not clear from your view which of these you prefer - can you 
clarify for me please?

Thanks,
r.


On 20 July 2015 at 15:30:56, 
stephane.litkow...@orange.com 
(stephane.litkow...@orange.com(mailto:stephane.litkow...@orange.com))
 wrote:

>
> Inline
>
>
>
>
>
> From: Jeffrey Haas [mailto:jh...@pfrc.org]
> Sent: Monday, July 20, 2015 16:05
> To: LITKOWSKI Stephane SCE/IBNF
> Cc: rtgwg@ietf.org
> Subject: Re: Comments on draft-shaikh-rtgwg-policy-model
>
>
>
>
>
>
>
>
>
> >
> > On Jul 20, 2015, at 3:58 PM, 
> > stephane.litkow...@orange.com(mailto:stephane.litkow...@orange.com)
> >  wrote:
> >
> >
> >
> >
> >
> >
> > Right, each protocol has its own constraint, but do you think creating an 
> > additional generic marker will solve those constraints ? We would expect to 
> > be able to have the generic marker to protocol tag and also two protocol 
> > tags with different constraints to interact between each other (I mean for 
> > example, learning a RIP tag and copying it to ISIS or OSPF).
> >
> >
>
>
>
>
>
>
> My thought is that by not using an element that has protocol semantics, we 
> can free the user from worrying about them when they don't care about whether 
> the route will or will not get redistributed into a protocol that might use 
> it. This is mostly to deal with your "local" property noted earlier.
>
>
>
>
>
>
> [SLI] Agree, that’s why I was pushing “tag” to be protocol agnostic and 
> having only this tag and then let implementations to manage the translation 
> to protocol tag when necessary.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -- 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 confi

RE: Comments on draft-shaikh-rtgwg-policy-model

[stephane.litkowski]

Sure ...

In the current version of the doc, option A is : single ‘tag’ type which can 
represent a protocol tag (it's only related to IGP tags in the draft)

So I would be in favor of option C :) (slight variation of option A) which is 
really single ‘tag’ type which can represent a protocol tag, or some purely 
local ‘colour’ attribute.


-Original Message-
From: Rob Shakir [mailto:r...@rob.sh] 
Sent: Tuesday, July 21, 2015 16:30
To: LITKOWSKI Stephane SCE/IBNF; Jeffrey Haas
Cc: rtgwg@ietf.org
Subject: RE: Comments on draft-shaikh-rtgwg-policy-model

 
Folks,

There’s some ambiguity in the discussion here, from my perspective:

Option A: single ‘tag’ type which can represent a protocol tag, or some 
‘colour’ attribute.
Option B: multiple ‘tag’ types, a generic ‘colour’ and then per-protocol tags.

Right now, oc-policy uses option A. I can see arguments for either - but 
Stephane I was not clear from your view which of these you prefer - can you 
clarify for me please?

Thanks,
r.


On 20 July 2015 at 15:30:56, stephane.litkow...@orange.com 
(stephane.litkow...@orange.com(mailto:stephane.litkow...@orange.com)) wrote:

>  
> Inline
>  
>  
>  
>  
>  
> From: Jeffrey Haas [mailto:jh...@pfrc.org]
> Sent: Monday, July 20, 2015 16:05
> To: LITKOWSKI Stephane SCE/IBNF
> Cc: rtgwg@ietf.org
> Subject: Re: Comments on draft-shaikh-rtgwg-policy-model
>  
>  
>  
>  
>  
>  
>  
>  
>  
> >  
> > On Jul 20, 2015, at 3:58 PM, 
> > stephane.litkow...@orange.com(mailto:stephane.litkow...@orange.com) wrote:
> >  
> >  
> >  
> >  
> >  
> >  
> > Right, each protocol has its own constraint, but do you think creating an 
> > additional generic marker will solve those constraints ? We would expect to 
> > be able to have the generic marker to protocol tag and also two protocol 
> > tags with different constraints to interact between each other (I mean for 
> > example, learning a RIP tag and copying it to ISIS or OSPF).
> >  
> >  
>  
>  
>  
>  
>  
>  
> My thought is that by not using an element that has protocol semantics, we 
> can free the user from worrying about them when they don't care about whether 
> the route will or will not get redistributed into a protocol that might use 
> it. This is mostly to deal with your "local" property noted earlier.
>  
>  
>  
>  
>  
>  
> [SLI] Agree, that’s why I was pushing “tag” to be protocol agnostic and 
> having only this tag and then let implementations to manage the translation 
> to protocol tag when necessary.
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> -- 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


_

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: Comments on draft-shaikh-rtgwg-policy-model

[stephane.litkowski]

Inline

From: Jeffrey Haas [mailto:jh...@pfrc.org]
Sent: Monday, July 20, 2015 16:05
To: LITKOWSKI Stephane SCE/IBNF
Cc: rtgwg@ietf.org
Subject: Re: Comments on draft-shaikh-rtgwg-policy-model


On Jul 20, 2015, at 3:58 PM, 
stephane.litkow...@orange.com wrote:

Right, each protocol has its own constraint, but do you think creating an 
additional generic marker will solve those constraints ? We would expect to be 
able to have the generic marker to protocol tag and also two protocol tags with 
different constraints to interact between each other (I mean for example, 
learning a RIP tag and copying it to ISIS or OSPF).

My thought is that by not using an element that has protocol semantics, we can 
free the user from worrying about them when they don't care about whether the 
route will or will not get redistributed into a protocol that might use it.  
This is mostly to deal with your "local" property noted earlier.

[SLI] Agree, that's why I was pushing "tag" to be protocol agnostic and having 
only this tag and then let implementations to manage the translation to 
protocol tag when necessary.




-- 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: Comments on draft-shaikh-rtgwg-policy-model

[stephane.litkowski]

Right, each protocol has its own constraint, but do you think creating an 
additional generic marker will solve those constraints ? We would expect to be 
able to have the generic marker to protocol tag and also two protocol tags with 
different constraints to interact between each other (I mean for example, 
learning a RIP tag and copying it to ISIS or OSPF).


From: Jeffrey Haas [mailto:jh...@pfrc.org]
Sent: Monday, July 20, 2015 14:44
To: LITKOWSKI Stephane SCE/IBNF
Cc: rtgwg@ietf.org
Subject: Re: Comments on draft-shaikh-rtgwg-policy-model

Stephane,

On Jul 20, 2015, at 2:21 PM, 
mailto:stephane.litkow...@orange.com>> 
mailto:stephane.litkow...@orange.com>> wrote:

[SLI] Do we really need to differentiate from a policy point of view ? from an 
import policy perspective, matching a tag, means learning the tag value 
available in the protocol (if available) and when the route ins inserted into 
RIB the tag value is copied from the protocol value if not overrided by import 
policy action; from an export policy perspective (talking about export from rib 
to protocol), matching a tag means matching the tag value in the RIB (which may 
come from protocol or not),  setting a tag means fill the protocol field if 
available. From a RIB point of view, the tag associated with the route is 
protocol agnostic, even if the protocol does not support tags in encoding you 
may associate a local tag for policy processing.

Having two types of tags is also possible : protocol-tag and local-tag but I 
see more complexity and do not see more flexibility : but maybe there is some 
use case that I do not see.

The messy detail with this attribute is that while it's useful as a generic 
policy element, in specific protocol context it needs to have differing 
constraints.  OSPF has one set of constraints, RIP a slightly different one 
(zero is reserved), and ISIS has different sizes with some option for one or 
two tags plus the 64-bit tag previously discussed.

This set of context specific constraints probably removes some level of the 
flexibility that you'd want for it to be a generic marker - unless you can live 
within the least common denominator.

-- 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: Comments on draft-shaikh-rtgwg-policy-model

[stephane.litkowski]

Hi Jeff,

Inline comments

From: Jeffrey Haas [mailto:jh...@pfrc.org]
Sent: Monday, July 20, 2015 13:47
To: LITKOWSKI Stephane SCE/IBNF
Cc: rtgwg@ietf.org
Subject: Re: Comments on draft-shaikh-rtgwg-policy-model


On Jul 20, 2015, at 1:35 PM, 
mailto:stephane.litkow...@orange.com>> 
mailto:stephane.litkow...@orange.com>> wrote:

-  Regarding tags, as pointed today, I would like to have “tag” to be a 
generic local identifier rather than pointing only to IS-IS and OSPF. Any route 
within a RIB may have a local tag (this local tag can be learned from the 
routing protocol or set by configuration or policy). So setting a tag does not 
refer to any igp-action.

I believe we do wish to keep this field used for IGP route tagging since that's 
a protocol component.
[SLI] Do we really need to differentiate from a policy point of view ? from an 
import policy perspective, matching a tag, means learning the tag value 
available in the protocol (if available) and when the route ins inserted into 
RIB the tag value is copied from the protocol value if not overrided by import 
policy action; from an export policy perspective (talking about export from rib 
to protocol), matching a tag means matching the tag value in the RIB (which may 
come from protocol or not),  setting a tag means fill the protocol field if 
available. From a RIB point of view, the tag associated with the route is 
protocol agnostic, even if the protocol does not support tags in encoding you 
may associate a local tag for policy processing.

Having two types of tags is also possible : protocol-tag and local-tag but I 
see more complexity and do not see more flexibility : but maybe there is some 
use case that I do not see.


(Fascinating issue, while researching ISIS implementations I found that the 
protocol permits 64bit tagging, but didn't find anyone that implemented them.)
[SLI] ☺ we have it in IS-IS yang model , tag64 if I remember correctly.

I do realize that there is also a need to do general route mark-up so that 
policy engines can operate off of that.  I know that for certain route types, 
the "tag" field might be able to be used for this purpose; e.g it has no 
semantics in a given BGP implementation unless the route is redistributed in 
the IGP.  (And I'm not even sure that field survives export, I'd have to check 
the code.)

Perhaps more appropriate would be to have a new mark-up field, name TBD, to 
cover this purpose.  It could then be implemented as appropriate for a given 
route type and vendor implementation?

-- 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

Comments on draft-shaikh-rtgwg-policy-model

[stephane.litkowski]

Hi,

As pointed this morning during the WG session :

-  We need to clarify (asap if possible) the boundary between this 
policy model and what should be defined in protocol models to extend the 
policy. In the current version, it looks like a mix of having part of IGP 
defined in the generic policy framework and so expecting some other extensions 
in IGP models. For BGP, all is within BGP. My proposal would be to let all the 
protocol extensions to be in protocol models, this includes :

o   Protocol specific matching

o   Protocol specific actions

o   Install-protocol identity for that protocol => so need to remove the 
existing ones for ISIS, OSPF, BGP in the current version.

-  Regarding tags, as pointed today, I would like to have "tag" to be a 
generic local identifier rather than pointing only to IS-IS and OSPF. Any route 
within a RIB may have a local tag (this local tag can be learned from the 
routing protocol or set by configuration or policy). So setting a tag does not 
refer to any igp-action.

-  Also regarding the "igp-action" container, I'm not in favor of 
having separate containers for igp-actions, bgp-actions and generic-actions. 
Two possibilities :

o   Each protocol creates a container (e.g. isis-actions, ospf-actions ...) 
which augments the action container. Isis-actions and ospf-actions may be 
different (for example in setting route-type or metric type ...)

o   Just having the "actions" container and put all the actions here whatever 
the applicable protocol.

o   Similar approach to be taken for protocol specific conditions

-  I would be in favor in adding routing table matching condition and a 
way to select also a destination routing table. E.g. , I use an import policy 
to force a routing protocol to insert routes in a specific routing table rather 
than the default one. Or I want to authorize routes from multiple routing 
tables to be exported to a particular protocol.





Best Regards,

[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE
Orange Expert Future Networks
phone: +33 2 23 28 49 83 

mobile: +33 6 37 86 97 52 

stephane.litkow...@orange.com



_

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: Joel Jaeggli's No Objection on draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)

[stephane.litkowski]

Hi All,

I just posted v10 based on your comments.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-lfa-manageability-10

Thanks,


-Original Message-
From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Joel Jaeggli
Sent: Thursday, June 25, 2015 07:14
To: The IESG
Cc: rtgwg@ietf.org
Subject: Joel Jaeggli's No Objection on draft-ietf-rtgwg-lfa-manageability-09: 
(with COMMENT)

Joel Jaeggli has entered the following ballot position for
draft-ietf-rtgwg-lfa-manageability-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-lfa-manageability/



--
COMMENT:
--

Ron Bonica's Opsdir review.

Folks,

I have reviewed this document as part of the Operational directorate's ongoing 
effort to review all IETF documents being processed by the IESG. 
These comments were written with the intent of improving the operational 
aspects of the IETF drafts. Comments that are not addressed in last call may be 
included in AD reviews during the IESG review.  Document editors and WG chairs 
should treat these comments just like any other last call comments.

This document is on the Standards Track. It provides operational feedback on 
LFA, highlights some limitations, and proposes a set of refinements to address 
those limitations.  It also proposes required management specifications.

The document is well-written and nearly ready for publication.

Major Issues

None

Minor Issues
---
- Please run this document through the NIT checker and address the NITS

- I am not sure how the sitting IESG feels about the use of lowercase "must", 
"should" and "may". You may want to check this before the IESG review.


Ron Bonica

---

example that I would cite as good to all caps

6.1
...


   o  Per prefixes: prefix protection SHOULD have a better priority
  compared to interface protection.  This means that if a specific
  prefix must be protected due to a configuration request, LFA must
  be computed and installed for this prefix even if the primary
  outgoing interface is not configured for protection.

LFA MUST

since it's a requirement

in most other cases I see a lower cast must what is being described is the 
logic that draws you to a conclusion, and those are ok.


___
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: Joel Jaeggli's No Objection on draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)

[stephane.litkowski]

Hi,

Thanks, this will be fixed in the next version.


-Original Message-
From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Joel Jaeggli
Sent: Thursday, June 25, 2015 07:14
To: The IESG
Cc: rtgwg@ietf.org
Subject: Joel Jaeggli's No Objection on draft-ietf-rtgwg-lfa-manageability-09: 
(with COMMENT)

Joel Jaeggli has entered the following ballot position for
draft-ietf-rtgwg-lfa-manageability-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-lfa-manageability/



--
COMMENT:
--

Ron Bonica's Opsdir review.

Folks,

I have reviewed this document as part of the Operational directorate's ongoing 
effort to review all IETF documents being processed by the IESG. 
These comments were written with the intent of improving the operational 
aspects of the IETF drafts. Comments that are not addressed in last call may be 
included in AD reviews during the IESG review.  Document editors and WG chairs 
should treat these comments just like any other last call comments.

This document is on the Standards Track. It provides operational feedback on 
LFA, highlights some limitations, and proposes a set of refinements to address 
those limitations.  It also proposes required management specifications.

The document is well-written and nearly ready for publication.

Major Issues

None

Minor Issues
---
- Please run this document through the NIT checker and address the NITS

- I am not sure how the sitting IESG feels about the use of lowercase "must", 
"should" and "may". You may want to check this before the IESG review.


Ron Bonica

---

example that I would cite as good to all caps

6.1
...


   o  Per prefixes: prefix protection SHOULD have a better priority
  compared to interface protection.  This means that if a specific
  prefix must be protected due to a configuration request, LFA must
  be computed and installed for this prefix even if the primary
  outgoing interface is not configured for protection.

LFA MUST

since it's a requirement

in most other cases I see a lower cast must what is being described is the 
logic that draws you to a conclusion, and those are ok.


___
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: Alvaro Retana's No Objection on draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)

[stephane.litkowski]

Hi Alvaro, Alia

> From Alvaro Retana> (aretana)
> Sent: Tuesday, June 23, 2015 3:44 PM
> To: LITKOWSKI Stephane SCE/IBNF
> Cc: draft-ietf-rtgwg-lfa-manageabil...@tools.ietf.org; Brian Haberman; 
> i...@ietf.org; rtgwg@ietf.org
> Subject: Re: Alvaro Retana's No Objection on draft-ietf-rtgwg-lfa-
> manageability-09: (with COMMENT)
> 
> On 6/23/15, 5:22 AM, "stephane.litkow...@orange.com"
>  wrote:
> 
> Stephane:
> 
> I¹m looping everyone else back in..I know Brian had the same comment.
> 
> >For the point #3, we had a comment from Alia on the list saying that 
> >we needed to point to some existing solutions.
> >
> >We propose to change the text as follows :
> >BEFORE :
> >Link color information SHOULD be signalled in the IGP.  How
> >   signalling is done is out of scope of the document but it may be
> >   useful to reuse existing admin-groups from traffic-engineering
> >   extensions or link attributes extensions like in
> >   [I-D.ietf-ospf-prefix-link-attr].
> >NEW TEXT :
> > Link color information SHOULD be signalled in the IGP in order to 
> >limit configuration effort.  e.g.
> >   [I-D.ietf-ospf-prefix-link-attr], [RFC5305], [RFC3630] ...
> >
> >Does it work ?
> 
> Honestly, both options point at the same thing: the suggestion (at 
> least) of a solution.  I am completely in favor of reusing 
> technology/ideas/drafts if they will help solve the problem.  My point 
> is that this document is not specifying solutions, just requirements..if that 
> is true, then don¹t point at the solutions.
> OTOH, if this document is to specify solutions, then lets do that.
> 
> Having said all that, I can defer to Alia.  However, please at least 
> make it clear that the solutions you are pointing to are just that (pointers).
> In the text above I would rather keep the original text that clearly 
> states that solutions are out of scope.  The text in 6.2.4.4 doesn¹t 
> explicitly say that the solutions are not in scope.

CURRENT text is:
   Link color information SHOULD be signalled in the IGP.  How
   signalling is done is out of scope of the document but it may be
   useful to reuse existing admin-groups from traffic-engineering
   extensions or link attributes extensions like in
   [I-D.ietf-ospf-prefix-link-attr].
 
My understanding is that you are calling for removing the pointer to the 
solution (and do the same thing for the node color section) or pushing for 
solutions.

CANDIDATE1: we can limit the text to :
"Link color information SHOULD be signaled in the IGP.  " and do the same thing 
for the node color.


We would be ok for this, but, this seems like a different direction compared to 
a previous comment from Alia who had previously proposed to _add_ reference to 
solution drafts, including  ospf-prefix-link-attr:
> From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Alia Atlas
> Sent: Friday, June 12, 2015 4:23 PM
> To: LITKOWSKI Stephane SCE/IBNF
> Cc: draft-ietf-rtgwg-lfa-manageabil...@tools.ietf.org; rtgwg@ietf.org
> Subject: Re: AD Review of draft-ietf-rtgwg-lfa-manageability
[...]
> 4) In Sec 6.2.7, you might be interested in the link/node-attribute drafts 
> that are being finished.
> [SLI] Could you give me the pointers of drafts you are thinking about ?
>You have the ISIS one for node admin tags.  I was also thinking of 
>draft-ietf-ospf-node-admin-tag-02  and 
>draft-ietf-ospf-prefix-link-attr-06.  For ISIS, it looks like the similar 
>draft  only provides for prefix attributes and not link ones.

Since you deferred to Alia, and "would rather keep the original text", our 
current understanding is to keep CURRENT text which has been revised as per 
Alia's comment.
Alia, Alvaro, please advise/propose text if this you prefer something different.


Best regards,


-Original Message-
From: Alvaro Retana (aretana) [mailto:aret...@cisco.com] 
Sent: Tuesday, June 23, 2015 15:44
To: LITKOWSKI Stephane SCE/IBNF
Cc: rtgwg@ietf.org; draft-ietf-rtgwg-lfa-manageabil...@tools.ietf.org; 
i...@ietf.org; Brian Haberman
Subject: Re: Alvaro Retana's No Objection on 
draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)

On 6/23/15, 5:22 AM, "stephane.litkow...@orange.com"
 wrote:

Stephane:

I¹m looping everyone else back in..I know Brian had the same comment.

>For the point #3, we had a comment from Alia on the list saying that we 
>needed to point to some existing solutions.
>
>We propose to change the text as follows :
>BEFORE :
>Link color information SHOULD be signalled in the IGP.  How
>   signalling is done is out of scope of the document but it may be
>   useful to reuse existing admin-groups from traffic-engineering
>   extensions or link attributes extensions like in
>   [I-D.ietf-ospf-prefix-link-attr].
>NEW TEXT :
> Link color information SHOULD be signalled in the IGP in order to 
>limit configuration effort.  e.g.
>   [I-D.ietf-ospf-prefix-link-attr], [RFC5305], [RFC3630] ...
>
>Does it work ?

Honestly, both options point at the same thing: the suggestion (at least) of a 
solution.  I 

RE: AD Review of draft-ietf-rtgwg-lfa-manageability

[stephane.litkowski]

Hi Alia,

I just posted the version 9. For the moment, I kept the six (co-)authors. As I 
explained, everyone did more than just contributing and there was a strong 
involvement on draft text and specification, so it would be wonderful if you 
can agree to keep all of them.

Hope the modified text will fit your comments.

Thanks,

Stephane

--

A new version of I-D, draft-ietf-rtgwg-lfa-manageability-09.txt

has been successfully submitted by Stephane Litkowski and posted to the IETF 
repository.



Name:  draft-ietf-rtgwg-lfa-manageability

Revision:  09

Title:  Operational management of Loop Free Alternates

Document date:   2015-06-19

Group:  rtgwg

Pages:   28

URL:
https://www.ietf.org/internet-drafts/draft-ietf-rtgwg-lfa-manageability-09.txt

Status: 
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/

Htmlized:   
https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-09

Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-lfa-manageability-09



Abstract:

   Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast

   ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic

   (and MPLS LDP traffic by extension).  Following first deployment

   experiences, this document provides operational feedback on LFA,

   highlights some limitations, and proposes a set of refinements to

   address those limitations.  It also proposes required management

   specifications.



   This proposal is also applicable to remote LFA solution.











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.



The IETF Secretariat




From: Alia Atlas [mailto:akat...@gmail.com]
Sent: Thursday, June 18, 2015 20:11
To: LITKOWSKI Stephane SCE/IBNF
Cc: rtgwg@ietf.org; draft-ietf-rtgwg-lfa-manageabil...@tools.ietf.org
Subject: Re: AD Review of draft-ietf-rtgwg-lfa-manageability

Just a quick reminder - but an updated draft is needed by tomorrow to address 
these issues.
Otherwise, I will have to remove the draft from the telechat on June 25 and 
postpone it until June 9,
assuming the draft is updated next week.

Regards,
Alia

On Fri, Jun 12, 2015 at 10:22 AM, Alia Atlas 
mailto:akat...@gmail.com>> wrote:
Hi Stephane,

On Fri, Jun 12, 2015 at 8:55 AM, 
mailto:stephane.litkow...@orange.com>> wrote:
Hi Alia,

Many thanks for your review, I will address them shortly and publish a new 
version.
Some comments inline.

Sounds good.



Best Regards,

Stephane

From: rtgwg [mailto:rtgwg-boun...@ietf.org] On 
Behalf Of Alia Atlas
Sent: Thursday, June 04, 2015 23:44
To: rtgwg@ietf.org; 
draft-ietf-rtgwg-lfa-manageabil...@tools.ietf.org
Subject: AD Review of draft-ietf-rtgwg-lfa-manageability


As is customary, I have done my AD Review of this draft.   Thank you for a 
clearly written and well thought out draft.

I do have some minor concerns,  as below, but I am also letting this draft move 
to IETF Last Call while they are addressed.   I will need an updated draft by 
June 18, so the draft can go on the IESG telechat on June 25.

Minor comments:

0)  This draft has 6 authors.  Please prune down to 5 or assign an editor 
or two.

[SLI] Everyone listed worked hardly on the text as well as on specifications, I 
will put myself as editor to keep everyone ☺.
We can talk about this.  Having 6 authors/editors is an exception that I would 
have to approve.

  1) In section 6.2.1, it says " When selecting the best alternate, the 
selection algorithm MUST
  consider all available alternates (connected or tunnel).  Especially,
  computation of PQ set ([I-D.ietf-rtgwg-remote-lfa]) SHOULD be
  performed before best alternate selection."

  Instead of "Especially" with a SHOULD - which implies that Remote LFA 
should always be run, could you change it to:  "For example with Remote LFA, 
computation of PQ set "?   I think the manageability concerns in this 
document are useful regardless of the fast-reroute technology and this is only 
a good example of an implementation ordering that is important.

[SLI] Fixed.

  2) In 6.2.4.1: " attributes from PLR to alternate path are 
retrieved from the
  interface connected to the alternate."

  There can be multiple interfaces.  The correct behavior (union or  
evaluate once per different interface) should be clearly described.  The 
similar issue exists for the alternate path and in 6.2.4.2, but there may be 
more or less freedom about controlling which path is taken.

[SLI] I need to discuss with my co authors on that.
Yes, I think this one is a non-trivial.  It's made more amusing by the 
probability of multiple paths taken at downstream hops.  I can see be

RE: AD Review of draft-ietf-rtgwg-lfa-manageability

[stephane.litkowski]

Hi Alia,

Many thanks for your review, I will address them shortly and publish a new 
version.
Some comments inline.


Best Regards,

Stephane

From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Alia Atlas
Sent: Thursday, June 04, 2015 23:44
To: rtgwg@ietf.org; draft-ietf-rtgwg-lfa-manageabil...@tools.ietf.org
Subject: AD Review of draft-ietf-rtgwg-lfa-manageability


As is customary, I have done my AD Review of this draft.   Thank you for a 
clearly written and well thought out draft.

I do have some minor concerns,  as below, but I am also letting this draft move 
to IETF Last Call while they are addressed.   I will need an updated draft by 
June 18, so the draft can go on the IESG telechat on June 25.

Minor comments:

0)  This draft has 6 authors.  Please prune down to 5 or assign an editor 
or two.

[SLI] Everyone listed worked hardly on the text as well as on specifications, I 
will put myself as editor to keep everyone ☺.

  1) In section 6.2.1, it says " When selecting the best alternate, the 
selection algorithm MUST
  consider all available alternates (connected or tunnel).  Especially,
  computation of PQ set ([I-D.ietf-rtgwg-remote-lfa]) SHOULD be
  performed before best alternate selection."

  Instead of "Especially" with a SHOULD - which implies that Remote LFA 
should always be run, could you change it to:  "For example with Remote LFA, 
computation of PQ set "?   I think the manageability concerns in this 
document are useful regardless of the fast-reroute technology and this is only 
a good example of an implementation ordering that is important.

[SLI] Fixed.

  2) In 6.2.4.1: " attributes from PLR to alternate path are 
retrieved from the
  interface connected to the alternate."

  There can be multiple interfaces.  The correct behavior (union or  
evaluate once per different interface) should be clearly described.  The 
similar issue exists for the alternate path and in 6.2.4.2, but there may be 
more or less freedom about controlling which path is taken.

[SLI] I need to discuss with my co authors on that.



3) In Sec 6.2.6, "Maintain a preference system between alternates based on 
number of
  SRLG violations : more violations = less preference."   The way that I've 
seen SRLGs used as a soft restriction is by giving each SRLG a value.  Then one 
can prefer the lower sum.  This allows different consideration and valuation of 
the SRLGs.  Of course, this can fall back to each SRLG has a value of 1.   
Could you please loosen the assumption here about equally valuing the SRLGs?  
I'd prefer to see both alternatives allowed - but that is technical 
opinion whereas loosening the assumption is about not accidentally 
forcing more limited behavior and removing the ability to implement more 
sophisticated mechanisms.

[SLI] Right, here is a new text proposal which is more open:

“

When SRLG protection is computed, and implementation SHOULD permit to :



Exclude alternates violating 
SRLG.

Maintain a preference system 
between alternates based on SRLG violations. How the preference system is 
implemented is out of scope of this document but here are few examples :



Preference based on number 
of violation. In this case : the more violation = the less preferred.

Preference based on 
violation cost. In this case, each SRLG violation has an associated cost. The 
lower violation cost sum is preferred.

”

The path considerations mentioned in (2) still apply.

4) In Sec 6.2.7, you might be interested in the link/node-attribute drafts that 
are being finished.

[SLI] Could you give me the pointers of drafts you are thinking about ?



5) In Sec 6.2.8: "The bandwidth criteria of the policy framework SHOULD work in 
two
   ways"  Please expand to "at least two ways" - there are other strategies as 
well that might be reasonable and no standardization reason to rule them out.

[SLI] Agree, fixed

Nits:
   a) Introduction needs to be the first section. Terminology can follow.

[SLI] Fixed

  b) Remote LFA reference needs updating to RFC 7490.  I think,  given some of 
the details in this draft,  that it should be a normative reference.

[SLI] Fixed.



Thanks for the good work,
Alia

_

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 messa

RE: Mail regarding draft-litkowski-rtgwg-spf-uloop-pb-statement

[stephane.litkowski]

Hi Martin,

That makes sense to me. I will remove the reference.

Thanks,

Stephane

From: Martin Horneffer [mailto:m...@nic.dtag.de]
Sent: Monday, May 11, 2015 16:06
To: LITKOWSKI Stephane SCE/IBNF; Mike Shand; 
draft-litkowski-rtgwg-spf-uloop-pb-statem...@tools.ietf.org
Cc: rtgwg@ietf.org
Subject: Re: Mail regarding draft-litkowski-rtgwg-spf-uloop-pb-statement

Hello Stephane, Mike, and group,

just one comment (see below) since I get to see more and more different 
networks from the operator's point of view.

Am 11.05.15 um 16:22 schrieb 
stephane.litkow...@orange.com:
4. "   Routers have more and more powerful controlplane and dataplane that
   reduce the Control plane to Forwarding plane overhead during the
   convergence process.  Even if FIB update is still reasonably the
   highest contributor in the convergence time for large network, its
   duration is reducing more and more and may become comparable to
   protocol timers.  This is particular true in small and medium
   networks."

I don't understand what is meant by "may become comparable to protocol timers"? 
Are you suggesting that the FIB update latency WAS greater than the protocol 
timers, but has now been reduced to a comparable value?
[SLI] Right, even if it may be not true for all the networks, this tends to be 
the case

The reference to small and medium networks is also confusing, since in my 
experience it is actually the small and medium networks which are subject to 
the LARGEST FIB update times as a result of the deployment of under powered 
hardware.
[SLI] Yes and no ...
I may say that small/medium networks have less powerful hardware, but also less 
routes (except badly designed networks :) ). Large network have more powerful 
hardware but more routes to handle.
This really depends on many corner conditions such as exact choice and age of 
hardware, network design in term of topology and routing architecture and, of 
course, size of the network.

While it might be possible for a small or medium sized network with a very 
clean design, a small number of internal routes, and modern hardware to have a 
very fast FIB update, there are numerous reasons why this could fail: old 
hardware or software, network design which includes many parts of the 
aggregation, access and service generation area in the IGP, and/or routing 
architectures which for one reason or the other include some service routes in 
the IGP.
For very large networks on the other hand it will definitely not be possible to 
keep FIB updates very fast.

IMHO it would be a good idea to remove  the reference to the size of the 
network. And don't even try to specify which kind of network has shorter or 
longer FIB update times. Just indicate that depending on size and exact design 
of a network it MAY have short FIB updates times, but make clear that by no 
means this is always the case.

Best regards, Martin

_

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: Mail regarding draft-litkowski-rtgwg-spf-uloop-pb-statement

[stephane.litkowski]

Hi Mike,

Thanks for this first review. I will for sure address your comments.
Some inline answers.

From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Mike Shand
Sent: Thursday, May 07, 2015 12:15
To: draft-litkowski-rtgwg-spf-uloop-pb-statem...@tools.ietf.org
Cc: rtgwg@ietf.org
Subject: Re: Mail regarding draft-litkowski-rtgwg-spf-uloop-pb-statement

I have been assigned as Routing Directorate QA reviewer for this document.
The following web page contains a briefing on the QA process.
​https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa


The document provides a useful summary of the issues leading to micro-loop 
formation, especially in mixed vendor networks and provides examples of the 
possibilities to adversely affect the the micro-loop behaviour by inconsistent 
choices of parameters and algorithms among the routers in the network.
I confess that I find the timing diagrams quite hard to follow. One of the 
penalties of being constrained by the need to use ASCII art. But I wonder if 
something could be done to make them a little easier to follow without losing 
the essential information?
There are some very simple mitigation techniques, such as delaying the locally 
triggered  SPF/FIB installation more than a remotely triggered one, which it 
may be helpful to mention.

The document goes on to propose future work to standardise some behaviours.

Clearly this work is at an early stage and the trade-offs between 
standardisation and allowing vendors freedom to innovate for the benefit of 
their customers must be carefully considered.

The document seems like a good starting point for this work.


In reading the document I spotted a few items which it would be as well to 
address.

General:

1. micro-loop or microloop. The terminology is used inconsistently. RFC 5715 
uses micro-loop
[SLI] Will be fixed

2. There are numerous instances of awkward usage of english. It would be 
helpful to address these at some stage.

Nits:

3. "   We will call SPF delay, the delay timer that exists in most
   implementations that makes codes to wait before running SPF
   computation after a SPF trigger is received."

The phrase "makes codes to wait" is somewhat contrived. How about "that 
specifies the required delay"?
[SLI] your proposal is fine, will be fixed


4. "   Routers have more and more powerful controlplane and dataplane that
   reduce the Control plane to Forwarding plane overhead during the
   convergence process.  Even if FIB update is still reasonably the
   highest contributor in the convergence time for large network, its
   duration is reducing more and more and may become comparable to
   protocol timers.  This is particular true in small and medium
   networks."

I don't understand what is meant by "may become comparable to protocol timers"? 
Are you suggesting that the FIB update latency WAS greater than the protocol 
timers, but has now been reduced to a comparable value?
[SLI] Right, even if it may be not true for all the networks, this tends to be 
the case

The reference to small and medium networks is also confusing, since in my 
experience it is actually the small and medium networks which are subject to 
the LARGEST FIB update times as a result of the deployment of under powered 
hardware.
[SLI] Yes and no …
I may say that small/medium networks have less powerful hardware, but also less 
routes (except badly designed networks ☺ ). Large network have more powerful 
hardware but more routes to handle.

5. "   In multi vendor networks, using different implementations of a link
   state protocol may favor micro-loops creation during convergence time
   due to deprecancies of timers."

deprecancies? Do you mean discrepancies?
[SLI] Yep, I meant “discrepancies” , will be fixed.


6. "4.2 Exponential Backoff"

"   o  First delay : amount of time to wait before running SPF.  This
  delay is used on when SPF is in fast mode."

I assume "is used only when SPF" is what you mean.
[SLI] Right, will be fixed


and similarly in the next bullet



Mike

_

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 
modi

RE: Request for WG adoption of draft-litkowski-rtgwg-spf-uloop-pb-statement and draft-decraene-rtgwg-backoff-algo

[stephane.litkowski]

Hi,

I support both drafts.

I'm not aware of any IPR.

Stephane


-Original Message-
From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Thursday, April 16, 2015 19:25
To: rtgwg@ietf.org
Subject: Request for WG adoption of 
draft-litkowski-rtgwg-spf-uloop-pb-statement and 
draft-decraene-rtgwg-backoff-algo

Hi RTGWG,

The authors have requested the RTGWG to adopt:
draft-litkowski-rtgwg-spf-uloop-pb-statement and 
draft-decraene-rtgwg-backoff-algo as working group documents.

There was support during the last IETF meeting (92) in Dallas.
Please indicate support or no-support by May 1st, 2015.


If you are listed as a document author or contributor please respond to this 
email stating of 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.


Thanks,


Jeff & Chris

___
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: LFA manageability : per AF config => feedback required

[stephane.litkowski]

Hi,

I updated the draft section in this way, I used MAY for per AF and per MPLS 
control plane. I think "MAY" is better as it may fit everyone's point of view 
(it's not strong and permit optional support).
Let me know your thoughts asap please. I would like to post the draft before 
cut off.


   An implementation of LFA SHOULD allow its activation with the
   following criteria:

   o  Per routing context: VRF, virtual/logical router, global routing
  table, ...

   o  Per interface

   o  Per protocol instance, topology, area

   o  Per prefixes: prefix protection SHOULD have a better priority
  compared to interface protection.  This means that if a specific
  prefix must be protected due to a configuration request, LFA must
  be computed and installed for this prefix even if the primary
  outgoing interface is not configured for protection.

   An implementation of LFA MAY allow its activation with the following
   criteria:

   o  Per address-family: ipv4 unicast, ipv6 unicast

   o  Per MPLS control plane: for MPLS control planes that inherit
  routing decision from the IGP routing protocol, MPLS dataplane may
  be protected by LFA.  The implementation may allow operator to
  control this inheritance of protection from the IP prefix to the
  MPLS label bound to this prefix.  The protection inheritance will
  concern : IP to MPLS, MPLS to MPLS, and MPLS to IP entries.  As
  example, LDP and segment-routing extensions for ISIS and OSPF are
  control plane eligible to this inheritance of protection.

-Original Message-
From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Hannes Gredler
Sent: Tuesday, February 24, 2015 18:30
To: Martin Horneffer
Cc: rtgwg@ietf.org
Subject: Re: LFA manageability : per AF config => feedback required

martin,

can you describe what are the pain points of FRR protecting
*all* your traffic (IPv4/IPv6/labeled/unlabeled) ?

why would you want your traffic not being protected ?

/hannes

On Tue, Feb 24, 2015 at 05:54:44PM +0100, Martin Horneffer wrote:
| Hello everyone,
| 
| I really do see a good use-case for turning on IP-FRR protection for 
| just one address family, and it does not have anything to do with 
| making IPv6 customer better or worse than IPv4 customer traffic.
| 
| Consider the IP/MPLS network I have today. Several address families 
| are active in the backbone, but all customer traffic is carried in 
| MPLS packets guided by IPv4-signalled LDP. This holds for ANY customer 
| traffic, whether it is public IPv4, public IPv6, VPNs in IPv4 or IPv6 
| or L2-VPNs. Unlabeled
| IPv4 traffic also exists in the same backbone, but only for routing 
| protocols themselves, and/or network management. Thus there is no need 
| to protect this unlabeled IPv4 traffic in the same way as the customer 
| MPLS traffic.
| 
| In the future, I might activate IPv6 in the backbone and introduce 
| more and more routing and management protocols with IPv6. Still no 
| need to protect IPv6. Eventually I might shift LDP (or SR) from IPv4 
| controlled to IPv6 controlled. What was IPv6-over-IPv4-controlled-MPLS 
| becomes plain IPv6-labeled traffic then, and IPv4-labeled traffic will 
| become IPv4-over-IPv6-controlled-MPLS. At THAT point in time it 
| becomes important to protect the IPv6 controlled MPLS traffic, and 
| thus the IPv6 address family in the IGP, but no earlier.
| 
| So please do not mix up control traffic and customer traffic, internal 
| routing and customer routes. Thank you.
| 
| Best regards, Martin
| 
| 
| Am 24.02.15 um 16:02 schrieb Hannes Gredler:
| >On Mon, Feb 23, 2015 at 03:55:32PM +, Les Ginsberg (ginsberg) wrote:
| >|I can imagine cases in which the per AF enabling might make sense (e.g.
| >|when the network associated w one address family is deemed 
non-critical).
| >
| >
| >HG> as it is unlikely that operators will tun off IPv4 protection,
| > may i have a ask that you repeat that quote above in the 6man
| > meeting ;-) ? - effectifely you're saying "IPv6 may be considered
| > as less critical", and therefore we SHOULD provide a knob
| > to turn protection off.
| >
| >|
| >|
| >|Section 5.1 is a SHOULD - as is most of the document. It is therefore a
| >|suggestion as to what an implementation should provide. If a given
| >|implementer thinks this is either too onerous or not useful they can 
omit
| >|it w/o being in violation. But I see no reason to eliminate this - and 
in
| >|actual practice I would expect the cost of supporting such a knob to be
| >|low cost. It is hard for me to see this as controversial.
| >|
| >|
| >|
| >|   Les
| >|
| >|
| >|
| >|
| >|
| >|From: stephane.litkow...@orange.com 
[mailto:stephane.litkow...@orange.com]
| >|Sent: Sunday, February 22, 2015 11:10 PM
| >|To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Jeff Tantsura;
| >|rtgwg@ietf.org
| >|Subject: RE: LFA manageability : per AF config => feedbac

RE: LFA manageability : per AF config => feedback required

[stephane.litkowski]

[Les:] I think your point here is that the LFA calculation is AF independent 
within a given topology - but resources are consumed independent of how many 
computations are required- giving an operator the ability to determine which 
prefixes are most critical seems useful. That could be per AF or per prefix.

[SLI] Agree but is the "resource saving" point strong enough to mandate per AF 
activation ?

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, February 23, 2015 05:01
To: Pushpasis Sarkar; Jeff Tantsura; LITKOWSKI Stephane SCE/IBNF; rtgwg@ietf.org
Subject: RE: LFA manageability : per AF config => feedback required

Pushpassis -

From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Pushpasis Sarkar
Sent: Friday, February 20, 2015 3:28 AM
To: Jeff Tantsura; 
stephane.litkow...@orange.com; 
rtgwg@ietf.org
Subject: Re: LFA manageability : per AF config => feedback required

HI Jeff et al,

I can think of a reason to have a knob per-level(or per-area) or per ISIS 
topology(note in ISIS a topology in ISIS always corresponds to a single AF,)

[Les:] This is a common mistake to make. If one simply uses RFC 5308, then IPv6 
prefixes can be advertised in the same topology as IPv4 (MTID #0) - and there 
are implementations which support this. More generally, from the protocol's POV 
a given topology can support any combinations of address families. It is only a 
convention because of the reserved MTIDs specified in RFC 5120 that certain 
MTIDs are "IPv6 only". But if one looks at the protocol capabilities such a 
restriction does not exist in general.

Interestingly you contradicted yourself below. :)
But I did want to set the record straight on this point - hopefully we are in 
agreement.

and per realm and topology in OSPF. But I cannot think of a reason of why 
within the same topology we need another set of knobs for each AF. Here, by AF 
I understand IPV4 or IPv6.

When both IPV4 and IPV6 are part of the same IGP topology, there is only one 
set of backup computations needed to protect both IPV4 and IPv6 traffic.

Also I cannot think of any motivation for an operator to turn on protection on 
only one AF and does not want to turn on for the other even if both AFs has 
been deployed for normal forwarding.

[Les:] I think your point here is that the LFA calculation is AF independent 
within a given topology - but resources are consumed independent of how many 
computations are required- giving an operator the ability to determine which 
prefixes are most critical seems useful. That could be per AF or per prefix.

   Les

Thanks
-Pushpasis

From: Jeff Tantsura 
mailto:jeff.tants...@ericsson.com>>
Date: Friday, February 20, 2015 at 12:59 PM
To: "stephane.litkow...@orange.com" 
mailto:stephane.litkow...@orange.com>>, 
"rtgwg@ietf.org" mailto:rtgwg@ietf.org>>
Subject: Re: LFA manageability : per AF config => feedback required

Hi Stephane,

/chair hat off

IMO in disjoined topologies one should have flexibility to enable/disable LFA 
as per AF.


Cheers,
Jeff

From: "stephane.litkow...@orange.com" 
mailto:stephane.litkow...@orange.com>>
Date: Thursday, February 19, 2015 at 11:21 PM
To: "rtgwg@ietf.org" 
mailto:rtgwg@ietf.org>>
Subject: LFA manageability : per AF config => feedback required

Hi Folks,

As you know, LFA manageability draft is in final phasis ...
The current document states per AF granularity activation as a SHOULD.
"
5.1.
  LFA enabling/disabling scope





   The granularity of LFA activation should be controlled (as alternate

   nexthop consume memory in forwarding plane).



   An implementation of LFA SHOULD allow its activation with the

   following criteria:



   o  Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast,

  LDP IPv6 unicast ...



   o  Per routing context : VRF, virtual/logical router, global routing

  table, ...


"

In the framework of ISIS/OSPF yang modelization, we are challenging this 
statement, do we really need to force implementation to support this "per AF" 
granularity ?

Please provide as soon as possible your feedback on this and also provide clear 
drivers to support or not per AF activation of LFA.


Thanks for your help !


[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE
Orange Expert Future Networks
phone: +33 2 23 28 49 83 

mobile: +33 6 37 86 97 52 

RE: LFA manageability : per AF config => feedback required

[stephane.litkowski]

+1, I confirm the two different goals to achieve in the draft. As Les 
mentioned, implementing it both in a common policy framework or in two 
different features is implementation dependent.


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, February 23, 2015 07:42
To: Pushpasis Sarkar; Jeff Tantsura; LITKOWSKI Stephane SCE/IBNF; rtgwg@ietf.org
Subject: RE: LFA manageability : per AF config => feedback required

Pushpassis -

Conceptually, there are two different functionalities being discussed:

1)Supporting selection of what prefixes are eligible for protection. This is 
what Section 5.1 of the draft discusses.

2)For the set of prefixes which are eligible for protection, supporting policy 
to choose between multiple LFA candidates. This is discussed in Section 5.2 of 
the draft.

How you choose to implement this support is outside the scope of both the draft 
and this discussion.

Les


From: Pushpasis Sarkar [mailto:psar...@juniper.net]
Sent: Sunday, February 22, 2015 10:33 PM
To: Les Ginsberg (ginsberg); Jeff Tantsura; 
stephane.litkowski@orange.cothe<mailto:stephane.litkowski@orange.cothe> 
abiloity to limit the set of prefixes m; rtgwg@ietf.org<mailto:rtgwg@ietf.org>
Subject: Re: LFA manageability : per AF config => feedback required

Hi Les,

From: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>
Date: Monday, February 23, 2015 at 11:46 AM
To: Pushpasis Sarkar mailto:psar...@juniper.net>>, Jeff 
Tantsura mailto:jeff.tants...@ericsson.com>>, 
"stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>" 
mailto:stephane.litkow...@orange.com>>, 
"rtgwg@ietf.org<mailto:rtgwg@ietf.org>" mailto:rtgwg@ietf.org>>
Subject: RE: LFA manageability : per AF config => feedback required

[Les:] "backup-selection-policy" specifies which member of an LFA set should be 
preferred when there are multiple candidates for protecting a given prefix. 
What we are discussing here is controlling which prefixes are eligible for 
protection. These ae two different concepts.

[Pushpasis] Well, it is not only preferring. It can also be not-preferring-any 
(or pruning). So if no protection for any IPv6 is required, it can be achieved 
by a policy as belows:

Destination ipv6-all {
{
   Interface all
   {
   Neighbor exclude all;
   }
}


_

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: LFA manageability : per AF config => feedback required

[stephane.litkowski]

Hi Anton,

As I replied to Jeff, in case of disjoint topologies, we are no more related to 
per AF activation but more to a per topology activation which is different.

Regarding the "per-prefix" control, this is also proposed in the draft. Per-AF 
was added in order to have a simple mechanism to exclude a family of prefixes 
(sort of subset of per prefix).

Best Regards,

Stephane


-Original Message-
From: Anton Smirnov [mailto:asmir...@cisco.com] 
Sent: Friday, February 20, 2015 10:17
To: LITKOWSKI Stephane SCE/IBNF; rtgwg@ietf.org
Subject: Re: LFA manageability : per AF config => feedback required

Hi Stephane,
I think concern of "alternate nexthops consume resources in the forwarding 
plane" is generally a valid one. But if you want to solve
*this* problem then solution is to give to operator great flexibility to select 
set of prefixes which are allowed to have protection and this flexibility 
should go beyond of just per-AF selection.

Per-context selection would actually solve different problem - CPU 
resources needed to compute LFAs (which are spent per-topology independent of 
number of nexthops which end up being protected).

So IMO per-AF granularity might be useful (especially in disjoint
topologies) but reason given in the draft does not connect with the solution.

Anton


On 02/20/2015 08:21 AM, stephane.litkow...@orange.com wrote:
> Hi Folks,
>
> As you know, LFA manageability draft is in final phasis ...
>
> The current document states per AF granularity activation as a SHOULD.
>
> "
>
>
>   5.1
>   
> .
>   LFA enabling/disabling scope
>
>
>
>
>
> The granularity of LFA activation should be controlled (as 
> alternate
>
> nexthop consume memory in forwarding plane).
>
>
>
> An implementation of LFA SHOULD allow its activation with the
>
> following criteria:
>
>
>
> o  Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 
> unicast,
>
>LDP IPv6 unicast ...
>
>
>
> o  Per routing context : VRF, virtual/logical router, global 
> routing
>
>table, ...
>
>
>
> "
>
> In the framework of ISIS/OSPF yang modelization, we are challenging 
> this statement, do we really need to force implementation to support 
> this "per AF" granularity ?
>
> Please provide as soon as possible your feedback on this and also 
> provide clear drivers to support or not per AF activation of LFA.
>
> Thanks for your help !
>
> Orange logo 
>
> *Stephane Litkowski *
> Network Architect
> Orange/SCE/EQUANT/IBNF/ENDD/NDE
>
> Orange Expert Future Networks
>
> phone: +33 2 23 28 49 83
>  voice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefau
> lt%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
> mobile: +33 6 37 86 97 52
>  voice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefau
> lt%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
> stephane.litkow...@orange.com 
>
> __
> ___
>
> 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
>

_

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 a

RE: LFA manageability : per AF config => feedback required

[stephane.litkowski]

Hi Hannes,

You are right, maybe the text should be clarified. To be honest, this text part 
is old and I took a shortcut and mixing two things :)

First thing is really a per AF activation (ipv4 unicast, ipv6 unicast ...).

The second is do I need to protect "LDP routes" that are inheriting some IGP 
properties or do I consider that LDP is protected by something else (RSVP-TE :) 
).

Best regards,

Stephane


-Original Message-
From: Hannes Gredler [mailto:han...@juniper.net] 
Sent: Friday, February 20, 2015 10:27
To: Anton Smirnov
Cc: LITKOWSKI Stephane SCE/IBNF; rtgwg@ietf.org
Subject: Re: LFA manageability : per AF config => feedback required

hi anton, et al,

there is one more quirk to this:

i have never heard of _LDP_ adress families:

| >o  Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast,
| >   LDP IPv6 unicast ...
| >

so we're referring to something which does not exist - please see latest IANA 
registry:

http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml

/hannes

On Fri, Feb 20, 2015 at 10:17:03AM +0100, Anton Smirnov wrote:
|Hi Stephane,
|I think concern of "alternate nexthops consume resources in the 
| forwarding plane" is generally a valid one. But if you want to solve 
| *this* problem then solution is to give to operator great flexibility 
| to select set of prefixes which are allowed to have protection and 
| this flexibility should go beyond of just per-AF selection.
| 
|Per-context selection would actually solve different problem - CPU 
| resources needed to compute LFAs (which are spent per-topology 
| independent of number of nexthops which end up being protected).
| 
|So IMO per-AF granularity might be useful (especially in disjoint
| topologies) but reason given in the draft does not connect with the 
| solution.
| 
| Anton
| 
| 
| On 02/20/2015 08:21 AM, stephane.litkow...@orange.com wrote:
| >Hi Folks,
| >
| >As you know, LFA manageability draft is in final phasis …
| >
| >The current document states per AF granularity activation as a SHOULD.
| >
| >“
| >
| >
| >  5.1
| >  
.
| >  LFA enabling/disabling scope
| >
| >
| >
| >
| >
| >The granularity of LFA activation should be controlled (as 
| > alternate
| >
| >nexthop consume memory in forwarding plane).
| >
| >
| >
| >An implementation of LFA SHOULD allow its activation with the
| >
| >following criteria:
| >
| >
| >
| >o  Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 
| > unicast,
| >
| >   LDP IPv6 unicast ...
| >
| >
| >
| >o  Per routing context : VRF, virtual/logical router, global 
| > routing
| >
| >   table, ...
| >
| >
| >
| >“
| >
| >In the framework of ISIS/OSPF yang modelization, we are challenging 
| >this statement, do we really need to force implementation to support 
| >this “per AF” granularity ?
| >
| >Please provide as soon as possible your feedback on this and also 
| >provide clear drivers to support or not per AF activation of LFA.
| >
| >Thanks for your help !
| >
| >Orange logo 
| >
| >*Stephane Litkowski *
| >Network Architect
| >Orange/SCE/EQUANT/IBNF/ENDD/NDE
| >
| >Orange Expert Future Networks
| >
| >phone: +33 2 23 28 49 83
| >cvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddef
| >ault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
| >mobile: +33 6 37 86 97 52
| >cvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddef
| >ault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
| >stephane.litkow...@orange.com 
| >
| >_
| >
| >
| >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
|

RE: LFA manageability : per AF config => feedback required

[stephane.litkowski]

Hi Jeff,

Thanks for your feedback.

In case of disjoined topology, this is another subject, it's per topology 
activation, not really per AF.
Per topology activation is also mentioned in the draft as granularity.

Does it make sense ?

Best regards,


From: Jeff Tantsura [mailto:jeff.tants...@ericsson.com]
Sent: Friday, February 20, 2015 08:30
To: LITKOWSKI Stephane SCE/IBNF; rtgwg@ietf.org
Subject: Re: LFA manageability : per AF config => feedback required

Hi Stephane,

/chair hat off

IMO in disjoined topologies one should have flexibility to enable/disable LFA 
as per AF.


Cheers,
Jeff

From: "stephane.litkow...@orange.com" 
mailto:stephane.litkow...@orange.com>>
Date: Thursday, February 19, 2015 at 11:21 PM
To: "rtgwg@ietf.org" 
mailto:rtgwg@ietf.org>>
Subject: LFA manageability : per AF config => feedback required

Hi Folks,

As you know, LFA manageability draft is in final phasis ...
The current document states per AF granularity activation as a SHOULD.
"
5.1.
  LFA enabling/disabling scope





   The granularity of LFA activation should be controlled (as alternate

   nexthop consume memory in forwarding plane).



   An implementation of LFA SHOULD allow its activation with the

   following criteria:



   o  Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast,

  LDP IPv6 unicast ...



   o  Per routing context : VRF, virtual/logical router, global routing

  table, ...


"

In the framework of ISIS/OSPF yang modelization, we are challenging this 
statement, do we really need to force implementation to support this "per AF" 
granularity ?

Please provide as soon as possible your feedback on this and also provide clear 
drivers to support or not per AF activation of LFA.


Thanks for your help !


[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE
Orange Expert Future Networks
phone: +33 2 23 28 49 83 

mobile: +33 6 37 86 97 52 

stephane.litkow...@orange.com



_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

LFA manageability : per AF config => feedback required

[stephane.litkowski]

Hi Folks,

As you know, LFA manageability draft is in final phasis ...
The current document states per AF granularity activation as a SHOULD.
"
5.1.
  LFA enabling/disabling scope





   The granularity of LFA activation should be controlled (as alternate

   nexthop consume memory in forwarding plane).



   An implementation of LFA SHOULD allow its activation with the

   following criteria:



   o  Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast,

  LDP IPv6 unicast ...



   o  Per routing context : VRF, virtual/logical router, global routing

  table, ...


"

In the framework of ISIS/OSPF yang modelization, we are challenging this 
statement, do we really need to force implementation to support this "per AF" 
granularity ?

Please provide as soon as possible your feedback on this and also provide clear 
drivers to support or not per AF activation of LFA.


Thanks for your help !


[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE
Orange Expert Future Networks
phone: +33 2 23 28 49 83 

mobile: +33 6 37 86 97 52 

stephane.litkow...@orange.com



_

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

Survey for YANG model design : routing protocols CLI implementation

[stephane.litkowski]

Hi Folks,

A lot of us are currently working on Yang model drafts. In the framework of 
routing protocols related drafts, we have some discussion regarding how to 
model the configuration of routing protocols and especially do it need to be 
routing-instance centric or protocol centric (see slides for quick explanation 
of the difference). This is a cross protocol discussion, as we would like to 
apply the same design to all.

In order to decide how to progress on this major design point, one point  is to 
evaluate current implementations and how many are routing-instance centric and 
protocol centric. The famous implementations are well known, but we would like 
to have a more global view. This metric would be one among others.

In order to help us to do this inventory, could you please respond unicast to 
me, if you are an implementor and you have an implementation of a 
routing-protocol (ISIS,OSPF,RIP,BGP, PIM ... but also MPLS-TE, LDP, RSVP ...) 
and in this case, what is your CLI flavor ?

Please use this sample format, so it would be easier for me to aggregate :
(If you own multiple implementations, you can fill multiple lines.)


Vendor

OS

Protocol Centric

VRF centric

Cisco

IOS/IOS-XE

X





Thanks for your help !


[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE
Orange Expert Future Networks
phone: +33 2 23 28 49 83 

mobile: +33 6 37 86 97 52 

stephane.litkow...@orange.com



_

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.



VRF centric vs protocol centric - IETF.pptx
Description: VRF centric vs protocol centric - IETF.pptx
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

RE: [mpls] Survey for YANG model design : routing protocols CLI implementation

[stephane.litkowski]

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, February 10, 2015 13:26
To: o...@ietf.org; 
isis...@ietf.org list 
(isis...@ietf.org); 
m...@ietf.org; i...@ietf.org; 
rtgwg@ietf.org
Cc: rtg-yang-co...@ietf.org
Subject: [mpls] Survey for YANG model design : routing protocols CLI 
implementation
Importance: High

Hi Folks,

A lot of us are currently working on Yang model drafts. In the framework of 
routing protocols related drafts, we have some discussion regarding how to 
model the configuration of routing protocols and
especially do it need to be routing-instance centric or protocol centric. This 
is a cross protocol discussion, as we would like to apply the same design to 
all.

Example of routing-instance centric CLI : (Typically Juniper, ALU)
routing-instance R1 {
protocol isis {};
protocol ospf {};
protocol ldp {};
}
routing-instance R2 {
protocol isis {};
protocol ospf {};
protocol ldp {};
}

Example of protocol centric CLI : (Typically CISCO)
protocol isis {
routing-instance R1 {}
routing-instance R2 {}
}
protocol ospf {
routing-instance R1 {}
routing-instance R2 {}
}



In order to decide how to progress on this major design point, one point  is to 
evaluate current implementations and how many are routing-instance centric and 
protocol centric. The famous implementations are well known, but we would like 
to have a more global view. This metric would be one among others.

In order to help us to do this inventory, could you please respond unicast to 
me, if you are an implementor and you have an implementation of a 
routing-protocol (ISIS,OSPF,RIP,BGP, PIM ... but also MPLS-TE, LDP, RSVP ...) 
and in this case, what is your CLI flavor ?

Please use this sample format, so it would be easier for me to aggregate :
(If you own multiple implementations, you can fill multiple lines.)


Vendor

OS

Protocol Centric

VRF centric

Cisco

IOS/IOS-XE

X





Thanks for your help !


[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE
Orange Expert Future Networks
phone: +33 2 23 28 49 83 

mobile: +33 6 37 86 97 52 

stephane.litkow...@orange.com



_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__

RE: Working Group last call on draft-ietf-rtgwg-lfa-manageability

[stephane.litkowski]

Hi Folks,

First, I would like to wish you all the best for this new year !

I just posted a new version of the draft addressing the comment from Uma, we 
are inline with the proposed update.

http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-lfa-manageability-05.txt


Best Regards,

Stephane


-Original Message-
From: Jeff Tantsura [mailto:jeff.tants...@ericsson.com] 
Sent: Saturday, December 27, 2014 09:08
To: rtgwg@ietf.org; draft-ietf-rtgwg-lfa-manageabil...@tools.ietf.org
Cc: Alvaro Retana
Subject: Re: Working Group last call on draft-ietf-rtgwg-lfa-manageability

All,

Working Group last call has been closed, we have only recevied supporting 
responses. 
There has been comment posted (Uma C).
Could the authors please address, agree with the reviewers, confirm that they 
are ready to go ahead and request publication of the updated version of the 
document?


Happy New Year!

Cheers,
Jeff




-Original Message-
From: Jeff Tantsura 
Date: Monday, November 10, 2014 at 10:56 AM
To: "rtgwg@ietf.org" 
Cc: Alvaro Retana 
Subject: Working Group last call on draft-ietf-rtgwg-lfa-manageability

>All,
>
>We are starting a working group last call on the subject document.


_

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: [mpls] maturity of the MRT technology

[stephane.litkowski]

Hi Yakov,

Thanks to point this important subject.

Consider the case where you have a link failure, it is easy for our customers 
to understand that their traffic have been impacted because the traffic was 
crossing the link that has failed.
Now, if to protect this link, we enable FRR and FRR path uses an "uncontrolled" 
path. When the link fails, traffic is switched to FRR path and may use some 
paths that is not well sized to handle this traffic.
This may create congestion on some links. Congestion will affect traffic that 
is not directly concerned by the failure, so customer will loss some traffic. 
For sure, the congestion duration will be bound to the convergence time 
(~seconds), but for some critical applications (that are not essential 
requiring LLQ -> so QoS may not fully help in this, in customer data class is 
congestionned), this is not acceptable. And customers cannot understand that 
they are impacted by an issue in another region of the world. (It's like the 
well known "Butterfly effect" :) )
This problematic is quite similar to the microloop one. Microloops are 
impacting traffic which is not directly concerned by the failure. And globally 
we already had complains for both issues (FRR using bad path and microloops).

Hope it helps to understand our concern.

Best Regards,

Stephane

-Original Message-
From: Yakov Rekhter [mailto:ya...@juniper.net] 
Sent: Wednesday, December 03, 2014 15:25
To: LITKOWSKI Stephane SCE/IBNF
Cc: Uma Chunduri; Alia Atlas; Loa Andersson; m...@ietf.org; 
mpls-cha...@tools.ietf.org; draft-atlas-mpls-ldp-...@tools.ietf.org; 
rtgwg@ietf.org
Subject: Re: [mpls] maturity of the MRT technology 

Stephane,

On 23/11/2014 08:47, stephane.litkow...@orange.com wrote:
 
> Hi Uma,
>
> >Is this because of domain wide deployment requirements MRT brings-in
> (as elaborated by Stewart?) or you are ok with LFA/rLFA coverage in 
> the network?
>
> No, domain-wide deployment is not an issue. The issue I see in MRT 
> (for my use case) is unoptimality of the FRR path (at least using 
> lowpoint algorithm). But anyway, as I mentioned, I'm not opposed to 
> make MRT progressing at all. It's good to have multiple tools.

While MRT may result in "unoptimality of the FRR path", why this unoptimality 
really matters that much, given that FRR suppose to be used for only a short 
period of time until IGP convergence?

Yakov.

_

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: maturity of the MRT technology

[stephane.litkowski]

HI Uma,

> Is this because of domain wide deployment requirements MRT brings-in (as 
> elaborated by Stewart?) or you are ok with LFA/rLFA coverage in the network?

No, domain-wide deployment is not an issue. The issue I see in MRT (for my use 
case) is unoptimality of the FRR path (at least using lowpoint algorithm). But 
anyway, as I mentioned, I’m not opposed to make MRT progressing at all. It’s 
good to have multiple tools.

Best Regards,


From: Uma Chunduri [mailto:uma.chund...@ericsson.com]
Sent: Friday, November 21, 2014 20:37
To: LITKOWSKI Stephane SCE/IBNF; Alia Atlas; Loa Andersson
Cc: m...@ietf.org; mpls-cha...@tools.ietf.org; 
draft-atlas-mpls-ldp-...@tools.ietf.org; rtgwg@ietf.org
Subject: RE: maturity of the MRT technology

>I’m not a great supporter of MRT implementation in my network, because it does 
>not address correctly my use cases but despite of this,

Is this because of domain wide deployment requirements MRT brings-in (as 
elaborated by Stewart?) or you are ok with LFA/rLFA coverage in the network?

> I deeply think that it’s another item in the FRR toolchest (like LFA, remote 
> LFA …),
>it will be up to each Service Provider to choose the appropriate technology 
>based on its own use case/constraints.

I agree with above.  It depends on the particular deployment scenario and 
applicability for that network.

--
Uma C.

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Friday, November 21, 2014 1:23 AM
To: Alia Atlas; Loa Andersson
Cc: m...@ietf.org; 
mpls-cha...@tools.ietf.org; 
draft-atlas-mpls-ldp-...@tools.ietf.org;
 rtgwg@ietf.org
Subject: Re: [mpls] maturity of the MRT technology

+1

As for all FRR technologies, MRT has pros and cons, and this does not influence 
the maturity of the technical solutions. We already had multiple discussions 
online and offline on technical details leading now to documents that are quite 
detailed and well understood technology (with pros and cons as I mentioned). 
I’m not a great supporter of MRT implementation in my network, because it does 
not address correctly my use cases but despite of this, I deeply think that 
it’s another item in the FRR toolchest (like LFA, remote LFA …), it will be up 
to each Service Provider to choose the appropriate technology based on its own 
use case/constraints. Processing of MRT , IMHO, should be done as LFA and other 
similar technologies so standard track sounds good to me.

We already seen much less mature technologies going to standard track and being 
RFC without any running code after …

Best Regards,

Stephane


From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Alia Atlas
Sent: Thursday, November 20, 2014 19:17
To: Loa Andersson
Cc: m...@ietf.org; 
mpls-cha...@tools.ietf.org; 
draft-atlas-mpls-ldp-...@tools.ietf.org;
 VIGOUREUX, MARTIN (MARTIN); rtgwg@ietf.org
Subject: Re: maturity of the MRT technology

Loa,

Without any hats on, I would note:

a) As far as I'm aware, this has seen two independent prototypes implemented.
b) I have not heard any concrete technical concerns.  Stewart and I did 
specificallly
discuss MRT this past IETF.  I am, of course, quite interested in hearing any
concrete technical concerns.

c) I'd be happy seeing this question asked of more drafts :-)

Regards,
Alia


On Tue, Nov 18, 2014 at 7:08 PM, Loa Andersson mailto:l...@pi.nu>> 
wrote:
Working Groups,

We have don an MPLS-RT of draft-atlas-mpls-ldp-mrt, the reviews has been
posted to the mpls wg mailing list.

In his MPLS-RT review Stewart Bryant says:

"I have concerns about whether or not MRT technology has the  maturity
 expected in the standards track. However that decision needs to be
 taken in RTGWG and MPLS needs to follow their and lead in determining
 the fate and track of this draft. This draft should not be published
 ahead of the drafts that define the technology that it is supporting."

He also says that he see no reason not to go ahead and start the poll to
see if we have consensus to adopt the document as an mpls wg document.

The question Stewart ask is valid, and we'd like input from the rtgwg
and rtgwg chairs (copied on this mail). We will also copy both the
poll for adoption and the wglc to the rtgwg mailing list.

/Loa
mpls wg co-chair
--


Loa Anderssonemail: 
l...@mail01.huawei.com
Senior MPLS Expert  l...@pi.nu
Huawei Technologies (consultant) phone: +46 739 81 21 
64

___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg


__

RE: maturity of the MRT technology

[stephane.litkowski]

+1

As for all FRR technologies, MRT has pros and cons, and this does not influence 
the maturity of the technical solutions. We already had multiple discussions 
online and offline on technical details leading now to documents that are quite 
detailed and well understood technology (with pros and cons as I mentioned). 
I’m not a great supporter of MRT implementation in my network, because it does 
not address correctly my use cases but despite of this, I deeply think that 
it’s another item in the FRR toolchest (like LFA, remote LFA …), it will be up 
to each Service Provider to choose the appropriate technology based on its own 
use case/constraints. Processing of MRT , IMHO, should be done as LFA and other 
similar technologies so standard track sounds good to me.

We already seen much less mature technologies going to standard track and being 
RFC without any running code after …

Best Regards,

Stephane


From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Alia Atlas
Sent: Thursday, November 20, 2014 19:17
To: Loa Andersson
Cc: m...@ietf.org; mpls-cha...@tools.ietf.org; 
draft-atlas-mpls-ldp-...@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); 
rtgwg@ietf.org
Subject: Re: maturity of the MRT technology

Loa,

Without any hats on, I would note:

a) As far as I'm aware, this has seen two independent prototypes implemented.
b) I have not heard any concrete technical concerns.  Stewart and I did 
specificallly
discuss MRT this past IETF.  I am, of course, quite interested in hearing any
concrete technical concerns.

c) I'd be happy seeing this question asked of more drafts :-)

Regards,
Alia


On Tue, Nov 18, 2014 at 7:08 PM, Loa Andersson mailto:l...@pi.nu>> 
wrote:
Working Groups,

We have don an MPLS-RT of draft-atlas-mpls-ldp-mrt, the reviews has been
posted to the mpls wg mailing list.

In his MPLS-RT review Stewart Bryant says:

"I have concerns about whether or not MRT technology has the  maturity
 expected in the standards track. However that decision needs to be
 taken in RTGWG and MPLS needs to follow their and lead in determining
 the fate and track of this draft. This draft should not be published
 ahead of the drafts that define the technology that it is supporting."

He also says that he see no reason not to go ahead and start the poll to
see if we have consensus to adopt the document as an mpls wg document.

The question Stewart ask is valid, and we'd like input from the rtgwg
and rtgwg chairs (copied on this mail). We will also copy both the
poll for adoption and the wglc to the rtgwg mailing list.

/Loa
mpls wg co-chair
--


Loa Anderssonemail: 
l...@mail01.huawei.com
Senior MPLS Expert  l...@pi.nu
Huawei Technologies (consultant) phone: +46 739 81 21 
64

___
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: Working Group last call on draft-ietf-rtgwg-lfa-manageability - IPR

[stephane.litkowski]

Hi Jeff,

I'm not aware of any IPR related to this draft.

Stephane


-Original Message-
From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Monday, November 10, 2014 21:54
To: rtgwg@ietf.org
Subject: Working Group last call on draft-ietf-rtgwg-lfa-manageability - IPR

All,

In parallel to the WGLC for this draft, I want to formally ask the authors (no 
additional contributors are listed in the latest version of the draft) to 
please respond to this message indicating whether or not you are aware of any 
relevant IPR.  The draft will not progress (pending the results of the WGLC) 
until we have received a response from each author.


In addition, we wanted to take this opportunity to remind the entire WG that 
the duty of disclosure is NOT limited to authors:

   (c) in order for the working group and the rest of the IETF to have
   the information needed to make an informed decision about the use
   of a particular technology, all those contributing to the working
   group's discussions must disclose the existence of any IPR the
   Contributor or other IETF participant believes Covers or may
   ultimately Cover the technology under discussion.  This applies
   to both Contributors and other participants, and applies whether
   they contribute in person, via email or by other means.  The
   requirement applies to all IPR of the participant, the
   participant's employer, sponsor, or others represented by the
   participants, that is reasonably and personally known to the
   participant.  No patent search is required.

RFC 3979 also points out disclosure must be "as soon as reasonably
possible":

   The IPR disclosure required pursuant to section 6.1.1 must be made as
   soon as reasonably possible after the Contribution is published in an
   Internet Draft unless the required disclosure is already on file.

Thank you!



Cheers,
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 adoption request for draft-litkowski-rtgwg-spf-uloop-pb-statement / draft-decraene-rtgwg-backoff-algo

[stephane.litkowski]

Sure, but the request was for chairs to launch a poll if they agree :)


From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, August 01, 2014 15:57
To: LITKOWSKI Stephane SCE/IBNF; rtgwg@ietf.org
Subject: Re: WG adoption request for 
draft-litkowski-rtgwg-spf-uloop-pb-statement / draft-decraene-rtgwg-backoff-algo

Hi Stephane,
I have some positive views on these drafts but it is normally the chairs that 
poll for WG adoption.
Thanks,
Acee

From: Stephane Litkowski 
mailto:stephane.litkow...@orange.com>>
Date: Friday, August 1, 2014 at 3:52 AM
To: "rtgwg@ietf.org" 
mailto:rtgwg@ietf.org>>
Subject: WG adoption request for draft-litkowski-rtgwg-spf-uloop-pb-statement / 
draft-decraene-rtgwg-backoff-algo

Dear all,

Following the two presentations in Toronto, the fruitful discussions in the 
meeting, the hallways and on the mailing list we'd like to request WG adoption 
of
15:30-15:40 - 
draft-litkowski-rtgwg-spf-uloop-pb-statement
15:40-15:50 - 
draft-decraene-rtgwg-backoff-algo

Thanks,
Best regards,
Stéphane, Bruno




_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

WG adoption request for draft-litkowski-rtgwg-spf-uloop-pb-statement / draft-decraene-rtgwg-backoff-algo

[stephane.litkowski]

Dear all,

Following the two presentations in Toronto, the fruitful discussions in the 
meeting, the hallways and on the mailing list we'd like to request WG adoption 
of
15:30-15:40 - 
draft-litkowski-rtgwg-spf-uloop-pb-statement
15:40-15:50 - 
draft-decraene-rtgwg-backoff-algo

Thanks,
Best regards,
Stéphane, Bruno




_

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: On minimizing SPF backoff induced blackouts

[stephane.litkowski]

More inline ...

-Original Message-
From: Hannes Gredler [mailto:han...@juniper.net] 
Sent: Monday, July 28, 2014 17:07
To: LITKOWSKI Stephane SCE/IBNF
Cc: DECRAENE Bruno IMT/OLN; Russ White; rtgwg@ietf.org
Subject: Re: On minimizing SPF backoff induced blackouts

On Fri, Jul 25, 2014 at 04:43:15PM +, stephane.litkow...@orange.com wrote:
| I agree with you at now routers are able to handle multiple events in a short 
time but anyway :
| - delaying is always necessary (I can't really see how we can go under 
100/150ms) :

the only reason it is necessary is that some implementations (ours included) do 
some state compression, such that there is a collection window of 20ms of 
local-events. strictly speaking thats just a efficiency/responsiveness tradeoff 
and we got some requests in the past to lower that window.

|   If you go to something like 0 or 5 msec, we may fall into 
| implementations issues with constant READ/WRITE contentions in FIB 
| that often cause corner cases where the router is completely lost in 
| what it must do

again thats implementation dependent. if you have now state-compression on your 
RIB/FIB path then you're doomed anyway. state of the art is that you do not 
de-queue route 'N(t)' if route 'N(t+1)' is available, but cancel N(t) update.

|   Moreover in case of complex outage (node failure or SRLG failure) where 
multiple LSPs are sent. We must ensure that all LSPs are received before 
computing SPF to ensure that the target topology is a good one.

see and this i do not believe is possible.
whatever  SPF initial wait will be, there will be always incidents where the 
LSP triggers arrives after , so there will be always corner cases for loops.

[SLI] Right, there may always be some corner case, but I think the number of 
occurences is low ... I can only think because we do not have statistics yet 
from routers :)

| - Increasing delay is also necessary. By experience there are 
| situations where you need absolutely to calm down computation to 
| prevent churn amplification (even today with stronger CPUs)

no doubt - the question is when do we need to kick in that self-protection 
layer ... is it after reception of the 2nd LSP or after the 10th ?

[SLI] That's the good question :) We are doing such tuning by experience for 
years now.
The only point is that the behavior must be aligned between all nodes and 
trying to figure out worst case (slowest routers)


| - we need to ensure that increasing delay steps are not so big, so in case of 
router unsynchronization (in delay value), the difference would be small.
| - as agreed , we can run more fast scheduled SPFs
| 
| Both current implementations (two steps and backoff) do no fill these 
"requirements".

rapid-run in a certain way does because it is widening your window of 
'concurrent, unrelated network events'
without going into backup mode.

[SLI] Right, but the gap between rapid-run and backup-mode is really high.


| I would be in favor of standardizing something really simple with no 
mathematic underway. Just extend the two steps to an N-Step tunable system that 
the operator can manage.
| Something like defining a WRED profile but without interpolation.
| Example :
| 
| Initial : 100 ms, 4 runs
| 2nd : 200ms, 2 runs
| 3rd : 300ms, 2 runs
| 4th : 500ms, 2 runs
| 5th : 700ms, 2 runs
| 6th : 800ms, 2 runs
| 7th : 1s, all subsequent runs

as tony (and others) have pointed out ... it will only work during nice-weather 
conditions ... as soon as you have the perfect-storm, you will have micro loops 
(and all the pain you try to protect yourself) - therefore i'd be much more in 
favour of 'something else' which gets us to zero uloops, and for that i am 
afraid we need to have the notions of independent forwarding planes (ala make 
before break) -

trying to synchronize RIB/FIB update across different 
CPUs/routing-stacks/vendors/load conditions is a battle that can never be won.

[SLI] This is not a definitive solution for microloops, just a simple quick win 
to remove somes.
I'm still dreaming on a simple definitive solution ... but I don't see any ... 
oFIB or synchronized FIBs sounds to not really have a good of support for 
implementations ...
In the meantime, I do think there are small and fast areas of improvments even 
if not definitive solutions. 


Stephane


| -Original Message-
| From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Hannes 
| Gredler
| Sent: Thursday, July 24, 2014 15:03
| To: DECRAENE Bruno IMT/OLN; Russ White
| Cc: rtgwg@ietf.org
| Subject: RE: On minimizing SPF backoff induced blackouts
| 
| hi bruno,
| 
| IMO the problem that you're trying to solve is to have the routers still 
being responsive when multiple events are happening in the network.
| 
| wouldn't then a simple fix be to kick the SPF pacing logic at a much 
| more later point in time ? - i.e. rather than slowing down things down 
| on event #2 or #3, do it at event # (please insert you're favorite 
| number

RE: On minimizing SPF backoff induced blackouts

[stephane.litkowski]

Hannes,

I agree with you at now routers are able to handle multiple events in a short 
time but anyway :
- delaying is always necessary (I can't really see how we can go under 
100/150ms) :
If you go to something like 0 or 5 msec, we may fall into 
implementations issues with constant READ/WRITE contentions in FIB that often 
cause corner cases where the router is completely lost in what it must do
Moreover in case of complex outage (node failure or SRLG failure) where 
multiple LSPs are sent. We must ensure that all LSPs are received before 
computing SPF to ensure that the target topology is a good one.

- Increasing delay is also necessary. By experience there are situations where 
you need absolutely to calm down computation to prevent churn amplification 
(even today with stronger CPUs)
- we need to ensure that increasing delay steps are not so big, so in case of 
router unsynchronization (in delay value), the difference would be small.
- as agreed , we can run more fast scheduled SPFs

Both current implementations (two steps and backoff) do no fill these 
"requirements".

I would be in favor of standardizing something really simple with no mathematic 
underway. Just extend the two steps to an N-Step tunable system that the 
operator can manage.
Something like defining a WRED profile but without interpolation.
Example :

Initial : 100 ms, 4 runs
2nd : 200ms, 2 runs
3rd : 300ms, 2 runs
4th : 500ms, 2 runs
5th : 700ms, 2 runs
6th : 800ms, 2 runs
7th : 1s, all subsequent runs



-Original Message-
From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Hannes Gredler
Sent: Thursday, July 24, 2014 15:03
To: DECRAENE Bruno IMT/OLN; Russ White
Cc: rtgwg@ietf.org
Subject: RE: On minimizing SPF backoff induced blackouts

hi bruno,

IMO the problem that you're trying to solve is to have the routers still being 
responsive when multiple events are happening in the network.

wouldn't then a simple fix be to kick the SPF pacing logic at a much more later 
point in time ? - i.e. rather than slowing down things down on event #2 or #3, 
do it at event # (please insert you're favorite number for )

/hannes


From: rtgwg  on behalf of bruno.decra...@orange.com 

Sent: Thursday, July 24, 2014 20:56
To: Russ White
Cc: rtgwg@ietf.org
Subject: RE: On minimizing SPF backoff induced blackouts

> > I'm willing to be persuaded, I just don't see the argument for 
> > specifying an algorithm with what's been put on the table to this point.
>
> Ok. So I guess my presentation/draft was not clear enough.

Let me try again.
In slide 5: http://tools.ietf.org/agenda/90/slides/slides-90-rtgwg-2.pdf
- do we agree that it would be better if node A and B both schedule their SPF 
at roughly the same time? i.e. wait for the same duration?
- if so, what would be your proposition?

Bruno


_

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

___
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.

RE: On minimizing SPF backoff induced blackouts

[stephane.litkowski]

Hannes,

" if an implementation and the system around it is properly designed"
-> This is exactly what SP are trying to be protected against (bad 
implementations) :)

Can every vendor sign with blood that their implementation and system are 
properly designed for all situations ... unfortunately (for us) I don't think 
so :)


Stephane


-Original Message-
From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Hannes Gredler
Sent: Thursday, July 24, 2014 08:36
To: rtgwg@ietf.org
Subject: On minimizing SPF backoff induced blackouts

hi RTGWG,

some old presentation from Dave Katz on backoff and timing.
https://www.nanog.org/meetings/nanog25/presentations/katz.ppt
[courtesy Chris Bowers for digging it up ...]

slide 15 is of particular interest - says that if an implementation and the 
system around it is properly designed then no backoff should be required.

/hannes

___
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: draft-decraene-rtgwg-backoff-algo-00.txt

[stephane.litkowski]

Hi Uma,

Thanks for the comment and your support.
Pls find inline comments.

-Original Message-
From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Uma Chunduri
Sent: Wednesday, July 23, 2014 22:43
To: DECRAENE Bruno IMT/OLN; rtgwg@ietf.org
Subject: RE: draft-decraene-rtgwg-backoff-algo-00.txt

Dear  Bruno, Stephane,

> my understanding is that all commenters agreed that having a 
> standardized algorithm would be better as it would allow all routers 
> in a network to compute the same SPF delay

Sure, It's fine to have a uniform mandatory SPF trigger algorithm.

But I would note the for the  link failure examples described in  
https://datatracker.ietf.org/doc/draft-litkowski-rtgwg-spf-uloop-pb-statement/?include_text=1
 (Section 2) we have LFA's which can serve us  till the re-convergence happens.

[SLI] No , unfortunately LFA (nor RSVP-TE link protect for monohop tunnels) 
would help in this ... As soon as S converges, S would stop using LFA and may 
fall into a loop to E.


Also : In Section 3 you said -

  2.  Run only Full SPF when required : e.g. if a link fails, a local
   node will run an SPF for its local LSP update.  If the LSP from
   the neighbor (describing the same failure) is received after SPF
   has started, the local node can decide that a new full SPF is not
   required as the topology has not change.

   3.  If topology does not change, only recompute reachability.


As we all agree it's very cheap to compute SPF (especially when we are doing 
100's LFA/remote LFA SPFs for each primary SPF) today; in that context we 
should not be picky on primary SPF (Partial/Full). 
Just to give an example,  due to multi-homed prefixes in the network, if we do 
incorrect computation to save few mill-seconds this can last till the next 
trigger comes!
So I would request to avoid above discussion in this context, as that is not 
the main point of the draft/what you are seeking.

[SLI] That was not my point ... we have an agreement that SPF is cheap. But the 
issue may come from timer management and when to trigger SPF. If 
implementations are using different strategies, they will be misaligned in term 
of delay timer values for a particular sequence of event. SPF duration is not 
involved there ... 



--
Uma C.


-Original Message-
From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Wednesday, July 23, 2014 4:25 PM
To: rtgwg@ietf.org
Subject: RE: draft-decraene-rtgwg-backoff-algo-00.txt

Hi all,

Today's presentations have triggered many interesting feedback and comment 
(which is good, many thanks for your time) but time has not allowed discussing 
all the comments (a) nor summarizing the feedbacks (b).

Regarding a), could you please post your additional comments on the list? (or 
emailed them privately if preferred) As all comments are welcomed.

Regarding b), my understanding is that all commenters agreed that having a 
standardized algorithm would be better as it would allow all routers in a 
network to compute the same SPF delay (*).
Please correct me if I'm wrong.

Thanks,
Regards,
Bruno, Stéphane

(*) assuming that the network owner has configured the same parameters on all 
routers; but this is orthogonal.

> From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of
> 
> Hi all,
> 
> Please find below a proposed short draft which:
> -a- calls for a standardized SPF back-off algorithm, for 
> interoperability purpose
> -b- proposes an algorithm
> 
> Comments are welcomed.
> 
> Note that v00 currently proposes the algorithm which is the most 
> deployed. I would be fine with any modification, based on WG consensus 
> (assuming WG adoption).
> 
> Thanks,
> Regards,
> Bruno
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Thursday, July 03, 2014 12:16 PM
> 
> A new version of I-D, draft-decraene-rtgwg-backoff-algo-00.txt
> has been successfully submitted by Bruno Decraene and posted to the 
> IETF repository.
> 
> Name: draft-decraene-rtgwg-backoff-algo
> Revision: 00
> Title:Back-off SPF algorithm for link state IGP
> Document date:2014-07-03
> Group:Individual Submission
> Pages:5
> URL:http://www.ietf.org/internet-drafts/draft-decraene-rtgwg-
> backoff-algo-00.txt
> Status: https://datatracker.ietf.org/doc/draft-decraene-rtgwg-backoff-
> algo/
> Htmlized:   http://tools.ietf.org/html/draft-decraene-rtgwg-backoff-algo-
> 00
> 
> 
> Abstract:
>This document defines a standard algorithm to back-off link-state IGP
>SPF computations.
> 
>This improves interoperability by reducing the probability and/or
>duration of transient forwarding loops during the IGP convergence in
>the area/level when the network reacts to multiple consecutive
>events.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until th

FW: New Version Notification for draft-litkowski-rtgwg-spf-uloop-pb-statement-00.txt

[stephane.litkowski]

Hi RTGWGers, 

Here is a problem statement draft showing the impact of using different SPF 
strategies in link state IGP protocols.

Comments are welcome.

Stephane


-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Friday, June 27, 2014 14:09
To: LITKOWSKI Stephane SCE/IBNF; LITKOWSKI Stephane SCE/IBNF
Subject: New Version Notification for 
draft-litkowski-rtgwg-spf-uloop-pb-statement-00.txt


A new version of I-D, draft-litkowski-rtgwg-spf-uloop-pb-statement-00.txt
has been successfully submitted by Stephane Litkowski and posted to the IETF 
repository.

Name:   draft-litkowski-rtgwg-spf-uloop-pb-statement
Revision:   00
Title:  Link State protocols SPF trigger and delay algorithm impact on 
IGP microloops
Document date:  2014-06-27
Group:  Individual Submission
Pages:  12
URL:
http://www.ietf.org/internet-drafts/draft-litkowski-rtgwg-spf-uloop-pb-statement-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-litkowski-rtgwg-spf-uloop-pb-statement/
Htmlized:   
http://tools.ietf.org/html/draft-litkowski-rtgwg-spf-uloop-pb-statement-00


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 in a first step.



  


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.

The IETF Secretariat


_

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

draft-ietf-rtgwg-lfa-manageability WGLC ?

[stephane.litkowski]

Hi WG chairs,


Did you have a chance to look at the last version of the document ? We would 
like to make this document progressing and we think it may be ready for WGLC 
and  if you (or anyone else) have any point to raise, we would be happy to 
address it.

Thanks,

Stephane



_

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: I-D Action: draft-ietf-rtgwg-ipfrr-ip-mib-03.txt

[stephane.litkowski]

Ok thanks Bruno

I will take this into account.


-Message d'origine-
De : DECRAENE Bruno IMT/OLN 
Envoyé : vendredi 30 mai 2014 14:36
À : LITKOWSKI Stephane SCE/IBNF; rtgwg@ietf.org
Objet : RE: I-D Action: draft-ietf-rtgwg-ipfrr-ip-mib-03.txt

Hi Stéphane,

Please see 1 point inline

 
> Hi Stéphane,
> 
> Looks good, thanks.
> 
> I have a question related to object "ipFrrAltType"
> 
> >   loopFreeRemote (4), -- remote loop free alternate
> >   loopFreeTunnel (5), -- loop free alternate using a configured 
> > tunnel
> 
> >   loopFreeRemote : remote LFA as described in 
> > draft-ietf-rtgwg-remote-
> lfa
> >   loopFreeTunnel : remote LFA reachable through a RSVP-TE or GRE 
> > tunnel
> 
> It's not clear to me what exactly is the difference between 
> loopFreeRemote and loopFreeTunnel:
> Is this the type of tunnels: explicitly routed (i.e. RSVP-TE) vs 
> following the shortest path (i.e. LDP, GRE, 
> draft-ietf-rtgwg-remote-lfa Is this the determination of the required 
> tunnels: automatically computed (i.e. draft- ietf-rtgwg-remote-lfa, 
> automatic RSVP-TE LSP bypass tunnel to the next-
> hop) vs configured.
> 
> 
> 
> Current description seems to mix both aspects.
> 
> [SLI] Good point ! :) I had some concern to express this ... the idea 
> was to differentiate rLFA alternates (based on the draft) from other 
> tunneled alternate. If you have a good way to express it , I will take it ...
> 
> > loopFreeTI : remote LFA reachable through a SPRING tunnel
> To some expect, the question also applies to "loopFreeTI" where there 
> is a mix of FRR algorithm (how is the alternate computed i.e. TI FRR) 
> and the type of tunnels to reach the alternate (here SPRING tunnels, 
> while in theory the alternate could equally be reached using a 
> RSVP-TE+ T-LDP tunnels
> 
> I'm open to any solution. IMHO the description of the FRR algo is the 
> more
> important:
>   ipFrrAltType OBJECT-TYPE
>   SYNTAX   INTEGER {
>   other (1), -- type not defined
>   equalCost (2), -- primary path
>   loopFreeConnected  (3), -- loop free connected 
> alternate
> (LFA)
>   loopFreeRemote(4), -- remote loop free alternate 
> (RLFA)
>   loopFreeNH(5), -- loop free alternate using a 
> tunnel toward the
> Next Hop
>   loopFreeNNH(6), -- loop free alternate using a 
> tunnel toward
> the Next Next Hop
>   loopFreeTI(7), -- loop free alternate using 
> topology
> independent algorithm
>   mrt   (8)  -- Maximally Redundant Trees
>}
> 
> [SLI] Agree, but in your proposal what is exactly loopFreeNH and 
> loopFreeNNH ?

loopFreeNH or may be "Next Hop" :  Next Hop (5), -- loop free alternate using 
an explicitly routed  tunnel toward the original Next Hop (link protection 
only) This typically what is offered by a single hop RSVP-TE LSP over the 
protected link.

NextNextHop(5), -- loop free alternate using an explicitly routed  tunnel 
toward the original Next Next Hop

By "original Next Hop" I mean the Next Hop in the current IGP topology (aka 
"old" during FRR activation/pre failure)

Thanks,
Bruno

 
> If you believe that we also need the type of tunnels/forwarding 
> infrastructure, another object could be added
>   ipFrrTunnType OBJECT-TYPE
>   SYNTAX   INTEGER {
>   other (1), -- type not defined
>   LDP (2)
>   IP  (3),  GRE, L2TP...
>   RSVP-TE   (4)
>   SPRING MPLS  (5)
>   SPRING IPv6  (6)
>   Multi-topology (7)
>}
> 
> [SLI] Yes , this may be very interesting, I will add it.
> 
> 
> Bruno
> 
> > -Original Message-
> > From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of 
> > stephane.litkow...@orange.com
> > Sent: Wednesday, May 28, 2014 9:18 AM
> > To: rtgwg@ietf.org
> > Subject: FW: I-D Action: draft-ietf-rtgwg-ipfrr-ip-mib-03.txt
> >
> > Hi all,
> >
> > To followup discussion in London, I updated the IP FRR MIB draft 
> > with some new things :
> > - different objects for IPv4 and IPv6 protection stats
> > - Interface configuration table
> > - IPFRR instance table as we may expect to have multiple flavors 
> > running on a common node
> > - Protectstats per instance table.
> > - Few other things
> >
> > Feel free to comment and propose addings/corrections.
> >
> >
> > Stephane
> >
> >
> >
> > -Original Message-
> > From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf 
> > Of internet-dra...@ietf.org
> > Sent: Tuesday, May 27, 2014 23:36
> > To: i-d-annou...@ietf.org
> > Cc: rtgwg@ietf.org
> > Subject: I-D Action: draft-ietf-rtgwg-ipfrr-ip-mib-03.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Dr