Ed Remmell wrote: > JinHyeock - > > Unnecessary BU is not a huge problem. So you get an extra L3 handover. Let's
Up to some degree. We tested a link with two routers advertising two different prefixes. Then an MN kept sending BU whenever a new RA arrives. But this, I think, we'd better discuss at mip6 or DNA. > keep things simple... IMO this scenario you have identified is not a good > reason for introducing a new bit in the RA. Also, I still believe that the new Though it's absolute necessity can't be proved, I think it's worthwhile to investigate the idea of using one bit to 1) indicate completeness and 2) confirm reachability/ acknowledge solicitation. > proposed Link Identifier RA option is an excellent solution, if you need to > use RAs for movement detection because you don't have reliable L2 triggers to > give you the same information. Some link types like WiFi will have reliable L2 > triggers that can be used to detect a change of network (ESSID, for WiFi). In > that case, IMHO it is preferable to use the L2 triggers and leave the current > non-mobility-aware RA behavior unchanged. But, people deploying Mobile IPv6 > will do whatever they want. With this draft, we try to put input for ND update. So we emphasized on problems and gave just a brief sketch of possible solutions. I think it's DNA which will design MD/ DNA solution. Multiple prefixes on a multiple links with multiple routers makes MD very complex. Maybe we need some guideline for prefix assignment. IMHO, we'd better have better understanding on MD issues. > > > I'm not exactly sure what the purpose of non-on-link > > prefixes is, but > > > I agree, it certainly confuses things. > > > > IMO, the purpose of non-on-link prefix is to check the > > validity of IP address. > > > > It means that an advertising router injects the route for > > that prefix into Internet. > > Assume a node has an IP address whose prefix is advertised in > > that link as > > non-on-link prefix. (For convenience, let's assume that > > address is globally > > unique.) Then Internet routing mechanism will forward to > > that node any packet > > destined for that address. > > Yes, that's the mechanics of it. I was saying that I didn't understand why it > would need to be used. Actually, I just thought of a good scenario where it After movement, a node can use it to check whether it's current IP address is still valid. If the prefix of its current IP address is in an advertised RA, the address is topologically correct (whether L=0 or L=1) and a node can keep using it (maybe after DAD). Best regards JinHyeock P.S I bring our discussion out so that other people may be informed and join it. > JinHyeock - > > > This is the messy scenario I am worried of. > > > > 1) An MN is in Cell 1, having a CoA with Prefix A:: > > 2) The MN moves to Cell 2 and receives a RA with LinkID and > > only Prefix B::. > > 3) MN assumes it has moved and forms a new CoA with Prefix B::. > > 4) MN sends BU with the CoA with Prefix B::, so unnecessary > > BU happens. > > Unnecessary BU is not a huge problem. So you get an extra L3 handover. Let's > keep things simple... IMO this scenario you have identified is not a good > reason for introducing a new bit in the RA. Also, I still believe that the new > proposed Link Identifier RA option is an excellent solution, if you need to > use RAs for movement detection because you don't have reliable L2 triggers to > give you the same information. Some link types like WiFi will have reliable L2 > triggers that can be used to detect a change of network (ESSID, for WiFi). In > that case, IMHO it is preferable to use the L2 triggers and leave the current > non-mobility-aware RA behavior unchanged. But, people deploying Mobile IPv6 > will do whatever they want. > > > > I'm not exactly sure what the purpose of non-on-link > > prefixes is, but > > > I agree, it certainly confuses things. > > > > IMO, the purpose of non-on-link prefix is to check the > > validity of IP address. > > > > It means that an advertising router injects the route for > > that prefix into Internet. > > Assume a node has an IP address whose prefix is advertised in > > that link as > > non-on-link prefix. (For convenience, let's assume that > > address is globally > > unique.) Then Internet routing mechanism will forward to > > that node any packet > > destined for that address. > > Yes, that's the mechanics of it. I was saying that I didn't understand why it > would need to be used. Actually, I just thought of a good scenario where it > makes sense to use a non-on-link prefix: PPPv6. If the network sends a RA > containing prefix(es) for stateless address auto-configuration over PPPv6 to a > host, it could allow that same prefix to be used for stateless address auto- > configuration on other PPPv6 links, because the network has control over the > assignment of the PPPv6 EUI-64 interface IDs since that is an option > negotiated by PPPv6. > > > P.S. Can I send a copy of this to IPv6 WG? > Sure, no need to ask me. You can send the whole thread if you'd like ;-) > > Thanks. > - Ed > > > ______________________________________ > This E-Mail was sent with MailMax/WEB. > http://www.smartmax.com > > > > > > Dear Ed > > > > Thanks for your comments. > > > > > I disagree. What does the MN lose by performing a L3 move in this case? > > > Not very much. The MN needs to receive the RA first before detecting > > > movement (L2 triggers are faster - RAs can be delayed). I have seen our > > > MN implementation register a new care-of address with the HA in less > > > than 1 millisecond (that was without IPsec). So, the MN drops the CoA > > > > Tha's impressive. But how about DAD? > > > > > with prefix A:, does a L3 move because the link identifier changed, and > > > then rediscovers prefix A: and auto-configures the same CoA again and > > > reregisters it with the HA... that isn't a big problem, as far as I'm > > > concerned. In fact, all of the extra protocol overhead involved in > > > > This is the messy scenario I am worried of. > > > > 1) An MN is in Cell 1, having a CoA with Prefix A:: > > 2) The MN moves to Cell 2 and receives a RA with LinkID and only Prefix B::. > > 3) MN assumes it has moved and forms a new CoA with Prefix B::. > > 4) MN sends BU with the CoA with Prefix B::, so unnecessary BU happens. > > > > > I'm not exactly sure what the purpose of non-on-link prefixes is, but I > > > agree, it certainly confuses things. > > > > IMO, the purpose of non-on-link prefix is to check the validity of IP address. > > > > It means that an advertising router injects the route for that prefix into > > Internet. > > Assume a node has an IP address whose prefix is advertised in that link as > > non-on-link prefix. (For convenience, let's assume that address is globally > > unique.) Then Internet routing mechanism will forward to that node any packet > > destined for that address. > > > > I wish the above helps. But we'd better check with the authors. Erik or Thomas. > > > > > But in this case, I would just > > > ignore this pathological scenario. > > > > This may be practical. But my point is that it is worthwhile to investigate the > > method of adding one additional bit to facilitate efficient MD. > > > > As before, it's illuminating to exchange opinions with you. I wish we will have > > a face to face discussion at Minneapolis. > > > > Best regards > > > > JinHyeock > > > > P.S. Can I send a copy of this to IPv6 WG? > > > > > > > > > > > > I am afraid that there is some pathological case in which > > > > link identifier is > > > > not sufficient. Here is an example. Kindly find an attached > > > > file. It's difficult to draw a figure in text file. > > > > > > > > In the figure, an router has two interfaces, interface 1 and > > > > interface 2. To each > > > > interface, an AP (hence a cell) is attached. Interface 1 > > > > advertises the prefix A:: > > > > and interface 2 advertises Prefix A::and B::. > > > > > > > > Cell 1 and Cell 2 can't have the same link identifier. If MN > > > > moves from Cell 1 to > > > > Cell 2, it can keep using its current CoA with Prefix A::. > > > > But if MN having CoA with > > > > Prefix B:: moves from Cell 2 to Cell 1, it can't use its CoA anymore. > > > > > > > > So MN can't check the validity of its current CoA with Link > > > > Identifier only. > > > > > > > > > > JinHyeock - > > > > > > I disagree. What does the MN lose by performing a L3 move in this case? > > > Not very much. The MN needs to receive the RA first before detecting > > > movement (L2 triggers are faster - RAs can be delayed). I have seen our > > > MN implementation register a new care-of address with the HA in less > > > than 1 millisecond (that was without IPsec). So, the MN drops the CoA > > > with prefix A:, does a L3 move because the link identifier changed, and > > > then rediscovers prefix A: and auto-configures the same CoA again and > > > reregisters it with the HA... that isn't a big problem, as far as I'm > > > concerned. In fact, all of the extra protocol overhead involved in > > > reregistering the same CoA through the new router is needed to tell the > > > network that that CoA is now reachable through the new router, not the > > > old router. > > > > > > I'm not exactly sure what the purpose of non-on-link prefixes is, but I > > > agree, it certainly confuses things. But in this case, I would just > > > ignore this pathological scenario. > > > > > > Thanks. > > > - Ed > > > > > > --- > > > Outgoing mail is certified Virus Free. > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > Version: 6.0.522 / Virus Database: 320 - Release Date: 9/29/2003 > > > > > > > > > > > > > > > > Dear Ed > > > > > > > > Thanks for prompt and helpful reply. > > > > > > > > In this draft, we try to focus on problems and present only the sketch of > > > > solutions. We will present more detailed solution later. > > > > > > > > > Actually, the link identifier option draft would resolve this issue, also. > > > > > The > > > > > MN uses the RA to detect movement (assuming L2 triggers are not available). > > > > > A > > > > > change in link identifier in the RA is enough of an indication that movement > > > > > has occurred. > > > > > > > > I am afraid that there is some pathological case in which link identifier is > > > > not sufficient. Here is an example. Kindly find an attached file. It's > > > > difficult > > > > to draw a figure in text file. > > > > > > > > In the figure, an router has two interfaces, interface 1 and interface 2. To > > > > each > > > > interface, an AP (hence a cell) is attached. Interface 1 advertises the prefix > > > > A:: > > > > and interface 2 advertises Prefix A::and B::. > > > > > > > > Cell 1 and Cell 2 can't have the same link identifier. If MN moves from Cell 1 > > > > to > > > > Cell 2, it can keep using its current CoA with Prefix A::. But if MN having > > > > CoA with > > > > Prefix B:: moves from Cell 2 to Cell 1, it can't use its CoA anymore. > > > > > > > > So MN can't check the validity of its current CoA with Link Identifier only. > > > > > > > > Multiple routers on multiple links with multiple prefixes make MD very > > > > complex. > > > > I think we'd better have more clear understanding. Maybe at DNA. I wish you > > > > participate at & contribute to DNA meeting at Minneapolis. > > > > > > > > > I looked at your draft, it is a very clear and accurate description of the > > > > > current issues with RAs w/ regards to using them for movement detection. > > > > > > > > > > Section 2.3: > > > > > " It may useful to assign S bit, in the case where we want nodes to be > > > > > able to determine that they have received a solicited router > > > > > advertisement. With S bit, a node can confirm reachability with only > > > > > RS/ RA exchange." > > > > > > > > > > A new bit is not needed here. If the RA is sent to a unicast destination > > > > > IPv6 > > > > > address that is local to the MN, that is sufficient. But, the router will > > > > > > > > I agree with you. But can we use it to confirm bi-directional reachability? I > > > > hope > > > > WG will decide so. > > > > > > > > > probably send the RA to a multicast destination address (when solicited by > > > > > RS) > > > > > because that's what RFC-2461 recommends to do. > > > > > > > > > > Section 3.1: > > > > > " We propose to assign a new bit (Complete bit) in RA message to > > > > > indicate its completeness. When Complete bit is set, it means the RA > > > > > contains all the options (including all the Prefix Information > > > > > Options)." > > > > > > > > > > Well, this doesn't fit too well with frequent RA beacons + MN Eager Cell > > > > > Switching. In that case, you want the RA to be as small as possible while > > > > > still supporting MN Eager Cell Switching, i.e. R-bit option is probably the > > > > > > > > I agree that it's not a good idea to send Complete RA constantly. It may take > > > > too much bandwidth. I think we'd better send Complete RA only when it's > > > > beneficial, for example when a RS is received. > > > > > > > > Thanks for your kind words. > > > > > > > > Would you put your comments in IPv6 mailing list and bring this discussion > > > > out, > > > > so that other people may be infomed and join it? > > > > > > > > We requested chairs for time slot at Minneapolis and it'll help us if there is > > > > a > > > > thread about it. We had asked at SF but denied for the lack of interests. :-( > > > > > > > > Thanks for your kind words and see you at Minneapolis. > > > > > > > > Best regards > > > > > > > > JinHyeock Choi > > > > > > > > > > > > > > > > > > > > > JinHyeock & Greg - > > > > > > > > > > Actually, the link identifier option draft would resolve this issue, also. > > > > > The > > > > > MN uses the RA to detect movement (assuming L2 triggers are not available). > > > > > A > > > > > change in link identifier in the RA is enough of an indication that movement > > > > > has occurred. > > > > > > > > > > I looked at your draft, it is a very clear and accurate description of the > > > > > current issues with RAs w/ regards to using them for movement detection. > > > > > > > > > > Section 2.3: > > > > > " It may useful to assign S bit, in the case where we want nodes to be > > > > > able to determine that they have received a solicited router > > > > > advertisement. With S bit, a node can confirm reachability with only > > > > > RS/ RA exchange." > > > > > > > > > > A new bit is not needed here. If the RA is sent to a unicast destination > > > > > IPv6 > > > > > address that is local to the MN, that is sufficient. But, the router will > > > > > probably send the RA to a multicast destination address (when solicited by > > > > > RS) > > > > > because that's what RFC-2461 recommends to do. > > > > > > > > > > Section 3.1: > > > > > " We propose to assign a new bit (Complete bit) in RA message to > > > > > indicate its completeness. When Complete bit is set, it means the RA > > > > > contains all the options (including all the Prefix Information > > > > > Options)." > > > > > > > > > > Well, this doesn't fit too well with frequent RA beacons + MN Eager Cell > > > > > Switching. In that case, you want the RA to be as small as possible while > > > > > still supporting MN Eager Cell Switching, i.e. R-bit option is probably the > > > > > only option needed in the RA beacon. So, I do not like this proposal, but I > > > > > do > > > > > like "3.2 RA with Link Identifier Option". [LinkID] seems like a very good > > > > > solution. > > > > > > > > > > Thanks. > > > > > - Ed Remmell > > > > > Elmic Systems, USA > > > > > > > > > > > > > > > > > > > > ______________________________________ > > > > > This E-Mail was sent with MailMax/WEB. > > > > > http://www.smartmax.com > proposed Link Identifier RA option is an excellent solution, if you need to > use RAs for movement detection because you don't have reliable L2 triggers to > give you the same information. Some link types like WiFi will have reliable L2 > triggers that can be used to detect a change of network (ESSID, for WiFi). In > that case, IMHO it is preferable to use the L2 triggers and leave the current > non-mobility-aware RA behavior unchanged. But, people deploying Mobile IPv6 > will do whatever they want. > > > > I'm not exactly sure what the purpose of non-on-link > > prefixes is, but > > > I agree, it certainly confuses things. > > > > IMO, the purpose of non-on-link prefix is to check the > > validity of IP address. > > > > It means that an advertising router injects the route for > > that prefix into Internet. > > Assume a node has an IP address whose prefix is advertised in > > that link as > > non-on-link prefix. (For convenience, let's assume that > > address is globally > > unique.) Then Internet routing mechanism will forward to > > that node any packet > > destined for that address. > > Yes, that's the mechanics of it. I was saying that I didn't understand why it > would need to be used. Actually, I just thought of a good scenario where it > makes sense to use a non-on-link prefix: PPPv6. If the network sends a RA > containing prefix(es) for stateless address auto-configuration over PPPv6 to a > host, it could allow that same prefix to be used for stateless address auto- > configuration on other PPPv6 links, because the network has control over the > assignment of the PPPv6 EUI-64 interface IDs since that is an option > negotiated by PPPv6. > > > P.S. Can I send a copy of this to IPv6 WG? > Sure, no need to ask me. You can send the whole thread if you'd like ;-) > > Thanks. > - Ed > > > ______________________________________ > This E-Mail was sent with MailMax/WEB. > http://www.smartmax.com > > > > > > Dear Ed > > > > Thanks for your comments. > > > > > I disagree. What does the MN lose by performing a L3 move in this case? > > > Not very much. The MN needs to receive the RA first before detecting > > > movement (L2 triggers are faster - RAs can be delayed). I have seen our > > > MN implementation register a new care-of address with the HA in less > > > than 1 millisecond (that was without IPsec). So, the MN drops the CoA > > > > Tha's impressive. But how about DAD? > > > > > with prefix A:, does a L3 move because the link identifier changed, and > > > then rediscovers prefix A: and auto-configures the same CoA again and > > > reregisters it with the HA... that isn't a big problem, as far as I'm > > > concerned. In fact, all of the extra protocol overhead involved in > > > > This is the messy scenario I am worried of. > > > > 1) An MN is in Cell 1, having a CoA with Prefix A:: > > 2) The MN moves to Cell 2 and receives a RA with LinkID and only Prefix B::. > > 3) MN assumes it has moved and forms a new CoA with Prefix B::. > > 4) MN sends BU with the CoA with Prefix B::, so unnecessary BU happens. > > > > > I'm not exactly sure what the purpose of non-on-link prefixes is, but I > > > agree, it certainly confuses things. > > > > IMO, the purpose of non-on-link prefix is to check the validity of IP address. > > > > It means that an advertising router injects the route for that prefix into > > Internet. > > Assume a node has an IP address whose prefix is advertised in that link as > > non-on-link prefix. (For convenience, let's assume that address is globally > > unique.) Then Internet routing mechanism will forward to that node any packet > > destined for that address. > > > > I wish the above helps. But we'd better check with the authors. Erik or Thomas. > > > > > But in this case, I would just > > > ignore this pathological scenario. > > > > This may be practical. But my point is that it is worthwhile to investigate the > > method of adding one additional bit to facilitate efficient MD. > > > > As before, it's illuminating to exchange opinions with you. I wish we will have > > a face to face discussion at Minneapolis. > > > > Best regards > > > > JinHyeock > > > > P.S. Can I send a copy of this to IPv6 WG? > > > > > > > > > > > > I am afraid that there is some pathological case in which > > > > link identifier is > > > > not sufficient. Here is an example. Kindly find an attached > > > > file. It's difficult to draw a figure in text file. > > > > > > > > In the figure, an router has two interfaces, interface 1 and > > > > interface 2. To each > > > > interface, an AP (hence a cell) is attached. Interface 1 > > > > advertises the prefix A:: > > > > and interface 2 advertises Prefix A::and B::. > > > > > > > > Cell 1 and Cell 2 can't have the same link identifier. If MN > > > > moves from Cell 1 to > > > > Cell 2, it can keep using its current CoA with Prefix A::. > > > > But if MN having CoA with > > > > Prefix B:: moves from Cell 2 to Cell 1, it can't use its CoA anymore. > > > > > > > > So MN can't check the validity of its current CoA with Link > > > > Identifier only. > > > > > > > > > > JinHyeock - > > > > > > I disagree. What does the MN lose by performing a L3 move in this case? > > > Not very much. The MN needs to receive the RA first before detecting > > > movement (L2 triggers are faster - RAs can be delayed). I have seen our > > > MN implementation register a new care-of address with the HA in less > > > than 1 millisecond (that was without IPsec). So, the MN drops the CoA > > > with prefix A:, does a L3 move because the link identifier changed, and > > > then rediscovers prefix A: and auto-configures the same CoA again and > > > reregisters it with the HA... that isn't a big problem, as far as I'm > > > concerned. In fact, all of the extra protocol overhead involved in > > > reregistering the same CoA through the new router is needed to tell the > > > network that that CoA is now reachable through the new router, not the > > > old router. > > > > > > I'm not exactly sure what the purpose of non-on-link prefixes is, but I > > > agree, it certainly confuses things. But in this case, I would just > > > ignore this pathological scenario. > > > > > > Thanks. > > > - Ed > > > > > > --- > > > Outgoing mail is certified Virus Free. > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > Version: 6.0.522 / Virus Database: 320 - Release Date: 9/29/2003 > > > > > > > > > > > > > > > > Dear Ed > > > > > > > > Thanks for prompt and helpful reply. > > > > > > > > In this draft, we try to focus on problems and present only the sketch of > > > > solutions. We will present more detailed solution later. > > > > > > > > > Actually, the link identifier option draft would resolve this issue, also. > > > > > The > > > > > MN uses the RA to detect movement (assuming L2 triggers are not available). > > > > > A > > > > > change in link identifier in the RA is enough of an indication that movement > > > > > has occurred. > > > > > > > > I am afraid that there is some pathological case in which link identifier is > > > > not sufficient. Here is an example. Kindly find an attached file. It's > > > > difficult > > > > to draw a figure in text file. > > > > > > > > In the figure, an router has two interfaces, interface 1 and interface 2. To > > > > each > > > > interface, an AP (hence a cell) is attached. Interface 1 advertises the prefix > > > > A:: > > > > and interface 2 advertises Prefix A::and B::. > > > > > > > > Cell 1 and Cell 2 can't have the same link identifier. If MN moves from Cell 1 > > > > to > > > > Cell 2, it can keep using its current CoA with Prefix A::. But if MN having > > > > CoA with > > > > Prefix B:: moves from Cell 2 to Cell 1, it can't use its CoA anymore. > > > > > > > > So MN can't check the validity of its current CoA with Link Identifier only. > > > > > > > > Multiple routers on multiple links with multiple prefixes make MD very > > > > complex. > > > > I think we'd better have more clear understanding. Maybe at DNA. I wish you > > > > participate at & contribute to DNA meeting at Minneapolis. > > > > > > > > > I looked at your draft, it is a very clear and accurate description of the > > > > > current issues with RAs w/ regards to using them for movement detection. > > > > > > > > > > Section 2.3: > > > > > " It may useful to assign S bit, in the case where we want nodes to be > > > > > able to determine that they have received a solicited router > > > > > advertisement. With S bit, a node can confirm reachability with only > > > > > RS/ RA exchange." > > > > > > > > > > A new bit is not needed here. If the RA is sent to a unicast destination > > > > > IPv6 > > > > > address that is local to the MN, that is sufficient. But, the router will > > > > > > > > I agree with you. But can we use it to confirm bi-directional reachability? I > > > > hope > > > > WG will decide so. > > > > > > > > > probably send the RA to a multicast destination address (when solicited by > > > > > RS) > > > > > because that's what RFC-2461 recommends to do. > > > > > > > > > > Section 3.1: > > > > > " We propose to assign a new bit (Complete bit) in RA message to > > > > > indicate its completeness. When Complete bit is set, it means the RA > > > > > contains all the options (including all the Prefix Information > > > > > Options)." > > > > > > > > > > Well, this doesn't fit too well with frequent RA beacons + MN Eager Cell > > > > > Switching. In that case, you want the RA to be as small as possible while > > > > > still supporting MN Eager Cell Switching, i.e. R-bit option is probably the > > > > > > > > I agree that it's not a good idea to send Complete RA constantly. It may take > > > > too much bandwidth. I think we'd better send Complete RA only when it's > > > > beneficial, for example when a RS is received. > > > > > > > > Thanks for your kind words. > > > > > > > > Would you put your comments in IPv6 mailing list and bring this discussion > > > > out, > > > > so that other people may be infomed and join it? > > > > > > > > We requested chairs for time slot at Minneapolis and it'll help us if there is > > > > a > > > > thread about it. We had asked at SF but denied for the lack of interests. :-( > > > > > > > > Thanks for your kind words and see you at Minneapolis. > > > > > > > > Best regards > > > > > > > > JinHyeock Choi > > > > > > > > > > > > > > > > > > > > > JinHyeock & Greg - > > > > > > > > > > Actually, the link identifier option draft would resolve this issue, also. > > > > > The > > > > > MN uses the RA to detect movement (assuming L2 triggers are not available). > > > > > A > > > > > change in link identifier in the RA is enough of an indication that movement > > > > > has occurred. > > > > > > > > > > I looked at your draft, it is a very clear and accurate description of the > > > > > current issues with RAs w/ regards to using them for movement detection. > > > > > > > > > > Section 2.3: > > > > > " It may useful to assign S bit, in the case where we want nodes to be > > > > > able to determine that they have received a solicited router > > > > > advertisement. With S bit, a node can confirm reachability with only > > > > > RS/ RA exchange." > > > > > > > > > > A new bit is not needed here. If the RA is sent to a unicast destination > > > > > IPv6 > > > > > address that is local to the MN, that is sufficient. But, the router will > > > > > probably send the RA to a multicast destination address (when solicited by > > > > > RS) > > > > > because that's what RFC-2461 recommends to do. > > > > > > > > > > Section 3.1: > > > > > " We propose to assign a new bit (Complete bit) in RA message to > > > > > indicate its completeness. When Complete bit is set, it means the RA > > > > > contains all the options (including all the Prefix Information > > > > > Options)." > > > > > > > > > > Well, this doesn't fit too well with frequent RA beacons + MN Eager Cell > > > > > Switching. In that case, you want the RA to be as small as possible while > > > > > still supporting MN Eager Cell Switching, i.e. R-bit option is probably the > > > > > only option needed in the RA beacon. So, I do not like this proposal, but I > > > > > do > > > > > like "3.2 RA with Link Identifier Option". [LinkID] seems like a very good > > > > > solution. > > > > > > > > > > Thanks. > > > > > - Ed Remmell > > > > > Elmic Systems, USA > > > > > > > > > > > > > > > > > > > > ______________________________________ > > > > > This E-Mail was sent with MailMax/WEB. > > > > > http://www.smartmaxLR¿¬(®H§‚ 躙šŠX§‚X¬¶*oê'~ŠàÙ¢ž+-«b½ä^ªç¬¶Èm¶›?ÿ 0Ö'~Šàþf¢–f§þX¬¶)ߣø©¿
