[spring] New draft on use of BFD Demand mode over MPLS p2p LSP

Dear All, the new draft, draft-mirsky-bfd-mpls-demand , was presented at MPLS WG meeting in Prague. The draft proposes how the

[spring] Fwd: New Version Notification for draft-mirsky-bfd-mpls-demand-01.txt

dra...@ietf.org> Date: Wed, Jun 28, 2017 at 12:05 PM Subject: New Version Notification for draft-mirsky-bfd-mpls-demand-01.txt To: Gregory Mirsky <gregimir...@gmail.com> A new version of I-D, draft-mirsky-bfd-mpls-demand-01.txt has been successfully submitted by Greg Mirsky and posted to the IET

Re: [spring] [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt

and for LSP-Ping, including draft-ietf-mpls-bfd-directed, > uses TFSs? > > Best, > > — Carlos. > > On May 9, 2017, at 12:00 PM, Greg Mirsky <gregimir...@gmail.com> wrote: > > Dear Carlos, > I've decided to re-start the discussion and am interested to hear > tech

[spring] Requirements towards OAM in Segment Routing network

Dear Authors, I'd like to bring your attention to the WG document OAM Requirements for Segment Routing Network . I think that many requirements listed in your document are common requirements for OAM in Segment Routing network

Re: [spring] [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt

The copy/paste did not > address the comments. > > Best, > > — Carlos. > > On May 8, 2017, at 11:33 PM, Greg Mirsky <gregimir...@gmail.com> wrote: > > Dear All, > perhaps this new draft may is of interest to you. > Your comments, suggestions are most welco

Re: [spring] [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt

antiated through a label >>> stack. But RFC 7110 does not use numeric label values, it uses TFSs. That >>> does not create any additional state. E.g.,: https://www.ietf.org/ma >>> il-archive/web/mpls/current/msg16091.html >>> >>> Thanks, >>>

[spring] Fwd: New Version Notification for draft-mirsky-bfd-mpls-demand-00.txt

00.txt To: Gregory Mirsky <gregimir...@gmail.com> A new version of I-D, draft-mirsky-bfd-mpls-demand-00.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-bfd-mpls-demand Revision: 00 Title: BFD in Demand Mod

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

very useful. > > > Yes! > > Because it piggy-backs on data without altering the data plane > realization. IPFIX for the rest. > > On Nov 16, 2017, at 3:33 AM, Greg Mirsky <gregimir...@gmail.com> wrote: > > Hi Zafar, et.al, > as I'm the one who have started the

Re: [spring] [mpls] redux: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi John, if network doesn't use payload information to handle ECMP then performance measurement using RFC 8169-style or pure active OAM based on RFC 6374 will certainly work. But if it is DPI-based hashing for ECMP, then there cannot be guarantee that packets with GAL/G-ACh follow the same path as

[spring] BFD in Segment Routed networks with MPLS data plane

Dear SPRING WG, the draft-mirsky-spring-bfd will be presented today at MPLS WG meeting (Afternoon Session I). We welcome your participation, comments, questions and suggestions at the mike and on the mailing list (please address to both

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Zafar, I don't see how managing, using passive OAM, i.e. counting fly-by packets, at transient SR-MPLS nodes can be equated to breaking "no-forwarding state at transient LSR" model.I believe that practical is as important as aesthetic and that network cannot be operated without comprehensive

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

> additional documentation (on the alternatives including existing counters) > to help us converge. Please stay tuned. > > > > Thanks > > > > Regards … Zafar > > > > > > *From: *Greg Mirsky <gregimir...@gmail.com> > *Date: *Monday, November 20,

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

plicity should be the first priority object. >> Hence we would have to make some compromise. >> >> Best regards, >> Xiaohu >> >> >> >> >> -- >> 徐小虎 Xuxiaohu >> M：+86-13910161692 >> E：xuxia...

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

rob...@raszuk.net> wrote: > Greg, > > There is zero labels of any sort in my proposal needed. Just basic netflow. > > best > r. > > On Nov 16, 2017 10:31, "Greg Mirsky" <gregimir...@gmail.com> wrote: > >> Hi Robert, >> you proposal is similar

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

ld have to make some compromise. > > Best regards, > Xiaohu > > > > > -- > 徐小虎 Xuxiaohu > M：+86-13910161692 > E：xuxia...@huawei.com > 产品与解决方案-网络战略与业务发展部 > Products & Solutions-Network Strategy & Business Development

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

> Architecture, highly unscalable and complicated to implement. We can solve > this problem without breaking the SR architecture. We plan to write a draft > before the next IETF. > > > > Thanks > > > > Regards … Zafar > > > > > > *From: *Xuxiaohu <xuxia...@hua

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

tate. > > > > My 2c, > > Sasha > > > > Office: +972-39266302 <+972%203-926-6302> > > Cell: +972-549266302 <+972%2054-926-6302> > > Email: alexander.vainsht...@ecitele.com > > > > *From:* Greg Mirsky [mailto:gregimir...@gmail.com

Re: [spring] [mpls] Whether both E2E and SPME performance measurement for MPLS-SR is needed?

ct this is most beauty of SR > that you can add one label to forward packets to different node in SPF > topology and you make sure that traffic will be natively flowing from there > over disjoined path to native path. > > > > How in those deployment cases all of those discussions h

Re: [spring] [mpls] Whether both E2E and SPME performance measurement for MPLS-SR is needed?

less extra labels. > Mach > *发件人：*Greg Mirsky > *收件人：*Alexander Vainshtein, > *抄 送：*spring,Robert Raszuk,m...@ietf.org, > *时间：*2017-11-17 10:10:41 > *主 题：*Re: [mpls] [spring] Whether both E2E and SPME performance > measurement for MPLS-SR is needed? > > Dear All, > we may

[spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Shraddha, thank you for very well written and thought through draft. I have these questions I'd like to discuss: - Have you thought of using not one special purpose label for both SR Path Identifier and SR Path Identifier+Source SID cases but request two special purpose labels, one

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Cell: +972-549266302 <+972%2054-926-6302> > > Email: alexander.vainsht...@ecitele.com > > > > *From:* mpls [mailto:mpls-boun...@ietf.org] *On Behalf Of *Greg Mirsky > *Sent:* Thursday, November 16, 2017 4:28 AM > *To:* Xuxiaohu <xuxia...@huawei.com> >

Re: [spring] [ippm] New Draft draft-gandhi-spring-udp-pm

Hi Rakesh, thank you for bringing this draft up for discussion. There was not enough time to ask questions at the SPRING WG meeting and this is a very good opportunity. I understand that you've proposed to use RFC 6374 to encode PM operations and measurements. Also, you've referenced work on OWAMP

Re: [spring] Questions and comments on draft-hu-spring-sr-tp-use-case-01

Hi Sasha, the most sincere thanks for your thorough review, thoughtful questions and detailed comments. All are of enormous help and are greatly appreciated. This is last week before the IETF meeting and, as you know, all are busy preparing for it. We'll discuss your questions and comments and

[spring] Couple comments on draft-ali-spring-bfd-sr-policy

Dear Authors, I've read the new draft and would appreciate your consideration of my comments and questions: - if I understand correctly, you prefer using S-BFD in SR domain over use of the base BFD. Without arguing with your choice, I'll note that the title of the draft doesn't reflect

Re: [spring] Couple comments on draft-ali-spring-bfd-sr-policy

sting and perhaps relevant to other > signalled circuits and TE paths like RSVP-TE or MPLS-TP, but they do not > seem appropriate for SR Policies to me. > > > > Thanks, > > Ketan > > > > *From:* Greg Mirsky <gregimir...@gmail.com> > *Sent:* 20 March 201

Re: [spring] Couple comments on draft-ali-spring-bfd-sr-policy

, 2018 at 4:42 PM, Ketan Talaulikar (ketant) <ket...@cisco.com > wrote: > Hi Greg, > > > > Thanks for your review and comments. Please check inline below for > responses. > > > > > > *From:* Greg Mirsky <gregimir...@gmail.com> > *Sent:* 20 M

[spring] Presentation slots request at IETF-101

Dear Bruno, Rob, and Martin, would appreciate opportunity to present and discuss two drafts during SPRING WG meeting in London: - Unified Identifier in IPv6 Segment Routing Networks draft-mirsky-6man-unified-id-srpresenter: Greg Mirskytime: 10 min - BFD in SR Networks

[spring] Fwd: New Version Notification for draft-mirsky-6man-unified-id-sr-00.txt

dra...@ietf.org> Date: Mon, Feb 26, 2018 at 6:56 PM Subject: New Version Notification for draft-mirsky-6man-unified-id-sr-00.txt To: Gregory Mirsky <gregimir...@gmail.com>, Shaofu Peng < peng.sha...@zte.com.cn> A new version of I-D, draft-mirsky-6man-unified-id-sr-00.txt has been successfully

Re: [spring] FW: New Version Notification for draft-ali-spring-bfd-sr-policy-02.txt

Hi Ali, thank you for your kind consideration of my comments. I've read the new version and section 3.3 in particular. Please kindly consider my comments: - I recall that the idea to construct SR tunnel through the network to terminate at the sender discussed in RFC 8403; - if the test

Re: [spring] FW: New Version Notification for draft-ali-spring-bfd-sr-policy-02.txt

. > >o Procedures on when and how to use the S-BFD Echo function. > > > > Hope this clarifies. > > > > Regards, > > Nagendra > > > > > > *From: *spring on behalf of Greg Mirsky < > gregimir...@gmail.com> > *Date: *Wednesday, October

[spring] Sequence Number in RFC 6374 and Synthetic Loss Measurement

Dear Authors, in your presentation of this draft at IPPM WG meeting I've pointed that assertion in Section 6 of the draft: The message formats for DM and LM [RFC6374] do not contain sequence number for probe query packets. is not accurate. RFC 6374 allows interpretation of the Timestamp

Re: [spring] Working Group Adoption Call for draft-cheng-spring-mpls-path-segment

Hi Bruno, Authors, et al., I support the adoption of the document by SPRING WG. I've made comments to the draft and will share the text addressing them before the week's end. Regards, Greg On Wed, Feb 20, 2019 at 1:03 AM wrote: > Hi SPRING WG, > > This email initiates a two week call for

[spring] Comments on draft-gandhi-spring-twamp-srpm

Dear Authors, I've read the draft and would share my comments with SPRING and IPPM WGs: - Section 3.1.1 - what is introduced in this section? Note, that in OWAMP 'O' stands for 'one-way', i.e., the receiver collects the measurement results. RFC 4656 defines Client Fetch

Re: [spring] Comments on draft-gandhi-spring-twamp-srpm

> > > Please see in line with … > > > > *From: *Greg Mirsky > *Date: *Thursday, February 28, 2019 at 7:05 PM > *To: *"draft-gandhi-spring-twamp-s...@ietf.org" < > draft-gandhi-spring-twamp-s...@ietf.org>, spring , IETF > IPPM WG > *Subj

Re: [spring] to progress draft-cheng-spring-mpls-path-segment

t; > On 2019-02-23 09:25, Rakesh Gandhi wrote: > > Hi Greg, > > > > I am not sure if the question has been answered. I would think GAL is at > > the bottom of the label stack. > > > > Thanks, > > Rakesh > > > > > > On Sat, Feb 1

Re: [spring] to progress draft-cheng-spring-mpls-path-segment

), right? If you put it on "another" tunnel, how do > you guarantee fate sharing? > > /Loa > > /Loa > > On 2019-02-23 11:55, Greg Mirsky wrote: > > Hi Loa, > > I think it will be similar to SPME and we'll need to have another > > SR-tunnel B-C with i

Re: [spring] to progress draft-cheng-spring-mpls-path-segment

D(B->C); - I agree that B->C SubPath must be the same in both cases. Regards, Greg On Sat, Feb 23, 2019 at 12:16 AM Loa Andersson wrote: > Greg, > > > > On 2019-02-23 12:31, Greg Mirsky wrote: > > Hi Loa, > > another tunnel with the Path segment from node C is

Re: [spring] to progress draft-cheng-spring-mpls-path-segment

> > My comments are in-line. > > > > B.R. > > Weiqiang Cheng > > > > *发件人:* Greg Mirsky [mailto:gregimir...@gmail.com] > *发送时间:* 2019年2月15日 3:37 > *收件人:* Alexander Vainshtein > *抄送:* spring@ietf.org; Stewart Bryant; > draft-cheng-spring-mpls-path-segm.

Re: [spring] to progress draft-cheng-spring-mpls-path-segment

Dear All, I concur with all what has been said in support of the adoption of this draft by SPRING WG. The document is well-written, addresses the real problem in SR-MPLS, and the proposed solution is technically viable. My comments and questions are entirely for further discussion: - would the

Re: [spring] [ippm] Latest Updates to SR PM Drafts

Hi Rakesh, and Authors, thank you for bringing the updates to the draft for the discussion. Please find my comments and questions below: - General. The draft title states that the underlying mechanism it uses is TWAMP. But the TWAMP, according to RFC 8545, is the union of TWAMP-Control

Re: [spring] IPv6-compressed-routing-header-crh

Hi Tom, in draft-mirsky-6man-unified-id-sr we've proposed the use of 20 and 32 bits-long SIDs in SR EH. Two bits-long field also defined in the Flags to identify the length of SID element in the SR EH: 0b00 - 128-bits SID;

Re: [spring] IPv6-compressed-routing-header-crh

the length of the field in SR EH to support 16 and 64 bits-long SIDs in addition to ones being proposed in the draft. Much appreciate your comments. Regards, Greg On Sat, Apr 20, 2019 at 12:50 PM Tom Herbert wrote: > > > On Fri, Apr 19, 2019, 5:54 PM Greg Mirsky wrote: > >> Hi Tom,

[spring] Fwd: New Version Notification for draft-mirsky-spring-bfd-08.txt

ashkin , Jeff Tantsura < jefftant.i...@gmail.com>, Mach Chen (Guoyi) A new version of I-D, draft-mirsky-spring-bfd-08.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-spring-bfd Revision: 08 Title: B

[spring] Followup on my comments on draft-ninan-spring-mpls-inter-as-oam

Dear Authors, et al., I've wanted to continue with my comments to the draft you've presented at MPLS WG meeting on Monday. As I've mentioned, please review draft-mirsky-spring-bfd and Section 4 Use Non-FEC Path TLV in particular. Welcome

Re: [spring] Followup on my comments on draft-ninan-spring-mpls-inter-as-oam

erent. > > IMO, it would be good to keep the usecase documents separate but work > together to > > Define protocol extension that can be used by both. > > > > Rgds > > Shraddha > > > > *From:* Greg Mirsky > *Sent:* Tuesday, July 23, 2019 10:29 AM > *

Re: [spring] Approaches to MTU efficiency in SRv6 in todays SPRING session

Hi Dirk, et al., I'd like to point to draft-mirsky-6man-unified-id-sr that proposes the use of the SRH for identifiers of 20 and 32 bits-long. Regards, Greg On Wed, Jul 24, 2019 at 12:20 PM Dirk Steinberg wrote: > Hi All, > > in

[spring] Fwd: New Version Notification for draft-mirsky-spring-bfd-08.txt

Dear SPRING WG Chairs, still awaiting your response to the inquiry below. Regards, Greg -- Forwarded message - From: Greg Mirsky Date: Fri, Aug 2, 2019 at 9:46 AM Subject: Fwd: New Version Notification for draft-mirsky-spring-bfd-08.txt To: spring , Dear All, with this update

Re: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

h the above > context in mind? I am positive that you will see that this is not getting > multicast work in Spring – that is being worked on in other WGs. > > > > Thanks, > > Ketan > > > > *From:* spring *On Behalf Of *Greg Mirsky > *Sent:* 17 November 201

Re: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Talaulikar (ketant) wrote: > Hi Greg, > > > > Please check inline. > > > > *From:* Greg Mirsky > *Sent:* 17 November 2019 13:14 > *To:* Ketan Talaulikar (ketant) > *Cc:* John E Drake ; spring@ietf.org; > Alexander Vainshtein ; > draft-voyer-spring-sr

Re: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Dear All, I concur with Sasha and John. Intended ingress replication of a particular flow, though using a unicast destination address, is still a multicast. Regards, Greg On Thu, Nov 14, 2019 at 5:36 AM John E Drake wrote: > Robert, > > As Sasha and I have indicated, your position is your own

Re: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

gt; > > Jeffrey > > > > *From:* Alexander Vainshtein > *Sent:* Monday, November 18, 2019 10:03 PM > *To:* Jeffrey (Zhaohui) Zhang > *Cc:* John E Drake ; spring@ietf.org; > draft-voyer-spring-sr-replication-segment.auth...@ietf.org; Robert Raszuk > ; ( > spring-cha...@

Re: [spring] New Version Notification for draft-mirsky-spring-bfd-08.txt

made some significant comments to your draft. > > I was kind of expecting that you would reply. Should we wait for your > replies? > > > > Regards, > > --Bruno > > > > > > *From**:* Greg Mirsky [mailto:gregimir...@gmail.com] > *Sent:* Saturday, November 9,

Re: [spring] 6man w.g. last call for

Dear Authors, et al., please find my comments, as WG LC comments, questions to this document below. - The Abstract and Introduction describe the document as "defines building blocks for Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane

[spring] Node failure detection (was Re: Draft for Node protection of intermediate nodes in SR Paths)

Hi Sasha, et al., many thanks for the great discussion. Please correct me if my recollection is not accurate, but at the time of RFC 4090 it was agreed, that a trigger to local protection may be in fact a false negative and, as a result, the protection switchover is suboptimal. I understand that

Re: [spring] 6man w.g. last call for - END.OTP

this document.* > > > I think current SR OAM draft fills that gap. > > Thx > R. > > > On Thu, Dec 19, 2019 at 3:49 PM Greg Mirsky wrote: > >> Hi Robert, >> could you please clarify your statement "there is huge value >> in defining packet t

Re: [spring] 6man w.g. last call for - END.OTP

Hi Robert, could you please clarify your statement "there is huge value in defining packet timestamping in all oam documents IETF produces these days"? Is that applicable to Active OAM methods or to other OAM methodologies, including, Passive and Hybrid? If the timestamping operation is entirely

Re: [spring] 6man w.g. last call for - END.OTP

wrote: > Hi Greg, Joel, > > FYI, END.OTP is used with TWAMP Light (RFC 5357) (and STAMP) in > draft-gandhi-spring-twamp-srpm and RFC 6374 in > draft-gandhi-spring-rfc6374-srpm-udp, for performance delay measurement > use-case. > > thanks, > Rakesh > > > On Thu,

Re: [spring] 6man w.g. last call for - END.OTP

reg, > > > > The END.OTP SID is NOT defined or to be used for in-situ OAM. > > > > Thanks > > > > Regards … Zafar > > > > *From: *ipv6 on behalf of Greg Mirsky < > gregimir...@gmail.com> > *Date: *Thursday, December 19, 2019 at 10:21 AM >

Re: [spring] New Version Notification for draft-mirsky-spring-bfd-09.txt

Dear All, Your comments and questions are always welcome and greatly appreciated. Best regards, Greg On Thu, Dec 19, 2019 at 7:39 PM Greg Mirsky wrote: > Dear All, > a new section Implementation Status has been added. > Your comments and questions are alwaysl > > -- Fo

[spring] Fwd: New Version Notification for draft-mirsky-spring-bfd-09.txt

< gregimir...@gmail.com>, Ilya Varlashkin , Jeff Tantsura < jefftant.i...@gmail.com>, Mach Chen (Guoyi) A new version of I-D, draft-mirsky-spring-bfd-09.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-spring-bfd Revision:

Re: [spring] 6man w.g. last call for

r > > > > *From: *"Zafar Ali (zali)" > *Date: *Wednesday, December 18, 2019 at 7:19 PM > *To: *Greg Mirsky , Ole Troan > > *Cc: *SPRING WG , 6man WG , 6man Chairs < > 6man-cha...@ietf.org>, "Zafar Ali (zali)" > *Subject: *Re: [spring] 6man

Re: [spring] New Version Notification for draft-mirsky-spring-bfd-08.txt

ls/pPq_LO8E0vIKKYLiHa50z7cFWks > https://mailarchive.ietf.org/arch/msg/mpls/iXsENQuPWmmgsueNiUMlyRCcu4U > https://mailarchive.ietf.org/arch/msg/mpls/X1a595fcp8D-WYGO9UkVsqum23s > Etc. > GIM>> As I've noted above, all the technical comments to draft-ietf-mpls-bfd-directed have been ad

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

not the case here at all. > > You apply PSP when you like on a per segment endpoint basis. OEM as we > have all agreed will not be subject to PSP. Is there a value to keep > repeating that every day :) ? > > Cheers, > R. > > > > On Sat, Feb 29, 2020 at 8:57 P

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

Hi Brian, you've said Also, answering your question "what harm does it do?" I think the answer objectively is "none, unless you want to use AH". On the other thread Ron and I have pointed that PSP does have decremental effect on the ability to perform OAM, particularly performance monitoring,

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

Hi Robert, yes, the path probably will be the same regardless whether PSP was applied or not. But performance metrics, e.g. packet delay, may be different for OAM and "regular" packets. Regards, Greg On Sun, Mar 1, 2020, 14:08 Robert Raszuk wrote: > Nope. > > Node can advertise two SIDs or PSP

Re: [spring] Updates to draft-gandhi-spring-twamp-srpm-05.txt

Dear Rakesh, my apologies for the belated response and comments that you can find below: - as I understand, the draft is applicable to TWAMP Light mode, mentioned in the informational Appendix I in RFC 5357, not the TWAMP protocol itself. Since TWAMP Light is not a standard but its idea

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

to the OAM draft from the > document. > > We’ve also removed the counters 2 and 3, keeping in this document the only > counter specific to this document. > > > > These changes have already been incorporated into revision 10. Many thanks > for the review. > > > > Cheers, &

Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Hi Robert, you've asked about a possible operational drawback of PSP. I think that for OAM PSP has decremental effect on the usefulness of performance measurements as there's no obvious information to identify the path a packet traversed. Regards, Greg On Fri, Feb 28, 2020 at 2:55 AM Robert

Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Ron > > > > > > *From:* spring *On Behalf Of *Greg Mirsky > *Sent:* Friday, February 28, 2020 11:22 AM > *To:* Robert Raszuk > *Cc:* John Scudder ; SPRING WG < > spring@ietf.org>; 6man WG > *Subject:* Re: [spring] I-D Action: > draft-ietf

Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

such text that PSP endpoint > behaviours should or must not be set for any OEM packets. Would that help ? > > Thx, > R. > > > > On Fri, Feb 28, 2020 at 5:22 PM Greg Mirsky wrote: > >> Hi Robert, >> you've asked about a possible operational drawback of PSP. I

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

; > Thanks, > > Pablo. > > > > *From: *Greg Mirsky > *Date: *Sunday, 19 January 2020 at 20:28 > *To: *"Pablo Camarillo (pcamaril)" > *Cc: *"spring@ietf.org" > *Subject: *Re: WGLC - draft-ietf-spring-srv6-network-programming > > > > H

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

nline PC2. > > > > Many thanks, > > Pablo. > > > > *From: *Greg Mirsky > *Date: *Monday, 27 January 2020 at 06:36 > *To: *"Pablo Camarillo (pcamaril)" > *Cc: *"spring@ietf.org" > *Subject: *Re: WGLC - draft-ietf-spring-srv6-network-programm

Re: [spring] 6man w.g. last call for

I will reach-out to you > again to discuss your comments. > > > > Thanks > > > > Regards … Zafar > > > > *From: *"Zafar Ali (zali)" > *Date: *Wednesday, December 18, 2019 at 7:19 PM > *To: *Greg Mirsky , Ole Troan > > *Cc: *SPRING W

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

Hi Pablo, thank you for your expedient response. Please find my new notes under GIM>> tag below in-line. Regards, Greg On Fri, Jan 10, 2020 at 1:09 PM Pablo Camarillo (pcamaril) < pcama...@cisco.com> wrote: > Hi Greg, > > > > Inline. > > > > Thanks,

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

them. Regards, Greg On Mon, Jan 13, 2020 at 10:23 AM Pablo Camarillo (pcamaril) < pcama...@cisco.com> wrote: > Hi Greg, > > > > Inline. > > > > Thank you, > > Pablo. > > > > *From: *Greg Mirsky > *Date: *Sunday, 12 January 2020 at 04:01

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

Dear Authors, WG Chairs, et al., I hope I'm not too late with my comments and questions on the document. Please kindly consider them as WG LC comments: - I have a question regarding the following pseudo-code: S08. max_LE = (Hdr Ext Len / 2) - 1 S09. If ((Last Entry > max_LE) or

Re: [spring] Updated draft-gandhi-spring-twamp-srpm and draft-gandhi-spring-stamp-srpm

Hi Rakesh, thank you for your thoughtful consideration of our discussion. I have a couple of questions to draft-gandhi-spring-twamp-srpm and hope you can clarify if I understand it correctly. In section 4.1 the process of selecting the destination IP address described s follows: When known,

[spring] Shorter SIDs in SR over IPv6 (Re: Adoption call criteria for CRH? [was: Re: CRH and RH0])

Hi Zafar, thank you for referring to the proposal that I'm one of the co-authors (Unified SID). And I cannot agree more that it is time for SPRING to take on the discussion of shorter SID in Segment Routing over IPv6. I think that the first step that all interested in the subject can easily do is

Re: [spring] The SPRING WG has placed draft-mirsky-spring-bfd in state "Call For Adoption By WG Issued"

Dear All, I support the adoption of draft-mirsky-spring-bfd by the SPRING WG for the following reasons: - optional control of the reverse path of the BFD session in SR-MPLS environment; - optional reduction of OAM data exchanged between BFD systems by using the BFD in Demand mode over

[spring] IPR related to draft-mirsky-spring-bfd

Dear All, please note that I am not aware of any IPR that applies to this document. Regards, Greg ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-19.txt

Dear Authors, et al., I've got a question, probably a very naive one, so my apologies in the front. The document in Section 4.16 defines a number of flavors of End, End.X, and End.T behaviors. Given that this is the SRv6 document and I don't seem to find analogous definitions for SR-MPLS, is it

Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-19.txt

ama...@cisco.com> wrote: > Hi Greg, > > > > Could you please clarify your question? This document is about SRv6, hence > I do not understand your question on SR-MPLS applicability. > > > > Thank you, > > Pablo. > > > > *From:* Greg Mirsky > *S

Re: [spring] Spring protection - determining applicability

Hi Andrew, would such requirements support using e2e protection? Regards, Greg On Mon, Aug 3, 2020 at 2:46 PM Andrew Alston < andrew.als...@liquidtelecom.com> wrote: > So – > > > > One of the use cases, in fact, some very major use cases in any spring > technology for us revolve around the

Re: [spring] Spring protection - determining applicability

the > protection mechanisms we are forced to use at this point > > > > Andrew > > > > > > *From:* Greg Mirsky > *Sent:* Tuesday, 4 August 2020 01:40 > *To:* Andrew Alston > *Cc:* Joel M. Halpern ; Robert Raszuk < > rob...@raszuk.net>; sp

[spring] Where a trigger for the protection switchover in SR-MPLS will come from?

Dear All, after reviewing draft-hegde-spring-node-protection-for-sr-te-paths I've got a question to ask Where a trigger for the protection switchover in SR-MPLS will come from? The draft discusses methods to provide local link and node protection. Obviously, the protection is triggered by the

Re: [spring] Leadership change

Thank you, Rob, Thanks to Jim and Joel for taking on the additional work and responsibilities. Thanks to Bruno for his continued commitment to the WG. Regards, Greg On Sun, Jun 14, 2020 at 1:25 PM Martin Vigoureux wrote: > WG, > > Rob had decided to step down as chair some time ago. There

Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear Authors, thank you for that well-written document. It was a pleasure to read. I have a number of questions and much appreciate it if you can clarify them for me: - how you envision mapping resources to a topological SID, e.g. adj-SID? Would it be 1:1, i.e., a new SID for each resource

Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

it is provisioned by the controller. That, in my opinion, breaks the SR paradigm of no per-flow state at intermediate SR nodes. I believe that any solution to the problem of SR-TE should be weighted against the work on Transport Slicing at the TEAS WG. Regards, Greg On Tue, Jul 28, 2020 at 8:47 AM Greg

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

Dear All, I support the WG adoption of the draft. It is well-written and addresses one of the problems that are awaiting the solution. Regards, Greg On Thu, Jul 30, 2020 at 5:25 AM wrote: > Hi SPRING WG, > > > > Authors of draft-hegde-spring-node-protection-for-sr-te-paths [1] have > asked

Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03

Hi Rakesh, thank you for the response to my comments. Please find my follow-up notes in-lined below under the GIM>> tag. Regards, Greg On Tue, Nov 10, 2020 at 8:01 AM Rakesh Gandhi (rgandhi) wrote: > Thank you Greg for taking time for thoroughly reviewing the documents and > providing the

Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

Hi Rakesh, thank you for the response to my comments. Please find my follow-up notes in-lined below under the GIM>> tag. Regards, Greg On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) wrote: > Thank you Greg for taking time for thoroughly reviewing the documents and > providing the

Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm

t; > *From:* ippm [mailto:ippm-boun...@ietf.org] *On Behalf Of *Tianran Zhou > *Sent:* Thursday, November 19, 2020 1:33 PM > *To:* Rakesh Gandhi (rgandhi) ; Greg > Mirsky > *Cc:* spring ; IPPM Chairs ; > spring-cha...@ietf.org; Tommy Pauly ; > IETF IPPM WG (i...@ietf.org) >

Re: [spring] FW: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt

Hi Weiqiang, members of the DT, thank you for volunteering your time and expertise to this important for the further development of the SR project. Please find my notes and questions below: - my first question is on the intended scope of the document. As I can understand from the title,

Re: [spring] FW: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt

and seems to overlook another, do not take a defensive position right away, engage in a discussion instead. Regards, Greg On Thu, Nov 19, 2020 at 6:32 PM Greg Mirsky wrote: > Hi Weiqiang, members of the DT, > > thank you for volunteering your time and expertise to this important for > t

Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm

make some valid point. > > Please see in line with . > > > > Cheers, > > Tianran > > > > *From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Rakesh > Gandhi (rgandhi) > *Sent:* Wednesday, November 18, 2020 7:41 AM > *To:* Greg Mirsky > *Cc:* spring ;

Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm

didn't take the liberty of adding BFD WG or its Chairs. I believe that decision to be made by the Chairs of IPPM And SPRING WGs. Regards, On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky wrote: > Hi Rakesh, > thank you for your prompt response, much appreciated. I'll carefully read

Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

Dear Chairs of the SPRING and IPPM WGs, Authors, et al., I've found myself in the situation when two related drafts are in the WG APs in the SPRING and IPPM WG (with the possibility that expertise from the third WG, BFD WG, might be desirable to review the "liveness monitoring"). Because these

Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03

Dear Chairs of the SPRING and IPPM WGs, Authors, et al., I've found myself in the situation when two related drafts are in the WG APs in the SPRING and IPPM WG (with the possibility that expertise from the third WG, BFD WG, might be desirable to review the "liveness monitoring"). Because these

[spring] When we have multiple proposals addressing the same problem [Re: WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn]

Dear All, I've edited the subject though left the original line in place to indicate the relationship between threads of discussion. Several comments already have referenced *bestbar* drafts that, in my understanding of them, propose a different solution to the problem addressed in

[spring] Fwd: New Version Notification for draft-ietf-spring-bfd-01.txt

, 2021 at 8:53 AM Subject: New Version Notification for draft-ietf-spring-bfd-01.txt To: Mach Chen (Guoyi) , Greg Mirsky < gregimir...@gmail.com>, Ilya Varlashkin , Ilya Varlashkin , Jeff Tantsura , Jiang Wenying < jiangweny...@chinamobile.com>, A new version of I-D, draft-ietf-sprin

  1   2   >