[ippm] Re: I-D Action: draft-ietf-ippm-asymmetrical-pkts-02.txt / Mcast

[Greg Mirsky <[e-mail]>]

Hi Rudiger,
thank you for your thoughtful comments and questions. Please find my notes
below tagged GIM2>>.

Regards,
Greg

On Mon, Nov 25, 2024 at 1:13 AM <[e-mail]> wrote:

> Hi Greg,
>
>
>
> I’ve decided to separate the Mcast discussion from security. I’d first
> like to better understand intended operation. See [RG 2].
>
>
>
> Regards,
>
>
>
> Ruediger
>
>
>
> 3.2. Active Performance Measurement in Multicast Environment
>
> “The Session-Reflector MUST use the source IP address of the received
> STAMP test packet as the destination IP address of the reflected test
> packet, and MUST use one of the IP addresses associated with the node as
> the source IP address for that packet.”
>
> [RG] please clarify text:  ..... associated with the node hosting the
> Session-Reflector as the source IP address for that packet.
>
>
>
> [RG]: If I understand the text correctly, a single Session-Sender packet
> is intended to be sent to an Mcast tree. Are all receivers expected to be
> STAMP aware?
>
> If not, please discuss operation. I also think, that some of the
> discussion of this section should be repeated within or copied to the
> security section.
>
> GIM>> I think that the expectation of STAMP capability on the remote
> endpoint of the STAMP test is the same in p2mp as in p2p case. As such, the
> system that hosts the STAMP Session-Sender might have information about the
> STAMP-capable leaves of the multicast tree or it may not. I think that that
> is outside of the scope of STAMP operation.
>
>
>
> [RG 2] My Mcast know is insufficient for a constructive discussion. I’d be
> happy, if this section passed a review from a person with sufficient Mcast
> expertise.
>
>
>
> A)
>
> [RG 2] I’ve asked some Telekom Mcast experts for feedback.
>
> [RG 2] If Layer 3 / Standard IP Mcast is addressed by the draft, Sender
> and Reflector have to be part for the same Mcast tree. I miss text stating,
> that this join to an Mcast tree is assumed or required to exist,
> respectively, and a reference describing, how that is done (protocol-
> options and static or dynamic join...).
>
GIM2>> Thank you for pointing that out. You are correct, it is implicitly
assumed that the Session-Sender is the root and expected
Session-Reflctors are leaves of the same multicast distribution tree. How
that tree is constructed is outside the scope of this specification. I'll
add the following text in Section 3.2:
NEW TEXT:
   For performance measurements using STAMP in a multicast environment,
   a Session-Sender is expected to be the root and Session-Reflectors
   leaves of the same multicast distribution tree.  The mechanism of
   constructing the multicast tree is outside the scope of this
   document.

[RG 2] Prior to a STAMP test creating significant MCAST and reflected
> loads, a test with conservative chosen load parametrization to check
> whether there’s an MCAST forwarding/control plane linking STAMP sender and
> reflector seems useful.
>
GIM2>> I agree that that would be a good operational step. Also, strict
control of the identity of a allowed Session-Senders by a
Session-Reflector, e.g., using ACLs, as suggested in Security
Considerations section of RFC 8545
<https://datatracker.ietf.org/doc/rfc8545/> (that is applicable to this
draft by the reference in RFC 8762
<https://datatracker.ietf.org/doc/rfc8762/>).

> [RG 2] My colleague failed to understand, how to operate the Layer 2 based
> Reflector control/selective filter. He’s asked how to operate, if the
> Reflector is a router and MCAST is linked to a loopback address (which
> isn’t linked to a MAC address – how would that work). Please note, that my
> colleague works on network operation.
>
GIM2>> As I understand it, in some environments, MAC addresses of network
devices may be centrally managed or have a common part. If that is the
case, an operator may use the Layer 2 filter to limit the scope of the
STAMP test.

>
>
> B)
>
> [RG 2] I’m also not sure, whether the draft recommends or limits the
> number and length of the reflected packets. My perception of a safer and
> useful operation was to limit reflection to a single packet per every
> received STAMP Sender packet from each downstream STAMP-reflector Mcast
> receiver, and it should be of a minimised length (which is discussed by the
> draft, I think).
>
GIM2>> I think that an implementation may be a better mechanism for such
limits. And I'll refer to my note above about using ACLs on a
Session-Reflector to control access of Session-Senders to STAMP capability
of that node.

>
>
> C)
>
> [RG 2] Just to make sure I understand the intent of the specification
> correctly:
>
>
>
> [RG 2] The Mcast case is limited to operation from STAMP-Sender upstream
> in a Mcast-Tree and the STAMP-Reflector always and only downstream of that
> sender in the Multicast tree?
>
> [RG 2] In case, the text says so explicitly, I apologize for having
> overread. In case not, please add a statement.
>
GIM2>> Your understanding is correct. A Session-Sender transmits STAMP test
packets over the multicast tree. AFAIK, multicast is usually operates over
unidirectional trees. Thus, a Session-Reflector will transmit reflector
packets over the shortest path, unless instructed otherwise, e.g.,
using Reflected Test Packet Control TLV.

>
>
>
>
>
>
>