Subject: Re: [rrg] ILNP q1: Scalability

From: Toni Stoev <[email-masked]>
Date: Thu, 3 Jun 2010 10:43:41 +0300

On 3 June 2010 at 10:29:42 Lixia Zhang sent:
> 
> On May 27, 2010, at 3:11 AM, Toni Stoev wrote:
> 
> > On Thursday 27 May 2010 at 03:22:25 Dae Young KIM sent:
> > 
> >>  o I'm in fact not a routing expert, even without any field
> >> experience.
> > 
> > Who's a routing expert in this group?
> 
> Toni, there are many routing experts on this list, people who wrote the routing code that forwards your and my email messages.
> 

Regards to those people for writing useful code.

> 
> > And in what routing? The one that lacks scalability?
> > 
> >> I'm just a teacher, so that I have to know clearer to 
> >> teach my students in the right direction.
> > 
> > I am a student in the University of Life.
> > _______________________________________________
> > rrg mailing list
> > [email-masked]
> > http://www.irtf.org/mailman/listinfo/rrg
> 
>

---

From: [email-masked]
Date: Fri, 4 Jun 2010 15:11:27 EDT

In einer eMail vom 04.06.2010 19:31:32 Westeuropäische Sommerzeit schreibt  
[email-masked]:

On 4  June 2010 at 16:41:15 Tony Li sent:
> 
> > But RRG's charter  includes exploration of "addressing" problems.
> > An "address" is  used to determine forwarding operation.
> > So it's natural to  discuss forwarding issues here. Right?
> 
> 
> Ummm...   No, not in the full generality of how some people use that term.
>  
> Again, we were chartered to discuss routing and addressing  architecture.
> Forwarding issues typically involve interesting  questions about how you 
can
> structure your FIB to minimize painful  memory accesses, what type of 
memory
> to use, how it should be  interconnected to your processing element, how 
to
> deal with ECMP,  dealing with indirect next hops and the like.  All of 
those
> are  out of scope.
> Regards,
> Tony

OK, I agree.
Tony, 
however I do disagree. You just  looked at what rtgwg is doing  (ECMP, 
"via"-routes ) and concluded such topics belong to rtgwg, hence not to  RRG, 
hence is out of scope.
 
First:the IAB-report talks a lot about Moore's law.
Second: A routing architecture is more than just solving the scalability  
problem.
Obviously you only look backwards: LISP is (as said by their authors  
themselves) a jackup solution. ILNP revitalizes ideas which exist at least  for 
one decade (right? btw this is not a  disadvantage per se. But it  is  
nothing new under the sun; it is still the wrong way of understanding  hierarchy )
 
A routing architecture is more. It should concurrently serve all the  
important issues:
-scalability (of course)
-mobility, multihoming,TE forward (knowing multipath alternatives) and  
backward (figuring out to choose the right multipath alternative) e.g. for  the 
sake of traffic balancing or the sake of congestion handling.
-multicast ( I don't know what is more disappointing: the IETF multicast  
technology or the fact that multicast is a non-issue in the RRG).
 
By addressing one issue after the other you will get any arbitrary  
solution in the end which is cast by the sequence these issues have been  
addressed. (btw, this is my general observation wrt to all IETF progresses,  too)
 
Heiner
 
Heiner

But  there is one certain point of intersection of addressing, forwarding 
and path  selection:
As clear an address shows a node's topological location, that  much it 
facilitates hop by hop path selection to that node, says: decision  making for 
forwarding, sequentially.

So why not just embed next hops in  an address: locator?
_______________________________________________
rrg  mailing  list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: Toni Stoev <[email-masked]>
Date: Mon, 7 Jun 2010 19:26:36 +0300

On 5 June 2010 at 02:32:03 Tony Li sent:
> 
> > But there is one certain point of intersection of addressing, forwarding and
> > path selection:
> So then the locator is basically a detailed path that has to change anytime
> there's a topology change along the path.

Yes. But having named nodes as hops, the topology change is not just a link change, but change in the sequence of nodes.
This naming is meant to be within a routing domain and from a starting node, so it's actually maintenance of a default path tree.

> Tony

Regards
Toni

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 7 Jun 2010 13:16:49 -0400

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