IETF conflict review for draft-filsfils-spring-large-scale-interconnect
conflict-review-filsfils-spring-large-scale-interconnect-00

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.