Re: [ippm] John Scudder's Discuss on draft-ietf-ippm-stamp-srpm-13: (with DISCUSS and COMMENT)

[Rakesh Gandhi <[e-mail]>]

Thank you John for the review.
I have incorporated your suggestions in the following version:

URL:
https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-srpm-15.txt
Html:
https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-srpm-15.html
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-ippm-stamp-srpm-15

Thanks for your help.

Regards,
Rakesh




On Thu, Jun 22, 2023 at 4:36 PM John Scudder <[e-mail]> wrote:

> [snipped extraneous stuff]
>
> > On Jun 22, 2023, at 2:40 PM, Rakesh Gandhi <[e-mail]>
> wrote:
> >
> > <RG> In the example, the DA in the STAMP Session-Sender test packet IPv4
> header (127.0.0.1) does not match the address of the Session-Reflector
> which is 1.1.1.2.
>
> We seem to be talking across each other. I guess maybe I am
> misunderstanding what you mean by “the Session-Reflector”. Surely, “the
> Session-Reflector” must mean a node functioning as a Session-Reflector?
> This is strongly implied by the name of the TLV, “Destination _Node_
> Address” (emphasis added). To repeat, any given IP node has many addresses
> (well, at least two, of which loopback will be one). So it doesn’t make
> sense to talk about “the” (singular) “address of the Session-Reflector”,
> and 127.0.0.1 most certainly is one address of the Session-Reflector node.
> Indeed, if it weren’t an address of every Session-Reflector node, the
> problem you illustrate wouldn’t exist.
>
> (In a previous version of this reply I went through a hair-splitting
> exercise where I tried to entertain the idea that “the Session-Reflector”
> means “a process on the node, which is bound to one and only one address”
> but that’s not a readily-supported interpretation, and it led me to a long
> and tortured chain of reasoning… which ended up at the same conclusion
> anyway.)
>
> If this is still unclear, it might be beneficial for us to schedule a
> short call to discuss further. But perhaps my OLD/NEW text below will help.
>
> > <RG> In the following example (without Destination Address TLV), if LSP
> or forwarding path is broken, the STAMP packet may be punted on an
> unintended Reflector node (let's say 1.1.1.9) and it will send a reply
> STAMP test packet. Such errors can not be easily detected.
> >
> > MPLS Header
> >      Label: 16001
> >      Label: 16002 [EOS]
> > IPv4 Header
> >      SA: 1.1.1.1
> >      DA: 127.0.0.1
> > UDP header
> > STAMP PAYLOAD
>
> Yes, I understand that. My point, again, is that your words say that
> 127.0.0.1 is not an address of the node. It ABSOLUTELY IS an address of
> essentially every IPv4 node in the universe.
>
> > <RG> Destination Address TLV carrying the intended Session-Reflector
> address of 1.1.1.2 helps detect this error. Using 1.1.1.2 then as the SA of
> the reply test packet is also good (instead of 127.0.0.1).
>
> I get that, too.
>
> > <RG> Does this use-case help? Will reply to the other comments below
> once we progress the above comment.
>
> I guess I will just jump ahead and outline some text that I *think* is
> right and that would address my concern.
>
> OLD:
>    The Session-Sender may need to transmit test packets to the Session-
>    Reflector with a destination address that is not matching the address
>    of the Session-Reflector e.g. when the STAMP test packet is
>    encapsulated by a tunneling protocol.  Examples are, STAMP test
>    packets encapsulated with an SR-MPLS Segment List and IPv4 header
>    containing destination IPv4 address from 127/8 range or STAMP test
>    packets encapsulated with outer IPv6 header and Segment Routing
>    Header (SRH) with inner IPv6 header containing IPv6 destination IPv6
>    address ::1/128.
>
>    In an ECMP environment, the hashing function in forwarding may decide
>    the outgoing path using the source address, destination address, UDP
>    ports, IPv6 flow-label, etc. from the packet.  Hence for IPv4, for
>    example, different values of IPv4 destination address from 127/8
>    range may be used in the IPv4 header of the STAMP test packets to
>    measure different ECMP paths.  For IPv6, for example, different
>    values of flow-label may be used in the IPv6 header of the STAMP test
>    packets to measure different ECMP paths.  In those cases, the STAMP
>    test packets may reach the node that is not the Session-Reflector for
>    this STAMP session in an error condition, and an un-intended node may
>    transmit reply test packet that can result in reporting of invalid
>    measurement metrics.
>
> NEW:
>    The Session-Sender may need to transmit test packets to the Session-
>    Reflector with a destination address that is not a routable (i.e.,
>    suitable for use as the Source Address of the reply test packet)
>    address of the Session-Reflector. This can be facilitated, for example,
>    by encapsulating the STAMP packet by a tunneling protocol, see <xref>
>    for a worked example.
>
> Then, if you wish, take the use case text I removed in my NEW version and
> use it as the basis of a Section 3.1 or Appendix A (the target of the xref
> I stubbed in above).
>
> It seems to me the following would be a good change as well:
>
> OLD:
>    The Destination Node Address TLV indicates an address of the intended
>    Session-Reflector node of the test packet.  The Destination Node
>    Address is also used to uniquely identify the STAMP session on the
>    Session-Reflector when the optional SSID is not sent.  If the
>    received Destination Node Address is one of the addresses of the
>    Session-Reflector, it SHOULD be used as the Source Address in the IP
>    header of the reply test packet.
>
> NEW:
>    The Destination Node Address TLV indicates an address of the intended
>    Session-Reflector node of the test packet.  If the received
>    Destination Node Address is one of the addresses of the
>    Session-Reflector, it SHOULD be used as the Source Address in the IP
>    header of the reply test packet.
>
>    If the Destination Node Address TLV is sent, the SSID TLV MUST also
>    be sent.
>
> This lets you get rid of the “is also used to” which muddies the water. I
> don’t insist on this, it’s just a suggestion, the old way isn’t broken,
> just weird (to me).
>
> —John
>