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

["Elwyn Davies" <elwynd@nortelnetworks.com>]

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:
elwynd@nortelnetworks.com
        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.
============================================================================
======