Subject: Re: applicability of bgp-tunnel [Re: (ngtrans) ngtrans status report]

From: [email-masked]
Date: Mon, 28 Jan 2002 11:06:58 +0100

Pekka,

see inline

Pekka Savola wrote:
> 
> On Mon, 21 Jan 2002 [email-masked] wrote:
> > Pekka Savola wrote:
> > > Was the justification hidden in this message in some subtle way?
> >
> > I was only trying to make clear that it is not a matter of selecting
> > option a) OR b).  Typical situations in which bgp-tunnel is used are
> > explained in the applicability section of the draft.
> 
> Why do you use the plural?  Out of the applicability section, this is the
> only one with significance:
> 
>    The transition methods described in this document typically applies
>    to an ISP that is familiar with BGP (possibly already offering
>    BGP/MPLS VPN services) and that wants to offer IPv6 services to some
>    of its customers.  However, the ISP does not (yet) want to upgrade
>    its network core to IPv6. With the mechanisms described here, the
>    provider only has to upgrade some PE routers in some POPs to Dual
>    Stack MP-BGP routers. The Dual Stack MP-BGP routers provide access to
>    IPv6 customers and may provide access to IPv4 customers in addition.
> 
> Basically, the application statement can be truncated to:
> 
> "Operator likes BGP and wants to interconnect customers running native
> IPv6 with IPv4 infrastructure."

That's a good summary, we just wanted to add some more context to it:
operators do know BGP and many of them do understand BGP/MPLS VPNs, so
they will be very happy if they can offer an additional service (IPv6)
using a mechanism they already know.

> 
> This sounds awfully familiar, only with the distinction that BGP is
> applied as a solution without clear view of the problem.

The problem is connecting IPv6 islands over an IPv4 core (and yes there
are other solutions, but some operators might like this solution more).

> 
> Alternative approach that has worked for years already: create tunnels and
> run a routing protocol over them.  If fully meshed topology is too much of
> a requirement (like iBGP), the tunneling could be full-meshed too, or via
> some tunnel routers like RR's.  Alternatively, automated mechanisms like
> ISATAP or 6to4 (only between PE-routers :-) could be used.
> 
> This seems to be nothing new, only a fancy way of establishing tunnels
> like MPLS.

We are not claiming to do 'rocket science', but there is a need to
describe the mechanism and the address format in "MP-BGP over IPv4"
clearly needs to be standardized in order that peering boxes use the
same address format.

> 
> btw,
> 
> 7.2. "MP-BGP over IPv4" and "MP-BGP over IPv6" approaches versus other
>    ngtrans mechanisms
> 
>    [TRANS] specifies a method to create automatic tunnels by using
>    IPv4-compatible IPv6 addresses.  This method is restricted to the
>    case in which the destination coincides with the endpoint of the
>    tunnel (host-to-host or router-to-host tunnels).  It has the
>    disadvantage that it requires an IPv4 address per host.
> 
> ==> see at the bottom
> 
> "MP-BGP over
>    IPv4" and "MP-BGP over IPv6" approaches require only one IPv4 address
>    per island
> 
> ==> it was assumed that the core of the island is IPv4-only, making this
> point moot?

The island is IPv6 and has a dual-stack router at its edge (PE router).

> 
>  and enables automatic tunnels for the router-to-router
>    case in contrast to the automatic tunneling described in [TRANS]
>    where the tunnel end-point is the final destination.
> 
> ==> why couldn't you do like (or am I misunderstanding what you talk
> about?):
> 
> routerA   -----   routerB  ------   customer1
> 3ffe:ffff:1::1    3ffe:ffff:2::2    3ffe:ffff:3::/48
> 10.0.0.1          10.0.0.2

Pekka, in order to understand your picture: where are your routerA and B
located: in the IPv4-only core, in the IPv6 island or are they dual
stack edge routers?

dirk

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Jan 2002 13:10:42 +0200 (EET)

> using a mechanism they already know.

If they perform BGP/MPLS VPN's, couldn't the same be supported via MPLS 
mechanisms?

> are other solutions, but some operators might like this solution more).

I think the question is whether this has any significant impact on the
transition, warranting the inclusion to the "cookbook".  Slightly
different way of doing the same thing is not that (IMO).

> The island is IPv6 and has a dual-stack router at its edge (PE router).

Well, 'island' can mean many things: you meant different sites (sites 
IPv6), I meant the core network still in IPv4.

The mechanism I described requires one IPv4 address per PE router, which 
is by definition non-issue.  Sites themselves require no IPv4 at all.  So 
I don't quite see the point of your argument of 'island requiring only one 
IPv4 address', or ellse I'm misunderstanding something.

> located: in the IPv4-only core, in the IPv6 island or are they dual

RouterA and B are PE routers at the edge of IPv4 core.

-- 
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

---

From: [email-masked]
Date: Mon, 28 Jan 2002 13:43:06 +0100

see below

> routerA:
> # ipv6 route 3ffe:ffff:3::/48 ::10.0.0.2

That's precisely what we did (until people wanted to get rid of
compatible addresses).  So now the next hop is a IPv4-mapped address.

And in order that routerA knows which addresses can be reached behind
routerB, MP-BGP is used. 

dirk