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." some more comments inline: > **ID: draft-tsenevir-ipv6-bgp-tun-00.txt** > > 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 ? > 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+ 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. > 3. Implementation vise it is easier to apply policies on attributes. > 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. > 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. 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 ? > > 5. In the ID we treat tunneling as reachability issue of the relay routers. > Thus decoupling, tunnel discovery from route policies - to simplify > implementation. 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. > > **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) 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. > 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. 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 ? > > 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 "simpler, scalable and easy to implement". Please convince us. thanks, Jeremy. -------------------------------------------------------------------- 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 PROTECTED] --------------------------------------------------------------------
