RE: Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

Dear all, A few comments: 1. I concur with Bruno’s latest comment about inconsistency between * “Any intermediate node can bypass the failed tail node” statement by the draft co-authors and * “This should be "penultimate SR segment endpoint” suggested by Yingzhen.

RE: [EXTERNAL] Genart last call review of draft-ietf-rtgwg-segment-routing-ti-lfa-13

Roni hi, Regarding one of your comments "Was there a discussion to have the document as informational or experimental and not standard track?" AFAIK multiple interoperable implementations of the draft exist and are successfully deployed in live networks. To me this means that "Experimental"

RE: [EXTERNAL] Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

Dear all, I have been trying to follow this discussion, and, as of this moment, I am somewhat confused. I have been taught that the two basic criteria for WG adoption of an individual draft are: * It deals with a real and relevant problem * It represents a valid first step to a

RE: [EXTERNAL] Re: WGLC for draft-ietf-rtgwg-segment-routing-ti-lfa (01/18/24 - 02/02/24)

Hi, I support publication of this draft. Regards, Sasha From: rtgwg On Behalf Of Stewart Bryant Sent: Saturday, January 20, 2024 10:50 PM To: Yingzhen Qu Cc: RTGWG ; spr...@ietf.org; rtgwg-chairs ; draft-ietf-rtgwg-segment-routing-ti-...@ietf.org Subject: [EXTERNAL] Re: WGLC for

RE: [EXTERNAL] Summary of the side meeting on TI-LFA

Yingzhen, Lots of thanks for conveying this meeting and for a very accurate summary. Regards, Sasha From: rtgwg On Behalf Of Yingzhen Qu Sent: Friday, November 10, 2023 11:05 AM To: RTGWG ; rtgwg-chairs ; spr...@ietf.org Subject: [EXTERNAL] Summary of the side meeting on TI-LFA Also sending

RE: [EXTERNAL] Reminder! Side meeting on TI-LFA

Vainshtein Cc: RTGWG ; rtgwg-chairs ; sp...@ietf.org Subject: Re: [EXTERNAL] Reminder! Side meeting on TI-LFA Please try this one: https://ietf.webex.com/meet/ietfsidemeeting2<https://ietf.webex.com/meet/ietfsidemeeting2> we're waiting for you On Wed, Nov 8, 2023 at 8:12 AM Alexander Vain

RE: [EXTERNAL] Reminder! Side meeting on TI-LFA

Still getting the same response – now after captcha requests☹. Did anybody succeed connecting to this meeting? Regards, Sasha From: Alexander Vainshtein Sent: Wednesday, November 8, 2023 6:02 PM To: 'Yingzhen Qu' Cc: 'RTGWG' ; 'rtgwg-chairs' ; 'sp...@ietf.org' Subject: RE: [EXTERNAL

RE: [EXTERNAL] Reminder! Side meeting on TI-LFA

Tried it again, still the same result… Regards, Sasha From: Alexander Vainshtein Sent: Wednesday, November 8, 2023 6:00 PM To: Yingzhen Qu Cc: RTGWG ; rtgwg-chairs ; sp...@ietf.org Subject: RE: [EXTERNAL] Reminder! Side meeting on TI-LFA Importance: High Yingzhen and all, Tried the link

RE: [EXTERNAL] Reminder! Side meeting on TI-LFA

Yingzhen and all, Tried the link, it says “Private room not found”. Regards, Sasha From: rtgwg On Behalf Of Yingzhen Qu Sent: Wednesday, November 8, 2023 10:45 AM To: RTGWG ; rtgwg-chairs ; sp...@ietf.org Subject: [EXTERNAL] Reminder! Side meeting on TI-LFA Hi all, Reminder. We will continue

My comments about TI-LFA and micro-loop avoidance drafts discussion at the RTGWG session today

Hi all, Please see below the comments I planned to present during the discussion at the RTGWG session today: 1. TI-LFA draft is about local handling of failures, while the micro-loop avoidance one is not limited to local reaction and deals with any kind of topology changes, including (but

RE: [EXTERNAL] Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment

. This alone looks to me a valid reason not to merge these drafts. My 2c, Sasha From: Gyan Mishra Sent: Friday, November 3, 2023 4:43 AM To: Alexander Vainshtein Cc: bruno.decra...@orange.com; draft-ietf-rtgwg-segment-routing-ti-...@ietf.org; rtgwg-chairs ; rtgwg@ietf.org Subject: Re: [EXTERNAL] Re

RE: [EXTERNAL] draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment

Dear Yingzhen, The proposed timeslot (14:30-16:00 CET 08-Nov-23) can work for me. Regards, Sasha From: Yingzhen Qu Sent: Friday, November 3, 2023 10:13 PM To: Stewart Bryant Cc: Gyan Mishra ; Alexander Vainshtein ; rtgwg@ietf.org; rtgwg-chairs ; draft-ietf-rtgwg-segment-routing-ti

RE: [EXTERNAL] Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment

Gyan and all, Inline below. Regards, Sasha From: Gyan Mishra Sent: Thursday, November 2, 2023 7:09 AM To: Alexander Vainshtein Cc: bruno.decra...@orange.com; draft-ietf-rtgwg-segment-routing-ti-...@ietf.org; rtgwg-chairs ; rtgwg@ietf.org Subject: [EXTERNAL] Re: draft-ietf-rtgwg-segment

RE: [EXTERNAL] Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment

Stewart and all, Please see some comments inline below. Regards, Sasha From: Stewart Bryant Sent: Thursday, November 2, 2023 9:30 AM To: Gyan Mishra Cc: Stewart Bryant ; Alexander Vainshtein ; rtgwg@ietf.org; rtgwg-chairs ; draft-ietf-rtgwg-segment-routing-ti-...@ietf.org Subject: [EXTERNAL

RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment

...@orange.com Sent: Monday, October 23, 2023 3:27 PM To: Alexander Vainshtein Cc: rtgwg@ietf.org; rtgwg-chairs ; draft-ietf-rtgwg-segment-routing-ti-...@ietf.org; Stewart Bryant Subject: [EXTERNAL] RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment Sasha, Thanks

RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment

Bruno, Stewart and all, I think that most of the things about TI-LFA and micro-loops have been said already (if in a slightly different context) and are mainly self-evident. However, I share the feeling that somehow the relationship between TI-LFA and micro-loop avoidance has become somewhat

A question and comment about Section 3 of draft-bashandy-rtgwg-segment-routing-uloop-15

Hi all, I have one question and one comment regarding Section 3 of the draft. This section says (verbatim): The computation to turn a post-convergence path into a loop-free list of segments is

Micro-loop avoidance procedures and support of SRLG in TI-LFA

Hi, I have a general question about relationship between SRLG support defined in the TI-LFA draft and various flavors of micro-loop avoidance defined, e.g., in RFC

Relationship between draft-chen-rtgwg-srv6-midpoint-protection and draft-ietf-spring-segment-protection-sr-te-paths-03

Hi, There is some obvious similarity between the problem addressed in the (expired) draft-ietf-spring-segment-protection-sr-te-paths-03 and

RE: [EXTERNAL] Inclusive language

Stewart, Lots of thanks for a prompt and very useful response! Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@rbbn.com -Original Message- From: Stewart Bryant Sent: Tuesday, March 22, 2022 2:58 PM To: Alexander Vainshtein Cc: Stewart

RE: [EXTERNAL] Re: Inclusive language

Hi all, I am not a native English speaker, and my understanding of what makes the language inclusive or non-inclusive is quite limited. But I have a couple of naive questions about the current draft (https://datatracker.ietf.org/doc/html/draft-addogra-rtgwg-vrrp-rfc5798bis-03): 1. The draft

RE: [EXTERNAL] Re: A problematic example with the TI-LFA draft

Stewart, Lots of thanks for a prompt response. Please see some comments inline below. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@rbbn.com From: Stewart Bryant Sent: Monday, August 9, 2021 10:54 AM To: Alexander Vainshtein Cc: Stewart Bryant

Re: [EXTERNAL] Re: [Int-area] New Version Notification for draft-lhan-problems-requirements-satellite-net-00.txt

Brian, Stewart and all, RFC 2804 notwithstanding, IETF has published RFC 3924 on Cisco LI Architecture. This is not a formal contradiction, since 3924 has been published as Informational. Can this be used as a precedent? Get Outlook for

RE: New rtgwg WG Co-Chair

+1 on both counts. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@rbbn.com From: rtgwg On Behalf Of bruno.decra...@orange.com Sent: Thursday, June 10, 2021 6:14 PM To: rtgwg@ietf.org Subject: [EXTERNAL] RE: New rtgwg WG Co-Chair Definitely +1

Re: KRP ID Discussion.

Khaled and all, I think that any proposal that involves massive (world-wide if I understand you correctly) re-allocation of already allocated stable public IPv4/IPv6 addresses can be safely rejected as impractical without going into any additional technical details. My 2c. Get Outlook for

RE: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

will be useful. Regards, Sasha Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com From: rtg-dir On Behalf Of Zhangmingui (Martin) Sent: Thursday, July 9, 2020 9:53 PM To: Alexander Vainshtein ; rtg-...@ietf.org Cc: rtg-...@ietf.org; Yemin (

RE: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

4:43 PM To: Alexander Vainshtein ; rtg-...@ietf.org Cc: rtg-...@ietf.org; rtgwg@ietf.org; Yemin (Amy) ; draft-ietf-trill-multilevel-single-nickname@ietf.org Subject: RE: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11 Hi Alexander, Thanks for the further comments. Please refer

Re: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

specific comments inline below marked [[Sasha]]. Regards, Sasha Get Outlook for Android<https://aka.ms/ghei36> From: Alexander Vainshtein Sent: Monday, July 6, 2020, 08:31 To: Zhangmingui (Martin); Alexander Vainshtein; rtg-...@ietf.org Cc: rtg-...@ie

Re: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Mingui, Get Outlook for Android<https://aka.ms/ghei36> From: rtg-dir on behalf of Zhangmingui (Martin) Sent: Sunday, July 5, 2020, 21:11 To: Alexander Vainshtein; rtg-...@ietf.org Cc: rtg-...@ietf.org; draft-ietf-trill-multilevel-single-nickname@ie

RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide

RE: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com From: Yemin (Amy) Sent: Monday, July 6, 2020 6:25 AM To: Alexander Vainshtein Subject: RE: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11 NOTICE: This email

RE: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

发件人: Alexander Vainshtein [mailto:alexander.vainsht...@rbbn.com] 发送时间: 2020年7月6日 13:03 收件人: Yemin (Amy) ; Alexander Vainshtein 抄送: rtg-...@ietf.org; rtgwg@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; rtg-...@ietf.org 主题: RE: RtgDir review: draft-ietf-trill--multilevel

Change of email address

Dear colleagues, Following the acquisition of my employer - ECI Telecom, by Ribbon, starting from 09-Jun-20 all the mails I will send to IETF will use alexander.vainsht...@rbbn.com as my address. I will still be receiving emails addressed to

RE: SRLG usage in the IGP Flexible Algorithm draft

Peter. Again lot of thanks. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com -Original Message- From: Peter Psenak Sent: Monday, May 4, 2020 11:06 AM To: Alexander Vainshtein ; shrad...@juniper.net; cfils...@cisco.com; ket

RE: SRLG usage in the IGP Flexible Algorithm draft

sense to add the corresponding clarifying text to the draft. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com -Original Message- From: Peter Psenak Sent: Friday, May 1, 2020 12:57 PM To: Alexander Vainshtein ; shrad

SRLG usage in the IGP Flexible Algorithm draft

Hi all, I have a question about the proposed usage of SRLG in the IGP Flexible Algorithm draft. This usage is defined Section 12 of the draft with the reference to the SRLG exclude rule as following: 2. Check if any exclude SRLG

RE: Mail regarding draft-hu-rtgwg-srv6-egress-protection

, and lots of thanks in advance, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com From: Yimin Shen Sent: Tuesday, February 25, 2020 4:26 PM To: Alexander Vainshtein Cc: rtgwg@ietf.org; Huaimo Chen Subject: Re: Mail regarding draft-hu-rtgwg-srv6-egress

RE: Mail regarding draft-hu-rtgwg-srv6-egress-protection

useful. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com From: Huaimo Chen Sent: Tuesday, February 25, 2020 1:01 AM To: Alexander Vainshtein ; Greg Mirsky Cc: Yimin Shen ; rtgwg@ietf.org Subject: Re: Mail regarding draft-hu-rtgwg-srv6-egress-prot

RE: Mail regarding draft-hu-rtgwg-srv6-egress-protection

Dear all, I concur with Yimin's comments in his last email. I have also an additional concern regarding support of a Mirror SID in SRv6. This concern is based on the following observations: 1. As per RFC 8402, a Mirror SID is a special case of the Binding SID 2. In SR-MPLS, a

Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

Protection Framework draft. My 2c. Get Outlook for Android<https://aka.ms/ghei36> From: Shraddha Hegde Sent: Monday, December 2, 2019, 06:10 To: Alexander Vainshtein; Robert Raszuk Cc: spr...@ietf.org; rtgwg@ietf.org; rtg-...@ietf.org Subject: RE: [spring]

Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

ion-framework/> draft (now in the RFC Editor queue). Get Outlook for Android<https://aka.ms/ghei36> ____ From: Alexander Vainshtein Sent: Saturday, November 23, 2019, 16:44 To: Robert Raszuk; Shraddha Hegde Cc: spr...@ietf.org; rtgwg@ietf.org; rtg-...@ietf.org

Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

et Outlook for Android<https://aka.ms/ghei36> ____ From: Alexander Vainshtein Sent: Saturday, November 23, 2019, 13:15 To: Robert Raszuk; Shraddha Hegde Cc: spr...@ietf.org; rtgwg@ietf.org; rtg-...@ietf.org Subject: Re: [spring] Draft for Node protection of intermediate no

Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

<https://aka.ms/ghei36> From: Robert Raszuk Sent: Saturday, November 23, 2019, 12:37 To: Alexander Vainshtein; Shraddha Hegde Cc: spr...@ietf.org; rtgwg@ietf.org; rtg-...@ietf.org Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR

Re: [spring] Draft for Node protection of intermediate nodes in SR Paths

Shraddha, Robert and all, Regarding Robert's question: I wonder if multi-hop IP BFD session with addresses used as /32 (or /128) prefixes serving as Nose SIDs of R8 and R7 respectively could be used as such a trigger by R7? Such a session would not respond to link failures, and I find it

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

Hi all, My colleague and I have discussed the relationship between link protection schemes in Section 5.2 of the draft and "pinned node" scheme in Section 5.3, and we would like to clarify this relationship. If the link between the PLR and the pinned node fails, but the tail-end node does not

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

Hi all, I concur with Stewart. >From my POV, it would be nice if the tables in Section 8 of >draft-ietf-rtgwg-segment-routing-ti-lfa were aligned with those in Section 9 >of RFC 7490, This would facilitate meaningful comparison between the two sets of networks. One of the differences between

RE: [netmod] Doubts about static routes in RFC 8349

...@ecitele.com -Original Message- From: Martin Bjorklund Sent: Wednesday, April 3, 2019 2:05 PM To: Alexander Vainshtein Cc: a...@cisco.com; lho...@nic.cz; net...@ietf.org; rtgwg@ietf.org Subject: Re: [netmod] Doubts about static routes in RFC 8349 Hi, Alexander Vainshtein wrote

RE: [netmod] Doubts about static routes in RFC 8349

you explain this controversy? Regards, and lots of thanks in advance, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com -Original Message- From: Martin Bjorklund Sent: Wednesday, April 3, 2019 1:34 PM To: Alexander Vainshtein Cc: a.

RE: Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)

draft-ietf-rtgwg-yang-rib-extend. Thanks, Acee From: Alexander Vainshtein mailto:alexander.vainsht...@ecitele.com>> Date: Tuesday, April 2, 2019 at 9:53 AM To: Acee Lindem mailto:a...@cisco.com>>, Ladislav Lhotka mailto:lho...@nic.cz>> Cc: Routing WG mailto:rtgwg@ietf.

Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)

Hi all, I have noticed that 8022 has been obsoleted by RFC 8349. But it has exactly the same problem. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com From: Alexander Vainshtein Sent: Tuesday, April 2, 2019 3:57 PM To: 'a...@cisco.com

Doubts about static routes in RFC 8022

Acee, Ladislav and all, I have serious doubts regarding the data model for static routes in RFC 8022. As I see it, the data model defined in this document does not support multiple routes with common destination, different next hops and different route preferences. This is because only route

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

Stephane, Again, lots of thanks for a prompt response. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com From: stephane.litkow...@orange.com Sent: Thursday, November 29, 2018 3:16 PM To: Alexander Vainshtein Cc: Michael Gorokhovsky

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

ovember 29, 2018 2:22 PM To: Alexander Vainshtein Cc: Michael Gorokhovsky ; rtgwg@ietf.org; akat...@juniper.net; kkous...@cisco.com Subject: RE: Expired draft-ietf-rtgwg-ipfrr-ip-mib That's a possibility. However for now, we have taken the approach to add FRR into the IGP models. You could p

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

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

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

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

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

, July 13, 2018 10:30 PM To: Stewart Bryant ; 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; Robert Raszuk ; Chris Bowers Subject: Re: Request for RTGWG Working Group adoption for

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

-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<mailto:rtgwg-cha...@ietf.org>; pfr...@gmail.com<mailto:pfr...@gmail.com

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

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

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

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

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

, 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

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

: 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

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

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

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

shandy ; 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:stewa

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

associated with the default algorithm. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com From: Stewart Bryant [mailto:stewart.bry...@gmail.com] Sent: Thursday, June 14, 2018 3:59 PM To: Alexander Vainshtein ; stephane.litkow...@orange.com Cc

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

...@orange.com; Alexander Vainshtein ; draft-bashandy-rtgwg-segment-routing-ti-lfa.auth...@ietf..org Cc: Michael Gorokhovsky ; draft-ietf-spring-segment-routing.auth...@ietf.org; spr...@ietf.org; rtgwg@ietf.org Subject: Re: Is TI-LFA compatible with the default SR algorithm? RFC5714 was written when we

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

ane.litkow...@orange.com] Sent: Thursday, June 14, 2018 1:57 PM To: Alexander Vainshtein ; draft-bashandy-rtgwg-segment-routing-ti-lfa.auth...@ietf.org Cc: Stewart Bryant ; Michael Gorokhovsky ; draft-ietf-spring-segment-routing.auth...@ietf..org; spr...@ietf.org; rtgwg@ietf.org Subject: RE:

Is TI-LFA compatible with the default SR algorithm?

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

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

Robert, Chris and all, I agree with Robert that it is up to the authors of an individual submission what they consider in or out of scope of the draft. However, I agree with Chris that the authors of an individual draft asking for its adoption by a specific WG should do their best to address the

RE: WG adoption poll for draft-nitish-vrrp-bfd-p2p

Resending after reducing the size. Chris and all, I support adoption of this draft as a WG document. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com From: Alexander Vainshtein Sent: Thursday, January 25, 2018 11:53 AM To: 'Nitish Gupta

RE: WG adoption poll for draft-nitish-vrrp-bfd-p2p

(nitisgup) [mailto:nitis...@cisco.com] Sent: Thursday, January 25, 2018 9:21 AM To: Alexander Vainshtein <alexander.vainsht...@ecitele.com> Cc: chrisbowers.i...@gmail.com; rtgwg@ietf.org; rtg-...@ietf.org; Aditya Dogra (addogra) <addo...@cisco.com>; draft-nitish-vrrp-bfd-...@ietf.

RE: WG adoption poll for draft-nitish-vrrp-bfd-p2p

11:32 AM To: Alexander Vainshtein <sa...@axerra.com>; Nitish Gupta (nitisgup) <nitis...@cisco.com> Cc: chrisbowers.i...@gmail.com; rtgwg@ietf.org; rtg-...@ietf.org; Aditya Dogra (addogra) <addo...@cisco.com>; Alexander Vainshtein <alexander.vainsht...@ecitele.com>

Re: WG adoption poll for draft-nitish-vrrp-bfd-p2p

nk you for your questions and its good to see interest in the Draft. Will be Happy to answer the questions. Please find our responses inline.   Thanks, Nitish   From: Alexander Vainshtein <alexander.vainsht...@ecitele.com> Date: Thursday, January 11, 2018 at 9:00 AM To: "draf

RE: WG adoption poll for draft-nitish-vrrp-bfd-p2p

Hi all, I have several questions regarding the draft that I would like to clarify before providing any firm opinion regarding its adoption. 1. The draft seems to deal just with VRRPv3 (RFC 5798) while completely ignoring VRRPv2 (RFC 3768). I wonder if this omission is due to some

Re: When the IETF can discuss drafts seriously?

+1.Sasha Vainshtein Sent from Yahoo Mail on Android On Thu, Dec 21, 2017 at 17:57, John C Klensin wrote: Folks, May I suggest that we wind this discussion thread down.  Whether correct or not, analyses of Khaled's character are probably not helpful and repetitive

Re: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)

Muthu,E2E protection of SR-TE LSPs against failure of Node- and Adj-SIDs that are part of the policy is definitely a valid and reasonable approach IMHO. And I also think that it can be combined with local (e.g., LFA-based) protection against failure of lunks and nodes that are NOT part of the

Re: RTGWG WGLC draft-ietf-rtgwg-backoff-algo

Support. Sent from Yahoo Mail on Android On Wed, Nov 29, 2017 at 9:41, Jeff Tantsura wrote: Dear RTGWG,     The authors have requested the RTGWG to last call draft-ietf-rtgwg-backoff-algo.     There was consensus that document is ready for the last call and the

Re: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)

FRR node knows to abandon the repair or to pick a particular path such as a particular binding SID. - Stewart On 28/11/2017 16:12, Alexander Vainshtein wrote: Stewart, I understand your concern. However, as I see it, the alternatives to local protection of a failed pinned node of a SR-T

Re: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)

Ahmed,Regarding what was not clear: As I see it, you have been carefully avoiding usage of the RFC 5331 language (context-specific label spaces and context identifiers) in your SR-related drafts. We (you and I) have already discussed this point wrt the SR anycast draft.  Regarding the overlap:

Re: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)

Ahmed,I believe that the so-called protected Adj-SID simply means that if the link that it represents fails, it can be replaced with the Node-SID of the node at the remote end if the adjacency. It does not help at all if the downstream node fails. Sent from Yahoo Mail on Android On Tue,

Re: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)

Muthu,Please take a look at draft-hegde-spring-node-protection-for-sr-te-paths that provides accurate descriprion of the requured DP behavior in the standard terms (context-specifuc label spaces and context-identifying labels). My 2c. Sent from Yahoo Mail on Android On Tue, Nov 28, 2017 at

Re: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)

Stewart,I understand your concern. However, as I see it, the alternatives to local protection of a failed pinned node of a SR-TE LSP are somewhat limited: 1. You can wait (with no traffic) until failure of the pinned node is recognized (e.g., fillowing IGP cobversion) and a new policy(that does

Re: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)

Ahmed and all,Two points:1. From my POV your description of forwarding behavior when the link S-->F fails is incomplete: the top label in the stack may be poppoed, but it is not "forgotten", and the next exposed label is looked up by S in the context label space that is F-specific. I.e., if S

Re: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)

Muthu and all,I do not see how the draft in quesrion us related to "SR Policy". >From my POV its scope is a SR LSP comprised of multiple Node SIDs within a >single IGP domain, and it provides local fast protection against failure of a >node that terminates one of the segments comprising this

Re: Last Call: (Micro-loop prevention by introducing a local convergence delay) to Proposed Standard

Hi all,I concur with Stewart regarding a simple advice to the operator. In most cases a link that goes down will not repair itself without some external intervention. And if we deal with a flapping link, it is a probkem by abd of itself,  and probably should be disabled until the underlying

test

Testing mu subscription - please ignore. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com ___ This e-mail message is intended for the recipient only and contains

RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt

Hi all, I have read the draft and I have one (presumably, minor) comment: - The IANA Considerations section of says that there are no IANA request. - At the same time the draft defines a new type of VRRP messages (2 - Backup Advertisement). As long as here was just one type of VRRP messages (1 -