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

[Martin Horneffer <[e-mail]>]

Hi Stewart,

a quick comment on this, from an operator's point of view: Yes, we do 
need the same measurements for LDP as well as for SR.

The exact kind of counter may be debatable. From what we have now, 
per-FEC counters (per-SID for SR) on every node seem like the best 
practical and existing solution.

Best regards, Martin


Am 17.11.17 um 03:45 schrieb Stewart Bryant:
>
> 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]
>> *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]] *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,
>>     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
>>
>> _________________________________________________________________________________________________________________________
>> 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]
>> https://www.ietf.org/mailman/listinfo/mpls
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls