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" <[email protected]> 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：+86-13910161692 > E：[email protected] > 产品与解决方案-网络战略与业务发展部 > Products & Solutions-Network Strategy & Business Development Dept > > *发件人： *Xuxiaohu > *收件人： *Jeff Tantsura<[email protected]>;Robert Raszuk< > [email protected]> > *抄送： *draft-hegde-spring-traffic-accounting-for-sr-paths<draft- > [email protected]>;spring< > [email protected]>;mpls<[email protected]>;Zafar Ali (zali)<[email protected]>;Greg > Mirsky<[email protected]> > *主题： *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：+86-13910161692 > E：[email protected] > 产品与解决方案-网络战略与业务发展部 > Products & Solutions-Network Strategy & Business Development Dept > > *发件人： *Xuxiaohu > *收件人： *Jeff Tantsura<[email protected]>;Robert Raszuk< > [email protected]> > *抄送： *draft-hegde-spring-traffic-accounting-for-sr-paths<draft- > [email protected]>;Greg Mirsky< > [email protected]>;spring<[email protected]>;Zafar Ali (zali)< > [email protected]>;mpls<[email protected]> > *主题： *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：+86-13910161692 > E：[email protected] > 产品与解决方案-网络战略与业务发展部 > Products & Solutions-Network Strategy & Business Development Dept > > *发件人： *Jeff Tantsura > *收件人： *Robert Raszuk<[email protected]> > *抄送： *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<draft- > [email protected]> > *主题： *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: *<[email protected]> on behalf of Robert Raszuk <[email protected]> > *Date: *Thursday, November 16, 2017 at 10:50 > *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://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 <[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. > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ spring mailing list > [email protected] https://www.ietf.org/mailman/listinfo/spring > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
