Hi Rakesh and all,
I read the draft, here is my feedback:
1) Draft is useful and augments the overall STAMP picture (RFC 8762, RFC 8972,
RFC 9503 etc.) by exact procedures including new.
2) Section 4 says "The one-way delay requires the clocks on the Session-Sender
and
Session-Reflector to be synchronized." I would add "by either NTP or PTPv2"
especially if you reffer that timestamp format should be from those protocols
in section 4.1, 7.1.1 and 7.2.1.
3) Section 4.1, Fig.2, says that SDN controller can use Yang-model
[I-D.ietf-ippm-stamp-yang] for provisioning that session info into the routers.
I also would suggest to think about special PCEP extensions for that (i.e.
PCECC RFC 8283 approach, there is also some similarity in the
draft-fizgeer-pce-pcep-bfd-parameters)
4) Session 4.4.1 "For delay measurement of an SR-MPLS Policy, the
Session-Sender test packets MUST be transmitted for every Segment List of the
Candidate-Path of the SR-MPLS Policy, by creating a separate STAMP session for
each Segment List." I think there will be need to make some estimations about
scalability constrains in this case (how many STAMP sessions can be...)
5) Section 4.4.1 says: "The Path Segment Identifier (PSID) [RFC9545] of an
SR-MPLS Policy (either for Segment List or for Candidate-Path) can be added to
the Segment List of the STAMP test packets and can be used for direct
measurement as described in Section 9, "Direct Measurement in SR Networks." I
would suggest to add here "The Path Segment Identifier (PSID) [RFC9545] of an
SR-MPLS Policy (either for Segment List or for Candidate-Path) can be added to
the Segment List, if the egress router supports its allocation... " Also if
PSID is not supported, can we estimate how that will influence STAMP
measurements procedures?
6) For the section 4.5 where is some dualism in Insert-Mode: "there may be two
incoming SRv6 SIDs for the Session-Reflector in the packet, the node SID for
the endpoint and the SID for the L3/L2 service.The Session-Sender may exclude
the node SID of the endpoint when carrying an L3/L2 service SID in the packet's
Segment List as an optimization. As an example, the Session-Sender may use the
Segment List of the SRv6 Policy in Insert-Mode utilizing the node SID of the
endpoint. "
I am afraid of interworking issues here in different implementations because of
"may exclude", "may use"... May be think about more stronger level OR describe
it in more detailed way for the case when one SID excluded and when it is not?
There are more detail in 4.5.1 but the last looks quite independent from 4.5
7) 4.5.1 same thoughts about scalability considerations as in 4.4.1. Also same
concern about PSID ("can be added to the Segment List of the STAMP test packets
and can be used for direct measurement as described in Section 9, "Direct
Measurement in SR Networks."") Thus same proposal: add "if egress node
supports PSID allocation" and describe more precisely what if PSID is not
supported.
8) 4.6 "For links, the Session-Sender may request in the test packet for the
Session-Reflector to transmit the reply test packet on the same link in the
reverse direction." -> "For links, the Session-Sender MAY request in the test
packet for the Session-Reflector to transmit the reply test packet on the same
link in the reverse direction." ?
Same suggestion is for SR Paths and SR IGP Flex-Algo paths.
9) 6.3.1.1. SR-MPLS Return Path
It says:"For example, they carry the SR-MPLS label stack of the Segment List of
the associated reverse Candidate-Path [I-D.ietf-pce-sr-bidir-path] or the
Binding SID label of the reverse SR-MPLS Policy or the SR-MPLS Prefix SID label
of the Session-Sender."
I think it would be helpful to add something like:" Those Binding SID label of
the reverse SR-MPLS Policy and reverse SR-MPLS Policy itself towards
Session-Sender SHOULD be either configured on Session Reflector or provisioned
there by SDN-controller using other means such as PCEP (
[draft-ietf-pce-segment-routing-policy-cp], RFC 9604) or BGP SR Policy (
[draft-ietf-idr-sr-policy-safi[,[draft-ietf-idr-bgp-sr-segtypes-ext]".
10) 6.4.1.1. SRv6 Return Path
Same comment as for 6.3.1.1
That is all.
Thank you.
SY,
Boris
On Friday, November 8, 2024 at 07:18:09 PM GMT+3, Rakesh Gandhi
<rgandhi.i...@gmail.com> wrote:
Thank you Zafar for the review comments.
Added in Section 4.5 of Revision-17 (also includes comments from Greg).
https://www.ietf.org/archive/id/draft-ietf-spring-stamp-srpm-17.html
Thanks,
Rakesh (for co-authors)
On Fri, Nov 8, 2024 at 2:38 PM Zafar Ali (zali)
<zali=40cisco....@dmarc.ietf.org> wrote:
>
>
>
> Dear authors,
>
>
>
> We presented draft-ali-pce-srv6-policy-sid-list-optimization [1] and had some
> hallway discussions of the relationship of the sid-list optimization in OAM
> probes. Specifically, an SRv6 policy's SID list may end with the policy
> endpoint's node SID, and the traffic steered (over policy) already ensures
> that it is taken to the policy endpoint. In such cases, the SID list can be
> optimized by excluding the endpoint Node SID when installing the policy.
>
>
>
> It would be good to add considerations for this case in
> draft-ietf-spring-stamp-srpm.
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-ali-pce-srv6-policy-sid-list-optimization/
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
>
> _______________________________________________
> spring mailing list -- spring@ietf.org
> To unsubscribe send an email to spring-le...@ietf.org
>
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
