Adrian,
Thank you. Below are the resolutions to your additional comments.
Please let us know if you have further comments.
Thank you very much,
Linda
From: Adrian Farrel
Sent: Thursday, February 8, 2024 4:33 AM
To: Linda Dunbar ; last-c...@ietf.org
Cc: andrew-i...@liquid.tech;
Adrian,
Thank you very much. RFC 9522 definition for Traffic Steering is very helpful.
I will add the reference to RFC 9522 and add the definition for C-PE.
C-PE:For SD-WAN network expanded from an existing
VPN, the term C-PE refers to the PE (or CPE) of the existing
Hi again, Linda.
Here is the response to your second email. Again, comments in line, with
snipping of agreed points.
Best,
Adrian
From: Linda Dunbar
Sent: 08 February 2024 01:58
To: adr...@olddog.co.uk; last-c...@ietf.org
Cc: andrew-i...@liquid.tech; bess-cha...@ietf.org;
Hi Linda,
Thanks for considering all of my comments. I'll respond to your two emails
separately. Comments inline. I snipped the obvious agreements.
Cheers,
Adrian
From: Linda Dunbar
Sent: 07 February 2024 00:23
To: adr...@olddog.co.uk; last-c...@ietf.org
Cc: andrew-i...@liquid.tech;
Adrian,
Please see below for the resolutions to your remaining comments.
Thank you very much for the detailed comments.
Linda
-Original Message-
From: Adrian Farrel
Sent: Saturday, February 3, 2024 3:54 PM
To: last-c...@ietf.org
Cc: andrew-i...@liquid.tech; bess-cha...@ietf.org;
Adrian,
Thank you very much for the extensive comments and suggestions.
I am breaking the resolutions in two separate emails. This one addresses the
comments to Section 3.1.2. Will have another email addressing the remaining
comments.
Can you check if the resolutions to your comments inserted
Hi Linda,
Without doing a full review of the proposed language in context, I don’t think
I can offer a firm thumbs-up or thumbs-down. But generally speaking, if the
document allows the reader to understand what the security architecture is and
how they would realize it, either by referencing
John,
One key SD-WAN scenario involves expanding the existing VPN network by
incorporating additional paths from other networks. In this context, the
operator can efficiently utilize their primary management channel, initially
designed for VPN control for the BGP to control the SD-WAN.
Yes, I noticed that, hence “no *IETF* specification”, it’s an individual draft.
If the security model of the present spec relies on BGP-over-TLS, maybe a 00
individual contribution isn’t as firm a foundation as you’d like.
Of course, I can’t speak for Roman, it’s his DISCUSS, I was just
John,
There is a draft on BGP over TLS:
https://datatracker.ietf.org/doc/draft-wirtgen-bgp-tls/
We are working with the author to enhance the draft.
We will add the reference to BGP over TLS. And remove the BGP over DTLS.
Can those changes address your comments?
Thank you,
Linda
I haven’t done a full review of this document, but I did notice that Roman
Danyliw balloted DISCUSS on version 15 [1], asking, among other things, "Are
there pointers for BGP over DTLS? Over TLS?”. This doesn’t appear to have been
addressed, either in Linda’s reply to Roman [2], or in the text
Hi,
I read this document again as part of its second Last Call. I have a
few comments that should ideally be fixed before passing the draft on
to the RFC Editor. (I ran out of steam around Section 6, sorry.)
Thanks,
Adrian
===
I wondered about the implementation status of this document. One
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'BGP Usage for SD-WAN Overlay Networks'
as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send
13 matches
Mail list logo
