Subject: Comments on draft-ietf-multi6-v4-multihoming-02

From: "Elwyn Davies" <[email-masked]>
Date: Tue, 9 Nov 2004 14:35:21 +0100

I don't think this is ready for the IESG as yet.  If the wg is going forward
with this document the language in it needs to be cleaned up considerably
IMHO.  I guess part of the problem is that it looks like an aide-memoire for
those already skilled in the art - as an introduction for somebody who is
new to the problem it probably assumes too large a knowledge base.

Substantive:
============

Section 6:
A problem with all of these schemes is that they have no inherent means for
informing the multihomed site of a failed path where the failure is not in a
link directly connected to the link.  A major failure in the provider
network or an upstream transit provider can result in outgoing traffic being
blackholed even though incoming traffic is being rerouted via the
alternative path.  A host's transport has no way to influence the routing
even if it discovers that the path is broken.

Editorial:
==========
Throughout:
Consistency as regards hyphenation: multihomed,multihome vs multi-homed,
multi-home

I don't believe there is a verb 'to multihome'...s/b to be multi-homed.

Several abbreviations are not expanded at first usage (ISP, RIR, AS, CIDR,
etc)

Abstract: 
s/The analysis is done in order to serve as underlaying documentation/This
analysis has been carried out to provide baseline documentation/
s/who are working/which is working to provide/
s/as are described/that are described/

S1:
several places: 'announcing an address block' is a sloppy description of
what BGP does.

para 3: s/who wish to multi-home/which wish to be multi-homed/

what is a 'netblock'?

last para: the first and second disdavantages are not properly
separated..the last sentence of the first disadvantage is actually the
second disadvantage restated.  Both disadvantages stem from the multihomed
site only leasing the addresses from the primary provider. The whole
paragraph would benefit from a rewrite.

ISP is not expanded at first use (and could be avoided)

S2:
the definition of transit provider is not the normally accepted usage

S4.2: 'covering supernet' probably needs more explanation

S4.3: s/A site that have solved their/A site that has solved its/

There is more but time has run out...

Regards,
Elwyn

----------------------------------------------------------------------------
------

Elwyn B Davies

        Routing and Addressing Strategy Prime & IPv6 Core Team Leader
        CTO Office, Portfolio Integration		Solutions Ready

        Nortel Networks plc			Email:
[email-masked]
        Harlow Laboratories     			ESN
6-742-5498
        London Road, Harlow,    			Direct Line
+44-1279-405498
        Essex, CM17 9NA, UK     		Fax
+44-1279-402047
        Registered Office: 			Maidenhead Office Park,
Westacott Way,
        Company No. 3937799			Maidenhead, Berkshire, SSL6
3QH
----------------------------------------------------------------------------
This message may contain information proprietary to Nortel Networks plc so
any
unauthorised disclosure, copying or distribution of its contents is strictly
prohibited.
----------------------------------------------------------------------------
"The Folly is mostly mine"
and the opinions are mine and not those of my employer.
============================================================================
======

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 9 Nov 2004 23:39:49 +0100

On 9-nov-04, at 14:35, Elwyn Davies wrote:

> alternative path.

We have discussed this extensively in the design team.

The obvious solution is to send keepalives all the time. This is what 
SCTP does and it's very wasteful in bandwidth, and it may have 
substantial unpleasant side effects. For instance, if I close the lid 
on my laptop for a minute, I don't want the other side to declare me 
disconnected and break my SSH session.

The non-obvious solution is to suppress keepalives when it's clear that 
they aren't needed. This can happen in two cases:

1. When there is no traffic in either direction
2. When there is traffic in both directions

Only when there is traffic in only one direction there MAY be a failure 
condition, so keepalives are in order to make sure. This should work 
very well except that failures may now only be detected by one end. For 
instance, when A and B communicate and there is only reachability from 
A to B but not the other way around, A won't detect the failure if B is 
sending data, because A is both receiving B's data and sending out 
ACKs. However, B will see data going out but nothing coming back so B 
notices the potential failure and can trigger reachability testing.