Bill,
>> Start by reading http://bill.herrin.us/network/trrp.html.
>> Don't just scan it. Read it. It's six pages long; it won't
>> kill you.
Thanks for the hint. You are right, it is a short
document, and I'm still alive (by most accounts :-)).
That said, I just want to deal with the architectural
issue that I'm interested here: locator liveness. I have
a bunch of other questions, but I just stuck them at the
end of this message because they don't directly deal with
this particular issue.
In any event, you say:
"The ITR finds an Egress Tunnel Router (ETR) for the
destination IP address via a DNS lookup."
and later
"The ITR should look up the route entry when it first
sees a packet for the destination. If possible, it
should hold packets for the destination in a buffer
until a route is found. "
(For this discussion, I'm ignoring issues around
buffering packets while waiting for a mapping, what
scalability constraints are put on the DNS, the effects
of having the mapping data be opqaue to the mapping
system, configuration of p2mp GRE tunnels, ...; see below
for questions around these things).
So what you describe is the well-known, standard
map-and-encap behavior. A packet hits the ITR, the ITR
looks up the mapping (existing mapping, DNS, APT, ALT,
static, or whatever), encaps the packet, sends it to the
destination ETR. Now, at this point if you have to asses
reachability somehow, or you can create a persistent
failure by latching on the wrong "route" (or "routes"; a
route here is analogous to what folks are calling RLOCs
in other contexts).
Of course, the host can always back off to another EID,
but if the ITR thinks a "route" (RLOC) that is associated
with that EID (however that happens) is reachable when it
isn't and continues to encapsulate packets to that
"route", then you have a persistant failure.
The upshot is that TRRP has the same locator liveness
problem I've been describing. I'm not at all surprised by
this, as I am under the impression that this is a general
property of the Loc/ID split architecture, and not any
particular proposal.
Dave
----
A few comments on your document (and thanks for pushing
on me to read it).
- In "General statement of the solution:"
" An AS-interior default route leads from the BGP
routers to the ITR."
Is this saying that there is a default in the
site's iBGP or IGP that tells it how to get to the
exit points for the site? If so, is this just an
implementation detail or a requirement?
"The ITR finds an Egress Tunnel Router (ETR) for the
destination IP address via a DNS lookup."
What destination address? The destination address in
the packet emitted by the host? So I saw this:
"The ITR should look up the route entry when it
first sees a packet for the destination. If
possible, it should hold packets for the destination
in a buffer until a route is found. "
So this is standard map-and-encap behavior (mod
holding the packet). I see that you inverse address
query for a TXT record associated with the IP address
in the destination address in the packet that
the host emitted (this TXT record encodes information
about the RLOCs of the ETRs, if you will). Yes?
So at this point if you have to asses reachability
somehow, or you can create a persistent failure by
latching on the wrong "route" (or "routes"). The host
has no visibility into this, so whatever it does is
more or less irrelevant. Now, in theory you could
snoop data traffic (note GSE can't do this), so you
might be able to determine liveness w/o probing, at
least for symmetrical (TCP) flows.
The upshot is that TRRP has the same locator liveness
problem I've been describing. I'm not at all surprised
by this, as I'm under the impression that this is a
general property of the Loc/ID split architecture, and
not any particular proposal (BTW, it'd be great if
someone could show otherwise).
- "The ITR then tunnels the packet via GRE to the "best"
ETR."
So the ITR got a set of ETR addresses from the
DNS (TXT records) in the previous step, each of which
is a candidate site for where it might send the
(encapsulated?) packet. Correct?
In addition, the ITR gets this list when it inverse
address queries for whatever was in the destination
of the packet that the host emitted (this is how I
understand your use of the DNS). It encapsulates this
packet over GRE to the destination found in the TXT
record (with some processing of the options in the
TXT record). Correct?
If so, how does the ITR know which ETRs its going to
talk to (in order to set up the GRE tunnels)? Or does
the ITR not set up s GRE tunnel between the ITR and
ETR? Or did you mean some kind of dynamic GRE (i.e.,
just uses GRE encap, or ?).
I see from this example that its the ETR that sets up
a p2mp tunnel:
Cisco IOS configuration example:
interface Tunnel0
description TRRP Egress Tunnel Router
no ip address
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 1
makes it seem lile the ETR will need to know where all
the other ITRs that might want to talk to it are. How
does that work?
- "The ETR, which must have an IP address within space
announced via BGP, knows a local-scope route to the
destination IP address and delivers the packet. "
That makes sense. The IGP (or possibly iBGP) knows how
to how to route packets within the domain (that's the
point of the IGP, AFAIK). Anyway, that makes sense.
- "Longer route prefixes are then withdrawn from BGP
until a comfortable BGP table size is attained."
I couldn't get that to follow from what you said, or
how it works.
- Other notes:
(i). dig couldn't find a nameserver for either
v4.trrp.arpa or v6.trrp.arpa, or
v4.trrp.in-addr.arpa or v6.trrp.in-addr.arpa
(ii). The term "route" is somehow overloaded in your
document. In particular, when you're talking
about the TXT record encoding, you overview the
encoding as 'pp,ii,route pp,ii,route ..." and in
the encoding you have stuff like
00 = always prefer this route
40 = prefer this route
80 = normal
b0 = avoid this route
ff = use this route only as a last resort
These are really the decapsulation point for the
source packet that's about to be encapped. Its
not really a route (or doesn't seem to be to me);
you really don't care what path the packet takes
(within reason), you just care that the packet
can tet to the "route" to be decapsulated. Yes?
(iii). Host unreachables
You say that the ETR needs to unreachables do to
the insecurity of ICMP. You suggest sending ICMP
echo-request. This is another form of searching
(with data probes) for locator liveness. In
addition, if the destination is unreachable, you
take it down for 5 minutes (mod you see traffic
for it). That's a failure mode we don't have in
the internet today; if the host is unreachable
due to, say, a routing anomaly, it becomes
reachable when routing converges. You're scheme
doesn't. Note here that I'm just observing the
properties of the mechanism you propose and
comparing that to what we see today.
(iv). BGP with the "Holey Route Authority"
You say:
A central route authority keeps track of all
holey routes and peers them with all ASes which
implement an ITR. Each such AS implements a
route-map to force those prefixes to head the
same direction as the default route.
All I can say is that hasn't worked to date.
(v). Preemptive Change Notification (PCN)
You say (PCN Type 1):
PCN Type 1: Notification of change by the DNS
server The authoritative DNS Route server
remembers all IP addresses which requested each
Route entry during the entry's TTL. Immediately
upon the Route entry's change, the Route Server
sends a UDP message to port XX of the
requestor. The first byte of the message is
0x01. The remaining bytes are the DNS query
which should immediately expire.
Can you comment on the scaling propeties of this?
I'll stop here.
Anyway, I hope this gets us going a bit.
Thanks,
Dave
signature.asc
Description: Digital signature
_______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
