Subject: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-00.txt

From: [email-masked]
Date: Tue, 12 Jan 2021 09:32:10 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Performance Measurement WG of the IETF.

        Title           : A YANG Data Model for In-Situ OAM
        Authors         : Tianran Zhou
                          Jim Guichard
                          Frank Brockners
                          Srihari Raghavan
	Filename        : draft-ietf-ippm-ioam-yang-00.txt
	Pages           : 25
	Date            : 2021-01-11

Abstract:
   In-situ Operations, Administration, and Maintenance (IOAM) records
   operational and telemetry information in user packets while the
   packets traverse a path between two points in the network.  This
   document defines a YANG module for the IOAM function.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ippm-ioam-yang-00
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-yang-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 13 Jan 2021 02:08:10 +0000

Hi WG,

Thanks Dhruv, Reshad, Mickey for the valuable comments during the adoption call.
We just revised the document and submitted the latest version.
More comments are welcome.

Here is the summary of this version:
1. As requested, we add an operational container "ioam-info" for assistant data like unit and timestamp. 
This is now empty for further augment. 
The IOAM data draft has these words:
" IOAM offers three different timestamp format options.  The Namespace-ID can be used to determine the
   timestamp format. IOAM-Data-Fields (e.g. buffer occupancy) which do not have a unit associated are to be interpreted within the
   context of a IOAM-Namespace. "
My interpretation is that  there is no need for additional information on timestamp. I will consider buffer occupancy next. 
More suggestions on specific informational data are welcome.

2. I associate ACE instead of ACL with each profile. 
Here I did not augment  ACE action, because there might be different kind of filters, ACL is just one. As Dhruv proposed, flow spec could be another one. I believe existing structure is more flexible.
And as suggested, I've add text in the document:
"IOAM actions MUST be driven by the accepted packets, when the matched ACE "forwarding" action is "accept"."
That is reasonable, because I assume ACL and IOAM are to independent module.
ACL could deny a packet, then this packet will not trigger IOAM.

3. I did not add the interface filter. Because ACL already include the interface filter, i.e., wildcard packet from a specific interface. So we can still use ACL filter for the use case proposed by Mickey.

Best Regards,
Tianran

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, January 13, 2021 1:32 AM
To: [email-masked]
Cc: [email-masked]
Subject: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm