Hi John, Trimming a bit the list of to/cc
I noticed you stated this: ".. as far as I’m aware, there is no IETF specification for BGP over TLS, and I don’t expect that there will ever be a specification for BGP over DTLS, given that BGP assumes a stream transport..." So that got me a bit curious as I have been using BGP over TCP over TLS and BGP over TCP over DTLS for years testing Sproute's SDWAN solution. Works perfectly fine. In fact it performs much better then BGP over TCP over IPSec. And now you said something even more interesting: ".. It’s possible to layer lots of things over lots of other things..." That sounds like using TCP over TLS or DTLS is a bad thing ... which clearly is not. Cheers, Robert PS. In the subject spec I found many references to running TLS or DTLS to RRs or PEs and having BGP established there. I would rather not delete DTLS from it. On Tue, Feb 6, 2024 at 8:39 PM John Scudder <j...@juniper.net> wrote: > Hi Robert, > > > On Feb 6, 2024, at 1:49 PM, Robert Raszuk <rob...@raszuk.net> wrote: > > > > Hi John, > > > > https://datatracker.ietf.org/doc/draft-wirtgen-bgp-tls/ > > See my earlier reply to Linda. > > > And for DTLS ... isn't this simply TCP over DTLS which works just fine ? > > I’m not sure what you’re getting at here. It’s possible to layer lots of > things over lots of other things. That doesn’t mean that it makes sense to > do so, or that it’s something you can just mention in (literally) a single > word in a spec and imagine you’ve provided enough detail. In this case, > Linda said she planned to remove the mention of DTLS, which makes more > sense to me, so I guess we don’t need to keep discussing it. > > —John > > > > > Many thx, > > R. > > > > > > > > On Tue, Feb 6, 2024 at 4:38 PM John Scudder <jgs= > 40juniper....@dmarc.ietf.org> wrote: > > 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 of the document. It seems ill-advised to be last calling a > document with an unaddressed DISCUSS. For what it’s worth, Roman’s point > seems to me to be on target — as far as I’m aware, there is no IETF > specification for BGP over TLS, and I don’t expect that there will ever be > a specification for BGP over DTLS, given that BGP assumes a stream > transport. > > > > $0.02, > > > > —John > > > > [1] > https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/ballot/#draft-ietf-bess-bgp-sdwan-usage_roman-danyliw > > [2] > https://mailarchive.ietf.org/arch/msg/bess/-AT3GpMR6rr6-ywB5vWD7EbGk0w/ > > > > > On Feb 1, 2024, at 11:58 AM, The IESG <iesg-secret...@ietf.org> wrote: > > > > > > > > > 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' > > > <draft-ietf-bess-bgp-sdwan-usage-19.txt> as Informational RFC > > > > > > The IESG plans to make a decision in the next few weeks, and solicits > final > > > comments on this action. Please send substantive comments to the > > > last-c...@ietf.org mailing lists by 2024-02-15. Exceptionally, > comments may > > > be sent to i...@ietf.org instead. In either case, please retain the > beginning > > > of the Subject line to allow automated sorting. > > > > > > Abstract > > > > > > > > > The document discusses the usage and applicability of BGP as the > > > control plane for multiple SD-WAN scenarios. The document aims to > > > demonstrate how the BGP-based control plane is used for large- > > > scale SD-WAN overlay networks with little manual intervention. > > > > > > SD-WAN edge nodes are commonly interconnected by multiple types of > > > underlay networks owned and managed by different network > > > providers. > > > > > > > > > > > > > > > The file can be obtained via > > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/__;!!NEt6yMaO-gk!E4My2sQFYwfDPTtjIaFd1jpCRXVBB-u6OkgI3yHHnKfSsS4Kc80iA-x0qPn_krxB9c0LBSQsXvI1RN7dGgEtnA$ > > > > > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > > > > > > > > > _______________________________________________ > > > IETF-Announce mailing list > > > ietf-annou...@ietf.org > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf-announce__;!!NEt6yMaO-gk!E4My2sQFYwfDPTtjIaFd1jpCRXVBB-u6OkgI3yHHnKfSsS4Kc80iA-x0qPn_krxB9c0LBSQsXvI1RN5i_8mwVg$ > > > > -- > > last-call mailing list > > last-c...@ietf.org > > https://www.ietf.org/mailman/listinfo/last-call > >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
