Zafar I don’t think you can assert that fails to comply with the SR arch. There is nothing they are doing that cannot be captured in Netflix/IPFIX and SR needs to work with IPFIX.
Stewart > On 16 Nov 2017, at 2:23 am, Zafar Ali (zali) <z...@cisco.com> wrote: > > 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 <spring-boun...@ietf.org> on behalf of Greg Mirsky > <gregimir...@gmail.com> > Date: Wednesday, November 15, 2017 at 11:10 AM > To: "draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org" > <draft-hegde-spring-traffic-accounting-for-sr-pa...@ietf.org>, > "m...@ietf.org" <m...@ietf.org>, "spring@ietf.org" <spring@ietf.org> > 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 > _______________________________________________ > mpls mailing list > m...@ietf.org > https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
