Subject: RE: Fwd: (ngtrans) 6to4anycast fineshes last call, ready for IESG forwarding as PS

From: "Christian Huitema" <[email-masked]>
Date: Wed, 10 Jan 2001 17:20:42 -0800

Keith,

I believe that there was a misunderstanding of your position, and that
there is now a slight misunderstanding of mine. Specifically, I wrongly
believed you were proposing to use ND to "nail" an association with the
router that received the anycast; this idea would make some sense, but
has more drawbacks than advantages; it turns out that this was not in
fact what you were requesting. Sorry. On the other hand, I believe that
Tony's proposal, of using some sort of redirect in order to route
traffic directly towards the best suited gateway for a particular v6
destination, is indeed complimentary of the anycast proposal. Indeed,
this is exactly why I wrote in the section 6	"Future Work" the
following text:

Using a default route to reach the IPv6 Internet has a potential 
drawback: the chosen relay may not be on the most direct path to the 
target v6 address. In fact, on might argue that, in the early phase 
of deployment, a relay close to the 6to4 site would probably not be 
the site's ISP or the native destination's ISP... it would probably 
be some third party ISP's relay which would be used for transit and 
may have lousy connectivity.  Using the relay closest to the native 
destination would more closely match the v4 route, and quite 
possibly provide a higher degree of reliability. A potential way to 
deal with this issue is to use a "redirection" procedure, by which 
the 6to4 router learns the most appropriate route for a specific 
destination. This is left for further study.

This text, in my mind, makes it clear that we should consider something
like Tony's proposal.

-- Christian Huitema

> -----Original Message-----
> From: Keith Moore [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2001 11:50 AM
> To: Bob Fink
> Cc: Randy Bush; Alain Durand; Tony Hain; Christian Huitema; 
> NGtrans List
> Subject: Re: Fwd: (ngtrans) 6to4anycast fineshes last call, ready for
> IESG forwarding as PS 
> 
> 
> Bob,
> 
> I must have misunderstood. 
> 
> I interpreted your last message ("please ask Christian any questions
> you may have about this new draft") to mean that you were closing 
> WG discussion of this draft as of last Monday (because you didn't
> say "submit comments to the list").  
> 
> I do have some objections to the new text in section 5.6:
> 
> 1. IIRC at the last IETF meeting Tony claimed that his scheme 
> for doing 
>    RD/ND was compatible with Christian's proposal, but the wording in 
>    the latest version of this document appears to nix that 
> possibility.  
>    I thought we had agreed to at least leave the possibility open, 
>    rather than closing the door.
> 
>    If we later decide that ND or RD is a good idea I don't want us 
>    to have to ask for another prefix.
> 
> 2.  as for the text itself:
> 
> > The ND alternative would be to use the anycast address for
> > discovering the nearest relay, and then to build a "regular"
> > association with this relay. It can be argued that using ND will be
> > more a more standard way to do routing, that with a regular
> > association failures will be easier to detect, and also that nailing
> > the default connection to a specific 6to4 relay router will avoid
> > any transient failure caused by the routing protocol. On the other
> > hand, there are many arguments against this type of association.
> 
> the principal reason that I saw for using ND/RD (or a variant thereof)
> is that packets destined for a native IPv6 subnet could be tunneled 
> directly to the IPv4 address of a router that was acting as a tunnel
> endpoint for that subnet, without having to tunnel all 
> non-6to4 packets 
> to a single relay router.  this would reduce the load on 
> relay routers.
> 
> in other words, I wasn't viewing ND as a mechanism for finding
> a single relay router but was viewing RD as a mechanism for finding
> a tunnel endpoint for a specific subnet.  the tunnel endpoints
> could be propagated using MP-BGP, perhaps using the same mechanism
> as suggested in draft-ietf-ngtrans-bgp-tunnel-00.txt.
> 
> > Using ND to discover the next hop router may be in line with the
> > generic IPv6 architecture, but is actually not in line with the
> > specific software written for 6to4, in which the IPv4 next hop is
> > derived algorithmically from the IPv6 destination address. 
> 
> this is only the case for 6to4 destination addresses, not for other
> destination addresses.
> 
> > In any
> > case, maintaining ND associations for each 6to4 router that they
> > serve will increase the load of 6to4 relay routers.
> 
> I might need to read the ND spec again, but from what I remember, I
> disagree.  I see no need for the relay routers to maintain per-client
> state.  And if the relay routers were able to redirect some traffic
> directly to an appropriate tunnel endpoint, it would lessen their
> overall load rather than increase it.
> 
> > If the default connection is nailed to a specific 6to4 relay router,
> > the 6to4 router must actively monitor that router, detect failures,
> > and then try to find a secondary router, which will only be possible
> > if routing tables have been updated.  
> 
> Well of course it assumed that relay routers will update their routing
> tables so that they can return RA replies based on current 
> information.
> But given that all of these RA replies are expressing tunnel endpoints
> in terms of IPv4 addresses, what's wrong with having each RD request
> stand on its own?
> 
> > In contrast, with a pure
> > anycast tunnelling solution, the packets will be routed to the
> > functioning 6to4 relay router as soon as the routing tables have
> > been updated.
> 
> granted, the RAs would need relatively short TTLs.
> 
> > After a failure of the nearest 6to4 relay router, if we use ND, the
> > default connection will be nailed to a back-up 6to4 relay router,
> > and will only be nailed back to the nearest 6to4 relay router if the
> > back-up fails. 
> 
> The connections don't get nailed to relay routers (or tunnel 
> endpoints)
> for any longer than the TTLs in the RA messages.  
> 
> > In contrast, with a pure anycast tunnelling solution,
> > the packets will always be routed to the nearest available 6to4
> > relay router.
> 
> right, but at the expense of having all non-6to4 traffic tunneled 
> through those relay routers.
> 
> it seems to me that which one is better really depends on your 
> model for deploying relay routers (do you want to deploy a few
> relay routers or are you willing to deploy lots of them and disperse
> them throughout your net?),  and your assumptions about how many 
> of the native v6 subnets will be willing to advertise suitable tunnel 
> endpoints.
> 
> > Another line of argument is that the use of ND between routers is
> > not entirely defined, and that using ND in this scenario is
> > potentially more complex and more error-prone than just forwarding
> > the packets to a well-known anycast address. In the absence of a
> > clear-cut advantage for the ND solution, it is preferable to chose
> > the simpler alternative, pure anycast tunnelling.
> 
> I agree with the argument that ND is more complex, but didn't think
> we had consensus to close the door on using it.
> 
> Keith
>

---

From: Keith Moore <[email-masked]>
Date: Wed, 10 Jan 2001 20:33:37 -0500

> This text, in my mind, makes it clear that we should consider something

okay, well if there wasn't really a serious proposal to use ND to 
find the default route, perhaps we could just save the electrons
used to print that section?    I suspect it could even be done
with an IESG note if IESG were willing...avoiding the need to 
re-issue another draft.

ND and RD are close enough that I still think  section 5.6 could be
confusing.

Keith