Re: KHALED Routing Protocol (KRP).

[Lee Howard <[e-mail]>]

From:  ietf <[e-mail]> on behalf of Khaled Omar
<[e-mail]>
Date:  Friday, April 28, 2017 at 8:08 AM
To:  ietf <[e-mail]>
Subject:  Fw: KHALED Routing Protocol (KRP).
> 
> Regarding the difference between tables, KRP within each region uses a table
> of only RBRs and RRs, the table is not listing prefixes because KRP uses the
> information stored on every single IP address and the IGP routing table, also,
> the Forwarding table details of one region is not advertised to other regions
> because they don't need to know it, enough to know how to reach the RBR and
> then it can deliver the packet faster and correctly.

Sorry, you¹re carrying full routes for every /32 and every /128 in your IGP?

> 
> 
> KRP will not require renumbering (reallocation) of IP addresses after the
> modification made to the 1st version of the draft that used the 1st two groups
> of IPv6 addresses as the KRP ASN, but the 2nd version used the middle two
> groups, and that will make the usage of KRP easier.

What about IPv4?

> 
> 
> Finally, don't stop on what you think is not applicable, share your thoughts
> to add a solution to make things applicable thats the aim of the discussion,
> because KRP can route packets successfully from the source to the destination
> using the Best best route and with the lowest table entries for faster routing
> decisions.

Define ³Best best.²
Shortest AS hops? Fewest intermediate devices? Cheapest link? Least
saturated link? Hot potato? Lowest packet one-way latency?

I agree with Dave; the 6renum WG published rfc7010 IPv6 Site Renumbering Gap
Analysis and then shut down; filling those gaps would be useful.

Lee

> 
> 
> 
> -------- Original Message --------
> Subject: Re: KHALED Routing Protocol (KRP).
> From: Dave Cridland
> To: Khaled Omar 
> CC: [e-mail]
> 
> 
>> On 26 April 2017 at 00:27, Khaled Omar wrote:
>>> > https://datatracker.ietf.org/doc/draft-omar-krp/
>> 
>> I like this idea, but I think it's sufficiently similar to the
>> original aim of EGP/BGP that it's already been proven impractical, and
>> moving to it would also be impractical. I am not a routing expert, so
>> I'll cheerfully wait being shot down by others, but this is my
>> rationale:
>> 
>> The reason why we have large routing tables within BGP routers is
>> mostly that ASNs now consist of many more prefixes than were
>> originally expected, and so the prefixes do not aggregate well enough.
>> 
>> This proposal involves, essentially, renumbering the entire internet
>> (which is very difficult in practical terms), such that aggregation
>> then works more efficiently. However, history has shown that while
>> this would work for the short term, it would require continuous
>> renumbering in response to many factors (new addresses, corporate
>> mergers, etc) in order to maintain its efficiency.
>> 
>> Since we have not solved renumbering very effectively in the first
>> place, I feel that this is not worth working on.
>> 
>> I would, however, suggest that addressing renumbering would be an
>> excellent use of your time. A viable solution to renumbering large
>> public networks would mean that the BGP table would shrink, by the
>> same logic as above.
>> 
>> That is, if we had a method for renumbering continuously, then it
>> would improve the efficiency of BGP as well, to almost the same
>> extent, without incurring the initial internet-wide renumbering
>> effort.
>> 
>> Finally, I would note that while routing tables are large, the
>> internet still functions - this may not be the best use of your time
>> therefore.
>> 
>> Dave.