Bill, Thanks for catching the error. Changed for the next revision.
Linda -----Original Message----- From: William Atwood <william.atw...@concordia.ca> Sent: Thursday, September 21, 2023 2:38 PM To: Linda Dunbar <linda.dun...@futurewei.com>; Joel Halpern <jmh.dir...@joelhalpern.com>; Joel Halpern <j...@joelhalpern.com>; draft-ietf-rtgwg-net2cloud-problem-statement....@ietf.org Cc: rtgwg@ietf.org Subject: Re: Comments from additional review 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://dat/ > atracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-entropy-label%2F&data=05%7C01 > %7Clinda.dunbar%40futurewei.com%7Cfec51064a8b740510a7808dbbada45f0%7C0 > fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638309218869104985%7CUnknown > %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ > XVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mPjoYUfoXPedJywDG7TUXDsqXxdory3UeiA8 > iE5PCrI%3D&reserved=0 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%2Fmailman%2Flistinfo%2Frtgwg&data=05%7C01%7Clinda.dunbar%40fu > turewei.com%7Cfec51064a8b740510a7808dbbada45f0%7C0fee8ff2a3b240189c753 > a1d5591fedc%7C1%7C0%7C638309218869104985%7CUnknown%7CTWFpbGZsb3d8eyJWI > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7 > C%7C%7C&sdata=oiqqI3WSJxUS2mgSfOulFHfEzUKPJfqobPEUVZT%2Fjpo%3D&reserve > d=0 -- 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
