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

[Francois Le Faucheur <[e-mail]>]

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

At 03:31 17/07/2002 +0100, Ole Troan wrote:
> >       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.
>
>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.
>
> >       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.
>
>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