| Newsgroups |
gmane.ietf.ops,gmane.ietf.opsawg,gmane.ietf.ippm |
| Message-ID |
<[email protected]> |
This is a multi-part message in MIME format.
--===============2782718267509748467==
Content-Type: multipart/alternative;
boundary="------------1GEt9FAdrsaw9eRkFNW17j2V"
Content-Language: en-US, fr
This is a multi-part message in MIME format.
--------------1GEt9FAdrsaw9eRkFNW17j2V
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Dear all,
On that front of foo-over-QUIC Operational Motivations & Challenges, we
have been posting this brand new draft
URL:https://www.ietf.org/archive/id/draft-netana-opsawg-telemetry-over-quic-00.txt
Status:https://datatracker.ietf.org/doc/draft-netana-opsawg-telemetry-over-quic/
HTML:https://www.ietf.org/archive/id/draft-netana-opsawg-telemetry-over-quic-00.html
HTMLized:https://datatracker.ietf.org/doc/html/draft-netana-opsawg-telemetry-over-quic
QUIC Transport for Network Telemetry
draft-netana-opsawg-telemetry-over-quic-00
Abstract
This document describes the use of the QUIC transport protocol as a
common transport substrate for operational Network Telemetry
protocols that currently rely on UDP. Specifically, it discusses
carrying protocols such as IPFIX, Syslog, YANG-Push UDP-Notif, and
RADIUS Accounting over QUIC connections. For telemetry protocols
whose data plane is inherently loss-tolerant (where a missing sample
is preferable to a delayed retransmission) this document recommends
use of the Unreliable Datagram Extension to QUIC (DATAGRAM frames).
A primary motivation for this work is the unification of transport-
layer security across heterogeneous telemetry protocols. Protocols
that currently have no mandatory transport security (syslog over UDP)
or optional-only security (IPFIX over UDP with DTLS) or weak security
(RADIUS with MD5 obfuscation) would all benefit from the mandatory
TLS 1.3 mutual authentication that QUIC provides. This document
specifically addresses the operational advantages of managing a
single PKI certificate lifecycle per Network Node to authenticate all
telemetry streams.
This document is intended as a framework and applicability statement.
Per-protocol bindings that require normative specification are
expected to be chartered in their respective IETF working groups.
Regards, Benoit (on behalf of the authors)
On 02/04/2026 17:33, [email protected] wrote:
>
> Hi all
>
> Many proposals (*) are being promoted in several IETF WGs to port
> protocols widely used in operator networks to be transported over
> QUIC. There are several technical arguments that motivate such
> extensions, however, porting protocols used within operator networks
> to support QUIC would have some impacts on fault isolation,
> troubleshooting, etc. Because of the lack of the visibility on the
> transport headers, providing feature parity may be challenging without
> tools upgrade and also logistic (e.g., synchronize keys to decode
> messages, etc.).
>
> There is a need to (1) have a common understanding of the operational
> benefits, (2) understand the underlying challenges that can be
> inherited especially when the connection endpoints are not adjacent to
> each others, and (3) identify deployment incentives especially when
> there are alternate mechanisms to achieve similar objectives (TLS,
> etc.), (4) identify whether there are specific missing QUIC features
> that would ease use in operators network , and (5) explore whether
> there is common operational guidance that can inform most of these
> extensions (and similar).
>
> Per (cced) kindly accepted to coordinate and lead the discussion on
> this topic. Per will be presenting the outcome during IETF#126. Many
> thanks Per!
>
> This is thus a call for inputs and feedback on this topic. Feel free
> to use this thread, get in touch with Per, or fill PRs/Issues using
> https://github.com/IETF-OPS-AD/foo-over-QUIC-Operational-Considerations
> <https://github.com/IETF-OPS-AD/foo-over-QUIC-Operational-Considerations>.
>
>
> Thank you
>
> Cheers,
>
> Med
>
> (*)
>
> * draft-ietf-netconf-over-quic
> <https://datatracker.ietf.org/doc/draft-ietf-netconf-over-quic/>:
> NETCONF over QUIC
> * draft-liu-grow-bmp-over-quic
> <https://datatracker.ietf.org/doc/draft-liu-grow-bmp-over-quic/>:
> Using BMP over QUIC connection
> * draft-liu-sidrops-rpki-rtr-over-quic
> <https://datatracker.ietf.org/doc/draft-liu-sidrops-rpki-rtr-over-quic/>:
> RPKI to Router Protocol over QUIC
> * draft-llg-opsawg-ipfix-over-quic
> <https://datatracker.ietf.org/doc/draft-llg-opsawg-ipfix-over-quic/>:
> IPFIX Protocol over QUIC
> * draft-retana-idr-bgp-quic
> <https://datatracker.ietf.org/doc/draft-retana-idr-bgp-quic/>: BGP
> over QUIC
> * draft-yl-radext-quic-transport
> <https://datatracker.ietf.org/doc/draft-yl-radext-quic-transport/>:
> RADIUS over QUIC
> * draft-yang-pce-pcep-over-quic
> <https://datatracker.ietf.org/doc/draft-yang-pce-pcep-over-quic/>:
> PCEP over QUIC
> * draft-cel-nfsv4-rpc-over-quicv1
> <https://datatracker.ietf.org/doc/draft-cel-nfsv4-rpc-over-quicv1/>:
> Remote Procedure Call over QUIC Version 1
> * draft-ietf-regext-epp-quic
> <https://datatracker.ietf.org/doc/draft-ietf-regext-epp-quic/>:
> Extensible Provisioning Protocol (EPP) Transport over QUIC
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> ippm mailing list [email protected]
> To unsubscribe send an email [email protected]
--------------1GEt9FAdrsaw9eRkFNW17j2V
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Dear all,<br>
<br>
On that front of foo-over-QUIC Operational Motivations &
Challenges, we have been posting this brand new draft<br>
<br>
<pre wrap="" class="moz-quote-pre">URL: <a
class="moz-txt-link-freetext"
href="https://www.ietf.org/archive/id/draft-netana-opsawg-telemetry-over-quic-00.txt">https://www.ietf.org/archive/id/draft-netana-opsawg-telemetry-over-quic-00.txt</a>
Status: <a class="moz-txt-link-freetext"
href="https://datatracker.ietf.org/doc/draft-netana-opsawg-telemetry-over-quic/">https://datatracker.ietf.org/doc/draft-netana-opsawg-telemetry-over-quic/</a>
HTML: <a class="moz-txt-link-freetext"
href="https://www.ietf.org/archive/id/draft-netana-opsawg-telemetry-over-quic-00.html">https://www.ietf.org/archive/id/draft-netana-opsawg-telemetry-over-quic-00.html</a>
HTMLized: <a class="moz-txt-link-freetext"
href="https://datatracker.ietf.org/doc/html/draft-netana-opsawg-telemetry-over-quic">https://datatracker.ietf.org/doc/html/draft-netana-opsawg-telemetry-over-quic</a></pre>
<br>
<pre> QUIC Transport for Network Telemetry
draft-netana-opsawg-telemetry-over-quic-00
Abstract
This document describes the use of the QUIC transport protocol as a
common transport substrate for operational Network Telemetry
protocols that currently rely on UDP. Specifically, it discusses
carrying protocols such as IPFIX, Syslog, YANG-Push UDP-Notif, and
RADIUS Accounting over QUIC connections. For telemetry protocols
whose data plane is inherently loss-tolerant (where a missing sample
is preferable to a delayed retransmission) this document recommends
use of the Unreliable Datagram Extension to QUIC (DATAGRAM frames).
A primary motivation for this work is the unification of transport-
layer security across heterogeneous telemetry protocols. Protocols
that currently have no mandatory transport security (syslog over UDP)
or optional-only security (IPFIX over UDP with DTLS) or weak security
(RADIUS with MD5 obfuscation) would all benefit from the mandatory
TLS 1.3 mutual authentication that QUIC provides. This document
specifically addresses the operational advantages of managing a
single PKI certificate lifecycle per Network Node to authenticate all
telemetry streams.
This document is intended as a framework and applicability statement.
Per-protocol bindings that require normative specification are
expected to be chartered in their respective IETF working groups.
Regards, Benoit (on behalf of the authors)</pre>
<br>
<br>
<div class="moz-cite-prefix">On 02/04/2026 17:33,
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:PATP264MB676505917F8C7EACD83CED468851A@PATP264MB6765.FRAP264.PROD.OUTLOOK.COM">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator"
content="Microsoft Word 15 (filtered medium)">
<style>@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;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Aptos",sans-serif;
mso-ligatures:standardcontextual;
mso-fareast-language:EN-US;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#467886;
text-decoration:underline;}span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Courier New";
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:11.0pt;
mso-fareast-language:EN-US;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0cm;}ul
{margin-bottom:0cm;}</style>
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-family:"Courier New"">Hi all<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"
style="font-family:"Courier New"">Many proposals
(*) are being promoted in several IETF WGs to port protocols
widely used in operator networks to be transported over
QUIC. There are several technical arguments that motivate
such extensions, however, porting protocols used within
operator networks to support QUIC would have some impacts on
fault isolation, troubleshooting, etc. Because of the lack
of the visibility on the transport headers, providing
feature parity may be challenging without tools upgrade and
also logistic (e.g., synchronize keys to decode messages,
etc.).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"
style="font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"
style="font-family:"Courier New"">There is a need
to (1) have a common understanding of the operational
benefits, (2) understand the underlying challenges that can
be inherited especially when the connection endpoints are
not adjacent to each others, and (3) identify deployment
incentives especially when there are alternate mechanisms to
achieve similar objectives (TLS, etc.), (4) identify whether
there are specific missing QUIC features that would ease use
in operators network , and (5) explore whether there is
common operational guidance that can inform most of these
extensions (and similar).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"
style="font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"
style="font-family:"Courier New"">Per (cced)
kindly accepted to coordinate and lead the discussion on
this topic. Per will be presenting the outcome during
IETF#126. Many thanks Per!<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"
style="font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"
style="font-family:"Courier New"">This is thus a
call for inputs and feedback on this topic. Feel free to use
this thread, get in touch with Per, or fill PRs/Issues using
</span><span style="font-family:"Courier New""><a
href="https://github.com/IETF-OPS-AD/foo-over-QUIC-Operational-Considerations"
moz-do-not-send="true"><span lang="EN-US">https://github.com/IETF-OPS-AD/foo-over-QUIC-Operational-Considerations</span></a></span><span
lang="EN-US" style="font-family:"Courier New"">.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"
style="font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"
style="font-family:"Courier New"">Thank you<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"
style="font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Courier New"">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Courier New"">Med<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Courier New"">(*)<o:p></o:p></span></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoNormal" style="mso-list:l0 level1 lfo2"><span
style="font-family:"Courier New""><a
href="https://datatracker.ietf.org/doc/draft-ietf-netconf-over-quic/"
moz-do-not-send="true"><span lang="EN-US">draft-ietf-netconf-over-quic</span></a></span><span
lang="EN-US" style="font-family:"Courier New"">:
NETCONF over QUIC<o:p></o:p></span></li>
<li class="MsoNormal" style="mso-list:l0 level1 lfo2"><span
style="font-family:"Courier New""><a
href="https://datatracker.ietf.org/doc/draft-liu-grow-bmp-over-quic/"
moz-do-not-send="true"><span lang="EN-US">draft-liu-grow-bmp-over-quic</span></a></span><span
lang="EN-US" style="font-family:"Courier New"">:
Using BMP over QUIC connection<o:p></o:p></span></li>
<li class="MsoNormal" style="mso-list:l0 level1 lfo2"><span
style="font-family:"Courier New""><a
href="https://datatracker.ietf.org/doc/draft-liu-sidrops-rpki-rtr-over-quic/"
moz-do-not-send="true"><span lang="EN-US">draft-liu-sidrops-rpki-rtr-over-quic</span></a></span><span
lang="EN-US" style="font-family:"Courier New"">:
RPKI to Router Protocol over QUIC<o:p></o:p></span></li>
<li class="MsoNormal" style="mso-list:l0 level1 lfo2"><span
style="font-family:"Courier New""><a
href="https://datatracker.ietf.org/doc/draft-llg-opsawg-ipfix-over-quic/"
moz-do-not-send="true"><span lang="EN-US">draft-llg-opsawg-ipfix-over-quic</span></a></span><span
lang="EN-US" style="font-family:"Courier New"">:
IPFIX Protocol over QUIC<o:p></o:p></span></li>
<li class="MsoNormal" style="mso-list:l0 level1 lfo2"><span
style="font-family:"Courier New""><a
href="https://datatracker.ietf.org/doc/draft-retana-idr-bgp-quic/"
moz-do-not-send="true"><span lang="EN-US">draft-retana-idr-bgp-quic</span></a></span><span
lang="EN-US" style="font-family:"Courier New"">:
BGP over QUIC<o:p></o:p></span></li>
<li class="MsoNormal" style="mso-list:l0 level1 lfo2"><span
style="font-family:"Courier New""><a
href="https://datatracker.ietf.org/doc/draft-yl-radext-quic-transport/"
moz-do-not-send="true"><span lang="EN-US">draft-yl-radext-quic-transport</span></a></span><span
lang="EN-US" style="font-family:"Courier New"">:
RADIUS over QUIC<o:p></o:p></span></li>
<li class="MsoNormal" style="mso-list:l0 level1 lfo2"><span
style="font-family:"Courier New""><a
href="https://datatracker.ietf.org/doc/draft-yang-pce-pcep-over-quic/"
moz-do-not-send="true"><span lang="EN-US">draft-yang-pce-pcep-over-quic</span></a></span><span
lang="EN-US" style="font-family:"Courier New"">:
PCEP over QUIC<o:p></o:p></span></li>
<li class="MsoNormal" style="mso-list:l0 level1 lfo2"><span
style="font-family:"Courier New""><a
href="https://datatracker.ietf.org/doc/draft-cel-nfsv4-rpc-over-quicv1/"
moz-do-not-send="true"><span lang="EN-US">draft-cel-nfsv4-rpc-over-quicv1</span></a></span><span
lang="EN-US" style="font-family:"Courier New"">:
Remote Procedure Call over QUIC Version 1<o:p></o:p></span></li>
<li class="MsoNormal" style="mso-list:l0 level1 lfo2"><span
style="font-family:"Courier New""><a
href="https://datatracker.ietf.org/doc/draft-ietf-regext-epp-quic/"
moz-do-not-send="true"><span lang="EN-US">draft-ietf-regext-epp-quic</span></a></span><span
lang="EN-US" style="font-family:"Courier New"">:
Extensible Provisioning Protocol (EPP) Transport over QUIC<o:p></o:p></span></li>
</ul>
<p class="MsoNormal"><span lang="EN-US"
style="font-family:"Courier New""><o:p> </o:p></span></p>
</div>
<pre>_________________<wbr>______________________________<wbr>______________________________<wbr>______________________________<wbr>_
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.</pre>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
ippm mailing list -- <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
To unsubscribe send an email to <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------1GEt9FAdrsaw9eRkFNW17j2V--
--===============2782718267509748467==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KT1BTLUFSRUEg
bWFpbGluZyBsaXN0IC0tIG9wcy1hcmVhQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4g
ZW1haWwgdG8gb3BzLWFyZWEtbGVhdmVAaWV0Zi5vcmcK
--===============2782718267509748467==--