On Tue, 2006-10-17 at 12:10 -0700, Zhenghui Xie wrote: > >I'm slightly confused by the wording and the intent. If network/initial > >is deleted, then how can IPsec and IP tunneling still be in > >network/initial? > > > > > > > sorry for the confusion. what I meant, is that NWAM daemon will take > care of most of the transient tasks in network/initial (and other > deleted services as well). But the IP tunneling tasks and IPsec tasks in > network/initial might be done by the IPsec service(s) and/or IP > tunneling service if it will exist, so NWAM daemon don't need to do it.
The problem with having a single IP tunneling service is that either all tunnels are configured or none of them. I then wouldn't be able to have an IPsec tunnel configured in one profile, and a 6to4 IPv6 tunnel in another. > >Also, why is IP tunneling not something that would be configured by the > >NWAM daemon itself like other IP interfaces? Would it not be > >appropriate to have tunnel configuration be part of a profile much like > >a link aggregation or an IPMP group? > > > > > > > It could be or could not be. Previously we thought IP tunneling will be > done by a service in which case NWAM only need to enable/disable it at a > "right" time. But now it will change as you mentioned, we can discuss it > more about how it works. Indeed, it would be good to work out the details here, as there are probably different use cases that would call for different types of configuration. For example, if I have a tunnel configured, it probably only works in a very specific networking context, where I know specific IP addresses are usually reachable. As such, it makes sense to me to have a tunnel only exist in the profile I've configured to contain it. > >> milestone/network will remain for backwards compatibility, but it will be > >> obsoleted so that we can delete it later. There might be concerns that > >> poorly > >> written network applications will need to depend on milestone/network > >> because they will fail if they don't find certain peer. > >> > >> > > > >The above rationale for milestone/network isn't consistent with the > >milestone/network in step 3 below. > > > > > > > I am not sure I understand what you imply correctly. Do you mean that > "obsolete" here is conflicting with "enable" in step 3? No. You stated that the reason you're keeping milestone/network is to appease applications that depend on reachability to their peers, and do this by depending on milestone/network. At the same time, you have milestone/network enabled when only loopback, IPsec, and IP filter are configured. The broken applications you're keeping milestone/network for will most definitely not be able to reach their peers when milestone/network is enabled... Having a milestone/network enabled where you have it is fine with me, but I think using broken applications to justify that isn't entirely accurate. There are probably different reasons for having a milestone/network where you've defined it. > >>Note2: Per Seb's latest email, clearview team is re-defining IP tunneling. > >>No IP > >> tunneling service is listed here for now. > >> > >> > > > >That's true, but it would be good to know where NWAM sees IP tunnels > >fitting in. Can I define a tunnel as part of a profile? If this is the > >case wouldn't they be created by the NWAM daemon? > > > > > > > > > As I said, we will discuss more. :-) Okay. > > I will need a little more input of "define a tunnel". So how will > clearview configure a tunnel? The same way as it is done today. You'll just have the option to use a niftier command-line interface (dladm) to configure the link-layer attributes of an IP tunnel, and have extra capabilities that you don't have today (such as the ability to name your tunnel interfaces and to observe them using snoop). > and another question is that: would this configuration be part of an > interface so that different interfaces can have different tunnels? or > would this configuration be system wise? I'm not sure I understand the distinction you're trying to make, and I'm sure it's because I'm not as familiar with the NWAM architecture as you are. :-) An IP tunnel is an interface with a data-link layer (albeit one that consists of IP underneath) and a network layer. It is not owned by any other network interface, and is independent from other network interfaces. > If it is per interface, then I > think LLP would be a better place to keep the information. ULP discussed > here is not the right place to do so. I think I'm starting to see where you're going with this, but I'm really not confident that I understand the distinction between LLP and ULP well enough to pick one. The NWAM design seems to place all configuration of data-links and IP interfaces as part of a LLP, and an IP tunnel is definitely both of those things. So, according to the design, an IP tunnel should be part of a LLP. At the same time, the NWAM architecture describes an upper-layer profile as something that defines a set of things that happen under certain conditions, such as the configuration of IP addresses in a particular subnet, or which physical links are connected. It would make sense to make the configuration of an IP tunnel conditional on such criteria. As such, I don't see the LLP vs. ULP distinction as being very clear cut for IP tunnels, and I think I'd benefit from a whack on the head by a heavy clue stick. :-) Thanks, -Seb
