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: [email protected] [mailto:[email protected]] On Behalf Of Robert Raszuk Sent: Thursday, November 16, 2017 10:51 AM To: Jeff Tantsura <[email protected]> Cc: Xuxiaohu <[email protected]>; Greg Mirsky <[email protected]>; spring <[email protected]>; mpls <[email protected]>; Zafar Ali (zali) <[email protected]>; draft-hegde-spring-traffic-accounting-for-sr-paths <[email protected]> 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" <[email protected]> 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 <[email protected]> on behalf of Robert Raszuk < > [email protected]> > *Date: *Thursday, November 16, 2017 at 10:26 > *To: *Xuxiaohu <[email protected]> > *Cc: *Greg Mirsky <[email protected]>, spring <[email protected]>, > mpls <[email protected]>, "Zafar Ali (zali)" <[email protected]>, > draft-hegde-spring-traffic-accounting-for-sr-paths < > [email protected]> > *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" <[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://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 <[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 _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
