[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] RRG process clarification



Lars,
even the existing routing paradigms should be questioned.
LISP doesn't do anything for Multicast, it doesn't do anything wrt the IPv4 depletion

I have mentioned before that we are working on LISP-Multicast and indicated an Internet-Draft will be available by the end of April. We are still sticking to that schedule.

And the main LISP spec describes two approaches that can be taken. The yet to be published draft-farinacci-lisp-multicast-00.txt chooses one of them and details the design.

issue, it produces new update churn as to fight existing update churn.
Or: Wasn't IPv6 the future? Now the new routing architecture is supposed to be backward compatible with IPv4 AND !!! IPv6. Hasn't IPv6 got its chance and didn't it miss this chance ? What about the orthogonality between intra- and interdomain routing protocols?! Isn't this a pity ? I mentioned Multicast and LISP above. I should defend LISP. All existing multicast models have an enormous flaw: they are not state- less. This can be changed and -imo- should be changed.

Stateless-multicast can only mean that you broadcast traffic everywhere. ;-)

Dino


Summary: There could be such a bright future for routing.But not if BGP, i.e. the distance vector algorithm, is considered a holy cow.

Heiner


In einer eMail vom 18.04.2008 19:29:10 Westeuropäische Normalzeit schreibt lars.eggert@nokia.com:
Hi,

thanks for your note - it does really make things a lot clearer.

On 2008-4-18, at 0:07, ext Lixia Zhang wrote:
> Further, once we have surveyed the solution space, we need to
> develop rough consensus on the approach through the solution space.
> Arguing about 'incremental deployment', for example, doesn't help
> this at all.  We need to first come to some agreement on the very
> highest level branches in the decision tree (e.g., do we do map-and-
> encap or translation or ???), and not worry about the detailed
> leaves.  That is up to the IETF to wrestle with.

I hate to bring up the R-word, but I think before we can get to a
consensus on architectural or technical directions for a solution, we
need some consensus on what the requirements are for the architecture.
What are the goals and non-goals?

All the solution proposals on the table apear to have slightly
different sets of problems they address, based on what the proponents
of each consider important. The ongoing discussion intermingles
arguments about which goals are important to address for a future
architecture with which technical mechanisms are suitable to address
them, and that's confusing (well, to me at least.)

Lars

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg