> On Mar 7, 2017, at 3:30 PM, Susan Hares <sha...@ndzh.com> wrote: > > Stefano: > > Summary: As I have often said, I believe in helping BGP meet the needs of > operators (DC or BGP), and this includes BGP-LS. If your transition from > OSPF/IS-IS LSPs to BGP in BGP to MPLS is to meet operator needs - great. > Just document the security concern issues (new types of information, privacy > issues on sending link info). > > My "concern" comments on BGP-LS only focus on 3 things: > 1) Upgrade your security section to deal with issues regarding new types of > information and privacy issues on sending link-information (inside DC or DCI)
agreed and will do so. Note also that EPE is just one piece of the picture described in the draft. > 1 to 3 paragraphs should be sufficient. I will suggest text. > 2) Be precise in your RFC3107 terminology - agreed. I added some text explaining what we intend by 3107 ebgp and ibgp. > 3) Encourage the use of 4-byte Private AS, and treat 2-byte Private ASes as > a legacy issues. ok, will do so. > All response below boil down to this summary. Editorial Nits are your > choice to adopt/not-adopt. IETF LC and IESG review will provide you lots of > feedback on editorial nits. yup, I applied all of them. Thanks. s. > > > Sue > > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-boun...@ietf.org] On Behalf Of Stefano Previdi > (sprevidi) > Sent: Tuesday, March 7, 2017 6:21 AM > To: Susan Hares > Cc: rtg-...@ietf.org; spring@ietf.org; i...@ietf.org; > draft-ietf-spring-segment-routing-msdc....@ietf.org > Subject: Re: [RTG-DIR] [spring] Review of > draft-ietf-spring-segment-routing-msdc-03 > > Hi Sue, > > thanks for the review. Some comments below. > > >> On Mar 6, 2017, at 5:25 PM, Susan Hares <sha...@ndzh.com> wrote: >> >> Reviewer: Susan Hares >> Review result: Has Issues >> >> The RTG-DIR has the categories: minor concerns or major concerns >> regarding "issues", I wil differentiate my issues by this quality. >> I also have editorial nits regardign under specified text. >> >> Major concerns: >> 1) The security section is not sufficient for any review by the >> Security area >> >> This draft depends on IDR WG draft (ietf-idr-bgp-prefix-sid) that >> defines the BGP Segment attribute. If this attribute is used with >> IPv6, this simply gives more infromation about a link to a next. >> However, the combination of this information with the information >> passed using draft-ietf-idr-bgpls-segment-routing-epe-09 that utilizes >> BGP to pass BGP topologies in BGP - requires a better security >> section. BGP-LS was described to be an "information gathering" >> function handled by a few routers on the edge of the network to obtain >> link-state topology information. The BGP peers would carry this >> information in a separate informational stream. With this constraint, >> it was approved by the IESG. > > Stefano: well, we have now different models that have been deployed and > assuming that bgp-ls uses a separate stream is not accurate if we look what’s > in the industry. However, I take your point and I agree that more text in > the security section is required in order to emphasize that the model the > draft addresses is internal (DC and interconnected DC over a > same-administration network). > > Sue: Good. I look forward to your security section. Please note to clearly > state (or reference) whether the interconnected DC is over physically > isolated or logically isolated on shared infrastructure. Please indicated > any privacy issues. > >> draft-ietf-idr-bgpls-segment-routing-epe expands the initial concept >> of BGP-LS from "information gathering" to a full-routing scheme of BGP >> within BGP for data centers and for data center interconnection to the >> network. > > Stefano: EPE defines a model where the topology of the peering point (not the > network, just the peering point) is advertised to an internal server. > Yes, but the topology of peering point may be considered information that > falls under the "privacy" issues in security. The security considerations > should indicate whether you assume the peering point is physically isolated > or shared infrastructure. If shared infrastructure, are you requiring TCP-AO > to e securie. > >> This extension takes it out of the approved range of the BGP-LS. > Stefano: I don’t know what is the “approved range”. To me, bgp-ls carries > topology information. We started with lsdb, then extended to mpls-lsp's, ip > tunnels, peering points, and more will come. The security of bgp-ls doesn’t > change. It’s the boundary of the network where bgp-ls is applied that matters. > > Sue: The focus is the security in this sentence. The security case in the > original BGP-LS was the transportation of the BGP-LS information (OSPF/ISIS > topologies) on a separate network. If you have changed due to customer > needs/wants, fine. Just provide the security case in the 3 paragraphs. > >> Therefore, the security sections in both the IDR WG drafts and this >> draft need to describe the new threat scenarios and describe threat >> mitigation strategies for deployments. > > Stefano: I will add more text about the information originated by bgp-ls (or > the bgp prefix sid) and how it is intended to be consumed internally to a > domain. > Sue: Great! > >> In addition, the information by BGP-LS >> (draft-ietf-idr-bgpls-segment-routing-epe) or in draft-ietf-bgp-sid >> may have privacy issues - so these need to be described the security >> section. > > Stefano: same here. I will emphasize the deployment model and the security > boundaries. > Sue: Wonderful! > >> 2) through-out the text you use words such as "ebgp3107" or BGP 3107 >> updates" >> >> This phrase is inaccurate. The base RFC3107 support will not provide >> BGP-Prefix support (as supported in bgp-idr-bgp-prefix. Some texts >> goes on to clarify the addition of the BGP SID Prefix attribute. It >> would be better to invent a new phrase or term. > > Stefano: I’ll check this out. > Sue: Great, just be a bit more precise in the test to aid future > implementations. > >> In section 8.1, the authors state: >> "The Prefix Segement is a lightweight extension to the BGP Labelled >> Unicast". As noted in my #1 major concern, this "hand-waving" >> description either needs to be refined to be accurate. If the MPLS >> usage only uses the BGP-Prefix label and does not extend to the >> Egress, it is simplier. > > Stefano: the BGP Prefix SID Attribute is just an extension to a 3107 update. > Sue: BGP Prefix is an BGP attribute that goes along with BGP-lS BGP topology > information in the whole solution. > The easiest thing is to just leave out the "evaluation". > Alternatively, make the evaluation more precise by including more > description. > >> However, it is not clear that is what section >> 8.1 is about. If 8.1 includes the >> draft-ietf-idr-bgpls-segment-routing-epe, then BGP-LS addition does >> have a number of prefixes and rules. The trade-off between BGP-LS + >> BGP-LS SID (draft-ietf-idr-bgp-sid) handling + BGP LS egress peer >> engineering draft (draft-ietf-idr-bgp-segment-routing-epe) and a >> signalling protocol is more complex than the hand-wave. > > Stefano: Not sure I understand your point but to me the statement: “The > Prefix Segment is a lightweight extension to the BGP Labelled Unicast” is > correct because the prefix-sid is really just a new attribute. Here we’re > just talking protocol extension. The interaction and combination between > prefix-sid and epe is a deployment and operational model that (we agreed > above) requires more explanation in terms of security. > > Sue: My purpose here is to simply point out where your RFC3107 and new BGP > Prefix SID Text too loose. > If you want to say that "BGP Prefix SID is a new BGP attribute and it along > with RFC3107 NLRI provides the internal-DC without the DCI-interconnection" - > just state that. > This is the purpose of the sentence below: >> It may be the right choice based on current implementations and management >> issues, but these need to be laid specifically. > > >> 3) Why are you defining 2-byte Private Use AS when there are plenty of >> 4-Byte Private Use AS (p. 5). > Stefano: well, we just want to be sure we address the worse case where you > only have 2 octets. > Sue: It would be better to encourage the general use of 4-Byte ASes which > have enough space to give most data center's one AS per box, and then deal > with the worst case issues. > >> >> This usage increases the confusion regarding 2-byte/4-byte ASN. IDR >> specifically worked on 4 byte ASN. > > Stefano: yes but in order to be aligned with 7938 we also take into account 2 > octet ASN and the re-usability of these numbers. > Sue: Wonderful, just add the 4 byte AS. > >> Minor concerns >> 1) It is not clear what happens in section 4.2.2 and figure 3-5 >> >> What happens if the traffic goes to node 3 instead of node 4 on the >> ECMP path? >> What happens if the traffic goes to node 8 instead of node 7 on the >> ECMP Path? >> >> Is there something missing in the stroy? > > > nope. This is plain segment routing. As explained in the draft, assuming that > you use the same SRGB (as recommended) a node is known through the same sid > value all along the network so ecmp becomes trivial. > > >> 2) section 4.3 - IBGP Labeled Unicast. >> >> The phrase "iBGP3107 reflection with nhop-self" needs to be explicitly >> spelled out as IBGP Route-Reflection with next-hop self. > > ok > >> If that is >> not what the authors mean, then it needs to be further spelled out. >> It is unclear where the central IBGP nodes are that share fully the >> information learned from the three clusters. (nodes:5-8 cluster 1, >> nodes 3-4 cluster 2, nodes 9-10 cluster 3). >> >> This section has hints of a solution, but it is miss a great deal. >> Please upgrade to specific solution. A diagram might help. > > > yes. I’ll check this out. In short (you certainly figured it out) it’s about > using iBGP session where each node acts as a RR so to propagate to other iBGP > peers (this is what "iBGP reflection” refers to). I agree, it’s probably a > bit too cryptic. > > >> 3) Load Sharing hints (Section 7.1) >> >> Elephant flow and mice flows are good descriptions. Flowlets and VL2 >> should either warrant a 1 sentence explanation that actually describes >> these features in a 22 page draft, or be removed. > > > We have a reference for them but will add more text. > > >> 4) The lack of a manageability or operations section (TBD in version >> -02) - concerns me. The operational issues may be well known to the >> data centers and devices manufacturers who have implement this >> specification, but this is an interoperability specification for IETF. >> Some manageabilty comments should be included or a BCP pointed to. > > > ack. > > >> Editorial issues: > > > I’ll go through all below and update the draft asap. > > Thanks. > s. > > >> >> #1 - The following 4 abbrevitions need to be initially expanded when >> first used: CLOs (p.3), SRGB(p.6), flowlets (p. 14), and VL2 (p. >> 14). >> >> #2 - page 7, section 4.2 last paragraph >> Old/: assuming the IP Addresses, AS and label-index allocation >> previously described, the" >> New/: assuming the IP address with the AS and label-index allocation >> previously described, the" >> [Comma is optional] >> >> #3 - page 14, section 7.1 paragraph 4, /(e.g. spine switch Node1)/ - >> by the diagram it should be node 5-8 or an error. Please check the >> number >> >> #4 - page 17, section 8.2 paragraph 2. >> >> Old/ >> This is easily accomplished by encapsulating the trafffic either >> directly at the host or the source ToR node by pushing the BGP- >> Prefix-SID of the destination ToR for intra-DC traffic, or border node >> for inter-DC or DC-to-outside-world traffic./ >> >> New/ >> This is easily accomplished by encapsulating the trafffic either >> directly at the host or the source ToR node by pushing the BGP- >> Prefix-SID of the destination ToR for intra-DC traffic, or the >> BGP-Prefix-SID for the the border node for inter-DC or >> DC-to-outside-world traffic./ >> >> If this is not the correct logic, then you can reword this further. >> I read it 4 or 5 times. >> >> #5 - Adding a diagram to section 4.3 might help your description. >> >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
