Skip to main content

Telechat Review of draft-ietf-spring-segment-routing-central-epe-07

Request Review of draft-ietf-spring-segment-routing-central-epe
Requested revision No specific revision (document currently at 10)
Type Telechat Review
Team Routing Area Directorate (rtgdir)
Deadline 2017-12-12
Requested 2017-11-03
Requested by Alvaro Retana
Authors Clarence Filsfils , Stefano Previdi , Gaurav Dawra , Ebben Aries , Dmitry Afanasiev
I-D last updated 2017-12-07
Completed reviews Rtgdir Last Call review of -04 by Jonathan Hardwick (diff)
Rtgdir Telechat review of -07 by Andrew G. Malis (diff)
Secdir Last Call review of -07 by Russ Mundy (diff)
Assignment Reviewer Andrew G. Malis
State Completed
Request Telechat review on draft-ietf-spring-segment-routing-central-epe by Routing Area Directorate Assigned
Reviewed revision 07 (document currently at 10)
Result Has issues
Completed 2017-12-07

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review. The purpose of
the review is to provide assistance to the Routing ADs. For more
information about the Routing Directorate, please see ‚Äč

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-spring-segment-routing-central-epe-07.txt
Reviewer: Andy Malis
Review Date: 7 December 2017
IETF LC End Date: 30 November 2017
Intended Status: Informational

I have some minor concerns about this document that I think should be
resolved before publication.

This document very usefully demonstrates how Segment Routing can be used to
provide BGP Egress Peer Engineering through the use of a centralized

It has been through a number of reviews, so it is overall in good shape for

Major Issues:

No major issues found.

Minor Issues:

1. This document is Informational, as it doesn't define any new protocol
elements or contain any new actions for IANA. However, it does make use of
RFC 2119 language. Alvaro Retana has already commented on this usage, and I
would like to add that especially in an Informational document, the use of
RFC 2119 language should be minimal and strictly used only to ensure
interoperability (see section 6 of RFC 2119).

In particular, I don't agree with the use of the uppercase MUST in the
second paragraph of section 9, which is imposing a requirement on an
operator. This paragraph is simply a rephrasing of section 9 in
draft-ietf-idr-bgpls-segment-routing-epe. I would much prefer a simple
reference to that section in draft-ietf-idr-bgpls-segment-routing-epe
rather than a restatement of that text in this document. That will also
ensure that if the text in draft-ietf-idr-bgpls-segment-routing-epe should
change (as that draft is still in progress), it would not require an update
of this document to match.

2. I think that it would be useful to move section 7 higher in the
document, perhaps as section 1.2.

3. I also note that the comments made by Alvaro in his email of November 3
have not yet been addressed. I agree with his comments, and request that
they be addressed prior to publication.