Weekly Routing Table Report

Masataka Ohta mohta at necom830.hpcl.titech.ac.jp
Sun Sep 1 00:04:03 UTC 2019


Valdis Klētnieks wrote:

>> The solution is:
>>
>> 	https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03
> 
> All I see there is some handwaving about separating something from
> something else, without even a description of why it was better than
> what was available when you wrote the draft.

Read the first three paragraphs of abstract of the draft:

    This memo describes the architecture of end to end multihoming.  End
    to end multihoming does not burden routing system for multihoming.
    That is, even extensive use of end to end multihoming does not
    increase the number of entries in a global routing table.

    Traditionally with IPv4, multihoming capability is offered by an
    intelligent routing system, which, as is always the case with
    violating the end to end principle, lacks scalability on a global
    routing table size and robustness against link failures.

    On the other hand, with end to end multihoming, multihoming is
    supported by transport (TCP) or application layer (UDP etc.) of end
    systems and does not introduce any problem in the network and works
    as long as there is some connectivity between the end systems.

> I don't see anything about how it's supposed to work - for example, if my cell
> phone had an IP address via DHCP from my home wireless router but also has an
> IPv6 from cellular connection, how *exactly* does it *securely* fall back to
> cellular if a thunderstorn knocks out Comcast's gear in the area?

Read the title of the draft. The draft is not intended to describe
protocol details.

There are other articles, some of which are peer reviewed papers, 
describing details.

But, first thing for you to do is to read the title and the abstract
section of the architectural draft

> Try attaching an actual protocol specification

Read the title of the draft.

							Masataka Ohta



More information about the NANOG mailing list