Segment Routing Centralized BGP Egress Peer Engineering
draft-ietf-spring-segment-routing-central-epe-10

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

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

(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

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/

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

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