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

[Robert Raszuk <[e-mail]>]

Well I still do not think we need anything new on the wire for this but
apparently half folks here do not get it ;)

So for those who need it we can just insert 8 octets of vxlan between label
stack and packet and use vnid as path id.

thx
r.

On Nov 16, 2017 14:46, "Xuxiaohu" <[e-mail]> wrote:

> Just an idea occurring in my mind: Maybe it's worthwhile to consider how
> to address this business demand by using the unified SR approach (
> https://datatracker.ietf.org/meeting/100/materials/slides-
> 100-mpls-04-draft-xu-mpls-unified-source-routing-instruction-ietf100/).
> More specifically, use the source port of the UDP tunnel header to carry
> the path identity, just like the idea of using the unified SR approach to
> address the load-balancing issue associated with the MPLS-SR.
>
>
>
>
> ------------------------------
> 徐小虎 Xuxiaohu
> M：[phone]
> E：[e-mail]
> 产品与解决方案-网络战略与业务发展部
> Products & Solutions-Network Strategy & Business Development Dept
>
> *发件人： *Xuxiaohu
> *收件人： *Jeff Tantsura<[e-mail]>;Robert Raszuk<
> [e-mail]>
> *抄送： *draft-hegde-spring-traffic-accounting-for-sr-paths<draft-
> [e-mail]>;spring<
> [e-mail]>;mpls<[e-mail]>;Zafar Ali (zali)<[e-mail]>;Greg
> Mirsky<[e-mail]>
> *主题： *Re: [spring] [mpls] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
> *时间： *2017-11-16 14:25:32
>
>
> s/per flow/per path.
>
>
>
> ------------------------------
> 徐小虎 Xuxiaohu
> M：[phone]
> E：[e-mail]
> 产品与解决方案-网络战略与业务发展部
> Products & Solutions-Network Strategy & Business Development Dept
>
> *发件人： *Xuxiaohu
> *收件人： *Jeff Tantsura<[e-mail]>;Robert Raszuk<
> [e-mail]>
> *抄送： *draft-hegde-spring-traffic-accounting-for-sr-paths<draft-
> [e-mail]>;Greg Mirsky<
> [e-mail]>;spring<[e-mail]>;Zafar Ali (zali)<
> [e-mail]>;mpls<[e-mail]>
> *主题： *Re: [spring] [mpls] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
> *时间： *2017-11-16 11:21:46
>
>
> If so, why not directly use RSVP-TE if the per flow state is needed?
>
>
>
> ------------------------------
> 徐小虎 Xuxiaohu
> M：[phone]
> E：[e-mail]
> 产品与解决方案-网络战略与业务发展部
> Products & Solutions-Network Strategy & Business Development Dept
>
> *发件人： *Jeff Tantsura
> *收件人： *Robert Raszuk<[e-mail]>
> *抄送： *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<draft-
> [e-mail]>
> *主题： *Re: [spring] [mpls] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
> *时间： *2017-11-16 11:09:13
>
> Today, if you run RSVP-TE, you’d get (at least on high end platforms)
> counters per LSP.
>
> Having the same functionality with SR seems rather logical.
>
>
>
> Cheers,
>
> Jeff
>
>
>
> *From: *<[e-mail]> on behalf of Robert Raszuk <[e-mail]>
> *Date: *Thursday, November 16, 2017 at 10:50
> *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://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]> 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.
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>
> _______________________________________________ spring mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/spring
>
>