Re: [spring] WG Adoption Call for https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

gregory.mirsky@ztetx.com Fri, 18 June 2021 02:57 UTC

Return-Path: <gregory.mirsky@ztetx.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C483A38E5; Thu, 17 Jun 2021 19:57:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pd1v2aSSsKdF; Thu, 17 Jun 2021 19:57:14 -0700 (PDT)
Received: from mxus.zteusa.com (mxus.zteusa.com [4.14.134.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE3AF3A38E4; Thu, 17 Jun 2021 19:57:12 -0700 (PDT)
Received: from mse-us.zte.com.cn (unknown [10.36.11.29]) by Forcepoint Email with ESMTPS id 2F291450CDDA11EE9411; Fri, 18 Jun 2021 10:57:10 +0800 (CST)
Received: from mgapp02.zte.com.cn ([10.36.9.143]) by mse-us.zte.com.cn with SMTP id 15I2v6Ci000924; Fri, 18 Jun 2021 10:57:06 +0800 (GMT-8) (envelope-from gregory.mirsky@ztetx.com)
Received: from mapi (mgapp01[null]) by mapi (Zmail) with MAPI id mid81; Fri, 18 Jun 2021 10:57:06 +0800 (CST)
Date: Fri, 18 Jun 2021 10:57:06 +0800
X-Zmail-TransId: 2af960cc0b82941b1296
X-Mailer: Zmail v1.0
Message-ID: <202106181057065902334@zte.com.cn>
In-Reply-To: <BL3PR11MB57310FB0DD8E1B0E932079CDBF0F9@BL3PR11MB5731.namprd11.prod.outlook.com>
References: MN2PR13MB42066A2630749C71112DA3A9C2389@MN2PR13MB4206.namprd13.prod.outlook.com, 202106111518474556174@zte.com.cn, BL3PR11MB57310FB0DD8E1B0E932079CDBF0F9@BL3PR11MB5731.namprd11.prod.outlook.com
Mime-Version: 1.0
From: gregory.mirsky@ztetx.com
To: rgandhi=40cisco.com@dmarc.ietf.org
Cc: jguichar@futurewei.com, spring@ietf.org, spring-chairs@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-us.zte.com.cn 15I2v6Ci000924
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/RDwbqb4XFKM9ZA0rQNFYtudslXE>
Subject: Re: [spring] WG Adoption Call for https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jun 2021 02:57:20 -0000

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.mirsky@ztetx.com
www.zte.com.cn
------------------Original Mail------------------
Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;jguichar@futurewei.com;
CC: spring@ietf.org;spring-chairs@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-bounces@ietf.org> on behalf of gregory.mirsky@ztetx.com <gregory.mirsky@ztetx.com>
Date: Friday, June 11, 2021 at 3:19 AM
To: jguichar@futurewei.com <jguichar@futurewei.com>
Cc: spring@ietf.org <spring@ietf.org>, spring-chairs@ietf.org <spring-chairs@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?

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.
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?
<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.
<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.
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?

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.

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?

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?
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.mirsky@ztetx.com
www.zte.com.cn
------------------Original Mail------------------
Sender: JamesGuichard
To: spring@ietf.org;
CC: spring-chairs@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