Skip to main content

Segment Routing Centralized BGP Egress Peer Engineering
RFC 9087

Revision differences

Document history

Date Rev. By Action
2021-08-14
10 (System)
Received changes through RFC Editor sync (created alias RFC 9087, changed abstract to 'Segment Routing (SR) leverages source routing. A node steers a packet …
Received changes through RFC Editor sync (created alias RFC 9087, changed abstract to 'Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows for the enforcement of a flow through any topological path while maintaining per-flow state only at the ingress node of the SR domain.

The Segment Routing architecture can be directly applied to the MPLS data plane with no change on the forwarding plane. It requires a minor extension to the existing link-state routing protocols.

This document illustrates the application of Segment Routing to solve the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based BGP-EPE solution allows a centralized (Software-Defined Networking, or SDN) controller to program any egress peer policy at ingress border routers or at hosts within the domain.', changed pages to 17, changed standardization level to Informational, changed state to RFC, added RFC published event at 2021-08-14, changed IESG state to RFC Published)
2021-08-14
10 (System) RFC published
2021-08-12
10 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-07-07
10 (System) RFC Editor state changed to AUTH48
2021-04-21
10 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-04-14
10 (System) RFC Editor state changed to EDIT from MISSREF
2017-12-21
10 (System) RFC Editor state changed to MISSREF
2017-12-21
10 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2017-12-21
10 (System) Announcement was received by RFC Editor
2017-12-21
10 (System) IANA Action state changed to No IC from In Progress
2017-12-21
10 (System) IANA Action state changed to In Progress
2017-12-21
10 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2017-12-21
10 Amy Vezza IESG has approved the document
2017-12-21
10 Amy Vezza Closed "Approve" ballot
2017-12-21
10 Amy Vezza Ballot approval text was generated
2017-12-21
10 Alvaro Retana IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2017-12-21
10 Gaurav Dawra New version available: draft-ietf-spring-segment-routing-central-epe-10.txt
2017-12-21
10 (System) New version approved
2017-12-21
10 (System) Request for posting confirmation emailed to previous authors: Gaurav Dawra , Stefano Previdi , Ebben Aries , Dmitry Afanasiev , Clarence Filsfils
2017-12-21
10 Gaurav Dawra Uploaded new revision
2017-12-21
09 Gaurav Dawra New version available: draft-ietf-spring-segment-routing-central-epe-09.txt
2017-12-21
09 (System) New version approved
2017-12-21
09 (System) Request for posting confirmation emailed to previous authors: Gaurav Dawra , Stefano Previdi , Ebben Aries , Dmitry Afanasiev , Clarence Filsfils
2017-12-21
09 Gaurav Dawra Uploaded new revision
2017-12-19
08 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2017-12-18
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-12-18
08 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2017-12-18
08 Gaurav Dawra New version available: draft-ietf-spring-segment-routing-central-epe-08.txt
2017-12-18
08 (System) New version approved
2017-12-18
08 (System) Request for posting confirmation emailed to previous authors: Ebben Aries , Gaurav Dawra , Dmitry Afanasiev , spring-chairs@ietf.org, Clarence Filsfils , Stefano Previdi
2017-12-18
08 Gaurav Dawra Uploaded new revision
2017-12-15
07 Alvaro Retana IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::Point Raised - writeup needed
2017-12-14
07 Cindy Morgan IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2017-12-14
07 Jean Mahoney Closed request for Last Call review by GENART with state 'No Response'
2017-12-14
07 Kathleen Moriarty
[Ballot comment]
Thanks for your work on this draft.  I agree with Ben's first comment in that the purpose and continued flow of the draft …
[Ballot comment]
Thanks for your work on this draft.  I agree with Ben's first comment in that the purpose and continued flow of the draft aligned to that purpose could be made more clear.
2017-12-14
07 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2017-12-14
07 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2017-12-14
07 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Russ Mundy.
2017-12-13
07 Ben Campbell
[Ballot comment]
Substantive Comments:

- General: The purpose of this draft is not clear. It claims to describe a solution in places. It's not clear …
[Ballot comment]
Substantive Comments:

- General: The purpose of this draft is not clear. It claims to describe a solution in places. It's not clear to me if this is a "solution", a set of requirements, or a general exploration of the design possibilities. The shepherd writeup doesn't really help, since it explicitly says this draft describes a "solution", which is usually more of a standards track thing.  I don't mean to say that I think it should not be informational, but a description of _why_ it's informational (in the draft itself) would be helpful. (This is further confused by the heavy use of language like "might", "could be", "likely", etc. throughout parts of the draft.)

- Requirements Language: The 2119 keywords in this draft are not used in the sense of RFC 2119. That RFC talks explicitly about interoperability among protocol implementations. This draft uses them to define requirement for protocol and architecture design. That's not necessarily a problem, but please change the Requirements Language section to describe the actual usage.

-10: The security considerations are entirely made up of citations to the underlying technology drafts. It should also talk about whether there are new security considerations introduced by there use in the context of this draft. Even if the answer is that there aren't any, it would be helpful to describe the thought processes that lead to that conclusion.

Editorial Comments and Nits:

- 1: The introduction is not really an introduction. I expected to find a description of the purpose of the draft, but all there is is a description of the draft structure.
-- Please expand "SID" on first mention.

-2, first paragraph: missing article before "BGP-EPE capable node"

-4.6: I can't parse the first sentence.
2017-12-13
07 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2017-12-13
07 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2017-12-13
07 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2017-12-13
07 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2017-12-07
07 Min Ye Request for Telechat review by RTGDIR Completed: Has Issues. Reviewer: Andrew Malis.
2017-11-30
07 Alvaro Retana IESG state changed to IESG Evaluation from Waiting for Writeup
2017-11-30
07 Alvaro Retana Ballot has been issued
2017-11-30
07 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2017-11-30
07 Alvaro Retana Created "Approve" ballot
2017-11-30
07 Alvaro Retana Ballot writeup was changed
2017-11-30
07 Alvaro Retana Changed consensus to Yes from Unknown
2017-11-30
07 (System) IESG state changed to Waiting for Writeup from In Last Call
2017-11-18
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Russ Mundy
2017-11-18
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Russ Mundy
2017-11-09
07 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2017-11-09
07 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-spring-segment-routing-central-epe-07, 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-central-epe-07, 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,

Sabrina Tanamal
IANA Services Specialist
2017-11-07
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2017-11-07
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2017-11-07
07 Min Ye Request for Telechat review by RTGDIR is assigned to Andrew Malis
2017-11-07
07 Min Ye Request for Telechat review by RTGDIR is assigned to Andrew Malis
2017-11-03
07 Jean Mahoney Request for Last Call review by GENART is assigned to Fernando Gont
2017-11-03
07 Jean Mahoney Request for Last Call review by GENART is assigned to Fernando Gont
2017-11-03
07 Amy Vezza IANA Review state changed to IANA - Review Needed
2017-11-03
07 Amy Vezza
The following Last Call announcement was sent out (ends 2017-11-30):

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

From: The IESG
To: IETF-Announce
CC: draft-ietf-spring-segment-routing-central-epe@ietf.org, bruno.decraene@orange.com, spring@ietf.org, spring-chairs@ietf.org, aretana.ietf@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Segment Routing Centralized BGP Egress Peer Engineering) to Informational RFC


The IESG has received a request from the Source Packet Routing in Networking
WG (spring) to consider the following document: - 'Segment Routing
Centralized BGP Egress Peer Engineering'
  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-11-30. 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


  Segment Routing (SR) leverages source routing.  A node steers a
  packet through a controlled set of instructions, called segments, by
  prepending the packet with an SR header.  A segment can represent any
  instruction topological or service-based.  SR allows to enforce a
  flow through any topological path while maintaining per-flow state
  only at the ingress node of the SR domain.

  The Segment Routing architecture can be directly applied to the MPLS
  dataplane with no change on the forwarding plane.  It requires a
  minor extension to the existing link-state routing protocols.

  This document illustrates the application of Segment Routing to solve
  the BGP Egress Peer Engineering (BGP-EPE) requirement.  The SR-based
  BGP-EPE solution allows a centralized (Software Defined Network, SDN)
  controller to program any egress peer policy at ingress border
  routers or at hosts within the domain.





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

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

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2721/
  https://datatracker.ietf.org/ipr/2548/





2017-11-03
07 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2017-11-03
07 Alvaro Retana Requested Telechat review by RTGDIR
2017-11-03
07 Alvaro Retana Placed on agenda for telechat - 2017-12-14
2017-11-03
07 Alvaro Retana Last call was requested
2017-11-03
07 Alvaro Retana Ballot approval text was generated
2017-11-03
07 Alvaro Retana Ballot writeup was generated
2017-11-03
07 Alvaro Retana IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2017-11-03
07 Alvaro Retana Last call announcement was changed
2017-11-03
07 Alvaro Retana Notification list changed to aretana.ietf@gmail.com from aretana@cisco.com
2017-10-29
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-10-29
07 Gaurav Dawra New version available: draft-ietf-spring-segment-routing-central-epe-07.txt
2017-10-29
07 (System) New version approved
2017-10-28
07 (System) Request for posting confirmation emailed to previous authors: Dmitry Afanasiev , Ebben Aries , spring-chairs@ietf.org, Stefano Previdi , Clarence Filsfils
2017-10-28
07 Gaurav Dawra Uploaded new revision
2017-08-30
06 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2017-08-30
06 Alvaro Retana Notification list changed to aretana@cisco.com
2017-08-30
06 Alvaro Retana
=== AD Review of draft-ietf-spring-segment-routing-central-epe-06 ===
https://mailarchive.ietf.org/arch/msg/spring/_zSoCdoSUB1ctCuwgKC7q_eAuVc/?qid=5f91a5b19c532064dd153dd976fa2dd8

Dear authors:

I just finished reading this document.  I have a couple of Major concerns (see below) which …
=== AD Review of draft-ietf-spring-segment-routing-central-epe-06 ===
https://mailarchive.ietf.org/arch/msg/spring/_zSoCdoSUB1ctCuwgKC7q_eAuVc/?qid=5f91a5b19c532064dd153dd976fa2dd8

Dear authors:

I just finished reading this document.  I have a couple of Major concerns (see below) which I would like to see addressed before starting the IETF Last Call on this document.

Thanks!!

Alvaro.



Major:

M1. This document mentions in several places that the segment routing information can be programmed at hosts (or “content source”).  As we all know, significant concerns exist in the community about using source routing all the way at the host (even if, as in this case, we’re talking about a centralized programing).  The Architecture document doesn’t explicitly eliminate hosts from an SR domain (the definition is “nodes participating into the source routing model”), but it also doesn’t explicitly include them…but the text can be interpreted as excluding (for example: “the explicit routing information MUST NOT be leaked through the boundaries of the administered domain”, or “Filtering MUST be performed on the forwarding plane at the boundaries of the SR domain”, etc.).  There is nothing specific that tells me that this case (EPE) is different from any other SR application – if hosts are to be explicitly considered part of a domain then that should be explicitly described in the Architecture document.  In short, please take references to hosts out of this document (unless you decide to add a discussion about them in the Architecture document).


M2. The requirements in Section 1.1. (Problem Statement) make non-explicit use of normative language; most of the requirements are non-technical and aspirational in nature.  While I think that the normative language is not used as intended in rfc2119 (“MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm”), I think it is ok in this case to express some requirements.  I would, however, prefer if their use las limited.  Nevertheless, here are some suggestions/questions/comments:

M2.1. What does “MUST NOT make any assumption” mean?
OLD>
    The solution MUST NOT make any assumption on the currently
      deployed iBGP schemes (RRs, confederations or iBGP full meshes)
      and MUST be able to support all of them.

NEW>
      The solution MUST support any deployed iBGP schemes
      (RRs, confederations or iBGP full meshes).

M.2.2. Two MUSTs doesn’t make the text better.
OLD>
    The solution MUST be applicable to any type of EPE router.  While
      "Egress Peer Engineering" refers to "External" peering, the
      solution MUST also be applicable to a router having internal
      peers.

NEW>
      The solution MUST be applicable to both routers with external
      and internal peers.

M2.3. “The solution SHOULD minimize the need for new BGP capabilities at the ingress PEs.”  What is the explicit requirement, that needs the “SHOULD”, from an interoperability point of view?

M2.4. “The solution MUST accommodate an ingress BGP-EPE policy at an ingress PE or directly at a source host within the domain.”  “MUST accommodate”??  What are you looking for?  The ability to program at those points?  The ability to instantiate any policy?  The Introduction says that “The exhaustive definition of all the means to program an BGP-EPE input policy is outside the scope of this document.”, so mandating something that is out of scope seems like a contradiction.

M2.5. “The solution MUST support automated Fast Reroute (FRR) and fast convergence mechanisms.”  But then section 3.6. (Fast Reroute (FRR)) says that FRR is optional.


M3. The references to I-D.ietf-idr-bgpls-segment-routing-epe, I-D.ietf-spring-segment-routing and RFC7752 should be Normative.


Minor:

P1. As in all the related documents, please take “service chain” out to avoid confusion.


P2. The examples in Sections 3.x seem incomplete and inaccurate to me.  Also, the names used don’t match what is specified in draft-ietf-idr-bgpls-segment-routing-epe.  In general, please be consistent with the names!  For example:

Section 3.1. (PeerNode SID to D):

  Descriptors:

  o  Node Descriptors (BGP router-ID, ASN): 192.0.2.3, AS1

  o  Peer Descriptors (peer BGP router-ID, peer ASN): 192.0.2.4, AS2

  o  Link Descriptors (IP interface address, neighbor IP address):
      2001:db8:cd::c, 2001:db8:cd::d

  Attributes:

  o  PeerNode SID: 1012


Comments>
- Section 5.1 in draft-ietf-idr-bgpls-segment-routing-epe uses “Local Node Descriptor” instead of simply “Node Descriptor”, and the BGP-LS ID is missing above.
- s/Peer Descriptors/Remote Node Descriptor
- The Link Descriptor uses the terms “IPv6 Interface Address” and “IPv6 Neighbor Address”…
- s/Attributes/Link Attribute


P3. Section 3.6. (Fast Reroute (FRR)): “A BGP-EPE enabled border router MAY allocate a FRR backup entry on a per BGP Peering SID basis (assuming inter-AS agreement on the FRR strategy/policy).”  Why is an “inter-AS agreement” needed?  FRR is a local decision, and, assuming that the border router is at the edge of the SR domain…why would the next AS need to agree?  Am I missing something?


P4. References:
- Please add a reference for BMP and IPFIX.
- Put the reference to BGP-LS on first mention (and not just way down in Section 9).
- Replace the reference to RFC3107 with draft-ietf-mpls-rfc3107bis – and it can be made Informative.
- The reference to RFC6241 should be Informative.


P5. From Section 9. (Manageability Considerations): “…the advertisement of EPE information MUST conform to standard BGP advertisement and propagation rules (iBGP, eBGP, Route-Reflectors, Confederations).”  What does this text mean?  As far as I can tell, there’s no change to BGP to be able to instantiate EPE…


Nits:

N1. The second paragraph in the Abstract seems unnecessary.

N2. Please avoid using “we”.

N3. Section 5.2 seems to introduce this new notation: “IP route L/8 set next-hop T1”… please explain.  L/8 is “hidden” in Figure 1, and not obvious since it looks like an IPv4 prefix, but the examples are all IPv6.

2017-08-23
06 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2017-06-20
06 Stefano Previdi New version available: draft-ietf-spring-segment-routing-central-epe-06.txt
2017-06-20
06 (System) New version approved
2017-06-20
06 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Ebben Aries , spring-chairs@ietf.org, Stefano Previdi , Dmitry Afanasiev
2017-06-20
06 Stefano Previdi Uploaded new revision
2017-03-17
05 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 documenting how to solve the BGP Egress Peer Engineering use case using Segment Routing and the Segment Routing BGP-LS extensions.

(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:

  Segment Routing (SR) leverages source routing.  A node steers a
  packet through a controlled set of instructions, called segments, by
  prepending the packet with an SR header.  A segment can represent any
  instruction topological or service-based.  SR allows to enforce a
  flow through any topological path and service chain while maintaining
  per-flow state only at the ingress node of the SR domain.
 
  This document illustrates the application of Segment Routing to solve
  the BGP Egress Peer Engineering (BGP-EPE) requirement.  The SR-based
  BGP-EPE solution allows a centralized (Software Defined Network, SDN)
  controller to program any egress peer policy at ingress border
  routers or at hosts within the domain.

Working Group Summary:

There has been support during working group adoption and no controversy.

Document Quality:

There are three implementations of the BGP-LS extensions defined in draft-ietf-idr-bgpls-segment-routing-epe and enabling the Segment Routing Centralized BGP Egress Peer Engineering described in this document.
RTG directorate review found the document very clear.


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.

I've reviewed draft-ietf-spring-segment-routing-central-epe-03 and sent a set of comments to the authors a SPRING WG.
https://mailarchive.ietf.org/arch/msg/spring/dU2CXWKX5EYNnTj7xFocjHVuA-w
I've reviewed the IDR WG BGP-LS extensions required for this document. I've found some lack of alignment between both documents, both on the terminology and some protocol extensions. They have been addressed by the authors.
I've asked authors of the BGP-LS extensions and the IDR chairs about the maturity of the BGP-LS extension. As a result, IDR ran WG LC from 2017/02/15 to 2017/3/1.

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

No concern.
The BGP-LS extension is in WG last call in IDR and has three implementations.

A recent routing directorate review has been done by Jonathan Hardwick. His comments have been addressed by authors.

(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.

(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, except Daniel Ginsburg who has not responded since the July 20'16 IPR call, despite multiple requests from the chairs and the editor of the document. As a consequence he has been removed from the list of authors and listed as contributor.

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

Two IPR have been filed for this document. During WG Last Call, chairs reminded the WG about those two IPRs. There has been no WG comments on those IPRs.
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-central-epe


(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?

WG understand the document and agree with it: there has been significant support during WG adoption.
Post WG adoption, WG involvement has been limited.

(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.

(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.

Idnits run fine. There is one outdated reference, but this is expected as many WGLC are running in parallel (both in SPRING and IDR WG)
No significant nits found in my review sent on the mailing list.

(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?

No.

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

N/A.


(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-17
05 Bruno Decraene Responsible AD changed to Alvaro Retana
2017-03-17
05 Bruno Decraene IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2017-03-17
05 Bruno Decraene IESG state changed to Publication Requested
2017-03-17
05 Bruno Decraene IESG process started in state Publication Requested
2017-03-16
05 Bruno Decraene Changed document writeup
2017-03-16
05 Bruno Decraene Changed document writeup
2017-03-16
05 Bruno Decraene Changed document writeup
2017-03-10
05 Stefano Previdi New version available: draft-ietf-spring-segment-routing-central-epe-05.txt
2017-03-10
05 (System) New version approved
2017-03-10
05 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Ebben Aries , Dmitry Afanasiev , Stefano Previdi
2017-03-10
05 Stefano Previdi Uploaded new revision
2017-03-07
04 Jonathan Hardwick Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Jonathan Hardwick.
2017-02-22
04 Jonathan Hardwick Request for Last Call review by RTGDIR is assigned to Jonathan Hardwick
2017-02-22
04 Jonathan Hardwick Request for Last Call review by RTGDIR is assigned to Jonathan Hardwick
2017-02-22
04 Bruno Decraene Requested Last Call review by RTGDIR
2017-02-16
04 Stefano Previdi New version available: draft-ietf-spring-segment-routing-central-epe-04.txt
2017-02-16
04 (System) New version approved
2017-02-16
04 (System) Request for posting confirmation emailed to previous authors: "Dmitry Afanasiev" , "Clarence Filsfils" , "Stefano Previdi" , "Ebben Aries"
2017-02-16
04 Stefano Previdi Uploaded new revision
2017-02-13
03 Bruno Decraene WGLC ends the 27th of February
https://mailarchive.ietf.org/arch/msg/spring/dkYKSh3ZRHZPUsTSWUv5Ft4aqkI
2017-02-13
03 Bruno Decraene IETF WG state changed to In WG Last Call from WG Document
2017-01-27
03 Martin Vigoureux Notification list changed to none from "Martin Vigoureux" <martin.vigoureux@nokia.com>, "Bruno Decraene" <bruno.decraene@orange.com>
2017-01-27
03 Martin Vigoureux Notification list changed to "Martin Vigoureux" <martin.vigoureux@nokia.com>, "Bruno Decraene" <bruno.decraene@orange.com> from "Martin Vigoureux" <martin.vigoureux@nokia.com>
2017-01-27
03 Martin Vigoureux Document shepherd changed to Bruno Decraene
2016-11-21
03 Stefano Previdi New version available: draft-ietf-spring-segment-routing-central-epe-03.txt
2016-11-21
03 (System) New version approved
2016-11-20
03 (System) Request for posting confirmation emailed to previous authors: spring-chairs@ietf.org, "Ebben Aries" , "Dmitry Afanasiev" , "Clarence Filsfils" , "Stefano Previdi" , "Daniel Ginsburg"
2016-11-20
03 Stefano Previdi Uploaded new revision
2016-09-13
02 Stefano Previdi New version available: draft-ietf-spring-segment-routing-central-epe-02.txt
2016-09-13
02 Stefano Previdi New version approved
2016-09-13
02 Stefano Previdi Request for posting confirmation emailed to previous authors: "Dmitry Afanasiev" , "Clarence Filsfils" , "Ebben Aries" , "Daniel Ginsburg" , "Stefano Previdi"
2016-09-13
02 (System) Uploaded new revision
2016-09-09
01 Martin Vigoureux Notification list changed to "Martin Vigoureux" <martin.vigoureux@nokia.com>
2016-09-09
01 Martin Vigoureux Document shepherd changed to Martin Vigoureux
2016-03-21
01 Stefano Previdi New version available: draft-ietf-spring-segment-routing-central-epe-01.txt
2015-12-02
Naveen Khan Posted related IPR disclosure: Google Inc.'s Statement about IPR related to draft-ietf-spring-segment-routing-central-epe and draft-ietf-idr-bgpls-segment-routing-epe
2015-10-15
00 Bruno Decraene Intended Status changed to Informational from None
2015-10-15
00 Bruno Decraene This document now replaces draft-filsfils-spring-segment-routing-central-epe instead of None
2015-10-15
00 Stefano Previdi New version available: draft-ietf-spring-segment-routing-central-epe-00.txt