Note: This ballot was opened for revision 00 and is now closed.
Ballot question: "Is this the correct conflict review response?"
Interesting to see that there are apparently two Steven Lins at Google that contributed to this work...
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.