Re: [spring] [EXTERNAL] Re: [Pals] Martini Pseudowires and SR

Stewart, Andrew and all, ++ Bess WG. I fully agree that using (targeted) LDP for setup of Martini PWs in an SR-based environment is quite problematic for the operators. One alternative is transition to setup of PWs using MP BGP based on the EVPN-VPWS mechanisms (RFC 8214

Re: [spring] [Pals] [EXTERNAL] Re: Martini Pseudowires and SR

: Gyan Mishra Sent: Monday, May 30, 2022 5:15 PM To: Rabadan, Jorge (Nokia - US/Sunnyvale) Cc: Alexander Vainshtein ; Andrew Alston - IETF ; SPRING WG ; Stewart Bryant ; b...@ietf.org; mpls-chairs ; p...@ietf.org Subject: Re: [Pals] [EXTERNAL] Re: [spring] Martini Pseudowires and SR Other

Re: [spring] [Pals] [EXTERNAL] Re: Martini Pseudowires and SR

these days 6. PW fragmentation and reassembly - not sure it is used these days. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@rbbn.com From: Rabadan, Jorge (Nokia - US/Sunnyvale) Sent: Monday, May 30, 2022 1:02 PM To: Alexander Vainshtein ; S

[spring] A technical concern regarding Circuit Style Segment Routing Policies draft

Hi all, I would like to share with you what I see as a serious (and probably critical) technical issue with the Circuit Style Segment Routing Policies draft. As I see it: * One of the key objectives of this draft is

Re: [spring] [EXTERNAL] Re: [Pce] A technical concern regarding Circuit Style Segment Routing Policies draft

ly 17, 2022 4:43 PM To: Alexander Vainshtein Cc: draft-schmutzer-pce-cs-sr-policy@ietf.org; p...@ietf.org; spring@ietf.org; Rotem Cohen ; Nitsan Dolev ; Dmitry Valdman Subject: [EXTERNAL] Re: [Pce] A technical concern regarding Circuit Style Segment Routing Policies draft Hi Sasha,

[spring] A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

Hi all, I would like to clarify that, from my POV, my technical concerns about draft-schmutzer-pce-sr-cs-routing-policies presented in my email dated 11-Jul-22

Re: [spring] A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

Schmutzer (cschmutz) Sent: Monday, July 25, 2022 6:45 PM To: Alexander Vainshtein Cc: Christian Schmutzer (cschmutz) ; draft-schmutzer-spring-cs-sr-policy@ietf.org; spring@ietf.org; Rotem Cohen ; Nitsan Dolev ; p...@ietf.org; Michael Gorokhovsky Subject: [EXTERNAL] Re: A technical concern

[spring] A query on draft-iqbal-spring-mpls-ping-algo-02

Hi, I see that draft-iqbal-spring-mpls-ping-algo has expired more than a year ago. LSP Ping for Flex-Algo defined in this draft seems to be an important tool. I wonder if the WG is interested in such a tool and whether

[spring] My question at the mike about draft-dong-spring-srv6-inter-layer-programming

Hi, I would like to repeat the question I have asked at the mike during the SPRING WG session today about draft-dong-spring-srv6-inter-layer-programming: How would the node that has allocated an End.XU SID f

Re: [spring] [EXTERNAL] Re: My question at the mike about draft-dong-spring-srv6-inter-layer-programming

Ketan, Lots of thanks for a prompt response. I fully agree that if the optical path is IP-enabled, End.X behavior should suffice and there is no need to invent a wheel. Regards, Sasha From: Ketan Talaulikar Sent: Tuesday, November 8, 2022 10:33 AM To: Alexander Vainshtein Cc: draft-dong

[spring] A question about End.MVPN SID in draft-wang-spring-multicast-vpn-segment-00

Hi, I have looked up draft-wang-spring-multicast-vpn-segment-00 and I think that the End.MVPN behavior in this draft can only be used with ingress replication as the P-tunneling technology for MVPN. This is becau

Re: [spring] My question at the mike about draft-dong-spring-srv6-inter-layer-programming

: Ketan Talaulikar ; Alexander Vainshtein Cc: draft-dong-spring-srv6-inter-layer-programm...@ietf.org; spring@ietf.org; Michael Gorokhovsky ; Nitsan Dolev ; Rotem Cohen Subject: [EXTERNAL] RE: [spring] My question at the mike about draft-dong-spring-srv6-inter-layer-programming Hi Ketan, In the

Re: [spring] My question at the mike about draft-dong-spring-srv6-inter-layer-programming

represent these underlay paths. So, as of this moment, I do not see any justification for yet another endpoint behavior and a new SID type. What, if anything, did I miss? Regards, Sasha From: Dongjie (Jimmy) Sent: Tuesday, November 8, 2022 3:47 PM To: Alexander Vainshtein Cc: draft-dong-spring

[spring] draft-ietf-spring-segment-protection-sr-te-paths

Hi, I see that draft-ietf-spring-segment-protection-sr-te-paths has expired. I wonder if there are any plans to refresh it. Regards, and lots of thanks in advance, Sasha Notice: This e-mail together with

[spring] 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 draft-chen-rtgwg-srv6-midpoint-protection

Re: [spring] draft-ietf-spring-segment-protection-sr-te-paths

Shraddha, Lots of thanks for a very prompt and encouraging response! Regards, Sasha From: Shraddha Hegde Sent: Tuesday, November 8, 2022 4:47 PM To: Alexander Vainshtein ; draft-ietf-spring-segment-protection-sr-te-pa...@ietf.org Cc: Nitsan Dolev ; Michael Gorokhovsky ; spring@ietf.org

Re: [spring] [EXTERNAL] Re: RE: My question at the mike aboutdraft-dong-spring-srv6-inter-layer-programming

<https://aka.ms/AAb9ysg> From: 韩柳燕 Sent: Wednesday, November 9, 2022, 02:54 To: Dongjie (Jimmy) ; Alexander Vainshtein ; draft-dong-spring-srv6-inter-layer-programm...@ietf.org Cc: spring@ietf.org ; Michael Gorokhovsky ; Nitsan Dolev ; Rotem Cohen S

Re: [spring] [EXTERNAL] Re: RE: My question at the mike aboutdraft-dong-spring-srv6-inter-layer-programming

dpoint behavior and associating it with some SID. Regards, Sasha From: Dongjie (Jimmy) Sent: Thursday, November 10, 2022 10:38 AM To: Alexander Vainshtein ; 韩柳燕 ; draft-dong-spring-srv6-inter-layer-programm...@ietf.org Cc: spring@ietf.org; Michael Gorokhovsky ; Nitsan Dolev ; Rotem Cohen S

Re: [spring] A question about Encapsulation of BFD for SRv6 Policy

Hi all, I wonder whether the authors have considered the possibility in which he SRv6 policy is comprised of just the routable SRv6 Service SID with no SRH present in the data packets. Among other things, in this case the head-end node would not be aware of any specific address of the tail-end

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

Hi all, I have a technical question on the following aspect of the SR Replication Segment for Multi-point Service Delivery draft. The draft states that: A Replication segment is identifi

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

nches. Regards, Sasha From: Alexander Vainshtein Sent: Sunday, December 11, 2022 12:54 PM To: draft-ietf-spring-sr-replication-segment.auth...@ietf.org Cc: p...@ietf.org; spring-cha...@ietf.org; SPRING WG ; James Guichard ; Nitsan Dolev ; Michael Gorokhovsky ; Nitsan Dolev ; Michael Gorokh

Re: [spring] [EXTERNAL] Re: WGLC for draft-ietf-spring-sr-replication-segment

Rishabh, Lots of thanks for a prompt and very encouraging response. Please see more inline below marked [[Sasha]]. Regards, Sasha From: Rishabh Parekh Sent: Sunday, December 11, 2022 9:04 PM To: Alexander Vainshtein Cc: draft-ietf-spring-sr-replication-segment.auth...@ietf.org; p...@ietf.org

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

Xuesong hi, In my email to the authors and the WG I have asked to clarify whether the same Downstream replication SID could be included in the Replication State of different "upstream" Replication SODs (including the cas

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

James, Rishabh and all, A short comment inline below. Regards, Sasha From: spring On Behalf Of James Guichard Sent: Tuesday, February 28, 2023 4:11 PM To: Rishabh Parekh ; SPRING WG List Cc: spring-cha...@ietf.org Subject: [EXTERNAL] Re: [spring] WGLC for draft-ietf-spring-sr-replication-segme

Re: [spring] A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

belonging to the SC-SR topology. Your feedback would be highly appreciated. Regards, Sasha From: Christian Schmutzer (cschmutz) Sent: Tuesday, May 2, 2023 7:29 PM To: Dongjie (Jimmy) Cc: Christian Schmutzer (cschmutz) ; Alexander Vainshtein ; draft-schmutzer-spring-cs-sr-policy@ietf

Re: [spring] [EXTERNAL] Re: A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

Raszuk Sent: Thursday, June 15, 2023 5:52 PM To: Alexander Vainshtein Cc: Christian Schmutzer (cschmutz) ; draft-schmutzer-spring-cs-sr-policy@ietf.org; spring@ietf.org; Dongjie (Jimmy) Subject: [EXTERNAL] Re: [spring] A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

Re: [spring] [EXTERNAL] Re: A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

Robert and all, ++ Stewart since resource-aware SR Segments<https://datatracker.ietf.org/doc/html/draft-ietf-spring-resource-aware-segments-07> may be quite relevant here. Regards, Sasha From: Alexander Vainshtein Sent: Thursday, June 15, 2023 6:08 PM To: Robert Raszuk Cc: Christian Sch

Re: [spring] [EXTERNAL] Re: A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

Raszuk Sent: Thursday, June 15, 2023 6:34 PM To: Alexander Vainshtein Cc: Christian Schmutzer (cschmutz) ; spring@ietf.org; Dongjie (Jimmy) ; Stewart Bryant Subject: Re: [EXTERNAL] Re: [spring] A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00 Hi, I have probably did not

Re: [spring] [EXTERNAL] Re: A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

or due to some transient condition (FRR, micro-loop avoidance etc.). Regards, Sasha From: Robert Raszuk Sent: Thursday, June 15, 2023 6:43 PM To: Alexander Vainshtein Cc: Christian Schmutzer (cschmutz) ; spring@ietf.org; Dongjie (Jimmy) ; Stewart Bryant Subject: Re: [EXTERNAL] Re: [spring] A

Re: [spring] [EXTERNAL] A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

violations is preferable. My 2c, Sasha From: Christian Schmutzer (cschmutz) Sent: Monday, June 19, 2023 10:33 AM To: Alexander Vainshtein Cc: Christian Schmutzer (cschmutz) ; Robert Raszuk ; spring@ietf.org; Dongjie (Jimmy) ; Stewart Bryant Subject: Re: [EXTERNAL] [spring] A technical concern

Re: [spring] [EXTERNAL] A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

Monday, June 19, 2023 11:40 AM To: Alexander Vainshtein Cc: Christian Schmutzer (cschmutz) ; Robert Raszuk ; spring@ietf.org; Dongjie (Jimmy) ; Stewart Bryant Subject: Re: [spring] [EXTERNAL] A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00 Alexander, I understand the di

Re: [spring] [EXTERNAL] Re: [IPv6] New draft: L4 Checksums in SRv6

Tal, Tom and all, IMHO and FWIW Tal has exposed a real and critical issue with compressed lists of SRv6 SIDs. I wonder if this issue could be addressed by explicitly stating that compressed lists of SIDs can only appear in the SRv6 header but not in the Destination Address of an IPv6 packet. M

Re: [spring] [EXTERNAL] A review of draft-ietf-spring-srv6-srh-compression-08

Adrian, A really amazing piece of a review! Regards, Sasha Get Outlook for Android From: spring on behalf of Adrian Farrel Sent: Thursday, September 21, 2023 4:36:39 PM To: 'SPRING WG List' Cc: spring-cha...@ietf.org Subject: [EXTERNA

Re: [spring] [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 ; spring@ietf.org Subject: [EXTERNAL] Summary of the side meeting on TI-LFA Also sending th

Re: [spring] [EXTERNAL] Re: Andrew Alston's Discuss on draft-ietf-spring-mpls-path-segment-20: (with DISCUSS and COMMENT)

Stewart, Andrew and all, I concur with Stewart. RFC 4182 clearly states that if the IPv4 or IPv6 Explicit Null label is found at the top of the stack but is not the bottom-of-stack label, it must be popped, and the next label processed in the usual

[spring] Intended status of draft-ietf-spring-resource-aware-segments

Hello, I have read the draft, and I do not have any technical comments on it. At the same time, I wonder why its intended status appears as "Standard Track": 1. The draft does not define any new mechanisms in

Re: [spring] [Lsr] Shepherd's Review of "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

Hi, I have looked up the resource-aware segments draft, and commented on its intended status. My guess (FWIW) that if it is changed from “Standards Track” to “Informational”, the chances of its not being progressed – and the associated risks for this draft – would be minimal. Regards, Sasha F

Re: [spring] [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 ; spring@ietf.org; rtgwg-chairs ; draft-ietf-rtgwg-segment-routing-ti-...@ietf.org Subject: [EXTERNAL] Re: WGLC for draft-ietf-rtg

Re: [spring] [EXTERNAL] Re: Intended status of draft-ietf-spring-resource-aware-segments

ent: Tuesday, January 23, 2024 8:02 AM To: Dongjie (Jimmy) Cc: Alexander Vainshtein ; draft-ietf-spring-resource-aware-segme...@ietf.org; spring@ietf.org Subject: [EXTERNAL] Re: [spring] Intended status of draft-ietf-spring-resource-aware-segments Hi Jie I understand the draft proposes an

Re: [spring] [EXTERNAL] Re: Intended status of draft-ietf-spring-resource-aware-segments

, Sasha From: Dongjie (Jimmy) Sent: Wednesday, January 24, 2024 10:37 AM To: Alexander Vainshtein ; Gyan Mishra Cc: draft-ietf-spring-resource-aware-segme...@ietf.org; spring@ietf.org; Acee Lindem Subject: RE: [EXTERNAL] Re: [spring] Intended status of draft-ietf-spring-resource-aware-segments

Re: [spring] [EXTERNAL] Re: Intended status of draft-ietf-spring-resource-aware-segments

ecific solutions. Regards, Sasha Regards, Sasha Get Outlook for Android<https://aka.ms/AAb9ysg> From: Gyan Mishra Sent: Friday, January 26, 2024 2:44:55 AM To: Alexander Vainshtein Cc: Acee Lindem ; Dongjie (Jimmy) ; draft-ietf-spring-resource-aware-segme

Re: [spring] [EXTERNAL] Re: 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 solution

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: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Ron and all, I respectfully disagree with the proposal of separation of SRv6 from the existing IPv6. IMHO and FWIW the most important added value of SRv6 is its ability to provide BGP-based overlay services without any changes in the P routers as described in Introduction of RFC 9252

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

ysg> From: Ron Bonica Sent: Tuesday, March 26, 2024 8:36:49 PM To: Alexander Vainshtein Cc: spring@ietf.org ; Andrew Alston - IETF ; Robert Raszuk ; Tom Herbert ; Alvaro Retana Subject: [EXTERNAL] Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compress

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

etwork. Regards, Sasha From: Andrew Alston - IETF Sent: Wednesday, March 27, 2024 11:36 AM To: Robert Raszuk Cc: Tom Herbert ; Ron Bonica ; Alexander Vainshtein ; spring@ietf.org; Alvaro Retana Subject: [EXTERNAL] Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11 No

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Andrew, Can you please provide any details about re-write of MPLS Ethertype? Why is it needed, what are the applications etc. I am not aware of any such operations. Regards, Sasha From: Andrew Alston - IETF Sent: Wednesday, March 27, 2024 2:25 PM To: Alexander Vainshtein ; Robert Raszuk Cc

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Layer 2 header (MAC addresses, VLAN tags and the Ethertype that identifies MPLS with downstream-allocated labels is pushed on the packet. Regards, Sasha From: Andrew Alston - IETF Sent: Wednesday, March 27, 2024 2:34 PM To: Alexander Vainshtein Cc: Tom Herbert ; Ron Bonica ; spring@ietf.org

Re: [spring] [EXTERNAL] Re: Chair Review of draft-ietf-spring-srv6-srh-compression-11

nt of the WG that owns that protocol” in your email. What did I miss? Regards, Sasha From: Stewart Bryant Sent: Wednesday, March 27, 2024 3:27 PM To: Andrew Alston - IETF Cc: Alexander Vainshtein ; Tom Herbert ; Ron Bonica ; spring@ietf.org; Alvaro Retana ; Robert Raszuk Subject: [EXTERNAL]

Re: [spring] [EXTERNAL] Re: Chair Review of draft-ietf-spring-srv6-srh-compression-11

rk-side IPv6 encapsulation. I have been the RTGWG reviewer of the draft that developed into this RFC, and I have then pointed to potential violations of the IPv6 addressing architecture in my review – but this did not prevent progressing of this draft. My 2c, Sasha From: Alexander Vainshtein Sen

Re: [spring] [EXTERNAL] Separating Threads (draft-ietf-spring-srv6-srh-compression)

Alvaro and all, Regarding the proposal for using a dedicated Ethertype for SRv6: Please note that RFC explicitly “introduces two data-plane instantiations of SR: SR over MPLS (SR-MPLS) and SR over IPv6 (SRv6)” and defines SRv6 as the instantiation of SR on the IPv6 data plane. From my POV using

Re: [spring] [EXTERNAL] Separating Threads (draft-ietf-spring-srv6-srh-compression)

My 2c, Sasha Get Outlook for Android<https://aka.ms/AAb9ysg> From: spring on behalf of Nick Hilliard Sent: Thursday, March 28, 2024 5:42:44 PM To: Alexander Vainshtein Cc: Alvaro Retana ; int-a...@ietf.org ; spring-cha...@ietf.org ; SPRING WG List

[spring] My question at the mike about draft-dong-spring-srv6-inter-layer-programming

Hi all, Just repeating the question about the draft I've asked at he mike at the SPRING WG session today. * Suppose that there is an underlay link between a pair of IP nodes that is not "visible in he

[spring] Re: [EXTERNAL] Re: My question at the mike about draft-dong-spring-srv6-inter-layer-programming

pair of IP nodes regular End.X SIDs suffice What, if anything, do I miss? Regards, Sasha From: Ketan Talaulikar Sent: Friday, July 26, 2024 2:47 PM To: Alexander Vainshtein Cc: draft-dong-spring-srv6-inter-layer-programm...@ietf.org; spring@ietf.org Subject: [EXTERNAL] Re: [spring] My question at

[spring] Re: My question at the mike about draft-dong-spring-srv6-inter-layer-programming

ie (Jimmy) Sent: Saturday, July 27, 2024 7:59:30 AM To: Alexander Vainshtein ; draft-dong-spring-srv6-inter-layer-programm...@ietf.org Cc: spring@ietf.org Subject: [EXTERNAL] Re: My question at the mike about draft-dong-spring-srv6-inter-layer-programming Hi Sasha, Thanks for your question a

[spring] Re: [EXTERNAL] Re: My question at the mike aboutdraft-dong-spring-srv6-inter-layer-programming

e SRv6 instantiation of the BGP peering segments [RFC8402<https://datatracker.ietf.org/doc/html/rfc8402>]. I.e., End.X behavior can be decoupled from IGP adjacencies. Hope this helps. Regards, Sasha From: 韩柳燕 Sent: Thursday, August 15, 2024 1:32 PM To: draft-dong-spring-sr ; Alexande

[spring] Re: [EXTERNAL] Re: WG Adoption Call for draft-bdmgct-spring-srv6-security (ends Aug/19)

Hi all, I have looked up Section 7.1.1 of the draft, and it looks problematic to me: * The first para of this section starts with “SRv6 packets rely on the routing header in order to steer traffic”. (T

[spring] Re: [EXTERNAL] Re: My question at the mikeaboutdraft-dong-spring-srv6-inter-layer-programming

Hi Liuyan, I think that we can simply agree to disagree. Regards, Sasha From: 韩柳燕 Sent: Thursday, August 22, 2024 11:40 AM To: Alexander Vainshtein Cc: spring@ietf.org; draft-dong-spring-sr ; Dongjie (Jimmy) Subject: Re:RE: [EXTERNAL] [spring] Re: My question at the mikeaboutdraft-dong

Re: [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls

Loa, and all, I have read the draft and your review on the Wiki page, and I think that your question about domain-wide labels is worth detailed discussion. In Section 2 "Illustration", the draft says that: - PE2 advertises (in the IGP) a host address 192.0.2.2/32 with its attached node segment 1

Re: [spring] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls

be changed. Regards, Sasha Email: alexander.vainsht...@ecitele.com Mobile: 054-9266302 > -Original Message- > From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] > Sent: Monday, September 29, 2014 3:56 PM > To: Alexander Vainshtein > Cc: Loa Andersson; rtg-...@iet

Re: [spring] [RTG-DIR] Routing Directorate QA review of draft-filsfils-spring-segment-routing-mpls

MPLS wg BEFORE > this is adopted as a SPRING wg document. > > /Loa > > On 2014-09-29 14:28, Alexander Vainshtein wrote: > > I concur with you that this requires discussion in the MPLS WG, and I am > not sure such a discussion should be postponed until the SPRING WG LC.

Re: [spring] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop

to:jonathan.hardw...@metaswitch.com] Sent: Wednesday, May 20, 2015 12:46 PM To: Alexander Vainshtein Cc: bruno.decra...@orange.com; j...@juniper.net; Alvaro Retana (aretana); Jon Hudson Subject: Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop Hi Sasha Pl

Re: [spring] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop

believe all the authors are on the SPRING mailing list anyway) list of recipients and with one more issue I have found in the draft - highlighted. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com From: Alexander Vainshtein Sent: Tuesday, July 28

Re: [spring] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop

Hi Stefano, OK by me. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com -Original Message- From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] Sent: Wednesday, July 29, 2015 4:13 PM To: Alexander Vainshtein Cc: rtg

[spring] Expiration of draft-francois-spring-segment-routing-ti-lfa-01

Hi all, I have just noticed that draft-francois-spring-segment-routing-ti-lfa-01 has expired more than 3 months ago. Since topology-independent FRR (TI FRR) looks like an important application of segment routing, I would like to know whether the authors plan to renew the draft. If the authors

Re: [spring] WG adoption calls (4x) and last call ending Monday

John and Stefano, I have sent my QA review of draft-filsfils-spring-segment-routing-ldp-interop more than 1 month ago. I have supported adoption of the draft but provided some comments that looked at the time substantial to me. Do you plan to address them? Regards, Sasha Office: +972-39266302

Re: [spring] WG adoption calls (4x) and last call ending Monday

: Alexander Vainshtein; Cc: John G. Scudder;; Subject:Re: [spring] WG adoption calls (4x) and last call ending Monday Hi Sasha, On Aug 31, 2015, at 3:09 PM, Alexander Vainshtein wrote: > John and Stefano, > I have sent my QA review of > draft-filsfils-spring-segment-routing-ldp-interop mo

Re: [spring] [SPRING] Query related to SR Architecture

Gaurav, Not sure I understand the context for your requirement. But to the best of my understanding your requirement does not match MPLS architecture. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com From: spring [mailto:spring-boun...@iet

Re: [spring] Last Call: (SPRING Problem Statement and Requirements) to Informational RFC

Hi all, I have read the Segment Routing Problem Statement and Requirements draft and I have a couple of comments on it. Editorial: The Abstract states that "Multicast use-cases and requirements are out of scope of this document", but this (or equivalent) statement does not appear anywhere

Re: [spring] Last Call: (SPRING Problem Statement and Requirements) to Informational RFC

: Alexander Vainshtein; spring@ietf.org Cc: pifra...@cisco.com; aret...@cisco.com; draft-ietf-spring-problem-statem...@ietf.org; spring-cha...@ietf.org Subject: Re: [spring] Last Call: (SPRING Problem Statement and Requirements) to Informational RFC Hello everyone, concerning the first comment: I don&#

Re: [spring] Last Call: (SPRING Problem Statement and Requirements) to Informational RFC

, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com From: Rob Shakir [mailto:r...@rob.sh] Sent: Wednesday, January 06, 2016 7:09 PM To: Martin Horneffer; spring@ietf.org; Alexander Vainshtein Cc: draft-ietf-spring-problem-statem...@ietf.org; pifra

Re: [spring] Last Call: (SPRING Problem Statement and Requirements) to Informational RFC

Robert, Loa and all, Quoting from a very old Jewish joke, “you are both right”. If SR is used just as replacement to LDP, and if its FRR mechanism is limited to what is defined for IP FRR with RLFA, it uses the same size of label stack as LDP would use. It may also provide FRR in situations that

[spring] Issue with path protection for SR-TE LSPs

Hi all, I have read the SR Resiliency Use Cases draft and I have an issue with the path protection use case. The draft defines this use case with the following constrains/qualifiers (quoting from Section 2)

Re: [spring] meaning of "Strict Shortest Path" algorithm in draft-ietf-spring-segment-routing-09

Stefano, Chris and all, I have to admit that I am completely confused: - to the best of my understanding, Chris has asked whether a policy that puts a limit on max. number of ECMP next hops is not compatible with the Strict SPF algorithm - Stefano says that "Yes, this policy is a

Re: [spring] meaning of "Strict Shortest Path" algorithm in draft-ietf-spring-segment-routing-09

: Monday, September 19, 2016 3:09 PM To: Stefano Previdi (sprevidi) Cc: Alexander Vainshtein ; spring@ietf.org; Chris Bowers Subject: Re: [spring] meaning of "Strict Shortest Path" algorithm in draft-ietf-spring-segment-routing-09 Number if ECMP paths is an implementation subject and wo

Re: [spring] meaning of "Strict Shortest Path" algorithm in draft-ietf-spring-segment-routing-09

m] Sent: Monday, September 19, 2016 4:17 PM To: Alexander Vainshtein ; Jeff Tantsura ; Chris Bowers Cc: spring@ietf.org Subject: Re: [spring] meaning of "Strict Shortest Path" algorithm in draft-ietf-spring-segment-routing-09 Chris, Jeff, Alex, strict-SPF behavior has been intended as th

Re: [spring] meaning of "Strict Shortest Path" algorithm in draft-ietf-spring-segment-routing-09

] Sent: Thursday, September 22, 2016 4:57 PM To: Alexander Vainshtein ; Chris Bowers Cc: spring@ietf.org; Jeff Tantsura Subject: Re: [spring] meaning of "Strict Shortest Path" algorithm in draft-ietf-spring-segment-routing-09 > On Sep 19, 2016, at 3:28 PM, Alexander Vainsht

Re: [spring] Issue with path protection for SR-TE LSPs

fano Previdi (sprevidi) Cc: spring@ietf.org; Alexander Vainshtein ; Shell Nakash ; Michael Gorokhovsky ; draft-ietf-spring-resiliency-use-ca...@ietf.org; Marina Fizgeer ; Rotem Cohen Subject: Re: [spring] Issue with path protection for SR-TE LSPs Hi Stefano, > From: Stefano Previdi (sprevid

Re: [spring] Issue with path protection for SR-TE LSPs

litkow...@orange.com [mailto:stephane.litkow...@orange.com] Sent: Tuesday, September 27, 2016 2:41 PM To: Alexander Vainshtein ; DECRAENE Bruno IMT/OLN ; Stefano Previdi (sprevidi) Cc: spring@ietf.org; Shell Nakash ; Michael Gorokhovsky ; draft-ietf-spring-resiliency-use-ca...@ietf.org; Marina Fizgeer ;

[spring] FW: Node Protection for SR-TE Paths: an expired draft

Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com From: Alexander Vainshtein Sent: Monday, November 07, 2016 5:56 PM To: 'shrad...@juniper.net' ; 'cbow...@juniper.net' Cc: 'spr...@ietf.com' Subject: Node

Re: [spring] A question regarding Section 3.2 of RFC 8402

From: Alexander Vainshtein Sent: Tuesday, December 10, 2019 1:14 PM To: spring@ietf.org Cc: Michael Gorokhovsky ; Sheetal Jangeed ; Madhav Purohit ; Abhijit Gokaraju (abhijit.gokar...@ecitele.com) ; Dmitry Valdman Subject: A question regarding Section 3.2 of RFC 8402 Importance: High Hi all, My

Re: [spring] A question regarding Section 3.2 of RFC 8402

inal Message- From: Peter Psenak Sent: Thursday, January 9, 2020 3:14 PM To: Alexander Vainshtein ; spring@ietf.org Cc: Madhav Purohit ; Dmitry Valdman ; Michael Gorokhovsky ; Abhijit Gokaraju ; Sheetal Jangeed Subject: Re: [spring] A question regarding Section 3.2 of RFC 8402 Hi Alexander,

Re: [spring] Mail regarding draft-hu-rtgwg-srv6-egress-protection

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: rt...@ietf.org; Huaimo Chen Subject: Re: Mail regarding draft-hu-rtgwg-srv6-egress

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi all, I cannot say whether PSP is allowed or disallowed by RFC 8200. But, to the best of my understanding, format of SRH and its handling are specified by the IPv6 Segment Routing Header draft that is owned by the 6MAN

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Joel, Andy and all, FWIW I concur with your positions regarding comparison between PHP in MPLS and PSP in SRv6. I would also like to stress that, to the best of my understanding, in MPLS PHP is a local behavior between the penultimate and ultimate nodes with the ultimate node explicitly reques

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

sht...@ecitele.com -Original Message- From: Ketan Talaulikar (ketant) Sent: Wednesday, March 4, 2020 11:49 AM To: Alexander Vainshtein ; Joel M. Halpern ; Andrew G. Malis Cc: spring@ietf.org; Martin Vigoureux Subject: RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming Hi

Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Pablo, Christian and all, I respectfully disagree with the statement " The processing defined in draft-ietf-spring-srv6-network-programming is aligned with the SRH". Specifically, from my POV the SRH draft does not define

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

: Wednesday, March 11, 2020 4:44 PM To: Alexander Vainshtein Cc: Ted Lemon ; Fernando Gont ; SPRING WG List ; 6...@ietf.org; draft-ietf-spring-srv6-network-programming Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming Hi Sasha

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Brian, Lots of thanks for a prompt and unambiguous response. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com -Original Message- From: Brian E Carpenter Sent: Wednesday, March 11, 2020 9:13 PM To: Alexander Vainshtein ; Darren

Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Pablo, Chris and all, I have not found the restriction for Binding SID not being the last SID in the SID list in RFC 8402 or RFC 8666. And I think that no such limitation exists in SR-MPLS, where a binding SID can be easily be the last SID in the LIST of SIDs in the SR policy that is used to d

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

.ms/ghei36> From: Darren Dukes (ddukes) Sent: Thursday, March 12, 2020, 15:17 To: Alexander Vainshtein; Brian E Carpenter Cc: SPRING WG List; 6...@ietf.org; Fernando Gont; draft-ietf-spring-srv6-network-programming Subject: Re: [spring] Request to close the

[spring] 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: [spring] 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

Re: [spring] 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: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management

Mach and all, From my POV saying that " With current SR ... there is no way for the devices to differentiate traffic over the same link or to the same destination, because the SID used by all the flows are the same" is inaccurate. AFAIK it is perfectly possible to associate multiple Prefix-SI

[spring] 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 alexander.vain

Re: [spring] Understanding the replication draft

Dhruv, Bruno and all, Regarding the statement " What is missing in the spring I-D is some very high level discussion in terms of architecture on how replication segment and SR P2MP policy come together" - I cannot agree more. My 2c, Sasha Office: +972-39266302 Cell: +972-549266302 Email:

Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

Bruno, and all, I strongly support adoption of draft-hegde-spring-node-protection-for-sr-te-paths as a WG document. >From my POV in its current stage it goes far beyond the common requirements >for adoption: * Addresses a real and important problem within the scope of the SPRING WG *

Re: [spring] Spring protection - determining applicability

Mach, Joel and all, I think that in most cases: 1. There is clear differentiation between "topological" and "service" instructions in SID advertisements. E.g.: o IGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the corresponding IGP advertisements) represent topological instr

Re: [spring] Spring protection - determining applicability

m is restricted > to just service SIDs. > > Suppose that the PCE has specified the path to meet some complex te > objective. The bypass node has no way of knowing what those > constraints > were. And for some kinds of traffic, it is better to drop the packet > than to deli

  1   2   3   >