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.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
