Re: [netmod] Tree diagrams

mohamed.boucadair@orange.com Fri, 15 October 2021 10:58 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309C63A115D; Fri, 15 Oct 2021 03:58:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-QsZik5TMdS; Fri, 15 Oct 2021 03:58:50 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43223A1166; Fri, 15 Oct 2021 03:58:49 -0700 (PDT)
Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar20.francetelecom.fr (ESMTP service) with ESMTPS id 4HW3D81qMLz8tkp; Fri, 15 Oct 2021 12:58:48 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1634295528; bh=UkH8jrDy18sZCJCIdO6qrYswbZmJyZ6f+GDjhAT6cCY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=IbmYoZ83dHwIzL2Opz+P9RlL+VVxL8atb3bHpCCouiS/HOowexbXnO7ZXleav+XVv MjT5ATZnT7xTNz1xP1WhCG1V3Xnf8smrq3SdsW90285kLwRimFz8EFag/WCsQTZ+S2 6GG77F4HPsH/xF8DKyHbBmXFiV3tpgvoRdib+lWHBozG+Vz0wszmIIIRhYT2naYqAg CyXVlPhPx1sSE1527Jj27YHSTj70nPbc+3Cigr63H4Au2eUkSIybcmVMIWh/D77F9E fud6D44TIwHXNWq3INKAfy8W/BUOwuxvu3S9c6Ft4ufgcC4+LvxWzzFXCIh9lPul1y VscxNG/tjv/Ow==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar05.francetelecom.fr (ESMTP service) with ESMTPS id 4HW3D80S9cz2xCp; Fri, 15 Oct 2021 12:58:48 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, tom petch <ietfc@btconnect.com>, "draft-ietf-opsawg-l3sm-l3nm@ietf.org" <draft-ietf-opsawg-l3sm-l3nm@ietf.org>, "draft-ietf-opsawg-vpn-common@ietf.org" <draft-ietf-opsawg-vpn-common@ietf.org>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: Tree diagrams
Thread-Index: AQHXwauokAtRaBjW2EGuZb/M49idHqvT1U0wgAAHftA=
Content-Class:
Date: Fri, 15 Oct 2021 10:58:46 +0000
Message-ID: <31588_1634295528_61695EE8_31588_200_1_787AE7BB302AE849A7480A190F8B93303542C895@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <AM7PR07MB62489EE33CE76695869A9302A0B99@AM7PR07MB6248.eurprd07.prod.outlook.com> <BY5PR11MB419673F4D67216E860892091B5B99@BY5PR11MB4196.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB419673F4D67216E860892091B5B99@BY5PR11MB4196.namprd11.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2021-10-15T10:58:37Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=33d51b0d-ed26-49b4-8f13-377d2b4089d3; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Tu97LDrpxz3Gjwxxk3urekETgY4>
Subject: Re: [netmod] Tree diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Oct 2021 10:58:56 -0000

Hi Rob, Tom, all, 

The trees are different because we are not importing the acl module, but are reusing "packet-fields" from RFC8519 to define the classification rules. 

Please note that trees in vpn-common are printed with "--tree-print-groupings". 

I suspected what happened for L3NM is that we touched manually the tree (this was there since -04) because sometimes we need so despite we are using "--tree-line-length 69".

We will make this change during AUTH48:

OLD: 
   |  |     |  |     +--:(destination-port-range-or-operator)

NEW:
   |  |     |  |     |        +--:(destination-port-range-or-operator)

Thank you, Tom. We always need fresh eyes. Much appreciated. 

Cheers,
Med

> -----Message d'origine-----
> De : Rob Wilton (rwilton) <rwilton@cisco.com>
> Envoyé : vendredi 15 octobre 2021 12:22
> À : tom petch <ietfc@btconnect.com>; BOUCADAIR Mohamed INNOV/NET
> <mohamed.boucadair@orange.com>; draft-ietf-opsawg-l3sm-l3nm@ietf.org;
> draft-ietf-opsawg-vpn-common@ietf.org
> Cc : netmod@ietf.org
> Objet : RE: Tree diagrams
> 
> Hi Tom, Med, Authors
> 
> Tom, thanks for flagging these.
> 
> Med, authors, please can you check if the tree diagrams in draft-ietf-
> opsawg-vpn-common-12 or draft-ietf-opsawg-l3sm-l3nm-18 need to be updated.
> If they do, then given that these documents are in the RFC editor queue
> then we will need to coordinate any corrections with the RFC editor.
> 
> Regards,
> Rob
> 
> 
> > -----Original Message-----
> > From: netmod <netmod-bounces@ietf.org> On Behalf Of tom petch
> > Sent: 15 October 2021 11:03
> > To: netmod@ietf.org
> > Subject: [netmod] Tree diagrams
> >
> > I do not understand tree diagrams.  My expectation is that the same
> > YANG should produce the same tree diagram but apparently not.  I look
> > at
> > RFC8519 and see
> >
> >         |        |  |  +--:(tcp)
> >         |        |  |  |  +--rw tcp {match-on-tcp}?
> > ............
> >         |  |  |     +--rw source-port
> >         |        |  |  |     |  +--rw (source-port)?
> >         |        |  |  |     |     +--:(range-or-operator)
> >         |        |  |  |     |        +--rw (port-range-or-operator)?
> >
> > but when imported into 'draft-ietf-opsawg-vpn-common-12' this becomes
> >           |  |     +--:(tcp)
> >           |  |     |  +-- tcp
> > ......
> >           |  |     |     +-- (source-port)?
> >           |  |     |     |  +--:(source-port-range-or-operator)
> >           |  |     |     |     +-- source-port-range-or-operator
> > ie the identifiers have gained a 'source'  (or 'destination').
> >
> > Also, the structure changes.  Moving on, vpn-common has
> >
> >           |  |     +--:(tcp)
> >           |  |     |  +-- tcp
> > .....
> >           |  |     |     +-- (source-port)?
> >           |  |     |     |  +--:(source-port-range-or-operator)
> >           |  |     |     |     +-- source-port-range-or-operator
> > .......
> >           |  |     |     +-- (destination-port)?
> >           |  |     |        +--:(destination-port-range-or-operator)
> >           |  |     |           +-- destination-port-range-or-operator
> > which looks fine until this is imported into
> > 'draft-ietf-opsawg-l3sm-l3nm-18' when it becomes
> >
> >    |  |     |  |     +--:(tcp)
> >    |  |     |  |     |  +--rw tcp
> > ...................
> >    |  |     |  |     |     +--rw (source-port)?
> >    |  |     |  |     |     |  +--:(source-port-range-or-operator)
> >    |  |     |  |     |     |     +--rw source-port-range-or-operator
> >    |  |     |  |     |     |                      inet:port-number
> >
> >    |  |     |  |     |     +--rw (destination-port)?
> >    |  |     |  |     +--:(destination-port-range-or-operator)
> >    |  |     |  |     |          +--rw destination-port-range-or-operator
> >    |  |     |  |     |             +--rw (port-range-or-operator)?
> >
> > 'destination-port-range-or-operator' has moved and we now have
> >    |  |     |  |     +--:(tcp)
> >    |  |     |  |     +--:(destination-port-range-or-operator)
> > which does not look fine to me; how can this be?
> >
> > Earlier drafts of l3nm did not have this feature.
> >
> > Tom Petch
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 information 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 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.