Subject: (ngtrans) draft-lefaucheur-bgp-tunnel-transition-00.txt

From: [email-masked]
Date: Wed, 17 Jul 2002 11:16:32 +0900

i don't understand why this transition technology is needed.

	to make use of this mechanism, we need to upgrade all of the EBGP
	routers in the cloud.  when doing so, we can setup normal RFC2893
	tunnels and do normal BGP4+ over IPv6 (over IPv6-over-IPv4 tunnel).
	we don't need a new automated mechanism.

	another thing bothers me is the special use of IPv4 mapped address
	as indication of tunnel endpoint.  IPv4 mapped address already has
	overloaded with multiple meanings (RFC2553 API, SIIT, ...) and i
	really want to see these multiple semantics get removed, and make it
	be used only for RFC2553 only.  it causes a lot of security issues
	as outlined in my previous drafts.
	(i'm happy to say long good bye to IPv4 mapped address itself, but that
	is another question)

	we don't need more magic.

itojun

---

From: Ole Troan <[email-masked]>
Date: Wed, 17 Jul 2002 03:31:35 +0100

> 	we don't need a new automated mechanism.

I believe the motivation here is for the operator who do not want to
maintain a full mesh of configured tunnels in addition to the BGP
mesh. looking at the scenario 1, note that there is no magic. the
next-hop carried in BGP is one matching whatever automatic tunnelling
mechanism chosen. as far as I know all current BGP/IPv6
implementations already support this.

> 	we don't need more magic.

the scenario 1 offers a solution where you use IPv6 in IPv4 tunnelling
to create IPv6 connectivity. scenario 2 does not give IPv6
connectivity until your BGP sessions are up. this allows you to e.g
use this mechanism to encapsulate IPv6 packets in MPLS without an
additional IPv4 header or IPv6 IGP in the core.

cheers,
Ole

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 17 Jul 2002 13:02:34 +0900

Hello,

I just had a conversation with Itojun about that as well.

It seems that my presentation did not make it completely clear that 
Scenario 1 involves absolutely nothing new. It is just documenting what 
some SPs want to deploy/have deployed and how to use existing mechanisms 
(ie what Itojun is describing below as "normal tunnels + normal MP-BGP over 
IPv6").
It is just documenting the obvious. But as part of the exercise of 
documenting Migration scenarios and Migration solutions, we also need to 
include the obvious ones. Don't we?

Scenario 2 addresses the environments where the SP wants to maintain a 
single MP-iBGP mesh. As an example, some Telcos/SPs have implemented MPLS 
VPNs and have an MP-iBGP peering mesh carrying IP4 and IPV4 VPN addresse 
families today; They want to carry the IPv6 Address Family in the same 
MP-iBGP peering mesh (and IPV6 VPN in some cases).
Also, as Ole said:
         - they may not want to maintain any tunnel mesh among the iBGP 
routers in addition to BGP mesh
         - they may want to minimise overhead (eg remove IPv4 header when 
encapsulating in MPLS core)
A number of SPs do want to deploy that (typically the ones which have 
deployed MPLS VPNs).

Cheers

Francois