Re: working group adoption poll for draft-mirsky-bfd-p2mp-vrrp-use-case

[Chris Bowers]

RTGWG,

This WG adoption poll ended last Friday.

One author and one non-author expressed support for adoption,
while no one expressed opposition to adoption. This adoption poll did
not produce any discussion or detailed feedback from anyone about the
draft itself.

I think there needs to be more technical discussion about the mechanism
proposed in this draft on the RTGWG list before consensus can be judged
either way.  I would encourage anyone interested in working on the
mechanism proposed in this draft to provide detailed feedback on the list.

Thanks,
Chris


On Wed, Jun 20, 2018 at 11:46 AM, Chris Bowers 
wrote:

> RTGWG,
>
> The authors of draft-mirsky-bfd-p2mp-vrrp-use-case have requested
> that RTGWG adopt this draft as a WG document.
> https://datatracker.ietf.org/doc/draft-mirsky-bfd-p2mp-vrrp-use-case/
>
> Please indicate whether or not you support adoption of the draft
> as a WG document.  An explanation of why or why not is also very helpful.
>
> The two authors have already indicated that they know of no relevant IPR
> other than what has already been disclosed. The draft has two IPR
> disclosures.
> https://datatracker.ietf.org/ipr/3133/
> https://datatracker.ietf.org/ipr/3135/
>
> For some history related to this draft, please see:
> https://www.ietf.org/mail-archive/web/rtgwg/current/msg06572.html
>
> For information about IPR in IETF technology, see RFC 8179.
> https://datatracker.ietf.org/doc/rfc8179/
>
> Note that one of the basic principles regarding how the IETF deals with
> IPR claims (from RFC 8179)
> is that: "The IETF will make no determination about the validity of any
> particular IPR claim."
>
> Since Jeff Tantsura is a co-author, he will not be involved in judging
> consensus.
>
> The closing date for this poll is Friday, July 6th.
>
> Thanks,
> Chris
>
>
>
>
>
___
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

[bruno.decraene]

Please see inline [Bruno2]

From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
Sent: Thursday, July 12, 2018 3:29 PM

On 12/07/2018 10:49, 
bruno.decra...@orange.com wrote:
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.
Correct

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.
That is not the point I am making.

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?
Correct, but you miss the point I am making.

The draft goes to considerable effort to constrain the FRR path to the path 
that the traffic arriving at the PLR will take post failure. However, the point 
illustrated by the network fragment is that not all that traffic benefits from 
that effort. In the draft you assert post convergence advantage to you 
approach, but do not seem to make it clear that this is a partial benefit and 
not a universal benefit.

[Bruno2] May be the term “post convergence” is misleading as it may refers to 
IGP convergence, while the draft is limited to a fast re-route solution. i.e. 
reaction of the PLR. FRR coverage is limited to 1) traffic reaching the PLR 2) 
before the IGP convergence. Within this FRR limit, the benefit applies to all 
this traffic.
But you are right that this is not all the traffic in the network, and the text 
needs to be updated if this is not clear enough



Depending on the specific advantage of constraining the path, this might be 
worth the complexity, or it might be better to use RLFA, or MRT or any one of 
the other technologies.

Also you really need to make it much clearer that the uloop avoidance 
properties (a big selling point of this technology) only apply to the traffic 
that will continue to arrive at C and that if any traffic will take another 
path you MUST implement an avoidance strategy.

[Bruno2] Again this draft is limited to IP FRR. As you stated, there is no 
loops during FRR, except when the failure is more expected than 
assumed/computed for.
Micro-loops happen during the sub-sequent IGP convergence which is out of scope 
of this FRR document. There is another draft about avoiding the micro-loop 
during the IGP convergence (draft-bashandy-rtgwg-segment-routing-uloop). Same 
issue with RLFA https://tools.ietf.org/html/rfc7490#section-10

I personally tend to agree with you that micro-loop avoidance is a must, but 
that is not the formulation used in the RLFA RFC: “If it is determined that 
micro-loops are a significant issue in the deployment, then a suitable 
loop-free convergence method, such as one of those described in 
[RFC5715], 
[RFC6976], or 
[ULOOP-DELAY], should be 
implemented.” For consistency, I’d rather favor reusing the same sentence 
(although 

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

[Alexander Vainshtein]

Bruno,
Lots of thanks for your prompt and clarifying response.

I am also trying to differentiate between technical behavior and “motivation” 
claims. This is not always easy.

Stephane has provided a pointer to RFC 7916 that lists lowest IGP metric of the 
repair path as one of the mandatory criteria for selecting LFA/RLFA.

Is this roughly equivalent to your statement that “the shortest path from the 
PLR to the destination is the best path (that we can choose from)”?

If yes, then it would make sense to me state that TI-LFA should use this (and 
all other) criteria and techniques defined in RFC 7916 (and include a Normative 
reference to it, of course).


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 3:07 PM
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:26 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,
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?
[Bruno] I think we should distinguish 2 aspects:
a) the technical behavior
b) the text/claims in the draft

My answer was about “a”. I see that you are not challenging it.
Regarding “b”, speaking for myself, I’m primarily interesting in the technical 
specification, less about the text introduced to motivate the solution. That 
being said:
1) If it were up to me, I would personally be very open to completely rewrite 
the text you cited. e.g. using my text ;-) (below).
2) I mostly agree with you. Although possibly the text could be rephrased to 
say that it refers to the local behavior on the PLR rather than the end to end 
path in the network. Also, capacity planning is very topology dependent and SP 
dependent. Here, Stewart’s example is custom-built to highlight a case where 
capacity planning for TI-LFA is different than capacity planning for link 
failure. I personally don’t find the example very typical of real network, as 
typically it’s more efficient to try to share the backup capacity for both link 
and node failure, which is not the case in the example.
That being said, the example is good enough to say that the capacity planning 
claim is not guaranteed. Again, cf my point 1. i.e. I support changing this 
text.

Coming back to the technical behavior, if we agree that using the shortest path 
from the PLR to the destination is the best path (that we can choose from) 
that’s good enough for me.

Regards,

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

[Alexander Vainshtein]

Hi all,
I concur with Stewart regarding the way to move forward with the draft.

I defer to the RTGWG chairs regarding the decision to adopt the draft now or 
after the new version is posted.

Regards,
Sasha

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

From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
Sent: Thursday, July 12, 2018 4:39 PM
To: bruno.decra...@orange.com; 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 
Subject: Re: Request for RTGWG Working Group adoption for 
draft-bashandy-rtgwg-segment-routing-ti-lfa



So, it sounds like we need a new version of the draft clarifying the solution's 
characteristics and allowing the reader to evaluate its applicability to their 
specific network problem.

Publishing an updated text fully addressing the review comments and putting it 
back to the WG for review of the revised draft would seem to be the way forward.

Best Regards

Stewart

On 12/07/2018 13:06, 
bruno.decra...@orange.com wrote:
Sasha,

Please see inline [Bruno]

From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Thursday, July 12, 2018 1:26 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,
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?
[Bruno] I think we should distinguish 2 aspects:
a) the technical behavior
b) the text/claims in the draft

My answer was about “a”. I see that you are not challenging it.
Regarding “b”, speaking for myself, I’m primarily interesting in the technical 
specification, less about the text introduced to motivate the solution. That 
being said:
1) If it were up to me, I would personally be very open to completely rewrite 
the text you cited. e.g. using my text ;-) (below).
2) I mostly agree with you. Although possibly the text could be rephrased to 
say that it refers to the local behavior on the PLR rather than the end to end 
path in the network. Also, capacity planning is very topology dependent and SP 
dependent. Here, Stewart’s example is custom-built to highlight a case where 
capacity planning for TI-LFA is different than capacity planning for link 
failure. I personally don’t find the example very typical of real network, as 
typically it’s more efficient to try to share the backup capacity for both link 
and node failure, which is not the case in the example.
That being said, the example is good enough to say that the capacity planning 
claim is not guaranteed. Again, cf my point 1. i.e. I support changing this 
text.

Coming back to the technical behavior, if we agree that using the shortest path 
from the PLR to the destination is the best path (that we can choose from) 
that’s good enough for me.

Regards,
--Bruno

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

[Stewart Bryant]

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

[Stewart Bryant]

So, it sounds like we need a new version of the draft clarifying the 
solution's characteristics and allowing the reader to evaluate its 
applicability to their specific network problem.


Publishing an updated text fully addressing the review comments and 
putting it back to the WG for review of the revised draft would seem to 
be the way forward.


Best Regards

Stewart


On 12/07/2018 13:06, bruno.decra...@orange.com wrote:


Sasha,

Please see inline [Bruno]

*From:*Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
*Sent:* Thursday, July 12, 2018 1:26 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,

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?

[Bruno] I think we should distinguish 2 aspects:

a) the technical behavior

b) the text/claims in the draft

My answer was about “a”. I see that you are not challenging it.

Regarding “b”, speaking for myself, I’m primarily interesting in the 
technical specification, less about the text introduced to motivate 
the solution. That being said:


1) If it were up to me, I would personally be very open to completely 
rewrite the text you cited. e.g. using my text ;-) (below).


2) I mostly agree with you. Although possibly the text could be 
rephrased to say that it refers to the local behavior on the PLR 
rather than the end to end path in the network. Also, capacity 
planning is very topology dependent and SP dependent. Here, Stewart’s 
example is custom-built to highlight a case where capacity planning 
for TI-LFA is different than capacity planning for link failure. I 
personally don’t find the example very typical of real network, as 
typically it’s more efficient to try to share the backup capacity for 
both link and node failure, which is not the case in the example.


That being said, the example is good enough to say that the capacity 
planning claim is not guaranteed. Again, cf my point 1. i.e. I support 
changing this text.


Coming back to the technical behavior, if we agree that using the 
shortest path from the PLR to the destination is the best path (that 
we can choose from) that’s good enough for me.


Regards,

--Bruno

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 

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

[Alexander Vainshtein]

Stephane,
I fully agree that doing TI-LFA with just Adj-SIDs is theoretically possible 
but not practical given existing HW and realistic network scales.

I also think that one big advantage of this draft is that it provides a set of 
implementable solutions that cover a wide spectrum of real life scenarios, and 
this is done by offering reasonable strategies for minimization of the label 
stack depth used by the repair path.

It is, of course, up to the authors to decide whether such optimization is in 
or out of scope of the draft.

But if it left out of scope, practical value of the draft will suffer – 
especially since quite a few implementations of (at least, some of) these 
optimization strategies are already implemented and, AFAIK, deployed.

My 2c.
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 4:02 PM
To: DECRAENE Bruno IMT/OLN ; 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

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 

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

[Stewart Bryant]

On 12/07/2018 10:49, bruno.decra...@orange.com wrote:


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.



Correct


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.



That is not the point I am making.


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?



Correct, but you miss the point I am making.

The draft goes to considerable effort to constrain the FRR path to the 
path that the traffic arriving at the PLR will take post failure. 
However, the point illustrated by the network fragment is that not all 
that traffic benefits from that effort. In the draft you assert post 
convergence advantage to you approach, but do not seem to make it clear 
that this is a partial benefit and not a universal benefit.


Depending on the specific advantage of constraining the path, this might 
be worth the complexity, or it might be better to use RLFA, or MRT or 
any one of the other technologies.


Also you really need to make it much clearer that the uloop avoidance 
properties (a big selling point of this technology) only apply to the 
traffic that will continue to arrive at C and that if any traffic will 
take another path you MUST implement an avoidance strategy.


- Stewart


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 its attachments.
As emails may be altered, Orange is not liable for messages 

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

[Alexander Vainshtein]

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

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

[Alexander Vainshtein]

Bruno,
Again lots of thanks for a prompt response.

I fully agree that the way to solve the scalability problem with RLFA is ‘to 
restrict yourself to the Q space of E with respect to the link S-E”.
This is exactly what RFC 7490 says.

But this is not what the TI-LFA says, IMHO, because it intersects the 
post-convergence path from the PLR to D with the Q-space of D for the failed 
link S-E.
You can probably adjust that by saying that Q-space of E can be used as proxy 
for Q-space of D. However:

-  The draft does not say that

-  The chances of the post-convergence path to D intersecting Q-space 
of D look quite reasonable to me. But what are the chances of non-empty 
intersection between the post-convergence path to D and Q-space of another node?

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 3:35 PM
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' 
mailto: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 
mailto:abashandy.i...@gmail.com>>; Robert Raszuk 

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 

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

[bruno.decraene]

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

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

[bruno.decraene]

Sasha,

Please see inline [Bruno]

From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Thursday, July 12, 2018 1:26 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,
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?
[Bruno] I think we should distinguish 2 aspects:
a) the technical behavior
b) the text/claims in the draft

My answer was about “a”. I see that you are not challenging it.
Regarding “b”, speaking for myself, I’m primarily interesting in the technical 
specification, less about the text introduced to motivate the solution. That 
being said:
1) If it were up to me, I would personally be very open to completely rewrite 
the text you cited. e.g. using my text ;-) (below).
2) I mostly agree with you. Although possibly the text could be rephrased to 
say that it refers to the local behavior on the PLR rather than the end to end 
path in the network. Also, capacity planning is very topology dependent and SP 
dependent. Here, Stewart’s example is custom-built to highlight a case where 
capacity planning for TI-LFA is different than capacity planning for link 
failure. I personally don’t find the example very typical of real network, as 
typically it’s more efficient to try to share the backup capacity for both link 
and node failure, which is not the case in the example.
That being said, the example is good enough to say that the capacity planning 
claim is not guaranteed. Again, cf my point 1. i.e. I support changing this 
text.

Coming back to the technical behavior, if we agree that using the shortest path 
from the PLR to the destination is the best path (that we can choose from) 
that’s good enough for me.

Regards,
--Bruno

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 

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

[Alexander Vainshtein]

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?
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 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 mailto:stewart.bry...@gmail.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 
mailto:abashandy.i...@gmail.com>>; Alexander 
Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>; 
Robert Raszuk mailto:rob...@raszuk.net>>; Chris Bowers 
mailto:cbow...@juniper.net>>
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 

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

[Alexander Vainshtein]

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

  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 

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

[bruno.decraene]

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 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: [GROW] [Lsr] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Hi Tim, Robert,

Thanks a lot for your comments. Regarding the idea of using BGP-LS for 
troubleshooting, we have also considered the possible pros and cons.

BGP-LS is initially proposed for carrying link state information using BGP, and 
is currently used for applications like topology visualization. However, I 
would not consider it as a strict “monitoring” protocol. NMP is intended for 
network troubleshooting, which monitors the protocol running status, exporting 
information more than just link state. For example, as also pointed out by Tim, 
in the NMP adjacency up/down event notification, possible reasons are included. 
Such non-link-state information is not defined in BGP-LS. It might be 
technically worktable for BGP-LS to carry the reason data by adding some 
“attribute” TLV, or to carry any other non-link-state data used for 
troubleshooting (e.g., PDU statistics), but it kind of deviates from the 
original intention of proposing BGP-LS.

In addition, whatever data conveyed by BGP-LS NLRI needs to be 
supported/encapsulated in the ISIS/OSPF PDUs. This bring scalability issue and 
extra IGP extension work whenever new information for new troubleshooting use 
cases is required. Besides, the extra data is to be flooded with ISIS/OSPF 
throughout the area/AS, which consumes extra bandwidth and is unwanted.

Another concern for BGP-LS is the lack of per-device feed. As we have stated in 
another email: The availability of real-time protocol PDUs collected from all 
monitored routers is necessary for troubleshooting analysis. As Tim pointed out 
that:
“BGP-LS also can be used to monitor EPE and direct/static routes, which is a 
bit of a stretch on putting that in BGP-LS, but nonetheless…”
 “Regarding requiring BGP-LS feeds from many or all nodes...  We need this 
regardless of this draft because of segment-routing/egress peer engineering.   
Due to EPE, we already recommend BGP-LS peering (feeds) from all EPE nodes 
(normally via a peering server) so that we can collect/monitor EPE (hopefully 
using https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-01).”
Although BGP-LS might be extended for multiple feeds in the future for specific 
purposes, to me, it again deviates from its original intention. And if we 
insist on extending BGP-LS for the purpose of troubleshooting, it just becomes 
NMP.

Regarding the comparison with other telemetry approaches, specifically 
gRPC/YANG, we have stated our points in the other email. To avoid repeating in 
this thread, please kindly refer to our previous email.

We agree with Tim that “The initiation message could lead to overloading it 
with all kinds of device specific info. Some constraint is needed. The per peer 
(adjacency) header is missing multi-topology.  BGP-LS includes the protocol 
type (e.g. CT) and MT (missing from this draft).”
In fact, not only during the initiation phase of the NMP session, but also 
during some network failure, e.g., route flapping, massive PDUs and other data 
are reported to the server. We think enabling different working modes (e.g., 
PDU compress mode, normal mode) of NMP at the device side could be a workable 
solution. We can refine this idea in the next version, as well as adding MT 
into the per-adjacency header.


BR,

Yunan

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: 2018年7月11日 17:25
To: Tim Evens (tievens) 
Cc: Greg Skinner ; GMO Crops 
; l...@ietf.org; ops...@ietf.org; rtgwg@ietf.org
Subject: Re: [GROW] [Lsr] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

Tim,

I already suggested use of BGP-LS *as-is* in this thread on Jul 6th.

But I guess we all agree that this is not the best use of BGP protocol to be 
now a vehicle of NMS only because it is easy with BGP to establish a TCP 
session and to distribute "stuff" in a relatively loop free fashion.

Thx,
R.

On Wed, Jul 11, 2018 at 2:40 AM, Tim Evens (tievens) 
mailto:tievens=40cisco@dmarc.ietf.org>> 
wrote:
Hi Robin, Yunan, Shunwan,

I'm a little late to this thread due to being preoccupied with a newborn.

Below are my comments, which take into consideration the other comments… sans 
the YANG/telemetry debate.  Considering we do use BGP-LS extensively, I don't 
think YANG is the only solution to these link-state monitoring use-cases.

BMP doesn't change or limit what's available in BGP. It encapsulates and 
multiplexes BGP over a single stream for remote monitoring.   BGP-LS (RFC7752) 
can be used today to monitor link state protocols (ISIS, OSPF).  BGP-LS also 
can be used to monitor EPE and direct/static routes, which is a bit of a 
stretch on putting that in BGP-LS, but nonetheless…  BGP-LS is available via 
BMP.

"Section 3.1, ISIS Adjacency Issues"

As written, this is covered by BGP-LS LINK NLRI.  We see a LINK change 
(advertised verses withdrawn) when the adjacency changes.  If the router dies 
or the control-plane fails in some way, we still see the NLRI change from the 
other side of