[spring] Re: [bess] Re: Inverse multi-layer OAM

s to comment on the running thread >rather than middle of the thread causing the forks. > > > > Please take this discussions to the SPRING mailing list. > > > > Thanks, > > Himanshu > > > > > > *From: *Zafar Ali (zali) > *Date: *Thursday,

[spring] Inverse multi-layer OAM

Hi Himanshu, > > Thank you for the presentation of > draft-karboubi-spring-sidlist-optimized-cs-sr > . > If I understood your response to Ali correctly, the proposed mechanism is > expected to use more aggressive netwo

[spring] Re: WGLC Chair review of draft-ietf-spring-bfd-12

Hi Alvaro, thank you for you detailed and helpful feedback. I'm working on addressing your comments and resolving outstanding concerns. Regards, Greg On Wed, Feb 19, 2025 at 1:30 AM Alvaro Retana wrote: > On February 1, 2025 at 6:43:12 PM, Greg Mirsky wrote: > > > Greg: >

[spring] Re: [Last-Call] Re: [RTG-DIR]Rtgdir last call review of draft-ietf-spring-bfd-12

captured and addressed > my comments. Thank you! > > /Loa > > Den 02/02/2025 kl. 00:43, skrev Greg Mirsky: > > Hi Loa, > > thank you for your thorough review and constructive comments; greatly > > appreciated. My apologies for the belated response. Please find my note

[spring] Re: Tsvart last call review of draft-ietf-spring-bfd-12

Hi Brian, thank you for your review and the conclusion. Regards, Greg On Mon, Jan 27, 2025 at 12:07 AM Brian Trammell via Datatracker < nore...@ietf.org> wrote: > Reviewer: Brian Trammell > Review result: Ready > > This document has been reviewed as part of the transport area review team's > ong

[spring] Re: WGLC Status for draft-ietf-spring-bfd

Hi Alvaro, I sincerely apologize for my poor communication. We are working on addressing your comments and RtgDir review . We appreciate the TSV review and are working on updates. We will share them with you

[spring] Re: WGLC for draft-ietf-spring-bfd (ends Dec/16)

Hi Jeff, thank you for the discussion. Please find my notes below tagged GIM3>>. Regards, Greg On Fri, Dec 13, 2024 at 9:47 AM Jeffrey Haas wrote: > Greg, > > > On Dec 12, 2024, at 7:22 PM, Greg Mirsky wrote: > > On Thu, Dec 12, 2024 at 11:55 AM Jeffrey Haas wrote: &

[spring] Re: WGLC for draft-ietf-spring-bfd (ends Dec/16)

Hi Jeff, thank you for the expedient response. Please find my follow-up notes below tagged GIM2>>. Regards, Greg On Thu, Dec 12, 2024 at 11:55 AM Jeffrey Haas wrote: > Greg, > > > On Dec 12, 2024, at 2:51 PM, Greg Mirsky wrote: > > On Thu, Dec 12, 2024 at 6:31 AM Jeff

[spring] Re: WGLC for draft-ietf-spring-bfd (ends Dec/16)

Hi Jeff, tank you for your review and comments. Please find my notes below tagged GIM>>. Regards, Greg On Thu, Dec 12, 2024 at 6:31 AM Jeffrey Haas wrote: > Alvaro, > > Here is a small review comment on draft-ietf-spring-bfd. > > In section 6, discussing BFD Echo (not Echo BFD), the text states

[spring] Re: WGLC for draft-ietf-spring-bfd (ends Dec/16)

Hi, Alvaro et al., As a co-author, I support moving this document forward to the publication. Regards, Greg On Mon, Dec 2, 2024 at 11:51 AM Alvaro Retana wrote: > [Sorry for the bad formatting. :-(] > > [cc'ing the bfd WG] > > > Dear WG: > > This message starts a two-week WG Last Call for draft

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

Hi Alvaro et al., I am not aware of any undisclosed IPR that is related to this draft. Regards, Greg On Mon, Dec 2, 2024 at 11:53 AM Alvaro Retana wrote: > [Sorry ofr the bad formatting. :-( ] > > > [cc'ing the bfd WG] > > > Dear authors and contributors: > > Are you aware of any IPR that appli

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

Hi Alvaro, thank you for your comments and suggestions. I will work on updating the draft and share the working version. Regards, Greg On Mon, Dec 2, 2024 at 2:12 PM Alvaro Retana wrote: > [I recently updated my email client and the formatting seems to be > broken…. ] > > > Greg/authors: > > ..

[spring] Re: Mail regarding draft-ietf-spring-stamp-srpm

Hi Rakesh, please kindly consider my notes: - I would propose a brief clarification for Section 4.5.1: An SRv6 Policy may suppress the tail-end node SID when adding an L3/L2 service SID in the packet's segment list to avoid tail-end processing two incoming SRv6 SIDs. In this case, the Session-

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

Networking (SPRING) WG of the IETF. Title: Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPLS Dataplane Authors: Greg Mirsky Jeff Tantsura Ilya Varlashkin Mach(Guoyi) Chen Jiang Wenying Name:draft-ietf-spring-bfd-12

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

do a deeper read of > the document. > > Alvaro. > > On September 9, 2024 at 10:44:22 AM, Greg Mirsky (gregimir...@gmail.com) > wrote: > > Hi Alvaro, > thank you for your thoughtful and helpful suggestions. Please find my > notes below tagged GIM>>. I've i

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

5 PM Alvaro Retana wrote: > On August 28, 2024 at 7:31:23 PM, Greg Mirsky wrote: > > Greg: > > Hi! > > > ... > > > 516 12. Security Considerations > > > > > > 518 Security considerations discussed in [RFC5880], [RFC5884], > [RFC7726], > &

[spring] Re: spring Digest, Vol 129, Issue 43

;For example, one single PSID MAY be used to identify some or all > >segment lists in a candidate path or an SR policy if an operator > >would like to aggregate these segment lists in operation. > > > > Thank you for your comments 😊 > > > > Resp

[spring] Re: spring Digest, Vol 129, Issue 43

Hi Cheng, I think that there some information about the per SR Policy performance measurement is not clear to me. AFAIK, performance measurement methods support concurrent test sessions over the same path between the particular set (p2p or p2mp) of systems. For example, in STAMP one can use Stamp S

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

Using MPLS Dataplane Authors: Greg Mirsky Jeff Tantsura Ilya Varlashkin Mach(Guoyi) Chen Jiang Wenying Name:draft-ietf-spring-bfd-11.txt Pages: 16 Dates: 2024-09-05 Abstract: Segment Routing (SR) architecture leverages the

[spring] Re: spring Charter Update (charter-ietf-spring)

Hi Alvaro, thank you for sharing the proposed updates to the SPRING charter. It all looks good to me. I have a minor proposal to the extend the list of the topics on which SPRING collaborates and coordinates adding the following: IPPM on performance measurement methods and metrics Regards, Greg

[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 d

[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 you

[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

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, Aut

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 > BCP

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 actio

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: > > > thank

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

e). If you 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 > ... > &

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

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

ch 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

an be 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 Sessi

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

xt To: 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

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 lis

[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 draft-ietf-spri

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 methods:

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 “and

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 c

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 detail

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

g 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, >>

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

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, ar

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 th

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 identifi

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

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,

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 SPRIN

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

rom: Date: 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-spri

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

s IETF aspect 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 solutio

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

s. > > 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 *

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 t

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

pe.fiocc...@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, Febru

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 seg

[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 d

[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 https://www.ietf.org/mailman/listin

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

t-voyer-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

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 refe

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

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 > > > > > > *From: *Greg Mirsky > *Date: *Tuesday, 15 February 2022 at

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

. We 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 > > > > Mat

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

is the “best possible” >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 S

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

n’t enforce 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:

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

d something. > 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

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

think 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

e such use 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, Februa

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

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

[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 forwar

[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 co

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

mparison. 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:* G

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

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? A

Re: [spring] Active OAM in SRv6

t > background) and for gray 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! > > Hao

Re: [spring] Active OAM in SRv6

oring/> 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

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 topic

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 do

[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

aft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; > > > > 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: > > > >> &g

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 d

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 pack

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

ocument 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 field

[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 draft-ietf-6man-ipv6-alt-

[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 refe

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

ith another C-SID 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..

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 P

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 happens).

  1   2   3   >