Hi MAch, thank you for the update. Will continue looking for the common solution.
Regards, Greg On Fri, Nov 17, 2017 at 10:37 AM, Mach Chen <mach.c...@huawei.com> wrote: > Hi Greg, > > Not all devices have that capability, I would prefer to a solution that > will require less extra labels. > Mach > *发件人：*Greg Mirsky > *收件人：*Alexander Vainshtein, > *抄 送：*spring,Robert Raszuk,m...@ietf.org, > *时间：*2017-11-17 10:10:41 > *主 题：*Re: [mpls] [spring] Whether both E2E and SPME performance > measurement for MPLS-SR is needed? > > Dear All, > we may have lead ourselves into the woods with Readable Label Depth (RLD) > limit. AFAIK, NPUs read number of bytes of the header into the fast memory > for processing. I believe that the number of bytes is 128. If that is the > case, then what is the RLD limit? If even existing nodes are capable to *parse > SR-MPLS stack* to detect special purpose label at the BoS, then there's > no apparent need to insert SR Path Indicator more than once. Or we can > use GAL/G-ACh, as John had pointed. > > Regards, > Greg > > On Fri, Nov 17, 2017 at 8:50 AM, Alexander Vainshtein < > alexander.vainsht...@ecitele.com> wrote: > >> I concur with John. >> >> >> Thump typed by Sasha Vainshtein >> >> ------------------------------ >> *From:* John E Drake <jdr...@juniper.net> >> *Sent:* Friday, November 17, 2017 1:33:30 AM >> *To:* Robert Raszuk >> *Cc:* Alexander Vainshtein; m...@ietf.org; spring; David Allan I >> >> *Subject:* RE: [spring] [mpls] Whether both E2E and SPME performance >> measurement for MPLS-SR is needed? >> >> >> Robert, >> >> >> >> How do R6, R2, and R3 determine w/ which SR segment list a packet is >> associated? E.g., the tuples in a packet from either R1 or R5 will be the >> same. >> >> >> >> Yours Irrespectively, >> >> >> >> John >> >> >> >> *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert >> Raszuk >> *Sent:* Thursday, November 16, 2017 8:44 AM >> *To:* John E Drake <jdr...@juniper.net> >> *Cc:* Alexander Vainshtein <alexander.vainsht...@ecitele.com>; >> m...@ietf.org; spring <spring@ietf.org>; David Allan I < >> david.i.al...@ericsson.com> >> *Subject:* Re: [spring] [mpls] Whether both E2E and SPME performance >> measurement for MPLS-SR is needed? >> >> >> >> Hi John, >> >> >> >> I think I did but let me restate ... >> >> >> >> Imagine we have a network like below: >> >> >> >> >> >> R1 --- R2 --- R3 --- R4 >> >> | >> >> R5 --- R6 >> >> >> >> >> >> R1 and R5 are ingress of SR-MPLS domain and R4 is an egress. You have two >> SR-MPLS paths: >> >> >> >> P1 - R1-R2-R3-R4 >> >> P2 - R5-R6-R2-R3-R4 >> >> >> >> (I know those are SPTs but this is just for illustration). >> >> >> >> So on each ingress we need to map packets to SR paths by some match ... >> it can be based on the dst IP, src/dst IP, port # etc ... So we record >> those with respect to each path they take. >> >> >> >> Now we also record on R4 the same set of tuples. >> >> >> >> So now we have all counters needed without asking R4 to report P1 nor P2 >> (nor need to carry them in the packets) as based on the tuples count which >> are used on ingress for mapping we can correlate in offline tool the exact >> count of traffic per ingress segment chain. >> >> >> >> In fact we can also derive per path stats even from transit nodes with >> exact the same type of offline data correlation. >> >> >> >> Does anyone see any issue ? Is going offline so bad that we must add >> labels and modify all hardware to be able to have comfort of using router's >> CLI to get this data on the routers itself ? >> >> >> >> Thx, >> >> R. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Nov 16, 2017 at 1:39 PM, John E Drake <jdr...@juniper.net> wrote: >> >> Hi, >> >> >> >> Or even just an extended email. >> >> >> >> Yours Irrespectively, >> >> >> >> John >> >> >> >> *From:* Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com] >> *Sent:* Thursday, November 16, 2017 6:59 AM >> *To:* Robert Raszuk <rob...@raszuk.net> >> *Cc:* m...@ietf.org; spring <spring@ietf.org>; David Allan I < >> david.i.al...@ericsson.com>; John E Drake <jdr...@juniper.net> >> *Subject:* RE: [spring] [mpls] Whether both E2E and SPME performance >> measurement for MPLS-SR is needed? >> >> >> >> Robert, >> >> Do you plan to post a draft that explains how this can be achieved >> without changing anything on the wire? >> >> Without such a draft it is a bit difficult to compare the solutions:-) >> >> >> >> Regards, >> >> Sasha >> >> >> >> Office: +972-39266302 <+972%203-926-6302> >> >> Cell: +972-549266302 <+972%2054-926-6302> >> >> Email: alexander.vainsht...@ecitele.com >> >> >> >> *From:* spring [mailto:spring-boun...@ietf.org <spring-boun...@ietf.org>] >> *On Behalf Of *Robert Raszuk >> *Sent:* Thursday, November 16, 2017 1:53 PM >> *To:* John E Drake <jdr...@juniper.net> >> *Cc:* m...@ietf.org; spring <spring@ietf.org>; David Allan I < >> david.i.al...@ericsson.com> >> *Subject:* Re: [spring] [mpls] Whether both E2E and SPME performance >> measurement for MPLS-SR is needed? >> >> >> >> 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-acc >> ounting-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/dr >> aft-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=> >> >> >> >> >> ____________________________________________________________ >> _______________ >> >> 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. >> ____________________________________________________________ >> _______________ >> >> >> >> ____________________________________________________________ >> _______________ >> >> 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 >> >> >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
