Stewart, Is there any real vendor support and real production deployment of rfc5586 ?
Is there any data on the max label depth such channel may be hidden under yet still visible to forwarding hardware ? Thx R. On Nov 17, 2017 03:49, "Stewart Bryant" <[email protected]> wrote: > Resenting with fewer names recipients > S > -------- Forwarded Message -------- > Subject: Re: [mpls] [spring] Special purpose labels in > draft-hegde-spring-traffic-accounting-for-sr-paths > Date: Fri, 17 Nov 2017 02:45:18 +0000 > From: Stewart Bryant <[email protected]> <[email protected]> > To: Mach Chen <[email protected]> <[email protected]>, > [email protected] <[email protected]> > <[email protected]>, Robert Raszuk <[email protected]> > <[email protected]>, Alexander Vainshtein <Alexander.Vainshtein@ecitele. > com> <[email protected]> > CC: mpls <[email protected]> <[email protected]>, spring <[email protected]> > <[email protected]>, Clarence Filsfils <[email protected]> > <[email protected]>, draft-hegde-spring-traffic-accounting-for-sr-paths > <[email protected]> > <[email protected]>, Michael > Gorokhovsky <[email protected]> > <[email protected]>, [email protected] > <[email protected]> > <[email protected]>, Zafar Ali (zali) > <[email protected]> <[email protected]> > > > 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:[email protected] <[email protected]>] *On > Behalf Of *[email protected] > *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; [email protected]; 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:[email protected] <[email protected]>] *On > Behalf Of *Robert Raszuk > *Sent:* Thursday, November 16, 2017 16:23 > *To:* Alexander Vainshtein > *Cc:* spring; Clarence Filsfils; mpls; Michael Gorokhovsky; > [email protected]; > 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" < > [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://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/?include_text=1> > 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://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00> > 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, 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 > > > > _________________________________________________________________________________________________________________________ > > > > 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 [email protected]https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > mpls mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/mpls > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
