[spring] Re: Shepherd review for draft-ietf-spring-bfd-10

Hi Ketan, thank you for your detailed review and thoughtful comments. I'll work on addressing your concerns and will bring proposed updates for the discussion. Regards, Greg On Tue, Jul 16, 2024 at 6:35 PM Ketan Talaulikar wrote: > Hello All, > > Please find below the shepherd review for this

[spring] Re: spring WG Adoption Call for draft-peng-spring-pmtu-sr-policy

Dear, Alvaro et al., my apologies for the belated note. I read the draft and found it well-written. Thank you, Authors! Section 4 is very useful (more thanks). As was explained, there are several drafts closely related to this work. I am not sure to whom my questions addressed, but I appreciate

[spring] Re: Follow-up comments on draft-ietf-mpls-spring-inter-domain-oam

be sent back to the ingress LSR.” > > > > GIM>> Thank you for clarifying and updating Section 6.2 of the draft. I > think it would be very helpful if the document further clarified what > constitutes the malformity of the Segment TLV. > > updated as below > &g

[spring] Re: Follow-up comments on draft-ietf-mpls-spring-inter-domain-oam

> > Thans again for the careful review and comments. > > Pls see inline for replies. > > Version -14 will address your comments. > > > > Rgds > > Shraddha > > > > Juniper Business Use Only > > *From:* James Guichard > *Sent:* Friday, May 10, 2024 9:59

Re: [spring] Follow-up comments on draft-ietf-mpls-spring-inter-domain-oam

Dear All, I've shared my comments about the draft-ietf-mpls-spring-inter-domain-oam-12. It seems like the latest version 13 does not address my questions. Please consider these comments as part of IETF LC. Regards, Greg On Tue, Apr 23, 2024 at 5:06 AM Greg Mirsky wrote: > Dear, Authors,

Re: [spring] [pim] wglc: draft-ietf-pim-sr-p2mp-policy

ping/04/> > which is also waiting for last call. > > > Hooman > > > > *From:* spring *On Behalf Of *Rishabh Parekh > *Sent:* Saturday, April 27, 2024 11:40 AM > *To:* Greg Mirsky > *Cc:* Michael McBride ; p...@ietf.org; > spring@ietf.org > *Subject:*

Re: [spring] [pim] wglc: draft-ietf-pim-sr-p2mp-policy

n section 2.2.2 and Appendix A.2.1 during the WGLC > in SPRING. > > -Rishabh > > On Mon, Apr 22, 2024 at 12:25 AM Greg Mirsky > wrote: > >> Dear Authors, >> thank you for a well-written document that is a pleasure to read. I >> believe that it is ready to prog

Re: [spring] IPR Disclosures for draft-ietf-spring-bfd

I am not aware of any undisclosed IPR related to this draft. Regards, Greg On Tue, Apr 23, 2024 at 5:39 PM Alvaro Retana wrote: > Dear authors and contributors: > > Are you aware of any IPR that applies to this draft? > > If so, has it been disclosed in compliance with IETF IPR rules (see >

Re: [spring] wglc: draft-ietf-pim-sr-p2mp-policy

Dear Authors, thank you for a well-written document that is a pleasure to read. I believe that it is ready to progress. However, I have one general observation to make. Although IETF documents are required to include an analysis of the existing and any new security threats, and requested IANA

Re: [spring] Dependency Issues (WAS: I-D Action: draft-ietf-spring-bfd-09.txt)

Hi Alvaro, thank you for supporting this work and guiding us through the process. My follow-up notes below tagged GIM3>>. Best regards, Greg On Wed, Apr 17, 2024 at 2:16 PM Alvaro Retana wrote: > On April 17, 2024 at 5:49:09 AM, Greg Mirsky wrote: > > Greg: > > > th

Re: [spring] Dependency Issues (WAS: I-D Action: draft-ietf-spring-bfd-09.txt)

agree, I'll upload it instantaneously. Regards, Greg On Tue, Apr 16, 2024 at 2:42 PM Alvaro Retana wrote: > On April 16, 2024 at 3:55:44 AM, Greg Mirsky wrote: > > Greg: > > ... > > > > > (1) I-D.ietf-spring-mpls-anycast-segments > ... > > GIM2>

Re: [spring] Dependency Issues (WAS: I-D Action: draft-ietf-spring-bfd-09.txt)

Hi Alvaro, my follow-up notes below tagged by GIM2>>. Regards, Greg On Mon, Apr 15, 2024 at 11:51 PM Alvaro Retana wrote: > On April 15, 2024 at 5:16:35 PM, Greg Mirsky wrote: > > > Greg: > > ... > > > (1) I-D.ietf-spring-mpls-anycast-segments &g

Re: [spring] Dependency Issues (WAS: I-D Action: draft-ietf-spring-bfd-09.txt)

Hi Alvaro, thank you for your analysis and detailed questions. Please find my notes below tagged GIM>>. Regards, Greg On Mon, Apr 15, 2024 at 5:48 PM Alvaro Retana wrote: > On January 27, 2024 at 3:00:04 PM, Greg Mirsky wrote: > > > Greg/authors: > > Hi! &

Re: [spring] draft-ietf-spring-srv6-srh-compression

N within the payload of the reply). >>> >>> Do you see any issue with STAMP packets in networks using C-SIDs ? If so >>> can you kindly describe it in detail ? >>> >>> Many thx, >>> R. >>> >>> >>> >>> >>> >&g

Re: [spring] draft-ietf-spring-srv6-srh-compression

just IPv6 (modulo some VPN where we would need > to identify such VPN within the payload of the reply). > > Do you see any issue with STAMP packets in networks using C-SIDs ? If so > can you kindly describe it in detail ? > > Many thx, > R. > > > > > > &

Re: [spring] draft-ietf-spring-srv6-srh-compression

Hi Robert, could you clarify "can be used"? Is it MAY, SHOULD or MUST? If we use an active performance measurement protocol, e.g., STAMP, then it is expected that the path of the reflected STAMP test packet traverses the same set of nodes and links as the original STAMP test packet. Thus, the

[spring] Fwd: I-D Action: draft-ietf-spring-bfd-09.txt

o: Cc: Internet-Draft draft-ietf-spring-bfd-09.txt is now available. It is a work item of the Source Packet Routing in Networking (SPRING) WG of the IETF. Title: Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPLS Dataplane Authors: Greg Mirsky Jeff Ta

Re: [spring] [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

tle discussion. If we end up with “everything is > OK and nothing needs to change” that will be OK with us. If we discover > that some work is using terms too generally, while others already have > perfect definitions, that will lead to something similar to this document > to brin

Re: [spring] [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

- Hi Carlos and Adrian, thank you for starting this work. I believe that having a common dictionary helps in having more productive discussions. I took the liberty of inviting all the WGs which you invited to review the document and added DetNet WG. Please feel free to trim the distribution

[spring] BFD in SPRING

Dear All, I wanted to point to the discussion of the applicability of BFD in Segment Routing we had with Ketan, Changwang, Sasha, and Gyan. I believe that we've agreed on the following text in

Re: [spring] FW: New Version Notification for draft-filsfils-spring-path-tracing-05.txt

Hi Ahmed and Authors, thank you for the update on the evolution of this work. I've read the latest version and have several questions. I greatly appreciate your kind consideration: - As I understand it, the motivation for this work is the perceived overhead of some on-path telemetry

Re: [spring] Issue 1 regarding draft-ietf-spring-srv6-srh-compression

Hi Darren, thank you for your thoughtful consideration of my suggestion. I put several notes in-line under the GIM>> tag. Regards, Greg On Wed, Aug 16, 2023 at 10:12 AM Darren Dukes (ddukes) wrote: > Hi Greg, thanks for clarifying your concerns with proposed text. I like > the inclusion of

Re: [spring] Issue 1 regarding draft-ietf-spring-srv6-srh-compression

Hi Zafar, thank you for pointing out the text in Section 7.2. I think that it might be the right place to illustrate that the defined behaviors indeed are part of the same data plane. And it can be started with an update of the first sentence like the following: OLD TEXT: An SR source node MAY

Re: [spring] Issue 1 regarding draft-ietf-spring-srv6-srh-compression

Hi Darren, I agree that in the current form, the authors asserted that proposed C-SID mechanisms are parts of the single data plane. But, as I've noted earlier, that the resolution should come as a conclusion, not an assertion. I hope that the authors will share text that would illustrate in

Re: [spring] Confimring resolution of issue #3 https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/

7102 > > Thanks > Suresh > > On Aug 9, 2023, at 2:30 PM, Greg Mirsky wrote: > > Dear Authors and Chairs, > I have a clarification question and appreciate your consideration. > It seems to me that the proposed text updates either RFC 8754 or RFC 8200 > where the Segment

Re: [spring] Confimring resolution of issue #3 https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/

Dear Authors and Chairs, I have a clarification question and appreciate your consideration. It seems to me that the proposed text updates either RFC 8754 or RFC 8200 where the Segments Left field is defined as: - RFC 8754: Segments Left: Defined in [RFC8200], Section 4.4. - RFC 8200:

Re: [spring] Comments on draft-ietf-spring-bfd-07

On Tue, Aug 1, 2023 at 5:35 PM Ketan Talaulikar wrote: > Hi Greg, > > Thanks for that update. The monitoring at Segment List level looks good to > me. > > Thanks, > Ketan > > > On Tue, Aug 1, 2023 at 3:45 PM Greg Mirsky wrote: > >> Hi Ketan, >> thank

Re: [spring] Comments on draft-ietf-spring-bfd-07

Hi Ketan, thank you for clarifying the SR Policy composition. We've updated the draft to address your suggestion. I greatly appreciate it if you review the updates highlighted in the diff and would kindly share your feedback.

Re: [spring] Issue 1 regarding draft-ietf-spring-srv6-srh-compression

Hi, Joel, Authors, et al., I have a clarification question and appreciate your help answering it. According to RFC 8986: SRv6 Endpoint behavior: A packet processing behavior executed at an SRv6 Segment Endpoint Node. As I understand it, two compression techniques, NEXT-C-SID and REPLACE-C-SID,

Re: [spring] Discussion on [draft-lin-bfd-path-consistency-over-sr]

gt; From minutes-117-spring/: > > 10:15 S-BFD Path Consistency over SRv6 (10 mins) > > Presenter: Changwang Lin > draft-lin-sbfd-path-consistency-over-srv6 > <https://datatracker.ietf.org/doc/draft-lin-sbfd-path-consistency-over-srv6/> > > Greg Mirsky: Current version of

Re: [spring] Comments on draft-ietf-spring-bfd-07

Hi Ketan, thank you for your clarification in the expedient follow-up note. I have a question about the use of the B-SID. As I understand the processing, B-SID would be replaced by the associated segment list in the forwarding plane. Is that right? If it is, it seems like the packet is not

Re: [spring] Pending work items on draft-ietf-spring-bfd

or SR Policy, it would make > sense to incorporate S-BFD as a mechanism in the SPRING BFD draft. > > Regards > > > Matthew > > -- > *From:* spring on behalf of Greg Mirsky < > gregimir...@gmail.com> > *Sent:* Wednesday, March 29, 2

Re: [spring] Pending work items on draft-ietf-spring-bfd

R Policy, it would make > sense to incorporate S-BFD as a mechanism in the SPRING BFD draft. > > Regards > > > Matthew > > -- > *From:* spring on behalf of Greg Mirsky < > gregimir...@gmail.com> > *Sent:* Wednesday, March 29, 2023

Re: [spring] Pending work items on draft-ietf-spring-bfd

hich of > these two mechanisms they prefer/use. Including this in the document would > also be helpful. > GIM>> I wholeheartedly agree and welcome anyone to share their experiences of monitoring SR policies with MPLS OAM tools. > > Thanks, > Ketan > > On Mon, Mar 27,

Re: [spring] Changes of AD/Chairs

Jim, congratulations on stepping up to a new challenges! Many thanks for your dedication to progressing work at SFC and SPRING WGs. A warm welcome to Alvaro! Best regards, Greg On Tue, Mar 28, 2023 at 9:43 AM Andrew Alston - IETF wrote: > Hi All, > > > > I wanted to send this before the

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

: Mon, Mar 27, 2023 at 6:00 PM Subject: New Version Notification for draft-ietf-spring-bfd-06.txt To: Mach Chen (Guoyi) , Greg Mirsky < gregimir...@gmail.com>, Ilya Varlashkin , Jeff Tantsura < jefftant.i...@gmail.com>, Jiang Wenying A new version of I-D, draft-ietf-spring-bfd-06.

Re: [spring] [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method

ect the spec surely > looks redundant. But if we extend the view to practical field deployments > we may see the value. > > Cheers, > Robert > > > > On Fri, Feb 17, 2023 at 10:25 PM Greg Mirsky > wrote: > >> Hi Robert, >> I think that the solution defined

Re: [spring] [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method

t; On the other hand, the latest revision as Giuseppe posted includes > deployment considerations on IPv6 or SRv6. > > I see Aijun also gave a good proposal. > > > > Best, > > Tianran > > > > *From:* ipv6 [mailto:ipv6-boun...@ietf.org] *On Behalf Of *Greg Mirsk

Re: [spring] [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method

Hi Robert, I think that the solution defined in RFC 9343 can operationally achieve everything that is suggested in this draft. Consider an SRv6 domain. I imagine that the support of on-path telemetry, whether IOAM or Alternate Marking, is controlled per node over the management plane. Furthermore,

Re: [spring] [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method

Dear All, I believe that Xiao Min expressed also my concerns about proposals to standardize multiple encodings for the IPv6 data plane. It seems that it is helpful to recall that SRv6 shares with IPv6 the same EtherType value. Thus, differentiating between IPv6-generic and SRv6-only encodings for

Re: [spring] [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method

and draft-ali-spring-ioam-srv6. > > > > Regards, > > > > Giuseppe > > > > *From:* Greg Mirsky > *Sent:* Friday, February 10, 2023 2:11 AM > *To:* Giuseppe Fioccola > *Cc:* Joel Halpern ; SPRING WG List ; > 6man > *Subject:* Re: [IPv6] WG Adop

Re: [spring] [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method

occ...@huawei.com> wrote: > Hi Greg, > > Thank you for your comments. > > Please find my replies inline tagged as [GF]. > > > > Regards, > > > > Giuseppe > > > > > > *From:* ipv6 *On Behalf Of * Greg Mirsky > *Sent:* Thursday, February 9

Re: [spring] [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method

Dear Authors, et al, I read the draft and have several questions: - It seems like the main motivation for this document is enabling the Alternate Marking method of collecting the operational state information, and on-path performance measurements in an SRv6 domain exclusively at SR

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

Dear All, as suggested by the SPRING WG Chairs, I'm bringing the discussion to the mailing list. I think that it is also relevant and might be of interest to the BFD WG community. My questions at the mic were: - What is unique in the encapsulations of a BFD Control message described in the

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

Dear All, this is a technical refresh, no updates. Regards, Greg -- Forwarded message - From: Date: Mon, Oct 24, 2022 at 1:53 PM Subject: New Version Notification for draft-ietf-spring-bfd-05.txt To: Mach Chen (Guoyi) , Greg Mirsky < gregimir...@gmail.com>, Ilya Varl

[spring] A question on draft-peng-spring-pmtu-sr-policy

Dear Authors, I've read the new draft and would appreciate it if you could clarify what technical solution is introduced in the draft that requires standardization. Regards, Greg ___ spring mailing list spring@ietf.org

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

er-spring-sr-replication-segment. The authors welcome your comments and questions. Regards, Greg -- Forwarded message - From: Date: Tue, Apr 26, 2022 at 9:42 AM Subject: New Version Notification for draft-ietf-spring-bfd-04.txt To: Mach Chen (Guoyi) , Greg Mirsky < gregimir...@g

Re: [spring] [ippm] FW: New Version Notification for draft-filsfils-spring-path-tracing-00.txt

Hi Ahmed and the Authors, thank you for sharing this information. I've read the draft and have several questions and comments: - It is not clear if you propose a new active measurement protocol or view it as a hybrid method (based on RFC 7799 classification). On one hand, packets are

Re: [spring] Comments on draft-bocci-mpls-miad-adi-requirements

er to your question below about whether the ancillary data needs a > common format, I agree that it at least needs a common header format. > > > > Regards > > > > Matthew > > > > > > *From: *Greg Mirsky > *Date: *Tuesday, 15 February 2022 at 20:1

Re: [spring] Comments on draft-bocci-mpls-miad-adi-requirements

have tried to address > these in the updated draft that we just posted. > > > > In answer to your question below about whether the ancillary data needs a > common format, I agree that it at least needs a common header format. > > > > Regards > > > > Matthew

Re: [spring] Comments on draft-saad-mpls-miad-usecases

ssible” >solution? This seems a very bold claim. > > GIM>> Because it follows the KISS principle. > >1. > > > > Thanks, > > Haoyu > > > > *From:* Greg Mirsky > *Sent:* Monday, February 28, 2022 2:00 PM > *To:* Haoyu Song > *Cc:*

Re: [spring] Comments on draft-saad-mpls-miad-usecases

nforce any solution but to show we have such requirements. When > MIAD is developed, whether and where another draft for applying NSH SFC in > it needs to be developed is a totally different issue. > > > > Best, > > Haoyu > > > > *From:* Greg Mirsky > *Sent:* Monday,

Re: [spring] Comments on draft-saad-mpls-miad-usecases

t; Could you please give more explanation on why you don’t like this use case > particularly? Thanks. > > > > Best, > > Haoyu > > > > *From:* Greg Mirsky > *Sent:* Monday, February 28, 2022 10:56 AM > *To:* Haoyu Song > *Cc:* Tarek Saad ; mpls ; > p...@ie

Re: [spring] Comments on draft-saad-mpls-miad-usecases

k is that whatever output is from MIAD, it will provide a new > solution to support NSH SFC in MPLS. > > RFC 8596 shows a way to support NSH SFC in MPLS, but it may not be > cooperative with the other use cases in the same packet. MIAD tries to > solve this problem. > > &

Re: [spring] Comments on draft-saad-mpls-miad-usecases

onsider to use a generic mechanism to handle all these otherwise piecemeal > solutions. Of course, finally we would need to pick which shall actually be > supported with the generic method, but at this point, we shall not limit > ourself. > > > > Regards, > > Haoyu > &g

Re: [spring] Comments on draft-saad-mpls-miad-usecases

se cases at the same > time, we need a generic mechanism to support them, so the use-case draft > serves as a motivation for our work in the ODT. > > Hopefully this answers your question. Thanks, > > Haoyu > > > > *From:* Greg Mirsky > *Sent:* Thursday, February 24, 202

Re: [spring] Comments on draft-saad-mpls-miad-usecases

tools.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-saad-mpls-miad-usecases-00.txt=https://raw.githubusercontent.com/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt> > > > > Regards, > > Tarek (for co-authors) > > > > *From: *s

[spring] Comments on draft-saad-mpls-miad-usecases

Dear Authors, thank you for your work putting this document together. It helps to analyze essential use cases in the scope of the work at the Open DT. Attached, please find a copy of the draft with my notes and some editorial suggestions. I hope you'll find some of them helpful. I am looking

[spring] Comments on draft-bocci-mpls-miad-adi-requirements

Hi Stewart and Matthew, thank you for organizing this document in a very clear and concise manner. I enjoyed reading it. Attached, please find a copy of the draft with my notes, comments, and suggestions. The most important, in my view, the question I have Should we add the requirement to have a

Re: [spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt

Hi Thomas, et al., what do you think of the new SPRING WG draft that introduces two methods of the compressed SRv6 SID list encoding in the SRH ? Regards, Greg On Sat, Feb 12, 2022 at 12:10 AM wrote: > Dear Yao,

Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

son. Regards, Greg On Wed, Feb 9, 2022 at 7:41 PM Huaimo Chen wrote: > Hi Greg, > > Thank you very much for your notes. > > My responses/explanations are inline below with [HC2]. > > Best Regards, > Huaimo > > ------ > *From:* Greg M

Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

ions are inline below with [HC]. > > Best Regards, > Huaimo > on behalf of co-authors > > ------ > *From:* spring on behalf of Greg Mirsky < > gregimir...@gmail.com> > *Sent:* Tuesday, February 8, 2022 4:38 PM > *To:* Bruno Decraene >

Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

Dear Authors, et al., I've read the draft and would appreciate it if the authors can clarify one question: - What do you consider as the significant advantage of the mechanism defined in your draft compared with the mechanism defined in draft-ietf-spring-segment-protection-sr-te-paths?

Re: [spring] Active OAM in SRv6

failure detection and prevention. > > > > I hope the WG can see the simplicity, extensibility, and great application > potential of the proposed scheme, and provide constructive suggestions to > improve it. > > > > Thanks! > > Haoyu > > > > *From:* Greg Mir

Re: [spring] Active OAM in SRv6

Regards, Greg On Thu, Jan 27, 2022 at 5:44 PM Haoyu Song wrote: > Hi Greg, please see Inline > > > > *From:* Greg Mirsky > *Sent:* Thursday, January 27, 2022 2:01 PM > *To:* Haoyu Song > *Cc:* spring@ietf.org; IETF IPPM WG > *Subject:* Re: [spring] Active OAM in SRv

Re: [spring] Active OAM in SRv6

gt; Best, > > Haoyu > > > > *From:* Greg Mirsky > *Sent:* Wednesday, January 26, 2022 3:01 PM > *To:* Haoyu Song > *Cc:* spring@ietf.org; IETF IPPM WG > *Subject:* Re: [spring] Active OAM in SRv6 > > > > Hi Haoyu, > > thank you for bringing the top

Re: [spring] Active OAM in SRv6

Hi Haoyu, thank you for bringing the topic of Active OAM to the discussion. As the concept of Active IOAM is introduced in the IPPM WG draft it seems to me like adding the IPPM WG community to the discussion is the right thing to

[spring] (no subject)

___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

Re: [spring] A question for draft-fz-spring-srv6-alt-mark

> > i...@ietf.org > > > > Subject: Re: A question for draft-fz-spring-srv6-alt-mark > > > > > > > > On Tue, Nov 9, 2021 at 7:31 AM Joel M. Halpern > wrote: > > > >> > > > >> Let me try phrasing the question about the

Re: [spring] SR Policy: per-SL reverse

Hi Mike, I have a question about the possible use of the reverse SR path association and much appreciate your help understanding its use in OAM. In draft-ietf-spring-bfd we propose a new Non-FEC TLV to specify the SR policy for the reverse

Re: [spring] A question for draft-fz-spring-srv6-alt-mark

trade. > > Yours, > Joel > > On 11/8/2021 2:28 PM, Giuseppe Fioccola wrote: > > Hi Greg, > > > > Yes, with DOH + SRH, the end node of a segment should still conform to > > RFC8200, based on the discussion in 6MAN. > > > > The proposal to use HBH is also m

[spring] A question about using the STAMP in the loopback mode

Hi Rakesh, Authors et al, I much appreciate it if you can help me understand what is expected to be standardized in Section 4.2.3 of the draft. As I understand it, the transmitting test probe node constructs a

Re: [spring] A question for draft-fz-spring-srv6-alt-mark

ases. > > > > Regards, > > > > Giuseppe > > > > > > *From:* Greg Mirsky > *Sent:* Monday, November 8, 2021 2:57 PM > *To:* Giuseppe Fioccola > *Cc:* draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; > i...@ietf.org > *Subject:* Re: A

Re: [spring] A question for draft-fz-spring-srv6-alt-mark

cument would update draft-ietf-6man-ipv6-alt-mark only for SRv6: > > - in case of SRH there would be a single way to apply AltMark through SRH > TLV, > > - while for all the other cases with IPv6 data plane the use of the HbH > and DOH is the only choice to carry AltMark data fields. &g

[spring] A question for draft-fz-spring-srv6-alt-mark

Dear Authors et al. thank you for this document. I am supporting and following the work on the Alternate Marking method in various IETF WGs. What do you see as the benefits of defining a new SRH TLV for the Alternate Marking method compared to solutions defined for IPv6 in

[spring] A question about the draft-ietf-spring-stamp-srpm

Dear All, I've read the latest available version of the draft and I still cannot find the answer I've asked during the WG AP of this document: What is the value the publication of this informational document can add? Besides ASCII-art figures, I find references to RFCs (though the normative

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

ID flavor. > > > > Thanks, > > Francois > > > > *From: *Greg Mirsky > *Date: *Friday, 8 October 2021 at 22:21 > *To: *Francois Clad (fclad) > *Cc: *Robert Raszuk , Ron Bonica 40juniper@dmarc.ietf.org>, James Guichard < > james.n.guich...@futurewei

Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

Hi Brian, so far I haven't noticed a proposal to support C-SID in IGP. I think that it brings up a legitimate question: How is it going to work? Would it C-SID be used in combination with dynamic routing protocols or only from a centralized controller? Regards, Greg On Sun, Oct 24, 2021 at 2:20

Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

(because it never happens).” > > I hope this helps. > > Darren > > -- > *From:* Gyan Mishra > *Sent:* Thursday, October 21, 2021 7:03 PM > *To:* Darren Dukes (ddukes) > *Cc:* Brian E Carpenter; Greg Mirsky; i...@ietf.org; spring@ietf.org > *Subject:* Re: Typo correction

Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Hi Brian, I've got some questions about what you've said: For that reason, the fact that the bottom 64 bits in the "address" look funny or change is simply irrelevant. They are invisible to routing (which is done based on the prefix) and invisible to neighbor discovery (because it never

Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02

Hi John, thank you for equipping your question with the definition of the data plane. That helps a lot. I agree with Gyan that as the local function processing the SID encoding in an SRH container must change, so the only conclusion we can make is that the data plane that supports C-SID is

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

ncois Clad (fclad) wrote: > Hi Greg, > > > > Thank you for the confirmation. I am glad that the matter of combining > C-SIDs of different flavors is clear now. > > > > Thanks, > > Francois > > > > *From: *Greg Mirsky > *Date: *Thursday, 7 Octobe

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

to the C-SID flavors as well. The choice of > flavors for the SIDs in the SID List is up to the SR Source Node. > > > > It is indeed possible to mix SIDs of different C-SID flavors in the same > SRH, and even in a single C-SID container. > > > > Thanks, > > Francois >

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

vor(s)) (i.e. > pseudocode) of that SID. > > > > RFC 8754 and 8986 have already standardized these mechanisms and the C-SID > draft only leverages the same SRv6 dataplane to introduce new endpoint > flavors for compression. > > > > > > Francois > > > > *F

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

cket further. > > What is non-interoperable here ? I see You would love to have a few bits > next to the locator prefix to specify verbatim what to do with the packet ? > What for ? To run out of those bits in no time and make a mess ? > > On Wed, Oct 6, 2021 at 12:20 AM Greg Mir

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

e implementation choice - I would > say vendor's secret sauce. > > On Wed, Oct 6, 2021 at 12:11 AM Greg Mirsky wrote: > >> I am not asking how to deal with the fact that the mode cannot manage >> different flavors using just information that is in the packet. I am >>

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Raszuk wrote: > To me the easiest option here is to simply configure on each node selected > compression schema for the domain. Do you see anything wrong with it ? > > On Wed, Oct 6, 2021 at 12:05 AM Greg Mirsky wrote: > >> Hi Robert, >> sorry, but it doesn't seem to addr

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

t; Does this answer your and maybe Ron's question ? > > Thx, > R. > > > On Tue, Oct 5, 2021 at 11:36 PM Greg Mirsky wrote: > >> Hi Robert, >> as I understand it, you believe everything that is written in the draft. >> I hope you can help me find an answer to one

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Hi Robert, as I understand it, you believe everything that is written in the draft. I hope you can help me find an answer to one simple question: Can a node that supports this draft in its entirety, i.e., supports all "flavors" defined in the document, process received SRv6 packet with the SRH

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Hi Jim, thank you for the detailed explanation of the considerations the WG Chairs went through before starting the WG AP. As I understand it, the C-SID proposal integrates two mechanisms that were presented to the SPRING WG and thoroughly discussed as separate drafts. These are uSID and GSRv6.

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

- From: Date: Fri, Oct 1, 2021 at 4:44 PM Subject: New Version Notification for draft-mirsky-bfd-mpls-demand-10.txt To: Greg Mirsky A new version of I-D, draft-mirsky-bfd-mpls-demand-10.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG Chairs, I have a question about the proposed note to be added if the document is adopted by the SPRING WG: Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members

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

< chengweiqi...@chinamobile.com>, Greg Mirsky , Liu Aihua , Peng Shaofu A new version of I-D, draft-mirsky-6man-unified-id-sr-10.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-6man-unified-id-sr Revision: 10

Re: [spring] Conclusion from WG poll on dataplane solution for compressing segment routing over IPv6

Hi Joel et al. in evaluating a draft during a WG AP I am looking for three questions: - Is the document written reasonably well to clearly convey the problem and proposed solution? - Does the problem statement reflect a real existing challenge, an issue that needs to be solved? -

Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

Hi Bruno et al. Firstly, many thanks to the members of the Design Team for all their commitment, long hours that resulted in such good work. And equally, thanks to all who commented, discussed helping make the documents stronger. I support adoption of both drafts by the SPRING WG. I'd be glad to

[spring] A possible additional topic for the discussion by the MPLS Open DT.

10.17487/RFC8595, June 2019, <https://www.rfc-editor.org/info/rfc8595>. Author's Address Mirsky Expires 12 September 2021 [Page 3]  Internet-DraftMultiple GALMarch 2021 Greg Mirsky ZTE Corp. Email: gregory.mir...@z

Re: [spring] Last-call comments on OAM in SRv6 draft

help close them; > much appreciated. > > > > We have uploaded rev 10 to address your comments. > > https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-10 > > > > The comments are addressed as in-lined with [ZA] in the following. > > > >

[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

[spring] Last-call comments on OAM in SRv6 draft

Dear Authors, 6man and SPRING community, I have read this draft and have several comments I want to share with you. The draft is well-written and I appreciate the work authors put into it. OAM is the essential element of any networking technology and I believe it is important that this document

Re: [spring] WG Last Call draft-ietf-spring-nsh-sr

Dear All, I have several questions about the draft: - When using the approach described in Section 4, i.e., SR-based SFC with the integrated NSH, how does a re-Classifier scenario be handled? If I understand it correctly, a re-Classifier can change the SPI of the NSH coming back from

  1   2   >