Fred, In my personal view, I think you need to really investigate what can be done with OSPF. There is a lot of experience with it and how it scales and there is real experience with OSPF on real NBMA networks. It is an existing well known solution.
If the real focus of this is large deployments of ISATAP across thousands of routers, I think you need to provide some evidence that this is a real problem in some real deployment. Also, why would someone want to use ISATAP in an environment like that? Native or point to point tunnels seems a lot simpler to me. With my w.g. chair hat on: If you are trying to turn ND into a routing protocol (for ISATAP), then then is very likely out of scope for the 6man w.g. This is not maintenance. Regards, Bob On Dec 1, 2009, at 5:09 PM, Templin, Fred L wrote: > Bob, > >> -----Original Message----- >> From: Bob Hinden [mailto:bob.hin...@gmail.com] >> Sent: Tuesday, December 01, 2009 4:14 PM >> To: Templin, Fred L >> Cc: Bob Hinden; Thomas Narten; ipv6@ietf.org >> Subject: Re: New draft on "Stub Router Advertisements in IPv6 >> NeighborDiscovery" >> >> Fred, >> >> Why not just use OSPF? It already supports NBMA networks and is widely >> supported by existing >> routers. > > On the sorts of NBMA links I am concerned with (ISATAP being > the primary example), it may be impractical to involve great > multitudes of routers in a single OSPF instance. For instance, > in ISATAP applied to ISP networks it might be possible for > hundreds or thousands of CPE routers that don't know about > each other to engage in a routing protocol instance with a > set of well-known default routers in the provider network > and thereby discover one another. But, it might not scale > well, and it might not allow for secure exchanges between > CPE routers that must consult with 3rd party trust anchors > within the ISP network before they can communicate with each > other directly. > >> Adding complexity to ND to solve what sounds like a routing problem seems to >> me like the >> wrong way to go. > > It is solving a routing problem without a routing protocol > by taking the ISATAP host-to-router model and extending it > to apply also to router-to-router. It leverages the concept > of the ISATAP link and the operation of IPv6 Neighbor > Discovery over the ISATAP link. > > Router-to-router tunneling is something that was left as > out-of-scope when RFCs 4214 and 5214 were published; I am > now working to address router-to-router tunneling through > a new document that would update RFC5214. Part of this is > how routing would work, and the other part is how ingress > filtering can be asserted so that packets that come from > a router that is not authorized to send them can be dropped. > > Thanks - Fred > fred.l.temp...@boieng.com > >> Bob >> >> >> On Dec 1, 2009, at 3:45 PM, Templin, Fred L wrote: >> >>> Hi Thomas, >>> >>>> -----Original Message----- >>>> From: Thomas Narten [mailto:nar...@us.ibm.com] >>>> Sent: Tuesday, December 01, 2009 1:54 PM >>>> To: Templin, Fred L >>>> Cc: ipv6@ietf.org >>>> Subject: Re: New draft on "Stub Router Advertisements in IPv6 >>>> NeighborDiscovery" >>>> >>>> Hi Fred. >>>> >>>> the picture is a start... >>> >>> OK. >>> >>>> "Templin, Fred L" <fred.l.temp...@boeing.com> writes: >>>> >>>>> http://osprey67.com/stub-router.pdf >>>> >>>>> In this picture, the link I am concerned with is labeled >>>>> "NBMA Link" in the diagram. >>>> >>>> Please add an indication for what a typical "site" is. Are all of the >>>> stub networks considered part of the same site (i.e., same company, >>>> same house, etc.)? >>> >>> In my picture, each stub network is a separate site. >>> The NBMA link and all of its attached devices is also >>> a separate site, so the provider-facing interfaces of >>> all of the stub routers in the diagram are connected >>> to the same site. (This is not to say that stub >>> network "sites" cannot be multi-homed; they certainly >>> can, but the drawing does not show examples of that >>> in order to avoid excessive clutter.) >>> >>>> Also, you show "stub network 1", 2, 3, .etc. >>>> >>>> What is the internal structure of those networks (or does it matter)? >>> >>> It doesn't matter. >>> >>>> In particular, there are presumably multiple links present in a stub >>>> network. Are there only "normal" routers internally? >>> >>> Normal routers and links, yes. But, each stub network >>> could itself contain multiple internal NBMA links which >>> would appear to be sites within themselves (or, "sites- >>> within-sites"). Each of those "sub-sites" would have >>> a set of default routers and a set of routers that >>> appear as stubs within that site. In other words, >>> the model is recursive. >>> >>>> Can a "stub" router only exist on the NBMA link? >>> >>> Do you mean, are NBMA links the only examples where >>> one would find stub routers? I don't think so, but >>> NBMA links are peculiar and may present challenges >>> to ordinary routing protocols that are not as >>> prevalent on "ordinary" links. >>> >>>> Can you provide a specific example of the kind of link technology you >>>> are thinking of for the NBMA link? Is this DSL/Cable/ATM? Or just a >>>> hypothetical NBMA link? And who runs the NBMA link? Is this not a link >>>> operated by the Provider? >>> >>> One example is an ISP network that connects multitudes >>> of CPE routers (i.e., stub routers) with a finite >>> collection of gateways via IP-in-IP tunneling. ISATAP >>> is an example NBMA link type that could be used in >>> such networks. >>> >>>> I see there are "hosts" on the NMBA link. Can you provide examples of >>>> what kind of hosts? (I guess I really don't understand the deployment >>>> model you are assuming here... i.e., why wouldn't the NBMA link only >>>> have routers on it, with all hosts being behind a router.) >>> >>> Take ISATAP for example. The hosts configure tunnel >>> endpoints that connect to the ISATAP "link". Any >>> device that supports ISATAP can connect to the >>> NBMA link in this fashion, e.g., if there is no >>> way for the host to connect behind an "ordinary" >>> router. >>> >>>>> As you can see, there are stub networks connected to the link by >>>>> stub routers, and default routers that connect the link to provider >>>>> networks (which then connect to the Internet in some way). The link >>>>> is intentionally shown as two segments joined together by "..." to >>>>> show that it can be arbitrarily large and in some cases may contain >>>>> hundreds, thousands, or even more stub routers and stub networks. >>>> >>>> OK. >>>> >>>>>> From the diagram, only those routers labeled "default router" >>>>> should advertise default router lifetimes, M&O flags, PIOs, >>>>> and other RA information that provides operating parameters >>>>> for the link. If the routers labeled "stub router" also >>>>> advertised those kinds of parameters, then any hosts labeled >>>>> "host on NBMA link" would incorrectly update their link >>>>> parameters. As a simple example, if a router labeled "stub >>>>> router" advertised a non-zero default router lifetime in >>>>> an RA that was heard by a host labeled "host on NBMA link", >>>>> then the host would incorrectly configure a default route >>>>> that points to a stub network. >>>> >>>> OK. I understand this. >>>> >>>> That said, my first reactions would be: >>>> >>>> 1) is this a real deployment scenario? Who is setting up a network >>>> like this? Maybe they shouldn't do this and there are better >>>> approaches... >>> >>> There are a wide variety of use cases; 'draft-rangers-russert' >>> lists many of them. >>> >>>> 2) So what if the default route (on some hosts) points to the wrong >>>> thing, the stub router will presumably send a redirect for any >>>> traffic it is relaying, and the host will update its cache and from >>>> that point forward things are fine. Perhaps not "optimal" in a pure >>>> sense, but I certainly don't see this is as so broken a fix is >>>> needed... At least not without really understanding who is >>>> operating a network like this... >>> >>> I'm afraid I didn't understand this; the hosts will discover >>> default routes in the same way that the stub routers will. >>> ISATAP is an example of a mechanism that provides for hosts >>> to discover the unicast addresses of default routers. >>> >>> Fred >>> fred.l.temp...@boeing.com >>> >>>> Thomas >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
