Re: [mpls] [spring] 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" <jefftant.ietf@gmail.com> 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 <spring-bounces@ietf.org> on behalf of Robert Raszuk <
> robert@raszuk.net>
> *Date: *Thursday, November 16, 2017 at 10:26
> *To: *Xuxiaohu <xuxiaohu@huawei.com>
> *Cc: *Greg Mirsky <gregimirsky@gmail.com>, spring <spring@ietf.org>, mpls
> <mpls@ietf.org>, "Zafar Ali (zali)" <zali@cisco.com>,
> draft-hegde-spring-traffic-accounting-for-sr-paths <
> draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org>
> *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" <xuxiaohu@huawei.com> 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：xuxiaohu@huawei.com
> 产品与解决方案-网络战略与业务发展部
> Products & Solutions-Network Strategy & Business Development Dept
>
> *发件人：* Zafar Ali (zali)
>
> *收件人：* Greg Mirsky<gregimirsky@gmail.com>;draft-hegde-spring-traffic-
> accounting-for-sr-paths<draft-hegde-spring-traffic-
> accounting-for-sr-paths@ietf.org>;mpls<mpls@ietf.org>;spring<
> spring@ietf.org>
>
> *主**题**：* 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 <spring-bounces@ietf.org> on behalf of Greg Mirsky <
> gregimirsky@gmail.com>
> *Date: *Wednesday, November 15, 2017 at 11:10 AM
> *To: *"draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org" <
> draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org>, "
> mpls@ietf.org" <mpls@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
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
> _______________________________________________ spring mailing list
> spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
>