Re: [spring] [mpls] Fwd: Re: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

[Robert Raszuk <[e-mail]>]

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" <[e-mail]> 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 <[e-mail]> <[e-mail]>
> To: Mach Chen <[e-mail]> <[e-mail]>,
> [e-mail] <[e-mail]>
> <[e-mail]>, Robert Raszuk <[e-mail]>
> <[e-mail]>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.
> com> <[e-mail]>
> CC: mpls <[e-mail]> <[e-mail]>, spring <[e-mail]>
> <[e-mail]>, Clarence Filsfils <[e-mail]>
> <[e-mail]>, draft-hegde-spring-traffic-accounting-for-sr-paths
> <[e-mail]>
> <[e-mail]>, Michael
> Gorokhovsky <[e-mail]>
> <[e-mail]>, [e-mail]
> <[e-mail]>
> <[e-mail]>, Zafar Ali (zali)
> <[e-mail]> <[e-mail]>
>
>
> 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:[e-mail] <[e-mail]>] *On
> Behalf Of *[e-mail]
> *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; [e-mail]; 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:[e-mail] <[e-mail]>] *On
> Behalf Of *Robert Raszuk
> *Sent:* Thursday, November 16, 2017 16:23
> *To:* Alexander Vainshtein
> *Cc:* spring; Clarence Filsfils; mpls; Michael Gorokhovsky;
> [e-mail]; 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" <
> [e-mail]> 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: [phone] <+972%203-926-6302>
>
> Cell:      [phone] <+972%2054-926-6302>
>
> Email:   [e-mail]
>
>
>
> *From:* mpls [mailto:[e-mail]] *On Behalf Of *Greg Mirsky
> *Sent:* Thursday, November 16, 2017 4:28 AM
> *To:* Xuxiaohu <[e-mail]>
> *Cc:* draft-hegde-spring-traffic-accounting-for-sr-paths <
> [e-mail]>; spring <
> [e-mail]>; Zafar Ali (zali) <[e-mail]>; mpls <[e-mail]>
> *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 <[e-mail]> 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：[phone]
> E：[e-mail]
> 产品与解决方案-网络战略与业务发展部
> Products & Solutions-Network Strategy & Business Development Dept
>
> *发件人：* Zafar Ali (zali)
>
> *收件人：* Greg Mirsky<[e-mail]>;draft-hegde-spring-traffic-
> accounting-for-sr-paths<draft-hegde-spring-traffic-
> [e-mail]>;mpls<[e-mail]>;spring<
> [e-mail]>
>
> *主**题：* 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 <[e-mail]> on behalf of Greg Mirsky <
> [e-mail]>
> *Date: *Wednesday, November 15, 2017 at 11:10 AM
> *To: *"[e-mail]" <
> [e-mail]>, "
> [e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> *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
> [e-mail]
> 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 [e-mail]://www.ietf.org/mailman/listinfo/mpls
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>
>