Hi Stefan, On the topic of multitenancy in customer sites I completely agree with You.
I pointed that to the authors already ;) But observe that if they also are targeting DCs as the draft says there is clear need for multi tenancy on compute nodes. I guess they are trying to cook two meals on the same fire. But then this is a bit of head on collision course with Contrail .... Best, R. On Thu, Jun 14, 2018, 12:41 <stephane.litkow...@orange.com> wrote: > Hi Robert, > > > > Thanks for sharing your point of view. I think we just have a different > reading/understanding of the goals. > > I do not disagree with what you say. > > > > I was not seeing this as an SD-WAN like solution. At least it is not > presented this way. > > I understood the draft as how can I overcome some security concerns today > with PPVPN. > > > > I’m fine to build automated VPNs over a public infra like Internet J > > If we want to make this solution more SDWAN like (I do not mean a full > SDWAN solution), we need to involve more automation, especially setup of > RRs and BGP sessions… > > > > Again, as I mentioned, the multitenancy is more a nice to have: most of > customers do not need this. > > > > > > Brgds, > > > > Stephane > > > > > > > > *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert > Raszuk > *Sent:* Thursday, June 14, 2018 11:13 > *To:* LITKOWSKI Stephane OBS/OINIS > *Cc:* Ron Bonica; bess@ietf.org > *Subject:* Re: [bess] New Version Notification for > draft-rosen-bess-secure-l3vpn-00.txt > > > > Hello Stephane, > > > > I read the draft with deep interest. In my opinion I completely have > opposite view to yours - "niche use case" - quite contrary connecting > customer sites over open infrastructure have already started to happen in > large scale globally. > > > > It is not about adding IPSec tunnel here and there - the crux is about > automating it to accommodate very large scale deployments. Perhaps your > comment is based on this specific point that IPSec today created manually > is a niche and therefor automating it does not make sense. But this is not > about it. It is about transition from SP operated L3VPNs into an > alternative L3VPN paradigm. > > > > Yes I understand that the draft may not be very comfortable for SPs who's > review comes from locking customer to MPLS-L3VPN backbone just like in the > old days they were locking customer to Frame Relay or ATM backbones :). > > > > Maybe our definitions of niche is a bit different, but when I look at the > market cap of SD-WAN vendors it seems like if you would call as niche an > ant in the forest here we are watching an army of elephants entering the > woods. > > > > Yes the draft is just first important step towards standards based open > infra secure interconnects - it can not be treated as full SD-WAN spec as > it is missing a lot of important functionalities today addressed in more or > less proprietary way by any such vendor. > > > > The technology is not new too ... since day one we had Carrier's Carrier > solution when customers could exchange their routes directly. We also had > tunnel encapsulation attribute in place where we could signal various > parameters of given encap. However putting it all together as Eric did in > this document is IMHO a very important step fwd especially coming under the > umbrella of one specific affiliation :). > > > > I do support this work and I hope this is just one brick which we can > start build on going forward standards based interoperable secure > connectivity over open public IP infrastructure. > > > > Kind regards, > > Robert. > > > > > > > > > > > > > > > > > > On Thu, Jun 14, 2018 at 8:17 AM, <stephane.litkow...@orange.com> wrote: > > Hi Ron, > > I have read quickly the document. > I think the use case of having secure L3VPNs is valid and we already have > all (or most of) the technology building blocks to do it. > Now the draft takes a complete upside down approach comparing to our well > known L3VPNs which are provider provisioned VPNs as you propose to build > them at the CE side. > This could be a valid approach but isn't it a niche use case ? > > Customer sites connected over the Internet is for sure a use case to > handle, and we already to it today by establishing an IPSec tunnel towards > an SP-PE, the tunnel ends in the customer VRF. > Customer data must not be exposed: also a valid use case. We have some > customers doing IPSec transport within MPLS VPN for some specific traffic.. > On the other hand, from an SP point of view, when core links are not fully > trusted, MACSEC or IPSec are also options. > > I'm less convinced by the routing that should not be exposed. I agree that > this is a possibility and a valid use case but I do not think that this is > a big deal for most of customers (even those requiring more security). The > good thing of MPLS VPN is the routing complexity is almost pushed to the SP > and the customer has few things to do and they are happy with that. > > The last case of the multitenancy on the customer side is also valid, but > I also think that it is a niche use case. > > My point is that the draft is currently focusing on one scenario which in > my opinion addresses a niche use case while there may be intermediate > scenarios (like no multitenancy and/or no need of routing protection) that > could be more widely applicable. > > Brgds, > > Stephane > > > > -----Original Message----- > From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Ron Bonica > Sent: Monday, June 11, 2018 21:56 > To: bess@ietf.org > Subject: [bess] FW: New Version Notification for > draft-rosen-bess-secure-l3vpn-00.txt > > Folks, > > Please review and comment on this draft. > > Ron > > > -----Original Message----- > From: internet-dra...@ietf.org <internet-dra...@ietf.org> > Sent: Monday, June 11, 2018 3:49 PM > To: Ron Bonica <rbon...@juniper.net>; Eric Rosen <ero...@juniper.net>; > Eric Rosen <ero...@juniper.net> > Subject: New Version Notification for draft-rosen-bess-secure-l3vpn-00.txt > > > A new version of I-D, draft-rosen-bess-secure-l3vpn-00.txt > has been successfully submitted by Eric C. Rosen and posted to the IETF > repository. > > Name: draft-rosen-bess-secure-l3vpn > Revision: 00 > Title: Augmenting RFC 4364 Technology to Provide Secure Layer > L3VPNs over Public Infrastructure > Document date: 2018-06-11 > Group: Individual Submission > Pages: 19 > URL: https://tools.ietf.org/html/draft-rosen-bess-secure-l3vpn-00 > > Status: > https://datatracker.ietf.org/doc/draft-rosen-bess-secure-l3vpn/ > Htmlized: https://tools.ietf.org/html/draft-rosen-bess-secure-l3vpn-00 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-rosen-bess-secure-l3vpn > > > Abstract: > The Layer 3 Virtual Private Network (VPN) technology described in RFC > 4364 is focused on the scenario in which a network Service Provider > (SP) maintains a secure backbone network and offers VPN service over > that network to its customers. Customers access the SP's network by > attaching "Customer Edge" (CE) routers to "Provider Edge" (PE) > routers, and exchanging cleartext IP packets. PE routers generally > serve multiple customers, and prevent unauthorized communication > among customers. Customer data sent across the backbone (from one PE > to another) is encapsulated in MPLS, using an MPLS label to associate > a given packet with a given customer. The labeled packets are then > sent across the backbone network in the clear, using MPLS transport. > However, many customers want a VPN service that is secure enough to > run over the public Internet, and which does not require them to send > cleartext IP packets to a service provider. Often they want to > connect directly to edge nodes of the public Internet, which does not > provide MPLS support. Each customer may itself have multiple tenants > who are not allowed to intercommunicate with each other freely. In > this case, the customer many need to provide a VPN service for the > tenants. This document describes a way in which this can be achieved > using the technology of RFC 4364. The functionality assigned therein > to a PE router can be placed instead in Customer Premises Equipment. > This functionality can be augmented by transmitting MPLS packets > through IPsec Security Associations. The BGP control plane sessions > can also be protected by IPsec. This allows a customer to use RFC > 4364 technology to provide VPN service to its internal departments, > while sending only IPsec-protected packets to the Internet or other > backbone network, and eliminating the need for MPLS transport in the > backbone. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > > _________________________________________________________________________________________________________________________ > > 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. > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > > > _________________________________________________________________________________________________________________________ > > 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. > >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
