Subject: Re: [OPSAWG] Call for Agenda Items for Buenos Aires

From: Petr Lapukhov <[email-masked]>
Date: Fri, 18 Mar 2016 13:41:56 +0000

Folks,

If possible I would like to request a slot on the agenda to present

https://datatracker.ietf.org/doc/draft-lapukhov-dataplane-probe/

This to start work on in-band telemetry format standardization. The technology is still at early stages, and I believe it would be helpful to agree on common formats to be used across multiple silicon vendors.

Looking for feedback and finding a best place to continue this work at.

Thanks!

Petr

---

From: "Scott O. Bradner" <[email-masked]>
Date: Fri, 18 Mar 2016 19:27:22 -0400

sorry but our agenda filled up a while back

I would suggest sending a note to the mailing list pointing to your ID and asking for review and
asking the WG if they think the topic is right for opsawg

Scott

> On Mar 18, 2016, at 9:41 AM, Petr Lapukhov <[email-masked]> wrote:
> 
> Folks,
>

---

From: Randy Bush <[email-masked]>
Date: Sat, 19 Mar 2016 12:30:19 +0900

> https://datatracker.ietf.org/doc/draft-lapukhov-dataplane-probe/

given the heavy per-hop payload, do you have estimates on how many hops
with an mtu of 512?  or is this really meant for use within an
operator/datacenter, and maybe one with junbo frames?

i do not understand the relationship of the Telemetry Record Template to
the Telemetry Record.  are these two separate list structures with
reduncancy?  or is it one list and the Telemetry Record Template (which
has TL but no V) is just there to confuse me?

randy

---

From: Melinda Shore <[email-masked]>
Date: Fri, 18 Mar 2016 19:42:30 -0800

I actually proposed something very much like this about 15 years
ago, based on a flexible transport layer that could deal with things
like NAT and with both authentication and authorization (I'm always
dismayed by proposals that are hand-wavey about security, baffled by
ones that don't mention it at all).  I think it's generally a good
idea even if the proposal is flawed.

Given that he's punted on both security and transport it may be better
to treat this as an information model or what-have-you rather than
as a complete protocol.

Melinda

---

From: Randy Bush <[email-masked]>
Date: Sat, 19 Mar 2016 12:48:05 +0900

the paragraph i deleted before sending was

  [ i do have sympathy for the motivation.  heck, nick duffield suckered
    me in the days when at&t had a research lab, but veered left into
    trajectory sampling and the psamp stuff. ]

i missed your stuff; apologies.  a cite would be good.

i do see the need for something in this space, for sure.

agree that security is critical; though i suspect the authors were more
oriented to intra-operator.  we all know how that ends up.

> to treat this as an information model or what-have-you rather than as
> a complete protocol.

would you like a saucer of yang milk?  :)

randy

---

From: Petr Lapukhov <[email-masked]>
Date: Sat, 19 Mar 2016 05:50:57 +0000

Hi Randy,

You are right, the primary use case is data-center network, with its specific devices: e.g. multiple shared-memory-buffer chips connected in Clos topology. The typical MTU I've seen so far there is still 1500, even though enabling jumbo framing is generally not a problem. However, the use of GRO and interrupt coalescing on host side made the need for jumbo MTU less pressuring.

The idea behind the "template" field was to inform the network device of the TLVs that are being "requested" by the originator of the message, along with the full spec of the field sizes. The device would then fill in the "slots" it can fill in, e.g. the device identifier, ingress/egress ports. This allows the originator to request for "lots of stuff", but get back the info supported by each individual device. I did receive feedback from some of the folks working on silicon side that parsing the template might be "somewhat" expensive, though not impossible. I'm continuing that conversation to get closer to "real" possibilities of the upcoming silicon. 

I mainly started the document to bring the in-band telemetry to the attention of the general network community. To us (facebook neteng) the ability to embed device state in data-plane packets is an important enabler for real-time fault isolation in the network (our current methodologies are based on some variations around fast/wide traceroute).

Regards,

Petr
________________________________________
From: Randy Bush [[email-masked]]
Sent: Friday, March 18, 2016 8:30 PM
To: Petr Lapukhov
Cc: opsawg
Subject: Re: [OPSAWG] Call for Agenda Items for Buenos Aires

> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dlapukhov-2Ddataplane-2Dprobe_&d=CwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=LU_vJaM_EQu1Ssm35j2xlA&m=uBG5ONHmU7YzsFZ9R25b6TL-l0JZUYFvwDLEAWPqEnA&s=IAtJOy3uPSUJUcEYqZI85xYPTWOcuSQEvcxRddmryAs&e=

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 19 Mar 2016 15:20:37 +0900

petr,

> You are right, the primary use case is data-center network, with its
> specific devices: e.g. multiple shared-memory-buffer chips connected
> in Clos topology. The typical MTU I've seen so far there is still
> 1500, even though enabling jumbo framing is generally not a problem.
> However, the use of GRO and interrupt coalescing on host side made the
> need for jumbo MTU less pressuring.

i have sympathy for this.  but there is too much experience with things
designed for the LAN ending up on the WAN.  hence melinda's concern for
security, mine for mtu, etc.

but this is a good start for a discussion.  there has been need for
something in this space since before dirt was invented.  and there have
been a number of tries. i am willing to keep reading and to have useless
opinions.

randy