[Idr] AD Review of draft-ietf-idr-bgp-bestpath-selection-criteria-12

[Alvaro Retana <[e-mail]>]

Rajiv:

Hi!  How are you?  I just finished reading this document.

First of all, thank you for your patience and perseverance in sticking with
this document for so long!

Having said that, I have significant issues with the document.  I have
specific in-line comments below, but I want to highlight some of the bigger
issues now -- please note that while you are the Author, the issues called
out here are directed at the WG/Chairs/Shepherd as well.

(1) What is the Update to rfc4271?

The document presents two amendments to the Route Resolvability Condition (§
9.1.2.1/rfc4271).  The first one is straight forward and obvious: resolve
the next-hop using the correct Routing Table.

The second one is to check the "path availability" to the next-hop.  While
a good thing to do, and optional, it introduces in the BGP Decision Process
unspecified functionality that depends on external mechanisms...which, in
my opinion, should be used to maintain the Routing Table and not be
specifically a part of BGP.

Both the policy to drive Amendment 1 and the expectations of the check in
Amendment 2 are not specified and declared out of scope.  IOW, the
specification is to do something that is not specified.  Back to my
question: what is the Update to rfc4271?

I didn't find a discussion on the list about the Update: either about
formally Updating rfc4271, *or* what the Update would be.  I did find a
note [1] that says "our AD requested we move the document from
Informational to Standards track, and add 'Updates: RFC 4271'"...but there
was no discussion; in fact, no reply at all.

[Disclaimer: I was not the AD in 2011.]

Related to this point, and specifically to the "path availability"
functionality...  In the Implementation Report [2], one of the implementers
reports support for "path availability check in several variations, but not
all. For example, BFD may be used to protect MPLS generated nexthops for
LDP and RSVP. For IP nexthops distributed via an IGP, the IGP may be
protected using BFD."  Because the "path availability" functionality is not
specified in this document, then I'm not sure whether either of these
satisfies this document...but both mechanisms described are about
protecting the next-hops (and presumably triggering FRR, for example), and
not specifically about providing BGP with an indication of availability to
forward traffic (which is my interpretation of "path availability").

To be clear:  I mention this text from the Implementation Report not to
criticize the implementation...but to support the points that (1) the
specification in this document is incomplete, and (2) that the OAM
mechanisms should be used to maintain the Routing Table (and not just
interact directly with BGP).  IOW, I believe that the implementation is
doing the right thing...but that is not what is described in the document.

[See more related comments in §3, after Amendment 2.]


(2) WG Discussion (...or lack of...)

As I mentioned above, there was no discussion of the Update in the WG.  In
fact, the only significant discussion was during adoption [3] -- at that
point the draft was Informational and it didn't Update anything.

The WGLCs [4][5] show only 1 comment, and no other explicit show of
support.  Not even the usual "support...+1...+1...".

I went back and looked at the minutes from IETF 73 [6], which is where the
draft was presented for the first time, but there was no feedback there.

draft-asati-bgp-mpls-blackhole-avoidance, which was presented at IETF 68,
was the precursor of this document.  The minutes from that meeting [7] show
not a lot of excitement and minor support for perhaps an Informational
one-page document saying "please be careful about selecting a next hop".

One last note on this point.  The Shepherd's writeup [8] reads:

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

   Solid in 2009.  As time goes on waiting for implementation reports,
   the memory of those days weakens.  However, since 2 major vendors
   have implemented and deployed this RFC - the solid WG
   support from 2009 has been validated.

The draft was adopted with rough consensus [3], so I don't interpret
implementations in this case as strong validation mainly because I don't
see a clear specification.

All this leads me to ask: Is this work (many years later!) still something
the WG wants to progress?  Or has it been taken over by events?  Is the
document in it's current form what the WG thought it was adopting?

I am looking for discussion and specific opinions (not +1s!).  I would be
very happy if someone pointed me to discussions I missed in my search.


(3) Terminology

In general, I think that most idr participants would clearly understand the
terminology used in this document.  However, the audience is wider than
that, and the terminology used doesn't correspond to that in other work.

For example, the first sentence in the Abstract reads:

   BGP specification (RFC4271) prescribes 'BGP next-hop reachability'
   as one of the key 'Route Resolvability Condition' that must be
   satisfied before the BGP bestpath candidate selection.

rfc4271 doesn't talk anywhere about reachability or a bestpath.

Please be consistent with the terminology in other RFCs, specially
rfc4271.  Introducing new terms is fine, if they are needed and properly
explained.


Given the points above, I am inclined to return this document to the WG for
further discussion.  I really don't want to do that given its long history,
so perhaps we can use some time next week in Montreal to talk face-to-face.

Thanks!

Alvaro.


[1] https://mailarchive.ietf.org/arch/msg/idr/jWNhfTvHbaY3rEk5nTYahS5w6_Q
[2]
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-bestpath-selection-criteria
[3] https://mailarchive.ietf.org/arch/msg/idr/Yr9u6V2HKrHEuQLtFw7aDstMPzg
[4] https://mailarchive.ietf.org/arch/msg/idr/kiTwL6ApC_k9QFrfhaMA_qC8BcA
[5] https://mailarchive.ietf.org/arch/msg/idr/OqsCexPPmtvKjHNJzf4EcpwPhtQ
[6] https://mailarchive.ietf.org/arch/msg/idr/OVg6Cfr3EUwIRcQS6cIkwq_dUtI
[7] https://mailarchive.ietf.org/arch/msg/idr/lezFHSGaOzvL2h16M883beeHcjI
[8]
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-bestpath-selection-criteria/shepherdwriteup/




[Line numbers from idnits.]

...
11 Abstract

13   BGP specification (RFC4271) prescribes 'BGP next-hop reachability'
14   as one of the key 'Route Resolvability Condition' that must be
15   satisfied before the BGP bestpath candidate selection. This
16   condition, however, may not be sufficient (as explained in the
17   Appendix section) and would desire further granularity.

[major nit] rfc4271 doesn't talk about "BGP next-hop reachability".
 §9.1.2.1.  (Route Resolvability Condition) does talk about whether the
NEXT_HOP is resolvable.

Also, the term bestpath is not in rfc4271 -- it used "best route" a couple
of times.

Please be consistent with the text in rfc4271 and use the right terminology.

[nit] s/as one of the key 'Route Resolvability Condition'/as a key 'Route
Resolvability Condition'

[nit] s/would desire further granularity/requires (??) further granularity

19   This document defines enhances the "Route Resolvability Condition"
20   to facilitate the next-hop to be resolved in the chosen data plane.

[nit] s/enhances/enhancements

[major] Please specifically mention (in the Abstract and the Introduction)
what the Update to rfc4271 is.  For example: "This document Updates rfc4271
by..."


...
67 1. Introduction

69   As per BGP specification [RFC4271], when a router receives a BGP
70   path, BGP must qualify it as the valid candidate prior to the BGP
71   bestpath selection using the 'Route Resolvability Condition'
72   (section#9.1.2.1 of RFC4271]. After the path gets qualified as the
73   bestpath candidate, it becomes eligible to be the bestpath, and may
74   get advertised out to the neigbhor(s), if it became the bestpath.

[nit] s/As per BGP specification/As per the BGP specification

[nit] s/BGP must qualify/it must qualify    it = the router/BGP speaker

[nit] s/the bestpath candidate/a bestpath candidate

[minor] "receives a BGP path"   I know what you mean, but rfc4271 talks
about when the "BGP speaker receives, from a peer, an UPDATE message that
advertises a new route, a replacement route, or withdrawn routes"...not a
path.

76   However, in BGP networks that utilize data plane protocol other than
77   IP, such as MPLS [RFC3031] etc. to forward the received traffic
78   towards the next-hop, the above qualification condition may not be
79   sufficient. In fact, this may expose the BGP networks to experience
80   traffic blackholing i.e. traffic loss, due to malfunctioning of the
81   chosen data plane protocol to the next-hop. This is explained
82   further in the Appendix section.

[major] "in BGP networks that utilize data plane protocol other than
IP...the above qualification condition may not be sufficient"  What is the
scope of this document?  Do the amendments apply to only encapsulated
traffic, non IP forwarded traffic, any type of traffic?  I am a little
confused because of statements like this one where it seems to point at non
IP traffic...  But there are no specific indications in the description of
the amendments (§3) that they would only apply to those cases.  Please
clarify.

[nit] s/utilize data plane protocol/utilize a data plane protocol

[minor] s/MPLS [RFC3031] etc./MPLS [RFC3031],

84   This document defines further granularity to the "Route
85   Resolvability Condition" by (a) resolving the BGP next-hop
86   reachability in the forwarding database of a particular data plane
87   protocol, and (b) optionally including the BGP next-hop "path
88   availability" check.

[major] Making (b) optional doesn't address the case where the route
exists, but the path isn't functional (which is the first example mentioned
in the Appendix).

90   The goal is to enable BGP to select the bestpaths based on whether
91   or not the corresponding nexthop can be resolved in the valid data
92   plane.

[minor] s/based on whether or not/based on whether


94 2. Specification Language

96   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
97   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
98   document are to be interpreted as described in [RFC2119].

[major] Use the template from rfc8174.

100 3. Route Resolvability Condition - Modification

[minor] Please make it clear that this is where the Update to rfc4271 is.
Peharps s/Modification/Update to rfc4271

102   This document proposes two amendments to 'Route Resolvability
103   Condition', which is defined in RFC4271, in consideration for a
104   particular data plane protocol:

[nit] s/This document proposes/This document specifies

[nit] s/amendments to 'Route Resolvability Condition'/amendments to the
'Route Resolvability Condition'

[major] §9.1.2.1/rfc4271 defines the route resolvability condition.
Presumably, the two amendments enhance that definition, right?  Please be
specific as to where the amendments apply -- for example, I am assuming
that the first amendment applies to the first part of the route
resolvability condition...

106   1) The next-hop reachability (check) SHOULD be resolved in a
107      forwarding database of a particular data plane protocol.

[major] rfc4271 doesn't talk about "next-hop reachability"...please be
specific.

[minor] "(check)"  Maybe it's just me, but I don't understand why "check"
is in parenthesis...or there at all.

[major] When would the resolution not be done "in a forwarding database of
a particular data plane protocol"?  IOW, why not use MUST?

[major] "a forwarding database"  The wording (using "a") implies that more
than one database may exist.  How is it selected?

109         For example, if a BGP IPv4/v6 or VPNv4/v6 path wants to use
110         MPLS data plane to the next-hop, as determined by the policy,
111         then the BGP 'next-hop reachability' should be resolved using
112         the MPLS forwarding database. In another example, if BGP path
113         wants to use the IP data plane to the next-hop, as determined
114         by the policy, then BGP 'next-hop reachability' should be
115         resolved using the IP forwarding database. The latter example
116         relates to MPLS-in-IP encapsulation techniques such as
117         [RFC4817], [RFC4023] etc.

[nit] Is the indentation necessary?

[nit] s/IPv4/v6/IPv4/IPv6

[minor] Explain what a VPNv4/v6 path (route!) is.

[minor] "path wants"   The paths don't "want" anything -- please reword.

[minor] Maybe put the example after the rest of the specification.

119   The selection of particular data plane is a matter of a policy, and
120   is outside the scope of this document. It is envisioned that the
121   policy would exist for either per-neighbor or per-SAFI or both. A
122   dynamic signaling such as BGP encapsulation SAFI (or tunnel encap
123   attribute) [RFC5512] may be used to convey the data plane protocol
124   chosen by the policy.

[major] I understand how the specification of the policy may be out of
scope.  However, because we're dealing with a Standards track document, I
need you to be more specific as to what the policy may look like...and then
give examples if you like.

[minor] The description is not clear...for instance...  The example (in the
previous paragraph) talked about a BGP route using the IP FIB, which sounds
pretty straight forward to me.  However, then it says that it "relates to
MPLS-in-IP".  Does it not also relate to simple IP packets (not
encapsulated)?

[nit] s/is a matter of a policy/is a matter of policy

126   This check is about confirming the availability of the valid
127   forwarding entry for the next-hop in the forwarding database of the
128   chosen data plane protocol.

130   2) The 'path availability' check for the BGP next-hop MAY be
131      performed. This criterion checks for the functional data plane
132      path to the next-hop in a particular data plane protocol.

[major] What is the "'path availability' check"?  What does a "functional
data plane path" mean?  It is suggested below that "any of the OAM
data-plane liveness mechanisms associated with the data plane" can be
used...but the indication of these mechanisms is liveliness of the path,
and not necessarily the ability to deliver the specific traffic to be
forwarded...which is what I would have guessed a "functional path" to be.

[major] By Updating rfc4271, this specification is adding the 'path
availability' check to the functions that all (!) BGP speakers have to
perform (even if optionally).  Are we (WG) sure that we want to add this
new function to the base BGP spec?  IOW, should the formal Update of
rfc4271 include both steps?

I didn't find a discussion on the list about the Update: either about
formally Updating rfc4271, *or* what the Update should be.  I did find a
note [1] that says "our AD requested we move the document from
Informational to Standards track, and add 'Updates: RFC 4271'"...but there
was no discussion.

[opinion] Personally, I think that "path availability" is important...but
it should be a function of the routing table (which would render the
next-hop unresolvable if not available)...and not part of the routing
protocol.

134   The path availability check may be performed by any of the OAM data-
135   plane liveness mechanisms associated with the data plane that is
136   used to reach the Next Hop. The data plane protocol for this
137   criterion MUST be the same as the one selected by the previous
138   criterion (#1).

[major] I think you're missing the requirement that the forwarding database
(if more than one exists for the data plane) has to be the same.

[major] Some of the existing OAM mechanisms require setting up the remote
peer as well.  Is the intent for the path availability to be applicable to
not-directly-connected eBGP next-hops?  This question is related to the
ones above about defining what the expected check is.

140   The mechanism(s) to perform the "path availability" check and the
141   selection of particular data plane are a matter of a policy and
142   outside the scope of this document.

[major] I understand that the specific mechanisms are out of scope.
However, related to my question above about what "path availability" is,
this document should explicitly define what is expected from that check.

[minor] path availability, 'path availability' and "path availability" are
used in different places...I assume to mean the same thing...is that true?
Please be consistent.


144         For example, if a BGP VPNv4 path wants to use the MPLS as the
145         data plane protocol to the next-hop, then MPLS path
146         availability to the next-hop should be evaluated i.e. liveness
147         of MPLS LSP to the next-hop should be validated.

[nit] Is the indent necessary?

149   This check is about confirming the availability of functioning path
150   to the next-hop. Note that it is not necessary to trigger the data-
151   plane liveness mechanism for a given next-hop as a consequence of
152   this check, though it may be an option. Another option is to do it a
153   priori. The selection of a particular option is deemed deployment
154   specific and outside the scope of this document.

[minor] What does "trigger the data-plane liveness mechanism" mean?

[minor] "The selection of a particular option is deemed deployment specific
and outside the scope of this document."  I don't think the selection of
these options is completely outside the scope of this document.  Because
they are mentioned here, I would like to see Deployment Considerations
related to the effect of using them and general guidelines of when they may
be used.

156 4. Conclusions

158   Both amendments discussed in section 2 provide further clarity and
159   granularity to help the BGP speaker to either continue to advertise
160   a BGP path's reachability or withdraw the BGP path's reachability,
161   based on the consideration for the path's next-hop reachability
162   and/or availability in a particular data plane.

[minor] s/section 2/Section 3

[major] This paragraph talks about the ability to "withdraw the BGP path's
reachability, based on the consideration for the path's next-hop
reachability and/or availability in a particular data plane"...but that
action is not reflected in the specification.  It should!

§9.1.2/rfc4271 already says this: "Unresolvable routes SHALL be removed
from the Loc-RIB and the routing table."  Clearly specifying the amendments
as part of the route resolvability condition (as mentioned in my comments
in §3) should take care of the Withdraws.

164   It is not expected that the proposed amendments would negatively
165   impact BGP convergence, barring any implementation specifics.

[major] "It is not expected..."  That text doesn't give anyone warm, fuzz
feelings.  What about the time it takes to check path availability?  I see
that this paragraph was added as a result of a similar question on the list
[9], but no explanation was given then either.

[9] https://mailarchive.ietf.org/arch/msg/idr/okJNyUYoXgGc7tKun_QhUuy9GZ4

167   The intention of this document is to help operators to build BGP
168   networks that can avoid self-blackholing.

[minor] This paragraph seems superfluous...specially because the items that
would in fact help operators are out of scope...

170 5. Security Considerations

172   While this draft doesn't impose any additional security constraints,
173   it can help with mitigating one particular type of routing attack in
174   which a BGP speaker could receive routes with an arbitrary next-hop.
175   If the next-hop is not reachable, then those routes/paths would not
176   get selected.

[major] "If the next-hop is not reachable..."  By not reachable you mean
that the path is not available, right?  I ask because finding a route in a
specific table (criteria 1) is basically what rfc4271 already says (except
for the part about using *a* specific table)...so that amendment doesn't
increase the security.

[major] The correct operation of the amendments depends on pieces that have
not been fully specified (policy and path availability), both of which
carry their own risks/vulnerabilities.  Those need to be described here.


...
193 8. Appendix

[minor] The Appendix should be placed after the References, and it is not
considered a Section (with a separate number) [rfc7322].

195 8.1. Problem Applicability

[nit] Should this Section be called "Problem Description" instead?


...
204   In MPLS or MPLS VPN networks [RFC4364], the same problem is observed
205   if the functional MPLS LSP to the next-hop is not available (due to
206   the forwarding path error on any node along the path to the next-
207   hop).

[minor] s/the forwarding path error/a forwarding path error

You mean an error, not *the* error, right?  Are there examples of this?

209   The following MPLS/VPN topology clarifies the problem -
210        <-eBGP/IGP-> <-------MP-BGP------> <-eBGP/IGP->

[minor] Expand these acronyms on first mention: eBGP, IBGP, MP-BGP, CE,
PE...

212        CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~
213                                                        ^
214                      ======PE1-PE2 LSP==>              ^
215                                                        ^
216                                                    a.b.c.d

[minor] Use rfc5737 addresses in the examples.

218                         Figure 1 MPLS VPN Network

220   In the network illustrated in Figure 1, the PE1 to PE2 LSP may be
221   non-functional due to any reason such as corrupted MPLS Forwarding
222   Table entry, or the missing MPLS Forwarding table entry, or LDP
223   binding defect, or down LDP session between the P routers (with
224   independent label distribution control) etc. In such a situation, it
225   is clear that the CE1->CE2 traffic inserted into the MPLS network by
226   PE1 will get dropped inside the MPLS network.

[minor] Expand/explain "P router".

[minor] I know that all the reasons mentioned for a non-functional path can
happen...or have happened...but some are errors or bugs; shouldn't the
focus be on fixing them??  Are they still an issue?


...
261 8.1.2. Single-Homed VPN Site with Site-to-Site Backup Connectivity
...
268                      <------MP-BGP------>

270        CE1~~~~~~~~~PE1~~~MPLS Network~~~PE2~~~~~~~~CE2~~
271          \                                         /   ^
272           \~~~~~~~~~~~~~~backup path~~~~~~~~~~~~~~/    ^
273                                                        ^
274                                                    a.b.c.d

276           Figure 3 MPLS VPN Network - CE1-CE2 Backup connection

278   Unless PE2 withdraws the route via the routing protocol used on the
279   PE-CE link, CE1 will not be able to activate the backup link
280   (barring any tracking functionality) to the remote VPN site.

[minor] "Unless PE2 withdraws..."  There is no qualification of why PE2
would do that.  I'm guessing that it is because the connection to CE2 went
down (or something like that).  I know this is another example of the same
thing, but please be complete.

BTW, a better example would be for PE1 to withdraw the route in response to
lack of reachability...which seems to be what the summary bellow points to.

282   In summary, if PE1 could appropriately qualify the BGP VPNv4
283   bestpath, then the VPN traffic outage could likely be avoided. Even
284   if the VPN site was not multi-homed, it is desirable to force PE1 to
285   withdraw the path from CE1 to improve the CE-to-CE convergence. This
286   document proposes a mechanism to achieve the optimal BGP behavior at
287   PE.

[nit] s/document proposes/document defines

[nit] s/at PE/at the PE

289 8.1.3. 6PE or 6VPE

291   This problem is very much applicable to the MPLS network that is
292   providing either 6PE [RFC4978] or 6VPE [RFC4659] service to
293   transport IPv6 packets over the MPLS network.

[minor] True, but it sounds like "I forgot to add v6..."  Maybe change one
of the examples to an IPv6 destination.


295 9. References

297 9.1. Normative References
...
302   [RFC4364] Rosen E. and Rekhter Y., "BGP/MPLS IP Virtual Private
303             Networks (VPNs)", RFC4364, February 2006.

[minor] I think this can be an Informative Reference.