Fred, Why not just use OSPF? It already supports NBMA networks and is widely supported by existing routers. Adding complexity to ND to solve what sounds like a routing problem seems to me like the wrong way to go.
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 --------------------------------------------------------------------
