From nobody Wed Sep 27 05:30:31 2023 Return-Path: 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 D2DB9C14CE45; Wed, 27 Sep 2023 05:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=plixer.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 tMIhTt4UOmOh; Wed, 27 Sep 2023 05:30:26 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2113.outbound.protection.outlook.com [40.107.244.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3119C14CEFD; Wed, 27 Sep 2023 05:30:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EWh98jlSnTfTlqrzF6MT0CLWUEn4y3eEWyzabf49s0KmiphaqMNGpXwf14rcG9S/sHqPWn550Ko/RxHHbjcGnxtn0JRNE5Le11cC5mYKu/wcaPeTpL7Y1Ozmc5nucMxA2kxdbAGE6tkHN2NAq6orhUTiBl+tOtPkc+EzQoVUA9ofwAR3QE5mievmgZVoiffADESOGi7XfuQOYkTE7/dNF9pIIU1ANOZgjURiM8GVGEYXz4DPEk8Y3zPiRsuxj4JJvRUc+rrOfj6HjDnmNmOFmQ00sWhm66YQsVkt/tKPq5WD7tvy9MdEk3/6mgpXCqrwNCKovMat05IhSsKY0fz/jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Zwpv6LzPDn+9qCx/9E/X1FwZeie4QrqMr9M4DfugVVU=; b=eKUMrh/G/PIiDtuDYs7b0V3DpHu0ueeRvZzcfS4aa/EgCHzu02E9xgzyo4RjUQANfxpuVpwWFhUCzskvrC8ofWYYw+zxAhERUEPmH8lts5D1+xKM1YhCpqe1byGuYTspVEmkm/6k4E+Y6ob/i8VRLAlBBgKXS1/dC/RHSYdgmcs/X5X1L58lrDO23/wUecFnDqBJ1Wcp/96kpxxShaYdQc6jSH4vcqLPIOIP9heDxv/+NweMpItMTuj1SlZX+HcVH8f9U2PLvdr38Pq9C0pzwRTLZGK5WLo/PODtfVQuad4GVDW0Y1tiBeNg1OWg7y5Qy8bCq41YURVeyWim0bZcUw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=plixer.com; dmarc=pass action=none header.from=plixer.com; dkim=pass header.d=plixer.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=plixer.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zwpv6LzPDn+9qCx/9E/X1FwZeie4QrqMr9M4DfugVVU=; b=bRX24Ky1KGq0RfKF30IXlu+KP5z6IppFqv6pe3TdpjnWAnJfhKEBsc0huuA1kX3ow/e8Nf2VoRP7tnEikYD9cLVh9izpc7iZjyMiirX3JtaLyAcnXhne89a2x3RZXPM8KWIU511te/GMuxTDK3rRcHOMtFsvHvVvHzl/gRhDVPA= Received: from MN2PR19MB3709.namprd19.prod.outlook.com (2603:10b6:208:190::10) by CH3PR19MB8439.namprd19.prod.outlook.com (2603:10b6:610:1cd::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6813.23; Wed, 27 Sep 2023 12:30:21 +0000 Received: from MN2PR19MB3709.namprd19.prod.outlook.com ([fe80::b716:c422:911d:b308]) by MN2PR19MB3709.namprd19.prod.outlook.com ([fe80::b716:c422:911d:b308%5]) with mapi id 15.20.6813.027; Wed, 27 Sep 2023 12:30:21 +0000 From: Andrew Feren To: "Aitken, Paul" , "mohamed.boucadair@orange.com" , opsawg , Benoit Claise CC: "ipfix@ietf.org" Thread-Topic: draft-ietf-opsawg-ipfix-fixes: tcpOptions/ipv4Options bit mappings Thread-Index: Adnq0jNyCRXZsLPFRzmQE+7bo7jeZwAD7kEAAAWqyWAANDC7IABBHzaAARtMCxM= Date: Wed, 27 Sep 2023 12:30:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=plixer.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MN2PR19MB3709:EE_|CH3PR19MB8439:EE_ x-ms-office365-filtering-correlation-id: 79453a30-4b1e-4cce-a50f-08dbbf558434 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: p4Rw/mzjcKXtOHaVDYwBeJsQtpMXMlK07eaRQXhWAogKLaf1npwA6JFK5Nv741hKuOKP8IMrCkg5s7nQzURSHB4BovG3BWTBFtsNfPVYTMo2QYLr33AHWmFBVsX4WuBLOOoRbgceznNJPQXoRdzW9E46WGq1fEY9oFIk5LcOUseUEsQ7OlLCYwCks1mywSJ6DJ2akB7viYjQ0x/nGeHT3al6oXZlsQtTYfdDW2WDSnZyGzTIr5uUL/m3oKiHMVCvmp019dqkZKhmbkk6m2y0vEIbuGyh8uD+hZn+zP9CIkPbETUZ440T+D7DzIwSfaN+kVl5W/m3vK+wEFJ9XCDUBHSn8q9hiXMfywxTk1511Gl40GKtWDlu44H+54JFC2uR0u2Tuc8yTHfo9UTK8XPD4vmd46N6HJDshAbcu7lgHbWHaJ0IATDUW8nhFLIoG9qTkKTxlpcs+36WvhqVyLolvP4NQFQE6Uk7ZfNbFx/iEqnLDdDrC1ia+fk9flUzZqHzEFqRFoeuubVUcQ/gTBdmsyi0vc9ZAXX1vtO9K1GeEArk14mmW2k/Oy82j4ByBislT8g2EFCCRy36lDK7e+1mWlGvsqPHumWuo8zJ5xkDZJs= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR19MB3709.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366004)(346002)(396003)(39840400004)(376002)(136003)(230922051799003)(451199024)(1800799009)(186009)(8676002)(9326002)(8936002)(4326008)(110136005)(44832011)(52536014)(5660300002)(71200400001)(53546011)(55016003)(7696005)(76116006)(9686003)(66946007)(66476007)(64756008)(26005)(66556008)(38070700005)(83380400001)(316002)(41300700001)(166002)(38100700002)(966005)(33656002)(86362001)(66446008)(6506007)(2906002)(19627235002)(478600001)(122000001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?3QisSQ8cBPHNx62okczuQ1qHf0V+OK4rBzH4ygYca/eKI2kvHHamHsjQ?= =?Windows-1252?Q?jZbYqyhDiDBLUAuaEVF4ok+D6nob04y59E329IhFEdHN2bouEx9iP6Yp?= =?Windows-1252?Q?/luYAEjUR5LDustHQxh24v6UuC6jeNxWETau+PRY6XQcgXPV6R8bGLJe?= =?Windows-1252?Q?IRLQfvyejRquf4ATdA7guD2EG/+biFwRBdyo0zLQ+UlxWby4po2Z5jzR?= =?Windows-1252?Q?mHAfAsol2kb8gBGHsgM6a+aeJy3yp7ZsGxGEMzEIEqjGFHREY9y77PDT?= =?Windows-1252?Q?recBGQKpazw2ouMMQNBuQz8TDJNogZrd1QP5dHpa2nXzQPnV+iwkOdJ6?= =?Windows-1252?Q?EnimU8qC2Skc9oOieCLWHIlppEF0BBqEcpsrEt+hLQvdqM/TXdNgk70Y?= =?Windows-1252?Q?zeClt/oWahTbGB6q+n/faCRJ2+0IxZJfvkx3meFXgAi2IBoAyl3rI2S9?= =?Windows-1252?Q?gGmC4J+fDYKy7iH9C/UE6jduKRkWcBMG0BSHlbNgpIR6BcLeMhcLjWSg?= =?Windows-1252?Q?90kUY9sbSuA8/S6DjSdkVzWqzYUUDGfqgBkEyExTN5p0yFUMYGheJChH?= =?Windows-1252?Q?KRY/55mnslzS0Yz81oXBkMTZcJwEZi5MPg7MPNHJy7UINbbxBg2GF/sb?= =?Windows-1252?Q?nlcSDroMZ4zVeG128wGOO0DnWrhUOCjyAYRdI+Rko8ixMr2wU39mwAvj?= =?Windows-1252?Q?DXCPceDG7Sp+NwZ+PKVmm6Ht3mYuO9DcsSLGCn8LL9IsbV+I2ixl7QLO?= =?Windows-1252?Q?kiYeWrZNT5PGIy9knKN3VahoUjBtTIoqBeKlgKGY/+fEsKFIYGIFrLAp?= =?Windows-1252?Q?QvlKYmPz1C3m9797/76S98n4KTkqOjnwmsUD6aOsL2hO+ZKiMWrazxHg?= =?Windows-1252?Q?fnI4JiXZ+luLf9Q/0K1xxrnlbKx1jltnS81hmOg2viapy/kM/b0a6yB5?= =?Windows-1252?Q?QsvJ8zVtp+RulRSzNuPRHj1xDYUzOFwNcb+CCGjTG6p4zk2dWWBc7g0g?= =?Windows-1252?Q?Y9G57gRM5GwyWdvcbHWCciitwAJAKK/SKQ5lcTZYl91/4sn7T0+7aaEp?= =?Windows-1252?Q?ikL5MDZ3AutU0QnKd7Dy4PVzuRw1fzXDVHvUQl8CgquZrIj+r7yPNYpf?= =?Windows-1252?Q?k/3zpW456uZKT1VdcA0x+Qoc60sZUpsxoSOvo4M3VosgbeGwtdds98qz?= =?Windows-1252?Q?hv2aa6GGo3EuNKRoUDp5EQzVikglIgi7CMDo1k+RN6xPinOxLTT83BtC?= =?Windows-1252?Q?o4TI7gEzUF0p5HN75jJDBp3UhutfgOVde5J3hNkKqFaNUX32FFg4u8jV?= =?Windows-1252?Q?PQPJMwiV1LYqzUHqgTNGl9a5OKajW24cXKi4NY6rhZPHxw3B/jCT5FJy?= =?Windows-1252?Q?7K6SBlpJbxzXwdDCmVdu44zKhGQRe50T2oh3Yp2o3V3E+mNazQKY97zi?= =?Windows-1252?Q?qVPw6LnSZ+bbWWjJBP/qs9mhtNBW4ZP7uCItPzvExFkUMBC2ajOlq/WC?= =?Windows-1252?Q?au2n8pp01TX1Z9DFzv6OS6rpec3YlahDqZjbGnBmv1W+d+DDS1kNIeHx?= =?Windows-1252?Q?nFATl6cba4G9/04T9UTnk63K9195LmoqY+E2/ohy6aGw6UFGb+N0PpsE?= =?Windows-1252?Q?WEp1MC1XSkrM/F/pWgbnE3LDTnnI4vL1UrnQiXdc6Adk+gkwKlkxGjPF?= =?Windows-1252?Q?/rWhdHBi4DP6zMIILw1shTriiKdAm9aT+1LJjwG+GEpBq6YnWiKVOg?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_MN2PR19MB370937229359E00F84868A55F0C2AMN2PR19MB3709namp_" MIME-Version: 1.0 X-OriginatorOrg: plixer.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR19MB3709.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 79453a30-4b1e-4cce-a50f-08dbbf558434 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2023 12:30:21.3639 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: dc941f2d-c470-4728-8910-fb11111d215f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /iPTm3yv/AgwhONJenSKCORqBD5Rt3Xj8jC4QRHpH4JyproU7xhWpmABbf3ftbwMNbfqEN+rZVOOQCvtEoICRg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR19MB8439 Archived-At: Subject: Re: [IPFIX] draft-ietf-opsawg-ipfix-fixes: tcpOptions/ipv4Options bit mappings X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2023 12:30:30 -0000 --_000_MN2PR19MB370937229359E00F84868A55F0C2AMN2PR19MB3709namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Paul, I=92m coming in a little late on this, but I took a few days to scan the ma= ny thousands of pcaps I=92ve collected from customers over the last 20 year= s and look at existing exporter and collector implementations that I have a= ccess too. Based on what I have found there may be no complaints because n= o one has implemented it. I was unable to find a single use of either ipv4= Options(208) or tcpOptions(209) in the wild. Looking at the RFCs and errat= a it is hard to see how anyone could have implemented these IEs without man= y questions. I asked myself how I would have implemented this if I had to make a decisio= n based on what exists and came to the same conclusions you did in https://= mailarchive.ietf.org/arch/msg/ipfix/v9ywSgTeYzataQnhMG-x7SxLo0U/. If other= s reach the same conclusions my inclination is to make a 3rd and, hopefully= final, errata attempt. As a collector developer I=92m sympathetic to the = option to deprecate these IEs and try again, but I feel like a careful erra= ta may be OK in this case. -Andrew From: IPFIX on behalf of Aitken, Paul Date: Thursday, September 21, 2023 at 4:55 PM To: mohamed.boucadair@orange.com , opsawg , Benoit Claise Cc: ipfix@ietf.org Subject: Re: [IPFIX] draft-ietf-opsawg-ipfix-fixes: tcpOptions/ipv4Options = bit mappings [EXTERNAL] CAUTION: This email originated from outside of the organization.= Do not click links or open attachments unless you recognize the sender and= know the content is safe. Med, no-one else has reported problems with these elements in the last 15 y= ears. So what do you want to achieve? We should not update the registry without first understanding what has alre= ady been implemented. The best we can hope for is that existing implementat= ions show consensus on the encoding. If so, then we should ensure that the = IPFIX registry and errata align with the implementations. If there's no consensus then it would be better to create new elements and = deprecate the existing ones. But it's not worth creating new elements unles= s they would be broadly deployed. P. On 20/09/2023 15:12, mohamed.boucadair@orange.com wrote: Hi Paul, all, I digged into ipfix archives to see the discussion that happened around the= se errata and when scrolling I found this message: https://mailarchive.ietf.org/arch/msg/ipfix/v9ywSgTeYzataQnhMG-x7SxLo0U/ [m= ailarchive.ietf.org] bu= t no follow-up. This confirms my initial assessment that a fix is needed. Cheers, Med De : BOUCADAIR Mohamed INNOV/NET Envoy=E9 : mardi 19 septembre 2023 15:02 =C0 : 'Aitken, Paul' ; opsawg = ; Benoit Claise Objet : RE: draft-ietf-opsawg-ipfix-fixes: tcpOptions/ipv4Options bit mappi= ngs Hi Paul, Yes, that=92s what I was referring to in my previous messages when I said = =93FWIW, (1) is what was followed in RFC5102 but changed since then by erra= ta.=94. I=92m having trouble with that errata as I don=92t understand why the rever= sal was only made at the octet level and not the full IE + how to link that= with =93Option number X is mapped to bit X=94. Thank you. Cheers, Med De : Aitken, Paul > Envoy=E9 : mardi 19 septembre 2023 12:13 =C0 : BOUCADAIR Mohamed INNOV/NET >; opsawg = >; Benoit Claise = > Objet : Re: draft-ietf-opsawg-ipfix-fixes: tcpOptions/ipv4Options bit mappi= ngs Med, this figure originally appeared in section 5.8.8 of draft-ietf-ipfix-i= nfo-13, -14, and RFC 5102 with the bits in this order: 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ... +-----+-----+-----+-----+-----+-----+-----+-----+ The bits were reversed by this errata: https://www.rfc-editor.org/errata/ei= d2946 [rfc-editor.org] Also see https://www.rfc-editor.org/errata/eid1739 [rfc-editor.org] P. On 19/09/2023 09:49, mohamed.boucadair@orange.com wrote: Hi all, The description of these IEs says that =93Options are mapped to bits accord= ing to their option numbers. Option number X is mapped to bit X=94, however= the drawing does not reflect that (tcpOptions): 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 8 9 10 11 12 13 14 15 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 |... +-----+-----+-----+-----+-----+-----+-----+-----+ 16 17 18 19 20 21 22 23 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 |... +-----+-----+-----+-----+-----+-----+-----+-----+ . . . 56 57 58 59 60 61 62 63 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 63 | 62 | 61 | 60 | 59 | 58 | 57 | 56 | +-----+-----+-----+-----+-----+-----+-----+-----+ I suspect that the confusion is rooted in the interpretation of =93bit X=94= : as (1) =93bit position X=94 or the resulting (2) =93binary value=94: 1. If (1) is followed, then bit#0 would be mapped to option 0, bit#1 to = option 1, and so on. This logic is followed, e.g., for ipv6ExtensionHeaders= . 2. If (2) is followed, then bit#63 would be mapped to option 0, bit#62 t= o option 1, and so on. In both cases, the drawing is not aligned with the narrative text. We may e= ither consider updating the drawing or the text. Which change is likely to have less impact on existing implementations? FWI= W, (1) is what was followed in RFC5102 but changed since then by errata. Thank you. Cheers, Med ___________________________________________________________________________= _________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= _________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. This email message and any attachments are confidential. If you are not the= intended recipient, please immediately reply to the sender and delete the = message from your email system. Thank you. --_000_MN2PR19MB370937229359E00F84868A55F0C2AMN2PR19MB3709namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Paul,

 

I=92m coming in a little late on this, but I took a = few days to scan the many thousands of pcaps I=92ve collected from customer= s over the last 20 years and look at existing exporter and collector implem= entations that I have access too.  Based on what I have found there may be no complaints because no one has impleme= nted it.  I was unable to find a single use of either ipv4Options(208)= or tcpOptions(209) in the wild.  Looking at the RFCs and errata it is= hard to see how anyone could have implemented these IEs without many questions.

 

I asked myself how I would have implemented this if = I had to make a decision based on what exists and came to the same conclusi= ons you did in https://mailarchive.ietf.org/arch/msg/ipfix/v9ywSgTeYzataQnhMG-x7SxLo0U/.  If others reach the same conclusions my inclination is to make a 3= rd and, hopefully final, errata attempt.  As a collector de= veloper I=92m sympathetic to the option to deprecate these IEs and try again, but I feel like a careful errata may be OK in thi= s case.

 

-Andrew

 

From: IPFIX <ipfix-bou= nces@ietf.org> on behalf of Aitken, Paul <paitken=3D40ciena.com@dmarc= .ietf.org>
Date: Thursday, September 21, 2023 at 4:55 PM
To: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>= ;, opsawg <opsawg@ietf.org>, Benoit Claise <benoit.claise@huawei.c= om>
Cc: ipfix@ietf.org <ipfix@ietf.org>
Subject: Re: [IPFIX] draft-ietf-opsawg-ipfix-fixes: tcpOptions/ipv4O= ptions bit mappings

[EXTERNAL] CAUTION: This email o= riginated from outside of the organization. Do not click links or open atta= chments unless you recognize the sender and know the content is safe.

 

Med, no-one else has = reported problems with these elements in the last 15 years. So what do you = want to achieve?

We should not update the registry without first understanding what has alre= ady been implemented. The best we can hope for is that existing implementat= ions show consensus on the encoding. If so, then we should ensure that the = IPFIX registry and errata align with the implementations.

If there's no consensus then it would be better to create new elements and = deprecate the existing ones. But it's not worth creating new elements unles= s they would be broadly deployed.

P.

Hi Paul, all,

 

I digged into ipfix archives to see the discussion that happened ar= ound these errata and when scrolling I found this message:  

http= s://mailarchive.ietf.org/arch/msg/ipfix/v9ywSgTeYzataQnhMG-x7SxLo0U/ [mailarchive.ietf.org] but no follow-up.

 

This confirms my initial assessment that a fix is needed.

 

Cheers,

Med

 

De := BOUCADAIR Mohamed INNOV= /NET
Envoy=E9 : mardi 19 septembre 2023 15:02
=C0 : 'Aitken, Paul' <p= aitken@ciena.com>; opsawg <opsawg@ietf.org>; Benoit Clai= se <benoit.claise@huawei.com>
Objet : RE: draft-ietf-opsawg-ipfix-fixes: tcpOptions/ipv4Optio= ns bit mappings

 

Hi Paul,

 

Yes, that=92s what I was referring to in my previous messages when = I said =93FWIW, (1) is what was followed in RFC5102 but changed since then = by errata.=94.

 

I=92m having trouble with that errata as I don=92t understand why t= he reversal was only made at the octet level and not the full IE + how to l= ink that with =93Option number X is mapped to bit X=94.

 

Thank you.

 

Cheers,

Med

 

De := Aitken, Paul <paitken@ciena.com>
Envoy=E9 : mardi 19 septembre 2023 12:13
=C0 : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; opsawg <opsawg@ietf.org>; Benoit Claise <= benoit.claise@huawei.com>= ;
Objet : Re: draft-ietf-opsawg-ipfix-fixes: tcpOptions/ipv4Optio= ns bit mappings

 

Med, this figure orig= inally appeared in section 5.8.8 of draft-ietf-ipfix-info-13, -14, and RFC = 5102 with the bits in this order:

           &nbs=
p;  0     1     2  &=
nbsp;  3     4     5 &nbs=
p;   6     7
          +-----+-----+--=
---+-----+-----+-----+-----+-----+
          |   0=
 |   1 |   2 |   3 |   4 | &nb=
sp; 5 |   6 |   7 |  ...
          +-----+-----+--=
---+-----+-----+-----+-----+-----+


The bits were reversed by this errata: https://www.rfc-editor.org/errata/eid2946 [rfc-editor.org]

Also see https://www.rfc-editor.org/errata/eid1739 [rfc-editor.org]

P.

On 19/09/2023 09:49, mohamed.boucadair@orange.com wrote:

= Hi all,

=  

= The description of these IEs says that =93Options are mapped to bits accord= ing to their option numbers. Option number X is mapped to bit X=94, however= the drawing does not reflect that (tcpOptions):

=  

=         0     1 = ;    2     3     4&n= bsp;    5     6     = 7

=     +-----+-----+-----+-----+-----+-----+-----+-----+=

=     |   7 |   6 |   5 | &= nbsp; 4 |   3 |   2 |   1 |   0 |&n= bsp; ...

=     +-----+-----+-----+-----+-----+-----+-----+-----+=

=  

=         8     9 = ;   10    11    12   = ; 13    14    15

=     +-----+-----+-----+-----+-----+-----+-----+-----+=

= ... |  15 |  14 |  13 |  12 |  11 |  10 |&nbs= p;  9 |   8 |...

=     +-----+-----+-----+-----+-----+-----+-----+-----+=

=  

=        16    17  &nb= sp; 18    19    20    21 =    22    23

=     +-----+-----+-----+-----+-----+-----+-----+-----+=

= ... |  23 |  22 |  21 |  20 |  19 |  18 |&nbs= p; 17 |  16 |...

=     +-----+-----+-----+-----+-----+-----+-----+-----+=

=  

=             &nb= sp;            = . . .

=  

=        56    57  &nb= sp; 58    59    60    61 =    62    63

=     +-----+-----+-----+-----+-----+-----+-----+-----+=

= ... |  63 |  62 |  61 |  60 |  59 |  58 |&nbs= p; 57 |  56 |

=     +-----+-----+-----+-----+-----+-----+-----+-----+=

=  

= I suspect that the confusion is rooted in the interpretation of =93bit X=94= : as (1) =93bit position X=94 or the resulting (2) =93binary value=94:

  1. If (1) is followe= d, then bit#0 would be mapped to option 0, bit#1 to option 1, and so on. Th= is logic is followed, e.g., for ipv6ExtensionHeaders.
  2. If (2) is follow= ed, then bit#63 would be mapped to option 0, bit#62 to option 1, and so on.

=  

= In both cases, the drawing is not aligned with the narrative text. We may e= ither consider updating the drawing or the text.

=  

= Which change is likely to have less impact on existing implementations? FWI= W, (1) is what was followed in RFC5102 but changed since then by errata. &n= bsp;

=  

= Thank you.

=  

= Cheers,

= Med

______________________________________________________________________=
______________________________________
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.

 

______________________________________________________________________=
______________________________________
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.

 

This email = message and any attachments are confidential. If you are not the intended r= ecipient, please immediately reply to the sender and delete the message fro= m your email system. Thank you.
--_000_MN2PR19MB370937229359E00F84868A55F0C2AMN2PR19MB3709namp_--