[mpls] draft-ietf-mpls-stamp-pw-07 telechat Tsvart review

[Vidhi Goel via Datatracker <[e-mail]>]

Document: draft-ietf-mpls-stamp-pw
Title: Encapsulation of Simple Two-Way Active Measurement Protocol for LSPs and
Pseudowires in MPLS Networks Reviewer: Vidhi Goel Review result: Ready with
Issues

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[e-mail] if you reply to or forward this review.

This document specifies how STAMP [RFC8762] [RFC8972] test packets are
encapsulated for MPLS LSPs and PWs, in two formats: Format-1 with an IP/UDP
header over the existing IPv4/IPv6 G-ACh types, and Format-2 with no IP/UDP
header over two new G-ACh types. The document is clearly written and the
figures and the use case table are helpful.

>From a transport perspective my main concern is with Format-2: removing the
IP/UDP header also removes the 4-tuple that RFC 8762/RFC 8972 rely on for
session identification, and removes the UDP-based guidance on test traffic
load that this document inherits by reference. Neither is replaced by
anything in this document. I have listed that and a few related items below.
I think these are addressable with text, so I would call this ready with
issues.

ISSUES:

1. Session identification in Format-2 (Sections 3.1, 4.2, 5.2)

Section 3 of [RFC8972] says: "A STAMP Session is identified by the 4-tuple
(source and destination IP addresses, source and destination UDP port
numbers)", and further: "An implementation of the STAMP Session-Reflector
that supports this specification MUST identify a STAMP Session using the SSID
in combination with elements of the usual 4-tuple for the session ... A STAMP
Session-Reflector MUST discard non-matching STAMP test packets."

In Format-2 there is no 4-tuple at all, so this normative requirement cannot
be met as written, and the document does not say what replaces it. Section
3.1 only explains how Session-Sender packets are told apart from
Session-Reflector packets (by channel type), not how two concurrent sessions
between the same pair of PEs over the same LSP or PW are told apart, or what
"non-matching" means for a Format-2 packet.

I think the document needs to state explicitly what identifies a STAMP
session in Format-2 - presumably the LSP/PW context (incoming label) plus the
SSID [RFC8972] - and, if the SSID is the only per-session discriminator, that
the SSID MUST be present and non-zero in Format-2 test packets. Note that the
SSID is only a MAY in Section 3 of [RFC8972], so this needs to be said here.
The payload references in Figures 3 and 5 already point at Figures 1-4 of
Section 3 of [RFC8972], i.e., the SSID-bearing formats, but the running text
never says so, and the SSID appears nowhere in the document except in Table 1
and in the Security Considerations.

Relatedly, in Format-1 the reflected packet is not the mirror of the received
one: per Figure 4, the Session-Reflector chooses both its source address and
its source port, and the Session-Sender's destination address may have been
from 127/8 or 100:0:0:1::/64. So the Session-Sender cannot associate a
received reflected packet with a test session using the 4-tuple either. It
would help to say how the Session-Sender is expected to do this association
(LSP/PW context plus SSID and Session-Sender Sequence Number?), or to require
the Session-Reflector to reuse the received destination port as its source
port so the 4-tuple is mirrored.

2. No congestion or test-load considerations for the PW / Format-2 case
   (Sections 6, 7)

Section 7 of [RFC8762] requires that "The load of the STAMP-Test packets
offered to a network MUST be carefully estimated" and points at Section 3.1.5
of [RFC8085] for UDP-based load guidance. This document inherits that by
reference in Section 7, which is fine for Format-1, but Format-2 test packets
are not UDP at all, and this document nowhere discusses test packet rate or
bandwidth.

More specifically, this document defines a new application of the VCCV
Control Channel for PWs, and Section 9 ("Congestion Considerations") of
[RFC5085] says "VCCV applications (i.e., Connectivity Verification (CV)
Types) MUST consider congestion and bandwidth usage implications and provide
details on bandwidth or packet frequency management", with a recommended
limit of 5% of the PW bit rate for the ICMP and MPLS LSP Ping applications.
Section 7 of this document cites Section 10 of [RFC5085] for message
throttling, but Section 9 of [RFC5085] is not referenced anywhere.

This matters most for the constant bit rate services this document explicitly
targets: PLE [RFC9801] and TDM over IP [RFC5087] PWs. Because the test
packets deliberately use the same label stack and the same forwarding
treatment as the client traffic, the test load is taken from inside the PW's
allocation, which is the opposite of the assumption in Section 9 of [RFC5085]
("The bandwidth required for the VCCV channel is taken outside any allocation
for PW data traffic"). Section 6 should discuss the rate at which test
packets are transmitted, that it is accounted for when the PW bandwidth is
provisioned, and that the Section 9 of [RFC5085] guidance applies to both
formats. Please also state whether any bound applies to the reflected
direction, given that the Session-Reflector replies to every received test
packet and the reverse LSP/PW may have less capacity than the forward one.

[RFC9780], which this document already cites, is a useful precedent for the
amount of text I am asking for: its Section 6 asks the operator to consider
the rate of Control packet generation and the extra traffic it produces, and
even the packet size difference between IP/UDP and G-ACh encapsulation.

3. UDP checksum handling is unspecified for Format-1 (Sections 4.1, 5.1)

Neither [RFC8762] nor this document says anything about the UDP checksum, and
in this encapsulation the question is sharper than in native STAMP: the
packet is delivered by G-ACh channel type rather than by IP forwarding, and
the destination address may be a 127/8 or 100:0:0:1::/64 address that never
appears on the wire outside the tunnel, so an implementation may be tempted
to skip the checksum. Please state whether the Session-Sender and
Session-Reflector MUST compute the UDP checksum and whether the receiver MUST
verify it. For IPv6 in particular, a zero UDP checksum is not permitted by
default (Section 8.1 of [RFC8200]: "IPv6 receivers must discard UDP packets
containing a zero checksum"), and the tunnel-encapsulation exception there
requires following [RFC6936]. If zero-checksum operation is intended for this
encapsulation, that needs to be stated and justified explicitly.

Two things make this more than a formality: in unauthenticated mode there is
no other integrity check on the test packet, and Section 7 relies on
sanity checks such as "T2 is later than T1" to catch bad packets, which a
corrupted timestamp can easily pass; and implementations that write the
transmit timestamp in hardware late in the transmit path have to update the
checksum accordingly.

4. Sender source port should be constrained in Format-1 (Sections 3, 3.1)

Section 3.1 says the packets are distinguished by destination UDP port, and
Figure 4 shows the reflected packet's destination port set to the
Session-Sender's source port. Since [RFC8762] leaves the source port free, a
Session-Sender that happens to choose the session's destination port (862 or
the configured port) as its source port makes the two directions
indistinguishable, and a reflected packet arriving at either node would be
parsed as a Session-Sender packet and reflected again. Please add a
requirement that the Session-Sender MUST NOT use the session's destination
UDP port as its source UDP port, or specify some other unambiguous rule.

5. No packet size / MTU considerations (Section 6)

The document does not discuss test packet size. Format-1 adds 4 octets of
G-ACh and Format-2 adds 4 octets of G-ACh plus, where GAL is used, another 4
octets of label stack, relative to the data traffic being measured, and
[RFC8972] allows sizeable padding, with the default symmetric sizing meaning
the reflected packet matches the size of the received one. A test packet that
exceeds the LSP or PW MTU will be dropped rather than fragmented - no transit
LSR will look inside a G-ACh to fragment the payload - so it shows up as
loss, i.e., as a measurement result rather than as a configuration error, and
the same applies independently to the reverse direction for the reflected
packet. A short paragraph in Section 6 noting that the test packet size
including this overhead has to fit the MTU in both directions, and that
Format-1 test packets should be sized to avoid IP fragmentation, would be
useful. Section 6 of [RFC9780] does something similar in noting the size
difference between the IP/UDP and G-ACh encapsulations.

6. Interaction between punt-path policing and loss measurement (Section 7)

Section 7 correctly points at the message throttling of Section 10 of
[RFC5085], and the TTL-expiry method of Section 3.2 means every test packet
is punted to the control plane at both ends. Worth noting explicitly, as
Section 9 of [RFC5085] does ("rate-limiting them can be harmful as it could
translate to incorrectly declaring connectivity failures"), that policing on
the punt path is indistinguishable from network loss to STAMP and will be
reported as such. Section 5 of [RFC9780] makes a similar recommendation for a
rate limiter on the packets passed to the control plane for processing. This
is really a note for Section 6 rather than a change to Section 7.

7. Broken-LSP considerations only cover Session-Sender packets (Section 6.1)

Section 6.1 and the filtering guidance address Session-Sender packets and
rely on a non-routable destination address. The reflected packet always
carries a routable destination address, namely the Session-Sender's source
address (Figure 4), so if the reverse LSP or PW is broken it can be
IP-forwarded off-path or out of the domain, and destination-address-based
filtering at the domain edge does not help there. Please say whether the same
considerations and filtering are expected for the reflected direction, and
what the Session-Reflector does when no reverse-direction LSP/PW context
exists at all.

NITS:

Section 3: "The base STAMP test packets can be encapsulated using an IP/UDP
header and may use destination UDP port 862 [RFC8762]." Section 4.1 of
[RFC8762] is stronger than "may use": the Session-Sender MUST use port 862 as
the default destination port. Suggest aligning the wording, e.g. "uses
destination UDP port 862 as the default destination port, as specified in
Section 4.1 of [RFC8762]".

Section 4.1, Figure 2: "Destination Port = User-configured Destination Port
or 862". Section 4.1 of [RFC8762] requires that, before using a number from
the User Ports range, "the possible impact on the network MUST be carefully
studied and agreed on by all users of the network domain where the test has
been planned". A pointer to that would be helpful here or in Section 6.

Section 1.1: the bulleted requirements use BCP 14 keywords for properties of
the solution ("The G-ACh MUST support STAMP test packets with an IP/UDP
header") rather than for implementation behaviour, and "Session-Reflector
test packets MAY follow the reverse underlay path" reads oddly as a
requirement. Consider non-normative phrasing ("needs to") in this section,
since the normative behaviour is specified in Sections 3 to 5 anyway.

Section 4.1: "An IPv6 address from the Dummy IPv6 Prefix address
100:0:0:1::/64 block [RFC9780] [IANA-IPv6-REG]" - "Prefix address ... block"
is redundant; suggest "from the Dummy IPv6 Prefix 100:0:0:1::/64". Also, the
IANA registry entry for this block records "Destination: False", which looks
at first glance like it contradicts the use here; Section 1 of [RFC9780]
explains that this is deliberate, i.e., a source-only address is used as the
destination precisely to generate an exception. Since this document depends on
that reasoning, [RFC9780] arguably belongs in the normative references, and a
half-sentence pointing at it would save the next reader the same detour.

Section 5.2, Figure 5 caption: "without IP/ UDP Header" - extra space before
UDP.

Section 6: "An operator may wish to only add MPLS encapsulation in STAMP test
packets destined to addresses within the MPLS administrative domain based on
some local policy." Suggest rewording, e.g. "Based on local policy, an
operator may add the MPLS encapsulation only for STAMP test packets destined
to addresses within the MPLS administrative domain."

Thanks,
Vidhi