Brian,
Thank you very much for the detailed explanation.
Linda
From: Brian Sipos
Date: Friday, October 21, 2022 at 6:16 PM
To: Linda Dunbar
Cc: Deb Cooley , Roman Danyliw ,
"ops-...@ietf.org" , "acme@ietf.org" ,
"draft-ietf-acme-dtnnodeid@ietf.org"
, "last-c...@ietf.org"
Subject: Re:
Linda,
To provide some clarification: a "delay-tolerant network" isn't just a
descriptive term, it is a specific type of overlay network operating with
the Bundle Protocol of RFC 9171 in accordance with the principals of RFC
4838. This proposed validation method is both conceptually and procedurall
Deb,
The discussion stemmed from my question about the mechanism specified in the
draft-ietf-acme-dtnnodeid-10 not touching upon the special properties of Delay
Tolerant. For example, are there any special considerations for the satellite
network that requires hours or days of the round trip in
Linda,
I'm now very confused. The original topic was comments on a DTN acme
draft. How did we get to discussing Virtual Network IDs of SD-WAN edge
devices?
Do you want to get X.509 certificates for these devices? Or do you have
something else in mind to validate these devices?
Deb Cooley
On
Roman,
Thanks.
I don't see how DTN wg is relevant, as the SD-WAN is NOT Delay Tolerant
Network. More relevance is on the "certificate issuance mechanism" to validate
if the IDs advertised by a remote node are legitime.
Does ACME Wg work on "Certificate issuance mechanism" for remote node IDs
IMO, the simplest thing would be to pose this question on the DTN WG mailing
list. This very specific work is being done in the ACME WG because it has the
expertise on the certificate issuance mechanism, but I see you applicability to
SD-WAN as more general.
Roman
> -Original Message-
Roman,
Can you give me a few names with who I can chat to find out more?
Thank you
Linda
On 10/21/22, 12:38 PM, "Roman Danyliw" wrote:
Hi Linda!
As I understand the scenario below, it would align to the work in this
document only to the degree that the SD-WAN network would be an
Hi Linda!
As I understand the scenario below, it would align to the work in this document
only to the degree that the SD-WAN network would be an underlay to the DTN
Bundle Protocol (via some as of yet undefined convergence layer) and the
Virtual Network IDs would have an easy mapping to the DTN
Roman,
Can the mechanism specified in the draft be used to validate the Virtual
Network IDs of SD-WAN edge devices?
For example, an SDWAN edge deployed in a remote site, say a shopping mall,
might advertise the routes and client VPN IDs to the BGP Route-Reflector (RR).
The RR needs to validat
Roman,
With you bringing back the explanation, all makes sense to me now. Wish your
explanation is incorporated into the document.
Thanks, Linda
On 10/20/22, 6:53 PM, "Roman Danyliw" wrote:
Thanks for the re-review Linda.
ACME WG: here is the thread from the IETF LC where propose
Thanks for the re-review Linda.
ACME WG: here is the thread from the IETF LC where proposed changes were
discussed:
https://mailarchive.ietf.org/arch/msg/last-call/nujBgHd6ZKHY6fG58ZWBKzFGVWs/
> -Original Message-
> From: Linda Dunbar via Datatracker
> Sent: Thursday, October 20, 202
Reviewer: Linda Dunbar
Review result: Has Issues
I have reviewed this document as part of the Ops area directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the Ops area directors.
Document editors and WG ch
12 matches
Mail list logo
