Thank you Boris for the detailed review of the draft.
Let us address your comments in the next revision of the draft.
Regards,
Rakesh (for co-authors)
On Mon, Nov 25, 2024 at 5:08 AM Boris Hassanov <bhassa...@yahoo.com> wrote:
> 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
