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

[Stewart Bryant <[e-mail]>]

On 17/11/2017 03:00, Robert Raszuk wrote:
> Stewart,
>
> Is there any real vendor support and real production deployment of 
> rfc5586 ?

Yes. It is used in PWs and MPLS-TP.  But it is only looked at by the 
egress PE.

>
> Is there any data on the max label depth such channel may be hidden 
> under yet still visible to forwarding hardware ?

Not that I know, but it was designed to be used only by the receiving PE 
where the number of labels would  normally be 3 or less (normally no 
more than LSP, PW, GAL).

If you are really asking about how far into the packet can we put a path 
marker that is visible to a p-router, then asking how into the packet 
can IPFIX work might be an alternative way to gather the information you 
need.

- Stewart


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