Re: Tsvart early review of draft-ietf-rtgwg-net2cloud-problem-statement-22

[Robert Raszuk <[e-mail]>]

Well those PEs provided someone is using VPNs are hardly ever co-located
with Cloud GWs - so in that respect the statement is misleading at best.

There is however a new wave of routing nodes being deployed by some IXPs
which enable L3 routing on a per tenant basis within the IXP fabric. Few
IXPs offer this today as a product.

Said this I have no concern - I was just hinting that if you want to make
the document complete the L2/L3 transit via IXP fabrics should not be
forgotten in the draft.

Thx,
R.

On Tue, Apr 25, 2023 at 3:45 AM Linda Dunbar <[e-mail]>
wrote:

> Robert,
>
>
>
> Will adding the following description address your concern?
>
> *Using a private VPN to connect an enterprise’s on-prem CPEs to a Cloud DC
> requires the private VPN has one or more PEs collocated with the Cloud GW
> at an IXP (Internet eXchange Point).*
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Monday, April 24, 2023 5:01 PM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* Black, David <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> *Subject:* Re: Tsvart early review of
> draft-ietf-rtgwg-net2cloud-problem-statement-22
>
>
>
> Hi Linda,
>
>
>
> There are not IXP specific issues. The set of issues (or to say it more
> precisely suboptimality of connections) the entire draft is describing are
> equally applicable also to connections via IXP fabrics. That is why they
> should not be dismissed.
>
>
>
> Kind regards,
>
> Robert
>
>
>
> On Mon, Apr 24, 2023 at 11:54 PM Linda Dunbar <[e-mail]>
> wrote:
>
> Robert,
>
>
>
> Can you write a section for the problems associated with connection via
> IXP? That will be greatly appreciated.
>
>
>
> Linda
>
>
>
>
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Monday, April 24, 2023 4:31 PM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* Black, David <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> *Subject:* Re: Tsvart early review of
> draft-ietf-rtgwg-net2cloud-problem-statement-22
>
>
>
>
>
> > Since the interconnect option via IXP fabric doesn’t have any problems,
> it is not included in the document.
>
>
>
> It is simply not true.
>
>
>
> Everything you are aiming to describe is equally applicable to
> interconnect to public clouds via IXPs.
>
>
>
> Regards,
>
> R.
>
>
>
>
>
>
>
>
>
> On Mon, Apr 24, 2023 at 11:20 PM Linda Dunbar <[e-mail]>
> wrote:
>
> Robert,
>
>
>
> See below for the resolution:
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Monday, April 24, 2023 3:48 PM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* Black, David <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> *Subject:* Re: Tsvart early review of
> draft-ietf-rtgwg-net2cloud-problem-statement-22
>
>
>
> Hi Linda,
>
>
>
> Please see inline ..
>
>
>
> > [Linda] Cloud interconnect by IXP (AWS’s Direct Connect, Azure’s
>  ExpressRoute, etc.) has been added since version -22.
>
>
>
> AWS Direct Connect or Azure Express Route are just commercial product
> names to indicate direct attachment to AWS or Azure public clouds. I have
> setup those myself in the past.
>
>
>
> [Linda] The document doesn’t include the AWS/Azure commercial names. I
> used the name for example only.
>
>
>
> My point was technical not marketing and I meant to indicate that your
> document is missing technical description of the most
> attractive interconnect option which is via IXP fabric. AWS Direct Connect
> or Azure Express Route use leased lines or direct dark fiber to attach to
> public cloud edge ports.
>
>
>
> [Linda] The main reason of mentioning direct connection via private
> circuits in the Section 4.3 is to describe the preferable connection when
> the private VPN network can’t reach the desired Cloud DCs. ( IPsec tunnels
> can be used to dynamically connect the private VPN PEs with the desired
> Cloud DCs GWs. As the private VPNs provide more secure and higher quality
> services, choosing a PE closest to the Cloud GW for the IPsec tunnel is
> desirable to minimize the IPsec tunnel distance over the public Internet.)
>
>
>
> Since the interconnect option via IXP fabric doesn’t have any problems, it
> is not included in the document.
>
> Linda
>
>
>
>
>
> > By that I mean both layer 2 and layer 3 types of interconnect over IXes
> ?
>
> > [Linda] Layer 2 VPN, Layer 3 VPN has been added.
>
>
>
> Attachment via IXP does not require ANY VPN ! That is the crux of the
> point.
>
>
>
> > [Linda] Here is Azure suggested network connecting to clouds:
> https://learn.microsoft.com/en-us/azure/virtual-wan/sd-wan-connectivity-architecture
>
>
>
> See this illustration is incomplete. It misses the most important
> interconnect via IXP ports. It also misses Express Route remote extension
> which number of telcos and ISPs and IXPs are providing today.
>
>
>
> - -
>
>
>
> If you choose to proceed with an incomplete draft it's ok. My point was to
> just provide an observation of the current state.
>
>
>
> Kind regards,
>
> Robert
>
>
>
>
>
>
>
> On Mon, Apr 24, 2023 at 10:26 PM Linda Dunbar <[e-mail]>
> wrote:
>
> Robert,
>
>
>
> Answers to your questions are inserted below:
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Monday, April 17, 2023 1:31 PM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* Black, David <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> *Subject:* Re: Tsvart early review of
> draft-ietf-rtgwg-net2cloud-problem-statement-22
>
>
>
> Hi Linda,
>
>
>
> Can you be so kind and elaborate why the document titled "net2cloud" does
> not even mention once the most popular way to connect to public clouds
> which is over IXP fabric(s) ?
>
> [Linda] Cloud interconnect by IXP (AWS’s Direct Connect, Azure’s
>  ExpressRoute, etc.) has been added since version -22.  Section 4.3 of the
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/
>
>
>
> By that I mean both layer 2 and layer 3 types of interconnect over IXes ?
>
> [Linda] Layer 2 VPN, Layer 3 VPN has been added.
>
>
>
> Looking holistically I also do not see much if at all discussion on
> host2cloud connectivity over Internet. If I connect to clouds today I use
> almost exclusively host2cloud model where my transit infrastructure is
> completely unaware underlay. And doing passive/active quality measurement
> over N disjoined paths I can rest assure you that it works perfectly well.
> The overlay can be of various sorts, but very often includes wireguard or
> wireguard like e2e encrypted pipes.
>
>
>
> [Linda] Here is Azure suggested network connecting to clouds:
> https://learn.microsoft.com/en-us/azure/virtual-wan/sd-wan-connectivity-architecture
>
>
>
> Linda
>
> Many thx,
>
> Robert
>
>
>
> PS. Btw I support in 100% all comments from Lukasz and do hope they get
> addressed.
>
>
>
>