From: [email protected] <[email protected]> Sent: 15 October 2021 11:58
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". <tp> That feature I do not understand. I agree that you are reusing packet-fields from RFC8519 but that module has 'grouping port-range-or-operator' with no mention AFAICT of a 'source' or a 'destination' in the identifier. Did you edit all those in as well? Tom Petch 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) <[email protected]> > Envoyé : vendredi 15 octobre 2021 12:22 > À : tom petch <[email protected]>; BOUCADAIR Mohamed INNOV/NET > <[email protected]>; [email protected]; > [email protected] > Cc : [email protected] > 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 <[email protected]> On Behalf Of tom petch > > Sent: 15 October 2021 11:03 > > To: [email protected] > > 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 > > [email protected] > > 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. _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
