Subject: [ippm] Adoption call for IOAM deployment and integrity documents

From: Tommy Pauly <[email-masked]>
Date: Tue, 03 Aug 2021 09:28:38 -0700

Hello IPPM,

As discussed in our meeting last week, we will be starting an adoption call for two IOAM-related documents that have been raised as important dependencies during the IESG review of IOAM-data.

This email begins a Working Group adoption call for two documents:

Integrity of In-situ OAM Data Fields
https://datatracker.ietf.org/doc/draft-brockners-ippm-ioam-data-integrity/ <https://datatracker.ietf.org/doc/draft-brockners-ippm-ioam-data-integrity/>
https://www.ietf.org/archive/id/draft-brockners-ippm-ioam-data-integrity-03.html <https://www.ietf.org/archive/id/draft-brockners-ippm-ioam-data-integrity-03.html>

In-situ OAM Deployment
https://datatracker.ietf.org/doc/draft-brockners-opsawg-ioam-deployment/ <https://datatracker.ietf.org/doc/draft-brockners-opsawg-ioam-deployment/>
https://datatracker.ietf.org/doc/html/draft-brockners-opsawg-ioam-deployment-03 <https://datatracker.ietf.org/doc/html/draft-brockners-opsawg-ioam-deployment-03>

This call will last until Wednesday, August 18. Please reply to this email with your comments, and if you think these documents should be taken on by IPPM.

Best,
Tommy & Ian

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 10 Aug 2021 19:08:45 +0000

Support the adoption of both documents (as author).

Cheers, Frank

From: ippm <[email-masked]> On Behalf Of Tommy Pauly
Sent: Dienstag, 3. August 2021 18:29
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: [ippm] Adoption call for IOAM deployment and integrity documents

Hello IPPM,

Integrity of In-situ OAM Data Fields
https://datatracker.ietf.org/doc/draft-brockners-ippm-ioam-data-integrity/
https://www.ietf.org/archive/id/draft-brockners-ippm-ioam-data-integrity-03.html

In-situ OAM Deployment
https://datatracker.ietf.org/doc/draft-brockners-opsawg-ioam-deployment/
https://datatracker.ietf.org/doc/html/draft-brockners-opsawg-ioam-deployment-03

Best,
Tommy & Ian

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 11 Aug 2021 02:32:43 +0000

Hi WG, Chairs,
I have been following the IOAM work as part of draft-gandhi-mpls-ioam.
Both of these documents (listed below) are useful and support the WG adoption of them.
Thanks,
Rakesh

From: ippm <[email-masked]> on behalf of Tommy Pauly <tpauly=[email-masked]>
Date: Tuesday, August 3, 2021 at 12:29 PM
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: [ippm] Adoption call for IOAM deployment and integrity documents
Hello IPPM,

In-situ OAM Deployment

Best,
Tommy & Ian

---

From: "Srihari Raghavan (srihari)" <[email-masked]>
Date: Wed, 11 Aug 2021 02:58:14 +0000

WG and Chairs,

Have been working with iOAM for some time and have contributed as draft-ietf-ippm-ioam-yang.

From the experience, support the WG adoption of both the documents listed below.

Thanks,
Srihari

From: ippm <[email-masked]> on behalf of Tommy Pauly <tpauly=[email-masked]>
Date: Tuesday, 3 August 2021 at 9:59 PM
To: "IETF IPPM WG ([email-masked])" <[email-masked]>
Subject: [ippm] Adoption call for IOAM deployment and integrity documents

Hello IPPM,

In-situ OAM Deployment

Best,
Tommy & Ian

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 11 Aug 2021 09:11:57 +0300

I support the adoption of both drafts (as a co-author).

Both drafts have been discussed by the WG, and both have been
discussed in the IESG review of the IOAM data draft.

Cheers,
Tal.

On Tue, Aug 3, 2021 at 7:29 PM Tommy Pauly
<tpauly=[email-masked]> wrote:
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Wed, 11 Aug 2021 10:08:26 +0000

Having implemented iOAM as a developer, support the WG adoption of both the documents listed below.

Thanks,
Srihari

From: ippm <[email-masked]<mailto:[email-masked]>> on behalf of Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>
Date: Tuesday, 3 August 2021 at 9:59 PM
To: "IETF IPPM WG ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Subject: [ippm] Adoption call for IOAM deployment and integrity documents

Hello IPPM,

In-situ OAM Deployment

Best,
Tommy & Ian

---

From: Justin Iurman <[email-masked]>
Date: Wed, 11 Aug 2021 12:33:40 +0200 (CEST)

I support the adoption of both drafts (mainly as a developer). I do believe that the deployment draft is a good summary and entry point for IOAM while the integrity draft addresses security concerns raised previously.

Thanks,
Justin

> Hello IPPM,
> 
> As discussed in our meeting last week, we will be starting an adoption call for
> two IOAM-related documents that have been raised as important dependencies
> during the IESG review of IOAM-data.
> 
> [ https://datatracker.ietf.org/doc/draft-brockners-ippm-ioam-data-integrity/ |
> https://datatracker.ietf.org/doc/draft-brockners-ippm-ioam-data-integrity/ ]
> [
> |
> ]
> [ https://datatracker.ietf.org/doc/draft-brockners-opsawg-ioam-deployment/ |
> https://datatracker.ietf.org/doc/draft-brockners-opsawg-ioam-deployment/ ]
> [
> |
> ]
> This call will last until Wednesday, August 18 . Please reply to this email with
> your comments, and if you think these documents should be taken on by IPPM.
> 
> Best,
> Tommy & Ian
>

---

From: "Ramesh Sivakolundu (sramesh)" <[email-masked]>
Date: Wed, 11 Aug 2021 15:41:12 +0000

WG and Chairs,

Have been working with iOAM for some time and have contributed in the discussion that has led to the call for adoption of these two documents.

I support the WG adoption of both the documents listed below.

Thanks,
-Ramesh

From: ippm <[email-masked]> on behalf of Tommy Pauly <tpauly=[email-masked]>
Date: Tuesday, August 3, 2021 at 9:29 AM
To: "IETF IPPM WG ([email-masked])" <[email-masked]>
Subject: [ippm] Adoption call for IOAM deployment and integrity documents

Hello IPPM,

In-situ OAM Deployment

Best,
Tommy & Ian

---

From: <[email-masked]>
Date: Thu, 12 Aug 2021 05:52:05 +0800 (CST)

Hi Tommy and Ian,

I've read both documents (I might be guilty of causing one of them to be written). I've found both documents well-written and are essential to the IOAM technology. Overall, drafts are ready for WG adoption. I'll support WG with my reviews and comments.

Regards,

Greg Mirsky

Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division

E: [email-masked] 
www.zte.com.cn

Original Mail

Sender: TommyPauly
To: IETF IPPM WG ([email-masked]);
Date: 2021/08/03 09:29
Subject: [ippm] Adoption call for IOAM deployment and integrity documents

Hello IPPM,

In-situ OAM Deployment

Best,

Tommy & Ian

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 12 Aug 2021 02:24:38 +0000

Hi WG,

I support the adoption of both two drafts.

Cheers,
Tianran

From: ippm [mailto:[email-masked]] On Behalf Of Tommy Pauly
Sent: Wednesday, August 4, 2021 12:29 AM
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: [ippm] Adoption call for IOAM deployment and integrity documents

Hello IPPM,

In-situ OAM Deployment

Best,
Tommy & Ian

---

From: <[email-masked]>
Date: Thu, 12 Aug 2021 11:04:44 +0800 (CST)

Hi all,

Support WG adoption of these two IOAM documents.
For Section 5 of IOAM deployment draft - IOAM Encapsulations, suggest to add BIER(draft-xzlnp-bier-ioam) into the scope.

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：TommyPauly
收件人：IETF IPPM WG ([email-masked]);
日 期 ：2021年08月04日 00:29
主 题 ：[ippm] Adoption call for IOAM deployment and integrity documents
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

Hello IPPM,

---

From: "Wangyali(Yali,Data Communication Standards and Patents Dept)" <[email-masked]>
Date: Thu, 12 Aug 2021 08:32:23 +0000

Hi Tommy and Ian,

Having read these two drafts, which are significant for IOAM implementation and security. I support the adoption of both two drafts.

Best,
Yali

Hello IPPM,

In-situ OAM Deployment

Best,
Tommy & Ian

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 12 Aug 2021 19:56:40 +0000

Hi, Tommy and Ian,

I support these two documents becoming adopted as WG documents. Yes, I have read them and believe they both should be taken on by IPPM.

Thanks,

—
Carlos Pignataro, http://carlos.pignataro.net

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

8/3/21 午後0:28、Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>のメール:

Hello IPPM,

In-situ OAM Deployment

Best,
Tommy & Ian
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

---

From: "MORTON JR., AL" <[email-masked]>
Date: Mon, 16 Aug 2021 00:18:39 +0000

Hi Tommy, Authors, and IPPM,

I took a look at one of the drafts the WG is considering:

For Integrity of In-situ OAM Data Fields, I got tripped-up by the first sentence of the Abstract 😊,

   In-situ Operations, Administration, and Maintenance (IOAM) records
   operational and telemetry information in the packet while the packet
   traverses a path between two points in the network.

I read “records” as a noun, not as a verb as I now see was intended. maybe s/records/collects/ to resolve that ambiguity.

Then the second sentence:

   ...  IOAM deployments
   could require ensuring the integrity of IOAM data fields.

Maybe we can say more specifically what needs to be done, something like:

IETF protocols require features to ensure their security; this document describes integrity protect for IOAM data fields.

In the Intro, after saying:
   As such, IOAM tracing data is carried in
   the packets in clear and there are no protections against any node or
   middlebox tampering with the data.

the draft says:
...  As a consequence, IOAM tracing
   data collected in an untrusted or semi-trusted environments cannot be
   trusted for critical operational decisions.

I think this is where the draft should indicate that a form of integrity protection is the solution to the problem, such as:

...IOAM tracing data collected in an untrusted or semi-trusted environments
   requires integrity protection to support critical operational decisions.

Parts of the intro need to move beyond the “this is for IPPM WG study” phase, to the “here’s the integrity protection solution(s)” voice.

Otherwise, the threat analysis is useful, and the Methods of providing integrity to IOAM data fields seem clear.

I support the adoption of “Integrity of In-situ OAM Data Fields” for additional development by the WG.

Al

From: ippm <[email-masked]> On Behalf Of Tommy Pauly
Sent: Tuesday, August 3, 2021 12:29 PM
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: [ippm] Adoption call for IOAM deployment and integrity documents

Hello IPPM,

Integrity of In-situ OAM Data Fields
https://datatracker.ietf.org/doc/draft-brockners-ippm-ioam-data-integrity/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-brockners-ippm-ioam-data-integrity/__;!!BhdT!0Ny1D5V4maIuQ6qGnzMqhb2g1XeWhqAWW3MMMWLT5TI-730YRx2JHVbaSFNx$>
https://www.ietf.org/archive/id/draft-brockners-ippm-ioam-data-integrity-03.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-brockners-ippm-ioam-data-integrity-03.html__;!!BhdT!0Ny1D5V4maIuQ6qGnzMqhb2g1XeWhqAWW3MMMWLT5TI-730YRx2JHQVTAIy3$>

In-situ OAM Deployment
https://datatracker.ietf.org/doc/draft-brockners-opsawg-ioam-deployment/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-brockners-opsawg-ioam-deployment/__;!!BhdT!0Ny1D5V4maIuQ6qGnzMqhb2g1XeWhqAWW3MMMWLT5TI-730YRx2JHUSOBrbQ$>
https://datatracker.ietf.org/doc/html/draft-brockners-opsawg-ioam-deployment-03<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-brockners-opsawg-ioam-deployment-03__;!!BhdT!0Ny1D5V4maIuQ6qGnzMqhb2g1XeWhqAWW3MMMWLT5TI-730YRx2JHWwp9dBH$>

Best,
Tommy & Ian

---

From: "MORTON JR., AL" <[email-masked]>
Date: Mon, 16 Aug 2021 23:30:16 +0000

Hi Tommy & Ian, Authors, and IPPM,

I took a look at the other draft the WG is considering.

TL;DR: I support adoption, and further development/review.

For In-situ OAM Deployment, the first sentence of the Abstract is the same as data Integrity, so same comment.

I note that this draft is intended as a BCP. It will be interesting to see if there is sufficient experience when the WG is reaching consensus to warrant BCP status, and we can leave this aspiration intact during WG adoption, IMO.

I appreciate that Section 4 (Types of IOAM) motivates deployment by describing use cases. But after introducing IOAM node roles, the draft should use that terminology in this section. Also, the ECMP acronym and load balancing got mixed together in an odd way. Last, "end-to-end" is used ambiguously in the Operations/Troubleshooting bullet:

Current:
   o  Per-hop tracing: OAM information about each IOAM node a packet
      traverses is collected and stored within the user data packet as
      the packet progresses through the IOAM domain.  Potential uses of
      IOAM per-hop tracing include:

      *  Optimization: Understand the different paths different packets
         traverse between a source and a sink in a network that uses
         load balancing such as Equal Cost Load Balancing (ECMP).  This
         information could be used to tune the algorithm for ECMP for
         optimized network resource usage.

      *  Operations/Troubleshooting: Understand which path a particular
         packet or set of packets take as well as what amount of jitter
         and delay different nodes in the path contribute to the overall
         end-to-end delay and jitter.

Suggest:
   o  Per-hop tracing: OAM information about each IOAM node a packet
      traverses is collected and stored within the user data packet as
      the packet progresses through the IOAM domain.  Potential uses of
      IOAM per-hop tracing include:

      *  Optimization: Understand the different paths different packets
|        traverse between a Encapsulating and a Decapsulating node in a network that uses
|        load balancing such as Equal Cost Multi-Path (ECMP).  This
         information could be used to tune the algorithm for ECMP for
         optimized network resource usage.

      *  Operations/Troubleshooting: Understand which path a particular
         packet or set of packets take as well as what amount of jitter
|        and delay different IOAM nodes in the path contribute to the overall
|        <source host to destination host ??> delay and jitter.

There seem to be many options for deployment, such as whether to use IOAM Direct Export in *Transit Nodes*, but it seems that some form of export is required at the edge nodes (Encap & Decap). In the context of this draft as a BCP, what (export) option is best for certain circumstances?

The term "best" only appears twice, on the first page. So please look for some circumstances where the best choice of options is clear, and call them out specifically, like "Pre-allocated Trace-Option is best-suited for software packet forwarder implementations." But
      "The operator has to ensure that the packet with the pre-allocated
      array that carries the IOAM Data-Fields does not exceed the MTU of
      any of the links in the IOAM domain."
The material provided in Section 7.3. IOAM Trace Option Types is closer to a BCP than other parts of the draft.

Regarding:
      ..."The operator
      has to ensure that the minimum MTU of any of the links in the IOAM
      domain is known to all IOAM transit nodes."
Each IOAM node knows the MTU of all its interconnecting links. So:
 - Isn't there some way the IOAM nodes can take the burden to discover and share the MTU info within the domain?
 - In a network domain with non-IOAM nodes and IOAM nodes, in what deployment scenario would the MTU-view of the IOAM nodes remain valid for the entire domain?

In 7.6 IOAM Active Mode:
(I'm sorry, I fell off the sled completely here.)

   The IOAM active mode flag indicates that a packet is an active OAM
   packet as opposed to regular user data traffic.  Active mode is
   expected to be used for active measurement using IOAM.  Example use-
   cases include:

   o  Endpoint detailed active measurement: Synthetic probe packets are
      sent between the source and destination, traversing the IOAM
      domain.  These probe packets include a Trace Option-Type (i.e.,
      either incremental or pre-allocated).
Are the source and destination outside the IOAM Domain?  Figure 1 of the flags draft says yes (?).
(But the packets seem to carry IOAM information/data into the domain, somehow.)

      Since the probe packets are
      sent between the endpoints, these packets are treated as data
      packets by the IOAM domain, and do not require special treatment
      at the IOAM layer.
So, the probe packets ARE encapsulated, like other data packets would be?
("do not require special treatment" is not clear to me.)

               The encapsulating node can choose to set the
      Active flag, providing an explicit indication that these probe
      packets are meant for telemetry collection.

Ok, but the flags draft says:
     The active flag indicates that a packet is used for active
     measurement.  An IOAM decapsulating node that receives a packet with
     the Active flag set in one of its Trace options must terminate the
     packet.
and then the Synthetic probe packets don't reach the intended destination,
beyond the IOAM domain ?? It would be good to make this clear(er).

In any case, I suggest to move the reference to the flags draft:
   For details on IOAM active mode, please refer to
   [I-D.ietf-ippm-ioam-flags].
very early in this section - don't place this reference in the last sentence.

hope this helps,
Al

Hello IPPM,

In-situ OAM Deployment

Best,
Tommy & Ian

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 17 Aug 2021 02:00:37 +0000

This is excellent work and I support it's adoption.

IOAM will provide operators critical management information that is badly lacking today.  This is a reason many enterprises delay IPv6 deployment and IOAM will be very beneficial in this regard and others as well.

Providing integrity will also remove another set of deployment related concerns.

Other key concerns are in the areas of operational adding complexity and resulting overhead or potential performance issues.    These areas seem to be addressed in the draft as well, but I have a related question/concern.
 As an enterprise operator, deploying anything new is always a challenge.  And if other new solutions for integrity of EHs choose different solutions, then this challenge becomes magnified.  Then potentially add confidentiality , authentication, etc. and the situation could quickly become a morass of solutions.    So my question is  if there is any chance of considering a more holistic approach to related or similar solutions?

Once again, please keep up the great work!

Thanks

Mike

[External email]
Hello IPPM,

In-situ OAM Deployment

Best,
Tommy & Ian

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

This message was secured by Zix(R).

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 17 Aug 2021 18:54:21 +0000

Hi Al,

Thanks a lot for your review and support. Please see inline.

From: ippm <[email-masked]> On Behalf Of MORTON JR., AL
Sent: Montag, 16. August 2021 02:19
To: Tommy Pauly <tpauly=[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: Re: [ippm] Adoption call for IOAM deployment and integrity documents

…FB: That is a good suggestion. We’ll use “collect” instead of “record” moving forward.

   ...  IOAM deployments

IETF protocols require features to ensure their security; this document describes integrity protect for IOAM data fields.
…FB: Another good suggestion. Similar to what you note below, the heritage of the above sentence is that the document started as an informational document discussing options for integrity protection.

the draft says:

…FB: Good points. We’ll fix those in the next rev – and ensure that the doc uses the appropriate language for a standards track document.

Thanks again Al.

Cheers, Frank

Al

From: ippm <[email-masked]<mailto:[email-masked]>> On Behalf Of Tommy Pauly
Sent: Tuesday, August 3, 2021 12:29 PM
To: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: [ippm] Adoption call for IOAM deployment and integrity documents

Hello IPPM,

In-situ OAM Deployment

Best,
Tommy & Ian

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 18 Aug 2021 10:54:05 -0700

Hello IPPM,

Thanks to everyone who provided feedback and reviews of these documents! We do have WG support for adopting these.

Authors, please submit draft-ietf-ippm-*-00 versions when ready, ideally incorporating any comments received during the adoption call.

Best,
Tommy & Ian

> On Aug 3, 2021, at 9:28 AM, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> Hello IPPM,
>