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

From: Greg Mirsky <[email-masked]>
Date: Thu, 16 Nov 2017 00:09:38 +0800

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

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 15 Nov 2017 18:23:44 +0000

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-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Wednesday, November 15, 2017 at 11:10 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
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

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 16 Nov 2017 08:15:30 +0800

Zafar

I don’t think you can assert that fails to comply with the SR arch. There is nothing they are doing that cannot be captured in Netflix/IPFIX and SR needs to work with IPFIX.

Stewart

> On 16 Nov 2017, at 2:23 am, Zafar Ali (zali) <[email-masked]> wrote:
> 
> Hi,
>  
> 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-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 16 Nov 2017 02:05:37 +0000

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<tel:+86-13910161692>
E：[email-masked]<mailto:[email-masked]>
产品与解决方案-网络战略与业务发展部
Products & Solutions-Network Strategy & Business Development Dept

发件人： Zafar Ali (zali)
收件人： Greg Mirsky<[email-masked]<mailto:[email-masked]>>;draft-hegde-spring-traffic-accounting-for-sr-paths<[email-masked]<mailto:[email-masked]>>;mpls<[email-masked]<mailto:[email-masked]>>;spring<[email-masked]<mailto:[email-masked]>>
主题： Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 02:24:10

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Nov 2017 03:26:31 +0100

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-masked]> 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-masked]
> 产品与解决方案-网络战略与业务发展部
> *发件人： *Zafar Ali (zali)
> *收件人： *Greg Mirsky<[email-masked]>;draft-hegde-spring-traffic-
> accounting-for-sr-paths<draft-hegde-spring-traffic-
> [email-masked]>;mpls<[email-masked]>;spring<
> [email-masked]>
> *主题： *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-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> *Date: *Wednesday, November 15, 2017 at 11:10 AM
> *To: *"[email-masked]" <
> [email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *[spring] Special purpose labels in draft-hegde-spring-traffic-
> accounting-for-sr-paths
>
>
>
> Hi Shraddha,
>
>    - 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
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 16 Nov 2017 10:31:23 +0800

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 <[email-masked]> 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
>>
>>
>>
>>
>> *收件人： *Greg Mirsky<[email-masked]>;draft-hegde-spring-traffic-acc
>> ounting-for-sr-paths<draft-hegde-spring-traffic-accounting-
>> [email-masked]>;mpls<[email-masked]>;spring<[email-masked]>
>> abstract of SR Architecture document https://tools.ietf.org/html/dr
>> aft-ietf-spring-segment-routing-13, which states:
>>
>> *Subject: *[spring] Special purpose labels in

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Nov 2017 03:34:06 +0100

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" <[email-masked]> wrote:

>>> ounting-for-sr-paths<draft-hegde-spring-traffic-accounting-f
>>> [email-masked]>;mpls<[email-masked]>;spring<[email-masked]>
>>> 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
>>>    - 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

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 16 Nov 2017 10:27:41 +0800

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

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 16 Nov 2017 10:36:49 +0800

Hi Robert,
consider number of ACL filters one has to configure just in case the
particular SR flow comes along. Yes, that works but there are other costs
to pay. The proposed approach has some very attractive, IMHO, qualities.

Regards,
Greg

On Thu, Nov 16, 2017 at 10:34 AM, Robert Raszuk <[email-masked]> wrote:

>>> 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.
>>>
>>>> *收件人： *Greg Mirsky<[email-masked]>;
>>>> draft-hegde-spring-traffic-accounting-for-sr-paths<draft-heg
>>>> [email-masked]>;mpls<[email-masked]
>>>> >;spring<[email-masked]>

---

From: ShaoWen Ma <[email-masked]>
Date: Thu, 16 Nov 2017 10:43:07 +0800

Hi Robert and all,

  SPRING try to get rid of per flow forwarding status. that's the design
principal for whole network.
  and Shraddha just want to add back per flow Traffic statistics as
request, which will only applied to interested flow.

  if you check the label stack for traffic statistics, that might be get
some processing trouble to handle:
{300|200|100} with another label stack such as {400|300|200|100} on the
same nodes.

  so path id do have it's value if customer want to check specific flow, by
not impact all packet process on the transit router.

Best Regards
Shaowen Ma

On Thu, Nov 16, 2017 at 10:26 AM, Robert Raszuk <[email-masked]> wrote:

> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Nov 2017 03:43:24 +0100

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.

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 16 Nov 2017 10:47:13 +0800

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-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Thursday, November 16, 2017 at 10:26
To: Xuxiaohu <[email-masked]>
Cc: Greg Mirsky <[email-masked]>, spring <[email-masked]>, mpls <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>, draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>
Subject: Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

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.

Best regards,
Xiaohu 

徐小虎 Xuxiaohu
M：+86-13910161692 
E：[email-masked]
产品与解决方案-网络战略与业务发展部

发件人： Zafar Ali (zali)

收件人： Greg Mirsky<[email-masked]>;draft-hegde-spring-traffic-accounting-for-sr-paths<[email-masked]>;mpls<[email-masked]>;spring<[email-masked]>

时间： 2017-11-16 02:24:10

Hi, 

Thanks

Regards … Zafar 

Hi Shraddha, 

·  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

_______________________________________________ spring mailing list [email-masked] https://www.ietf.org/mailman/listinfo/spring

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Nov 2017 03:47:48 +0100

I am not suggesting checking any label stack.

All info comes from packet behind label stack. Just like it is read on
ingress when/before you apply stack the same can be done on egress where
there is no more stack at all any more.

thx
r.

On Nov 16, 2017 10:43, "ShaoWen Ma" <[email-masked]> wrote:

Hi Robert and all,

Best Regards
Shaowen Ma

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Nov 2017 03:50:36 +0100

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-masked]> wrote:

> 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-masked]> on behalf of Robert Raszuk <
> [email-masked]>
> *Date: *Thursday, November 16, 2017 at 10:26
> *To: *Xuxiaohu <[email-masked]>
> *Cc: *Greg Mirsky <[email-masked]>, spring <[email-masked]>, mpls
> <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>,
> draft-hegde-spring-traffic-accounting-for-sr-paths <
> [email-masked]>
> *Subject: *Re: [spring] [mpls] Special purpose labels in
> *发件人：* Zafar Ali (zali)
> *收件人：* Greg Mirsky<[email-masked]>;draft-hegde-spring-traffic-
> *主**题**：* Re: [mpls] [spring] Special purpose labels in
> *时间：* 2017-11-16 02:24:10
>
>
>
> Hi,
>
>
>
> ·  Have you thought of using not one special purpose label for both SR
> ·  And how you envision to collect the counters along the path? Of
> ·  And the last, have you considered ability to flush counters per flow.
> _______________________________________________ spring mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/spring
>

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 16 Nov 2017 02:54:40 +0000

I fully agree with you that OAM tools are important.

I just felt that the approach as proposed in the draft would enconter the same terrible issues as those associated with the MPLS-SR entropy label usage due to RLD and MSD hardware limitations.

Best regards,
Xiaohu

发件人： Greg Mirsky
收件人： Xuxiaohu<[email-masked]<mailto:[email-masked]>>
抄送： Zafar Ali (zali)<[email-masked]<mailto:[email-masked]>>;draft-hegde-spring-traffic-accounting-for-sr-paths<[email-masked]<mailto:[email-masked]>>;mpls<[email-masked]<mailto:[email-masked]>>;spring<[email-masked]<mailto:[email-masked]>>
主题： Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 10:27:55

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 <[email-masked]<mailto:[email-masked]>> 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

发件人： Zafar Ali (zali)

Hi,

Thanks

Regards … Zafar

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 15, 2017 at 11:10 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Shraddha,

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 16 Nov 2017 11:08:58 +0800

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-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Thursday, November 16, 2017 at 10:50
To: Jeff Tantsura <[email-masked]>
Cc: Xuxiaohu <[email-masked]>, Greg Mirsky <[email-masked]>, spring <[email-masked]>, mpls <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>, draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>
Subject: Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

thx

r.

Robert,

Cheers,

Jeff

cheers,

r.

Best regards,
Xiaohu 

徐小虎 Xuxiaohu
M：+86-13910161692 
E：[email-masked]
产品与解决方案-网络战略与业务发展部

发件人： Zafar Ali (zali)

时间： 2017-11-16 02:24:10

Hi, 

Thanks

Regards … Zafar 

Hi Shraddha, 

Regards,

Greg

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 16 Nov 2017 03:11:19 +0000

Robert,

If we have to get the N:1 mapping then we need to count all the N flows on a transit router.
N is really huge number and it is really not practical to count every flow on a transit router.

There have also been comments about creating state in the network.
The proposed solution in the draft does not create per-path forwarding state and does not create any per-path control state in
The network. It's only the counters that are getting created per-path which is most essential for OAM.

Rgds
Shraddha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 10:51 AM
To: Jeff Tantsura <[email-masked]>
Cc: Xuxiaohu <[email-masked]>; Greg Mirsky <[email-masked]>; spring <[email-masked]>; mpls <[email-masked]>; Zafar Ali (zali) <[email-masked]>; draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>
Subject: Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

thx
r.

On Nov 16, 2017 10:47, "Jeff Tantsura" <[email-masked]> wrote:

> 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
>
>
>
> *Cc: *Greg Mirsky <[email-masked]>, spring <[email-masked]>, 
> mpls <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>, 
> 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.
>
>
>
> abstract of SR Architecture document 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_ht
> ml_&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA
> 7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=D8UZYa9EWpns6URXJvtBqZ5gX2lDpl7l5
> ZTaXTlEJGw&s=xB3z335gatRnndYZzanLmzNqezYOznxweYSwcOKuMMo&e=
> makes controller job much harder and error prune. In summary, I find 
> the procedure very complex and unscalable.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
>
>
> draft-hegde-spring-traffic- accounting-for-sr-paths
>
>
>
> Hi Shraddha,
>
> 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.
>
> 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.
>
> 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

---

From: David Allan I <[email-masked]>
Date: Thu, 16 Nov 2017 03:11:36 +0000

So your point would be that this does not require a special label to achieve this. Nor do we need a redesign of stack processing at every node in the network to enable this functionality.

Cheers
Dave

From: spring [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Thursday, November 16, 2017 11:09 AM
To: Robert Raszuk <[email-masked]>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>; spring <[email-masked]>; Greg Mirsky <[email-masked]>; mpls <[email-masked]>; Xuxiaohu <[email-masked]>; Zafar Ali (zali) <[email-masked]>
Subject: Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Cheers,
Jeff

From: <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 16, 2017 at 10:50
To: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Cc: Xuxiaohu <[email-masked]<mailto:[email-masked]>>, Greg Mirsky <[email-masked]<mailto:[email-masked]>>, spring <[email-masked]<mailto:[email-masked]>>, mpls <[email-masked]<mailto:[email-masked]>>, "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

thx
r.

On Nov 16, 2017 10:47, "Jeff Tantsura" <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Cheers,
Jeff

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 16, 2017 at 10:26
To: Xuxiaohu <[email-masked]<mailto:[email-masked]>>
Cc: Greg Mirsky <[email-masked]<mailto:[email-masked]>>, spring <[email-masked]<mailto:[email-masked]>>, mpls <[email-masked]<mailto:[email-masked]>>, "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

cheers,
r.

On Nov 16, 2017 10:05, "Xuxiaohu" <[email-masked]<mailto:[email-masked]>> 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

Hi,

Thanks

Regards … Zafar

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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________ spring mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/spring

---

From: Mach Chen <[email-masked]>
Date: Thu, 16 Nov 2017 03:15:44 +0000

I totally agree with Jeff here.

Remember that several WGs in IETF are working on performance measurement, and even there is a dedicated PM WG (IPPM).

I am not sure SR is an exception.

Best regards,
Mach

From: spring [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Thursday, November 16, 2017 11:09 AM
To: Robert Raszuk
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths; spring; Greg Mirsky; mpls; Xuxiaohu; Zafar Ali (zali)
Subject: Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Cheers,
Jeff

thx
r.

Cheers,
Jeff

cheers,
r.

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 16 Nov 2017 03:21:14 +0000

If so, why not directly use RSVP-TE if the per flow state is needed?

发件人： Jeff Tantsura
收件人： Robert Raszuk<[email-masked]<mailto:[email-masked]>>
抄送： Xuxiaohu<[email-masked]<mailto:[email-masked]>>;Greg Mirsky<[email-masked]<mailto:[email-masked]>>;spring<[email-masked]<mailto:[email-masked]>>;mpls<[email-masked]<mailto:[email-masked]>>;Zafar Ali (zali)<[email-masked]<mailto:[email-masked]>>;draft-hegde-spring-traffic-accounting-for-sr-paths<[email-masked]<mailto:[email-masked]>>
主题： Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 11:09:13

Cheers,
Jeff

thx
r.

Cheers,
Jeff

cheers,
r.

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Mach Chen <[email-masked]>
Date: Thu, 16 Nov 2017 03:28:41 +0000

Hi Zafar,

Given that SR supports SID Binding, states only maintained at ingress is not very true.

Best regards,
Mach

From: mpls [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Thursday, November 16, 2017 2:24 AM
To: Greg Mirsky; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 16 Nov 2017 03:35:07 +0000

I agree with some of the opinions expressed here wrt transit LSR not completely immune of statelessness;
lightweight (counters only) or otherwise.

Another point that Greg made is important to underline.

If such radioactive flows generate counters at LSRs, there needs to be a way to clear them,
If intent of the scheme is to use it for spotlighting only.

Thanks,
Himanshu

From: spring <[email-masked]> on behalf of Mach Chen <[email-masked]>
Date: Thursday, November 16, 2017 at 11:29 AM
To: 'Zafar ' <[email-masked]>, Greg Mirsky <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Zafar,

Best regards,
Mach

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 16 Nov 2017 03:52:26 +0000

The beauty of MPLS-SR is less states are required. To keep it as beautiful as possible, it'd better for us to overcome the impulsion of adding more and more complicated functions.

Best regards,
Xiaohu

发件人： Mach Chen
收件人： Zafar Ali (zali)<[email-masked]<mailto:[email-masked]>>;Greg Mirsky<[email-masked]<mailto:[email-masked]>>;draft-hegde-spring-traffic-accounting-for-sr-paths<[email-masked]<mailto:[email-masked]>>;mpls<[email-masked]<mailto:[email-masked]>>;spring<[email-masked]<mailto:[email-masked]>>
主题： Re: [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 11:29:12

Hi Zafar,

Best regards,
Mach

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Mach Chen <[email-masked]>
Date: Thu, 16 Nov 2017 03:56:21 +0000

Yes, counting at transit LSR is normally treated an on-demand function, means you could turn it on/off when needed.

Best regards,
Mach

From: Shah, Himanshu [mailto:[email-masked]]
Sent: Thursday, November 16, 2017 11:35 AM
To: Mach Chen; Zafar Ali (zali); Greg Mirsky; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Thanks,
Himanshu

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Mach Chen <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 16, 2017 at 11:29 AM
To: 'Zafar ' <[email-masked]<mailto:[email-masked]>>, Greg Mirsky <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Zafar,

Best regards,
Mach

From: mpls [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Thursday, November 16, 2017 2:24 AM
To: Greg Mirsky; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Mach Chen <[email-masked]>
Date: Thu, 16 Nov 2017 04:01:52 +0000

IMHO, OAM is a fundamental function that is for an operator to running their SR network.

I hope we’d better not repeat the philosophy debate here. We should focus on the specific use case/requirement/technologies.

Best regards,
Mach

From: Xuxiaohu
Sent: Thursday, November 16, 2017 11:52 AM
To: Mach Chen; Zafar Ali (zali); Greg Mirsky; draft-hegde-spring-traffic-accounting-for-sr-paths; mpls; spring
Subject: RE: [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Best regards,
Xiaohu

Hi Zafar,

Best regards,
Mach

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: "Chengli (IP Technology Research)" <[email-masked]>
Date: Thu, 16 Nov 2017 04:03:09 +0000

Shraddha,

I agree with your point of counters are needed for per flow fully, if we need to measure per flow in SR. 

For measuring performance, some states are needed, and it is good to not create new forwarding states or control states.  It is the same for both solutions.

But I still think 3 or 4(If the reserved label (0-15) can not be assigned ) labels are too many for label stack since the limit of MSD.

For 2 or 3 labels  solution, the limit will become global segments for identifying path.

Regards
Cheng

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Shraddha Hegde
Sent: Thursday, November 16, 2017 11:11 AM
To: Robert Raszuk <[email-masked]>; Jeff Tantsura <[email-masked]>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>; spring <[email-masked]>; Greg Mirsky <[email-masked]>; mpls <[email-masked]>; Xuxiaohu <[email-masked]>; Zafar Ali (zali) <[email-masked]>
Subject: Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Robert,

There have also been comments about creating state in the network.
The proposed solution in the draft does not create per-path forwarding state and does not create any per-path control state in The network. It's only the counters that are getting created per-path which is most essential for OAM.

Rgds
Shraddha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 10:51 AM
To: Jeff Tantsura <[email-masked]>
Cc: Xuxiaohu <[email-masked]>; Greg Mirsky <[email-masked]>; spring <[email-masked]>; mpls <[email-masked]>; Zafar Ali (zali) <[email-masked]>; draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>
Subject: Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

thx
r.

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 16 Nov 2017 12:36:37 +0800

ATM would give us event better visibility ;-)

I’m not advocating for a particular solution, nor expressing my liking of anything proposed, just stating that there a business need, especially for those, migrating from RSVP-TE to SR.

There’s big difference between per LSP (not per flow) networking state and accounting in a system…

Perhaps obvious – the value of an architecture is not in its abstract beauty (which I fully appreciate) but in its usability and value created.

Cheers,

Jeff

From: Xuxiaohu <[email-masked]>
Date: Thursday, November 16, 2017 at 11:21
To: Jeff Tantsura <[email-masked]>, Robert Raszuk <[email-masked]>
Cc: Greg Mirsky <[email-masked]>, spring <[email-masked]>, mpls <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>, draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>
Subject: RE: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

徐小虎 Xuxiaohu
M：+86-13910161692 
E：[email-masked]
产品与解决方案-网络战略与业务发展部

发件人： Jeff Tantsura

收件人： Robert Raszuk<[email-masked]>

抄送： Xuxiaohu<[email-masked]>;Greg Mirsky<[email-masked]>;spring<[email-masked]>;mpls<[email-masked]>;Zafar Ali (zali)<[email-masked]>;draft-hegde-spring-traffic-accounting-for-sr-paths<[email-masked]>

时间： 2017-11-16 11:09:13

Cheers,

Jeff

thx

r.

Robert,

Cheers,

Jeff

cheers,

r.

Best regards,
Xiaohu 

徐小虎 Xuxiaohu
M：+86-13910161692 
E：[email-masked]
产品与解决方案-网络战略与业务发展部

发件人： Zafar Ali (zali)

时间： 2017-11-16 02:24:10

Hi, 

Thanks

Regards … Zafar 

Hi Shraddha, 

Regards,

Greg

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 16 Nov 2017 06:25:05 +0000

s/per flow/per path.

发件人： Xuxiaohu
收件人： Jeff Tantsura<[email-masked]<mailto:[email-masked]>>;Robert Raszuk<[email-masked]<mailto:[email-masked]>>
抄送： draft-hegde-spring-traffic-accounting-for-sr-paths<[email-masked]<mailto:[email-masked]>>;Greg Mirsky<[email-masked]<mailto:[email-masked]>>;spring<[email-masked]<mailto:[email-masked]>>;Zafar Ali (zali)<[email-masked]<mailto:[email-masked]>>;mpls<[email-masked]<mailto:[email-masked]>>
主题： Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths
时间： 2017-11-16 11:21:46

发件人： Jeff Tantsura

Cheers,
Jeff

thx
r.

Cheers,
Jeff

cheers,
r.

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 16 Nov 2017 06:46:32 +0000

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
收件人： Jeff Tantsura<[email-masked]<mailto:[email-masked]>>;Robert Raszuk<[email-masked]<mailto:[email-masked]>>
抄送： draft-hegde-spring-traffic-accounting-for-sr-paths<[email-masked]<mailto:[email-masked]>>;spring<[email-masked]<mailto:[email-masked]>>;mpls<[email-masked]<mailto:[email-masked]>>;Zafar Ali (zali)<[email-masked]<mailto:[email-masked]>>;Greg Mirsky<[email-masked]<mailto:[email-masked]>>
主题： 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

发件人： Jeff Tantsura

Cheers,
Jeff

thx
r.

Cheers,
Jeff

cheers,
r.

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Nov 2017 07:58:47 +0100

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-masked]> 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
> *收件人： *Jeff Tantsura<[email-masked]>;Robert Raszuk<
> [email-masked]>
> *抄送： *draft-hegde-spring-traffic-accounting-for-sr-paths<draft-
> [email-masked]>;spring<
> [email-masked]>;mpls<[email-masked]>;Zafar Ali (zali)<[email-masked]>;Greg
> Mirsky<[email-masked]>
> *主题： *Re: [spring] [mpls] Special purpose labels in
> *时间： *2017-11-16 14:25:32
>
>
> s/per flow/per path.
>
>
>
> *发件人： *Xuxiaohu
> *收件人： *Jeff Tantsura<[email-masked]>;Robert Raszuk<
> [email-masked]>
> *抄送： *draft-hegde-spring-traffic-accounting-for-sr-paths<draft-
> [email-masked]>;Greg Mirsky<
> [email-masked]>;spring<[email-masked]>;Zafar Ali (zali)<
> [email-masked]>;mpls<[email-masked]>
> *主题： *Re: [spring] [mpls] Special purpose labels in
> *时间： *2017-11-16 11:21:46
>
>
> *发件人： *Jeff Tantsura
> *收件人： *Robert Raszuk<[email-masked]>
> *抄送： *Xuxiaohu<[email-masked]>;Greg Mirsky<[email-masked]>;
> spring<[email-masked]>;mpls<[email-masked]>;Zafar Ali (zali)<
> [email-masked]>;draft-hegde-spring-traffic-accounting-for-sr-paths<draft-
> [email-masked]>
> *主题： *Re: [spring] [mpls] Special purpose labels in
> *时间： *2017-11-16 11:09:13
>
> *From: *<[email-masked]> on behalf of Robert Raszuk <[email-masked]>
> *Date: *Thursday, November 16, 2017 at 10:50
> *To: *Jeff Tantsura <[email-masked]>
> *Cc: *Xuxiaohu <[email-masked]>, Greg Mirsky <[email-masked]>,
> spring <[email-masked]>, mpls <[email-masked]>, "Zafar Ali (zali)" <
> [email-masked]>, draft-hegde-spring-traffic-accounting-for-sr-paths <

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Nov 2017 08:11:59 +0000

Greg,
I concur with your position: let’s first  of all agree that ability to measure traffic carried by an SR-TE LSP in a specific transit node is a require OAM function for SR.

I have looked up the SR OAM Use Cases<https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/?include_text=1> draft, and I did not find any relevant use cases there.
The only time measurements are mentioned is a reference to an expired implementation report<https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00> draft discussing delay measurements.  Since delay measurements are in any case based on synthetic traffic, and are always end-to-end (one-way or two-way), this reference is not relevant, IMHO, for this discussion.

I have added the authors of the SR OAM Use Cases draft to tis thread.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: mpls [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Thursday, November 16, 2017 4:28 AM
To: Xuxiaohu <[email-masked]>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>; spring <[email-masked]>; Zafar Ali (zali) <[email-masked]>; mpls <[email-masked]>
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Nov 2017 09:23:04 +0100

Folks,

This thread started and the requirements reported clearly stated that all
what we need is the ability to account per path traffic on egress nodes.

Now out of the sudden I see requirement popping up to be able to measure
per path in transit nodes.

Well you can do it today with SRv6 if your hardware allows or you can do it
with RSVP-TE.

SR-MPLS is replacing LDP and adds ability for limited TE. But SR-MPLS never
intended to become connection oriented protocol nor architecture.

So I recommend we take a step back here. Or if you like first go and fix
basic MPLS LDP LSPs to allow per end to end path accounting in transit
nodes then come back here to ask for the same in SR-MPLS. Not the other way
around.

Thx
r.

On Nov 16, 2017 16:12, "Alexander Vainshtein" <
[email-masked]> wrote:

Greg,

I concur with your position: let’s first  of all agree that ability to
measure traffic carried by an SR-TE LSP in a specific transit node is a
require OAM function for SR.

I have looked up the SR OAM Use Cases
<https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/?include_text=1>
draft, and I did not find any relevant use cases there.

The only time measurements are mentioned is a reference to an expired
implementation report
<https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00>
draft discussing delay measurements.  Since delay measurements are in any
case based on synthetic traffic, and are always end-to-end (one-way or
two-way), this reference is not relevant, IMHO, for this discussion.

Regards,

Sasha

Office: +972-39266302 <+972%203-926-6302>

Cell:      +972-549266302 <+972%2054-926-6302>

*From:* mpls [mailto:[email-masked]] *On Behalf Of *Greg Mirsky
*Sent:* Thursday, November 16, 2017 4:28 AM
*To:* Xuxiaohu <[email-masked]>
*Cc:* draft-hegde-spring-traffic-accounting-for-sr-paths <
[email-masked]>; spring <
[email-masked]>; Zafar Ali (zali) <[email-masked]>; mpls <[email-masked]>
*Subject:* Re: [mpls] [spring] Special purpose labels in
draft-hegde-spring-traffic-accounting-for-sr-paths

Dear All,

Regards,

Greg

Best regards,
Xiaohu

徐小虎 Xuxiaohu
M：+86-13910161692
E：[email-masked]
产品与解决方案-网络战略与业务发展部

*发件人：* Zafar Ali (zali)

*收件人：* Greg Mirsky<[email-masked]>;draft-hegde-spring-traffic-
accounting-for-sr-paths<draft-hegde-spring-traffic-
[email-masked]>;mpls<[email-masked]>;spring<[email-masked]

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

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.”

Thanks

Regards … Zafar

*From: *spring <[email-masked]> on behalf of Greg Mirsky <
[email-masked]>
*Date: *Wednesday, November 15, 2017 at 11:10 AM
*To: *"[email-masked]" <
[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>
*Subject: *[spring] Special purpose labels in draft-hegde-spring-traffic-
accounting-for-sr-paths

Hi Shraddha,

Regards,

Greg

This e-mail message is intended for the recipient only and contains
information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
received this
transmission in error, please inform us by e-mail, phone or fax, and then
delete the original
and all copies thereof.
___________________________________________________________________________

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 16 Nov 2017 08:25:09 +0000

Hi Folks,

I also agree that it’s not a question on requirement but about a procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that breaks SR Architecture, highly unscalable and complicated to implement. We can solve this problem without breaking the SR architecture. We plan to write a draft before the next IETF.

Thanks

Regards … Zafar

From: Xuxiaohu <[email-masked]>
Date: Wednesday, November 15, 2017 at 9:54 PM
To: Greg Mirsky <[email-masked]>
Cc: "Zafar Ali (zali)" <[email-masked]>, draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>, "[email-masked]" <[email-masked]>, spring <[email-masked]>
Subject: RE: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Best regards,
Xiaohu

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 16 Nov 2017 16:33:10 +0800

Hi Zafar, et.al,
as I'm the one who have started the thread I'd like to clarify and
reiterate my point Performance measurements are required not only e2e but
on a span, i.e. SPME, using MPLS-TO lingo. If we agree on that, then we are
ready to discuss how to support these measurements in SR-MPLS.

Regards, Greg

On Nov 16, 2017 4:25 PM, "Zafar Ali (zali)" <[email-masked]> wrote:

> Hi Folks,
>
>
>
> I also agree that it’s not a question on requirement but about a procedure
> (in draft-hegde-spring-traffic-accounting-for-sr-paths) that breaks SR
> Architecture, highly unscalable and complicated to implement. We can solve
> this problem without breaking the SR architecture. We plan to write a draft
> before the next IETF.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
>
>
> *From: *Xuxiaohu <[email-masked]>
> *Date: *Wednesday, November 15, 2017 at 9:54 PM
> *To: *Greg Mirsky <[email-masked]>
> *Cc: *"Zafar Ali (zali)" <[email-masked]>, draft-hegde-spring-traffic-accounting-for-sr-paths
> <[email-masked]>, "
> [email-masked]" <[email-masked]>, spring <[email-masked]>
> *Subject: *RE: [mpls] [spring] Special purpose labels in
> I just felt that the approach as proposed in the draft would enconter the
> same terrible issues as those associated with the MPLS-SR entropy label
> usage due to RLD and MSD hardware limitations.
>
> Best regards,
> Xiaohu
>
>
>
> *发件人：* Greg Mirsky
> *收件人：* Xuxiaohu<[email-masked]>
>
> *抄送：* Zafar Ali (zali)<[email-masked]>;draft-hegde-spring-traffic-
> *时间：* 2017-11-16 10:27:55
>
>
>
> Dear All,
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Nov 2017 08:34:49 +0000

Robert,
For the reference,  draft-hegde-spring-traffic-accounting-for-sr-paths<https://tools.ietf.org/html/draft-hegde-spring-traffic-accounting-for-sr-paths-00> explicitly mentions per LSP measurements in transit nodes in Section 11 “Scalability Considerations”.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 10:23 AM
To: Alexander Vainshtein <[email-masked]>
Cc: Greg Mirsky <[email-masked]>; draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>; spring <[email-masked]>; mpls <[email-masked]>; Michael Gorokhovsky <[email-masked]>; [email-masked]; Zafar Ali (zali) <[email-masked]>; Clarence Filsfils <[email-masked]>
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Folks,

This thread started and the requirements reported clearly stated that all what we need is the ability to account per path traffic on egress nodes.

Now out of the sudden I see requirement popping up to be able to measure per path in transit nodes.

Well you can do it today with SRv6 if your hardware allows or you can do it with RSVP-TE.

SR-MPLS is replacing LDP and adds ability for limited TE. But SR-MPLS never intended to become connection oriented protocol nor architecture.

So I recommend we take a step back here. Or if you like first go and fix basic MPLS LDP LSPs to allow per end to end path accounting in transit nodes then come back here to ask for the same in SR-MPLS. Not the other way around.

Thx
r.

On Nov 16, 2017 16:12, "Alexander Vainshtein" <[email-masked]<mailto:[email-masked]>> wrote:
Greg,
I concur with your position: let’s first  of all agree that ability to measure traffic carried by an SR-TE LSP in a specific transit node is a require OAM function for SR.

Regards,
Sasha

Office: +972-39266302<tel:+972%203-926-6302>
Cell:      +972-549266302<tel:+972%2054-926-6302>
Email:   [email-masked]<mailto:[email-masked]>

From: mpls [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Greg Mirsky
Sent: Thursday, November 16, 2017 4:28 AM
To: Xuxiaohu <[email-masked]<mailto:[email-masked]>>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]<mailto:[email-masked]>>; spring <[email-masked]<mailto:[email-masked]>>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>; mpls <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 16 Nov 2017 17:15:07 +0800

Hi Sasha,
many thanks.
I'd point to SR OAM Requirements
<https://tools.ietf.org/html/draft-ietf-spring-sr-oam-requirement-03>
(regrettably expired):

   REQ#13:  SR OAM MUST have the ability to measure Packet loss, Packet
            Delay or Delay variation using Active (using synthetic
            probe) and Passive (using data stream) mode.

I think that our discussion indicates that OAM requirements document
is useful at least for as long as we're developing OAM toolset. And
the document will benefit from clarification to reflect our discussion
that PM may be performed both e2e and over SPME.

Regards,

Greg

---

From: <[email-masked]>
Date: Thu, 16 Nov 2017 09:19:03 +0000

Sasha,

the purpose of the SR OAM Use Case is to illustrate how Segment Routing enables new ways to perform OAM tasks. Like delay measurements.

What is discussed here are new OAM requirements caused by SR. To me, these are part of an own or a different draft. The scope of the SR OAM Use Case never was intended to cover them.

Regards,

Ruediger

Von: Alexander Vainshtein [mailto:[email-masked]]
Gesendet: Donnerstag, 16. November 2017 09:12
An: Greg Mirsky <[email-masked]>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>; spring <[email-masked]>; Zafar Ali (zali) <[email-masked]>; mpls <[email-masked]>; Xuxiaohu <[email-masked]>; Michael Gorokhovsky <[email-masked]>; [email-masked]
Betreff: RE: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Greg,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Nov 2017 10:44:36 +0100

Greg,

It is easy to support req 13 counters but those are interface counters
without history to which sr-mpls path it belongs.

SR-MPLS is *NOT* connection oriented and since you are poping domain wide
labels you have no path history in transit nodes.

So if anyone here now attempts to make SR-MPLS to become connection
oriented and carry and inspect per path ID in transit nodes this is
fundamental change.

Perhaps SR-MPLS spec should explicitely clarify in version 12 that this is
not the intended objective of sr-mpls.

thx
r.

On Nov 16, 2017 17:15, "Greg Mirsky" <[email-masked]> wrote:

Hi Sasha,
many thanks.

Regards,

Greg

On Thu, Nov 16, 2017 at 4:11 PM, Alexander Vainshtein <
[email-masked]> wrote:

> *收件人：* Greg Mirsky<[email-masked]>;draft-hegde-spring-traffic-acc

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Nov 2017 09:46:27 +0000

Greg,
I do not think that the quoted requirement from the SR OAM Requirements draft is relevant for this discussion, because, from my POV, it does not refer to ability to measure actual traffic carried in a specific SR-TE LSP across a specific link in the transit node. And this is actually what draft-hegde is all about.

I also do not see how SPME (an ill-begotten MPLS-TP construct) is relevant for this discussion.

As for the added state in transit node: From mu POV ability to recognize specific SR-TE Path ID in the label stack of a packet and to update the counters allocated to this SR-TE Path is a forwarding plane state.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Greg Mirsky [mailto:[email-masked]]
Sent: Thursday, November 16, 2017 11:15 AM
To: Alexander Vainshtein <[email-masked]>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>; spring <[email-masked]>; Zafar Ali (zali) <[email-masked]>; mpls <[email-masked]>; Xuxiaohu <[email-masked]>; Michael Gorokhovsky <[email-masked]>; [email-masked]
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Sasha,
many thanks.
I'd point to SR OAM Requirements<https://tools.ietf.org/html/draft-ietf-spring-sr-oam-requirement-03> (regrettably expired):

I think that our discussion indicates that OAM requirements document is useful at least for as long as we're developing OAM toolset. And the document will benefit from clarification to reflect our discussion that PM may be performed both e2e and over SPME.

Regards,

Greg

On Thu, Nov 16, 2017 at 4:11 PM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Greg,
I concur with your position: let’s first  of all agree that ability to measure traffic carried by an SR-TE LSP in a specific transit node is a require OAM function for SR.

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Mach Chen <[email-masked]>
Date: Thu, 16 Nov 2017 09:50:58 +0000

Hi all,

I agree with Sasha and Greg here!

I think the first thing we need to agree on the requirements, then discuss the solution will make more sense. I would ask the following questions:

1.       Is only E2E PM needed for MPLS-SR?

2.       Is only SPME PM needed for MPLS-SR?

3.       Are both E2E and SPME PM needed for MPLS-SR?

Best regards,
Mach

From: mpls [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Thursday, November 16, 2017 5:15 PM
To: Alexander Vainshtein
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths; spring; mpls; Michael Gorokhovsky; [email-masked]; Zafar Ali (zali)
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Sasha,
many thanks.

Regards,

Greg

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Nov 2017 09:51:20 +0000

Ruediger hi!
I understand that measurement of actual traffic carried in a SR-TE path via a transit link has not been considered in the SR OAM Use Cases draft. It only dealt with end-to-end liveness monitoring and measurements, and this is clearly stated in the Intro section.

But, from my POV, these measurements represent a valid OAM use case nevertheless.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, November 16, 2017 11:19 AM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Michael Gorokhovsky <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Sasha,

Regards,

Ruediger

Von: Alexander Vainshtein [mailto:[email-masked]]
Gesendet: Donnerstag, 16. November 2017 09:12
An: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]<mailto:[email-masked]>>; spring <[email-masked]<mailto:[email-masked]>>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>; mpls <[email-masked]<mailto:[email-masked]>>; Xuxiaohu <[email-masked]<mailto:[email-masked]>>; Michael Gorokhovsky <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Betreff: RE: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Greg,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,
thank you for very well written and thought through draft. I have these questions I'd like to discuss:
&#0;.       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.
&#0;.       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.
&#0;.       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

---

From: David Allan I <[email-masked]>
Date: Thu, 16 Nov 2017 09:56:27 +0000

I’d rephrase this to be a bit more solution agnostic….

1.       Is E2E PM required. (and this can only be achieved with pairwise measurement points).

2.       Are transit measurement points required as well…..

BTW transmit measurement points without e2e measurement points strikes me as bizarre….

The view from here
Dave

From: spring [mailto:[email-masked]] On Behalf Of Mach Chen
Sent: Thursday, November 16, 2017 5:51 PM
To: Greg Mirsky <[email-masked]>; Alexander Vainshtein <[email-masked]>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>; spring <[email-masked]>; mpls <[email-masked]>; Michael Gorokhovsky <[email-masked]>; [email-masked]; Zafar Ali (zali) <[email-masked]>
Subject: [spring] Whether both E2E and SPME performance measurement for MPLS-SR is needed?

Hi all,

Best regards,
Mach

From: mpls [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Thursday, November 16, 2017 5:15 PM
To: Alexander Vainshtein
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths; spring; mpls; Michael Gorokhovsky; [email-masked]<mailto:[email-masked]>; Zafar Ali (zali)
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Sasha,
many thanks.

Regards,

Greg

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Mach Chen <[email-masked]>
Date: Thu, 16 Nov 2017 10:00:17 +0000

Hi Dave,

Your rephrase is much better!

Thanks,
Mach

From: David Allan I [mailto:[email-masked]]
Sent: Thursday, November 16, 2017 5:56 PM
To: Mach Chen; Greg Mirsky; Alexander Vainshtein
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths; spring; mpls; Michael Gorokhovsky; [email-masked]; Zafar Ali (zali)
Subject: RE: Whether both E2E and SPME performance measurement for MPLS-SR is needed?

The view from here
Dave

From: spring [mailto:[email-masked]] On Behalf Of Mach Chen
Sent: Thursday, November 16, 2017 5:51 PM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]<mailto:[email-masked]>>; spring <[email-masked]<mailto:[email-masked]>>; mpls <[email-masked]<mailto:[email-masked]>>; Michael Gorokhovsky <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>
Subject: [spring] Whether both E2E and SPME performance measurement for MPLS-SR is needed?

Hi all,

Best regards,
Mach

Hi Sasha,
many thanks.

Regards,

Greg

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 16 Nov 2017 18:18:54 +0800

Hi Sasha,
completely agree that the current version of the #13 does not reflect the
use case at hand. Thus my suggestion to edit #13, update the Requirements
document to reflect the use case and keep the SR OAM requirements document
alive, not necessary to publish, for similar occasions.
In regards to SPME, Dave's wording is perfect and I withdraw mine.

Regards,
Greg

On Thu, Nov 16, 2017 at 5:46 PM, Alexander Vainshtein <
[email-masked]> wrote:

> Greg,
>
> I do not think that the quoted requirement from the SR OAM Requirements
> draft is relevant for this discussion, because, from my POV, it does not
> refer to *ability to measure* *actual traffic carried in a specific SR-TE
> LSP across a specific link in the transit node*. And this is actually
> what draft-hegde is all about.
>
>
>
> As for the added state in transit node: From mu POV ability to recognize
> specific SR-TE Path ID in the label stack of a packet and to update the
> counters allocated to this SR-TE Path is a forwarding plane state.
>
>
>
> My 2c,
>
> Sasha
>
>
>
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Thursday, November 16, 2017 11:15 AM
> *To:* Alexander Vainshtein <[email-masked]>
> [email-masked]>; Zafar Ali (zali) <[email-masked]>; mpls <[email-masked]>;
> Xuxiaohu <[email-masked]>; Michael Gorokhovsky <
> [email-masked]>; [email-masked]

---

From: <[email-masked]>
Date: Thu, 16 Nov 2017 10:33:46 +0000

Dave,

there’s a scalability aspect in TE traffic matrix calculation if TE isn’t based on RSVP-TE.

Regards, Ruediger

DA> BTW transmit measurement points without e2e measurement points strikes me as bizarre….

The view from here
Dave

Hi all,

Best regards,
Mach

Hi Sasha,
many thanks.

Regards,

Greg

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: <[email-masked]>
Date: Thu, 16 Nov 2017 10:48:46 +0000

Hi,

Yes today we do not have any CLI command on any router to get paths statistics for LDP (I mean Ingress to Egress) as LDP is based on MP2P LSPs, so a transit node does not have the knowledge of the source. From an operational point of  view, what we do today is that we collect netflow statistics on core routers, we project the label stack onto the routing with an external tool to get the Ingress to Egress LDP traffic including the mapping of the flows on the links.

Now for RSVP, we do have such statistics as the LSP is P2P and has states on every node.

Robert mentioned correctly that SR-TE (especially with MPLS dataplane) has limited TE features (we cannot mimic all what RSVP does in SRTE without adding too much complexity).

Thus, is it a problem (transit node stats) worth to be solved ? If yes, where do we accept to put the complexity ? For a stats issue I would rather prefer to move the complexity to an external tool that can do correlations or whatever operations rather than getting it in the forwarding plane…
IMO, that’s a “nice to have” problem to solve getting that we do not have this for LDP and we know the limitations of SR-TE MPLS.
However, Ingress stats per SRTE LSP are for sure mandatory to get !

The main drawback I see with the proposed solution is that it mimics what Entropy label does with a solution which is similar and at the same time cannot replace entropy label as the provided entropy is far from being sufficient (this is not the goal I know, but I was looking for potential use case optimizations). So in a network running entropy label and this mechanism, a router will need to find the ELI/EL and hash, then find another special label to build the stats (maybe tomorrow there will be a third one to look at and a fourth one…). That starts to be a big overhead for the forwarding plane.

Brgds,

Stephane

From: mpls [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 16:23
To: Alexander Vainshtein
Cc: spring; Clarence Filsfils; mpls; Michael Gorokhovsky; [email-masked]; draft-hegde-spring-traffic-accounting-for-sr-paths; Zafar Ali (zali)
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Folks,

Thx
r.

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Nov 2017 11:49:37 +0100

Dave,

Two main fundamental points:

1.

Is there any assumption that SR-MPLS paths are end to end (ingress to
egress) of a given domain ?

SR does not require end to end paths. In fact this is most beauty of SR
that you can add one label to forward packets to different node in SPF
topology and you make sure that traffic will be natively flowing from there
over disjoined path to native path.

How in those deployment cases all of those discussions here even apply ?

2.

To make a construct of a SR PATH you must assume that SR segments are
tightly coupled. And this is very bad as by design segments are not coupled
to each other and in fact can be chosen dynamically in transit nodes. In
those cases there is no concept of SR PATH at all.

Thx,
R.

On Thu, Nov 16, 2017 at 10:56 AM, David Allan I <[email-masked]>
wrote:

> *From:* spring [mailto:[email-masked]] *On Behalf Of *Mach Chen
> *Sent:* Thursday, November 16, 2017 5:51 PM
> *To:* Greg Mirsky <[email-masked]>; Alexander Vainshtein <
> [email-masked]>
> [email-masked]>; mpls <[email-masked]>; Michael Gorokhovsky <
> [email-masked]>; [email-masked];
> Zafar Ali (zali) <[email-masked]>
> *Subject:* [spring] Whether both E2E and SPME performance measurement for
> MPLS-SR is needed?
>
>
>
> Hi all,
>
>
>
> I think the first thing we need to agree on the requirements, then discuss
> the solution will make more sense. I would ask the following questions:
>
>
>
> *From:* mpls [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Greg Mirsky
> *Sent:* Thursday, November 16, 2017 5:15 PM
> *To:* Alexander Vainshtein
> *Cc:* draft-hegde-spring-traffic-accounting-for-sr-paths; spring; mpls;
> Michael Gorokhovsky; [email-masked]; Zafar Ali
> (zali)

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Nov 2017 11:52:59 +0100

/* resending and I got suppressed due to exceeding # of recipients */

Dave,

1.

2.

Thx,
R.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Nov 2017 11:06:26 +0000

Stephane,
Lots of thanks for formulating the questions that, from my POV, should be answered (one way or another). As I see it, they are:

1.       Is transit node per SR-TE LSP statistics a problem that should be solved?

2.       If yes:

a.       Is it a critical or “nice to have” issue? Or something in between?

b.       Should the solution be localized  in the NEs or moved to an external entity?
Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 16, 2017 12:49 PM
To: Robert Raszuk <[email-masked]>; Alexander Vainshtein <[email-masked]>
Cc: spring <[email-masked]>; Clarence Filsfils <[email-masked]>; mpls <[email-masked]>; Michael Gorokhovsky <[email-masked]>; [email-masked]; draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>; Zafar Ali (zali) <[email-masked]>
Subject: RE: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi,

Brgds,

Stephane

From: mpls [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 16:23
To: Alexander Vainshtein
Cc: spring; Clarence Filsfils; mpls; Michael Gorokhovsky; [email-masked]<mailto:[email-masked]>; draft-hegde-spring-traffic-accounting-for-sr-paths; Zafar Ali (zali)
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Folks,

Thx
r.

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

Thank you.

---

From: John E Drake <[email-masked]>
Date: Thu, 16 Nov 2017 11:43:38 +0000

Robert,

I think you’re right that ‘SR Path Id’ is the wrong term and that it should be ‘SR Segment List Id’.  We developed this draft in response to requests from our customers that, as described in our draft, have an interface on a node in the interior of an SR network whose utilization is above a given threshold.  In this situation, they need to be able to know which ingress nodes using which SR segment lists are sending traffic to that interface and how much traffic each ingress nodes is sending on each of its SR segment lists.

This will allow the SR segment lists in question to be adjusted in order to steer traffic away from that interface in a controlled manner.

Yours Irrespectively,

John

From: mpls [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 5:53 AM
To: David Allan I <[email-masked]>
Cc: mpls <[email-masked]>; spring <[email-masked]>
Subject: Re: [mpls] Whether both E2E and SPME performance measurement for MPLS-SR is needed?

Dave,

1.

Is there any assumption that SR-MPLS paths are end to end (ingress to egress) of a given domain ?

SR does not require end to end paths. In fact this is most beauty of SR that you can add one label to forward packets to different node in SPF topology and you make sure that traffic will be natively flowing from there over disjoined path to native path.

2.

To make a construct of a SR PATH you must assume that SR segments are tightly coupled. And this is very bad as by design segments are not coupled to each other and in fact can be chosen dynamically in transit nodes. In those cases there is no concept of SR PATH at all.

Thx,
R.

On Thu, Nov 16, 2017 at 10:56 AM, David Allan I <[email-masked]<mailto:[email-masked]>> wrote:
I’d rephrase this to be a bit more solution agnostic….

The view from here
Dave

From: spring [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mach Chen

Hi all,

Best regards,
Mach

Hi Sasha,
many thanks.
I'd point to SR OAM Requirements<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsr-2Doam-2Drequirement-2D03&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=NMHWJAxk35ikFsOqNiswcGOWr8RLMKDjZIVUWOKbHng&s=O9dIUxKQrlwTmypTpQrHJI2ctXc1U5kWcUB1yEsqPsA&e=> (regrettably expired):

Regards,

Greg

I have looked up the SR OAM Use Cases<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dspring-2Doam-2Dusecase_-3Finclude-5Ftext-3D1&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=NMHWJAxk35ikFsOqNiswcGOWr8RLMKDjZIVUWOKbHng&s=ZBzVsWlwT1TW-rc8hRIu2oXOGTGFWyN8oEpwHOiK63Q&e=> draft, and I did not find any relevant use cases there.
The only time measurements are mentioned is a reference to an expired implementation report<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dleipnitz-2Dspring-2Dpms-2Dimplementation-2Dreport-2D00&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=NMHWJAxk35ikFsOqNiswcGOWr8RLMKDjZIVUWOKbHng&s=QfQBqcrZK7iG73fzIFm7Pt92DgaVOiHkhujytZ0q_zo&e=> draft discussing delay measurements.  Since delay measurements are in any case based on synthetic traffic, and are always end-to-end (one-way or two-way), this reference is not relevant, IMHO, for this discussion.

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D13&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=NMHWJAxk35ikFsOqNiswcGOWr8RLMKDjZIVUWOKbHng&s=xKKBtL1_7pyQ6k9hakXPemUtJJc9c8wKgw2FgwYttIg&e=>, 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.”

Thanks

Regards … Zafar

Hi Shraddha,

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=NMHWJAxk35ikFsOqNiswcGOWr8RLMKDjZIVUWOKbHng&s=08NHkgGh3s2IUy6RcA-PJ9m6Un8j-FQd_zZABnvAz9Q&e=>

---

From: John E Drake <[email-masked]>
Date: Thu, 16 Nov 2017 11:47:45 +0000

Hi,

We are dealing with an SR network in which the data plane is MPLS rather than IP.

Yours Irrespectively,

John

From: mpls [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Thursday, November 16, 2017 1:47 AM
To: Jeff Tantsura <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>; spring <[email-masked]>; Zafar Ali (zali) <[email-masked]>; mpls <[email-masked]>
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

s/per flow/per path.

Cheers,
Jeff

thx
r.

Cheers,
Jeff

cheers,
r.

Best regards,
Xiaohu

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D13&d=DwMFbw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=Ermkx05sbKf8rezSgTWtbNoRU0NCkfX8LQAVXujSOTc&s=ef3tcju6yWwGb7J7MfjMpJVL5O0J7NJUr8vaEBuI1fk&e=>, 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.”

Thanks

Regards … Zafar

Hi Shraddha,

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMFbw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=Ermkx05sbKf8rezSgTWtbNoRU0NCkfX8LQAVXujSOTc&s=5JJv1iTKb6YIcmmJ0E1WzZUxH3HkU_zOJc4SXRJNKas&e=>
_______________________________________________ spring mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMFbw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=Ermkx05sbKf8rezSgTWtbNoRU0NCkfX8LQAVXujSOTc&s=hIyKCff30sGs4zIHazkjkrYLg5FkJADEIEMtEoD0xdA&e=>

---

From: John E Drake <[email-masked]>
Date: Thu, 16 Nov 2017 11:51:03 +0000

Sasha,

We did not use the term SR-TE LSP in our draft and I think it is misleading.  I suggested to Robert in another email that we use the term ‘SR Segment List’ since that is what the SR Architecture document describes.

Yours Irrespectively,

John

From: mpls [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Thursday, November 16, 2017 3:12 AM
To: Greg Mirsky <[email-masked]>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>; spring <[email-masked]>; mpls <[email-masked]>; Michael Gorokhovsky <[email-masked]>; [email-masked]; Zafar Ali (zali) <[email-masked]>
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Greg,

I have looked up the SR OAM Use Cases<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dspring-2Doam-2Dusecase_-3Finclude-5Ftext-3D1&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=o9qv2My5eWygGvjkf_QsK_1IAw2Atjqea6_llVBKJEk&s=ifN9UpNTQHQoMWV6z0HBj3Wav-2yLAINnkkeydarDro&e=> draft, and I did not find any relevant use cases there.
The only time measurements are mentioned is a reference to an expired implementation report<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dleipnitz-2Dspring-2Dpms-2Dimplementation-2Dreport-2D00&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=o9qv2My5eWygGvjkf_QsK_1IAw2Atjqea6_llVBKJEk&s=-HwWyJMbl3Zaa1RER9PwlKM4mv41ifM5TXFe_aAtPFk&e=> draft discussing delay measurements.  Since delay measurements are in any case based on synthetic traffic, and are always end-to-end (one-way or two-way), this reference is not relevant, IMHO, for this discussion.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Dear All,

Regards,
Greg

Best regards,
Xiaohu

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D13&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=o9qv2My5eWygGvjkf_QsK_1IAw2Atjqea6_llVBKJEk&s=rUa_oHozfedMbkZ2PtR9f8PGmo2i2JykgBbtQvdBn8A&e=>, 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.”

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Nov 2017 12:53:05 +0100

Hi John,

If so I stand by my msgs stating that you can accomplish your goal without
putting anything new on the wire.

Best,
r.

On Nov 16, 2017 19:43, "John E Drake" <[email-masked]> wrote:

> Robert,
>
>
>
> I think you’re right that ‘SR Path Id’ is the wrong term and that it
> should be ‘SR Segment List Id’.  We developed this draft in response to
> requests from our customers that, as described in our draft, have an
> interface on a node in the interior of an SR network whose utilization is
> above a given threshold.  In this situation, they need to be able to know
> which ingress nodes using which SR segment lists are sending traffic to
> that interface and how much traffic each ingress nodes is sending on each
> of its SR segment lists.
>
>
>
> This will allow the SR segment lists in question to be adjusted in order
> to steer traffic away from that interface in a controlled manner.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* mpls [mailto:[email-masked]] *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, November 16, 2017 5:53 AM
> *To:* David Allan I <[email-masked]>
> *Cc:* mpls <[email-masked]>; spring <[email-masked]>
> *Subject:* Re: [mpls] Whether both E2E and SPME performance measurement
> for MPLS-SR is needed?
>
>
>
> On Thu, Nov 16, 2017 at 10:56 AM, David Allan I <
> [email-masked]> wrote:
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsr-2Doam-2Drequirement-2D03&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=NMHWJAxk35ikFsOqNiswcGOWr8RLMKDjZIVUWOKbHng&s=O9dIUxKQrlwTmypTpQrHJI2ctXc1U5kWcUB1yEsqPsA&e=>
> (regrettably expired):
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dspring-2Doam-2Dusecase_-3Finclude-5Ftext-3D1&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=NMHWJAxk35ikFsOqNiswcGOWr8RLMKDjZIVUWOKbHng&s=ZBzVsWlwT1TW-rc8hRIu2oXOGTGFWyN8oEpwHOiK63Q&e=>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dleipnitz-2Dspring-2Dpms-2Dimplementation-2Dreport-2D00&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=NMHWJAxk35ikFsOqNiswcGOWr8RLMKDjZIVUWOKbHng&s=QfQBqcrZK7iG73fzIFm7Pt92DgaVOiHkhujytZ0q_zo&e=>
> draft-ietf-spring-segment-routing-13
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D13&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=NMHWJAxk35ikFsOqNiswcGOWr8RLMKDjZIVUWOKbHng&s=xKKBtL1_7pyQ6k9hakXPemUtJJc9c8wKgw2FgwYttIg&e=>,
> which states:
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=NMHWJAxk35ikFsOqNiswcGOWr8RLMKDjZIVUWOKbHng&s=08NHkgGh3s2IUy6RcA-PJ9m6Un8j-FQd_zZABnvAz9Q&e=>
>
>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Nov 2017 11:57:06 +0000

John,
I am fine with the name “SR Segment List ID”.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: John E Drake [mailto:[email-masked]]
Sent: Thursday, November 16, 2017 1:51 PM
To: Alexander Vainshtein <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>; spring <[email-masked]>; mpls <[email-masked]>; Michael Gorokhovsky <[email-masked]>; [email-masked]; Zafar Ali (zali) <[email-masked]>
Subject: RE: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Sasha,

Yours Irrespectively,

John

To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>

Greg,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Nov 2017 11:59:01 +0000

Robert,
Do you plan to post a draft that explains how this can be achieved without changing anything on the wire?
Without such a draft it is a bit difficult to compare the solutions:-)

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: spring [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 1:53 PM
To: John E Drake <[email-masked]>
Cc: [email-masked]; spring <[email-masked]>; David Allan I <[email-masked]>
Subject: Re: [spring] [mpls] Whether both E2E and SPME performance measurement for MPLS-SR is needed?

Hi John,

If so I stand by my msgs stating that you can accomplish your goal without putting anything new on the wire.

Best,
r.

On Nov 16, 2017 19:43, "John E Drake" <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Yours Irrespectively,

John

From: mpls [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 5:53 AM
To: David Allan I <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>; spring <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] Whether both E2E and SPME performance measurement for MPLS-SR is needed?

Dave,

1.

2.

Thx,
R.

The view from here
Dave

Hi all,

Best regards,
Mach

Hi Sasha,
many thanks.

Regards,

Greg

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: John E Drake <[email-masked]>
Date: Thu, 16 Nov 2017 12:05:01 +0000

Dave,

Comment inline

Yours Irrespectively,

John

From: mpls [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Thursday, November 16, 2017 4:56 AM
To: Mach Chen <[email-masked]>; Greg Mirsky <[email-masked]>; Alexander Vainshtein <[email-masked]>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>; spring <[email-masked]>; mpls <[email-masked]>; Michael Gorokhovsky <[email-masked]>; [email-masked]; Zafar Ali (zali) <[email-masked]>
Subject: Re: [mpls] Whether both E2E and SPME performance measurement for MPLS-SR is needed?

[JD]  Not so bizarre in an SR network in which ECMP is used.  E2e in this situation, in which we do not have an actual e2e connection does strike me as bizarre.  8->

The view from here
Dave

Hi all,

Best regards,
Mach

Hi Sasha,
many thanks.
I'd point to SR OAM Requirements<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsr-2Doam-2Drequirement-2D03&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=eO1GSURe6u7GcIepwgY8HMchjqQcWU7I06a2TUyHG8U&s=mk1jLoDLICcRiTEA-MNTjg3EbW5Hbk--OXerVANYvS0&e=> (regrettably expired):

Regards,

Greg

I have looked up the SR OAM Use Cases<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dspring-2Doam-2Dusecase_-3Finclude-5Ftext-3D1&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=eO1GSURe6u7GcIepwgY8HMchjqQcWU7I06a2TUyHG8U&s=qCm_5v2HFoBrhJMnDXrYRXqglDAE4psQGDX46TOMqtE&e=> draft, and I did not find any relevant use cases there.
The only time measurements are mentioned is a reference to an expired implementation report<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dleipnitz-2Dspring-2Dpms-2Dimplementation-2Dreport-2D00&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=eO1GSURe6u7GcIepwgY8HMchjqQcWU7I06a2TUyHG8U&s=v0jMnzom7gbuphm4wMVx-AJBCPYOP5JGcLmDd4bBlxM&e=> draft discussing delay measurements.  Since delay measurements are in any case based on synthetic traffic, and are always end-to-end (one-way or two-way), this reference is not relevant, IMHO, for this discussion.

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D13&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=eO1GSURe6u7GcIepwgY8HMchjqQcWU7I06a2TUyHG8U&s=T7UTelNuxDIpriuwnND6wHl9ckuZ9tanV9i0Ci7Ue48&e=>, 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.”

Thanks

Regards … Zafar

Hi Shraddha,

---

From: John E Drake <[email-masked]>
Date: Thu, 16 Nov 2017 11:54:34 +0000

Zafar,

Comment inline.

Yours Irrespectively,

John

From: mpls [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Thursday, November 16, 2017 3:25 AM
To: Xuxiaohu <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>; spring <[email-masked]>; mpls <[email-masked]>
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Folks,

I also agree that it’s not a question on requirement but about a procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that breaks SR Architecture, highly unscalable and complicated to implement.

[JD]  Do you have any evidence to justify any of your assertions, above?

We can solve this problem without breaking the SR architecture. We plan to write a draft before the next IETF.

Thanks

Regards … Zafar

From: Xuxiaohu <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 15, 2017 at 9:54 PM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, spring <[email-masked]<mailto:[email-masked]>>
Subject: RE: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Best regards,
Xiaohu

Dear All,

Regards,
Greg

Best regards,
Xiaohu

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D13&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=4ACxEfj7IJklDsA3Ti7k6mh4kxbTn0ukKi8Q5frZGLU&s=G3eqIWBBxQL2bH2bDbZYZlmTgsmjmi9uV10OBZ1-XvE&e=>, 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.”

Thanks

Regards … Zafar

Hi Shraddha,

---

From: John E Drake <[email-masked]>
Date: Thu, 16 Nov 2017 12:32:17 +0000

Hi,

This I completely agree with, however, given that we have had similar counters in LSRs since the advent of MPLS/RSVP-TE I am not sure this is a “complicated function”.

Yours Irrespectively,

John

From: mpls [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Wednesday, November 15, 2017 10:52 PM
To: Mach Chen <[email-masked]>; Zafar Ali (zali) <[email-masked]>; Greg Mirsky <[email-masked]>; draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>; mpls <[email-masked]>; spring <[email-masked]>
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Best regards,
Xiaohu

Hi Zafar,

Best regards,
Mach

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D13&d=DwMFbw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=H0f4eGIEJx8dGGNmVC6odbGYPjUtSzVjG1nidDV81W4&s=_uDfZ91-H1J1EfZbUnB1bCKToDMryuq30oQd8aOBquQ&e=>, 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.”

Thanks

Regards … Zafar

Hi Shraddha,

---

From: John E Drake <[email-masked]>
Date: Thu, 16 Nov 2017 12:38:17 +0000

Robert,

We are more than open to aternatives.

Yours Irrespectively,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 6:53 AM
To: John E Drake <[email-masked]>
Cc: David Allan I <[email-masked]>; [email-masked]; spring <[email-masked]>
Subject: RE: [mpls] Whether both E2E and SPME performance measurement for MPLS-SR is needed?

Hi John,

Best,
r.

Yours Irrespectively,

John

Dave,

1.

2.

Thx,
R.

The view from here
Dave

Hi all,

Best regards,
Mach

Hi Sasha,
many thanks.

Regards,

Greg

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: John E Drake <[email-masked]>
Date: Thu, 16 Nov 2017 12:39:14 +0000

Hi,

Or even just an extended email.

Yours Irrespectively,

John

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Thursday, November 16, 2017 6:59 AM
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]; spring <[email-masked]>; David Allan I <[email-masked]>; John E Drake <[email-masked]>
Subject: RE: [spring] [mpls] Whether both E2E and SPME performance measurement for MPLS-SR is needed?

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: spring [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 1:53 PM
To: John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; spring <[email-masked]<mailto:[email-masked]>>; David Allan I <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] [mpls] Whether both E2E and SPME performance measurement for MPLS-SR is needed?

Hi John,

Best,
r.

Yours Irrespectively,

John

Dave,

1.

2.

Thx,
R.

The view from here
Dave

Hi all,

Best regards,
Mach

Hi Sasha,
many thanks.

Regards,

Greg

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: John E Drake <[email-masked]>
Date: Thu, 16 Nov 2017 12:22:22 +0000

ShaoWen,

We are not talking about per-flow counting but rather per SR Segment list counting.

Yours Irrespectively,

John

From: mpls [mailto:[email-masked]] On Behalf Of ShaoWen Ma
Sent: Wednesday, November 15, 2017 9:43 PM
To: Robert Raszuk <[email-masked]>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>; spring <[email-masked]>; mpls <[email-masked]>; Zafar Ali (zali) <[email-masked]>
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Robert and all,
  SPRING try to get rid of per flow forwarding status. that's the design principal for whole network.
  and Shraddha just want to add back per flow Traffic statistics as request, which will only applied to interested flow.

  if you check the label stack for traffic statistics, that might be get some processing trouble to handle:
{300|200|100} with another label stack such as {400|300|200|100} on the same nodes.

  so path id do have it's value if customer want to check specific flow, by not impact all packet process on the transit router.

Best Regards
Shaowen Ma

On Thu, Nov 16, 2017 at 10:26 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
The architecture is fine. This is accounting state not forwarding state.

cheers,
r.

Best regards,
Xiaohu

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D13&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=pDf9Z_0bnb1M7ZTb9cuNMjqRvJMQ3j-OP-PYnk8mLsE&s=iLt83qz5E4U-p9yrmrynWZOsqFbqZtvO4kCko3KsFQs&e=>, 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.”

Thanks

Regards … Zafar

Hi Shraddha,

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=pDf9Z_0bnb1M7ZTb9cuNMjqRvJMQ3j-OP-PYnk8mLsE&s=aTsPnyRyp1Lp89MSXSIobm3FyFI7pnVCedU9BHwYSZs&e=>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=pDf9Z_0bnb1M7ZTb9cuNMjqRvJMQ3j-OP-PYnk8mLsE&s=m2O9yZ_fhqx3EWotB7qiZTrgYXqZ03Cw3IiHwOL4pdg&e=>

---

From: John E Drake <[email-masked]>
Date: Thu, 16 Nov 2017 12:28:10 +0000

Himanshu,

Good point.  We also need to be able to turn on and off packet marking by the ingress routers.

Yours Irrespectively,

John

From: mpls [mailto:[email-masked]] On Behalf Of Shah, Himanshu
Sent: Wednesday, November 15, 2017 10:35 PM
To: Mach Chen <[email-masked]>; Zafar Ali (zali) <[email-masked]>; Greg Mirsky <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Thanks,
Himanshu

Hi Zafar,

Best regards,
Mach

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D13&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=4ShnRNbDzoyjKbbNOE-PVSsfnSVi8F_DypuBCQKeBg4&s=f7J_nBpiwUgdnKFZwyOikcSLxaC1P3Jl5Rt7977hqeo&e=>, 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.”

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Nov 2017 14:43:46 +0100

Hi John,

I think I did but let me restate ...

Imagine we have a network like below:

R1 --- R2 --- R3 --- R4
            |
R5 --- R6

R1 and R5 are ingress of SR-MPLS domain and R4 is an egress. You have two
SR-MPLS paths:

P1 - R1-R2-R3-R4
P2 - R5-R6-R2-R3-R4

(I know those are SPTs but this is just for illustration).

So on each ingress we need to map packets to SR paths by some match ... it
can be based on the dst IP, src/dst IP, port # etc ... So we record those
with respect to each path they take.

Now we also record on R4 the same set of tuples.

So now we have all counters needed without asking R4 to report P1 nor P2
(nor need to carry them in the packets) as based on the tuples count which
are used on ingress for mapping we can correlate in offline tool the exact
count of traffic per ingress segment chain.

In fact we can also derive per path stats even from transit nodes with
exact the same type of offline data correlation.

Does anyone see any issue ? Is going offline so bad that we must add labels
and modify all hardware to be able to have comfort of using router's CLI to
get this data on the routers itself ?

Thx,
R.

On Thu, Nov 16, 2017 at 1:39 PM, John E Drake <[email-masked]> wrote:

> *From:* Alexander Vainshtein [mailto:[email-masked]]
> *Sent:* Thursday, November 16, 2017 6:59 AM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* [email-masked]; spring <[email-masked]>; David Allan I <
> [email-masked]>; John E Drake <[email-masked]>
> *Subject:* RE: [spring] [mpls] Whether both E2E and SPME performance
> measurement for MPLS-SR is needed?
>
>
>
> Robert,
>
> *From:* spring [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Robert Raszuk
> *Sent:* Thursday, November 16, 2017 1:53 PM
> *To:* John E Drake <[email-masked]>
> *Cc:* [email-masked]; spring <[email-masked]>; David Allan I <
> [email-masked]>
> *Subject:* Re: [spring] [mpls] Whether both E2E and SPME performance
> measurement for MPLS-SR is needed?
>
>
>
> Hi John,
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Nov 2017 14:53:06 +0100

> We are dealing with an SR network in which the data plane is MPLS rather

​I think this is very important to stop here for a moment and discuss ...
What is MPLS data plane ?

MPLS data plane can be connection less (constructed with LDP or IGP
extensions of domain wide labels) - that is really an IP based control
plane which controls the forwarding modulo tunnels to specific nodes
(SR-MPLS, GRE, VXLAN etc ....)

MPLS data plane can also be connection oriented (example using RSVP-TE​)
which setup LSP across the network. Does not reserve nor guarantee anything
in the data plane (only if well done in the control plane - which btw some
folks still do not believe after so many years :-).

So here we are now really trying to take connection oriented model and push
it to connecton less paradigm.

Very bizarre ...

​Best,
Robert.​

---

From: Mach Chen <[email-masked]>
Date: Thu, 16 Nov 2017 14:46:53 +0000

Hi Stephane,

If you want to do transit measurement, you have to pay some cost. The difference is how large the cost is, one, two or multiple labels.

For E2E measurement, it could be much easier. A single label (could be local or global) is inserted immediately follow the last label of the SR path. Since there is only one label, the path label could be put into the stack at the beginning, no matter whether the measurement is enable or not. With this, it will not affect the entropy.

Best regards,
Mach

From: mpls [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, November 16, 2017 6:49 PM
To: Robert Raszuk; Alexander Vainshtein
Cc: mpls; spring; Clarence Filsfils; draft-hegde-spring-traffic-accounting-for-sr-paths; Michael Gorokhovsky; [email-masked]; Zafar Ali (zali)
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi,

Brgds,

Stephane

Folks,

Thx
r.

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

Thank you.

---

From: Mach Chen <[email-masked]>
Date: Thu, 16 Nov 2017 14:51:40 +0000

Hi Stephane,

For E2E measurement, it could be much easier and simpler. A single label (could be local or global, as proposed in https://tools.ietf.org/html/draft-cheng-spring-path-segment ) is inserted immediately follow the last label of the SR path. Since there is only one label, the path label could be put into the stack at the beginning, no matter whether the measurement is enable or not. With this, it will not affect the entropy.

Best regards,
Mach

Hi,

Brgds,

Stephane

Folks,

Thx
r.

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

Thank you.

---

From: John E Drake <[email-masked]>
Date: Thu, 16 Nov 2017 23:33:30 +0000

Robert,

How do R6, R2, and R3 determine w/ which SR segment list a packet is associated?  E.g., the tuples in a packet from either R1 or R5 will be the same.

Yours Irrespectively,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 8:44 AM
To: John E Drake <[email-masked]>
Cc: Alexander Vainshtein <[email-masked]>; [email-masked]; spring <[email-masked]>; David Allan I <[email-masked]>
Subject: Re: [spring] [mpls] Whether both E2E and SPME performance measurement for MPLS-SR is needed?

Hi John,

R1 --- R2 --- R3 --- R4
            |
R5 --- R6

R1 and R5 are ingress of SR-MPLS domain and R4 is an egress. You have two SR-MPLS paths:

P1 - R1-R2-R3-R4
P2 - R5-R6-R2-R3-R4

So on each ingress we need to map packets to SR paths by some match ... it can be based on the dst IP, src/dst IP, port # etc ... So we record those with respect to each path they take.

So now we have all counters needed without asking R4 to report P1 nor P2 (nor need to carry them in the packets) as based on the tuples count which are used on ingress for mapping we can correlate in offline tool the exact count of traffic per ingress segment chain.

In fact we can also derive per path stats even from transit nodes with exact the same type of offline data correlation.

Does anyone see any issue ? Is going offline so bad that we must add labels and modify all hardware to be able to have comfort of using router's CLI to get this data on the routers itself ?

Thx,
R.

On Thu, Nov 16, 2017 at 1:39 PM, John E Drake <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Yours Irrespectively,

John

From: Alexander Vainshtein [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 16, 2017 6:59 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; spring <[email-masked]<mailto:[email-masked]>>; David Allan I <[email-masked]<mailto:[email-masked]>>; John E Drake <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] [mpls] Whether both E2E and SPME performance measurement for MPLS-SR is needed?

Robert,

Regards,
Sasha

Hi John,

Best,
r.

Yours Irrespectively,

John

Dave,

1.

2.

Thx,
R.

The view from here
Dave

Hi all,

Best regards,
Mach

Hi Sasha,
many thanks.

Regards,

Greg

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: John E Drake <[email-masked]>
Date: Thu, 16 Nov 2017 23:51:18 +0000

Robert,

Upon reflection, the same question can be asked of R4.

Yours Irrespectively,

John

From: John E Drake
Sent: Thursday, November 16, 2017 6:34 PM
To: Robert Raszuk <[email-masked]>
Cc: Alexander Vainshtein <[email-masked]>; [email-masked]; spring <[email-masked]>; David Allan I <[email-masked]>
Subject: RE: [spring] [mpls] Whether both E2E and SPME performance measurement for MPLS-SR is needed?

Robert,

Yours Irrespectively,

John

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 8:44 AM
To: John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; spring <[email-masked]<mailto:[email-masked]>>; David Allan I <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] [mpls] Whether both E2E and SPME performance measurement for MPLS-SR is needed?

Hi John,

R1 --- R2 --- R3 --- R4
            |
R5 --- R6

P1 - R1-R2-R3-R4
P2 - R5-R6-R2-R3-R4

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Hi John,

Best,
r.

Yours Irrespectively,

John

Dave,

1.

2.

Thx,
R.

The view from here
Dave

Hi all,

Best regards,
Mach

Hi Sasha,
many thanks.

Regards,

Greg

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Nov 2017 01:37:50 +0100

How the same packet can be received (or generated) by both R1 and R5 from
other domains or sources ?

If network would do that it is likely to get reordered ins't it ? At least
l3+l4 tuple should identify packets without any problem. If this is vpn
packets in transit let's also add vpn label.

Thx
R.

On Nov 17, 2017 00:51, "John E Drake" <[email-masked]> wrote:

> *From:* John E Drake
> *Sent:* Thursday, November 16, 2017 6:34 PM
> *Cc:* Alexander Vainshtein <[email-masked]>;
> [email-masked]; spring <[email-masked]>; David Allan I <
> How do R6, R2, and R3 determine w/ which SR segment list a packet is
> associated?  E.g., the tuples in a packet from either R1 or R5 will be the
> same.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* [email-masked] [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Robert Raszuk
> *Sent:* Thursday, November 16, 2017 8:44 AM
> *Cc:* Alexander Vainshtein <[email-masked]>;
> [email-masked]; spring <[email-masked]>; David Allan I <
> Does anyone see any issue ? Is going offline so bad that we must add
> labels and modify all hardware to be able to have comfort of using router's
> CLI to get this data on the routers itself ?
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 17 Nov 2017 00:50:55 +0000

I concur with John.

Thump typed by Sasha Vainshtein

________________________________
From: John E Drake <[email-masked]>
Sent: Friday, November 17, 2017 1:33:30 AM
To: Robert Raszuk
Cc: Alexander Vainshtein; [email-masked]; spring; David Allan I
Subject: RE: [spring] [mpls] Whether both E2E and SPME performance measurement for MPLS-SR is needed?

Robert,

Yours Irrespectively,

John

Hi John,

R1 --- R2 --- R3 --- R4
            |
R5 --- R6

P1 - R1-R2-R3-R4
P2 - R5-R6-R2-R3-R4

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Hi John,

Best,
r.

Yours Irrespectively,

John

Dave,

1.

2.

Thx,
R.

The view from here
Dave

Hi all,

Best regards,
Mach

Hi Sasha,
many thanks.

Regards,

Greg

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 17 Nov 2017 10:10:20 +0800

Dear All,
we may have lead ourselves into the woods with Readable Label Depth (RLD)
limit. AFAIK, NPUs read number of bytes of the header into the fast memory
for processing. I believe that the number of bytes is 128. If that is the
case, then what is the RLD limit? If even existing nodes are capable to *parse
SR-MPLS stack* to detect special purpose label at the BoS, then there's no
apparent need to insert SR Path Indicator more than once. Or we can use
GAL/G-ACh, as John had pointed.

Regards,
Greg

On Fri, Nov 17, 2017 at 8:50 AM, Alexander Vainshtein <
[email-masked]> wrote:

> *From:* John E Drake <[email-masked]>
> *Sent:* Friday, November 17, 2017 1:33:30 AM
> *To:* Robert Raszuk
> *Cc:* Alexander Vainshtein; [email-masked]; spring; David Allan I
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk

---

From: Mach Chen <[email-masked]>
Date: Fri, 17 Nov 2017 02:37:27 +0000

Hi Greg,

Not all devices have that capability, I would prefer to a solution that will require less extra labels.
Mach
发件人：Greg Mirsky
收件人：Alexander Vainshtein,
抄 送：spring,Robert Raszuk,[email-masked],
时间：2017-11-17 10:10:41
主 题：Re: [mpls] [spring] Whether both E2E and SPME performance measurement for MPLS-SR is needed?

Dear All,
we may have lead ourselves into the woods with Readable Label Depth (RLD) limit. AFAIK, NPUs read number of bytes of the header into the fast memory for processing. I believe that the number of bytes is 128. If that is the case, then what is the RLD limit? If even existing nodes are capable to parse SR-MPLS stack to detect special purpose label at the BoS, then there's no apparent need to insert SR Path Indicator more than once. Or we can use GAL/G-ACh, as John had pointed.

Regards,
Greg

On Fri, Nov 17, 2017 at 8:50 AM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
I concur with John.

________________________________
From: John E Drake <[email-masked]<mailto:[email-masked]>>
Sent: Friday, November 17, 2017 1:33:30 AM
To: Robert Raszuk
Cc: Alexander Vainshtein; [email-masked]<mailto:[email-masked]>; spring; David Allan I

Robert,

Yours Irrespectively,

John

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk

Hi John,

R1 --- R2 --- R3 --- R4
            |
R5 --- R6

P1 - R1-R2-R3-R4
P2 - R5-R6-R2-R3-R4

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Hi John,

Best,
r.

Yours Irrespectively,

John

Dave,

1.

2.

Thx,
R.

The view from here
Dave

Hi all,

Best regards,
Mach

Hi Sasha,
many thanks.

Regards,

Greg

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 17 Nov 2017 02:45:18 +0000

I would like to ask a fundamental question here.

Do we need transit counters for only MPLS-SR, or do we need it for 
MPLS-LDP as well?

If we need it for both, then we need to have this discussion in a 
general MPLS context and not in an MPLS-SR specific context.

At least some of the methods described here would work for both.

Also WRT the proposal to do ingress collection, if nodal paths are used, 
that only tells us the approximate path, not the hotspot which I 
understand to be the original goal.

- Stewart

On 16/11/2017 14:46, Mach Chen wrote:
>
> Hi Stephane,
>
> If you want to do transit measurement, you have to pay some cost. The 
> difference is how large the cost is, one, two or multiple labels.
>
> For E2E measurement, it could be much easier. A single label (could be 
> local or global) is inserted immediately follow the last label of the 
> SR path. Since there is only one label, the path label could be put 
> into the stack at the beginning, no matter whether the measurement is 
> enable or not. With this, it will not affect the entropy.
>
> Best regards,
>
> Mach
>
> *From:*mpls [mailto:[email-masked]] *On Behalf Of 
> [email-masked]
> *Sent:* Thursday, November 16, 2017 6:49 PM
> *To:* Robert Raszuk; Alexander Vainshtein
> *Cc:* mpls; spring; Clarence Filsfils; 
> draft-hegde-spring-traffic-accounting-for-sr-paths; Michael 
> Gorokhovsky; [email-masked]; Zafar Ali (zali)
> Yes today we do not have any CLI command on any router to get paths 
> statistics for LDP (I mean Ingress to Egress) as LDP is based on MP2P 
> LSPs, so a transit node does not have the knowledge of the source. 
> From an operational point of  view, what we do today is that we 
> collect netflow statistics on core routers, we project the label stack 
> onto the routing with an external tool to get the Ingress to Egress 
> LDP traffic including the mapping of the flows on the links.
>
> Robert mentioned correctly that SR-TE (especially with MPLS dataplane) 
> has limited TE features (we cannot mimic all what RSVP does in SRTE 
> without adding too much complexity).
>
> Thus, is it a problem (transit node stats) worth to be solved ? If 
> yes, where do we accept to put the complexity ? For a stats issue I 
> would rather prefer to move the complexity to an external tool that 
> can do correlations or whatever operations rather than getting it in 
> the forwarding plane…
>
> IMO, that’s a “nice to have” problem to solve getting that we do not 
> have this for LDP and we know the limitations of SR-TE MPLS.
>
> The main drawback I see with the proposed solution is that it mimics 
> what Entropy label does with a solution which is similar and at the 
> same time cannot replace entropy label as the provided entropy is far 
> from being sufficient (this is not the goal I know, but I was looking 
> for potential use case optimizations). So in a network running entropy 
> label and this mechanism, a router will need to find the ELI/EL and 
> hash, then find another special label to build the stats (maybe 
> tomorrow there will be a third one to look at and a fourth one…). That 
> starts to be a big overhead for the forwarding plane.
>
> Brgds,
>
> Stephane
>
> *From:*mpls [mailto:[email-masked]] *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, November 16, 2017 16:23
> *Cc:* spring; Clarence Filsfils; mpls; Michael Gorokhovsky; 
> [email-masked] 
> <mailto:[email-masked]>; 
> draft-hegde-spring-traffic-accounting-for-sr-paths; Zafar Ali (zali)
> This thread started and the requirements reported clearly stated that 
> all what we need is the ability to account per path traffic on egress 
> nodes.
>
> SR-MPLS is replacing LDP and adds ability for limited TE. But SR-MPLS 
> never intended to become connection oriented protocol nor architecture.
>
> So I recommend we take a step back here. Or if you like first go and 
> fix basic MPLS LDP LSPs to allow per end to end path accounting in 
> transit nodes then come back here to ask for the same in SR-MPLS. Not 
> the other way around.
>
> Thx
>
> r.
>
> On Nov 16, 2017 16:12, "Alexander Vainshtein" 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Greg,
>
> measure traffic carried by an SR-TE LSP in a specific transit node is 
> a require OAM function for SR.
>
> draft discussing delay measurements.  Since delay measurements are in 
> any case based on synthetic traffic, and are always end-to-end 
> (one-way or two-way), this reference is not relevant, IMHO, for this 
> discussion.
>
> Office: +972-39266302 <tel:+972%203-926-6302>
>
> Cell: +972-549266302 <tel:+972%2054-926-6302>
>
> <mailto:[email-masked]>
>
> *From:*mpls [mailto:[email-masked] 
> <mailto:[email-masked]>] *On Behalf Of *Greg Mirsky
> *To:* Xuxiaohu <[email-masked] <mailto:[email-masked]>>
> *Cc:* draft-hegde-spring-traffic-accounting-for-sr-paths 
> <[email-masked] 
> <mailto:[email-masked]>>; 
> spring <[email-masked] <mailto:[email-masked]>>; Zafar Ali (zali) 
> <[email-masked] <mailto:[email-masked]>>; mpls <[email-masked] 
> <mailto:[email-masked]>>
> 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
>
>     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 <tel:+86-13910161692>
>     E：[email-masked] <mailto:[email-masked]>
>     产品与解决方案-网络战略与业务发展部
>     *发件人：***Zafar Ali (zali)
>     *收件人：***Greg Mirsky<[email-masked]
>     <mailto:[email-masked]>>;draft-hegde-spring-traffic-accounting-for-sr-paths<[email-masked]
>     <mailto:[email-masked]>>;mpls<[email-masked]
>     <mailto:[email-masked]>>;spring<[email-masked]
>     <mailto:[email-masked]>>
>
>     *主**题：***Re: [mpls] [spring] Special purpose labels in
>     *时间：***2017-11-16 02:24:10
>
>     Hi,
>
>     https://tools.ietf.org/html/draft-ietf-spring-segment-routing-13,
>     which states:
>
>     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-masked]
>     <mailto:[email-masked]>> on behalf of Greg Mirsky
>     <[email-masked] <mailto:[email-masked]>>
>     *To: *"[email-masked]
>     <mailto:[email-masked]>"
>     <[email-masked]
>     <mailto:[email-masked]>>,
>     "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>       * 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
>
>
> [email-masked] <mailto:[email-masked]>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 17 Nov 2017 10:45:59 +0800

Hi MAch,
thank you for the update. Will continue looking for the common solution.

Regards,
Greg

On Fri, Nov 17, 2017 at 10:37 AM, Mach Chen <[email-masked]> wrote:

> *发件人：*Greg Mirsky
> *收件人：*Alexander Vainshtein,
> *抄 送：*spring,Robert Raszuk,[email-masked],
> *时间：*2017-11-17 10:10:41
> *主 题：*Re: [mpls] [spring] Whether both E2E and SPME performance
> SR-MPLS stack* to detect special purpose label at the BoS, then there's
> no apparent need to insert SR Path Indicator more than once. Or we can
> use GAL/G-ACh, as John had pointed.
>
> Regards,
> Greg
>
>> So on each ingress we need to map packets to SR paths by some match ...
>> it can be based on the dst IP, src/dst IP, port # etc ... So we record
>> those with respect to each path they take.
>>
>>
>>
>> *From:* spring [mailto:[email-masked] <[email-masked]>]
>> *On Behalf Of *Robert Raszuk
>> If so I stand by my msgs stating that you can accomplish your goal
>> without putting anything new on the wire.
>>
>>
>>
>> Best,
>>
>> r.
>>
>>
>>
>> *Subject:* [spring] Whether both E2E and SPME performance measurement
>> for MPLS-SR is needed?
>>
>>
>>
>> Hi all,
>>
>>
>>
>> I think the first thing we need to agree on the requirements, then
>> discuss the solution will make more sense. I would ask the following
>> questions:
>>
>>
>>
>> aft-ietf-spring-segment-routing-13

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 17 Nov 2017 02:48:51 +0000

Resenting with fewer names recipients

S
-------- Forwarded Message --------
Subject: 	Re: [mpls] [spring] Special purpose labels in 
draft-hegde-spring-traffic-accounting-for-sr-paths
Date: 	Fri, 17 Nov 2017 02:45:18 +0000
From: 	Stewart Bryant <[email-masked]>
To: 	Mach Chen <[email-masked]>, [email-masked] 
<[email-masked]>, Robert Raszuk <[email-masked]>, 
Alexander Vainshtein <[email-masked]>
CC: 	mpls <[email-masked]>, spring <[email-masked]>, Clarence Filsfils 
<[email-masked]>, draft-hegde-spring-traffic-accounting-for-sr-paths 
<[email-masked]>, Michael 
Gorokhovsky <[email-masked]>, 
[email-masked] 
<[email-masked]>, Zafar Ali (zali) <[email-masked]>

- Stewart

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 17 Nov 2017 10:58:07 +0800

Hi,

Some comments after reading the thread:

/*rtgwg-chair hat on

I wonder, who are the mighty “we” who are better than unworthy “them”?  I find the wording rather unfortunate 

*/

The problem statement – Uniquely identify at any given node: (SID stack, *) or (*, source) or (SID stack, source)

            Data plane – metadata encoding (label(s), VNID, none, etc)

            Control plane – capability adv, context adv, potentially divided over flooding facility (IGP/BGP) and an NBI (BGP-LS/PCEP)

If we agree, there’s a problem to solve, we review every proposal made, pros/cons analysis.

If there’s none – we move on.

Thoughts?

Cheers,

Jeff    

From: mpls <[email-masked]> on behalf of "Zafar Ali (zali)" <[email-masked]>
Date: Thursday, November 16, 2017 at 16:25
To: Xuxiaohu <[email-masked]>, Greg Mirsky <[email-masked]>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>, spring <[email-masked]>, mpls <[email-masked]>
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Folks, 

Thanks

Regards … Zafar 

Best regards,
Xiaohu 

徐小虎 Xuxiaohu
M：+86-13910161692 
E：[email-masked]
产品与解决方案-网络战略与业务发展部

发件人： Greg Mirsky

收件人： Xuxiaohu<[email-masked]>

抄送： Zafar Ali (zali)<[email-masked]>;draft-hegde-spring-traffic-accounting-for-sr-paths<[email-masked]>;mpls<[email-masked]>;spring<[email-masked]>

时间： 2017-11-16 10:27:55

Dear All, 

Regards,

Greg

Best regards,
Xiaohu 

徐小虎 Xuxiaohu
M：+86-13910161692 
E：[email-masked]
产品与解决方案-网络战略与业务发展部

发件人： Zafar Ali (zali)

时间： 2017-11-16 02:24:10

Hi, 

Thanks

Regards … Zafar 

Hi Shraddha, 

Regards,

Greg

_______________________________________________ mpls mailing list [email-masked] https://www.ietf.org/mailman/listinfo/mpls

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Nov 2017 04:00:15 +0100

Stewart,

Is there any real vendor support and real production deployment of rfc5586 ?

Is there any data on the max label depth such channel may be hidden under
yet still visible to forwarding hardware ?

Thx
R.

On Nov 17, 2017 03:49, "Stewart Bryant" <[email-masked]> wrote:

> From: Stewart Bryant <[email-masked]> <[email-masked]>
> To: Mach Chen <[email-masked]> <[email-masked]>,
> [email-masked] <[email-masked]>
> <[email-masked]>, Robert Raszuk <[email-masked]>
> <[email-masked]>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.
> com> <[email-masked]>
> CC: mpls <[email-masked]> <[email-masked]>, spring <[email-masked]>
> <[email-masked]>, Clarence Filsfils <[email-masked]>
> <[email-masked]>
> Gorokhovsky <[email-masked]>
> <[email-masked]>, [email-masked]
> <[email-masked]>
> <[email-masked]>, Zafar Ali (zali)
> <[email-masked]> <[email-masked]>
>
>
> If we need it for both, then we need to have this discussion in a general
> MPLS context and not in an MPLS-SR specific context.
>
> that only tells us the approximate path, not the hotspot which I understand
> to be the original goal.
>
> - Stewart
>
> local or global) is inserted immediately follow the last label of the SR
> path. Since there is only one label, the path label could be put into the
> stack at the beginning, no matter whether the measurement is enable or not.
> With this, it will not affect the entropy.
>
>
>
> Best regards,
>
> Mach
>
>
>
> Behalf Of [email-masked]
> *Cc:* mpls; spring; Clarence Filsfils; draft-hegde-spring-traffic-accounting-for-sr-paths;
> statistics for LDP (I mean Ingress to Egress) as LDP is based on MP2P LSPs,
> so a transit node does not have the knowledge of the source. From an
> operational point of  view, what we do today is that we collect netflow
> statistics on core routers, we project the label stack onto the routing
> with an external tool to get the Ingress to Egress LDP traffic including
> the mapping of the flows on the links.
>
>
>
> Robert mentioned correctly that SR-TE (especially with MPLS dataplane) has
> limited TE features (we cannot mimic all what RSVP does in SRTE without
> adding too much complexity).
>
>
>
> Thus, is it a problem (transit node stats) worth to be solved ? If yes,
> where do we accept to put the complexity ? For a stats issue I would rather
> prefer to move the complexity to an external tool that can do correlations
> or whatever operations rather than getting it in the forwarding plane…
>
> IMO, that’s a “nice to have” problem to solve getting that we do not have
> this for LDP and we know the limitations of SR-TE MPLS.
>
> The main drawback I see with the proposed solution is that it mimics what
> Entropy label does with a solution which is similar and at the same time
> cannot replace entropy label as the provided entropy is far from being
> sufficient (this is not the goal I know, but I was looking for potential
> use case optimizations). So in a network running entropy label and this
> mechanism, a router will need to find the ELI/EL and hash, then find
> another special label to build the stats (maybe tomorrow there will be a
> third one to look at and a fourth one…). That starts to be a big overhead
> for the forwarding plane.
>
>
>
> Brgds,
>
>
>
> Stephane
>
>
>
>
>
> [email-masked]; draft-hegde-spring-traffic-accounting-for-sr-paths;
> Zafar Ali (zali)
> mpls mailing [email-masked]://www.ietf.org/mailman/listinfo/mpls
>
>
>

---

From: Mach Chen <[email-masked]>
Date: Fri, 17 Nov 2017 03:17:42 +0000

Hi Stewart,

Indeed, the same idea can apply to both MPLS-SR and MPLS-LDP. For now, the requirements that I heard are from MPLS-SR.

Best regards,
Mach

From: Stewart Bryant [mailto:[email-masked]]
Sent: Friday, November 17, 2017 10:45 AM
To: Mach Chen; [email-masked]; Robert Raszuk; Alexander Vainshtein
Cc: mpls; spring; Clarence Filsfils; draft-hegde-spring-traffic-accounting-for-sr-paths; Michael Gorokhovsky; [email-masked]; Zafar Ali (zali)
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Do we need transit counters for only MPLS-SR, or do we need it for MPLS-LDP as well?

If we need it for both, then we need to have this discussion in a general MPLS context and not in an MPLS-SR specific context.

Also WRT the proposal to do ingress collection, if nodal paths are used, that only tells us the approximate path, not the hotspot which I understand to be the original goal.

- Stewart

Best regards,
Mach

From: mpls [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, November 16, 2017 6:49 PM
To: Robert Raszuk; Alexander Vainshtein
Cc: mpls; spring; Clarence Filsfils; draft-hegde-spring-traffic-accounting-for-sr-paths; Michael Gorokhovsky; [email-masked]<mailto:[email-masked]>; Zafar Ali (zali)
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi,

Brgds,

Stephane

Folks,

Thx
r.

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

Thank you.

mpls mailing list

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 17 Nov 2017 03:25:27 +0000

> Is there any real vendor support and real production deployment of 

Yes. It is used in PWs and MPLS-TP.  But it is only looked at by the 
egress PE.

>
> Is there any data on the max label depth such channel may be hidden 
> under yet still visible to forwarding hardware ?

Not that I know, but it was designed to be used only by the receiving PE 
where the number of labels would  normally be 3 or less (normally no 
more than LSP, PW, GAL).

If you are really asking about how far into the packet can we put a path 
marker that is visible to a p-router, then asking how into the packet 
can IPFIX work might be an alternative way to gather the information you 
need.

- Stewart

On 17/11/2017 03:00, Robert Raszuk wrote:
> Is there any data on the max label depth such channel may be hidden 
> under yet still visible to forwarding hardware ?
>
> Thx
> R.
>
> On Nov 17, 2017 03:49, "Stewart Bryant" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     <mailto:[email-masked]>
>     To: 	Mach Chen <[email-masked]>
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>
>     <[email-masked]>
>     <mailto:[email-masked]>, Robert Raszuk
>     <[email-masked]> <mailto:[email-masked]>, Alexander
>     Vainshtein <[email-masked]>
>     CC: 	mpls <[email-masked]> <mailto:[email-masked]>, spring
>     <[email-masked]> <mailto:[email-masked]>, Clarence Filsfils
>     <[email-masked]> <mailto:[email-masked]>,
>     <mailto:[email-masked]>,
>     Michael Gorokhovsky <[email-masked]>
>     <mailto:[email-masked]>,
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>, Zafar Ali (zali)
>     <[email-masked]> <mailto:[email-masked]>
>
>
>
>
>     Also WRT the proposal to do ingress collection, if nodal paths are
>     used, that only tells us the approximate path, not the hotspot
>     which I understand to be the original goal.
>
>     - Stewart
>
>>     If you want to do transit measurement, you have to pay some cost.
>>     The difference is how large the cost is, one, two or multiple labels.
>>
>>     For E2E measurement, it could be much easier. A single label
>>     (could be local or global) is inserted immediately follow the
>>     last label of the SR path. Since there is only one label, the
>>     path label could be put into the stack at the beginning, no
>>     matter whether the measurement is enable or not. With this, it
>>     will not affect the entropy.
>>
>>     Best regards,
>>
>>     Mach
>>
>>     [email-masked] <mailto:[email-masked]>
>>     Gorokhovsky; [email-masked]
>>     <mailto:[email-masked]>; Zafar Ali (zali)
>>     Yes today we do not have any CLI command on any router to get
>>     paths statistics for LDP (I mean Ingress to Egress) as LDP is
>>     based on MP2P LSPs, so a transit node does not have the knowledge
>>     of the source. From an operational point of  view, what we do
>>     today is that we collect netflow statistics on core routers, we
>>     project the label stack onto the routing with an external tool to
>>     get the Ingress to Egress LDP traffic including the mapping of
>>     the flows on the links.
>>
>>     Robert mentioned correctly that SR-TE (especially with MPLS
>>     dataplane) has limited TE features (we cannot mimic all what RSVP
>>     does in SRTE without adding too much complexity).
>>
>>     Thus, is it a problem (transit node stats) worth to be solved ?
>>     If yes, where do we accept to put the complexity ? For a stats
>>     issue I would rather prefer to move the complexity to an external
>>     tool that can do correlations or whatever operations rather than
>>     getting it in the forwarding plane…
>>
>>     IMO, that’s a “nice to have” problem to solve getting that we do
>>     not have this for LDP and we know the limitations of SR-TE MPLS.
>>
>>     The main drawback I see with the proposed solution is that it
>>     mimics what Entropy label does with a solution which is similar
>>     and at the same time cannot replace entropy label as the provided
>>     entropy is far from being sufficient (this is not the goal I
>>     know, but I was looking for potential use case optimizations). So
>>     in a network running entropy label and this mechanism, a router
>>     will need to find the ELI/EL and hash, then find another special
>>     label to build the stats (maybe tomorrow there will be a third
>>     one to look at and a fourth one…). That starts to be a big
>>     overhead for the forwarding plane.
>>
>>     Brgds,
>>
>>     Stephane
>>
>>     This thread started and the requirements reported clearly stated
>>     that all what we need is the ability to account per path traffic
>>     on egress nodes.
>>
>>     SR-MPLS is replacing LDP and adds ability for limited TE. But
>>     SR-MPLS never intended to become connection oriented protocol nor
>>     architecture.
>>
>>     So I recommend we take a step back here. Or if you like first go
>>     and fix basic MPLS LDP LSPs to allow per end to end path
>>     accounting in transit nodes then come back here to ask for the
>>     same in SR-MPLS. Not the other way around.
>>
>>     Thx
>>
>>     r.
>>
>>     I concur with your position: let’s first  of all agree that
>>     ability to measure traffic carried by an SR-TE LSP in a specific
>>     transit node is a require OAM function for SR.
>>
>>     The only time measurements are mentioned is a reference to an
>>     expired implementation report
>>     draft discussing delay measurements. Since delay measurements are
>>     in any case based on synthetic traffic, and are always end-to-end
>>     (one-way or two-way), this reference is not relevant, IMHO, for
>>     this discussion.
>>
>>     spring <[email-masked] <mailto:[email-masked]>>; Zafar Ali
>>     (zali) <[email-masked] <mailto:[email-masked]>>; mpls
>>     <[email-masked] <mailto:[email-masked]>>
>>     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
>>
>>         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
>>
>>         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
>>         <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
>>
>>         *To:
>>         *"[email-masked]
>>         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
>>     <https://www.ietf.org/mailman/listinfo/mpls>
>>
>>     Ce message et ses pieces jointes peuvent contenir des
>>     informations confidentielles ou privilegiees et ne doivent donc
>>     pas etre diffuses, exploites ou copies sans autorisation. Si vous
>>     avez recu ce message par erreur, veuillez le signaler
>>     If you have received this email in error, please notify the
>>     sender and delete this message and its attachments.
>>     As emails may be altered, Orange is not liable for messages that
>>     have been modified, changed or falsified.
>>     Thank you.
>>
>>
>>     <https://www.ietf.org/mailman/listinfo/mpls>
>
>
>     <https://www.ietf.org/mailman/listinfo/mpls>
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Nov 2017 04:26:00 +0100

Folks,

LDP LSPs follow pure dst based IGP SPT. So for each ip dst the path packet
takes is well known.

What is there to record at each transit router hop other then what you
already have today from basic netflow counters ?

Thx
R.

On Nov 17, 2017 04:18, "Mach Chen" <[email-masked]> wrote:

> Hi Stewart,
>
>
>
> Indeed, the same idea can apply to both MPLS-SR and MPLS-LDP. For now, the
> requirements that I heard are from MPLS-SR.
>
>
>
> Best regards,
>
> Mach
>
>
>
> *From:* Stewart Bryant [mailto:[email-masked]]
> *Sent:* Friday, November 17, 2017 10:45 AM
> *To:* Mach Chen; [email-masked]; Robert Raszuk; Alexander
> Vainshtein

---

From: John E Drake <[email-masked]>
Date: Fri, 17 Nov 2017 03:55:21 +0000

Stewart,

The intent is to have a general MPLS capability, as I think the draft mentions, and the draft is targeted at the MPLS WG.

Yours Irrespectively,

John

From: mpls [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Thursday, November 16, 2017 9:45 PM
To: Mach Chen <[email-masked]>; [email-masked]; Robert Raszuk <[email-masked]>; Alexander Vainshtein <[email-masked]>
Cc: mpls <[email-masked]>; spring <[email-masked]>; Clarence Filsfils <[email-masked]>; draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>; Michael Gorokhovsky <[email-masked]>; [email-masked]; Zafar Ali (zali) <[email-masked]>
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

- Stewart

Best regards,
Mach

Hi,

Brgds,

Stephane

Folks,

Thx
r.

I have looked up the SR OAM Use Cases<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dspring-2Doam-2Dusecase_-3Finclude-5Ftext-3D1&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=XwzheBED25QfOPpnZX0j6yIYLYFELDZD48fS4lpL0Oc&s=XIXFBN9loHgQ4Xnc-3LNMQdlblqxKif-n-5O6cIPww8&e=> draft, and I did not find any relevant use cases there.
The only time measurements are mentioned is a reference to an expired implementation report<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dleipnitz-2Dspring-2Dpms-2Dimplementation-2Dreport-2D00&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=XwzheBED25QfOPpnZX0j6yIYLYFELDZD48fS4lpL0Oc&s=unmsrzrN0KA-bcKG0k6iyQgg723q1HUQrpsDNqIb74Q&e=> draft discussing delay measurements.  Since delay measurements are in any case based on synthetic traffic, and are always end-to-end (one-way or two-way), this reference is not relevant, IMHO, for this discussion.

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D13&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=XwzheBED25QfOPpnZX0j6yIYLYFELDZD48fS4lpL0Oc&s=IZJpsfMsdKVSRqpPL1yhoSYIsc2l8LKuMSBkNxzs93Y&e=>, 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.”

Thanks

Regards … Zafar

Hi Shraddha,

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=XwzheBED25QfOPpnZX0j6yIYLYFELDZD48fS4lpL0Oc&s=4CBjkeudgxZuhxv39lGDzIU_P7E6usmmUmK05mlnKXw&e=>

Thank you.

mpls mailing list

https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=XwzheBED25QfOPpnZX0j6yIYLYFELDZD48fS4lpL0Oc&s=4CBjkeudgxZuhxv39lGDzIU_P7E6usmmUmK05mlnKXw&e=>

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 17 Nov 2017 05:00:14 +0000

>Do we need transit counters for only MPLS-SR, or do we need it for MPLS-LDP as well?
Would be good to start with SR-MPLS label stack, including transit nodes – not all LSRs but the Nodal/Adj-Sids as indicated in the SR-Label stack.

>Also WRT the proposal to do ingress collection, if nodal paths are used, that only tells us the approximate path, not the hotspot which I understand to be the original goal.

1.                   Though it would be limited – SR path level stats would be extremely useful – especially slicing use cases where 100’s of thousands of flows gets mapped relatively less number of SR-Paths/Sr-NODAL-ADJ-SID stack.

2.                   If we are fixated on the “hotspot issue” solution – then you *may* get into a more complex solution (both w.r.t RLD & MLDs and with usage of special labels) …
#2 is not new (possible with existing LDP network). But #1 would be a great plus for ST-TE deployments.
--
Uma C.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 17 Nov 2017 13:56:30 +0800

> On 17 Nov 2017, at 11:26 am, Robert Raszuk <[email-masked]> wrote:
> 
> Folks,
> 
> LDP LSPs follow pure dst based IGP SPT. So for each ip dst the path packet takes is well known.
> 
Yes but ... it is subjected to ecmp and just as you may wish to tune the sr stack to avoid a hotspot, so you might wish to tune the EL to get a better traffic spread.

> What is there to record at each transit router hop other then what you already have today from basic netflow counters ?
 
The traffic source.

Stewart

>> On Nov 16, 2017 16:12, "Alexander Vainshtein" <[email-masked]> wrote:
>> 
>> Greg,
>> 
>> I have looked up the SR OAM Use Cases draft, and I did not find any relevant use cases there.
>> 
>> The only time measurements are mentioned is a reference to an expired implementation report draft discussing delay measurements.  Since delay measurements are in any case based on synthetic traffic, and are always end-to-end (one-way or two-way), this reference is not relevant, IMHO, for this discussion.
>> 
>>  
>>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 17 Nov 2017 08:37:01 +0000

Hi Mach

The hotspot avoidance idea woud seem to apply to both SR and reguar LDP 
since you can always manipulate the EL modify the ECMP split. If you had 
SR that would be more direct, but EL change would be applicable to 
legacy networks. Since instrumentation could be via IPFIX prettyy much 
any P-router can support this.

Stewart

On 17/11/2017 03:17, Mach Chen wrote:
>
> Hi Stewart,
>
> Indeed, the same idea can apply to both MPLS-SR and MPLS-LDP. For now, 
> the requirements that I heard are from MPLS-SR.
>
> Best regards,
>
> Mach
>
> *From:*Stewart Bryant [mailto:[email-masked]]
> *To:* Mach Chen; [email-masked]; Robert Raszuk; 
> Alexander Vainshtein
> used, that only tells us the approximate path, not the hotspot which I 
>     (could be local or global) is inserted immediately follow the last
>     label of the SR path. Since there is only one label, the path
>     label could be put into the stack at the beginning, no matter
>     whether the measurement is enable or not. With this, it will not
>     affect the entropy.
>
>     Best regards,
>
>     Mach
>
>     get the Ingress to Egress LDP traffic including the mapping of the
>     flows on the links.
>
>     yes, where do we accept to put the complexity ? For a stats issue
>     I would rather prefer to move the complexity to an external tool
>     that can do correlations or whatever operations rather than
>     entropy is far from being sufficient (this is not the goal I know,
>     but I was looking for potential use case optimizations). So in a
>     network running entropy label and this mechanism, a router will
>     need to find the ELI/EL and hash, then find another special label
>     to build the stats (maybe tomorrow there will be a third one to
>     look at and a fourth one…). That starts to be a big overhead for
>     the forwarding plane.
>
>     Brgds,
>
>     Stephane
>
>     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
>
>         unscalable. It also makes controller job much harder and error
>         prune. In summary, I find the procedure very complex and
>         unscalable.
>
>         Thanks
>
>         Regards … Zafar
>
>             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.
>     If you have received this email in error, please notify the sender
>     and delete this message and its attachments.
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Nov 2017 12:12:05 +0100

Stewart,

Cariden Mate based on the topology and netflow computes accurate live
trafic matrix from src to dst and includes transit points for years.

It even estimates load upon failure of a node or a link.

The entire discussion here clearly does not consider or is just not aware
about tools available for a long time for IP and LDP networks capacity
planning.

And when we rolled out RSVP-TE 17 years back Cariden proved that their
accuracy of adjusting the IGP metric to wisely distribute the traffic
across domain is almost as good (95% if I recall correctly) as entire
RSVP-TE machinery.

Ref:

https://www.google.com.sg/url?sa=t&source=web&rct=j&url=http://ripe61.ripe.net/presentations/156-ripe61-bcp-planning-and-te.pdf&ved=0ahUKEwjF59nKtsXXAhUGKY8KHZpPB9gQFggnMAE&usg=AOvVaw3QvoSRcs1lFFrj1LEylTft

So before we load set of new requirements on forwarding plane please let's
at least be aware on what is possible today without those new hardware
extensions.

Many thx,
Robert.

On Nov 17, 2017 13:56, "Stewart Bryant" <[email-masked]> wrote:

Folks,

Yes but ... it is subjected to ecmp and just as you may wish to tune the sr
stack to avoid a hotspot, so you might wish to tune the EL to get a better
traffic spread.

The traffic source.

Stewart

Thx
R.

---

From: Martin Horneffer <[email-masked]>
Date: Fri, 17 Nov 2017 16:33:07 +0100

Hi,

first thank you Shraddha for bringing the topic of traffic measurement 
to the lists.
And thanks to Stephane for focusing on the - from my point of view - 
most important aspects.

Apparently you can have different requirement for traffic measurement 
and based on those you'll need more or less complex solutions. And then 
you can often place different degree of complexity and different points.

While I don't know everybody's measurement requirements I can name those 
from an operator of a large multi protocol backbone that bears many 
different services on a global scale. Tools for network simulation and 
optimization like those mentioned by Robert - but not limited to that 
particular tool - appear to have the same basic requirement:

  - On a given topology, which can be the whole MPLS cloud, or as well a 
"core" like subtopology, you need an end-to-end traffic matrix in order 
to be able to simulate the exact traffic distribution to that topology 
and for possible changes, be it network remodeling or traffic 
engineering optimizations.

  - At least for our network the design goal was always to keep 
complexity for the forwarding nodes as low as possible. Neccessary 
complexity should better be moved to external tools that do the traffic 
matric calculation and network simulation. Even though we always had a 
strong focus on traffic measurement we never wanted to change the actual 
forwarding just for the sake of measurement.

What this really means is that we don't need to measure every single 
path an every node. Thus the current proposal is quite over-engineered 
for our purpose (and probably overly complex).

If we look at current MPLS-LDP networks, contemporary devices have 
enough means for ende-to-end traffic matrix measurements. Regardless of 
whether they are called "MPLS counters" or "LDP traffic statistics": 
there are per-FEC counters and they are well-suited, when taken from 
alle involved routers, to exactly get the traffic matrix. And there are 
usually counters at head ends of traffic enigneering tunnels of any 
kind, so that you always can verify the effect of related traffic 
engineering measures.

Per-FEC counters do not require additinal state in routers. They merely 
require a counter for every FIB entry they need to have anyways.

Do we need a requirements document to get the same for SR?

Other ideas for getting the traffic matrix are welcome, just please 
don't add more complexity on the forwarding machinery, e.g. don't add 
more labels than really needed.

Best regards, Martin

Am 16.11.17 um 11:48 schrieb [email-masked]:
> [email-masked];

---

From: Martin Horneffer <[email-masked]>
Date: Fri, 17 Nov 2017 16:44:38 +0100

Hi Stewart,

a quick comment on this, from an operator's point of view: Yes, we do 
need the same measurements for LDP as well as for SR.

The exact kind of counter may be debatable. From what we have now, 
per-FEC counters (per-SID for SR) on every node seem like the best 
practical and existing solution.

Best regards, Martin

Am 17.11.17 um 03:45 schrieb Stewart Bryant:
>> For E2E measurement, it could be much easier. A single label (could 
>> be local or global) is inserted immediately follow the last label of 
>> the SR path. Since there is only one label, the path label could be 
>> put into the stack at the beginning, no matter whether the 
>> measurement is enable or not. With this, it will not affect the entropy.
>>
>> Best regards,
>>
>> Mach
>>
>> collect netflow statistics on core routers, we project the label 
>> stack onto the routing with an external tool to get the Ingress to 
>> Egress LDP traffic including the mapping of the flows on the links.
>>
>> for potential use case optimizations). So in a network running 
>> entropy label and this mechanism, a router will need to find the 
>> ELI/EL and hash, then find another special label to build the stats 
>> (maybe tomorrow there will be a third one to look at and a fourth 
>> one…). That starts to be a big overhead for the forwarding plane.
>>
>> Brgds,
>>
>> Stephane
>>
>> I concur with your position: let’s first  of all agree that ability 
>> to measure traffic carried by an SR-TE LSP in a specific transit node 
>> is a require OAM function for SR.
>>
>> network. True, some will brave the challenge and be the early 
>> 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 
>> towards OAM is real and valid. Then we can continue to discussion of 
>> what measurement method to use.
>>
>> Regards,
>>
>> Greg
>>
>>     also makes controller job much harder and error prune. In
>>     summary, I find the procedure very complex and unscalable.
>>
>>     Thanks
>>
>>     Regards … Zafar
>>
>>         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
>>
>>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sat, 18 Nov 2017 06:12:29 +0000

Hi John,

Sorry for delay in the response; I was away from the emails. Please see in-line.

Thanks

Regards … Zafar

<snip>
 <snip> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that breaks SR Architecture, highly unscalable and complicated to implement.

Please note that in draft-hegde-spring-traffic-accounting-for-sr-paths:

•    The transit node needs to be able to recognize the special label, read the SR Path Identification label and update the counter against such “states”.
•    The draft proposes to push (up to) 3 Labels for each segment in the SR Path. That means that label stack is increased up to 3x times! This is a serious a scaling issue.
•    The controller needs to keep track of transit node capability and push the additional per-path labels, accordingly. I.e., the controller also needs to maintain such information for the transit nodes.

<snip>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sat, 18 Nov 2017 06:33:49 +0000

Hi Martin and all, 

Re: Requirement document. We already have a working group document on SR OAM requirement document, https://tools.ietf.org/html/draft-ietf-spring-sr-oam-requirement-03. We should add counter requirements to it.

n.b. Please note that “we = WG” here. I use “we” to refer to the WG. 

Thanks
 
Regards … Zafar 

On 11/17/17, 10:33 AM, "spring on behalf of Martin Horneffer" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    

    

    

    Best regards, Martin

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 18 Nov 2017 14:08:09 -0000

Thanks for helping me break my resolution to leave this thread alone :-(

>>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that breaks SR
>>> Architecture, highly unscalable and complicated to implement. 
>>
> •    The transit node needs to be able to recognize the special label, read
>        the SR Path Identification label and update the counter against such
>        “states”. 

Possibly worth noting that existing devices are capable of maintaining many counters and updating them at line speed.

Several people have noted that ipfix is a process used for accounting in networks. That approach may have to find the bottom of stack and then match the packet that follows. 

Other approaches (e.g., to ECMP) involve finding the bottom of stack and hashing on the header of the payload.

Some hardware cannot perform either mechanism. This usually results from a trade between low cost, high performance, and features. Generally you can't have all three.
That hardware can't perform transit accounting with fine granularity (although you have promised us a solution within the next four months).

> •    The draft proposes to push (up to) 3 Labels for each segment in the SR
>        Path. That means that label stack is increased up to 3x times! This is a 
>        serious a scaling issue.  

John asked for evidence and you provided a misunderstanding or misreading of our draft. 
The document proposes adding 2 or 3 labels per SR Path (noting as John did, that this is our own term). 
That is not what you say, so perhaps you could retract or provide a pointer to the text.

Thus, "increased up to 3x times" applies only with the single case where the imposed label stack has exactly one label *and* the three label option is applied. So, while what you say is true, it is clearly (and wilfully?) exaggerating the severity of impact, and it is doubtful that  4-label stack is actually a problem.

> •    The controller needs to keep track of transit node capability and
>       push the additional per-path labels, accordingly. I.e., the controller
>       also needs to maintain such information for the transit nodes. 

In most cases, the controller/ingress only needs to care about the capabilities of the egress nodes. That is, if the special purpose label reaches the top of the stack it has to be able to handle it.

The only time when the transit node issue arises is when there is a small RLD. That information may need to be known by the controller to enable correct ECMP behavior, and it is distributed in the IGP. 
If there is a desire to enable accounting at transit nodes with a small RLD then the Path ID can be inserted higher up the stack and *that* means that the controller has to be sensitive as to where in the network the special purpose label will rise to the top of the stack.

It seems to me that:
- Controllers are not particularly resource constrained: adding a flag per node
   (or even per link!) would not break any scaling behavior.
- Adding another flag to the IGP alongside the RLD is not significant scaling issue.

Cheer,
Adrian

---

From: John E Drake <[email-masked]>
Date: Sun, 19 Nov 2017 17:59:46 +0000

Hi,

Comments inline

Yours Irrespectively,

John

From: spring [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Saturday, November 18, 2017 1:12 AM
To: John E Drake <[email-masked]>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>; spring <[email-masked]>; mpls <[email-masked]>
Subject: Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi John,

Thanks

Regards … Zafar

<snip>

[JD]  I think I mentioned in a previous email that this is the type of capability used by RSVP-TE LSPs since the advent of MPLS

[JD]  Um, no.  Two or three labels per SR segment list (aka MPLS label stack)

[JD]  Absolutely not, whatever gave you that idea?  If a transit node understands the labels it can maintain and report the counters, otherwise it doesn’t, but the controller doesn’t need to know this a priori.

<snip>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 20 Nov 2017 23:36:28 +0000

Hi Adrian, 

Some comments are provided in-line. 

Please note that, we all want to let this lingering tread die and follow-up on the next steps noted during this email exchange. I will be happy to have a webEx call and discuss it further, offline. 

Thanks

Regards … Zafar 

On 11/18/17, 9:08 AM, "Adrian Farrel" <[email-masked]> wrote:

<snip> 

    

>    Some hardware cannot perform either mechanism. This usually results from a trade between low cost, high performance, and features. Generally you can't have all three.

The question is not about if the hardware is able to perform such operations but regarding breaking the very beauty of SR – no states at the transit/ egress nodes. In the context of label stack size explosion, the draft also talks about needs to break an SR Path into sub-paths – thereby creating yet additional states in the network for accounting reasons (see more detail on this in the following). Furthermore, SR-MPLS is designed for SDN – the architecture calls for simplification of the network not adding complexity in the network fabric. Please also note that a network may have a large number of SR Path, thereby creating another dimension for scaling limitations. 

The proposed procedure also does not work for node protection in the network. The draft essentially calls for ALL nodes to implement procedure proposed in the document; I am quoting from the draft. 

“When using extensions
   described in this document for traffic accounting and with node-
   protection enabled in the network, it is RECOMMENDED to make sure all
   the nodes in the network support the extension.”

<snip>

    
>    Thus, "increased up to 3x times" applies only with the single case where the imposed label stack has exactly one label *and* the three label option is applied. So, while  what you say is true, i…
 
There are many scenarios that will require SR-Path-Stats Labels (up to 3 labels) to be present multiple times in the label stack. These scenarios are not uncommon. The following scenarios as noted in the draft.   
   
  “The head-end node SHOULD insert the SR-
   Path-Stats Labels at a depth in the label stack such that the nodes
   in the SR path can access the SR-Path-Identifier for accounting.  The
   SR-Path-Stats Labels may be present multiple times in the label stack
   of a packet.”

 “It is possible to partially deploy this feature when not all the
   nodes in the network support the extensions defined in this document.
   In such scenarios, the special labels MUST NOT get exposed on the top
   of the label stack at a node that does not support the extensions
   defined in this document.  This may require multiple blocks of SR-
   Path-Stats Labels to be inserted in the packet header.”

    
    
>    - Adding another flag to the IGP alongside the RLD is not significant scaling issue.
  
The comment here was not so much related to scaling but was for adding complexity to the controller/ ingress node. As you noted above and in the draft, controller/ Ingress node needs to worry about the following cases every time a path needs to be computed (quoting some of the cases from the draft). 
   
“When the head-end node
   inserts the SR-Path-Stats labels in the label stack, the place in the
   stack is decided based on whether the node where the special label
   gets exposed is capable of popping those labels.”

“While inserting the SR-Path-Stats labels, the head-end router MUST
   ensure that the labels are not exposed to the nodes that do not
   support them. “ 

“Because it is necessary that the SR-Path-Stats labels are removed
   when they are found at the top of the label stack, the node imposing
   the label stack (the ingress) must know which nodes are capable of
   stripping the labels.”

In RLDC limitation cases, “To support traffic
   accounting in such cases it is necessary to insert the SR-Path-Stats
   Labels within the Readable Label Stack Depth Capability (RLDC) of the
   nodes in the SR path.”

“The head-end node SHOULD insert the SR-
   Path-Stats Labels at a depth in the label stack such that the nodes
   in the SR path can access the SR-Path-Identifier for accounting.”

“The special labels MUST NOT get exposed on the top
   of the label stack at a node that does not support the extensions
   defined in this document.”  

“If the egress has not indicated that it is capable of removing the
   SR-Path-Stats Labels, then they MUST NOT be placed at the bottom of
   the label stack.  In this case the SR-Path-Stats Labels SHOULD be
   placed at a point in the label stack such that they will be found at
   the top of stack by the latest node in the SR path that is capable of
   removing them. “

“SR paths may require large label stacks.  Some hardware platforms do
   not support creating such large label stacks (i.e., imposing a large
   number of labels at once).  To overcome this limitation sub-paths are
   created within the network, and Binding-SIDs are allocated to these
   sub-paths.” … which means controller/ ingress software need to also create/ install sub-paths. 
  
<snip>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 20 Nov 2017 23:40:13 +0000

Hi John,

My response to Adrian’s email should also cover this email too. However, as I also noted in email to Adrian … we all want to let this lingering tread die and follow-up on the next steps noted during this email exchange. I will be happy to have a webEx call and discuss it further, offline.

Thanks

Regards … Zafar

From: "[email-masked]" <[email-masked]>
Date: Sunday, November 19, 2017 at 12:59 PM
To: "Zafar Ali (zali)" <[email-masked]>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]>, spring <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi,

Comments inline

Yours Irrespectively,

John

Hi John,

Thanks

Regards … Zafar

<snip>

<snip>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 20 Nov 2017 16:03:53 -0800

Hi Zafar,
I don't see how managing, using passive OAM, i.e. counting fly-by packets,
at transient SR-MPLS nodes can be equated to breaking "no-forwarding state
at transient LSR" model.I believe that practical is as important as
aesthetic and that network cannot be operated without comprehensive OAM
tool box. Of course, every tool in the box is optional and will not be
deployed unless the need arises. If we agree on that, perhaps we can
discuss new requirement to be added to the SR OAM Requirements document.
And then, then consider how to address such requirement. I believe that two
options were mentioned in the thread:

   - described in draft-hegde-spring-traffic-accounting-for-sr-paths
   special purpose label (actually it may end up be extended special purpose
   label) and up to two labels;
   - use GAL and ACH (perhaps somewhat similar to approach used in RFC
   8169).

Regards,
Greg

On Mon, Nov 20, 2017 at 3:36 PM, Zafar Ali (zali) <[email-masked]> wrote:

> Please note that, we all want to let this lingering tread die and
> follow-up on the next steps noted during this email exchange. I will be
> happy to have a webEx call and discuss it further, offline.
>
> Thanks
>
> Regards … Zafar
>
> >    Possibly worth noting that existing devices are capable of
> maintaining many counters and updating them at line speed.
>
> >    Several people have noted that ipfix is a process used for accounting
> in networks. That approach may have to find the bottom of stack and then
> match the packet that follows.
>
> >    Other approaches (e.g., to ECMP) involve finding the bottom of stack
> and hashing on the header of the payload.
>
> >    Some hardware cannot perform either mechanism. This usually results
> from a trade between low cost, high performance, and features. Generally
> you can't have all three.
>
> The question is not about if the hardware is able to perform such
> operations but regarding breaking the very beauty of SR – no states at the
> transit/ egress nodes. In the context of label stack size explosion, the
> draft also talks about needs to break an SR Path into sub-paths – thereby
> creating yet additional states in the network for accounting reasons (see
> more detail on this in the following). Furthermore, SR-MPLS is designed for
> SDN – the architecture calls for simplification of the network not adding
> complexity in the network fabric. Please also note that a network may have
> a large number of SR Path, thereby creating another dimension for scaling
> limitations.
>
> The proposed procedure also does not work for node protection in the
> network. The draft essentially calls for ALL nodes to implement procedure
> proposed in the document; I am quoting from the draft.
>
> “When using extensions
> >    Thus, "increased up to 3x times" applies only with the single case
> where the imposed label stack has exactly one label *and* the three label
> option is applied. So, while  what you say is true, it is clearly (and
> wilfully?) exaggerating the severity of impact, and it is doubtful that
> 4-label stack is actually a problem.
>
> There are many scenarios that will require SR-Path-Stats Labels (up to 3
> labels) to be present multiple times in the label stack. These scenarios
> are not uncommon. The following scenarios as noted in the draft.
>
> >    In most cases, the controller/ingress only needs to care about the
> capabilities of the egress nodes. That is, if the special purpose label
> reaches the top of the stack it has to be able to handle it.
>
> >    The only time when the transit node issue arises is when there is a
> small RLD. That information may need to be known by the controller to
> enable correct ECMP behavior, and it is distributed in the IGP.
> >    If there is a desire to enable accounting at transit nodes with a
> small RLD then the Path ID can be inserted higher up the stack and *that*
> means that the controller has to be sensitive as to where in the network
> the special purpose label will rise to the top of the stack.
>
> >    It seems to me that:
> The comment here was not so much related to scaling but was for adding
> complexity to the controller/ ingress node. As you noted above and in the
> draft, controller/ Ingress node needs to worry about the following cases
> every time a path needs to be computed (quoting some of the cases from the
> draft).
>
> “When the head-end node

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Tue, 21 Nov 2017 03:06:50 +0000

Hi Greg,

Overloading existing special label, optimizing stack overheads in draft-hegde, etc. will not change the architectural direction of the proposal.

I feel additional discussion on this thread will be non-productive. Martin Horneffer, Robert Raszuk, Stephane Litkowski and others have shared from their operation experiences; their input cannot be ignored by the vendors. They and others have outlined some alternatives. We need to follow-up on additional documentation (on the alternatives including existing counters) to help us converge. Please stay tuned.

Thanks

Regards … Zafar

From: Greg Mirsky <[email-masked]>
Date: Monday, November 20, 2017 at 7:03 PM
To: "Zafar Ali (zali)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, spring <[email-masked]>
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Zafar,
I don't see how managing, using passive OAM, i.e. counting fly-by packets, at transient SR-MPLS nodes can be equated to breaking "no-forwarding state at transient LSR" model.I believe that practical is as important as aesthetic and that network cannot be operated without comprehensive OAM tool box. Of course, every tool in the box is optional and will not be deployed unless the need arises. If we agree on that, perhaps we can discuss new requirement to be added to the SR OAM Requirements document. And then, then consider how to address such requirement. I believe that two options were mentioned in the thread:

  *   described in draft-hegde-spring-traffic-accounting-for-sr-paths special purpose label (actually it may end up be extended special purpose label) and up to two labels;
  *   use GAL and ACH (perhaps somewhat similar to approach used in RFC 8169).
Regards,
Greg

On Mon, Nov 20, 2017 at 3:36 PM, Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Adrian,

Thanks

Regards … Zafar

On 11/18/17, 9:08 AM, "Adrian Farrel" <[email-masked]<mailto:[email-masked]>> wrote:

<snip>

“When using extensions

<snip>

“When the head-end node

<snip>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 20 Nov 2017 19:53:20 -0800

Hi Zafar,
"overloading existing special label"? AFAIK, MPLS WG created Extended
Special Label exactly for cases like we're discussing.
Of course, alternative proposal for SR-MPLS use case will be most helpful.
As description of GAL-ACH based proposal. Stay tuned.

Regards,
Greg

On Mon, Nov 20, 2017 at 7:06 PM, Zafar Ali (zali) <[email-masked]> wrote:

> Hi Greg,
>
>
>
> Overloading existing special label, optimizing stack overheads in
> draft-hegde, etc. will not change the architectural direction of the
> proposal.
>
>
>
> I feel additional discussion on this thread will be non-productive. Martin
> Horneffer, Robert Raszuk, Stephane Litkowski and others have shared from
> their operation experiences; their input cannot be ignored by the vendors.
> They and others have outlined some alternatives. We need to follow-up on
> additional documentation (on the alternatives including existing counters)
> to help us converge. Please stay tuned.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
>
>
> *From: *Greg Mirsky <[email-masked]>
> *Date: *Monday, November 20, 2017 at 7:03 PM
> *To: *"Zafar Ali (zali)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, spring <[email-masked]>
> *Subject: *Re: [mpls] [spring] Special purpose labels in

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Tue, 21 Nov 2017 05:58:46 +0000

Greg,

Looking forward to the modified proposal.

Thanks

Regards … Zafar

Date: Monday, November 20, 2017 at 10:53 PM

Hi Zafar,
"overloading existing special label"? AFAIK, MPLS WG created Extended Special Label exactly for cases like we're discussing.
Of course, alternative proposal for SR-MPLS use case will be most helpful. As description of GAL-ACH based proposal. Stay tuned.

Regards,
Greg

On Mon, Nov 20, 2017 at 7:06 PM, Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Thanks

Regards … Zafar

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 20, 2017 at 7:03 PM
To: "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, spring <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Zafar,

Thanks

Regards … Zafar

<snip>

“When using extensions

<snip>

“When the head-end node

<snip>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 21 Nov 2017 17:56:37 -0000

Hi,

I understand that you doubt that this thread will yield anything productive, but there are a couple of things you're raising that need to be nailed down.

Probably the most important of these is the concern that you express that maintaining counters in the network goes against the beauty of the SR architecture because it means holding state at transit nodes. This seems to be a debate about the perfection of an architecture versus the manageability of the network. Don't get me wrong, I love a beautiful architecture, but only if the network can be operated successfully.

So, we should start at the top of the document and work our way down. I assume that you don't have any issues with Section 1: it seems to say what you are saying about the statelessness of SR. Section 2 is probably where you start to be unhappy: it sets an objective (to be able to count packets per flow) and sets some requirements on any solution. 

That is, I think you believe that it is not necessary (or not desirable?) to count packets in an SR network and assign those counts to the SR paths that generated those packet flows. So the challenge for you is to say whether the problem described in Figure 1 is:
- not a concern in network management
- can be solved by other means without counting traffic at
   transit nodes (Note Well that other ways of counting
   traffic at transit nodes are still counting traffic at transit
   nodes).

But one other point I want to pick up on is your claim that "the draft also talks about needs to break an SR Path into sub-paths". Sub-paths that are achieved through an expansion of a Binding SID are just part of the landscape and (of course) thy have to be coped with. The draft doesn't introduce sub-paths, it just observes that they exist.

Lastly, the conversation on the number of labels as a multiplier seems to have gotten out of hand. Why not just agree that you original statement of "increased by up to 3x" was an exaggeration?

Cheers,
Adrian

> From: Zafar Ali (zali) [mailto:[email-masked]]
> Sent: 20 November 2017 23:36
> To: [email-masked]
> Cc: 'spring'; 'mpls'
> Please note that, we all want to let this lingering tread die and follow-up on the
> next steps noted during this email exchange. I will be happy to have a webEx call
> and discuss it further, offline.
> 
> Thanks
> 
> Regards … Zafar
> 
> >    Possibly worth noting that existing devices are capable of maintaining many
> counters and updating them at line speed.
> 
> >    Several people have noted that ipfix is a process used for accounting in
> networks. That approach may have to find the bottom of stack and then match
> the packet that follows.
> 
> >    Some hardware cannot perform either mechanism. This usually results from a
> trade between low cost, high performance, and features. Generally you can't
> have all three.
> 
> The question is not about if the hardware is able to perform such operations but
> regarding breaking the very beauty of SR – no states at the transit/ egress nodes.
> In the context of label stack size explosion, the draft also talks about needs to
> break an SR Path into sub-paths – thereby creating yet additional states in the
> network for accounting reasons (see more detail on this in the following).
> Furthermore, SR-MPLS is designed for SDN – the architecture calls for
> simplification of the network not adding complexity in the network fabric. Please
> also note that a network may have a large number of SR Path, thereby creating
> another dimension for scaling limitations.
> 
> The proposed procedure also does not work for node protection in the network.
> The draft essentially calls for ALL nodes to implement procedure proposed in the
> document; I am quoting from the draft.
> 
> “When using extensions
> >    Thus, "increased up to 3x times" applies only with the single case where the
> imposed label stack has exactly one label *and* the three label option is applied.
> So, while  what you say is true, it is clearly (and wilfully?) exaggerating the
> severity of impact, and it is doubtful that  4-label stack is actually a problem.
> 
> There are many scenarios that will require SR-Path-Stats Labels (up to 3 labels) to
> be present multiple times in the label stack. These scenarios are not uncommon.
> The following scenarios as noted in the draft.
x`x> 
> >    In most cases, the controller/ingress only needs to care about the capabilities
> of the egress nodes. That is, if the special purpose label reaches the top of the
> stack it has to be able to handle it.
> 
> >    The only time when the transit node issue arises is when there is a small RLD.
> That information may need to be known by the controller to enable correct ECMP
> behavior, and it is distributed in the IGP.
> >    If there is a desire to enable accounting at transit nodes with a small RLD then
> the Path ID can be inserted higher up the stack and *that* means that the
> controller has to be sensitive as to where in the network the special purpose
> label will rise to the top of the stack.
> 
> >    It seems to me that:
> complexity to the controller/ ingress node. As you noted above and in the draft,
> controller/ Ingress node needs to worry about the following cases every time a
> path needs to be computed (quoting some of the cases from the draft).
> 
> “When the head-end node

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 21 Nov 2017 19:34:10 +0100

Hi Adrian,

I am not going to defend beauty of any architecture. I think there is much
bigger fundamental misunderstanding how in practice someone will use
SR-MPLS and I think this is the root cause for this little thread and
different perspectives of its participants.

So SR-MPLS is not RSVP-TE and there is no EROs. The set of SIDs are no more
then hints on how to steer the packets within connection less paradigm
(same as IP tunnel so to say with less encap overhead) via one or more of
IGP segments.

*The less SIDs you add to the packet the better !*

Yes that requires to be smart (or to have smart central controller) to add
only a very few labels/SIDs to accomplish the network traffic distribution
objectives. I clearly see folks thinking of SR-MPLS like a RSVP-TE analogy
with EROs, but this is IMO fundamentally wrong. Only that you can do it (to
build SR-MPLS paths all the way via your domain) does not make it a good
idea. No where in SR architecture I see any pre-asssumption that last IGP
segment will be connected to domain egress node (with the exception of EPE
but this is different app).

In fact as some may recall we are 17 years after RSVP-TE shipping code and
only very few networks ever deployed it for all unicast traffic end to end
for many reasons. Most folks used it for FRR or for hot spot bypass.

Now as far as OAM sure it is great to have it both for IP networks and
MPLS-LDP networks and SR-MPLS networks. Especially iOAM is very useful. But
this is not really related to SR-MPLS architecture.

With that I think the draft makes set of assumptions which are far from how
SR-MPLS should be deployed and this does make it rather problematic. It is
just like draft describing use of BGP for data centers ... now everyone is
using BGP for all data centers or even other types of networks regardless
if this is even applicable or best choice for a given cluster scale they
are building :).

Counters are great, more counters are even better, but I fail to see the
value for yet again counting traffic arriving via specific IGP segments
when we are already counting packets arriving via given IGP topology. My
recommendation would be to solve it for MPLS-LDP in MPLS WG first (which
after all is one example where flooding domain wide labels in IGP replaces)
and then SR-MPLS will inherit the same solution.

Cheers,
Robert.

On Tue, Nov 21, 2017 at 6:56 PM, Adrian Farrel <[email-masked]> wrote:

> Hi,
>
> I understand that you doubt that this thread will yield anything
> productive, but there are a couple of things you're raising that need to be
> nailed down.
>
> Probably the most important of these is the concern that you express that
> maintaining counters in the network goes against the beauty of the SR
> architecture because it means holding state at transit nodes. This seems to
> be a debate about the perfection of an architecture versus the
> manageability of the network. Don't get me wrong, I love a beautiful
> architecture, but only if the network can be operated successfully.
>
> So, we should start at the top of the document and work our way down. I
> assume that you don't have any issues with Section 1: it seems to say what
> you are saying about the statelessness of SR. Section 2 is probably where
> you start to be unhappy: it sets an objective (to be able to count packets
> per flow) and sets some requirements on any solution.
>
> That is, I think you believe that it is not necessary (or not desirable?)
> to count packets in an SR network and assign those counts to the SR paths
> that generated those packet flows. So the challenge for you is to say
> whether the problem described in Figure 1 is:
> But one other point I want to pick up on is your claim that "the draft
> also talks about needs to break an SR Path into sub-paths". Sub-paths that
> are achieved through an expansion of a Binding SID are just part of the
> landscape and (of course) thy have to be coped with. The draft doesn't
> introduce sub-paths, it just observes that they exist.
>
> Lastly, the conversation on the number of labels as a multiplier seems to
> have gotten out of hand. Why not just agree that you original statement of
> "increased by up to 3x" was an exaggeration?
>
> Cheers,
> Adrian
>
> follow-up on the
> >     >>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths)
> that
> > breaks SR
> maintaining many
> > >    Other approaches (e.g., to ECMP) involve finding the bottom of
> stack and
> > hashing on the header of the payload.
> >
> from a
> operations but
> network.
> > >    John asked for evidence and you provided a misunderstanding or
> misreading
> > of our draft.
> > >    The document proposes adding 2 or 3 labels per SR Path (noting as
> John did,
> > that this is our own term).
> > >    That is not what you say, so perhaps you could retract or provide a
> pointer to
> > the text.
> >
> where the
> labels) to
> capabilities
> small RLD.
> small RLD then
> > >    - Adding another flag to the IGP alongside the RLD is not
> significant scaling
> > issue.
> >
> >    sub-paths.” … which means controller/ ingress software need to also
> create/
> > install sub-paths.
> >
> > <snip>
> >
> >
>
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 22 Nov 2017 07:35:53 +0000

Hi Adrian,

I could not agree more with Robert. Martin Horneffer, Stephane Litkowski and others have shared similar view from their operation experiences.

Nailing down on minor details will just create additional rat-holes. Before jumping into solutions, what we need to do is to formally document what can be achieved using the existing tools and counters, and use it to perform gap analysis (please stay tuned on it).

Thanks

Regards … Zafar

From: <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Tuesday, November 21, 2017 at 1:34 PM
To: "[email-masked]" <[email-masked]>
Cc: "Zafar Ali (zali)" <[email-masked]>, "[email-masked]" <[email-masked]>, spring <[email-masked]>
Subject: Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi Adrian,

I am not going to defend beauty of any architecture. I think there is much bigger fundamental misunderstanding how in practice someone will use SR-MPLS and I think this is the root cause for this little thread and different perspectives of its participants.

So SR-MPLS is not RSVP-TE and there is no EROs. The set of SIDs are no more then hints on how to steer the packets within connection less paradigm (same as IP tunnel so to say with less encap overhead) via one or more of IGP segments.

The less SIDs you add to the packet the better !

Yes that requires to be smart (or to have smart central controller) to add only a very few labels/SIDs to accomplish the network traffic distribution objectives. I clearly see folks thinking of SR-MPLS like a RSVP-TE analogy with EROs, but this is IMO fundamentally wrong. Only that you can do it (to build SR-MPLS paths all the way via your domain) does not make it a good idea. No where in SR architecture I see any pre-asssumption that last IGP segment will be connected to domain egress node (with the exception of EPE but this is different app).

In fact as some may recall we are 17 years after RSVP-TE shipping code and only very few networks ever deployed it for all unicast traffic end to end for many reasons. Most folks used it for FRR or for hot spot bypass.

Now as far as OAM sure it is great to have it both for IP networks and MPLS-LDP networks and SR-MPLS networks. Especially iOAM is very useful. But this is not really related to SR-MPLS architecture.

With that I think the draft makes set of assumptions which are far from how SR-MPLS should be deployed and this does make it rather problematic. It is just like draft describing use of BGP for data centers ... now everyone is using BGP for all data centers or even other types of networks regardless if this is even applicable or best choice for a given cluster scale they are building :).

Counters are great, more counters are even better, but I fail to see the value for yet again counting traffic arriving via specific IGP segments when we are already counting packets arriving via given IGP topology. My recommendation would be to solve it for MPLS-LDP in MPLS WG first (which after all is one example where flooding domain wide labels in IGP replaces) and then SR-MPLS will inherit the same solution.

Cheers,
Robert.

On Tue, Nov 21, 2017 at 6:56 PM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Cheers,
Adrian

> From: Zafar Ali (zali) [mailto:[email-masked]<mailto:[email-masked]>]
> To: [email-masked]<mailto:[email-masked]>
> Cc: 'spring'; 'mpls'
x`x>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 22 Nov 2017 09:56:04 +0000

Comments inline:

> Please note that, we all want to let this lingering tread die and follow-up on the next steps noted during this email exchange. I will be happy to have a webEx call and discuss it further, offline.

No, some of us would  like to resolve the issue since it raises 
interesting architectural issues with SR.

> The question is not about if the hardware is able to perform such operations but regarding breaking the very beauty of SR – no states at the transit/ egress nodes.

Well, it's more about minimum state. Zero state at egress only applies 
for some classes of traffic.

Whilst the intent is for zero state in the transit nodes, this cannot be 
at the expense of not being able to manage the network.

> In the context of label stack size explosion, the draft also talks about needs to break an SR Path into sub-paths – thereby creating yet additional states in the network for accounting reasons (see more detail on this in the following). Furthermore, SR-MPLS is designed for SDN – the architecture calls for simplification of the network not adding complexity in the network fabric.

No. SR is not and never has been solely for SDN. On day one there was 
the concept that the ingress could compute the path.

> Please also note that a network may have a large number of SR Path, thereby creating another dimension for scaling limitations.
>

If all nodes support this (as recommended), then all nodes support it so 
it works during re-route. Indeed this is more important during reroute 
since that is when you expect hot spots to form.

The dynamic counter concept is no different to dynamic counters needed 
in IPFIX, so it is a concept that a lot of routers already have.

>      >        Path. That means that label stack is increased up to 3x times! This is a

Maybe there needs to be a change in the text, but what is required is 
three labels per ingress being monitored. This is something where SR 
really introduces confusion for the OAM systems and we need to work this 
through. In "classic" MPLS each label represented a layer in the 
network. SR breaks that model, with sadly little comment on this in the 
architecture. So we do need to think this through a bit, and understand 
whether we need to have a rule stating that there can only be one source 
identifier in the stack - meaning that SI can only be BoS and that if 
you want to record the source when you introduce a new layer you need to 
terminate the old stack and start a new one.

> The comment here was not so much related to scaling but was for adding complexity to the controller/ ingress node.

As far as I can tell the complexity is exactly the same as the 
complexity needed to insert the EL. Indeed you probably insert the 
labels at the same time,
and I suppose we should consider having a combined EL/SI SPL.

> As you noted above and in the draft, controller/ Ingress node needs to worry about the following cases every time a path needs to be computed (quoting some of the cases from the draft).
>     
> “When the head-end node

These look like exactly the same considerations needed for EL.

Now we need to consider what happens if we have a node that does not 
support
the required depth. In both cases the result is the same - the feature 
is not
supported, but the packet is correctly forwarded. In this case it will mean
that there is an unmonitored part of the network. That is not so bad in 
that
you can at least figure out the region in the network where this happened.
In the case of the same limitation and the EL system the result may well be
a traffic overload as there is little entropy in an SR label stack.

- Stewart

---

From: Martin Horneffer <[email-masked]>
Date: Wed, 22 Nov 2017 17:33:49 +0100

+1

In other words, I confirm from an operators point of view that Robert 
got good network desing goals quite right. I also perfectly agree with 
the observations concerning the use of RSVP in the past.

BR, Martin

Am 21.11.17 um 19:34 schrieb Robert Raszuk:
> Hi Adrian,
>
> I am not going to defend beauty of any architecture. I think there is 
> much bigger fundamental misunderstanding how in practice someone will 
> use SR-MPLS and I think this is the root cause for this little thread 
> and different perspectives of its participants.
>
> So SR-MPLS is not RSVP-TE and there is no EROs. The set of SIDs are no 
> more then hints on how to steer the packets within connection less 
> paradigm (same as IP tunnel so to say with less encap overhead) via 
> one or more of IGP segments.
> *
> *
> Yes that requires to be smart (or to have smart central controller) to 
> add only a very few labels/SIDs to accomplish the network traffic 
> distribution objectives. I clearly see folks thinking of SR-MPLS like 
> a RSVP-TE analogy with EROs, but this is IMO fundamentally wrong. Only 
> that you can do it (to build SR-MPLS paths all the way via your 
> domain) does not make it a good idea. No where in SR architecture I 
> see any pre-asssumption that last IGP segment will be connected to 
> domain egress node (with the exception of EPE but this is different app).
>
> In fact as some may recall we are 17 years after RSVP-TE shipping code 
> and only very few networks ever deployed it for all unicast traffic 
> end to end for many reasons. Most folks used it for FRR or for hot 
> spot bypass.
>
> MPLS-LDP networks and SR-MPLS networks. Especially iOAM is very 
> useful. But this is not really related to SR-MPLS architecture.
>
> With that I think the draft makes set of assumptions which are far 
> from how SR-MPLS should be deployed and this does make it rather 
> problematic. It is just like draft describing use of BGP for data 
> centers ... now everyone is using BGP for all data centers or even 
> other types of networks regardless if this is even applicable or best 
> choice for a given cluster scale they are building :).
>
> Counters are great, more counters are even better, but I fail to see 
> the value for yet again counting traffic arriving via specific IGP 
> segments when we are already counting packets arriving via given IGP 
> topology. My recommendation would be to solve it for MPLS-LDP in MPLS 
> WG first (which after all is one example where flooding domain wide 
> labels in IGP replaces) and then SR-MPLS will inherit the same solution.
>
> Cheers,
> Robert.
>
>
>     productive, but there are a couple of things you're raising that
>     need to be nailed down.
>
>     Probably the most important of these is the concern that you
>     express that maintaining counters in the network goes against the
>     beauty of the SR architecture because it means holding state at
>     transit nodes. This seems to be a debate about the perfection of
>     an architecture versus the manageability of the network. Don't get
>     me wrong, I love a beautiful architecture, but only if the network
>     can be operated successfully.
>
>     So, we should start at the top of the document and work our way
>     down. I assume that you don't have any issues with Section 1: it
>     seems to say what you are saying about the statelessness of SR.
>     Section 2 is probably where you start to be unhappy: it sets an
>     objective (to be able to count packets per flow) and sets some
>     requirements on any solution.
>
>     That is, I think you believe that it is not necessary (or not
>     desirable?) to count packets in an SR network and assign those
>     counts to the SR paths that generated those packet flows. So the
>     challenge for you is to say whether the problem described in
>     Figure 1 is:
>     But one other point I want to pick up on is your claim that "the
>     draft also talks about needs to break an SR Path into sub-paths".
>     Sub-paths that are achieved through an expansion of a Binding SID
>     are just part of the landscape and (of course) thy have to be
>     coped with. The draft doesn't introduce sub-paths, it just
>     observes that they exist.
>
>     Lastly, the conversation on the number of labels as a multiplier
>     seems to have gotten out of hand. Why not just agree that you
>     original statement of "increased by up to 3x" was an exaggeration?
>
>     Cheers,
>     Adrian
>
>     > To: [email-masked] <mailto:[email-masked]>
>     > Cc: 'spring'; 'mpls'
>     >     >>> procedure (in
>     draft-hegde-spring-traffic-accounting-for-sr-paths) that
>     > breaks SR
>     >     >>> Architecture, highly unscalable and complicated to
>     implement.
>     >     >>
>     >     >> [JD]  Do you have any evidence to justify any of your
>     assertions, above?
>     >     >
>     >     > Please note that in
>     draft-hegde-spring-traffic-accounting-for-sr-paths:
>     >     >
>     >     > •    The transit node needs to be able to recognize the
>     special label, read
>     >     >        the SR Path Identification label and update the
>     counter against such
>     >     >        “states”.
>     >
>     > >    Other approaches (e.g., to ECMP) involve finding the bottom
>     of stack and
>     >     > •    The draft proposes to push (up to) 3 Labels for each
>     segment in the SR
>     >     >        Path. That means that label stack is increased up
>     to 3x times! This is a
>     >     >        serious a scaling issue.
>     >
>     > >    John asked for evidence and you provided a misunderstanding
>     or misreading
>     > of our draft.
>     > >    The document proposes adding 2 or 3 labels per SR Path
>     (noting as John did,
>     > >    That is not what you say, so perhaps you could retract or
>     provide a pointer to
>     > the text.
>     >
>     >     >       push the additional per-path labels, accordingly.
>     I.e., the controller
>     >     >       also needs to maintain such information for the
>     transit nodes.
>     >
>     >    sub-paths.” … which means controller/ ingress software need
>     to also create/
>     > install sub-paths.
>     >
>     > <snip>
>     >
>     >
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/spring>
>
>
>
>

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 22 Nov 2017 13:08:06 -0800

Wrt architecture - don’t think one has to fit all needs. While some migrate to SR from IP/LDP environment and pretty happy with what they have got today, others come from a heavy traffic engineered one, with per LSP/node counters that are mandatory from a network management prospective(and I believe that initial discussion had been triggered by such need).
There’s no free lunch, additional requirements wrt counters will inevitably create more state, however if one doesn’t need it, it must not be imposed.
If one is willing to deal(pay) with complexity - why shouldn’t the technology facilitate it?

Regards,
Jeff

> On Nov 22, 2017, at 08:33, Martin Horneffer <[email-masked]> wrote:
> 
> +1
> 
> In other words, I confirm from an operators point of view that Robert got good network desing goals quite right. I also perfectly agree with the observations concerning the use of RSVP in the past.
> 
> BR, Martin
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 22 Nov 2017 22:17:30 +0100

Jeff,

> however if one doesn’t need it, it must not be imposed.

Sorry but ASICs do not work that way ... They are not software with options
which one can enable or not based on their wish of the day.

But if you issue a RFC which complicates things and imposes new hardware
requirements those will result in an avalanche effect on the technology in
question. And I would be very supportive of adding more management and
accounting ability if there would not be already a way to accomplish the
same as described previously in this thread.

Cheers,
Robert.

On Wed, Nov 22, 2017 at 10:08 PM, Jeff Tantsura <[email-masked]>
wrote:

> Wrt architecture - don’t think one has to fit all needs. While some
> migrate to SR from IP/LDP environment and pretty happy with what they have
> got today, others come from a heavy traffic engineered one, with per
> LSP/node counters that are mandatory from a network management
> prospective(and I believe that initial discussion had been triggered by
> such need).
> There’s no free lunch, additional requirements wrt counters will
> inevitably create more state, however if one doesn’t need it, it must not
> be imposed.
> In other words, I confirm from an operators point of view that Robert got
> good network desing goals quite right. I also perfectly agree with the
> observations concerning the use of RSVP in the past.
>
> BR, Martin
>
> more then hints on how to steer the packets within connection less paradigm
> With that I think the draft makes set of assumptions which are far from
> how SR-MPLS should be deployed and this does make it rather problematic. It
> is just like draft describing use of BGP for data centers ... now everyone
> is using BGP for all data centers or even other types of networks
> regardless if this is even applicable or best choice for a given cluster
> scale they are building :).
>
>> > >    That is not what you say, so perhaps you could retract or provide
>> a pointer to
>> > the text.
>> >
> spring mailing [email-masked]://www.ietf.org/mailman/listinfo/spring
>
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 27 Nov 2017 04:02:00 +0000

Hi, Sasha,

Just like Rüdiger stated, “SR OAM Use Case” describes a centralized system that is topology-aware to perform data plane monitoring and measurement (including delay measurement between arbitrary points).

“End-to-end liveness monitoring and measurements”, as you write, is not the correct description.

Key elements of “SR OAM Use Case” include the realization of a centralized PM server instead of modifying packets. It also allows for measurements between arbitrary points using arbitrary segment lists, with probes from the server and to the server. It does not concern itself with end-to-end measurements per se.

And “SR OAM Use Case” is not intended to be a collection of potential use cases either. Orthogonal to this thread.

Thanks,

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

On Nov 16, 2017, at 4:51 AM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:

Ruediger hi!

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, November 16, 2017 11:19 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Michael Gorokhovsky <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Sasha,

Regards,

Ruediger

Cc: draft-hegde-spring-traffic-accounting-for-sr-paths <[email-masked]<mailto:[email-masked]>>; spring <[email-masked]<mailto:[email-masked]>>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>; mpls <[email-masked]<mailto:[email-masked]>>; Xuxiaohu <[email-masked]<mailto:[email-masked]>>; Michael Gorokhovsky <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]>

Greg,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

This draft breaks the SR architecture. I am quoting a snippet from abstract of SR Architecture documenthttps://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.”

Thanks

Regards … Zafar

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 27 Nov 2017 04:11:52 +0000

[Sorry for jumping late to this thread! A couple of quick observations.]

On Nov 21, 2017, at 1:34 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

. I clearly see folks thinking of SR-MPLS like a RSVP-TE analogy with EROs

[and]

On Nov 16, 2017, at 5:48 AM, [email-masked]<mailto:[email-masked]> wrote:

I think this is the key, let’s not ATM-ify the OAM uses for SR (MPLS or IPv6).

On Nov 21, 2017, at 1:34 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Especially iOAM is very useful.

Yes!

Because it piggy-backs on data without altering the data plane realization. IPFIX for the rest.

On Nov 16, 2017, at 3:33 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Zafar, et.al<http://et.al/>,
as I'm the one who have started the thread I'd like to clarify and reiterate my point Performance measurements are required not only e2e but on a span, i.e. SPME, using MPLS-TO lingo. If we agree on that, then we are ready to discuss how to support these measurements in SR-MPLS.

I believe trying to RSVP-TE-ify the path characteristics, or inventing SR-MPLS-TP is not a good idea.

Thanks,

—

On Nov 21, 2017, at 1:34 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adrian,

Cheers,
Robert.

Cheers,
Adrian

x`x>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 27 Nov 2017 04:24:17 +0000

Actually, draft-ietf-spring-sr-oam-requirement should fade away and not progress.

Please see https://mailarchive.ietf.org/arch/msg/spring/x8f_1aM4WsPlWzuqsPmL53wF_m4

Martin, can you please update the datatracker state to reflect this, as per your email above?

As it relates to this thread:

  *   draft-ietf-spring-sr-oam-requirement contains such a high-level list of requirements that is not practically useful.
  *   Those requirements speak to protocol solutions and not to operational problems to be solved.
  *   REQ#13 is too generic to be useful. It says *nothing* about transit measurements of any kind.
  *   This discussion indicates things other than “ that OAM requirements document is useful”.

Thanks,

—

On Nov 16, 2017, at 4:15 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sasha,
many thanks.

Regards,

Greg

Regards,
Sasha

Dear All,

Regards,
Greg

Best regards,
Xiaohu

Hi,

Thanks

Regards … Zafar

Hi Shraddha,

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 27 Nov 2017 14:54:10 -0800

Hi Carlos.
you've stated: "Because it piggy-backs on data without altering the data
plane realization. IPFIX for the rest."
Do you believe that this combination, iOAM and IPFIX, addresses all SR
requirements towards OAM? That there's no need for any other tool in the SR
OAM toolbox?

Regards,
Greg

On Sun, Nov 26, 2017 at 8:11 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> On Nov 21, 2017, at 1:34 PM, Robert Raszuk <[email-masked]> wrote:
>
>
>
> On Nov 16, 2017, at 5:48 AM, [email-masked] wrote:
>
>
> On Nov 21, 2017, at 1:34 PM, Robert Raszuk <[email-masked]> wrote:
>
>
>
> On Nov 16, 2017, at 3:33 AM, Greg Mirsky <[email-masked]> wrote:
>
> Hi Zafar, et.al,
> Carlos Pignataro, [email-masked]
>
> On Nov 21, 2017, at 1:34 PM, Robert Raszuk <[email-masked]> wrote:
>
> Hi Adrian,
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 27 Nov 2017 23:07:05 +0000

Greg,

On Nov 27, 2017, at 5:54 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos.
you've stated: "Because it piggy-backs on data without altering the data plane realization. IPFIX for the rest."
Do you believe that this combination, iOAM and IPFIX, addresses all SR requirements towards OAM? That there's no need for any other tool in the SR OAM toolbox?

I believe there’s need for other OAM tools, such as LSP Ping/Trace (approved draft-ietf-mpls-spring-lsp-ping in the RFC Editor queue), and S-BFD, to name a couple key ones. There are clearly operational needs closer to trace route than to mid-point strict accounting. The sentence you quote above is in the context of this.

Best,

— Carlos.

Regards,
Greg

On Sun, Nov 26, 2017 at 8:11 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
[Sorry for jumping late to this thread! A couple of quick observations.]

[and]

Yes!

Thanks,

—

Hi Adrian,

Cheers,
Robert.

Cheers,
Adrian

x`x>