Subject: Under IESG review: draft-coene-sctp-multihome-03.txt

From: Alex Zinin <[email-masked]>
Date: Sat, 29 Mar 2003 10:59:03 -0800

Folks-

 Comments on this one would be appreciated...
 It has "Interaction with routing"...

-- 
Alex

---

From: Acee Lindem <[email-masked]>
Date: Wed, 02 Apr 2003 15:31:30 -0500

Alex,
I don't really see any problems with this one. Sort of a loose
discussion of the transport using multiple endpoints and fate
sharing. However I didn't see anything blatantly incorrect
(other than there is a statement that multiple addresses, aka
secondary addresses are new for IPv6 ;^). I really don't like
the fact that their examples use some sort of ID rather than
IP addresses but one has to pick their battles.

Here is the link:

http://www.ietf.org/internet-drafts/draft-coene-sctp-multihome-03.txt

-- 
Acee

---

From: Alex Zinin <[email-masked]>
Date: Wed, 2 Apr 2003 15:06:36 -0800

Acee,

  Hmmm... What about the fact that hosts would need
  to run routing protocols in order to figure out what
  addresses to use? Imagine a server...

-- 
Alex

---

From: Acee Lindem <[email-masked]>
Date: Wed, 02 Apr 2003 18:15:28 -0500

Alex,

I said it was a loose discussion ;^)

     Under the assumption that every IP address will have a different,
     seperate path towards the remote endpoint, (this is the
     responsibility of the routing protocols or of manual configuration)
                           ~~~~~~~~~~~~~~~~~
     , if the transport to one of the IP addresses (= 1 particular path)
     fails then the traffic can migrate to the other remaining IP address
     (= other paths) within the SCTP association.

-- 
Acee

---

From: Alex Zinin <[email-masked]>
Date: Wed, 2 Apr 2003 16:37:40 -0800

Acee,

  That part was fine. How about this:

> 2.2 SCTP multihoming and the size of routing tables
> 
> 
> 
>     As multihoming means that more than one destination address is used
>     on the host, that would mean that a routing descision must be made
>     on the host in IP. The host does not know beforehand to which other
>     host it is going to send something, so that would in theory require
>     that all possible paths to all possible destinations should be known
>     on that host. This amounts to the host being a part of the
>     distribution of the routing information in the network.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

-- 
Alex

---

From: Alex Zinin <[email-masked]>
Date: Fri, 11 Apr 2003 12:29:34 -0700

Ross,

  Thanks a lot for your comments! I'll forward them to the IESG.

-- 
Alex
http://www.psg.com/~zinin/

Wednesday, April 9, 2003, 11:24:41 AM, Ross Callon wrote:
> At 04:37 PM 4/2/2003 -0800, Alex Zinin wrote:
>>...That part was fine. How about this:
>>

> I think that it would be a big mistake to have hosts (including servers)
> running routing protocols, for several reasons (there are probably other 
> reasons as well):

> 1. It increases the number of nodes running routing, which may have
> scaling implications.

> 2. It makes it harder to secure the routing infrastructure (the set of all
> hosts in any given network have a larger number of services turned on 
> than the set of routers -- making them more susceptible to worms,
> for example -- also, some of the hosts listening in might be looking
> for information that they can use to attack, for example, by highjacking
>   a BGP session). I think that there are many ways that this opens up
> holes in the security of the routing infrastructure. 

> On the other hand, the above paragraph is not completely clear to me
> regarding whether it says that hosts run routing protocols. It might mean
> that hosts listen in on routing protocols (which has other implications, 
> such as the need to figure out whether to reliably transfer LSAs/LSPs
> to hosts, and how hosts listen in on BGP -- which we might not want 
> them to do). Alternatively, it might mean that routers pass routing 
> information to hosts in some manner.

> This ambiguity would appear to be another problem.

> Also, an excerpt from section 2.1 (just after figure 2.1.4):

>>         As a practical matter, it is recommended that IP addresses in a 
>>         multihomed endpoint be assigned IP endpoints from different TLA's 
>>         to ensure against network failure. 

> Aren't TLAs "top level aggregates"? This doesn't make any sense to 
> me. Are they saying that hosts should be multi-homed to completely
> different backbone providers, so that if one major provider goes down
> it can use another one? In many cases hosts might want to be multi-
> homed to the same provider, and use two addresses which are both
> from that provider's space. Alternatively, hosts might be multi-homed
> to two different network segments internal to the same corporate
> network, and the corporate network might itself be multi-homed to 
> the same large service provider. The host might have two different 
> addresses, but not necessarily from different TLAs. 

> One minor nit: The acronym TLA is not actually defined in this document. 

> The document only lists some issues, and in most cases doesn't give
> a clear indication regarding what the solution to the issues are. I don't 
> think that it even clearly states the issues. 

> Thus I guess at some level I don't see the point. 

> Ross