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

[Shraddha Hegde <[e-mail]>]

Robert,

If we have to get the N:1 mapping then we need to count all the N flows on a transit router.
N is really huge number and it is really not practical to count every flow on a transit router.

There have also been comments about creating state in the network.
The proposed solution in the draft does not create per-path forwarding state and does not create any per-path control state in
The network. It's only the counters that are getting created per-path which is most essential for OAM.

Rgds
Shraddha

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 10:51 AM
To: Jeff Tantsura <[e-mail]>
Cc: Xuxiaohu <[e-mail]>; Greg Mirsky <[e-mail]>; spring <[e-mail]>; mpls <[e-mail]>; Zafar Ali (zali) <[e-mail]>; draft-hegde-spring-traffic-accounting-for-sr-paths <[e-mail]>
Subject: Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

As explained it is not needed to get all information required per path.

Yes you may have N:1 mapping of flows to path so what is the problem ?

thx
r.

On Nov 16, 2017 10:47, "Jeff Tantsura" <[e-mail]> wrote:

> Robert,
>
>
>
> HW counters are rather precious resources, but that’s beside the point.
>
> An architecture is not an immutable object, on contrary, a very import 
> property of a good architecture is flexibility and agility, ability to 
> adapt when business need arises.
>
>
>
> Keeping semantics aside – what’s needed, is a metadata (here encoded 
> as a
> label) that uniquely identifies a path, where FIB lookup would yield 
> an “counter hit”, potentially counter creation if the packet is the 
> first packet in the flow. Value of the label would be hashed in the 
> counter ID that is unique and could be resolved by a management layer 
> into accounting record.
>
>
>
> Cheers,
>
> Jeff
>
>
>
> *From: *spring <[e-mail]> on behalf of Robert Raszuk < 
> [e-mail]>
> *Date: *Thursday, November 16, 2017 at 10:26
> *To: *Xuxiaohu <[e-mail]>
> *Cc: *Greg Mirsky <[e-mail]>, spring <[e-mail]>, 
> mpls <[e-mail]>, "Zafar Ali (zali)" <[e-mail]>, 
> draft-hegde-spring-traffic-accounting-for-sr-paths < 
> [e-mail]>
> *Subject: *Re: [spring] [mpls] Special purpose labels in 
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
> The architecture is fine. This is accounting state not forwarding state.
>
>
>
> But no new labels are needed.
>
>
>
> See on ingress you apply sr label stack based on some match of the 
> fields of actual packet. So all you need is to do accounting on the 
> very same fields of the packets on egress and you have path accounting 
> required for you.
>
>
>
> Besides this method also seamlessly works over non sr capable SFs as 
> long as such SFs do not mess with the packet content of those tuples.
>
>
>
> cheers,
>
> r.
>
>
>
> On Nov 16, 2017 10:05, "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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_ht
> ml_&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA
> 7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=D8UZYa9EWpns6URXJvtBqZ5gX2lDpl7l5
> ZTaXTlEJGw&s=xB3z335gatRnndYZzanLmzNqezYOznxweYSwcOKuMMo&e=
> 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