Hi Rakesh,
thank you for sharing your thoughts on the loopback mode. Please find my notes
in-lined in your last mail under GIM>> tags.
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn
------------------Original Mail------------------
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: spring@ietf.org;spring-cha...@ietf.org;jguic...@futurewei.com;
Date: 2021/06/23 19:37
Subject: Re: [spring] WG Adoption Call for
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Hi Greg,
In loopback mode, either it is STAMP (as in this draft) or BFD (as in
draft-ietf-bfd-unaffiliated-echo), the reflector simply loops the test packet
back in forwarding and does not participate in test. In both cases, I hope you
agree that the loopback mode is useful as it removes the dependency on the
reflector.
GIM>> Of course, I agree. The self-addressed test probe is a well-known OAM
tool, and IETF has published several documents that apply that principle in
different environments. However, I don't believe that the loopback in SR needs
more coverage than already in draft-ietf-6man-spring-srv6-oam. Note that that
document has a detailed explanation of the loopback mode and the right level of
abstraction.
The loopback mode does require specification on the sender, e.g. how the test
packet is encapsulated in SR, test packet is transmitted as well as how the
received test packet is processed. The metrics are computed differently than
the one-way or two-way modes, etc.
GIM>> Is the SR encapsulation of a self-addressed test probe any different
from, in principle, from encapsulating a packet in SR? I think it is not. Add
an SRH or a label stack designed to reach the intended destination. It doesn't
make any difference if the destination is the sender or any arbitrary SR node.
Hence, anyone familiar with SR is expected to understand how to encapsulate a
test probe to get it to come back to the sender. Besides, how metrics are
calculated is better to be left to the implementor. I'd argue that the packet
delay can be measured more accurately, especially in the SRv6 environment, if
T1 is recorded by the sender locally as the test packet being transmitted. Thus
an implementation can exclude variable delay caused by recalculating IP
checksum after T1 is copied into the test packet.
The loopback mode does belong to the same specification where all measurement
modes are described, to fully understand the behaviours of the sender and
reflector in each mode. For example, it can also help an operator make an
informed decision on which mode to enable in the network after reading the
standard.
GIM>> We have different views on the value of that. However, I believe in the
following principle: "A document is ready not when there's nothing left to add
to it but when there's nothing left to remove from it without it losing
informational value."
Thanks,
Rakesh
From: gregory.mir...@ztetx.com <gregory.mir...@ztetx.com>
Date: Wednesday, June 23, 2021 at 9:34 PM
To: Rakesh Gandhi (rgandhi) <rgan...@cisco.com>
Cc: spring@ietf.org <spring@ietf.org>, spring-cha...@ietf.org
<spring-cha...@ietf.org>, jguic...@futurewei.com <jguic...@futurewei.com>
Subject: Re:[spring] WG Adoption Call for
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Hi Rakesh,
I'm top-posting to share my understanding of why
draft-ietf-bfd-unaffiliated-echo is on the Standards track. As you've noted,
draft-ietf-bfd-unaffiliated-echo describes the use of BFD Echo between a BFD
system and a system that might not support BFD. But RFC 5880 excludes such use
cases by requiring that a BFD Echo be transmitted only after the BFD session is
in the Upstate. In other words, BFD peers must bring the session by exchanging
BFD control messages to the Upstate, and only after that, any system can
transmit a BFD Echo packet. draft-ietf-bfd-unaffiliated-echo will update RFC
5880 in that, and that is why, as I understand it, the draft is on the
Standards Track, not because it defines behavior entirely internal for the
sender of a BFD Echo. As I have pointed, this draft is not updating STAMP, and
the loopback mode is not affecting the Session-Reflector. I don't see that
including the description of one of the possible implementations in the
document adds value as t
her
e is no interoperability to be defined.
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn
------------------Original Mail------------------
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: spring@ietf.org;spring-cha...@ietf.org;jguic...@futurewei.com;
Date: 2021/06/23 15:59
Subject: Re: [spring] WG Adoption Call for
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Hi Greg,
Many thanks for your review comments. Please see replies inline with <RG3>…
From: gregory.mir...@ztetx.com <gregory.mir...@ztetx.com>
Date: Wednesday, June 23, 2021 at 4:57 PM
To: Rakesh Gandhi (rgandhi) <rgan...@cisco.com>
Cc: spring@ietf.org <spring@ietf.org>, spring-cha...@ietf.org
<spring-cha...@ietf.org>, jguic...@futurewei.com <jguic...@futurewei.com>
Subject: Re:[spring] WG Adoption Call for
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Hi Rakesh,
thank you for your consideration. Please find my follow-up notes in-lined under
the GIM2>> tag.
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn
------------------Original Mail------------------
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: spring@ietf.org;spring-cha...@ietf.org;jguic...@futurewei.com;
Date: 2021/06/21 12:44
Subject: Re: [spring] WG Adoption Call for
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Hi Greg,
Many thanks for your review comments and suggestions.
Please see replies inline with <RG2>…
From: gregory.mir...@ztetx.com <gregory.mir...@ztetx.com>
Date: Thursday, June 17, 2021 at 10:57 PM
To: Rakesh Gandhi (rgandhi) <rgan...@cisco.com>
Cc: jguic...@futurewei.com <jguic...@futurewei.com>, spring@ietf.org
<spring@ietf.org>, spring-cha...@ietf.org <spring-cha...@ietf.org>
Subject: Re:[spring] WG Adoption Call for
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
Hi Rakesh,
thank you for responding to my comments. I've added follow-up notes in-line
tagged GIM>>.
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn
------------------Original Mail------------------
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;jguic...@futurewei.com;
CC: spring@ietf.org;spring-cha...@ietf.org;
Date: 2021/06/16 12:50
Subject: Re: [spring] WG Adoption Call for
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Hi Greg,
Many thanks for your review comments and suggestions.
Please see replies inline with <RG>…
From: spring <spring-boun...@ietf.org> on behalf of gregory.mir...@ztetx.com
<gregory.mir...@ztetx.com>
Date: Friday, June 11, 2021 at 3:19 AM
To: jguic...@futurewei.com <jguic...@futurewei.com>
Cc: spring@ietf.org <spring@ietf.org>, spring-cha...@ietf.org
<spring-cha...@ietf.org>
Subject: Re: [spring] WG Adoption Call for
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
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.
<RG> Many thanks.
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?
<RG> Figure 2 shows both IPv4 and IPv6 address family and they are the
addresses of the Session-Sender and Session-Reflector as defined in STAMP. The
STAMP packet is further encapsulated with an SR-MPLS/SRv6 header depending on
SR-MPLS Policy or SRv6 Policy being measured.
GIM>> Can you please clarify for me SRv6 scenario. The authors of the draft
propose to encapsulate a STAMP packet, from a Session-Sender or
Session-Reflector, in IP/UDP and then, on top of that, add another IPv6
encapsulation with SRH? Any reason why not simply add the SRH to a STAMP
packet encapsulated in IPv6?
<RG2> When using the SIDs of the forward path in SRH, the top IPv6/SRH is added
to bring the test packet to the Session-Reflector from the Session-Sender. In
loopback mode, the bottom IPv6 header is used to bring the test packet back
from the Session-Reflector to the Session-Sender. The bottom IPv6 header is
not required when using SIDs of both forward + reverse paths in SRH.
GIM2>> Thank you for the clarification. If I understand it correctly, in the
loopback mode the STAMP Session-Reflector function is not involved in
processing the STAMP test packet. If that is the case, what is the value of
including the description of the loopback mode in the draft?
<RG3> This is similar to BFD in loopback mode as defined in
draft-ietf-bfd-unaffiliated-echo-02.txt, where the remote side does not support
BFD protocol for example, and simply loops back the packet. It is also a
Standards-track document.
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.
<RG> Thanks for the suggestion, agree to update it in the next revision.
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.
<RG> Agree to remove this sentence in the next revision.
GIM>> Thank you, looking forward to the next version.
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.
<RG> It is not necessary to add SR encapsulate for sending test packets for
links.
<RG> However, we could add text to state
“SR encapsulation (e.g. adjacency SID of the link) can be added for
transmitting the test packets for links.”
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?
<RG> As mentioned above, RFC 8762 base STAMP packets carry IP/UDP header.
GIM>> I disagree. RFC 8762 does not require STAMP test packet use IP/UDP
encapsulation. It states that if STAMP test message is enapculated in IP/UDP,
then it may use destination port 862 for a Session-Sender test packets. Other
encapsulations are outside the scope of RFC 8762. If we consider MPLS, then,
in addition to using IP/UDP, a new ACH type can be used to carry STAMP messages.
The IP address family in the base STAMP test packet can be IPv4 or IPv6 address
of the Session-Sender and Session-Reflector. In SR, the STAMP packets are
further encapsulated with an SR header.
<RG2> The scope of this draft is IP/UDP header based STAMP test packets. We are
planning to publish a new draft in MPLS WG to define a new ACH Type.
GIM2>> I think that it is helpful to explicitly state the scope of the
document. What do you think?
<RG3> Ok to add.
GIM>> As noted earlier, I'm interested in SRv6 scenario. Does it add the whole
IP/UDP encapsulation or only SRH?
What is the benefit of using the inner IP Header as presented in Figure 4?
<RG2> Please see the reply at the top.
GIM2>> Thank you for clarifying this in your response. I'm looking forward to
the updated version of the draft to clearly state that in the document.
<RG> The inner IP header is useful in loopback mode, the outer header is
responsible for transmitting the test packet to the Session-Reflector. The
Session-Reflector will decap SRv6 tunnel header and forward the test packet
back to the Session-Sender according to the inner header.
GIM>> I have to admit that I'm confused by your explanation. As I understand
the loopback mode, a test packet is not decapsulated by the Session-Reflector.
The Session-Reflector, I assume, acts as a segment end-point but the SR policy
brings the test packet all the way back to the Session-Sender. If that is
how the loopback mode is expected to perform, I believe that my original
question stil stands.
<RG2> Please see the reply at the top.
<RG> We can update this in the next revision.
As for Figure 2, I propose changing the reference to Section 3 of RFC 8792
(Figure 2).
<RG> We are ok to update it in the next revision.
As for Figure 4, I have a question about the inner IP header in Figure 7.
<RG> It is not necessary. We can update in the next revision.
Can you point to the definition (or provide it) of the loopback mode?
<RG> In this (informational) draft, it is defined for SR networks in Section
4.2.3.
GIM>> What is observable by a Session-Reflector behavior when a Session-Sender
uses the loopback mode? As I understand it, there's none. The Session-Reflector
is not participating in a test in the loopback mode. If that is the case,
there's no interworking, interoperability and, as a result, nothing to
document.
<RG2> Right, the Session-Reflector is not participating in the loopback mode
test. This draft is defining the procedure on how to do loopback mode.
GIM2>> I think that the draft does not define SR encapsulation, whether SR-MPLS
or SRv6. Since the test packet is processed by the sender, there's no apparent
need in describing how the sender manipulates the packet before transmitting or
after receiving it. That is entirely implementation specific and not
observable from an outside the system.
<RG3> Please see reply above for BFD in loopback mode draft:
draft-ietf-bfd-unaffiliated-echo-02.txt, which is a standards-track document.
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?
<RG> In this (informational) draft, it is defined for SR networks in Section
4.2.3.
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?
<RG> It is destination UDP port in the Session-Sender test packet. We are ok to
update in the next revision.
GIM>> Could that be UDP port 862, as that is the one well-known port allocated
for Session-Sender transmitted test packets?
<RG2> This is the source port Session-Sender uses.
GIM2>> I think that is implentation-specific. For example, the Session-Sender
might use a special UDP port for self-addressed packets. Would you agree? That
is another reason, in my opinion, that there's no value in descrbing the
loopback mode in the document.
<RG3> Following text is added in the revised draft, which should cover the case.
“The STAMP Session-Sender sets the Destination UDP port to the UDP port it uses
to receive the reply STAMP test packets.”
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?
<RG> This informational draft explains various delay metrics in SR. It does not
change RFC 8762.
GIM>> Informational drafts, to the best of my understanding, document how
techniques defined in Standard-track RFCs can be used, can work together. This
document does introduce something that does not exists, is not described in RFC
8762 or RFC 8962.
<RG2> So it looks like the document should be Standards-track.
GIM2>> Not at all. My point is quite clear - the loopback mode, as described in
the draft, is not part of STAMP, does not change STAMP and is has no observable
from the outside behavior. Thus, it must be removed from the document as not
adding any value for a developer.
<RG3> Please see reply above for BFD in loopback mode draft:
draft-ietf-bfd-unaffiliated-echo-02.txt, which is a standards-track document.
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.
<RG> As described in Section 4.3 of [RFC8029], for IP address 127/8 case with
using TTL=1, it is to ensure that the test packet does not get incorrectly IP
routed to more than one IP hop and provide incorrect measurement.
GIM>> I believe that the use of loopback as destination address from rouing IP
packet. On the other hand, using TTL/Hop Count == 1 does not allow for GTSM
being used and, at least in theory, creates an attack vector for DoS. The
tunnel is a single hop for the encapsulated STAMP packet. Why not use GTSM?
<RG2> We are Ok to update in the next revision.
GIM2>> I am looking forward to reading the updated version.
The same question for the use case described in the second paragraph.
<RG> Please see above.
Two previous questions are also applicable to Section 4.4.2.
<RG> Please see above.
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?
<RG> Session-Sender has the knowledge about this mode. Session-Sender can set
the Session-Sender Sequence Number to Sequence Number to avoid any confusion.
We are ok to update it in the next revision.
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.
<RG> RFC 6374 has good discussions on the two loss measurement modes. We are ok
to update the text as follows to align with RFC 6374.
This method can be used for inferred packet loss measurement,
however, it provides only approximate view of the data packet loss.
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?
<RG> Yes, we can add following text in the next update:
Forwarding plane has various hashing functions available to forward
packets on specific ECMP paths. For SR-MPLS Policy, sweeping of
entropy label [RFC6790] values can be used in Session-Sender test packets
and Session-Reflector test packets
to take advantage of the hashing function in forwarding
plane to influence the ECMP path taken by them.
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?
<RG> As specified in [draft-ietf-ippm-stamp-srpm-00], the Destination Node
Address TLV is applicable to P2P SR Policy.
GIM>> Does that mean that any SR node can send STAMP test packet to the
Session-Reflector without the Destination Address TLV and receive the reflected
packet? Wouldn't that be a major security concern?
<RG2> This is addressed in Section 5, Security Section of
[draft-ietf-ippm-stamp-srpm-00]. We are adding following in the next update:
“The Security Considerations specified in [I-D.ietf-ippm-stamp-srpm]
are also equally applicable to the procedures defined in this document.”
GIM2>> I couldn't find the lack of the Destination Address TLV in the
Session-Sender test packet discussed in the Security Conciderations section of
ietf-ippm-stamp-srpm. Section 3 of that draft that defines the TLV notes that
it is optional. And that raises a valid question, if the Destination Address
TLV is not present, how the Session-Reflector can verify that it is indeed the
intended destination of the STAMP test packet?
<RG3> Ok to make the Destination TLV a MUST.
Thanks,
Rakesh
Thanks,
Rakesh
We can add the sentence in this draft as well in the next update.
Thanks,
Rakesh
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: gregory.mir...@ztetx.com
www.zte.com.cn
------------------Original Mail------------------
Sender: JamesGuichard
To: spring@ietf.org;
CC: spring-cha...@ietf.org;
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
spring@ietf.org
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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
