Skip to main content

BGP Prefix Segment in Large-Scale Data Centers
draft-ietf-spring-segment-routing-msdc-11

Revision differences

Document history

Date Rev. By Action
2019-11-18
11 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-10-23
11 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-08-20
11 (System) RFC Editor state changed to RFC-EDITOR from REF
2019-08-06
11 (System) RFC Editor state changed to REF from EDIT
2019-07-04
11 (System) RFC Editor state changed to EDIT from MISSREF
2018-11-30
11 (System) RFC Editor state changed to MISSREF
2018-11-30
11 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-11-30
11 (System) Announcement was received by RFC Editor
2018-11-30
11 (System) IANA Action state changed to No IANA Actions from In Progress
2018-11-30
11 (System) IANA Action state changed to In Progress
2018-11-30
11 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-11-30
11 Cindy Morgan IESG has approved the document
2018-11-30
11 Cindy Morgan Closed "Approve" ballot
2018-11-30
11 Cindy Morgan Ballot approval text was generated
2018-11-30
11 Alvaro Retana IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2018-11-30
11 Alvaro Retana Ballot approval text was generated
2018-11-30
11 Mirja Kühlewind [Ballot comment]
Thanks for addressing my discuss!
2018-11-30
11 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss
2018-11-29
11 Gaurav Dawra New version available: draft-ietf-spring-segment-routing-msdc-11.txt
2018-11-29
11 (System) New version approved
2018-11-29
11 (System) Request for posting confirmation emailed to previous authors: Gaurav Dawra , Clarence Filsfils , Petr Lapukhov , Ebben Aries , Stefano Previdi
2018-11-29
11 Gaurav Dawra Uploaded new revision
2018-10-15
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-10-15
10 Gaurav Dawra New version available: draft-ietf-spring-segment-routing-msdc-10.txt
2018-10-15
10 (System) New version approved
2018-10-15
10 (System) Request for posting confirmation emailed to previous authors: Gaurav Dawra , Clarence Filsfils , Petr Lapukhov , Ebben Aries , Stefano Previdi
2018-10-15
10 Gaurav Dawra Uploaded new revision
2018-09-06
09 Alvaro Retana IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2018-05-29
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-05-29
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2018-05-29
09 Gaurav Dawra New version available: draft-ietf-spring-segment-routing-msdc-09.txt
2018-05-29
09 (System) New version approved
2018-05-29
09 (System) Request for posting confirmation emailed to previous authors: Jon Mitchell , Ebben Aries , spring-chairs@ietf.org, Petr Lapukhov , Clarence Filsfils , Stefano Previdi
2018-05-29
09 Gaurav Dawra Uploaded new revision
2018-01-25
08 Jean Mahoney Closed request for Telechat review by GENART with state 'No Response'
2018-01-18
08 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Tina Tsou.
2018-01-11
08 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2018-01-11
08 Mirja Kühlewind
[Ballot discuss]
Sorry for the late input, but based on the additional TSV review provided by Martin Stiemerling (Thanks!), I got convenienced that I would …
[Ballot discuss]
Sorry for the late input, but based on the additional TSV review provided by Martin Stiemerling (Thanks!), I got convenienced that I would like to discuss the TCP related parts of this document further before publication (even though this is "only" an informational doc). I agree with the TSV review that the solution approaches discussed in 7.1 and 7.2 are slightly speculative and should therefore probably not be published in an RFC without further discussions in respective other groups of the IETF.

Per-packet/flowlet path switching (7.1) will have an impact on the TCP machinery and should be further discussed in a tsv group before it would be presented as a solution approach in an RFC.

Performance-aware routing (7.2) is actually a hard problem as congestion state is changing very dynamically and an attempt to utilize this information on a different time-scale than TCP does can lead to unwanted interfere and interdependencies. We currently have a proposed research group (PANRG) for this sort of problems, and this group would probably a better place for discussing these problems and proposed solutions (instead of an RFC-to-be).

The easiest way to address my concerns is probably to removed TCP-related paragraph from section 3 as well as remove section 7.1 and 7.2 entirely and follow on those discussions in tsv area/tcpm and panrg instead.
2018-01-11
08 Mirja Kühlewind Ballot discuss text updated for Mirja Kühlewind
2018-01-11
08 Mirja Kühlewind
[Ballot discuss]
Sorry for the late input, but based on the additional TSV review provided by Martin Stiemerling (Thanks!), I got convenience I would like …
[Ballot discuss]
Sorry for the late input, but based on the additional TSV review provided by Martin Stiemerling (Thanks!), I got convenience I would like to discuss the TCP related part of this document further before publication (even though this is "only" information doc). I agree with the TSV review that the solution approaches discussed in 7.1 and 7.2 are slightly speculative and should therefore probably not be published in an RFC without further discussions in respective other groups of the IETF.

Per-packet/flowlet path switching (7.1) will have an impact on the TCP machinery and should be further discussed in a tsv group before it would be presented as a solution approach in an RFC.

Performance-aware routing (7.2) is actually a hard problem as congestion state is changing very dynamically and an attempt to utilize this information on a different time-scale than TCP does can lead to unwanted interfere and interdependencies. We currently have a proposed research group (PANRG) for this sort of problems, and this group would probably a better place for discussing these problems and proposed solutions (instead of an RFC-to-be).

The easiest way to address my concerns is probably to removed TCP-related paragraph from section 3 as well as remove section 7.1 and 7.2 entirely and follow on those discussions in tsv area/tcpm and panrg instead.
2018-01-11
08 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to Discuss from No Objection
2018-01-11
08 Benoît Claise [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from No Record
2018-01-11
08 Benoît Claise
[Ballot comment]
OPS DIR review from Tina:

I found this document well written to be READY for publication as an
informational document.

Some nits:

4.2 …
[Ballot comment]
OPS DIR review from Tina:

I found this document well written to be READY for publication as an
informational document.

Some nits:

4.2 eBGP Labeled Unicast (RFC8277)

Each node peers with its neighbors via a eBGP session

should be

Each node peers with its neighbors via an eBGP session

7.  Addressing the open problems

the same could be re-used in context of
  other domains as well

A period is missing in the end.

Are the centralized controller and centralized agent the same components?

Even though the design in this document is specified for same domain, it would
be useful to develop an approach for inter-domain without leaking intra-domain
topology and policy.

Have this feature been included or being aligned with carrier grade FIB in
FD.io VPP https://wiki.fd.io/view/VPP ?
2018-01-11
08 Benoît Claise Ballot comment text updated for Benoit Claise
2018-01-10
08 Adam Roach
[Ballot comment]
I spent a long time trying to understand the following text from section 2, where the sub-bullet appears to flatly contradict its parent …
[Ballot comment]
I spent a long time trying to understand the following text from section 2, where the sub-bullet appears to flatly contradict its parent bullet:

  o  Each node is its own AS (Node X has AS X). 4-byte AS numbers are
      recommended ([RFC6793]).

      *  For simple and efficient route propagation filtering, Node5,
        Node6, Node7 and Node8 use the same AS, Node3 and Node4 use the
        same AS, Node9 and Node10 use the same AS.

After a great deal of study of these and the following bullets, I convinced myself (perhaps incorrectly?) that the intention here is to say "We're going to talk about these nodes as if they each have their own AS, although in real deployments they'll probably be grouped together." Is that the intention? If so, it would be much easier to read if the sub-bullet made this clearer.
2018-01-10
08 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2018-01-10
08 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2018-01-10
08 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-01-10
08 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-01-10
08 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2018-01-10
08 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2018-01-10
08 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2018-01-09
08 Martin Stiemerling Request for Telechat review by TSVART Completed: Not Ready. Reviewer: Martin Stiemerling.
2018-01-08
08 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2018-01-08
08 Martin Stiemerling Request for Telechat review by TSVART is assigned to Martin Stiemerling
2018-01-08
08 Martin Stiemerling Request for Telechat review by TSVART is assigned to Martin Stiemerling
2018-01-05
08 Mirja Kühlewind Requested Telechat review by TSVART
2018-01-05
08 Mirja Kühlewind
[Ballot comment]
I have a question regarding this part in section 3:
"The absence of path visibility leaves transport protocols, such as
      …
[Ballot comment]
I have a question regarding this part in section 3:
"The absence of path visibility leaves transport protocols, such as
      TCP, with a "blackbox" view of the network.  Some TCP metrics,
      such as SRTT, MSS, CWND and few others could be inferred and
      cached based on past history, but those apply to destinations,
      regardless of the path that has been chosen to get there.  Thus,
      for instance, TCP is not capable of remembering "bad" paths, such
      as those that exhibited poor performance in the past.  This means
      that every new connection will be established obliviously (memory-
      less) with regards to the paths chosen before, or chosen by other
      nodes."
Is that actually a well-known problem? This is not fully clear to me. Because given that usually all paths in a data center network have roughly the same characteristics (at least regarding the cached values such as SRTT and MSS) caching of TCP parameters should not be a problem in symmetric topologies like Clos. Or do you have any specific corner cases in mind?
2018-01-05
08 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2018-01-05
08 Mirja Kühlewind
[Ballot comment]
I have a question regarding this part in section 3:
"The absence of path visibility leaves transport protocols, such as
      …
[Ballot comment]
I have a question regarding this part in section 3:
"The absence of path visibility leaves transport protocols, such as
      TCP, with a "blackbox" view of the network.  Some TCP metrics,
      such as SRTT, MSS, CWND and few others could be inferred and
      cached based on past history, but those apply to destinations,
      regardless of the path that has been chosen to get there.  Thus,
      for instance, TCP is not capable of remembering "bad" paths, such
      as those that exhibited poor performance in the past.  This means
      that every new connection will be established obliviously (memory-
      less) with regards to the paths chosen before, or chosen by other
      nodes."
Is that actually a well-known problem? This is not fully clear to me. Because given that usually all paths in a data center network have roughly the same characteristics (at least regarding the chached values such as SRTT and MSS) caching of TCP parameters should not be a problem in symetric topologies like Clos. Or do you have any specific corner cases in mind?
2018-01-05
08 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from No Record
2018-01-05
08 Mirja Kühlewind
[Ballot comment]
I have a question regarding this part in section 3:
"The absence of path visibility leaves transport protocols, such as
      …
[Ballot comment]
I have a question regarding this part in section 3:
"The absence of path visibility leaves transport protocols, such as
      TCP, with a "blackbox" view of the network.  Some TCP metrics,
      such as SRTT, MSS, CWND and few others could be inferred and
      cached based on past history, but those apply to destinations,
      regardless of the path that has been chosen to get there.  Thus,
      for instance, TCP is not capable of remembering "bad" paths, such
      as those that exhibited poor performance in the past.  This means
      that every new connection will be established obliviously (memory-
      less) with regards to the paths chosen before, or chosen by other
      nodes."
Is that actually a well-known problem? This is not fully clear to me. Because given that usually all paths in a data center network have roughly the same characteristics (at least regarding the chached values such as SRTT and MSS) caching of TCP parameters should not be a problem in symetric topologies like Clos. Or do you have any specific corner cases in mind?

Btw. cwnd is usually not cached (ssthresh maybe).
2018-01-05
08 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2017-12-29
08 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2017-12-28
08 Jean Mahoney Request for Telechat review by GENART is assigned to Fernando Gont
2017-12-28
08 Jean Mahoney Request for Telechat review by GENART is assigned to Fernando Gont
2017-12-28
08 Jean Mahoney Closed request for Last Call review by GENART with state 'No Response'
2017-12-21
08 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2017-12-21
08 Gaurav Dawra New version available: draft-ietf-spring-segment-routing-msdc-08.txt
2017-12-21
08 (System) New version approved
2017-12-21
08 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Petr Lapukhov , Ebben Aries , Stefano Previdi , Jon Mitchell
2017-12-21
08 Gaurav Dawra Uploaded new revision
2017-12-20
07 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2017-12-19
07 Alvaro Retana IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2017-12-19
07 Alvaro Retana Ballot has been issued
2017-12-19
07 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2017-12-19
07 Alvaro Retana Created "Approve" ballot
2017-12-19
07 Alvaro Retana Ballot writeup was changed
2017-12-19
07 Alvaro Retana Changed consensus to Yes from Unknown
2017-12-19
07 Alvaro Retana IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup
2017-12-19
07 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2017-12-19
07 Gaurav Dawra New version available: draft-ietf-spring-segment-routing-msdc-07.txt
2017-12-19
07 (System) New version approved
2017-12-19
07 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Petr Lapukhov , Ebben Aries , Stefano Previdi , Jon Mitchell
2017-12-19
07 Gaurav Dawra Uploaded new revision
2017-12-14
06 (System) IESG state changed to Waiting for Writeup from In Last Call
2017-12-12
06 Takeshi Takahashi Request for Last Call review by SECDIR Completed: Ready. Reviewer: Takeshi Takahashi. Sent review to list.
2017-12-09
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Takeshi Takahashi
2017-12-09
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Takeshi Takahashi
2017-12-07
06 Jean Mahoney Request for Last Call review by GENART is assigned to Fernando Gont
2017-12-07
06 Jean Mahoney Request for Last Call review by GENART is assigned to Fernando Gont
2017-12-04
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tina Tsou
2017-12-04
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tina Tsou
2017-12-01
06 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2017-12-01
06 Amanda Baber
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-spring-segment-routing-msdc-06, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-spring-segment-routing-msdc-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Amanda Baber
Lead IANA Services Specialist
2017-11-30
06 Alvaro Retana Notification list changed to aretana.ietf@gmail.com from aretana@cisco.com
2017-11-30
06 Cindy Morgan IANA Review state changed to IANA - Review Needed
2017-11-30
06 Cindy Morgan
The following Last Call announcement was sent out (ends 2017-12-14):

From: The IESG
To: IETF-Announce
CC: spring@ietf.org, spring-chairs@ietf.org, aretana.ietf@gmail.com, draft-ietf-spring-segment-routing-msdc@ietf.org, bruno.decraene@orange.com …
The following Last Call announcement was sent out (ends 2017-12-14):

From: The IESG
To: IETF-Announce
CC: spring@ietf.org, spring-chairs@ietf.org, aretana.ietf@gmail.com, draft-ietf-spring-segment-routing-msdc@ietf.org, bruno.decraene@orange.com, aretana@cisco.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (BGP-Prefix Segment in large-scale data centers) to Informational RFC


The IESG has received a request from the Source Packet Routing in Networking
WG (spring) to consider the following document: - 'BGP-Prefix Segment in
large-scale data centers'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-12-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes the motivation and benefits for applying
  segment routing in BGP-based large-scale data-centers.  It describes
  the design to deploy segment routing in those data-centers, for both
  the MPLS and IPv6 dataplanes.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-msdc/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-msdc/ballot/


No IPR declarations have been submitted directly on this I-D.




2017-11-30
06 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2017-11-30
06 Alvaro Retana Placed on agenda for telechat - 2018-01-11
2017-11-30
06 Alvaro Retana Last call was requested
2017-11-30
06 Alvaro Retana Ballot approval text was generated
2017-11-30
06 Alvaro Retana Ballot writeup was generated
2017-11-30
06 Alvaro Retana IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2017-11-30
06 Alvaro Retana Last call announcement was generated
2017-11-30
06 Alvaro Retana Last call announcement was generated
2017-10-30
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-10-30
06 Arjun Sreekantiah New version available: draft-ietf-spring-segment-routing-msdc-06.txt
2017-10-30
06 (System) New version approved
2017-10-30
06 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Petr Lapukhov , Ebben Aries , Stefano Previdi , Jon Mitchell
2017-10-30
06 Arjun Sreekantiah Uploaded new revision
2017-08-31
05 Alvaro Retana
=== AD Review of draft-ietf-spring-segment-routing-msdc-05 ===
https://mailarchive.ietf.org/arch/msg/spring/PnzueRoyev9wQ3_0c_rRCBu0zjk/?qid=f318375fa7a03bea26d12df815d73dae

Dear authors:

I just finished reading this document.  Thanks for a clear and straight forward draft!

I have …
=== AD Review of draft-ietf-spring-segment-routing-msdc-05 ===
https://mailarchive.ietf.org/arch/msg/spring/PnzueRoyev9wQ3_0c_rRCBu0zjk/?qid=f318375fa7a03bea26d12df815d73dae

Dear authors:

I just finished reading this document.  Thanks for a clear and straight forward draft!

I have some comments (see below).  The main one is about the inclusion of hosts as defining the source routed path, without them being explicitly called out in the draft-ietf-spring-segment-routing.  Knowing that some of the authors overlap, please make sure there are no holes in the Architecture.  I will start the IETF LC once this item is addressed, and a revised ID is produced do address the other comments, as needed.

Thanks!

Alvaro.


Major:

M1. As with draft-ietf-spring-segment-routing-central-epe, it worries me that hosts are called out as being able to define the source routed path.  Please make sure that the Architecture document has some text about the use of hosts – maybe constrained to the case where the hosts can be programmed.  Section 6 provides some good text for that.


Minor:

P1. “service chain”: please remove to avoid confusion with SFC (same comment as for all the SR documents).

P2. References:
- s/rfc3107/draft-ietf-mpls-rfc3107bis
- The references to I-D.ietf-spring-segment-routing-central-epe and rfc7938 should be Normative.

P3. There are 2 instances of using rfc2119 language, I don’t think that either is needed because you’re really paraphrasing other documents.  IOW, I recommend you take the Normative language off.

P3.1. Section 4.2.1. (Control Plane): “The implicit-null label in the NLRI tells Node10 that it is the penultimate hop and MUST pop the top label…”  This is normal MPLS operation, so the MUST is really not introducing anything new, just paraphrasing the MPLS architecture.  Instead of the MUST, a reference to MPLS would be more than enough.  s/MUST/must

P3.2. Section 11. (Manageability Considerations): “As recommended in [I-D.ietf-spring-segment-routing], the same SRGB SHOULD be allocated in all nodes…”  The Architecture document doesn’t (yet) make that recommendation explicitly, but a pointer to it should be enough.  s/SHOULD/should

P4. Section 4.2.4. (Global BGP Prefix Segment through the fabric): “…a packet with top label 16011 received by any node in the fabric…and the label 16011 is penultimate-popped at Node10”, or at Node9, right?

P5. Section 4.3: “…and with the BGP-Prefix-SID attribute extension defined in this document”; that was not defined in this document.

P6. Section 4.3. (iBGP Labeled Unicast (RFC3107)) contains this text: “AIGP metric ([RFC7311]) is likely applied to the BGP-Prefix-SID as part of a large-scale multi-domain design such as Seamless MPLS [I-D.ietf-mpls-seamless-mpls].“  This paragraph sounds random to me as there is no further explanation of the use, impact, advantages, etc.  Neither AIGP/Seamless MPLS is mentioned again in the document, nor in draft-ietf-idr-bgp-prefix-sid or rfc7938.  Please either expand the concepts/use or delete this paragraph.

P7. Section 5. (Applying Segment Routing in the DC with IPv6 dataplane): “Node5 originates 2001:DB8::5/128 with the attached BGP-Prefix-SID advertising the support of the Segment Routing extension header (SRH, [I-D.ietf-6man-segment-routing-header])…”  draft-ietf-idr-bgp-prefix-sid says nothing explicitly about the BGP-Prefix-SID Attribute advertising support for the SRH – maybe it should, but it doesn’t.

NEW>
  Node5 originates 2001:DB8::5/128 with the attached BGP-Prefix-SID
  for IPv6 packets destined to
  segment 2001:DB8::5 ([I-D.ietf-idr-bgp-prefix-sid]).

Instead, put the reference later in the same section where it says “…sending IPv6 packets with a SRH extension header…”.


Nits:

N1. s/BGP4/BGP-4

N2. Section 3: “Further in this document…”  A reference to Section 7 would be nice.

N3. s/index11)/index11

N4. It would have been nice to illustrate the operation in 4.2.x using IPv6 addresses.

N5. Throughout most of the document the nodes are referred to as Nodex, but there are a couple of places where Torx is used.  Even though these nodes have been identified as ToRs, it would be nice to be consistent to avoid confusion.

N6. Section 7: s/problems describe above/problems described above  Also, putting a reference back to Section 3 would be nice.

N7. The content in Section 7 is good, and the DC example helps in the illustration – but the applicability is not just constrained to it.  It might be a good idea to add at note at the start mentioning the broader applicability.

N8. Please avoid using “we”.
2017-08-31
05 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2017-08-30
05 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2017-08-30
05 Alvaro Retana Notification list changed to aretana@cisco.com
2017-06-20
05 Stefano Previdi New version available: draft-ietf-spring-segment-routing-msdc-05.txt
2017-06-20
05 (System) New version approved
2017-06-20
05 (System) Request for posting confirmation emailed to previous authors: Stefano Previdi , Jon Mitchell , Ebben Aries , spring-chairs@ietf.org, Petr Lapukhov , Clarence Filsfils
2017-06-20
05 Stefano Previdi Uploaded new revision
2017-03-21
04 Bruno Decraene
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Requested status is "Informational" as indicated in the title page header.
This is appropriate for a document describing a use case and the applicability of Segment Routing to this use case.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  The document describes the motivation and benefits for applying
  segment routing in BGP-based large-scale data-center.  It describes the design to
  deploy segment routing in those data-center, for both the MPLS and IPv6 dataplanes.

Working Group Summary:

There has been good support during WG adoption and no opposition since then.

Document Quality:

There are three implementations of the related BGP extensions. There is no publicly known deployment, but it's said that one is in progress and another one in preparation.

Personnel:

Bruno Decraene is the Document Shepherd. Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Full review of this document. Comments sent on the mailing list.
https://mailarchive.ietf.org/arch/msg/spring/f5BtvW81G8v0yOD28Z3frdqORjY
https://mailarchive.ietf.org/arch/msg/spring/uhg7t7WuDt0D9LiSGYD1BbVDMwo

Review of the related BGP extensions in the IDR WG, in particular to check for consistency. https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-03

Review of all emails on this WG document. (emails on the individual version of the draft are too old/out of sync)

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.
- WG Last Call has been forwarded to the IDR WG which host the related BGP protocol extension: https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid
- IDR WG has initiated the WG Last Call of this BGP extension (IDR LC 3/6 to 3/20/2017).
- WG Last Call has been forwarded to RTGWG WG which had published a related RFC (RFC 7938 “Use of BGP for Routing in Large-Scale Data Centers”) https://tools.ietf.org/html/rfc7938
- A routing directorate review has been done by Susan Hares (IDR co-chair).

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No specific review needed.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concern.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors have confirmed IPR disclosure.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosed. https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-msdc
On a side note, there is also no IPR on the related BGP extension  https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-idr-bgp-prefix-sid


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG as a whole understand and agree with the document, there is WG consensus and no opposition.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No. No one expressed opposition to this document.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID Nits run fine. https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-spring-segment-routing-msdc-04.txt


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

[I-D.ietf-spring-segment-routing] has been submitted to IESG.
[I-D.ietf-idr-bgp-prefix-sid] is currently under WG Last Call in the IDR WG.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downward normative references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Publication of this document will not change the status of any existing RFCs.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

There is no IANA section and no need for one.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

N/A
2017-03-21
04 Bruno Decraene Responsible AD changed to Alvaro Retana
2017-03-21
04 Bruno Decraene IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2017-03-21
04 Bruno Decraene IESG state changed to Publication Requested
2017-03-21
04 Bruno Decraene IESG process started in state Publication Requested
2017-03-21
04 Bruno Decraene Tag Doc Shepherd Follow-up Underway cleared.
2017-03-21
04 Bruno Decraene IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2017-03-13
04 Bruno Decraene waiting for end of IDR LC on the protocol extension (3/6 to 3/20/2017)
2017-03-13
04 Bruno Decraene Tag Doc Shepherd Follow-up Underway set.
2017-03-13
04 Bruno Decraene IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2017-03-13
04 Bruno Decraene Changed document writeup
2017-03-09
04 Stefano Previdi New version available: draft-ietf-spring-segment-routing-msdc-04.txt
2017-03-09
04 (System) New version approved
2017-03-09
04 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Jon Mitchell , Ebben Aries , Petr Lapukhov , Stefano Previdi
2017-03-09
04 Stefano Previdi Uploaded new revision
2017-03-06
03 Susan Hares Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Susan Hares. Sent review to list.
2017-03-03
03 Clarence Filsfils New version available: draft-ietf-spring-segment-routing-msdc-03.txt
2017-03-03
03 (System) New version approved
2017-03-03
03 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Jon Mitchell , Ebben Aries , Petr Lapukhov , Stefano Previdi
2017-03-03
03 Clarence Filsfils Uploaded new revision
2017-02-22
02 Jonathan Hardwick Request for Last Call review by RTGDIR is assigned to Susan Hares
2017-02-22
02 Jonathan Hardwick Request for Last Call review by RTGDIR is assigned to Susan Hares
2017-02-22
02 Bruno Decraene Requested Last Call review by RTGDIR
2017-02-21
02 Bruno Decraene WGLC: https://mailarchive.ietf.org/arch/msg/spring/XAd1rcZDX66D9NRGvhKbamAgrLg
Until 7th of March
2017-02-21
02 Bruno Decraene IETF WG state changed to In WG Last Call from WG Document
2017-01-27
02 Martin Vigoureux Notification list changed to none from "Bruno Decraene" <bruno.decraene@orange.com>
2017-01-27
02 Martin Vigoureux Notification list changed to "Bruno Decraene" <bruno.decraene@orange.com>
2017-01-27
02 Martin Vigoureux Document shepherd changed to Bruno Decraene
2016-10-03
02 Stefano Previdi New version available: draft-ietf-spring-segment-routing-msdc-02.txt
2016-10-03
02 (System) New version approved
2016-10-03
02 (System) Request for posting confirmation emailed to previous authors: "Jon Mitchell" , spring-chairs@ietf.org, "Ebben Aries" , "Clarence Filsfils" , "Stefano Previdi" , "Petr Lapukhov"
2016-10-03
02 Stefano Previdi Uploaded new revision
2016-04-13
01 Stefano Previdi New version available: draft-ietf-spring-segment-routing-msdc-01.txt
2015-11-02
00 Bruno Decraene Intended Status changed to Informational from None
2015-10-12
00 Bruno Decraene This document now replaces draft-filsfils-spring-segment-routing-msdc instead of None
2015-10-12
00 Stefano Previdi New version available: draft-ietf-spring-segment-routing-msdc-00.txt