(ngtrans) Connect-IGP draft comments

[Pekka Savola <[e-mail]>]

Mostly just editorial issues at this point.

You assume that IS-ISv4 + IS-ISv6 or OSPFv2 + OSPFv3 are used;
what about (mainly) OSPFv2  + IS-ISv6?

--8<--
1. Abstract

This draft proposes a mechanism that allows an  incremental deployment
of IPv6 inside an IPv4 AS. It aims at automatically set up tunnels,
using IGP standard capabilities, in order to gradually introduce IPv6
connectivity within an initially IPv4 AS. As specified in
draft-ietf-ngtrans-introduction-to-ipv6-transition-07.txt, this 
technique must be considered as a solution with a scope of domain.

==> "it aims at automatically set up tunnels" should be phrased better

==> change the document name to a reference.

Terminology:

o Routing Protocols Gateway RPG
		
A routing protocols gateway is a component able to transfer routing
information (e.g. IPv6 prefixes, metrics...) from a routing protocol to
another one.

==> s/RPG/(RPG)/

==> from one routing protocol to another

4.1 General case

[...]
The IPv4 IGP will flood sufficient information in the AS provide
connectivity between these " IPv6 islands " to set up tunnel.

==> please rephrase, makes no sense.

>From a scope point of view, two cases are possible : 

==> s/>//

An IPv6 island is considered as a part of an IPv4 area :
    In this case, the information flooded through the network 
(via IPv4 IGP messages) should be broadcasted with an intra area scope. 
The border area routers will have to process the IPv4 IGP message 
(with intra area scope) and flood another IPV4 IGP message with 
inter area scope

==> s/border area/area border/ ?

4.2.1 Case description
[...]

To create tunnels between IPv6 islands, the IPv6 prefixes of a particular
island will be passed by OSPFv3 to OSPFv2 via the RPG. The RPG will
construct an OSPFv2 message and will flood it to all other OSPFv2
nodes. An OSPF v2 handling specific routing protocol gateway message
will receive this message and pass it to OSPF v3 via the RPG.
This technique will automatize the creation of tunnel in the IPV4 
domain.

==> What kind of tunnel?  IP-IP as specified in GTP?

The IPv6 prefixes transferred over the IPV4 IGP can be of any types
(e.g. ISATAP).

==> very little sense IMO to give ISATAP as an example, as when ISATAP
is used, igp-connect almost never would be used, I think.

4.2.3.2 Reception of opaque LSA 
When receiving this kind of opaque LSA, atunnel is created with the 
information given by the opaque LSA : the
TLV Type 1 giving the tunnel end point information and the TLVs Type 2
giving the prefixes information.

==> s/atunnel/a tunnel/

The way tunnel can be setup and used is implementation dependant. 
It can be automatic or configured tunnels.

==> hopefully this doesn't aim for standards track then as
then there could not be interoperability.

When reception of these opaque LSA are successfully completed, each
IPv6 island included in this IPv4 AS has the opportunity to communicate
with all the other IPv6 islands included in this AS.

==> s/LSA/LSA's/

6. Security considerations

The security mechanisms of the native routing protocols are used. 

==> security considerations of tunneling
techniques (in particular, decapsulation) will also apply.  This is 
especially bad if automatic tunneling is used.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords