Subject: Re: (ngtrans) ngtrans status report

From: [email-masked]
Date: Mon, 21 Jan 2002 13:22:12 +0100

Pekka Savola wrote:
> 
> On Mon, 21 Jan 2002 [email-masked] wrote:
> > You are right, we didn't answer Alain's question on the mailing list.
> > One should not consider bgp-tunnel as a mechanism opposed to the couple
> > (6to4, isatap):
> >
> > - When "MP-BGP over IPv4" is used the sites themselves can use isatap
> > - In "MP-BGP over IPv6" 6to4 can be the underlying inter-site ngtrans
> > mechanism, while isatap is used within the site
> 
> 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.

dirk

> 
> Pekka
> 
> > > On Wed, 16 Jan 2002, Bob Fink wrote:
> > > [snip]
> > > > BGP-TUNNEL has been changed from Informational to Standards Track due to
> > > > the recent addition of an approach that requires standardization.
> > > > BGP-TUNNEL will be passed thru the IDR working group for comment as it is
> > > > last called for forwarding
> > >
> > > I recall Alain asking the authors of BGP tunneling mechanisms to justify
> > > their solutions:
> > >
> > > --8<--
> > > Date: Wed, 05 Sep 2001 10:53:39 -0700
> > > From: Alain Durand <[email-masked]>
> > > To: ngtrans <[email-masked]>
> > > Subject: (ngtrans) BGP-tunnels and connect-ipv6-igp
> > >
> > > Stepping back a little, we now have 2 set of proposals to address the
> > > issue of scaling tunnel set-up during transition.
> > >
> > > a) 6to4 + isatap
> > > b) BGP-tunnel + connect-ipv6-igp
> > >
> > > As work in the general direction of a) has started long time ago and is well
> > > on its way, I would like to suggest the authors of b) to come up with some
> > > rationale/applicability statements that would help the working group
> > > to understand better how to position b) in regards to a)
> > > --8<--
> > >
> > > There were no follow-ups.
> > >
> > > Has this been discussed in the last meeting, off-list, or when the
> > > decision to stardardize (would experimental be better, anyway?) BGP
> > > tunneling was made?
> > >
> > > --
> > > 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
> >
> >
> 
> --
> 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

-- 
Dirk Ooms                       mailto:[email-masked]
                                tel:+32 3 2404732
Network Strategy Group (NSG)    http://aww.alcatel.com/nsg
Alcatel                         http://www.alcatel.com

---

From: Pekka Savola <[email-masked]>
Date: Sun, 27 Jan 2002 20:46:36 +0200 (EET)

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

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

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.

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?

 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          

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

routerB:
# ipv6 route 3ffe:ffff:3::/48 [ptp-address between routerB and customer1]
# ipv6 route ::/0 ::10.0.0.1

(of course, manual tunneling could also be used)

That is, I may have missed something, but in your draft you're assuming 
ISP's core is still IPv4-only, but that fact couldn't be used when
interconnecting the sites?