I uploaded version 11 to IETF. See repond inline "#Ahmed"
Thanks again for the thorough review
Ahmed
On 1/3/20 12:00 PM, Yingzhen Qu wrote:
Hi authors,
Happy New Year!
I did a review of draft-ietf-rtgwg-bgp-pic-10 for shepherd write-up.
Thanks for working on this informational document, and it’s very
useful to improve routing convergence.
I have the following comments and would like you to consider.
General:
* Throughout the document, both BGP PIC and BGP-PIC are used. I’m ok
with either one, please keep it consistent.
* Regarding references, idnits is giving the following warnings:
== Outdated reference: draft-ietf-spring-segment-routing-mpls has been
published as RFC 8660
== Outdated reference: A later version (-05) exists of
draft-bashandy-rtgwg-segment-routing-ti-lfa-02
#Ahmed: Upadted both references as well as other outdated references
* There are links to references in the document are broken/not
working, please go through and fix them.
#Ahmed: I do not create any links :). I just uploaded the text file
using the submission tool. So it is the tool that has the problem:)
*
* Other idnits warnings:
== The copyright year in the IETF Trust and authors Copyright Line
does not
match the current year
== The document seems to contain a disclaimer for pre-RFC5378 work,
but was
first submitted on or after 10 November 2008. The disclaimer is
usually
necessary only for documents that revise or obsolete older RFCs,
and that
take significant amounts of text from those RFCs. If you can
contact all
authors of the source material and they are willing to grant the
BCP78
rights to the IETF Trust, you can and should remove the disclaimer.
Otherwise, the disclaimer is needed and you can ignore this comment.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
#Ahmed: Removed that paragraph
* Section 2.1.2: some clarification needed here. When the primary
next-hop fails, my understanding is that BGP PIC will first use
other primary next-hops if available, e.g ECMP before using the
pre-computed backup paths. Also “The existence of a secondary
next-hop is clear for the following reason:”, this needs some
explanations, and this is different from for example pre-computed
backup paths using IP FRR.
#Ahmed:
Your understanding that an implementation would divide the list of
next-hops into "primary" and "secondary" and would start to use
"secondary" next-hops only after all "primary" next-hops become
unreachable is most likely correct.
However I would rather leave the decision to whether divide next-hops
into "primary" and "secondary" or just treat all of them as "primary" to
implementations, rather than recommending such behavior.
The original BGP spec allows only for a single next-hop. The term
"secondary next-hops" is explained in the 3rd paragraph of the same
section where it refers to add-path [10] and best external [5],..., etc.
So from the original BGP protocol point of view, there is only one path.
Basically the term "primary" and "secondary" in this section is
referring to BGP, not to how an implementation chooses which paths are
used when one of them becomes unreachable.
*
* Section 7 title is “Properties”, and it seems to me this section
is more like a summary. I’d suggest combining section 7 and 10,
then change the title to summary or something. No strong opinion
on this one though.
#Ahmed: Section 7 details the properties of BGP-PIC behavior while
Section 10 is just a summary. I can remove section 10 if it seems redundant
*
* Throughout the document, lots of paragraphs are missing the ending “.”
#Ahmed: Corrected
*
Nits:
* The following are editorial nits, please consider fixing them. I’m
using the line number from idnits.
136 techniques, multiple techniques have been proposed to allow for
137 BGP to advertise more than one path for a given prefix
I’m not sure it should be “allow” or “allow for”.
#Ahmed: Corrected
169 o Ingress PE, "iPE": A BGP speaker that learns about a prefix
170 through a IBGP peer and chooses an egress PE as the
next-hop for
171 the prefix.
Should be “an iBGP peer”. Also this definition is not clear to me. I’d
also suggestion add one for “ePE”.
#Ahmed: Corrected
239 o A shared hierarchical forwarding Chain: It is not
uncommon to see
Should be “chain”.
#Ahmed: Corrected
270 This section describes the required functionality in the
forwarding
271 and control planes to support BGP-PIC described in this
document
“functionalities”, also missing ending “.”.
#Ahmed: Corrected
334 VPN-IP2, respectively. Suppose that BGP-NH1 and BGP-NH2 are
resolved
335 via the IGP prefixes IGP-IP1 and IGP-P2, where each happen
to have 2
336 ECMP paths with IGP-NH1 and IGP-NH2 reachable via the
interfaces I1
337 and I2, respectively. Suppose that local labels (whether
LDP [4] or
338 segment routing [13]) on the downstream LSRs for IGP-IP1
are IGP-L11
339 and IGP-L12 while for IGP-P2 are IGP-L21 and IGP-L22. As
such, the
340 routing table at iPE is as follows:
I think you meant “IGP-IP2”, instead of “IGP-P2”.
#Ahmed: corrected (Thanks for catching this one)
Thanks,
Yingzhen
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
