Re: [spring] 答复: Questions about the life span of Path Segment

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

Hi Sasha,
Yes, path segment is used for counters for loss measurement for a path. However, for every path invalidation on ingress node, getting a new path segment ID from egress node using PCE might not be scalable.

Thanks,
Rakesh


From: Alexander Vainshtein <[e-mail]>
Date: Thursday, August 1, 2019 at 11:21 AM
To: "=SMTP:rgandhi@cisco. com" <[e-mail]>, "Chengli (Cheng Li)" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: 答复: Questions about the life span of Path Segment

Dear all,
Lots of thanks for your responses and apologies for my much delayed reaction.

I did not mention it in my original email, but the scenario when a Path Segment is used by the DP to collect some kind of statistics (e.g., packet loss) for the SR policy for which it has been allocated has been the major drive for raising my questions.

In this scenario when the path becomes invalid the Path Segment allocated for it should be detached from whatever statistics have been collected using it to prevent the situation when collected statistics for the now invalidated path and for some new one (e.g., the recomputed one between the same two nodes) are mixed.

I think that this is roughly what Rakesh has said in his response. And I think this should not be left for the implementation to decide but, rather, explicitly required in the draft.

My 2c,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]

From: Rakesh Gandhi (rgandhi) <[e-mail]>
Sent: Thursday, August 1, 2019 3:11 PM
To: Chengli (Cheng Li) <[e-mail]>; Alexander Vainshtein <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: 答复: Questions about the life span of Path Segment

Hi Sasha,
For PM loss measurement use-case, the same path segment ID can be used during the life span of SR Policy.

Thanks,
Rakesh


From: "Chengli (Cheng Li)" <[e-mail]<mailto:[e-mail]>>
Date: Friday, July 26, 2019 at 11:43 AM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: 答复: Questions about the life span of Path Segment
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, "=SMTP:rgandhi@cisco. com" <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-Date: Friday, July 26, 2019 at 11:43 AM

Hi Sasha,

Many thanks for you comments and sorry for my delay. Please see my reply inline.

Cheng

________________________________
发件人: spring [[e-mail]] 代表 Alexander Vainshtein [[e-mail]]
发送时间: 2019年7月24日 23:27
收件人: [e-mail]<mailto:[e-mail]>
抄送: [e-mail]<mailto:[e-mail]>
主题: [spring] Questions about the life span of Path Segment
Dear colleagues,
I have a couple of questions about the life span of the Path Segment.

Suppose that some entity has computed and instantiated an SR LP that follows a specific path from the ingress node to the  egress node across a single IGP domain. This path is expressed as a sequence of valid IGP Segments (e.g., Node and/or Adjacency segments) .
Suppose also that a Path Segment has been allocated by the egress node for this path, and the ingress node is aware of this and inserts the label acting as the SID for the Path segments immediately after the last SID of the path.

Now my questions:

1.       What happens to the Path Segment when one of the IGP segments defining the original path fails?

a.       To the best of my understanding the path itself becomes invalid

[Cheng] Agree. But IMO, the path segment has the same life circle with the associated LSP. so it MAY not be invalid in FRR since the egress, ingress even the controller does not know that until the Reroute is triggered, then it should be treated as invalid.



b.       Will the Path Segment that identifies the now invalid path be retained indefinitely, or would it be invalidated as well and the label acting as its SID released?

[Cheng] Honestly, I think it depends on implementation. The the LSP fails, then the related Path Segment is invalid. But when the Rerouted LSP is installed, the path segment should be allocated, and we don't make any assumption of the value of the path segment. It CAN be the same value as the previous one.



2.       Suppose that the entity that has computed and instantiated the original path re-computes it and instantiate a new valid path.

a.       Should the new path (that replaces the invalidated original one) be allocated with the same Path Segment as the original path, or should a new Path Segment be allocated for it?

[Cheng] Same as above. As long as the information is synchronized between the controller and the data plane, any value is OK. But the same path segment should be recommended.



b.       If the Path Segment allocated for the invalidated path is released (see (1b) above), can the label that identified it be re-used as the Path Segment ID immediately, or only after some delay?

[Cheng] It depends on the implementation. Just to make sure that the path segment can be available.



From my POV the answers to these questions do not depend on the actual method by which the Path Segments are allocated and propagated from the egress node to the ingress one.
And while my questions explicitly mention IGP Segments that define the SR LSP for which the Path Segment is allocated, the desired behavior should not depend on the type of segments used in the definition of the path.
[Cheng] Sure.

Your feedback would be highly appreciated.

Regards, and lots of thanks in advance,
[Cheng] Thank you as well for valuable comments.
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>


___________________________________________________________________________

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

___________________________________________________________________________

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