Linda,
The first word of the chosen sentence should be "One", not "On".
Bill
On 9/21/2023 3:15 PM, Linda Dunbar wrote:
Attention This email originates from outside the concordia.ca domain. //
Ce courriel provient de l'extérieur du domaine de concordia.ca
Joel,
I have taken your suggested wording for Section 3.7:
“On of the areas of concern of enterprises using Cloud services is the
lack of awareness of the location of their services in the Cloud."
Thank you!
Linda
*From:* Joel Halpern <jmh.dir...@joelhalpern.com>
*Sent:* Thursday, September 21, 2023 2:06 PM
*To:* Linda Dunbar <linda.dun...@futurewei.com>; Joel Halpern
<j...@joelhalpern.com>;
draft-ietf-rtgwg-net2cloud-problem-statement....@ietf.org
*Cc:* rtgwg@ietf.org
*Subject:* Re: Comments from additional review
Thank you. I will consider saying something about he key management in
BESS, although I participate there only very lightly.
With regard to 3.7, the proposed sentence
/“One of the concerns of //_enterprises_//using Cloud services is not
aware of where the resource is located. “/
is still not grammatical. Suggestions:
"One of the concerns of enterprises using Cloud services is achieving
awareness of where those cloud resources are located."
or
"On of the areas of concern of enterprises using Cloud services is the
lack of awareness of the location of those cloud resources."
Yours,
Joel
On 9/21/2023 2:28 PM, Linda Dunbar wrote:
Joel,
Thank you very much for the additional comments.
Resolutions to your comments are inserted below:
Linda
-----Original Message-----
From: Joel Halpern <j...@joelhalpern.com> <mailto:j...@joelhalpern.com>
Sent: Wednesday, September 20, 2023 5:45 PM
To: draft-ietf-rtgwg-net2cloud-problem-statement....@ietf.org
<mailto:draft-ietf-rtgwg-net2cloud-problem-statement....@ietf.org>
Subject: Comments from additional review
I have reviewed the latest version of the document. I hope the
below comments will help the document and possibly head off some
controversies that we don't intend to raise. Many of these are
relatively minor, probably even nits. (My thanks to the editors for
their work getting us to this point.)
Abstract:
Old text: "This document also describes the mitigation practices for
getting around"
Suggested text: This document also describes some mitigation
practices to help alleviate"
reasoning: To avoid overstating what we achieve. We do not try to
cover all the mitigations, and we do not claim the mitigations
completely solve the problems.
[Linda] Changed to the following:
/This document also describes the mitigation practices to alleviate
the issues caused by the identified problems.. /
Section 3.1 Bullet 1: In the reference to RFC 5492, it would be
good to
reference the section that says this. If I read things properly, that
is section 5.
[Linda] Added.
Section 3.1 bullet 3, after setting up default routes, would it make
sense to say "and filter as many routes as practical replacing them
with
that default in the eBGP advertisement" so as to make clear what we are
asking the enterprise to do?
[Linda] Added. Maybe we should consider adding an extra property
about the Routes in the BGP Router Capabilities Attribute [
https://datatracker.ietf.org/doc/draft-ietf-idr-entropy-label/
<https://datatracker.ietf.org/doc/draft-ietf-idr-entropy-label/ such as
* Droppable routes, which can be dropped when the Max routes
threshold limit is reached for the customer.
* Non-droppable Routes,
So that the Cloud GW can ignore the Droppable-Routes from a customer
when its max routes exceed the limit.
With this option, the Cloud GW doesn’t need to drop all routes when
the number of routes exceeds the limit.
Section 3.7 paragraph 1. The first sentence is not English. I think
some words got lost in repeated edits. Trying putting in specific
actors and actions along the lines of "One of the concerns of operators
using Cloud services is a lack of knowledge of where resources are
located." (Only if I guessed right what the sentence should say.)
[Linda] changed to
/“One of the concerns of //_enterprises_//using Cloud services is
not aware of where the resource is located. “/
I do note that section 3.7 is a bit vague about whether "location"
means
topological location or geographic location. The two are not
interchangeable. Whether the text means one or the other (or both) it
would be helped by being clear about which notion of location is
intended. (This is mostly regarding paragraphs 1 and 2. Being clear
there will provide sufficient context for paragraph 3.)
[Linda] added the following sentence to Section 3.7:
/While the geographic locations are usually exposed to the
enterprises, such as Availability Zones or Regions, the topological
location is usually hidden./
Editorial - Line one of section 4 shows up in Bold face for some
reason. Confusing to the reader. Section 5 also has this problem.
[Linda] next revision should fix the problem.
-
Section 5.1 in describing the number of IPSec tunnels needed, the text
is somewhat unclear. I think there are three sets of things:
enterprise sites(A), enterprise data centers(B), and cloud DCs(C).
Each category needs to talk to all the other categories, and for load
distribution categories B need to talk to each other and categories C
need to talk to each other. While this is still a large number, it is
smaller than N*N by A*A. And since A is presumably significantly
larger
than B or C, that makes a big difference in the calculation. If you
are
assuming all sites need to talk to all other sites, that does not match
my experience, and the complexity is not related to the net2cloud
problem.
[Linda] This section is to say that a large enterprise with many
locations (e.g., L1-L20) reaching a set of Cloud DCs (e.g., C1-C5)
need to establish 20*5*2 (bidirectional) IPsec SAs.
Changed the text to the following:
/“… there are N*C*2 IPsec SAs (tunnels) between Cloud DC gateways
and all those sites, with N being the number of enterprise sites and
C being the number of Cloud sites.”/
Personal opinion, I might put in some caveats in the reference to
[SECURE-EVPN] along the lines of "If the security properties prove
out...." as that as far as I can tell has not been vetted by the
security folks. Up to you. I do think we should include a note in the
security considerations section that a full security evaluation will be
needed before [SECURE-EVPN] can be recommended. Otherwise, I expect
the
Security folks will become concerned about suggesting changes to
keying. (I do recognize that the draft has a co-author from the
security community, which helps.)
[Linda] Agree with you. I think that the Key Management portion
(Section 4 & 5) of the
https://datatracker.ietf.org/doc/draft-ietf-bess-secure-evpn/
<https://datatracker.ietf.org/doc/draft-ietf-bess-secure-evpn/ should be
separated as an independent draft to be discussed in the IPsecme WG, as the
modified IPsec Key Management scheme doesn’t belong to the Routing Area. I have
suggested to Ali, but he has been ignoring my suggestion. Can you make a request
on the BESS mailing list?
-
I find section 5.2 a bit confusing. Paragraphs 1 and 3 are about the
overhead of encaps / decaps and encrypt / decrypt (largely the later;
encaps / decaps is cheap, it is the encrypt / decrypt that is
expensive). But paragraph 2 is about connectivity across the Internet
and the potential performance impacts of that. I get lost. What
problem are we trying to solve here?
[Linda] The title of the section should be “5.2. Improving CPEs
interconnection Over the Public Internet”
The first paragraph is now removed:
2. /Improving CPEs interconnection Over the Public Internet/
/When enterprise CPEs are far away from each other, e.g., across
country/continent boundaries, the performance of IPsec tunnels over
the public Internet can be problematic and unpredictable. Even
though there are many monitoring tools available to measure delay
and various performance characteristics of the network, the
measurement for paths over the Internet is passive and past
measurements may not represent future performance. /
/[MULTI-SEG-SDWAN] describes some methods to utilize the Cloud
backbone to interconnect enterprise CPEs in dispersed geographic
locations without requiring the Cloud GW to decrypt and re-encrypt
the traffic from the CPEs. /
Thank you very much!
Linda
Yours,
Joel M. Halpern
-
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
--
Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046
Distinguished Professor Emeritus fax: +1 (514) 848-2830
Department of Computer Science
and Software Engineering
Concordia University ER 1234 email:william.atw...@concordia.ca
1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
