[Tsv-art] Re: [mpls] draft-ietf-mpls-stamp-pw-07 telechat Tsvart review

[Rakesh Gandhi <[e-mail]>]

Hi Vidhi,

Thank you for the discussions and your review/suggested text.

We have posted rev-17 that addresses your comments.

https://datatracker.ietf.org/doc/draft-ietf-mpls-stamp-pw/

Please see replies inline with <RG>..


On Wed, Sep 2, 2026 at 12:12 AM Vidhi Goel <[e-mail]> wrote:

> Hi Rakesh,
>
>   Thanks for the quick turnaround. Note I have read rev-16, not rev-12, so
> the sections have moved: UDP checksum is now 4.4 (was 3.2.3), session
> identification 3.3 (was 3.1.1), operational text 7.3-7.6 (was 6.1-6.4). I
> use rev-16 numbering below.
>
>   Items 2 and 3 and the minor point are closed - RFC 8085 is Normative,
> the disputed congestion bullet is gone, and Section 3.3 now covers both
> Session-Reflector modes. Thanks.
>


<RG> Thanks for confirming.



>
>   Item 1 is not yet resolved. Dropping [RFC7510] and mapping Section 5 of
> [RFC6936] directly is the right move, and requirements 1, 3 and 4 read
> fine. Requirement 5 does not:
>
>     "A transported protocol with a non-tunnel payload ... MUST have a CRC
> or other mechanism for checking packet integrity"
>

<RG> Revised the text to highlight this point.


>
>   A STAMP test packet is a non-tunnel payload, so this MUST applies here.
> Section 4.4 answers it with "STAMP test packets in the authentication mode
> ... are RECOMMENDED in networks where packet integrity is required", which
> works for requirement 2 (itself a RECOMMENDED in [RFC6936]) but cannot
> discharge a MUST. The condition is also circular, since requirement 5 is
> what establishes that integrity is required. As written, Section 4.4 still
> permits IPv6 + zero checksum + unauthenticated mode, i.e. a test packet
> with no integrity protection.
>
>   Note also that the enabling text offers a checksum complement [RFC7820]
> as an alternative to zero-checksum, and a complement yields a correct
> non-zero checksum - so it cannot be the mechanism satisfying requirement 5
> once the checksum is zero. For IPv6 zero-checksum, the authenticated mode
> is the only integrity mechanism available.
>
>   Three ways to close it, in my order of preference:
>
>   (A) Permit IPv6 zero-checksum only in the authenticated mode: change
> item 2 of the [RFC6936] list to "STAMP test packets that use the UDP
> zero-checksum mode for IPv6 MUST use the authenticated mode defined in
> Figures 3 and 4 of [RFC8972]", and add "For IPv6 STAMP test packets that do
> not use the authenticated mode, the UDP checksum MUST be computed and
> verified." Worth checking whether this leaves a real deployment case: a
> node whose hardware cannot recompute a UDP checksum after stamping a
> timestamp generally cannot compute an HMAC over the same packet either. If
> that set is empty, (B) is cleaner.
>
>   (B) Drop the exception for IPv6 and keep it for IPv4 only, stating that
> requirement 5 cannot be met in the unauthenticated mode and that a checksum
> complement is used where the checksum cannot be recomputed.
>
>   (C) Keep unauthenticated IPv6 zero-checksum, but drop the requirement 5
> claim and say plainly that it is not met and why the residual risk is
> acceptable within a single administrative domain. Defensible as a
> documented deviation, but it needs AD agreement, so it is the slowest path.
>

<RG> Yes, this (C) is the desired option for this implementation.


>
>   Either way, please add a signpost to Section 8.1 of [RFC8200] at the top
> of the IPv6 bullet - that STAMP test packets are the innermost payload
> rather than a tunnel encapsulation, so [RFC6936] is applied directly.
> Without it the reader sees an unexplained conflict. I would also reconsider
> the requirement 3 mapping: requirement 3 is about tunnels relying on the
> inner packet's integrity checks, and there is no inner packet here.
>

<RG> Added this.


>
>   Four smaller things in Section 4.4:
>
>   1. Items 4 and 5 of the [RFC8085] list both cite "the fourth requirement
> in Section 3.4.1". One is wrong.
>
>   2. The opening "a non-zero UDP checksum SHOULD be used by default"
> conflicts with item 1's "MUST be the default configuration" for IPv6.
>
>   3. The second requirement in Section 3.4.1 of [RFC8085] requires
> compliance with Section 4 of [RFC6936] as well as Section 5; only Section 5
> is mapped.
>
>   4. Please state that a receiver MUST verify a non-zero UDP checksum and
> discard on failure, rather than treating it as a measurement result.
>

<RG> Fixed/added these things.


>
>   And two leftovers from the nits:
>
>   - Section 6.2, Figure 5 caption still reads "without IP/ UDP Header".
> Marked fixed at rev-08 but present in -07, -09, -12 and -16, so I think the
> edit was missed.
>

<RG> Seems to be some tooling issue. I see the source text ok.


>
>   - Section 3.1 attaches the "impact on the network MUST be carefully
> studied" requirement to the source port, citing Section 4.1 of [RFC8762].
> That section says nothing about source ports; the requirement governs
> non-default destination ports. Suggest stating it where the destination
> port is specified, and leaving source-port guidance to [RFC6056] and
> [RFC6335].
>

<RG> Removed.


>
>   None of this needs to hold up the telechat - everything from my original
> review is addressed and Sections 7.3-7.6 read well. I would still like
> requirement 5 resolved before publication, and I am happy to turn around
> updated text quickly.
>

<RG> Appreciate this.

Thanks,
Rakesh (for authors)





>
>   Thanks,
>   Vidhi
>
> On Aug 28, 2026, at 3:11 PM, Rakesh Gandhi <[e-mail]> wrote:
>
> Hi Vidhi,
>
> Thank you for verifying the updates and your suggestions.
>
> We have posted rev-12 that addresses your further comments.
>
>   https://datatracker.ietf.org/doc/draft-ietf-mpls-stamp-pw/
>
> Please see replies inline with <RG>...
>
>
>
> On Thu, Aug 27, 2026 at 8:48 PM Vidhi Goel <[e-mail]> wrote:
>
>> Hi Rakesh, Gorry,
>>
>> Thanks for the quick turnaround, and thanks Gorry for the nudge.
>>
>> All seven issues from my review are addressed, and in a
>> couple of places the text goes further than I asked for. Specifically:
>>
>> - Issue 1 (session identification without a 4-tuple): the new Section
>> 3.1.1
>>   plus the requirement in Section 3 that the SSID be non-zero and be
>> carried
>>   in both directions resolves this cleanly for Format-2.
>> - Issue 2 (congestion / test load): Section 6.2 now covers provisioning,
>>   points at Section 3.1.5 of RFC 8085 for Format-1 and Section 9 of RFC
>> 5085
>>   for Format-2, and picks up the 5% guidance. Good.
>> - Issue 3 (UDP checksum): Section 3.2.3 covers the ground I asked about,
>> with
>>   one loose end that I have written up as item 1 below.
>> - Issue 4 (source port): the bullets in Section 3 cover this.
>> - Issue 5 (MTU): Section 6.3 is what I was after, and the octet counts are
>>   right.
>> - Issue 6 (punt-path policing vs. loss measurement): Section 6.1 says it
>>   explicitly, which is what I wanted.
>> - Issue 7 (reflected packets on a broken reverse path): the last
>> paragraph of
>>   Section 6.4 covers it.
>>
>
>
> <RG> Thanks for confirming these 7 issues as addressed.
>
>
>> The nits are all taken care of too.
>>
>
> <RG> Great.
>
>
>>
>> So from a transport perspective I would now call this ready, and I do not
>> think any of the following needs to hold up the telechat, though I would
>> like
>> to see the first item resolved before publication.
>>
>
> <RG> Great, thanks!
>
>
>>
>> 1. Section 3.2.3, IPv6 zero-checksum basis
>>
>> This is the one I would like to see changed. The two references used to
>> justify a zero UDP checksum for IPv6 are both scoped to protocols that use
>> UDP as the *outer* tunnel encapsulation: RFC 7510 is MPLS-in-UDP, and
>> Section 3.4.1 of RFC 8085 is the guidance for "tunnel protocols using
>> UDP".
>> In this document the layering is the other way round - the UDP datagram is
>> the innermost payload, carried inside MPLS - so the exception in Section
>> 8.1
>> of RFC 8200 ("protocols that use UDP as a tunnel encapsulation") does not
>> obviously apply, and RFC 6936, which is the applicability statement that
>> Section 8.1 of RFC 8200 points to, is not referenced anywhere in the
>> document.
>>
>> Either of these would work for me:
>>
>> (a) Drop the IPv6 zero-checksum allowance and rely on the checksum
>>     complement [RFC7820] or the authenticated mode, which the section
>>     already mentions; or
>>
>> (b) Keep it, but justify it against RFC 6936 rather than RFC 7510 - i.e.,
>>     cite RFC 6936 and state which of its Section 5 requirements this
>>     encapsulation meets. Some you already satisfy and say elsewhere in
>> the
>>     document: requirement 1 (enabled only for a specific port or port
>> range
>>     at both endpoints), requirement 4 (corruption must not accumulate
>>     incorrect state - your "MUST NOT make assumptions regarding the
>>     correctness of received test packets" covers this), and the
>>     single-administrative-domain restriction in Section 7.
>>
>
> <RG> We took this approach of (b) in the latest updates.
>
>
>>
>> If you take route (b), please look closely at requirement 5 of Section 5
>> of
>> RFC 6936: "A transported protocol with a non-tunnel payload or one that
>> encapsulates non-IP packets MUST have a CRC or other mechanism for
>> checking
>> packet integrity". A STAMP test packet is a non-tunnel payload, and in
>> unauthenticated mode there is no such mechanism, so I think that
>> requirement
>> points at permitting the IPv6 zero checksum only where the checksum
>> complement [RFC7820] or the authenticated mode is in use - which is close
>> to
>> route (a) in practice, and is also the case where the "local processor
>> cannot
>> recompute the UDP checksum" motivation no longer applies. Restricting the
>> zero-checksum exception to IPv4 would be another way out.
>>
>> I have no objection in principle to zero-checksum operation being
>> permitted
>> here; it is the citation trail and the unauthenticated-mode case that I
>> would
>> like to see resolved, since an implementer reading Section 3.2.3 against
>> Section 8.1 of RFC 8200 will otherwise see a conflict.
>>
>
> <RG> Hope the latest updates address this concern.
>
>
>>
>> 2. RFC 8085 reference classification
>>
>> Section 3.2.3 now depends on RFC 8085 normatively ("MUST behave correctly
>> when a UDP datagram is corrupted as described in [RFC8085]", and the
>> requirements quoted from its Section 3.4.1), but RFC 8085 is still an
>> Informative reference. It should move to Normative, alongside RFC 768,
>> RFC 6056 and RFC 7510.
>>
>
> <RG> Fixed.
>
>
>>
>> 3. Section 6.2, last bullet
>>
>>   "Any rate limit applied to the Session-Sender test packets will prevent
>>    the corresponding reflected test packet traffic from exceeding the
>>    reverse direction bandwidth capacity."
>>
>> That only holds if the reverse capacity is at least the forward rate
>> limit,
>> which the third bullet of the same list says may not be the case. Suggest
>> qualifying it, e.g. "... provided the rate limit is set with respect to
>> the
>> lower of the two directions' capacities", or simply dropping the bullet
>> since the preceding two already make the point.
>>
>
> <RG> Removed.
>
>
>>
>> Minor: Section 3.1.1 gives the identification rules for the Stateful
>> Session-Reflector only. Since session identification is separate from test
>> state, and RFC 8972 requires a conforming Session-Reflector to discard
>> non-matching test packets either way, it would help to either cover the
>> stateless mode too or say why the rules only apply to the stateful one. A
>> pointer to Section 4.2 of RFC 8762, where the two modes are defined, would
>> also help the reader.
>>
>
> <RG> for the Stateful is removed.
>
> Thanks,
> Rakesh (for authors)
>
>
>
>> Happy to look at updated text if you post another revision.
>>
>> Thanks,
>> Vidhi
>>
>>
>> On Aug 25, 2026, at 1:55 AM, Gorry Fairhurst <[e-mail]>
>> wrote:
>>
>> On 25/08/2026 00:15, Rakesh Gandhi wrote:
>>
>> Hi Vidhi,
>>
>> FYI:
>> We have posted rev-09 that further refines the previous updates to
>> address your comments.
>>
>>    - https://datatracker.ietf.org/doc/draft-ietf-mpls-stamp-pw/
>>
>> P.S. Thank you Gorry for your review/suggestions.
>>
>> Thanks,
>> Rakesh (for authors)
>>
>> Vidhi & Rakesh,
>>
>> This new revision is much more informative (and improved) from a
>> transport perspective. If you see anything that is notable or can be
>> further improved do continue.
>>
>> Vidhi, if you find time, could you have a quick check to see if the new
>> sections address the issues relating to stamp or they may need further
>> refinement?
>>
>> I will schedule time to read this again next week and plan to update my
>> position before the telechat meeting on 2026-09-0.
>>
>> Best wishes,
>>
>> Gorry
>>
>>
>>
>>
>>
>> On Fri, Aug 21, 2026 at 10:52 AM Rakesh Gandhi <[e-mail]>
>> wrote:
>>
>>> Hi Vidhi,
>>>
>>> Thank you for the thorough review of the draft.
>>>
>>> We have posted rev-8 with the suggested updates.
>>>
>>> URL:
>>> https://www.ietf.org/archive/id/draft-ietf-mpls-stamp-pw-08.txt
>>> HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-mpls-stamp-pw
>>> Diff:
>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-mpls-stamp-pw-08
>>>
>>> Please see replies inline with <RG>...
>>>
>>>
>>> On Wed, Aug 19, 2026 at 5:13 PM Vidhi Goel via Datatracker <
>>> [e-mail]> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> <RG> Added new Section 3.1.1 for this.
>>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>>
>>> <RG> Added new Section 6.2 for this.
>>>
>>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> <RG> Added new Section 3.2.3 for this.
>>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>>
>>> <RG> Updated Section 3 to add this.
>>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> <RG> Added new Section 6.3 for this.
>>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> <RG> Added new Section 6.1 for this.
>>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> <RG> Updated Section 7 to add this.
>>>
>>>
>>>>
>>>> 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]".
>>>>
>>>
>>> <RG> Fixed.
>>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> <RG> Fixed.
>>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> <RG> Fixed.
>>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> <RG> Fixed.
>>>
>>>
>>>>
>>>> Section 5.2, Figure 5 caption: "without IP/ UDP Header" - extra space
>>>> before
>>>> UDP.
>>>>
>>>
>>> <RG> Fixed.
>>>
>>>
>>>>
>>>> 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."
>>>>
>>>
>>> <RG> Fixed.
>>>
>>> Thanks,
>>> Rakesh (for authors)
>>>
>>>
>>>
>>>
>>>>
>>>> Thanks,
>>>> Vidhi
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> mpls mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>
>> _______________________________________________
>> Tsv-art mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>>
>> _______________________________________________
>> Tsv-art mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>>
>> _______________________________________________
> Tsv-art mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
>