> On 17 Nov 2017, at 11:26 am, Robert Raszuk <rob...@raszuk.net> wrote: > > Folks, > > LDP LSPs follow pure dst based IGP SPT. So for each ip dst the path packet > takes is well known. > Yes but ... it is subjected to ecmp and just as you may wish to tune the sr stack to avoid a hotspot, so you might wish to tune the EL to get a better traffic spread.
> What is there to record at each transit router hop other then what you > already have today from basic netflow counters ? The traffic source. Stewart > > Thx > R. > >> On Nov 17, 2017 04:18, "Mach Chen" <mach.c...@huawei.com> wrote: >> Hi Stewart, >> >> >> >> Indeed, the same idea can apply to both MPLS-SR and MPLS-LDP. For now, the >> requirements that I heard are from MPLS-SR. >> >> >> >> Best regards, >> >> Mach >> >> >> >> From: Stewart Bryant [mailto:stewart.bry...@gmail.com] >> Sent: Friday, November 17, 2017 10:45 AM >> To: Mach Chen; stephane.litkow...@orange.com; Robert Raszuk; Alexander >> Vainshtein >> Cc: mpls; spring; Clarence Filsfils; >> draft-hegde-spring-traffic-accounting-for-sr-paths; 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 >> >> >> >> >> I would like to ask a fundamental question here. >> >> Do we need transit counters for only MPLS-SR, or do we need it for MPLS-LDP >> as well? >> >> If we need it for both, then we need to have this discussion in a general >> MPLS context and not in an MPLS-SR specific context. >> >> At least some of the methods described here would work for both. >> >> Also WRT the proposal to do ingress collection, if nodal paths are used, >> that only tells us the approximate path, not the hotspot which I understand >> to be the original goal. >> >> - Stewart >> >> On 16/11/2017 14:46, Mach Chen wrote: >> >> Hi Stephane, >> >> >> >> If you want to do transit measurement, you have to pay some cost. The >> difference is how large the cost is, one, two or multiple labels. >> >> >> >> For E2E measurement, it could be much easier. A single label (could be local >> or global) is inserted immediately follow the last label of the SR path. >> Since there is only one label, the path label could be put into the stack at >> the beginning, no matter whether the measurement is enable or not. With >> this, it will not affect the entropy. >> >> >> >> Best regards, >> >> Mach >> >> >> >> From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of >> stephane.litkow...@orange.com >> Sent: Thursday, November 16, 2017 6:49 PM >> To: Robert Raszuk; Alexander Vainshtein >> Cc: mpls; spring; Clarence Filsfils; >> draft-hegde-spring-traffic-accounting-for-sr-paths; 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, >> >> >> >> Yes today we do not have any CLI command on any router to get paths >> statistics for LDP (I mean Ingress to Egress) as LDP is based on MP2P LSPs, >> so a transit node does not have the knowledge of the source. From an >> operational point of view, what we do today is that we collect netflow >> statistics on core routers, we project the label stack onto the routing with >> an external tool to get the Ingress to Egress LDP traffic including the >> mapping of the flows on the links. >> >> >> >> Now for RSVP, we do have such statistics as the LSP is P2P and has states on >> every node. >> >> >> >> Robert mentioned correctly that SR-TE (especially with MPLS dataplane) has >> limited TE features (we cannot mimic all what RSVP does in SRTE without >> adding too much complexity). >> >> >> >> Thus, is it a problem (transit node stats) worth to be solved ? If yes, >> where do we accept to put the complexity ? For a stats issue I would rather >> prefer to move the complexity to an external tool that can do correlations >> or whatever operations rather than getting it in the forwarding plane… >> >> IMO, that’s a “nice to have” problem to solve getting that we do not have >> this for LDP and we know the limitations of SR-TE MPLS. >> >> However, Ingress stats per SRTE LSP are for sure mandatory to get ! >> >> >> >> The main drawback I see with the proposed solution is that it mimics what >> Entropy label does with a solution which is similar and at the same time >> cannot replace entropy label as the provided entropy is far from being >> sufficient (this is not the goal I know, but I was looking for potential use >> case optimizations). So in a network running entropy label and this >> mechanism, a router will need to find the ELI/EL and hash, then find another >> special label to build the stats (maybe tomorrow there will be a third one >> to look at and a fourth one…). That starts to be a big overhead for the >> forwarding plane. >> >> >> >> Brgds, >> >> >> >> Stephane >> >> >> >> >> >> From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Robert Raszuk >> Sent: Thursday, November 16, 2017 16:23 >> To: Alexander Vainshtein >> Cc: spring; Clarence Filsfils; mpls; Michael Gorokhovsky; >> draft-ietf-spring-oam-usec...@ietf.org; >> draft-hegde-spring-traffic-accounting-for-sr-paths; Zafar Ali (zali) >> Subject: Re: [mpls] [spring] Special purpose labels in >> draft-hegde-spring-traffic-accounting-for-sr-paths >> >> >> >> Folks, >> >> >> >> This thread started and the requirements reported clearly stated that all >> what we need is the ability to account per path traffic on egress nodes. >> >> >> >> Now out of the sudden I see requirement popping up to be able to measure per >> path in transit nodes. >> >> >> >> Well you can do it today with SRv6 if your hardware allows or you can do it >> with RSVP-TE. >> >> >> >> SR-MPLS is replacing LDP and adds ability for limited TE. But SR-MPLS never >> intended to become connection oriented protocol nor architecture. >> >> >> >> So I recommend we take a step back here. Or if you like first go and fix >> basic MPLS LDP LSPs to allow per end to end path accounting in transit nodes >> then come back here to ask for the same in SR-MPLS. Not the other way around. >> >> >> >> Thx >> >> r. >> >> >> >> >> >> On Nov 16, 2017 16:12, "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 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 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 >> >> Cell: +972-549266302 >> >> 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, 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 >> >> >> >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu >> ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >> Thank you. >> >> >> >> >> _______________________________________________ >> 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
