[IPFIX] Options Templates, Templates, and related Data Sets sent in separate transport sessions

Garri Djavadyan <g.djavadyan@gmail.com> Sat, 03 February 2024 14:38 UTC

Return-Path: <g.djavadyan@gmail.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9910AC1654EF for <ipfix@ietfa.amsl.com>; Sat, 3 Feb 2024 06:38:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Orq6-h2KZ9e1 for <ipfix@ietfa.amsl.com>; Sat, 3 Feb 2024 06:38:51 -0800 (PST)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD4DC151553 for <ipfix@ietf.org>; Sat, 3 Feb 2024 06:38:51 -0800 (PST)
Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a30e445602cso863700066b.0 for <ipfix@ietf.org>; Sat, 03 Feb 2024 06:38:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706971129; x=1707575929; darn=ietf.org; h=mime-version:user-agent:content-transfer-encoding:autocrypt:date:to :from:subject:message-id:from:to:cc:subject:date:message-id:reply-to; bh=h6v9DlMe1uP7hSddcl6nh+TvqYwr9BN4qiYSkZKSJZ0=; b=MmoHUoi0CS8R0cB7H6DUGxh4NW7yqmGvnOn6oPTw6ziW7B0h0RWu1HyIemSrNxRAJS Y3QWkUvzs/JKN8JmKO8CcepEomVSs8g7rUjf+qGMKdjcYASac4puCAlngdd7O0wFMs/i Wa20vZYuxhwIcW7zKHtn1MN63elXqxjyljvce67j19AleMyYyIV86+7gPHW5MnjAs2nh Gwru+mqbGDOfVC+e5jf/6VRC2eiFv/f1k0GWrWhl9wEFZqiweC5EIb9s2iiIx8FIRqUW VACmYC85zOjKaKdnDzo2igLj6UvBLzueCfhmBadnsTVLeQVvsQs2MEpgZrb9srKr+3PZ UjyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706971129; x=1707575929; h=mime-version:user-agent:content-transfer-encoding:autocrypt:date:to :from:subject:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=h6v9DlMe1uP7hSddcl6nh+TvqYwr9BN4qiYSkZKSJZ0=; b=UTKJE6LytKpgJk+QmNkKDXb9nFuNf4AcKJ3ClX0ogDuGGM/4XYIbcHR2YK02suA1VO TIlRzMo1Xnuqz71ZLq2E7zl1c0ZmRbRkn7rUL8lNFRknO5BtVsVykmDM5DgZ1U8wkPeE MhdxNgdUdBk9rl6Mu8RfBgYj1gs588zQgXn+Qys6FQS10QtLLuw9yi8S6M7H9Zjgt0+U hnAA3OggHh4rk5B1aG7HXtcsr/jgbXO7g2zRu3UaYX/st1ffmQdbEdzvKv/fHODniHd6 FcR+XiSf0zkLxOZSfhQNFofimV4s19kZAfhNFOw5885i+T+6Jot/AqNq0E63GmY2Kz4B EcfQ==
X-Gm-Message-State: AOJu0YyxLKkDqGj9ur8C60si6dLodMWpVF3xO9s30+hEoVrMB+quhj7n 8/2BaKjYCJvr6sQB2A+RaPPJ2LhsdxWGWrfdlUWkwBo61DGWQEhGZED9MtW4
X-Google-Smtp-Source: AGHT+IGD2GVOe8DKdgJbblswO+IKhApc/f6stoklHcylnnZhki0Tzykcxn5UECRXUMQK4dvvZ7fjxQ==
X-Received: by 2002:a17:906:c0a:b0:a37:6800:e37 with SMTP id s10-20020a1709060c0a00b00a3768000e37mr680510ejf.27.1706971128538; Sat, 03 Feb 2024 06:38:48 -0800 (PST)
Received: from ?IPv6:2a02:a210:2280:c00:4e94:e21b:393c:8e98? (2a02-a210-2280-0c00-4e94-e21b-393c-8e98.cable.dynamic.v6.ziggo.nl. [2a02:a210:2280:c00:4e94:e21b:393c:8e98]) by smtp.gmail.com with ESMTPSA id rf22-20020a1709076a1600b00a37295502c0sm1290138ejc.138.2024.02.03.06.38.47 for <ipfix@ietf.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 03 Feb 2024 06:38:47 -0800 (PST)
Message-ID: <095e959a3b1f5c557fe1e463754379edc21b32ea.camel@gmail.com>
From: Garri Djavadyan <g.djavadyan@gmail.com>
To: ipfix@ietf.org
Date: Sat, 03 Feb 2024 15:38:46 +0100
Autocrypt: addr=g.djavadyan@gmail.com; prefer-encrypt=mutual; keydata=mQINBFo+To4BEADC1carfPgdOb+6l/NlXtXwXK0iKTJQnlihyg8MrDcrxSa/XjW1ISpfuBID40gqIIKNnGSjljfzf9FroR7WIQkImT1w80chWU57jf2ag8ytR2RJhM4tV2j98mqc6sZK5TG52SMVjOKnE266tXCL+HlILQaD9vpkfRrj79uNZHecprvIIflR4AXLAuXABzy65CnQ4jdxcZKReFL1+4Q7874+xAIe6dHuxWeS7PZPvj8FnRVNHDwPJxumEwV4sRYKeLF5lghPZlx9YAOknlnXdU58yh1UalvfiiKTthSS07BpUgwoiBAu5rYHE1DpUWcqvZWh59iy2JAsABrGJT/fEDC8UYr3wf7hWRNSkArEn3cCKth4crPyOhd9R/MO4eQAQnrdJXI6lgZojMwDZjIpItcxdekiVO4wnfPYvBf8BALPAw6k1PvAB8f7fiF+i1pKmr+nTuBcVpLkHV851BGVWXRW4l5QTYNQnf7lolhD4ErmJgOSfs7mu/jN8K8iUZlTwLScET71r/lplLBz5Is1cJVR/uZH36XK/16i4oaNshR2dxls3JcNCrBKDCrjev2G8SkKei7QqvysWKr5GdTyWnTjl6xQ3b6YoHymm3m/gRrTSrko8xxkuSOHsYSJq08Oy/STtFrB5jZe+/wC1r3EDZQZy5s8pT1OPGQbElzHDCyAzwARAQABtCdHYXJyaSBEamF2YWR5YW4gPGcuZGphdmFkeWFuQGdtYWlsLmNvbT6JAlQEEwEKAD4WIQTrf7SULpRILLSZ9B5gZG43gCh3ZwUCWj5OjgIbAwUJCWYBgAULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBgZG43gCh3Z4/IEAC9E+DHF//+651Tb/n5WbrZPUkt3WzjXHNIMzwCYWbCQag+WBvRxz9l qm00wDuZyGQzK5RY6RrSJ8A5rZRcMSHh5Jh8QAJLA4v5KDUUWh0n91sdRd/Vc cyzQhQmiWgvA2Rl/YfSyaQHimbDOUbDgApMGTy5ltZ51dKlwLUma2IVHW/qLGWnh51i2VXts+lPIo2lndqPSik0dLxEiL8d5IvpaukOiJrP8atwvm522nunr6V7bpwsq1lPEkW0eJBlqwjqZ/TQNQAqD/QWofFtvC7iTXEz4rfrHZP/2cHklo+rZtE2TNF44qe1k5G1y6SCL0iGuaVckdrVyyv6TuxGf8+59aGamqpySkfU4p9hwEsxWx+iPhkq31irstxuzzrWDjvoHNrw6s+2g07VRclfSOkX+4iFXxgchjwxbgdWo2PUEcGFDEbCgTUQ64B6PHMLMc9O3l/3cQAnFgW7dL7CMMOUjy6sRgvqF906c+ZPGk4OR3yanXuJOKXz9OVCbNgYPnxOuZo1L7BgW4JdewT96qjvkObeMwNOi2ED4WCU8w2XEx9FE1SR1A71/TKNHgMzycKCYqNk9xOi70yzXnIhrDYTJvC2rOqNC/8COtCvZ8epJ5JoJxQXQC+GEAOCMkERTY7aeEpfAKUuwwYYtR8kv7irlDQOTGe+xt+eI7C1g3SVyg==
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.2
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipfix/5xjVeNo0CkcSeEsbEqF0ZUsKI-s>
Subject: [IPFIX] Options Templates, Templates, and related Data Sets sent in separate transport sessions
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipfix/>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Feb 2024 14:38:51 -0000

Hi IPFIX experts,


Recently, my colleagues and I faced an IPFIX exporter implementation
that sends IPFIX messages with the Template and related Data Sets in
one transport UDP session and the Options Template and related Data
Sets in another transport UDP session (sourced from a different UDP
port) to the same IPFIX collector port.

While trying to understand this behaviour, I checked RFC7011 and a few
related RFCs but could not find any notes suggesting use cases when it
might be necessary. Also, I could not find any notes prohibiting this.

However, we know of at least one use case when sending the
aforementioned 4 IPFIX messages over 2 separate transport sessions is
undesirable. For example, when multiple self-sufficient IPFIX
collectors are listening on the same UDP socket using the socket option
SO_REUSEPORT (for horizontal scaling), the kernel-level load-balancing
algorithm can distribute 2 related sessions of the same exporter to
different processes. As a result, the process receiving the Flow
Records, cannot process them properly without the related Options. In
theory, it can also happen in the environments where layer-4 load-
balancers are used to distribute transport UDP sessions between IPFIX
collecting hosts.

Considering this, could you please help answer the following question?

Did I interpret the IPFIX RFCs correctly and the mentioned exporter's
behaviour is a compliant implementation?

There is a note in the "Template Management" section 8 of RFC7011
saying:

   Options Templates and Templates that are related or interdependent
   (e.g., by sharing common properties as described in [RFC5473])
   SHOULD be sent together in the same IPFIX Message.

but the Templates and the Options Templates in the case that I
mentioned are not interdependant by the common properties per RFC5473.



Thank you in advance!


Kind regards,
Garri Djavadyan