Skip to main content

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