Re: [Tsv-art] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

Wesley Eddy <wes@mti-systems.com> Tue, 16 January 2024 15:08 UTC

Return-Path: <wes@mti-systems.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5788C14EB17 for <tsv-art@ietfa.amsl.com>; Tue, 16 Jan 2024 07:08:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20230601.gappssmtp.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 uV3X003eWrN1 for <tsv-art@ietfa.amsl.com>; Tue, 16 Jan 2024 07:08:45 -0800 (PST)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 D0CCCC14F6E3 for <tsv-art@ietf.org>; Tue, 16 Jan 2024 07:08:44 -0800 (PST)
Received: by mail-qk1-x736.google.com with SMTP id af79cd13be357-78314e00350so873607485a.1 for <tsv-art@ietf.org>; Tue, 16 Jan 2024 07:08:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20230601.gappssmtp.com; s=20230601; t=1705417724; x=1706022524; darn=ietf.org; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=CWOhEGCe5zcLq4AgWmX8VADO2ZzTaABFpSSXzWRGwjk=; b=x4y7+y3yWZ8WLmgah/IFbcLdQNEIUIJFw7uG1mjCMdDYMohky+2IvuV10w+x3UyRr8 RuznQOah38tQQ44375f8JZy14FRi1KBAbNUAXxgl9lulQiZCjLgPkTRsK4LN0KkPsPHi 9ehRLZLPeEYIVq7aB9O4TmhzOiV7N+CaE+2M7vc8bUnZgaLj/qQdnKV/cyFsY2hxGD3O ONKQ3h6k1cKPVx1H0rt7bctG2LDItSrNZv08LFPi+rU1MhcroIVEZZVZOLfK7H15hSJd s+CgZOepWSM7CurLnsIdNQjJeg6h1cF70HGeAwbP1hcSeIoQrAMoWJIC1TBM3Q5KSJ6H PpEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705417724; x=1706022524; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=CWOhEGCe5zcLq4AgWmX8VADO2ZzTaABFpSSXzWRGwjk=; b=Wp5AYBuwLqS31jEz928JMOInK66xlpViaWa7aqY6/tLlrLBxbAnibtfSqpsUXyTYJs FmfC4bybxJ1/PTU91r3iybt6F62BwollONILxZEhqr8LfRxomSXIWgs/YVXapL63XyVz /sKT9bHCgIjbQPi5194r4b6KpMJC8b9Nv5oOGax1BMWNDXzlJ4Aw/7iS2VLBbkKp2+44 s6CNJ7JWwMKLS5Vu8912n56DFJiK9Omd25e0Hh8UKaJvsLDNSe4lZyKOWwq/oIDPEOja Bd/6Z/CEaQI+tX/+pAiUtFu4TolSMPaaj4OIEWwcQ5RsO1gUnV2MJmL6p+yNa1lVbL3y auxw==
X-Gm-Message-State: AOJu0Yx247malwjjZ3JMyVXUuwYVcjMh9OyD1hFu9LFDtg8HrVpZG0fO Zo4XlENer7ai9f10U/G+IdOAjJ6H4OOpOg==
X-Google-Smtp-Source: AGHT+IF+kC3g7cWiVCLjziVg1fbF3yyGi1F+z0XxGWblBHloOqHGfXnjZguyX9F9V7Goe9bbsCj6rw==
X-Received: by 2002:a05:620a:21db:b0:783:3efa:b15f with SMTP id h27-20020a05620a21db00b007833efab15fmr8347060qka.87.1705417723755; Tue, 16 Jan 2024 07:08:43 -0800 (PST)
Received: from [192.168.1.121] (069-135-001-122.biz.spectrum.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id d15-20020a05620a240f00b0078329049342sm3779811qkn.73.2024.01.16.07.08.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Jan 2024 07:08:43 -0800 (PST)
Content-Type: multipart/alternative; boundary="------------bPx2CF2lRRkfIfR0eUi7HFLN"
Message-ID: <faf715ff-dae2-49cf-b29d-daca4cae73a7@mti-systems.com>
Date: Tue, 16 Jan 2024 10:08:41 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: mohamed.boucadair@orange.com, "tsv-art@ietf.org" <tsv-art@ietf.org>
Cc: "draft-ietf-opsawg-ipfix-tcpo-v6eh.all@ietf.org" <draft-ietf-opsawg-ipfix-tcpo-v6eh.all@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
References: <170421960173.20693.6271938298987993574@ietfa.amsl.com> <DU2PR02MB10160E07E26F7B486D45DFDFE886C2@DU2PR02MB10160.eurprd02.prod.outlook.com>
From: Wesley Eddy <wes@mti-systems.com>
In-Reply-To: <DU2PR02MB10160E07E26F7B486D45DFDFE886C2@DU2PR02MB10160.eurprd02.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/9unY7KUc6RFAlact52K9kLH7ZxU>
Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jan 2024 15:08:47 -0000

The changes look good to me; I just want to make sure you understand one 
of my questions that doesn't look like it was clear enough:

On 1/15/2024 4:13 AM, mohamed.boucadair@orange.com wrote:
>> - The way an implementation understands the TCP ExIDs may benefit
>> from slightly more explanation:
>>    -- In 4.2 and 4.3, is the idea that the implementation is just
>> sampling the
>>    16 or 32 bits following the experimental option kind being
>> indicated, and
>>    assuming those 2 or 4 bytes to be ExIDs?  From Section 6.2, I
>> got the sense
>>    that the implementation is aware of particular ExID values
>> specifically, to
>>    know if they should be reported as 2 or 4 byte values.
> [Med] 2-byte IDs are reported in tcpSharedOptionExID16 while 4-byte IDs are reported in tcpSharedOptionExID32.
Are you expecting the implementation to have an exhaustive list of all 
of the ExIDs in use to understand the difference between 2 and 4 byte 
usage?  I don't quite understand how this is supposed to work at the 
sampling point, since it's the TCP implementation that interprets the 
option and determines whether it is to be interpreted as containing (1) 
no ExID, (2) a 16-bit ExID, (3) a 32-bit ExID. This information is not 
available within the protocol to a third party.  The third party would 
need a list of ExIDs in-use in order to understand them.