Hi John, If so I stand by my msgs stating that you can accomplish your goal without putting anything new on the wire.
Best, r. On Nov 16, 2017 19:43, "John E Drake" <jdr...@juniper.net> wrote: > Robert, > > > > I think you’re right that ‘SR Path Id’ is the wrong term and that it > should be ‘SR Segment List Id’. We developed this draft in response to > requests from our customers that, as described in our draft, have an > interface on a node in the interior of an SR network whose utilization is > above a given threshold. In this situation, they need to be able to know > which ingress nodes using which SR segment lists are sending traffic to > that interface and how much traffic each ingress nodes is sending on each > of its SR segment lists. > > > > This will allow the SR segment lists in question to be adjusted in order > to steer traffic away from that interface in a controlled manner. > > > > Yours Irrespectively, > > > > John > > > > *From:* mpls [mailto:mpls-boun...@ietf.org] *On Behalf Of *Robert Raszuk > *Sent:* Thursday, November 16, 2017 5:53 AM > *To:* David Allan I <david.i.al...@ericsson.com> > *Cc:* mpls <m...@ietf.org>; spring <spring@ietf.org> > *Subject:* Re: [mpls] Whether both E2E and SPME performance measurement > for MPLS-SR is needed? > > > > /* resending and I got suppressed due to exceeding # of recipients */ > > > > Dave, > > > > Two main fundamental points: > > > > 1. > > > > Is there any assumption that SR-MPLS paths are end to end (ingress to > egress) of a given domain ? > > > > SR does not require end to end paths. In fact 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 here even apply ? > > > > 2. > > > > To make a construct of a SR PATH you must assume that SR segments are > tightly coupled. And this is very bad as by design segments are not coupled > to each other and in fact can be chosen dynamically in transit nodes. In > those cases there is no concept of SR PATH at all. > > > > Thx, > > R. > > > > On Thu, Nov 16, 2017 at 10:56 AM, David Allan I < > david.i.al...@ericsson.com> wrote: > > I’d rephrase this to be a bit more solution agnostic…. > > > > 1. Is E2E PM required. (and this can only be achieved with pairwise > measurement points). > > > > 2. Are transit measurement points required as well….. > > > > 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 *Mach Chen > *Sent:* Thursday, November 16, 2017 5:51 PM > *To:* Greg Mirsky <gregimir...@gmail.com>; Alexander Vainshtein < > alexander.vainsht...@ecitele.com> > *Cc:* draft-hegde-spring-traffic-accounting-for-sr-paths < > draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring < > spring@ietf.org>; mpls <m...@ietf.org>; Michael Gorokhovsky < > michael.gorokhov...@ecitele.com>; draft-ietf-spring-oam-usec...@ietf.org; > Zafar Ali (zali) <z...@cisco.com> > *Subject:* [spring] Whether both E2E and SPME performance measurement for > MPLS-SR is needed? > > > > Hi all, > > > > I agree with Sasha and Greg here! > > > > I think the first thing we need to agree on the requirements, then discuss > the solution will make more sense. I would ask the following questions: > > > > 1. Is only E2E PM needed for MPLS-SR? > > 2. Is only SPME PM needed for MPLS-SR? > > 3. Are both E2E and SPME PM needed for MPLS-SR? > > > > Best regards, > > Mach > > > > > > *From:* mpls [mailto:mpls-boun...@ietf.org <mpls-boun...@ietf.org>] *On > Behalf Of *Greg Mirsky > *Sent:* Thursday, November 16, 2017 5:15 PM > *To:* Alexander Vainshtein > *Cc:* draft-hegde-spring-traffic-accounting-for-sr-paths; spring; mpls; > Michael Gorokhovsky; draft-ietf-spring-oam-usec...@ietf.org; Zafar Ali > (zali) > *Subject:* Re: [mpls] [spring] Special purpose labels in > draft-hegde-spring-traffic-accounting-for-sr-paths > > > > Hi Sasha, > > many thanks. > > I'd point to SR OAM Requirements > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsr-2Doam-2Drequirement-2D03&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=NMHWJAxk35ikFsOqNiswcGOWr8RLMKDjZIVUWOKbHng&s=O9dIUxKQrlwTmypTpQrHJI2ctXc1U5kWcUB1yEsqPsA&e=> > (regrettably expired): > > REQ#13: SR OAM MUST have the ability to measure Packet loss, Packet > > Delay or Delay variation using Active (using synthetic > > probe) and Passive (using data stream) mode. > > > > I think that our discussion indicates that OAM requirements document is > useful at least for as long as we're developing OAM toolset. And the document > will benefit from clarification to reflect our discussion that PM may be > performed both e2e and over SPME. > > > > Regards, > > Greg > > > > On Thu, Nov 16, 2017 at 4:11 PM, Alexander Vainshtein < > alexander.vainsht...@ecitele.com> wrote: > > Greg, > > I concur with your position: let’s first of all agree that ability to > measure traffic carried by an SR-TE LSP in a specific transit node is a > require OAM function for SR. > > > > I have looked up the SR OAM Use Cases > <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dspring-2Doam-2Dusecase_-3Finclude-5Ftext-3D1&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=NMHWJAxk35ikFsOqNiswcGOWr8RLMKDjZIVUWOKbHng&s=ZBzVsWlwT1TW-rc8hRIu2oXOGTGFWyN8oEpwHOiK63Q&e=> > draft, and I did not find any relevant use cases there. > > The only time measurements are mentioned is a reference to an expired > implementation report > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dleipnitz-2Dspring-2Dpms-2Dimplementation-2Dreport-2D00&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=NMHWJAxk35ikFsOqNiswcGOWr8RLMKDjZIVUWOKbHng&s=QfQBqcrZK7iG73fzIFm7Pt92DgaVOiHkhujytZ0q_zo&e=> > draft discussing delay measurements. Since delay measurements are in any > case based on synthetic traffic, and are always end-to-end (one-way or > two-way), this reference is not relevant, IMHO, for this discussion. > > > > I have added the authors of the SR OAM Use Cases draft to tis thread. > > > > Regards, > > Sasha > > > > Office: +972-39266302 <+972%203-926-6302> > > 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> > *Cc:* draft-hegde-spring-traffic-accounting-for-sr-paths < > draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>; spring < > spring@ietf.org>; Zafar Ali (zali) <z...@cisco.com>; mpls <m...@ietf.org> > *Subject:* Re: [mpls] [spring] Special purpose labels in > draft-hegde-spring-traffic-accounting-for-sr-paths > > > > Dear All, > > I cannot imagine that operators will agree to deploy network that lacks > critical OAM tools to monitor performance and troubleshoot the network. > True, some will brave the challenge and be the early adopters but even they > will likely request that the OAM toolbox be sufficient to support their > operational needs. I see that this work clearly describes the problem and > why ability to quantify the flow behavior at internal nodes is important > for efficient network operation. First let's discuss whether the case and > requirement towards OAM is real and valid. Then we can continue to > discussion of what measurement method to use. > > > > Regards, > > Greg > > > > On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu <xuxia...@huawei.com> wrote: > > Concur. Although it has some values, it's not cost-efficient from my point > of view. Network simplicity should be the first priority object. Hence we > would have to make some compromise. > > Best regards, > Xiaohu > ------------------------------ > > 徐小虎 Xuxiaohu > M：+86-13910161692 > E：xuxia...@huawei.com > 产品与解决方案-网络战略与业务发展部 > Products & Solutions-Network Strategy & Business Development Dept > > *发件人：* Zafar Ali (zali) > > *收件人：* Greg Mirsky<gregimir...@gmail.com>;draft-hegde-spring-traffic- > accounting-for-sr-paths<draft-hegde-spring-traffic- > accounting-for-sr-pa...@ietf.org>;mpls<m...@ietf.org>;spring< > spring@ietf.org> > > *主**题：* Re: [mpls] [spring] Special purpose labels in > draft-hegde-spring-traffic-accounting-for-sr-paths > > *时间：* 2017-11-16 02:24:10 > > > > Hi, > > > > This draft breaks the SR architecture. I am quoting a snippet from > abstract of SR Architecture document https://tools.ietf.org/html/ > draft-ietf-spring-segment-routing-13 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D13&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=NMHWJAxk35ikFsOqNiswcGOWr8RLMKDjZIVUWOKbHng&s=xKKBtL1_7pyQ6k9hakXPemUtJJc9c8wKgw2FgwYttIg&e=>, > which states: > > “SR allows to enforce a flow through any topological path while > maintaining per-flow state only at the ingress nodes to the SR domain.” > > > > In addition to creating states at transit and egress nodes, the procedure > also affects the data plane and makes it unscalable. It also makes > controller job much harder and error prune. In summary, I find the > procedure very complex and unscalable. > > > > Thanks > > > > Regards … Zafar > > > > > > *From: *spring <spring-boun...@ietf.org> on behalf of Greg Mirsky < > gregimir...@gmail.com> > *Date: *Wednesday, November 15, 2017 at 11:10 AM > *To: *"draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org" < > draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, " > m...@ietf.org" <m...@ietf.org>, "spring@ietf.org" <spring@ietf.org> > *Subject: *[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 for each case. Then the SR Path Identifier > would not have to lose the bit for C flag. > - And how you envision to collect the counters along the path? Of > course, a Controller may query LSR for all counters or counters for the > particular flow (SR Path Identifier+Source SID). But in addition I'd > propose to use in-band mechanism, perhaps another special purpose label, to > trigger the LSR to send counters of the same flow with the timestamp > out-band to the predefined Collector. > - And the last, have you considered ability to flush counters per > flow. In Scalability Considerations you've stated that counters are > maintained as long as collection of statistics is enabled. If that is on > the node scope, you may have to turn off/on the collection to flush off > some old counters. I think that finer granularity, per flow granularity > would be useful for operators. Again, perhaps the flow itself may be used > to signal the end of the measurement and trigger release of counters. > > Regards, > > Greg > > > > > ____________________________________________________________ > _______________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > ____________________________________________________________ > _______________ > > > > > _______________________________________________ > mpls mailing list > m...@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=NMHWJAxk35ikFsOqNiswcGOWr8RLMKDjZIVUWOKbHng&s=08NHkgGh3s2IUy6RcA-PJ9m6Un8j-FQd_zZABnvAz9Q&e=> > > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
