[ippm] IOAM Aggregation Traces - followup from IETF 126 7/22 I PPBM/BMWG session
Alexander Clemm <ludwig=40clemm.org-Tr9gZwTxerDR74oF6e/[email protected]> Wed, 22 Jul 2026 13:19:03 +0200
| Newsgroups | gmane.ietf.ippm,gmane.ietf.bmwg |
|---|---|
| Message-ID | <[email protected]> |
This is a multipart message in MIME format.
--===============3412169645556937078==
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_00C5_01DD19DC.ABB57B80"
Content-Language: en-us
This is a multipart message in MIME format.
------=_NextPart_000_00C5_01DD19DC.ABB57B80
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi all,
=20
just to follow up from today's discussion of IOAM Aggregation Traces in th=
e
joint IPPM/BMWG session=20
=20
* Giuseppe made the comment to check if there are other drafts on
proposed IOAM extensions that could be related to either templating, or
that involve aggregation functionality, and that may benefit from
coordination/alignment. Looking at the set of drafts that mention IOAM I
see a proposal for an IOAM option related to the alternate marking method
(draft-he-ippm-ioam-extensions-incorporating-am-06), which shares a coauth=
or
with that on template option,as well as a proposal for an IOAM option for
Bit Error Measurements (draft-zhang-ippm-ber-00), again sharing a coauthor
with the template option draft and submitted fairly recently. So, I assum=
e
that where any of those drafts have shared coauthors, they will take these
into consideration for each of the drafts. =20
There is one draft, draft-xiao-ippm-ioam-trace-extensions-03, which does n=
ot
share a coauthor. That one is not concerned with aggregation but per-node
data; however, it could perhaps be related to a template. The template
option as proposed is however concerned with fixed size data, whereas the
data in that draft is flex size depending on the number of nodes, so there
is a difference, although that draft and the template draft could perhaps
benefit from cross-referencing each other. However, by and large I do thi=
nk
we are covered. =20
=20
Question to the IPPM mailer: are you aware of any other drafts that the WG
believes may be related and that should be considered? If so, please let =
us
know; it would certainly be useful for authors of those drafts to step
forward. Please note that the Aggregation Trace Option was first propose=
d
in October 2023 so probably predates most of those other drafts. =20
=20
* Another comment relating to the Template Option perhaps being the
draft that ends all other drafts and carrying analogy to IPFIX templates: =
I
think the situation is in fact a bit more nuanced than that so I just want=
ed
to follow up here to avoid misunderstandings. As nice as that would be, t=
he
templates here do not simply select among existing data fields which to
include and which not, but specifically where aggregation is involved
concern new semantics. For example, when defining a template for an
aggregation trace, what needs to be defined includes things like an
aggregation function, a data parameter involving a separate registry (sinc=
e
not just the basic 20-or-so data items can be subjected to aggregation, bu=
t
potentially many more), flags to handle very specific error conditions to
facilitate troubleshooting. None of these are defined anywhere else in IO=
AM
so any template that is introduced cannot simply refer to them, but instea=
d
they need to be specified and provided in an interoperable manner. So, at
least as far as aggregation traces are concerned, they need to be specifie=
d
separately from templates. Whether a template is defined for this, or an
IOAM option, is basically equivalent as far as implementation is concerned
and even what things look like on the wire - this was one of the outcomes
that our Hackathon project shows quite clearly. As far as Internet Drafts
are concerned, we _do_ need two specifications - the aggregation trace can
be carried as an own option, or it can be carried via a template, however,
the fields, their semantics, the behavior all need to be very much defined
either way. =20
=20
Thanks
=2D-- Alex
------=_NextPart_000_00C5_01DD19DC.ABB57B80
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 15 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Aptos;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;
mso-ligatures:standardcontextual;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;
mso-ligatures:standardcontextual;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1753507309;
mso-list-type:hybrid;
mso-list-template-ids:-1037806578 1360403164 67698691 67698693 67698689 =
67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Aptos",sans-serif;
mso-fareast-font-family:Aptos;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US =
link=3D"#467886" vlink=3D"#96607D" style=3D'word-wrap:break-word'><div =
class=3DWordSection1><p class=3DMsoNormal>Hi all,<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>just to =
follow up from today’s discussion of IOAM Aggregation Traces in =
the joint IPPM/BMWG session <o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><ul style=3D'margin-top:0in' =
type=3Ddisc><li class=3DMsoListParagraph =
style=3D'margin-left:0in;mso-list:l0 level1 lfo1'>Giuseppe made the =
comment to check if there are other drafts on proposed IOAM extensions =
that could be related to either templating, or that involve =
aggregation functionality, and that may benefit from =
coordination/alignment. Looking at the set of drafts that mention =
IOAM I see a proposal for an IOAM option related to the alternate =
marking method (draft-he-ippm-ioam-extensions-incorporating-am-06), =
which shares a coauthor with that on template option,as well as a =
proposal for an IOAM option for Bit Error Measurements =
(draft-zhang-ippm-ber-00), again sharing a coauthor with the template =
option draft and submitted fairly recently. So, I assume that =
where any of those drafts have shared coauthors, they will take these =
into consideration for each of the drafts. <br><br>There is one =
draft, draft-xiao-ippm-ioam-trace-extensions-03, which does not share a =
coauthor. That one is not concerned with aggregation but per-node =
data; however, it could perhaps be related to a template. The =
template option as proposed is however concerned with fixed size data, =
whereas the data in that draft is flex size depending on the number of =
nodes, so there is a difference, although that draft and the template =
draft could perhaps benefit from cross-referencing each other. =
However, by and large I do think we are covered. =
<o:p></o:p></li></ul><p class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal style=3D'margin-left:.5in'>Question to the IPPM =
mailer: are you aware of any other drafts that the WG believes may be =
related and that should be considered? If so, please let us know; =
it would certainly be useful for authors of those drafts to step =
forward. Please note that the Aggregation Trace Option was =
first proposed in October 2023 so probably predates most of those other =
drafts. <o:p></o:p></p><p class=3DMsoNormal =
style=3D'margin-left:.5in'><o:p> </o:p></p><ul =
style=3D'margin-top:0in' type=3Ddisc><li class=3DMsoListParagraph =
style=3D'margin-left:0in;mso-list:l0 level1 lfo1'>Another comment =
relating to the Template Option perhaps being the draft that ends all =
other drafts and carrying analogy to IPFIX templates: I think the =
situation is in fact a bit more nuanced than that so I just wanted to =
follow up here to avoid misunderstandings. As nice as that would =
be, the templates here do not simply select among existing data fields =
which to include and which not, but specifically where aggregation is =
involved concern new semantics. For example, when defining a =
template for an aggregation trace, what needs to be defined includes =
things like an aggregation function, a data parameter involving a =
separate registry (since not just the basic 20-or-so data items can be =
subjected to aggregation, but potentially many more), flags to =
handle very specific error conditions to facilitate =
troubleshooting. None of these are defined anywhere else in IOAM =
so any template that is introduced cannot simply refer to them, but =
instead they need to be specified and provided in an interoperable =
manner. So, at least as far as aggregation traces are concerned, =
they need to be specified separately from templates. Whether a =
template is defined for this, or an IOAM option, is basically equivalent =
as far as implementation is concerned and even what things look like on =
the wire – this was one of the outcomes that our Hackathon project =
shows quite clearly. As far as Internet Drafts are concerned, we =
_<i>do</i>_ need two specifications – the aggregation trace can be =
carried as an own option, or it can be carried via a template, however, =
the fields, their semantics, the behavior all need to be very much =
defined either way. <o:p></o:p></li></ul><p =
class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal>Thanks<o:p></o:p></p><p class=3DMsoNormal>--- =
Alex<o:p></o:p></p></div></body></html>
------=_NextPart_000_00C5_01DD19DC.ABB57B80--
--===============3412169645556937078==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KaXBwbSBtYWls
aW5nIGxpc3QgLS0gaXBwbUBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IGlwcG0tbGVhdmVAaWV0Zi5vcmcK
--===============3412169645556937078==--