Jerome et.al
Consider the attached diagram.
Abstract diagram below..
AS2
AS 1 AS3
| |
Site A | | Site B
Relay A - --- Relay B
1.
If we the remote relay routers are across multiple AS . In such a case BGP NEXT_HOP attribute would not represent the IP address of the relay routers.
2. In general, and most commonly, remote relay sites may not be known in advance and there can be multiple of such sites. In this case explicit peering and thus use of BGP NEXT_HOP attribute is not possibile.
3. When relay routers IP address is hidden in the NLRI, it is not convinent to apply BGP policies.
So abstracting relay router address as an attribute allows to address all that..
Why simple ?
Proposed method use BGP4+ and extended attributes.. There is no special tunnel specific parsers needed. It is all driven by BGP policy engine
Why scalable ?
It does not need any explcit peering or anything for tunneling purpose. Hence it scale as much the BGP 4+ scale
Why copied to PPVPN ?
RFC 2547 has roots in PPVPN. ID: draft-ietf-ngtrans-bgp-tunnel-04.txt has direct reference to 2547 and I am confident those folks can comment on the on going discussion productively
>From: [EMAIL PROTECTED]
>To: Tissa Senevirathne <[EMAIL PROTECTED]>
>CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Francois Le Faucheur <[EMAIL PROTECTED]>, Dirk OOMS <[EMAIL PROTECTED]>, Gerard GASTAUD <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>Subject: Re: ID on BGP extensions to Tag IPv6 routes that has IPv4 tunnels
>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 mailin!
!
!
!
g 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."
>
>s!
!
!
!
ome 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 r!
!
!
!
elates 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 couple!
!
!
!
s
>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. P!
!
!
!
lease 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.
Do You Yahoo!?
Sign-up for Video Highlights of 2002 FIFA World Cup
ipv6bgp diagram.doc
Description: ipv6bgp diagram.doc
