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 |