RE: [GROW] [Lsr] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

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

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

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

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

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;

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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.

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;

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

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

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

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

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

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