IETF conflict review for draft-filsfils-spring-large-scale-interconnect
conflict-review-filsfils-spring-large-scale-interconnect-00
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-10-29
|
00 | Cindy Morgan | The following approval message was sent From: The IESG To: Martin Vigoureux , Adrian Farrel , draft-filsfils-spring-large-scale-interconnect@ietf.org, rfc-ise@rfc-editor.org … The following approval message was sent From: The IESG To: Martin Vigoureux , Adrian Farrel , draft-filsfils-spring-large-scale-interconnect@ietf.org, rfc-ise@rfc-editor.org Cc: IETF-Announce , The IESG , iana@iana.org Subject: Results of IETF-conflict review for draft-filsfils-spring-large-scale-interconnect-12 The IESG has completed a review of draft-filsfils-spring-large-scale-interconnect-12 consistent with RFC5742. The IESG has no problem with the publication of 'Interconnecting Millions Of Endpoints With Segment Routing' as an Informational RFC. The IESG has concluded that this work is related to IETF work done in WG SPRING, but this relationship does not prevent publishing. The IESG would also like the Independent Submissions Editor to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: https://datatracker.ietf.org/doc/conflict-review-filsfils-spring-large-scale-interconnect/ A URL of the reviewed Internet Draft is: https://datatracker.ietf.org/doc/draft-filsfils-spring-large-scale-interconnect/ The process for such documents is described at https://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary |
2018-10-29
|
00 | Cindy Morgan | IESG has approved the conflict review response |
2018-10-29
|
00 | Cindy Morgan | Closed "Approve" ballot |
2018-10-29
|
00 | Cindy Morgan | Conflict Review State changed to Approved No Problem - announcement sent from Approved No Problem - announcement to be sent |
2018-10-25
|
00 | Cindy Morgan | Conflict Review State changed to Approved No Problem - announcement to be sent from IESG Evaluation |
2018-10-25
|
00 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-10-25
|
00 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-10-25
|
00 | Benjamin Kaduk | [Ballot comment] Interesting to see that there are apparently two Steven Lins at Google that contributed to this work... |
2018-10-25
|
00 | Benjamin Kaduk | [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk |
2018-10-25
|
00 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-10-24
|
00 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2018-10-24
|
00 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-10-24
|
00 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-10-23
|
00 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-10-10
|
00 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2018-10-08
|
00 | Amy Vezza | Placed on agenda for telechat - 2018-10-25 |
2018-10-08
|
00 | Martin Vigoureux | [Ballot comment] Dear IESG, this document was initiated in SPRING (at the time I was chair and Alvaro AD). However it was decided that SPRING … [Ballot comment] Dear IESG, this document was initiated in SPRING (at the time I was chair and Alvaro AD). However it was decided that SPRING should not pursue this type of initiative and should focus on architectural specifications rather than use-case and similar documents. The ISE path was therefore suggested to the authors. Also, please see below the list of comments I have sent to the authors and the ISE: As a general comment, it is not crystal clear what allows to scale up to the numbers you give in the abstract. Is that some capability inherent to SR or is that a specific design which you propose? I believe the reader needs to know. So, I think that some text, early in the document, needs to say either: SR intrinsically allows to scale to these numbers and this document illustrates this. Or The specific design which allows to scale is presented in detail in this document and it includes the following key aspects/capabilities: - - - 4. Control Plane The SR PCE [RFC4655] is made of two components. A multi-domain topology and a computation engine. The multi-domain topology is continuously refreshed through BGP-LS [RFC7752] feeds from each Do you mean the traffic engineering database instead of the multi-domain topology? Also, the second sentence of this paragraph is hard to parse. The same SRGB sub-range is re-used within each DC (DC1 and DC2) region. for each DC: e.g. 20000-23999. Specifically, range 20000-23999 range is used in both DC1 and DC2 regions and nodes A and Z have both SID 20001 allocated to them. I think this needs to be reworked as: The same SRGB sub-range is re-used within each DC (DC1 and DC2) region. for each DC: e.g. 20000-23999. Specifically, nodes A and Z both have SID 20001 allocated to them. 5. Illustration of the scale There's 1 core domain and 100 of leaf (metro) domains. s/100 of/100/ Why do you change terminology, i.e., use leaf instead of metro? Please use a consistent naming through out the document. 6,000 leaf node segments multiplied by 100 leaf domains: 600,000 nodes. s/leaf node segments/leaf nodes/ Shouldn't the 200 core nodes be added? Core node segment scale: 6,000 leaf domain segments + 300 core domain segments = 6,300 segments s/domain/node/? 6.5. Compressed SRTE policies The Binding SID also provide for an inherent churn protection. s/provide/provides/ When the core topology changes, the control-plane can update the low- latency SRTE Policy from Agg1 to the DCI pair to DC2 without updating the SRTE Policy from A to Z. The presence of DC2 confused me first. I had to read and read this again to understand. I think it would be easier to read if you were just saying "from Agg1 to the (DCI3, DCI4) pair", and remove "to DC2". But I leave this up to you. 8.1. Simplified operations Two protocols have been removed from the network: LDP and RSVP-TE. No new protocol has been introduced. The design leverage the core IP protocols: ISIS, OSPF, BGP, PCEP with straightforward SR extensions. s/have been removed from the network/are not needed in this design/ s/leverage/leverages/ 8.2. Inter-domain SLA The use of anycast SID's also provide an improvement in availability and resiliency. s/SID's/SIDs/ s/provide/provides/ This section is really reduced to the strict minimum. It makes a number of statements which aren't backed-up by descriptive text. I don't necessarily disagree with those but I really think this should be developed. 8.3. Scale Again, to be fair to these protocols I think that you should say here that these protocols are not needed for that use case. Also, could you elaborate on "per-service midpoint states have also been removed from the network." 8.4. ECMP Each policy (intra or inter-domain, with or without TE) is expressed as a list of segments. Since each segment is optimized for ECMP, then the entire policy is optimized for ECMP. The ECMP gain of anycast prefix segment should also be considered (e.g. 16001 load- shares across any gateway from M1 leaf domain to Core and 16002 load- shares across any gateway from Core to M1 leaf domain. 16001 and 16002 are not anycast segments. I am missing something? 14. Informative References I was surprised not to see in the document some references to the useful (necessary?) other documents one should read if he/she wanted to deploy such design. |
2018-10-08
|
00 | Martin Vigoureux | Ballot comment text updated for Martin Vigoureux |
2018-10-08
|
00 | Martin Vigoureux | [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux |
2018-10-08
|
00 | Martin Vigoureux | Created "Approve" ballot |
2018-10-08
|
00 | Martin Vigoureux | Conflict Review State changed to IESG Evaluation from AD Review |
2018-10-05
|
00 | Martin Vigoureux | New version available: conflict-review-filsfils-spring-large-scale-interconnect-00.txt |
2018-09-20
|
00 | Alissa Cooper | Removed from agenda for telechat |
2018-09-20
|
00 | Alissa Cooper | Conflict Review State changed to AD Review from Needs Shepherd |
2018-09-20
|
00 | Alissa Cooper | Shepherding AD changed to Martin Vigoureux |
2018-09-17
|
00 | Amy Vezza | Placed on agenda for telechat - 2018-09-27 |
2018-09-16
|
00 | Adrian Farrel | IETF conflict review requested |