Deb, We really appreciate your review and comments to the document. Please see below for the resolution to your comments.
Linda -----Original Message----- From: Deb Cooley <[email protected]> Sent: Sunday, April 9, 2023 6:28 AM To: [email protected]; [email protected]; [email protected] Subject: Re: [secdir] Secdir early review of draft-ietf-rtgwg-net2cloud-problem-statement-22 Note: I hit ‘send’ too early, ugh. Please see the comments on the datatracker for the correct version. Deb Cooley > On Apr 9, 2023, at 6:59 AM, Deb Cooley via Datatracker > <[email protected]<mailto:[email protected]>> wrote: > > Reviewer: Deb Cooley > Review result: Not Ready > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Document: draft-ietf-rtgwg-net2cloud-problem-statement-22 > Reviewer: Deb Cooley > Review Date: 2023-04-06 (early review) > > Please note that I know almost nothing about BGP, MPLS or routing. > > The summary of the review is > > Section 3.1, para 1, sentence 2: Grammar: 'with more variety of > parties' could be 'with a larger variety of parties.' > [Linda] Per RTGarea Director suggestion, the text has been changed to the following. Is it Okay with you? Site failures include (but not limited to) a site capacity degradation or entire site going down. The reasons for these capacity degradations or failures can include: a) fiber cut for links connecting to the site or among pods within the site, b) cooling failures, c) insufficient backup power, d) cyber threat attacks, e) too many changes outside of the maintenance window, or other errors. Fiber-cut is not uncommon within a Cloud site or between sites. > Section 3.1, para 2, sentence 2: 'IP tunnels', does this imply IPSec? > Or something else? > [Linda] changed. > Section 3.1, para 3: By setting up default eBGP routes, these don't > count as routes from an external entity? The rest of the paragraph > addresses the handling of exceeding the maximum route threshold? But > there appears to be an option to keep the BGP session? This paragraph is > confusing. [Linda] The intent is to say: When inbound routes exceed the maximum routes threshold for a peer, the current common practice is generating out of band alerts (e.g., Syslog) via management system to the peer, or terminating the BGP session (with cease notification messages [RFC 4486] being sent). However, it would be useful if IETF can specify some in-band alert messages to indicate the inbound routes exceeding the threshold. > > Section 3.2, paragraph 2: IGP? AS? I can't tell what this is trying to say. > [Linda] changed to domain. > Section 3.2, paragraph 3: If there is a site failure, how is the > Cloud GW 'running fine'? Is this GW using a different site? BFD? [Linda] Failures within a site like a fiber cut between two racks. So the GW is still running fine. > > Section 3.2: Para 1 states why a site might go down. Para 2-6 > outline the routing (?) issues that occur when a site goes down. I > think these could be better organized. Only the last para suggests > mitigations. [Linda] changed to the "Failures within a site". > > Section 3.3 I'm not an expert, but isn't this an issue to any routing > scenario? > Can this be combined with Section 3.6? [Linda] Section 3.3 is to introduce the problem of multiple instances available at different sites for one service (such as using ANYCAST address). The site with the shortest distance might not be the optimal service instance as the site might be overloaded. Section 3.6 is about DNS resolution at different sites. . > > Section 3.4, para 3, item 1: Is this a problem? Or a feature? If it > is a problem, can you say why? [Linda] Item 1 is meant to say: The difference of routing distances to multiple server instances in different edge Cloud is relatively small. Therefore, the edge Cloud that is the closest doesn’t contribute much to the performance. > > Section 3.5: I would suggest moving this to Section 7. There are a > couple of mitigations listed - anti-DDOS, DTLS, IPSec, monitoring. > [Linda] Good suggestion. Changed. > Section 3.6, last paragraph: A globally unique name won't 'resolve > the same way from every perspective'? Other than being restricted > (previous paragraph), what does this mean? If this is covered in the > previous para, I would recommend deleting the phrase. > [Linda] DNSOPS director insisted on adding this paragraph to empathize that not all globally unique names can be resolved. > Stopped at Section 4. > > > > _______________________________________________ > secdir mailing list > [email protected]<mailto:[email protected]> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Fsecdir&data=05%7C01%7Clinda.dunbar%40f > uturewei.com%7C07fbc4f2cc284e39624f08db38ed774e%7C0fee8ff2a3b240189c75 > 3a1d5591fedc%7C1%7C0%7C638166364798968574%7CUnknown%7CTWFpbGZsb3d8eyJW > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000% > 7C%7C%7C&sdata=2SVXI%2BaoyU%2Bc4Aa8RRvb6BEQUIMmwTz%2BsqF6Z5o%2FnuU%3D& > reserved=0 > wiki: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac > .ietf.org%2Ftrac%2Fsec%2Fwiki%2FSecDirReview&data=05%7C01%7Clinda.dunb > ar%40futurewei.com%7C07fbc4f2cc284e39624f08db38ed774e%7C0fee8ff2a3b240 > 189c753a1d5591fedc%7C1%7C0%7C638166364798968574%7CUnknown%7CTWFpbGZsb3 > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7 > C3000%7C%7C%7C&sdata=vbmjW7gi%2BOgn9xbql5S4grf6NZayrZ%2B%2BgFYC3%2B0yK > cE%3D&reserved=0
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
