Thank for Boris for reviewing the document and providing great comments.
Sorry for the delay in replying.
Please see replies inline with <RG>….
From: Boris Hassanov <bhassa...@yahoo.com>
Date: Monday, November 25, 2024 at 5:08 AM
To: Zafar Ali (zali) <z...@cisco.com>, Rakesh Gandhi <rgandhi.i...@gmail.com>
Cc: draft-ietf-spring-stamp-s...@ietf.org
<draft-ietf-spring-stamp-s...@ietf.org>, spring@ietf.org <spring@ietf.org>
Subject: Re: [spring] Re: draft-ietf-spring-stamp-srpm and sidlist optimization
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.
<RG> Thanks.
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.
<RG> Added.
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)
<RG> At the moment, such extensions do not exist. Perhaps, we wait until there
is PCEP extension solution available.
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...)
<RG> Added in Section 14.
“ When STAMP sessions are created for every Segment List of the SR
Policies, the scalability of the number of STAMP sessions needs to be
carefully considered.”
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?
<RG> Added “if the egress router supports its allocation”
<RG> Remove text for direct measurement as it is already covered in Section 9..
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
<RG> Updated the text in the attached draft to:
“As an
optimization to avoid processing additional SIDs, the Session-Sender
excludes the node SID of the endpoint when carrying an L3/L2 service
SID in the packet's Segment List.”
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.
<RG> Added “if the egress router supports its allocation”.
<RG> Section 9 has details for SR direct measurement.
<RG> SR needs some SID for measuring traffic on egress.
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.
<RG> Updated text as:
“For links, the Session-Sender sets the "Reply Requested on the Same
Link" flag in the Control Code Sub-TLV in the Return Path TLV defined
in [RFC9503] to request the Session-Reflector to transmit the reply
test packet on the same link in the reverse direction.”
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]".
<RG> Added SDN controller as an example.
<RG> Prefer to not include various drafts related to BSID in the references, as
BSID signaling are outside the scope of this draft.
10) 6.4.1.1. SRv6 Return Path
Same comment as for 6.3.1.1
<RG> Updated as above.
Thanks,
Rakesh
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
