Dear Authors, et al.,
I've read the draft. Thank you for your thoughtful consideration of comments
from earlier discussions. The document is well-written and I agree with it
being on the Informational track. I've several questions and much appreciate it
if you help me to understand.
In the example of a STAMP test packet (Figure 2) the text suggests that IPv4
addresses can be used as the source and destination. In which case you see IPv4
address family should be used in the SR environment?
I suggest changing the reference in Figure 2 from Section 4.2 of RFC 8762 to
Section 3 of RFC 8972 (Figure 1). Thus the STAMP Session Identifier will be
supported in SR environments and implementations can use the value of the field
to simplify demultiplexing STAMP test sessions.
I couldn't understand the last sentence in Section 4.1.1:
An IPv4 address from the range 127/8 or IPv6
loopback address ::1/128 [RFC4291] must not be used to IP route test
packets in a network.
How this requirement (if that is the requirement, then s/must not/MUST NOT/
might be needed), is related to RFC 1801 that states that:
A router SHOULD NOT forward, except over a loopback interface, any
packet that has a destination address on network 127.
Also, it appears that only IP encapsulation is explained in Section 4.1.1.
Since the draft includes in its scope both SRv6 and SR-MPLS, I wonder in what
case IPv4 addressing will be used? It seems that rather than including IPv4,
the section should document the encapsulation of a STAMP test packet over an
MPLS link.
Section 4.1.2 also refers to IPv4 address family being used by a Session-Sender
and SR Policy. What could be the use case for IPv4 in SR?
What is the benefit of using the inner IP Header as presented in Figure 4?
As for Figure 2, I propose changing the reference to Section 3 of RFC 8792
(Figure 2).
As for Figure 4, I have a question about the inner IP header in Figure 7.
Can you point to the definition (or provide it) of the loopback mode?
The second paragraph of Section 4.2.3 suggests that the Session-Sender is
expected to receive a self-addressed STAMP test packet. Can you point out the
text in RFC 8762 that defines the base STAMP functionality on which this model
is based?
In the same paragraph, the draft states:
The Session-Sender sets the Reflector UDP port that it uses to receive the
test packet.
Can you clarify the definition of the Reflector UDP port?
The third paragraph, as I understand it, assumes that the Session-Sender does
not use some fields to calculate performance metrics. I couldn't find such a
mode is described in RFC 8762. Does this draft propose changes to the RFC 8762?
I've got confused by the rules listed for setting TTL in Section 4.4.1. For
example, according to the rule in the third paragraph, TTL must be set to 1 for
the STAMP measurement over a link. But that seems like the opposite to what is
required in RFC 5082 The Generalized TTL Security Mechanism (GTSM). I hope you
can share why TTL must be set to 1 in this case.
The same question for the use case described in the second paragraph.
Two previous questions are also applicable to Section 4.4.2.
Section 5, as I understand it, suggests that all modes of operation described
in Section 4 can be used to measure packet loss. At the same time, in Section
4.2.3. Loopback Measurement Mode is noted (or required) that the Session-Sender
sets the value of the Session-Sender Sequence Number field to zero. If that is
the case, how the packet loss is calculated in the loopback mode?
Also, Section 5 provides a very intriguing statement:
This method can be used for inferred packet loss measurement,
however, it does not provide accurate data packet loss metric.
Do you have more information, perhaps a reference to a study or RFC, to support
this statement? Following the logic of that statement, if packet loss measured
using STAMP is not accurate, wouldn't measured packet delay also be not
accurate? It seems that, if authors want to maintain this position, the
definition of the accuracy of the measurement must be introduced.
I feel that the suggestion to variate IPv4 address in measuring performance
metrics in the SR-MPLS environment is somewhat outdated and is not in step with
RFCs 6790 and 8662. Why choosing addresses from the 127/8 range is preferred to
using the Entropy label which is more likely to be used on the data traffic?
I have another question on the last sentence of Section 8:
The STAMP Session-Reflector must not transmit reply test packet if it is
not the intended destination node in the "Destination Node Address"
TLV [I-D.gandhi-ippm-stamp-srpm].
How does this requirement work in the case of a P2MP SR policy? And which
address would be used in the Destination Node Address TLV in that case?
I believe that while some questions are non-blocking and can be addressed at a
later time, there is a significant number of technical substantive issues that
must be resolved before the adoption of this draft.
I am looking forward to the Authors' feedback.
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D
Institute/Wireline Product Operation Division
E: [email protected]
www.zte.com.cn
------------------Original Mail------------------
Sender: JamesGuichard
To: [email protected];
CC: [email protected];
Date: 2021/06/07 05:34
Subject: [spring] WG Adoption Call for
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
Dear WG:
The IPPM WG has adopted
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00 as a WG
document. In a previous communication (December 16th 2020), the SPRING chairs
decided not to adopt
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt into the
WG until its companion document was accepted by the IPPM WG. This has now
happened and therefore we feel it is now time to revisit the WG adoption of
the SPRING document.
Due to the lapse of several months since the initial WG adoption call, the
chairs would like to start another 2-week WG adoption call for
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt, ending
June 21st 2021.
After review of the SPRING document please indicate support (or not) for WG
adoption to the mailing list. Please also provide comments/reasons for that
support (or lack thereof) as silence will not be considered as consent.
Thanks!
Jim, Joel & Bruno
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
