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

This discussion is about a form of iOAM in SR-MPLS . To your point where in
mpls architecture in general there is provisioning for iOAM ?

And last time I check mpls is still used here and there ;)

Good news is that SRv6 is natively solving this by keeping the SID stacks
intact to the egress.

thx
r.

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

> Dear All,
> I cannot imagine that operators will agree to deploy network that lacks
> critical OAM tools to monitor performance and troubleshoot the network.
> True, some will brave the challenge and be the early adopters but even they
> will likely request that the OAM toolbox be sufficient to support their
> operational needs. I see that this work clearly describes the problem and
> why ability to quantify the flow behavior at internal nodes is important
> for efficient network operation. First let's discuss whether the case and
> requirement towards OAM is real and valid. Then we can continue to
> discussion of what measurement method to use.
>
> Regards,
> Greg
>
> On Thu, Nov 16, 2017 at 10:05 AM, 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-
>> 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/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
>
>