Early Review of draft-ietf-idr-add-paths-guidelines-07
review-ietf-idr-add-paths-guidelines-07-rtgdir-early-bryant-2015-05-20-00
| Request | Review of | draft-ietf-idr-add-paths-guidelines |
|---|---|---|
| Requested revision | No specific revision (document currently at 08) | |
| Type | Early Review | |
| Team | Routing Area Directorate (rtgdir) | |
| Deadline | 2015-05-20 | |
| Requested | 2015-05-06 | |
| Authors | Jim Uttaro , Pierre Francois , Keyur Patel , Jeffrey Haas , Adam Simpson , Roberto Fragassi | |
| Draft last updated | 2015-05-20 | |
| Completed reviews |
Rtgdir Early review of -07
by
Stewart Bryant
(diff)
|
|
| Assignment | Reviewer | Stewart Bryant |
| State | Completed | |
| Review |
review-ietf-idr-add-paths-guidelines-07-rtgdir-early-bryant-2015-05-20
|
|
| Reviewed revision | 07 (document currently at 08) | |
| Result | Not Ready | |
| Completed | 2015-05-20 |
review-ietf-idr-add-paths-guidelines-07-rtgdir-early-bryant-2015-05-20-00
Hello,
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
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
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-idr-add-paths-guidelines-07.txt
Reviewer: Stewart Bryant
Review Date: 20 May 2015
IETF LC End Date: Not yet in IETF LC
Intended Status: Standards Track
Summary:
I have significant concerns about this document and recommend
that the
Routing ADs discuss these issues further with the authors.
(Actually I see that this document has not yet been passed to the
ADs,
so I suggest that the chairs address these issues with the
authors)
I provide comments inline - Please look for SB>
IDR Working
Group J. Uttaro
Internet-Draft
AT&T
Intended status: Standards Track
Expires: Jun 3, 2015
P. Francois
IMDEA Networks
K. Patel
Cisco Systems
P. Mohapatra
Cumulus Networks
J. Haas
Juniper Networks
A. Simpson
R. Fragassi
Alcatel-Lucent
SB> This document has seven authors against a guideline
of five.
SB> I assume that the chairs and ADs are happy with
this.
Dec 3, 2014
Best Practices for Advertisement of Multiple Paths
in IBGP
draft-ietf-idr-add-paths-guidelines-07.txt
SB> I wonder if this document is correct as ST rather
than BCP? Certainly the
SB> the title and abstract imply a better match with
BCP.
SB> There are 9 nits warnings, of which the following
should be
SB> addressed:
================
Checking nits according to
http://www.ietf.org/id-info/checklist
:
----------------------------------------------------------------------------
== There are 5 instances of lines with
non-RFC5735-compliant IPv4 addresses
in the document. If these are example addresses, they
should be changed.
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 611 has weird spacing: '...ltipath selec...'
Checking references for intended status: Proposed
Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using
normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'RFC 4271' is mentioned on line
153, but not defined
== Missing Reference: 'RFC-2119' is mentioned on line
175, but not defined
== Missing Reference: 'RFC4364' is mentioned on line 808,
but not defined
== Unused Reference: 'RFC2119' is defined on line 912,
but no explicit
reference was found in the text
== Unused Reference: 'RFC4271' is defined on line 939,
but no explicit
reference was found in the text
== Outdated reference: A later version (-10) exists of
draft-ietf-idr-add-paths-07
===============
======== =====================
= +---+ +---+ +---+
= |RTR|________|RTR| |RTR|
= | E | | A | | C |
= +---+Path A->+---+ AS1 +---+
= = = \ / =
= = = \ / =
= = = \ / =
= = = \ / =
= AS3 = = +---+ =
= = = |RR | =
= = = | 1 | =
= = = +---+ =
= = = / \ =
= = = / \ =
= = = / \ =
= = = / \ =
= +---+Path B->+---+ +---+
= |RTR| ______|RTR| |RTR|
= | F | | B | | D |
= +---+ +---+ +---+
======== =====================
Figure 1: Example Topology
SB> Surely the advertisments go L to R, but the paths
SB> actually go R to L?
Under these circumstances consider the steps required to
restore
traffic from router D to destination XYZ when the link
between Router
SB> For clarification " destination XYZ reachable via
AS3"
A and Router E fails. (Assume that router A set next-hop
to self when
advertising path A and that router B is not configured
for best-
external).
SB> is "best-external" the formal name for this
configuration. If not
SB> I recommend that you use the formal name.
1. Router A sends a BGP UPDATE message Withdrawing its
advertisement
of path (A).
SB> Presumable "Router A sends a BGP UPDATE message to
RR1 withdrawing..."
============
5. Router D reruns its decisions process, determines
path (B) to be
the best path, and updates its forwarding table.
After this step
traffic from router D to destination XYZ is restored
(the traffic
path has changed from A to B).
SB> Surely " path has changed from path A to path B"
==========
1. Router A sends a BGP UPDATE message withdrawing its
advertisement
of path (A).
SB> Presumable "Router A sends a BGP UPDATE message to
RR1 withdrawing..."
2. RR1 receives the withdrawal, and propagates it to its
other client
peers, routers B, C and D.
3. Router D receives the withdrawal, reruns the decision
process and
updates the forwarding entry for destination XYZ.
SB> Wait a minuite here. What about the other other
routers in the
SB> network? Maybe you are considering a BGP-free core,
which is fine
SB> but that has to be noted up front as a constraint,
but so far
SB> as I can see you do not talk about that. In a BGP
free core
SB> what you say holds, but in a regular IP core you may
get loops
SB> until the on path routers have been converged. This
really needs some
SB> text.
SB>
SB> You talk about this later in the text, but you
really need to
SB> at least summarise your important assumptions
earlier in the text.
3.2. Load Balancing
Increased path diversity allows routers to install
several paths in
their forwarding tables in order to load balance traffic
across those
paths.
SB> Again the matter of BGP free core needs some
discussion.
SB> In the case of non-BGP-free core it's not quite that
simple.
3.3. Churn Reduction
When Add-Paths is used in an AS, the availability of
additional
backup paths means failures can be recovered locally
with much less
path exploration in iBGP and therefore less updates
disseminate in
eBGP. When the preferred backup path is the
post-convergence path,
churn is minimized.
SB> The text containing "therefore less updates
disseminate" does
SB> not scan correctly.
SB> BTW When the preferred backup path is the
post-convergence path
SB> you don't get loops.
==============
SB> You might consider some RFC2119 language in the
following para:
A BGP UPDATE message from an Add-Paths peer may
advertise and
withdraw more than one NLRI belonging to one or more
address
families. In this case Add-Paths may be supported for
some of the
address families and not others. In this situation the
receiving BGP
router should not expect that all of the path
identifiers in the
UPDATE message will be the same.
===============
Control Plane Stress: Coping with multiple iBGP paths
has two
implications on the computation that a router has to
handle. First,
it has to compute the paths to send to its peers, i.e.
more than the
best path. Second, it also has to handle the potential
churn related
to the exchange of those multiple paths.
SB> Is there any SIDR and BGPsec related compute stress
that needs
SB> to be called out?
===============
5.2. Scalability Considerations
In terms of scalability, we note that advertising
multiple paths per
prefix requires more memory and state than the current
behavior of
advertising the best path only. A BGP speaker that does
not implement
Add-Paths maintains send state information in its prefix
data
structure per neighbor as a way to determine that the
prefix has been
advertised to the neighbor. With Add-Paths, this
information has to
be replicated on a per path basis that needs to be
advertised.
Mathematically, if "send state" size per prefix is 's'
bytes, number
of neighbors is 'n', and number of paths being
advertised is 'p',
then the current memory requirement for BGP "send state"
= n * s
bytes; with Add-Paths, it becomes n * s * p bytes.
SB> The following are personal preferences which can be
ingrored if
SB> you wish.
SB>
SB> If these are the IDR standard terms (n, s, p) then
fine. However I
SB> was initially confused by the change of meaning and
case of n.
SB> Elsewhere we use k for number of neighbours. An
equation
SB> K * s * N might be less confusing. A bit of a nit
it's
SB> handy if the order of definitions and order of terms
in
SB> the equation is the same.
==============
5.4. Consistency between Advertised Paths and Forwarding
Paths
When using Add-Paths, routers may advertise paths that
they have not
selected as best, and that they are thus not using for
traffic
forwarding. This is generally not an issue if
encapsulation is used
in the AS as described in [RFC4364] and all forwarding
decisions,
including by the tunnel egress router, are based on
label information
- i.e. if only the ingress router performs an IP FIB
lookup. In this
situation the dataplane path followed by the packets is
the one
intended by the ingress router, and corresponds to the
control plane
path it selected.
SB> I was looking for discussion on this earlier in the
text
SB> as I was confused about forwarding consistency
there.
===============
=====================
6. Security Considerations
TBD
SB> This is a showstopper! It is not possible to advance
a document
SB> without a security section.
=====================
9. IANA Considerations
TBD
SB> This is also a showstopper! If there are no IANA
considerations
SB> this needs to be noted.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs
to Indicate
Requirement Levels", BCP 14, RFC 2119,
March 1997.
10.2. Informative References
[Add-Paths] Walton, D., Retana, A., Chen E.,
Scudder J.,
"Advertisement of Multiple Paths in
BGP", draft-
ietf-idr-add-paths-07, June 17, 2012.
SB> I cannot see how this can possibly be informative
since it is
SB> fundamental to the advice.
SB> I have not checked all of refs for
Normative/Informative status
SB> but they do need to be checked.
=============
[RFC4271] Rekhter, Y., Li, T., Hares, S., "A
Border Gateway
Protocol 4 (BGP-4), January 2006.
SB> Nit - Trailing quote (") missing.
============
A.3. Advertise Paths at decisive step -1
SB> This really needs a reference. What is decisive step
minus 1?
==============