Hi,
I'm very sorry, but I am pretty sure that I don't
fully grasp what folks are trying to say in this thread.
While I am trying to respond to several notes in this
one note, it is possible that I am not correctly
understanding someone else's words, in which case
my reply might not make much sense.
I apologise, but the multiple quoting within the thread
also has me confused, so I won't try to name authors
for the various snippets below.
> But if ILNP wants some destiantiosn to be reached
> using exit 1, and some reached using exit 2, most sites
> simply do not have any practical way to do that.
&
> And if you want the hosts to decide for itself
> whether it shoudl use exit 1 or exit 2 to reach
> rloc 1, rloc2, or rloc 3, then site TE can not
> solve the problem.
I'm not 100% certain I understand the above.
If I do understand it, then I agree,
but there are practical things that can be done.
Example:
Origin node indicates preferred egress by
Source Locator selection & then site interior routers
examine the Source IP as a hint as to the preferred
egress, which I talk about more below, and which
someone else [tli ?] already noted was a possible
enhancement to routers).
> Unfortunately, until we are prepared to make a much larger
> set of changes, we do not have the tools to allow a host
> to choose which outbound site connection is used by the
> host's outbound traffic.
I partly agree, and partly disagree.
If we're talking about already deployed IPv6 routers used
to handle ILNPv6 traffic, then I think that is probably
true that the site interior routers don't have any extra
wisdom enabling them to understand the originating
node's preferred egress router. In this case, as the
quote above indicates, ILNP is no worse than existing IP,
which is the central point to grasp.
If, however, we consider those site interior routers
practical to upgrade, there is at least a practical
approach for the situation where the interior originating
node is aware of all upstream prefixes that it may use.
In that special case, the originating node could indicate
a preference by thoughtful selection of the Locator
for itself that was associated with the preferred
egress uplink. In turn, provided the path was available,
the site interior routers could use that Source IP
Address information as part of an algorithm to select
an egress site border router. If the preferred egress
stopped being available or site-wide routing policy
over-rode that node-specific preference, then Locator
rewriting would always be available to the site border
router(s).
One of the advantages of ILNP (and possibly also LISP,
although I'm not certain about the details of LISP)
is that by de-coupling the routing information (i.e. Locator)
from the node identity (i.e. Identifier), it is possible
to enhance routers to make more intelligent decisions,
including decisions based on information beyond the
current (practical, de facto) constraint of (Destination IP,
RIB) data. Router implementers aren't required to add such
capabilities, but the de-coupling makes it practical
to add a range of routing policy features that are
not entirely practical within the deployed Internet
Architecture.
> This also means that the network path betwen host -> border
> has to do some internal TE such that when on exit path is
> [unavailable or contrary to site-wide policy, then] traffic
> naturally flows [...] toward a 'better' exit path.
OSPF, IS-IS, and RIP all commonly carry 'default'
routes for egress when deployed within an end site.
That 'default' routing information can be used
to discover a working (policy-conforming) egress
router.
> I was under the impression that ILNP would permit the
> site border routers to change the locator bits on exit.
Correct, and 'permit' is precisely correct,
as the site border routers are not required
to rewrite the Locator bits.
> This means the network devices and the hosts have
> to agree on the set of locators they all can use.
I don't think that claim is precisely true as written.
The MILCOM 2009 paper discusses a concrete
counter-example in reasonable detail.
In that counter-example, ULAs are within a site. Nodes
having LP records instead of L records. Site border
routers control both (1) the L records that all the LP
records point to and (2) the egress uplink/path.
> This also means that the network path betwen
> host -> border has to do some internal TE such that
> when on exit path is 'bad' traffic naturally flows
> toward an alternate path internally toward a 'better'
> exit path.
Hmm. I don't think so. See my comment above that
talks about the various IGPs.
> If the above all works, then the borders simply
> swap locator bits as appropriate on exit... easy, peasy.
Yes, and at least one deployed packet processing
chip can do this in hardware today, at wire speed,
for an interesting number of 10 Gbps links concurrently.
> In ILNP, a host controls how packets arrive by changing
> the locators that are advertised. Outbound, intra-domain
> packet routing is separate, and COULD be based on the hosts
> source locator, but this is a separate enhancement that
> we could make.
Exactly so.
> Once the host updates DNS with the C locator, it should
> also concurrently send ICMP locator updates to its active
> correspondents and inform them of the C locator.
Yes.
Further, tli has pointed out off-list that I need to edit
the ICMP Locator Update I-D to permit that message to
also indicate relative preference among the set of
valid Locator values. This is already handled in the
ILNP DNS I-D, but was not handled in the other I-D
due to my error. I will be making that edit whenever
I can find the time to spin all the ILNP I-Ds.
(I really hope I haven't muddied the waters hopelessly
with the above.)
Yours,
Ran
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
