IETF 67 DNA Working Group Minutes Monday, November 6, 2006 1300-1500 Afternoon Session I Room: Harbor Island III Chairs: Greg Daley (not present) & Suresh Krishnan Minute taker: Shinta Sugimoto Jabber Scribe: Alex Petrescu Agenda - WG documents walkthrough - Discussion of DNA protocol document - FRD document status update * WG documents walkthrough a. DNA protocol version 03. WG needs review. Volunteer is b. Fast router discovery document. A few issues raised. c. DNA Link information. c. Link Information Document - A couple of issues were raised by Jari Arkko and Bernald Aboba - Changes: Removed normative language descriptions towards SDOs. Add a new security consideration section. JA: Did you submit the document(link information document)? SK: Yes. JA: I would like to see Bernald agree on the bridging issue. Other parts seem to be fine. * DNA protocol document Sathya Narayanan introduced the changes from the previous versions. JC: Question about Step #9. Does the link information include reachability status? Assume an NC entry indicates reachable and the host performed DNA. If the result tells that the link has not been changed, would the host restore the state to reachable? SN: Yes. JC: Landmark Option with N-bit is no longer used? SN: Will talk about this later when we discuss open issues. Open issues #1 Increasing MaxRtrAdvInterval JC: Wrt the value of MaxRtrAdvInterval, should we increase the default value (3 times of current value)? EN: Probably going in wrong direction. The reason behind this number is a concern that we are relying on prefixes. If we want to solve this issue, we don't want to hold old information forever. A prefix may be assigned to different link quicker than the prefix would have been expired. If we want to solve issue #2, we need something else than #1. Maybe explicit notion of timestamp and so on. Holding it longer would be a bad idea. TN: It's not clear what problem does the document is trying to solve (by changing the MaxRtrAdvInterval). The goal is to optimize the case where you move and recover quickly? EN: Yes, the target problem is to optimize the quick renumbering/move. But the problem is you don't have reliable indication of losing your connectivity. In 2461 default timers for address are very long (e.g 7 days) so you cannot rely on those. The idea is don't keep them long because you never know if its still valid or not. TN: In DNA for IPv4, we did not optimize this feature. A DHCP client would hold the list. EN: In IPv6 case, there are multiple prefixes/addresses. Even if a given prefix is still there, it does not assure that all the other prefixes are also there. Complicated. We need to have some sort of robust mechanism. Issue #2: Should we mandate router to include at least one prefix in RA? JK: The case of issue #2 (no prefix is advertised on a given link) could be possible. Network operator may want router to send RA to serve as default router and address assignment is served by DHCP. So mandating the router to include prefix does not matter in the case of DHCP. SN: It was mentioned before that DNA solution would be different in stateless and stateful scenarios. We are talking about stateless scenario where DNA can be used to detecting the link change. For stateful network, another mechanism would be needed. JC: Even for stateful case, I think mandating the router to send RA with L-bit set is fine. It makes the DNA useful. JC: Think that the flow chart should be applicable for stateless scenario and not for the stateful scenario. SN: Do we all agree that we remove any dependency on DHCP and mandate the router to include at least one prefix which is LinkID prefix. (no objection was made in the room) Agreement: Mandate router to include at least one prefix which is LinkID prefix in its RA. Issue #3: Need for Y/N-bits in Landmark Option JC: Landmark is selected by DNA host prefix list, right? SN: Yes. JC: It may be possible that Landmark prefix is invalid. EN: You end up facing the same problem. You need some other mechanism that does not rely on prefixes but for instance random numbers. Maybe random number and timestamp that each router on a link agree, something which will not be reassigned. JC: Think that the interval of RA (30 minutes) is too long in cellular case. Cellular operator probably don't want to wakeup terminals in every 30 minutes. Suggest to make it 3 times longer. SK: But it still does not solve flash renumbering issue, right? We can get a false negative for the link change. EN: Host need to know the number that the router is using (the interval). HS: How would the router inform hosts of the interval value? How do you ensure that the behavior is compatible with existing implementations? In 2461bis, we discussed this issue and we reached to a conclusion that 50 minutes. If you go beyond that, you can make it backward compatible. How would you account for existing host? SN: Existing host would not perform DNA. So don't think it's a problem. Backward compatibility that we care is that DNA host should still work on legacy (non-DNA) link. EN: Just incrementing the value (MaxRtrAdvInterval) at the router side should not cause interoperability problem because a host can reject the value if it thinks too long. SK: But the problem is that host has no knowledge on the interval value. EN: Yes. Router should tell the host max RA interval. Adding another option to RA. SK: Ok. SN: If there are multiple routers on a link, MaxRtrAdvInterval of each router may be different. So, we recommend to use the largest interval. Everyone agree? (yes) Agreement: Extend RA to have an option for the router to inform host of maximum RA interval (MaxRtrAdvInterval). If there are multiple routers on a link, recommendation is to use the largest interval among those. Need for Y/N-bits in Landmark Option is questionable. N-bit is not used in the current spec. EN: Semantics of getting a Y answer back is that router has your RS. If a router receives multiple RSs with Landmark Option, it may respond with a single RA with a Landmark Option. So host may not know if its RS made it to the router. JC: Response of Landmark Option is sent by unicast. If the host sends RS with Landmark Option, it uses optimistic address with tentative option. Response will be in unicast. Hence without Y-bit host still can know if its RS made it to the router. EN: Other thing we can do in format wise is to get rid of Lanmark Option. All we want to do is to include a Landmark Prefix in an RS so that the router could tell the host that you are still in the same link. SK: What do we gain from removing the Landmark Option? Simplicity? JC: With the Landmark Option, we may include an information which is not prefix. Link identifier may be included in a Landmark Option. EN: LPIO can be something other than prefix too. LPIO could be a link identifier option. SN: Is there any objection to remove Y-bit? (No consensus was sensed in the room. Will take it to the list) Issue #4: Constant value vs. configurable parameter There are a few variables in the document. Should we make it constant value or configurable? TN: Against for making it configurable. Majority of devices are not touched by users or should not be touched by users. If we need to require users to touch the configuration, we may not have done our job properly. So recommend to define constants. SN: Ok. TN: Variable configuration for cell phones. Agreement: Be more conservative about the treatment of variables. Make them constants. Configurable case is only when needed. Issue #5: Terminology TN: Some informative references addressed in the draft are expired. Think that definitions are normative (rather than informative). If the terms are needed, make them normative. If not, just get rid of them. SN: Ok. Will take a look at the draft. Issue #6: MaxCacheTime Do we want to keep the idea of making use of prior information which is valid during MaxCacheTime? SN: Do we want to keep this idea? Or is it outside the scope of DNA? In some scenarios (e.g. CARD, FMIPv6) it might be helpful. EN: Don't think the optimization buys us much. There might be future optimization to avoid sending RS based on characteristics of a given L2 link. No need to define it in the base protocol. Agreement: Remove MaxCacheTime. Issue #7: Storing old LinkID list There are two similar lists defined in the document: DNA Prefix List and DNA LinkID List. No texts how they are maintained when a host is moved to new link. SN: LinkID single list or list for each link? EN: Could it be one list? TN: Think right direction. A link is a conceptual object and there are some information associated with that. Naming the object is difficult. SN: Main advantage of maintaining the LinkID list is forward compatibility in future you may have a link which is identified by non-prefix based LinkID. EN: You can still do that with maintaining a single list. Each entry can have type. Most of them are prefixes. SK: Quite a few people from outside the working group said that there are non-prefix link identifier. We should not make decision now. We should hear the opinions on the mailing list. MANET and AUTOCONF people are interested in it. Issue #8: DNA without link up notification Text from CPL. If DNA solution assumes notification from L2 If there is no indication from L2, what to do from CPL point of view? HS: Distinction between link-up and interface-comes-up should be made. The two things are different although both events trigger the DNA. JC: The current link information draft describes the event "link up notification." Do you mean that we should change that? JA: Other document talks about link information indication. If there is something concrete that we should look at, let's look at that. If not, we should ignore it. SK: The link information draft does not make the distinction. It says that when link is up, L2 connectivity is established. HS: Think that distinguish should be made. At least a document should mention that "link up" is a conceptual event that covers both events. JC: Don't think the section is needed. We can remove the "DNA without link up notification" Erroneous prefix list section. SN: Let me check erroneous prefix list section again. JC: Think that "DNA complication" section can also go away. Agreement: Sathya will ask ML whether it's OK to remove the "DNA without link up notification" section and decide if we want to keep it or not. Issue #9: Section titled "Initiation of DNA procedures" Do we want to keep the section? JC: Think that the section can go away. "DNA complication" section too. Agreement: Remove the section titled "Initiation of DNA procedures." Chair(SK): Anything we discussed in this meeting and thought we made decision will be sent to the mailing list for confirmation. Anything which was not said strongly should be decided by the mailing list. Everything needs to be confirmed on the mailing list. Proposed schedule SN: Next revision by Dec 15. Another revision by Feb 15. Need reviews. Need fresh eyes for reviewing the documents. JC: Issues raised in this meeting should also be resolved. SN: Let's start the discussion on the mailing list so that the issues can be resolved soon. * FRD (Fast Router Discovery) Draft: draft-ietf-dna-frd-02.txt JinHyeock Choi updated the status of the document. JA: Clarification. You said on the ML that you move the part (about scanning section) to an appendix but do you now agree to remove it completely? JC: Yes. JA: About multiple mechanism. Want to see if the WG comes to a consensus on smaller set of mechanisms. Agree that they are different scenarios and have different tradeoffs. But all these seem rather short terms. If we have a good recommendation from IETF in this space, that would affect what people deploy. Upgrade the routers if one need quicker router discovery. I really care what the solutions are. And I prefer reduction of number of the solutions. JC: Agree. Will reduce the number of solutions. TN: My personal opinion is that this WG should focus on the merged document exclusively. Don't want to spend time on other documents until the main document is done. JA: Agree with what Thomas said. Don't issue WGLC should not be issued (for other documents) until the main document issues are done. Abbreviation of name of the people on microphone: JA: Jari Arkko SN: Sathya Narayanan JC: JinHyeock Choi EN: Erik Nordmark HS: Hesham Soliman SK: Suresh Krishnan TN: Thomas Narten