Re: [ippm] Section 6 - draft-fz-ippm-alt-mark-deployment-01

Giuseppe Fioccola <> Mon, 30 October 2023 10:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D7BAC151065; Mon, 30 Oct 2023 03:53:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C04Etz_hIez5; Mon, 30 Oct 2023 03:53:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DDF3AC14CF15; Mon, 30 Oct 2023 03:53:50 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4SJqm06fXbz6JB1L; Mon, 30 Oct 2023 18:49:52 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Mon, 30 Oct 2023 11:53:47 +0100
Received: from ([]) by ([]) with mapi id 15.01.2507.031; Mon, 30 Oct 2023 11:53:47 +0100
From: Giuseppe Fioccola <>
To: tom petch <>, Nilo Massimo <>, "" <>, "" <>, "" <>
Thread-Topic: Section 6 - draft-fz-ippm-alt-mark-deployment-01
Thread-Index: AdnvorM7OAaThpJqSiCXHe8g9y5AaANefEUQAi31OdAAAChi8AC6mKrSAAsLNRYAAJ2JsA==
Date: Mon, 30 Oct 2023 10:53:47 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [ippm] Section 6 - draft-fz-ippm-alt-mark-deployment-01
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Oct 2023 10:53:55 -0000

Hi Tom,
Thank you for your feedback. We plan to revise the draft soon to address your comments.
Please find my replies inline tagged as [GF].



-----Original Message-----
From: tom petch <> 
Sent: Friday, October 27, 2023 5:43 PM
To: Giuseppe Fioccola <>; Nilo Massimo <>;;;
Subject: Re: Section 6 - draft-fz-ippm-alt-mark-deployment-01

And I get a bounce from
Cannot see it among the expansions for this I-D but I expect that it is there somewhere

I had the same in August when commenting on an Erratum

Tom Petch

From: ippm <> on behalf of tom petch <>
Sent: 27 October 2023 11:49
To: Giuseppe Fioccola; Nilo Massimo;;;
Subject: Re: [ippm] Section 6 - draft-fz-ippm-alt-mark-deployment-01

From: ippm <> on behalf of Giuseppe Fioccola <>
Sent: 23 October 2023 18:27

Hi again,
I forgot to mention that, in relation to this document, we also published two new drafts:

  *   IPFIX Alternate-Marking Information (
  *   YANG Data Model for the Alternate Marking Method (
These documents complement the AltMark deployment document for what concerns the configuration (YANG) and data export (IPFIX) aspects.

Your reviews are welcomed.

YANG is mostly lower case whereas I note that the file name is upper case.

[GF]: Sure, we will revise the use of the term YANG.

Also, I find prefix long - here it is longer than the file name.  Perhaps 'amm:' or altmk:'.  Some models have path statements which are nested ten deep and then the length of the prefix can significantly affect legibility. I think that 3-4-5 characters is good.

[GF]: Ok, thank you for pointing that out. Maybe 'amm' can work.

YANG imports must be Normative References in the I-D; you need to add 8353 8532.   Common practice is to have a section 4.1 saying the YANG module imports from [RFC8532], [RFC8353] and makes reference to ...

[GF]: Good suggestion. We will review it and include a new section.

I suggest mentioning RFC9341 RFC9342 in the Abstract (but not as an XML link).

[GF]: Yes, it makes sense.

Note that users can augment this module
Well yes, how can you stop them?  I suggest adding something about what augmentations are likely and where they are likely to be.  Sometimes authors add empty containers as anchors for potential augmentations.

[GF]: Good suggestions. We will consider this point and provide guidance for possible future augmentations.

the reference in the revision clause is not quite the same as the document title

[GF]: Ok, we will revise.

support for a function is often indicated by a presence container as opposed to feature; this is widespread in routing modules.

[GF]: Ok, we will fix it.

what are the units of period?

[GF]: Ok, we will define it.

not sure if opsawg are interested in this

[GF]: Right. Since this discussion is related only to the draft in IPPM (draft-gfz-ippm-alt-mark-yang), I'm removing OPSAWG from the list of recipients.

Tom Petch


(on behalf of the coauthors)

From: Giuseppe Fioccola
Sent: Monday, October 23, 2023 7:19 PM
To: 'Nilo Massimo' <>;;;
Subject: RE: Section 6 - draft-fz-ippm-alt-mark-deployment-01

Dear All,
Please note that we just submitted a new version of draft-fz-ippm-alt-mark-deployment to address the comments received.

Inputs and suggestions are always welcome.


(on behalf of the coauthors)

From: Nilo Massimo <<>>
Sent: Thursday, October 12, 2023 5:22 PM
Subject: RE: Section 6 - draft-fz-ippm-alt-mark-deployment-01

Hi Thomas,
thank you for your feedback.
I have a couple of comments.
In section 6.1 for IPFIX, in order to calculate loss you said to use for packets the entity octetDeltaCount(IE1). But might it be better to use the entity packetDeltaCount(IE2)?

Moreover I suggest for the delay to add the use of existing entities flowEndSeconds, flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds.

Best Regards,


Gruppo TIM - Uso Interno - Tutti i diritti riservati.
From: ippm <<>> On Behalf Of<>
Sent: lunedì 25 settembre 2023 13:23
Subject: [EXT] [ippm] Section 6 - draft-fz-ippm-alt-mark-deployment-01

Dear draft-fz-ippm-alt-mark-deployment authors, Dear IPPM working group,

First of all I think draft-fz-ippm-alt-mark-deployment is a valuable document describing the deployment of Alternat Marking.

I have reviewed the Network Telemetry aspect described in Section 6 and wrote a proposal for -01 as following:

The new section describes how the export could be performed with existing IPFIX entities where decomposition is performed at the data collection and what needs to be consider for new IPFIX entities. I also described the publication with YANG push and what needs to be considered in terms of subscription, data publication and modeling.

Here the current diff:

I hope this makes sense and is helpful for the community. Feedback and comments welcome.

Best wishes


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

ippm mailing list