Subject: Re: ID on BGP extensions to Tag IPv6 routes that has IPv4 tunnels

From: "Tissa Senevirathne" <[email-masked]>
Date: Wed, 19 Jun 2002 15:22:19 +0000

Truly a good question.. Thanks

Here is the summary of differences.

**ID: draft-tsenevir-ipv6-bgp-tun-00.txt**

1. Treat IPv4 tunneling as an attribute of the native IPv6 route

2. Extended community attributes are presented as a generic way of 
identifying specific properties of IPv6 routes or for that matter any route. 
In other words it is an extension to BGP4+

3. Implementation vise it is easier to apply policies on attributes. 
Actually the recommended method is to use attributes not more messages.

4. Methods in the ID Allows Ipv6 devices(routers) to select either a native 
Ipv6 connection or a tunnel connection (eg: ipv4) to reach remote Ipv6 
cloude, based BGP policies.

5. In the ID we treat tunneling as reachability issue of the relay routers. 
Thus decoupling, tunnel discovery from route policies - to simplify 
implementation.

**ID: draft-ietf-ngtrans-bgp-tunnel-04.txt**

(the way I understand..)

1. it propose to use special NLRI to encode IPv4 address (section 4.1)

2. in section 7.3 the ID explains that it does not need to use VPN specific 
parts of 2547. in such case the methods can be simplified further, as 
presented in the new ID.

Conclusion:

The methods presented in ID draft-tsenevir-ipv6-bgp-tun-00.txt is simpler, 
scalable and easy to implement. NOTE: Tunnel between relay routers is a 
reachability issue between them and it is better that we do not complicate 
our IPv6 routes with that

>From: Pekka Savola <[email-masked]>
>To: Tissa Senevirathne <[email-masked]>
>CC: [email-masked]
>Subject: Re: ID on BGP extensions to Tag IPv6 routes that has IPv4 tunnels
>Date: Wed, 19 Jun 2002 08:57:02 +0300 (EEST)
>
>On Wed, 19 Jun 2002, Tissa Senevirathne wrote:
> > ID below describe use of BGP extended community attributes to tag IPv6
> > routes that need IPv4 tunneling.
> >
> > Please could you comment.
> >
> > 
>http://search.ietf.org/internet-drafts/draft-tsenevir-ipv6-bgp-tun-00.txt
>
>Have you read:
>
>http://search.ietf.org/internet-drafts/draft-ietf-ngtrans-bgp-tunnel-04.txt
>
>?
>
>--
>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
>
>--------------------------------------------------------------------
>IETF IPng Working Group Mailing List
>IPng Home Page:                      http://playground.sun.com/ipng
>FTP archive:                      ftp://playground.sun.com/pub/ipng
>Direct all administrative requests to [email-masked]
>--------------------------------------------------------------------

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Thu, 20 Jun 2002 16:36:46 +0200

Hi,

thanks Pekka for identifying this.

as far as I understand, the problem both drafts are trying solve is to
'signal' the IPv4 address to use as the egress of the tunnel, when
advertising IPv6 routes over an IPv4 backbone via BGP/TCP/IPv4. In order
to avoid the "additional explicit configuration" mentioned in RFC2545
(section 4).

RFC2545 says:
"
   Thus, when
   using TCP over IPv4 as a transport for IPv6 reachability information,
   additional explicit configuration of the peer's network address is
   required.
"

* draft-tsenevir-ipv6-bgp-tun encodes this IPv4 address as a new
sub-type from a BGP extended cummunities attribute.

* draft-ietf-ngtrans-bgp-tunnel encodes this IPv4 address in the BGP
NEXT_HOP field, in an IPv4-mapped IPv6 address.

Tissa, 

[sidenote : should we discuss this on the ppvpn mailing list ? I don't
think it's of specific interest to this community.]

You're proposing to use an IPv4 address encoded in an extended BGP
attribute as the tunnel endpoint ? this would mean that you don't use
the BGP NEXT_HOP attribute any more ? Which address will the BGP
NEXT_HOP contain ? What will it be used for ? How will BGP routers treat
it when propagating messages ?

Could you please explain for which router the following is a problem :
"
   Key problem in hand is to distinguish between IPV6 routes that have
   native connectivity and IPv6 routes that do not have native
   connectivity.
"
or what's wrong with this reasoning: "if the NEXT_HOP is reachable via
an IPv6 network (BGP/TCP/IPv6), use IPv6 forwarding; if the NEXT_HOP is
reachable via an IPv4 network (BGP/TCP/IPv4), use tunneling."

> 1. Treat IPv4 tunneling as an attribute of the native IPv6 route

is the fact that the IPv6 route is distributed over an IPv4 network not
enough to know that normal forwarding is not going to work and that
you'll need some tunneling ?
 
> In other words it is an extension to BGP4+

The BGP NEXT_HOP attribute is the attribute to use to find the next hop
address to use to forward traffic towards the announced destinations.

> Actually the recommended method is to use attributes not more messages.

I fail to see how this relates to policies.
Which draft is introducing which additional messages ? Both drafts are
using existing BGP messages.

> cloude, based BGP policies.

Who can make the selection ? the traffic-egress (BGP sender) or the
traffic-ingress (BGP receiver)?

Does this mean the network is IPv4 AND IPv6 capable ? If the answer is
yes, why should you tunnel IPv6 traffic ?

> Thus decoupling, tunnel discovery from route policies - to simplify

I'm confused. The extended communities attribute contains the tunnel
egress IPv4 address, AND will be used for some policy. So it couples
tunnel discovery and route policies, no ?

in draft-ietf-ngtrans-bgp-tunnel-04.txt, the BGP NEXT_HOP attribute is
used to identify the next hop, any other attributes can be added for any
other policy.

> 1. it propose to use special NLRI to encode IPv4 address (section 4.1)

There's no special NLRI. The draft uses IPv6 NLRI (with known AFI/SAFI),
actually MP_REACH_NLRI as it's defined in MP-BGP, and an IPv4-mapped
IPv6 address as NEXT HOP.

> parts of 2547. in such case the methods can be simplified further, as

section 7.3 says that there are no VPN specific parts in
draft-ietf-ngtrans-bgp-tunnel. Please explain the 'further
simplification' of your proposal.

why is using a new attribute simpler than using the next hop attribute ?

> our IPv6 routes with that

"simpler, scalable and easy to implement". Please convince us.

thanks,

Jeremy.