Hi Joel,
I'm quite embarrassed---I don't see the loop you are referring to. Could
you spell it out for me?
FAIW, here is my analysis (within which I don't see a looping
situation...what am I missing?). I'm happy to clean up this analysis and
include it in the draft if that is what you are asking for.
First, lets consider the static configured VP-list approach (currently
described in draft-ietf-grow-va-00).
There are two misconfig possibilities:
V1: A router thinks a VP exists that doesn't actually (i.e. its VP-list
claims that a VP exists, but there is no router that itself acts as the
APR for that VP).
In this case, the router expects to see a route to the VP. If it does not
see the route, then it either installs the sub-prefixes, in which case
routing works fine, or it does not, in which case it drops the packets.
(Which it does is a policy decision, subject to available FIB space.)
Either way, no loop.
V2: A router does not think a VP exists that actually does. In this
case, the router will FIB-install the sub-prefixes and routing works fine.
Next, lets consider VP-route tagging approach (described in
draft-ietf-grow-va-auto-00).
Here, there is no static configuration of VPs per se. Rather, the only
configuration is that of the APR. When an APR advertises a VP-route,
presumably it is either prepared to forward packets (i.e. it has
FIB-installed the sub-prefix), in which case all is well, or it is has for
some reason not FIB-installed one or more sub-prefixes, in which case it
should drop the packet. (There should never be a case where an APR
forwards a packet to another APR just cause it doesn't have a route to a
specific IP address. This is a router functionality issue, not a
configuration issue.)
Lets consider the non-APRs (for a given prefix). When it receives a
VP-route, the route is tagged, and so the non-APR knows it is a VP. It
will forward packets to the VP (for FIB-suppressed sub-prefixes), at which
point the behavior in the above paragraph applies (the APR either forwards
for drops the packet, but no loops). If there is no VP-route anywhere for
a given VP, the non-APR simply assumes that it is not a VP, and either
installs the sub-prefixes or not, but either way no loop.
If a non-APR is doing graceful restart, then until the RIB converges, it
might have incorrect information, as follows:
GR1: It thinks there is a VP when there isn't.
In this case, it will tunnel packets to what it thinks is the APR for the
VP (say R1). R1 will then tunnel the packet to the correct APR (if there
is one), or drop it (if there isn't). Is there a possible scenario
whereby R1 thinks that some router R2 is the APR, and R2 thinks that some
router R1 is the APR? It is hard to imagine one. Lets imagine, for
instance, that both R1 and R2 are APRs at time T1. At T1, the admin
reconfigures them both to be non-APRs. Then they both at the same time go
into GR. But this shouldn't happen, because when a router is told that it
is no longer an APR, it will first withdraw the VP route, then wait a
while (for the withdraw info to propagate), and only then FIB-suppress the
sub-prefixes. So both R1 and R2 should be able to forward to
sub-prefixes during the GR period, and so no loop should form. (As a
further safety, we could have a rule that says that a router never
forwards a received tunneled packet to an APR, but this seems unnecessary
in practice.)
GR2: It does not know of a VP that exists.
Here, the non-APR should simply drop the packets. No loop.
Finally, lets consider the can-suppress approach specified in
draft-ietf-grow-va-auto-00.
Here the concern is that the configured VP-range table does not match
reality. Again, there are two cases of concern:
CS1: The router thinks that an address range has a VP when there is in
fact none.
Here the router will tag sub-prefix routes as can-suppress. Routers that
see this (which are non-APR routers) will FIB-suppress the sub-prefixes,
and packets will be dropped, not looped.
CS2: The router thinks that an address range has no VP when there is one.
In this case, the sub-prefix routes will not be tagged as can-suppress.
Other routers will FIB-install the sub-prefixes (if there is FIB space),
and packets will be forwarded correctly. If there is not FIB space, then
the packets will correctly be forwarded to the VP.
PF
"Joel M. Halpern" <jmh at joelhalpern.com> wrote on 10/20/2009 05:20:54 PM:
I am glad to see this draft, as I believe this problem is a critical
obstacle in the way of the community giving VA serious consideration.
I believe that there is one class of issue that is alluded to briefly in
the document, but not discussed, which needs attention for credibility.
That is the issue of inconsistent information.
As written, there is no discussion about what happens if during
transitions, routers have different vies of the VP routes and the
suppress prefix sets. It appears that under such circumstances large
collections of traffic may loop. (Double-tunneling would prevent this,
but that is not currently mandated by the base VA draft, for good
reason.) Without some discussion of the problem, there will be a
tendency for readers to conclude that it is a major issue.
As a lesser topic, it seems to me that the inability to install prefixes
if the VP routers are down seems like a serious flaw in the can-suppress
approach. If it is somehow not an issue, then the problems raised in
the VP-route tag discussion would seem to be even less important.
Either way, it seems that VP-route tag is simply cleaner.
Yours,
Joel
Internet-Drafts at ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Global Routing Operations Working
Group of the IETF.
Title : Proposal for Auto-Configuration in Virtual
Aggregation
Author(s) : P. Francis, et al.
Filename : draft-ietf-grow-va-auto-00.txt
Pages : 11
Date : 2009-10-18
Virtual Aggregation as specified in [I-D.ietf-grow-va] requires a
certain amount of configuration, namely virtual prefixes (VP), a VP
list, type of tunnel, and popular prefixes. This draft proposes
optional approaches to auto-configuration of popular prefixes and the
VP list, and discusses the pros and cons of each. If these proposals
are accepted, they will be incorporated into [I-D.ietf-grow-va].
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-grow-va-auto-00.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
------------------------------------------------------------------------
_______________________________________________
GROW mailing list
GROW at ietf.org
https://www.ietf.org/mailman/listinfo/grow