How the same packet can be received (or generated) by both R1 and R5 from other domains or sources ?
If network would do that it is likely to get reordered ins't it ? At least l3+l4 tuple should identify packets without any problem. If this is vpn packets in transit let's also add vpn label. Thx R. On Nov 17, 2017 00:51, "John E Drake" <[email protected]> wrote: > Robert, > > > > Upon reflection, the same question can be asked of R4. > > > > Yours Irrespectively, > > > > John > > > > *From:* John E Drake > *Sent:* Thursday, November 16, 2017 6:34 PM > *To:* Robert Raszuk <[email protected]> > *Cc:* Alexander Vainshtein <[email protected]>; > [email protected]; spring <[email protected]>; David Allan I < > [email protected]> > *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:* [email protected] [mailto:[email protected] <[email protected]>] *On > Behalf Of *Robert Raszuk > *Sent:* Thursday, November 16, 2017 8:44 AM > *To:* John E Drake <[email protected]> > *Cc:* Alexander Vainshtein <[email protected]>; > [email protected]; spring <[email protected]>; David Allan I < > [email protected]> > *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 <[email protected]> wrote: > > Hi, > > > > Or even just an extended email. > > > > Yours Irrespectively, > > > > John > > > > *From:* Alexander Vainshtein [mailto:[email protected]] > *Sent:* Thursday, November 16, 2017 6:59 AM > *To:* Robert Raszuk <[email protected]> > *Cc:* [email protected]; spring <[email protected]>; David Allan I < > [email protected]>; John E Drake <[email protected]> > *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: [email protected] > > > > *From:* spring [mailto:[email protected] <[email protected]>] *On > Behalf Of *Robert Raszuk > *Sent:* Thursday, November 16, 2017 1:53 PM > *To:* John E Drake <[email protected]> > *Cc:* [email protected]; spring <[email protected]>; David Allan I < > [email protected]> > *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" <[email protected]> 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:[email protected]] *On Behalf Of *Robert Raszuk > *Sent:* Thursday, November 16, 2017 5:53 AM > *To:* David Allan I <[email protected]> > *Cc:* mpls <[email protected]>; spring <[email protected]> > *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 < > [email protected]> 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:[email protected]] *On Behalf Of *Mach Chen > *Sent:* Thursday, November 16, 2017 5:51 PM > *To:* Greg Mirsky <[email protected]>; Alexander Vainshtein < > [email protected]> > *Cc:* draft-hegde-spring-traffic-accounting-for-sr-paths < > [email protected]>; spring < > [email protected]>; mpls <[email protected]>; Michael Gorokhovsky < > [email protected]>; [email protected]; > Zafar Ali (zali) <[email protected]> > *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:[email protected] <[email protected]>] *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; [email protected]; 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 < > [email protected]> 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: [email protected] > > > > *From:* mpls [mailto:[email protected]] *On Behalf Of *Greg Mirsky > *Sent:* Thursday, November 16, 2017 4:28 AM > *To:* Xuxiaohu <[email protected]> > *Cc:* draft-hegde-spring-traffic-accounting-for-sr-paths < > [email protected]>; spring < > [email protected]>; Zafar Ali (zali) <[email protected]>; mpls <[email protected]> > *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 <[email protected]> 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：[email protected] > 产品与解决方案-网络战略与业务发展部 > Products & Solutions-Network Strategy & Business Development Dept > > *发件人：* Zafar Ali (zali) > > *收件人：* Greg Mirsky<[email protected]>;draft-hegde-spring-traffic- > accounting-for-sr-paths<draft-hegde-spring-traffic- > [email protected]>;mpls<[email protected]>;spring< > [email protected]> > > *主**题：* 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 <[email protected]> on behalf of Greg Mirsky < > [email protected]> > *Date: *Wednesday, November 15, 2017 at 11:10 AM > *To: *"[email protected]" < > [email protected]>, " > [email protected]" <[email protected]>, "[email protected]" <[email protected]> > *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 > [email protected] > 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. > ____________________________________________________________ > _______________ > > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
