Hey Ran, > Off the top of my head, it seems to me that this issue already exists > in the deployed IPv4 Internet and also in the deployed IPv6 Internet. > > If one considers a multi-homed end-system (i.e. one that is > directly connected to multiple IP subnetworks), that host needs > to make a decision about which source IP address to use > to communicate. > > If it is communicating with a remote node that is also multi-homed > (same definition), then it needs to make a decision about which > destination IP address to use to communicate (typically this is > a choice from the set of A/AAAA records that the first host found > in the DNS for the remote node).
The difference is has three dimensions: what information
about which source addresses and which destination
addresses are available, the knowledge symmetry of that
information (i.e., what do hosts know and what does
routing known about the which <source,destination> pairs
will be used). and where the decision as to which
<source,destination> pairs to use is made.
In today's world, hosts have pretty much complete
information about which <source,destination> pairs are
available. The decision as to which <source,destination>
pair is to be used is made by host, and again the host
has visibility into the alternatives (or even that there
are alternatives). So it can try them by whatever
algorithm it desires (linear, round-robin, etc). This is
generally O(N) in today's world (where there are N
destination addresses). No new news there.
In the case of host-based schemes like shim6 which
postulate multiple PA addresses per host, you just probe
the entire <src,dest> space mod the utilization of
heuristics like if you've received traffic, etc (i.e., in
a scheme such as REAP). This is generally O(N*M), where
there are N source addresses and M destination
addresses.
In map-and-encap schemes, the host doesn't know how many
"ways" there are to reach a remote ID (i.e., how many
RLOCs there are, or if they are reachable), so it can't
implement a strategy test reachability to the
correspondent (note that even TCP timeout doesn't help
here, unless there the host finds another EID that maps
to a different RLOC set).
Specifically, if the network element that is doing the
mapping chooses a <src,dest> pair that is not reachable
(note that the <src,dest> pair is in the locator space,
into which the host has no visibility), the host will not
have connectivity to the correspondent host, even though
there may be workable alternaltives (i.e., other RLOCs in
the EID-to-RLOC mapping). The mapping entity needs to
asses locator liveness somehow.
In hybrid network-based rewriting schemes (e.g., GSE),
the host doesn't know what source is being used, so while
it knows the destination ingress points (those are in the
DNS), it doesn't what source is being used to attempt to
reach the correspondent host. So it also can't implement
a strategy to search the space of available <src,dest>
pairs for a workable pair.
I mentioned in the private email, another way to look at
this is that the host can't explore the <src,dest> space
for reachibility because it doesn't know what the its
(src) RGs look like (or how many there are). The point
here is that there may be a source RG selected (by
routing) which *does not* work with the dest D-RG||D-EID
(concatenation of the dest RG and dest ID, what's in the
DNS) selected by the host, but the host can't tell why
(or test whether its D-RG||D-EID works, since, again, it
doesn't know what source RG is being selected).
> Few multi-homed hosts participate in intra-domain routing.
> Fewer participate in inter-domain routing. So nearly all hosts
> wanting to correspond cannot use knowledge from the routing
> system to make a better informed decision about either the
> source address to use or the destination address to use.
Right.
> To the extent that folks agree with the above, it would be helpful
> to add discussion of this as a current issue in the Meyer & Lewis
> draft.
Be glad to, to the extent that I agree.
>
> To the extent that folks disagree with the above, then it would
> be helpful if the Meyer & Lewis draft explained why folks believe
> the existing deployed Internet does not have the same issue,
> and at least describe why the scenario outlined above doesn't.
See above. Most of that text is already in the
draft. What could be added is how hosts work today
(without any loc/id split technology). Is that what you
are looking for? That seems a good idea if so.
Dave
signature.asc
Description: Digital signature
_______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
