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

Hi Ahmed, thanks for the update. I like the approach taken, especially using a small and deterministic packet format which doesn't change while passing nodes. Are there any plans of the WG to adopt this draft - looking at the list of co-authors, some network operators seem to be interested in

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

Hi Ahmed, Thanks for the draft. I appreciate the small and well specified format of the measurement and hope that endpoints and transit routers supporting Path Tracing in SRv6 networks are able to fill in the specified fields at linerate during forwarding. I'd also appreciate an SR-MPLS

[spring] WG: [ippm] Call for adoption: draft-geib-ippm-connectivity-monitoring

Dear Spring WG, IPPM started a call for adoption of draft-geib-ippm-connectivity-monitoring-03. The (tomographic) metric suggested by the draft can only be measured applying SR, that's why I forward the call for adoption to the SR list. I appreciate your support on

[spring] WG: New Version Notification for draft-geib-spring-oam-opt-00.txt

Dear Spring-chairs, dear WG The new draft below describes how to reduce the number of SR MPLS Echo request / reply dialogues in the presence of ECMP (RFC 8029 section 4.1 Dealing with Equal-Cost Multipath (ECMP) remarks "However, full coverage may not be possible" to say that no all paths of

Re: [spring] Monitoring metric to detect and locate congestion

Hi Tianran, using node based information like added by IOAM is another valid option. The method I propose is to stay at forwarding layer and work without node support. That way forwarding issues are detected, even if the control plane isn’t aware of it. Also that happens. Active measurements

Re: [spring] Monitoring metric to detect and locate congestion

Hi Haoyu, thanks for your remarks. Let me pick up your numbering 1. IOAM information could be added by a passed router, if there's interest. The draft doesn't exclude that. But that's not in focus either. I didn't make up my mind, whether and which IOAM information may add value to such

Re: [spring] Monitoring metric to detect and locate congestion

Hi Al, the draft explains the “or” in section “2. A brief segment routing connectivity monitoring framework” (the last bullet point list at the end of the section). Segment Routing allows to concatenate Tranport Labels, which carry routing information following SPF. A loss in connectivity is

Re: [spring] Monitoring metric to detect and locate congestion

Hi Robert, thanks for your support and comments. I’d be glad if other interested operator representatives indicate their interest on the list... Regards, Ruediger Von: Robert Raszuk Gesendet: Donnerstag, 27. Februar 2020 10:38 An: Geib, Rüdiger Cc: ippm-cha...@ietf.org; SPRING WG ;

Re: [spring] Monitoring metric to detect and locate congestion

Hi Robert, regarding scalability, I hope the difference between our positions is just whether it’s a router or a dedicated CPE. I don’t promote deploying 20k PCs (I hope to promote a metric to replace them). I prefer the dedicated CPE, but routers do as well. The telemetry threshold might be

Re: [spring] Monitoring metric to detect and locate congestion

Hi Robert, Thanks, my replies in line marked [RG1] I have read your draft and presentation with interest as I am a big supporter and in some lab trials of end to end network path probing. Few comments, observations, questions: You are essentially measuring and comparing delay across N paths

[spring] Monitoring metric to detect and locate congestion

Dear IPPM (and SPRING) participants, I'm solliciting interest in a new network monitoring metric which allows to detect and locate congested interfaces. Important properties are * Same scalability as ICMP ping in the sense one measurement relation required per monitored connection *

Re: [spring] Implementation Requirement Policy

Hi Bruno, my preference is for a). Interoperability is a requirement discussed with vendors ahead of implementation. The sooner issues are discovered and removed, the better. The interoperable implementations should be from completely independent implementors. The detailed implementation

Re: [spring] WG Review: Source Packet Routing in Networking (spring)

Hi Bruno, one comment on the proposed agenda, o New types of segments mapping to forwarding behaviour (e.g., local ingress replication, local forwarding resources, a pre-existing replication structure) if needed for new usages. [RG] The multicast part has been agreed. I personally am not

Re: [spring] Updating the SPRING WG Charter

Hi Bruno, thanks, looks good to me. Regards, Ruediger Von: spring [mailto:spring-boun...@ietf.org] Im Auftrag von bruno.decra...@orange.com Gesendet: Donnerstag, 28. Juni 2018 14:52 An: SPRING WG List Betreff: Re: [spring] Updating the SPRING WG Charter Hi SPRING, Following the discussion

Re: [spring] Updating the SPRING WG Charter

There’s no objection against policies installed at ingress interfaces to an SR domain. Rob correctly states, that the SR architecture does not require per path state at transit nodes. And that’s good and correct. I’d like to see the number of signaling protocols in the SR core network being

Re: [spring] Updating the SPRING WG Charter

Dear Ji, you’ve written „Although SR can rely on the network controller for global traffic optimization and placement, there is no mechanism to provide resource guarantee and service separation in the data plane.” If this is linked to maintenance of per segment (or per segment range) state on

Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-14

Dear authors, I've read the document and have one minor comment and 3 editorials/nits, see below. As a general comment from a non-native speaker I'd suggest a review by a native speaker (noting that one of the authors is a native speaker). I went through that with some of the informational

Re: [spring] IETF 101 minutes

some more links, https://datatracker.ietf.org/doc/minutes-101-spring/ https://datatracker.ietf.org/meeting/101/materials/minutes-101-spring-00.txt The link below didn’t work in my browser. Thanks for the minutes. Regards, Ruediger Von: spring [mailto:spring-boun...@ietf.org] Im Auftrag von

Re: [spring] What is "TE" and the rechartering discussion

Hi Adrian, sure, I hope we'll soon see a fairly well defined revised Spring charter. If "Spring policy routing" isn't sufficiently well defined for the new charter, let's improve that (without writing a book, though..). I think success of any WG depends on a charter (or framework) defining the

Re: [spring] What is "TE" and the rechartering discussion

Hi Adrian, that's a fair proposal, I think. In addition, it may help to avoid the term "Traffic Engineering" when rechartering Spring. Spring needs to recharter now. I didn't see any emails on the list which advised against Spring policy routing and the related OAM mechanisms as future work

Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

Martin, Thanks. I’d be glad if the discussion returns to charter contents and usual WG cooperation. Work of TEAS should progress independently from Spring. My take of the TEAS WG is, that Traffic Engineering linked to RSVP TE is covered there. Spring policy routing isn’t linked to RSVP-TE

Re: [spring] SPRING - rechartering discussion

Dear WG Chairs, I agree with Zafar that the OAM topics listed below are of high importance. Off-list activities on the topics below has been going on for years and the current status is that the first drafts were submitted to IETF Spring WG. From my point of view standardized solutions are

Re: [spring] Deborah Brungard's No Objection on draft-ietf-spring-oam-usecase-09: (with COMMENT)

Hi Deborah, hi Ben, after having received an IESG state change to "Approved-announcement to be sent::Revised I-D Needed", we've submitted https://www.ietf.org/id/draft-ietf-spring-oam-usecase-10.txt We didn't agree on two issues. However we added text trying to improve the draft. It is marked

Re: [spring] Deborah Brungard's No Objection on draft-ietf-spring-oam-usecase-09: (with COMMENT)

Hi Deborah, thanks for your comment. Your suggestion to describe the PMS as a functional component (and a use case "separate physical unit") is good. I have no command of SDN or RFC5623 related terminology yet. I'll have to read a little before I start to parse the draft and adapt text. I'll

Re: [spring] ***CAUTION_Invalid_Signature*** Re: Ben Campbell's No Objection on draft-ietf-spring-oam-usecase-09: (with COMMENT)

Hi Ben, thanks for your help. I repeat sections with agreed text following your suggestions below. I’d like to start with your question related to the content: > -- [BC 1] 10, last paragraph: I don't understand the intent of this > paragraph. > > [RG 1] > > OLD:A PMS may operate

Re: [spring] Ben Campbell's No Objection on draft-ietf-spring-oam-usecase-09: (with COMMENT)

Hi Ben, again thanks for your comments. Please find new text proposals below. A line indent followed by [RG] marks the starting point for proposed text changes. Nits: comment followed by a brief statement, beginning with [RG]. Regards, Ruediger -Ursprüngliche Nachricht- Von: Ben

Re: [spring] Ben Campbell's No Objection on draft-ietf-spring-oam-usecase-09: (with COMMENT)

Hi Ben, thanks for your comments. I started to agree text changes with my co-editor. Takeshi and you commented on the same sentence, which can't be parsed. Your comment: -10 --5th paragraph: I can't parse the last sentence. Takeshi's comment: 3. This sentence "As it is necessary to know

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

John, that’s not what I’m looking for. What I’m looking for is traffic statistics collected at transit nodes. These statistics should reveal the true end-to-end traffic demand within the MPLS domain. The collection of statistics shouldn’t add complexity. A low number of counters helps to

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

Dave, there’s a scalability aspect in TE traffic matrix calculation if TE isn’t based on RSVP-TE. Regards, Ruediger DA> BTW transmit measurement points without e2e measurement points strikes me as bizarre…. The view from here Dave From: spring [mailto:spring-boun...@ietf.org] On Behalf Of

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

Adrian, to me, there’s no ideal solution. But an analysis may help to find a useful solution. There’s a need to collect traffic statistics also for packets which don’t follow the shortest end to end path. There’s no simple howto, I think. For the time being, I’d prefer not to add special

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

Sasha, the purpose of the SR OAM Use Case is to illustrate how Segment Routing enables new ways to perform OAM tasks. Like delay measurements. What is discussed here are new OAM requirements caused by SR. To me, these are part of an own or a different draft. The scope of the SR OAM Use Case

Re: [spring] Rtgdir last call review of draft-ietf-spring-oam-usecase-06

Hi Joel, thanks for your review. The comments of the draft editors are marked [ED] inserted in your text below. Regards, Ruediger ## Minor: [JH] The introduction treats having a single centralized monitoring system as an unalloyed positive. To set context properly, it would

Re: [spring] Genart last call review of draft-ietf-spring-oam-usecase-06

Hi Pete, thanks for proposing to make this an Applicability Statement, BCP or standard. I don't object, but if the status of this draft is supposed to be changed, my chairs and AD need to support this. Bruno and Alvaro, what's your view on Pete's proposal? We may have to invest some more time

Re: [spring] AD Review of draft-ietf-spring-oam-usecase-06

Hi Alvaro, we are fine, hope you are too - thanks for your review and comments. As we work with two editors, our comments are marked [ED]. [AR] Major: [AR] M1. The Introduction says that the monitoring system described in this document will be simplified “by enabling MPLS topology detection

Re: [spring] draft-ietf-spring-oam-usecase - shepherd review

Hi Bruno, thanks for your new review. I've tried to adapt text and deleted the related sections below. In some cases, I didn't change text, that's discussed below (marked [RG]). Regards, Ruediger Name: draft-ietf-spring-oam-usecase Revision: 06 Title:A Scalable and

[spring] WG: draft-ietf-spring-oam-usecase - shepherd review

Hi Bruno, thanks for your thorough review. Your comments help to clarify how to use SR to improve monitoring of an MPLS domain. We've adapted text, there's some mostly minor discussion on a few issues. Comments are marked [RG] in your text below. Version -05 has just been submitted. Regards,

Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06

I also support the document. Regards, Ruediger -Original Message- From: Martin Vigoureux [mailto:martin.vigour...@nokia.com] Sent: Friday, January 27, 2017 12:05 To: spring@ietf.org Cc: draft-ietf-spring-segment-routing-m...@ietf.org Subject: WG Last Call for

Re: [spring] draft-ietf-spring-oam-usecase - shepherd review

Hi Bruno, before reading - thanks for sheperding and thanks for your review. Hope, you had a good start into 2017, Ruediger Von: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com] Gesendet: Dienstag, 17. Januar 2017 17:35 An: draft-ietf-spring-oam-usec...@ietf.org Cc:

Re: [spring] IPR for draft-ietf-spring-oam-usecase prior to WGLC

Hi John, I'm aware of the following IPR: IPR disclosure to "A Scalable and Topology-Aware MPLS Dataplane Monitoring System" (draft-ietf-spring-oam-usecase): https://datatracker.ietf.org/ipr/2314/ I'm not aware of another IPR related to draft-ietf-spring-oam-usecase. Regards, Ruediger

[spring] WG: New Version Notification for draft-geib-spring-oam-usecase-05.txt

Chairs, editorial changes only. The authors still wait for a decision of the chairs how to make progress on the draft. Regards, Ruediger -Ursprüngliche Nachricht- Von: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Gesendet: Mittwoch, 1. Juli 2015 14:17 An: Nagendra

Re: [spring] WG Adoption Call for draft-filsfils-spring-segment-routing

I support adaption as WG document. Von: spring [mailto:spring-boun...@ietf.org] Im Auftrag von Alvaro Retana (aretana) Gesendet: Mittwoch, 24. September 2014 15:02 An: spring@ietf.org Cc: draft-filsfils-spring-segment-rout...@tools.ietf.org Betreff: [spring] WG Adoption Call for

Re: [spring] WG Adoption Call for draft-filsfils-spring-segment-routing-mpls

I support adoption as a WG document. Von: spring [mailto:spring-boun...@ietf.org] Im Auftrag von Alvaro Retana (aretana) Gesendet: Mittwoch, 24. September 2014 15:08 An: spring@ietf.org Cc: draft-filsfils-spring-segment-routing-m...@tools.ietf.org Betreff: [spring] WG Adoption Call for

Re: [spring] IPR Claims related to draft-ietf-spring-problem-statement

Hi Alvaro, I'm not aware of any IPR claims related to draft-ietf-spring-problem-statement. I support adoption of this draft as a co-author. Regards, Ruediger Von: Alvaro Retana (aretana) [mailto:aret...@cisco.com] Gesendet: Dienstag, 23. September 2014 20:35 An:

Re: [spring] SPRING MPLS and Entropy Label

Hi Rob, I agree, a single ELI/EL deeper in the stack as proposed by §3.1 is the most useful target solution also from my point of view. Regards, Ruediger -Message- From: spring [mailto:spring-boun...@ietf.org] Rob Shakir Hi Sri! [snip] rjs Addressing the final goal - as per