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

Greg,

There is zero labels of any sort in my proposal needed. Just basic netflow.

best
r.

On Nov 16, 2017 10:31, "Greg Mirsky" <gregimirsky@gmail.com> wrote:

> Hi Robert,
> you proposal is similar to idea of Synonymous Labels
> <https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-00>but I'm
> afraid it will not scale for SR-MPLS as it require that the whole SR MPLS
> stack must consist of such synonymous labels. And that will create state in
> the transient nodes in the data plane, IMHO of course.
>
> Regards,
> Greg
>
> On Thu, Nov 16, 2017 at 10:26 AM, Robert Raszuk <robert@raszuk.net> wrote:
>
>> 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-acc
>>> ounting-for-sr-paths<draft-hegde-spring-traffic-accounting-f
>>> or-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/dr
>>> aft-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
>>>
>>>
>