Last Modified: 2005-06-27
| Done | Submit to IESG Goals for Detecting Network Attachment in IPv6 | |
| Dec 04 | Submit to IESG Existing Link Layer Hints Catalogue | |
| Feb 05 | Submit to IESG Recommendations for Detecting Network Attachment in IPv6 | |
| Feb 05 | Submit to IESG DNA solutions for IPv6 Framework document | |
| Apr 05 | Submit to IESG Protocol Enhancements for Detecting Network Attachment in IPv6 | |
| May 05 | Close or Re-charter WG. |
|
IETF 63 dna wg meeting minutes
============================== People referenced in minutes ============================ Greg Daley (Greg) Pekka Nikander (Pekka) Suresh Krishnan (Suresh) Alper Yegin (Alper) Erik Nordmark (Erik) James Kempf (James) Keith Moore (Keith) Sathya Narayanan (Sathya) Nicolas Montavont (Nicolas) Christian Vogt (Christian) Brett Pentland (Brett) Gabriel Montenegro (Gabriel) Pascal Thubert (Pascal) JinHyeock Choi (Jin) Hesham Soliman (Hesham) Jim Bound (Jim) Rajeev Koodli (Rajeev) Vijay Devarapalli (Vijay) Thomas Narten (Thomas) Introduction and Agenda - Greg ============================== Pekka stepped down as chair of DNA. Suresh is new chair Assumptions regarding the session ================================= People in the room have read the drafts. If not already read, they should read at least the solutions documents now. Reminder regarding BCP79 Agenda ====== * Discuss WG documents and open issues * Fast Router discovery * Assess solution progress * Pick link identification scheme and perform a consensus call * DNA relocation * DNA and fast handover interaction * Fast RA will be covered if we have some time Document Status - Greg ====================== * WG is behind on all milestones. * First cover the milestones for which we already have WG documents. We need review of these documents * Link information draft can be Last Called after resolving comments received on the mailing list * Hosts BCP and Routers BCP need additional review inside the WG. * CPL needs external review. * Solution framework document received a bunch of comments. * We need a single solution document out by the end of August or beginning of September Link Information Draft (draft-ietf-dna-link-information-02.txt) - Alper ======================================================================= Addresses comments from Pekka Savola and Bernard Aboba. Major change is addition of ethernet section contributed by Greg A new non deterministic link up has been added by the use of the R(isk) flag. Alper wants to know whether the extended model with non deterministic link up needs to be supported. The alternative is to wait for 100% assurance before sending link up. The authors think the non det link up might have some utility for certain host stacks Erik wants to know if the non deterministic link up will be followed by a normal one. Alper believes it will be. Erik thinks it might be useful as a host can send an RS on receipt on each of this link up triggers to speed up the receipt of an RA. Alper agrees and also mentions that this is not mandated (It is a MAY). Authors think that the document is ready for WGLC and the chairs agree. DNA with unmodified routers (draft-ietf-dna-cpl-01.txt) - Erik ============================================================== Number of RAs to wait for before declaring the prefix list complete has been reduced to 1 from 3. Absence of link up indications causes some issues. e.g. a single candidate link object might contain prefixes obtained from solicited RAs from one link and unsolicited RAs from another. Erik wants to know if the document should address issues due to flash renumbering or just mention that is is not desirable. James thinks that it easier to just mention the problem and not try to come up with a complex solution as it is not so frequent. Keith thinks that two assumptions made in the document are dubious. 1) Every network has a router. 2) you can name a network using one of its prefixes. He thinks that this is a model of an explicitly managed network where a human can avoid doing stupid things. MANETs and other ad-hoc networks do not follow this model and this should be made explicit in the document. Erik agrees with Keith and believes that CPL should not make things worse for Neighbor Discovery than they are in absence of a DNA. Erik also wants to know if anyone has an opinion on how many RAs to wait for before declaring is the number of RAs to complete. Nobody comes up with one. Greg wants to discuss further issues on the list. Solution framework (draft-ietf-dna-soln-frame-00.txt) - Erik ============================================================ Tried to describe how this will interact wil DAD and MLD. The discussion now exists in other drafts as well. Greg wants to know if this should become an INFORMATIONAL RFC or stay as WG document while the solution process progresses. Erik thinks that if it becomes an RFC, this will become a snapshot of where things started off and it will not be too useful. Sathya mentions a discussion at the last IETF meeting about documenting the design discussions from the DT in a draft. This would explain why the design choices were made and why some solutions were dropped and some were not. The WG agreed to do this but there is no document yet. Erik thinks that this document would be good to have but is not the highest priority. The protocol document is more important. Satya thinks it is not wrong to publish it after the protocol document, if it just a record of why the DT made the choices it made. Greg will check with the prospective authors and ADs on how to proceed with the document. Router BCP (draft-ietf-dna-routers-00.txt) - Nicolas ==================================================== Has become a WG document. Resolving comments raised by Brett and Martin Dunmore. Analysis of response time and RA rates moved to Appendices. Three remaining issues. 1) The number of routers on a link is currently limited to 3. It is a compromise between bandwidth consumption and robustness. Is it enough if we just mention the tradeoff or should we limit the number of routers on a link?Greg wants to discuss this on the list; Christian wants to know how the delay to acquire an RA is affected by limiting the number of routers. Greg mentions that with 3 routers the delay is 125ms on average 2) Disjoint administration: Routers managed by different entities existing on the same link. Is this scenario realistic? Should this scenario be illustrated with concrete examples James thinks that this is pretty uncommon. Routing infrastructure could be run by someone other than the access. He is not sure if it an issue. Keith does not agree that all routers on a link will continue to be managed by the same entity in the future. Erik mentions that IPv6 routing will not work in this scenario if ingress filtering is in effect. He believes there are other ways to share infrastructure in a coordinated manner such as 802.1x with vlans, different ssids etc. Gabriel thinks that SEND can be used for selecting the right router and establishing trust. Greg mentions that Router->Router relationships are not covered in this document and wants to know if that is an issue. Pascal believes that mesh networks will make this scenario possible. He thinks it is a good idea to include source address selection policy in this document Erik wants to know how this will work with shim6 and Greg does not want to solve this issue yet. Nicolas wants to know if SEND should be recommended in a BCP document. He is concerned about the added latency. James believes the latency could be minimized by using 802.21 IS to acquire certificated before handover. Alper thinks that since DNA does not need SEND, SEND should not be mandated. James does not understand what the issue is. Erik agrees with Alper that SEND and DNA could be decoupled since they are orthogonal, and would like to mention SEND as a good solution in the Security considerations. ACTION: Need replacement text from authors and get reviews done by the people who commented. Hosts BCP (draft-ietf-dna-hosts-01.txt) - Sathya ================================================ Included comments from Subba and Erik Added a section on DNA steps to improve the flow of the document. Simplify text to say there needs to be a mechanism to detect link change and to not specify how. ML discussions indicated that it is OK to leave reachability detection in the draft. Too much unnecessary information in the draft. Shorten the hints section. Greg had already cut this short. Are the following sections too long? * Section describing configuration that needs to be invalidated on link change * Section describing complications to DNA * Security considerations Greg wants more people to read the draft and believes that with sufficient internal and external review the draft will be ready for WGLC. FRD (draft-jinchoi-dna-frd-01.txt) - Jin ======================================== This mechanism is used to deliver an RA with minimum latency on reception of a link up trigger (say 802.11/16) A router cannot usually percieve link up but the PoA-Point of Attachment (802.11 AP or 802.16 BS) does. PoA cann either trigger the AR to send the RA (RA Tiggering) or send a cached RA (RA Caching). The RA is delivered to the unicast link layer address of the host. Delay between Layer2 association to receiving RA is on average 1.3ms 1.1-1.8ms. The scheme is suitable for network initiated DNA and hence is Cellular/Mobile network friendly. The scheme is not widely applicable but it works very well where link layer support is available. The authors request to make this INFORMATIONAL RFC to be able to send to other SDOs (WiMax, IEEE etc.). Greg clarifies that making this an INFORMATIONAL RFC may not necessarily facilitate adoption by other SDOs. Jin mentions that the version of 802.16 deployed in Korea(WiBro) plans to send RA in the same way Greg thinks that this is likely to be deployed in the real world and the WG could provide input to get the solution right. He wants to know if the WG is interested in working on this? Erik thinks that this is an useful option when the APs can be modified and not otherwise. James believes that interest of other SDO's should not be a justification to accept this as a WG document, He is worried that the SDO's don't really back up/correlate the info. He is worried about the cached RAs having limited lifetime. Keith believes that examples of documenting using L2 support to speed up delivering of an RA is a good thing. Rajeev believes that this is useful but is worried about consistency issues between the L2 and L3. Pascal thinks that a AR->AP control channel is needed. Suresh belives that 802.21 MICS or RA triggering can be used. CONSENSUS CALL: Anyone object to adopting this as a WG doc? (No objection) Document becomes a WG document. DNA Solutions ============= James wants to know if the WG has decided to use fastRA for delivering the RA. Greg mentions that it is the only contender but is willing to discuss it further on the mailing list Both the DNA solutions have been implemented and they are both known to work. The WG needs to pick one to proceed further. The emphasis of the solution is to be more holistic rather than detailed. Solution 1 ========== Solution 1 (draft-pentland-dna-protocol-01.txt) - Brett ======================================================= Link identification scheme for this solution has two parts -> 1) Landmark: include prefix in RS to ask whether it is still on link. Routers having complete knowlege, can answer with a Yes or No answer. This results in a Small RA when there is no link change. -> 2) Fallback to CompleteRA: Routers Already monitor the link for prefixes. Prefixes configured on the routers are announced with PIO and the prefixes not configured on the routers are announced with a new DNAO. In the most common case all routers on the link would advertise the same prefixes and there would be no additional overhead due to CompleteRA. Pros * Works well with legacy devices. * Causes Immediate build of CPL * Results in small RAs when link does not change * Rate limits unicast RAs * Complete synchronization between routers is not required. All that is required is at least one overlapping prefix between different RAs. The presence of at least one overlapping prefix implies that there is no link change. Cons * RS needs to be modified * Using the previous prefix exposes link (can avoid LO) * DNA0 size is theoretically unbounded but CPL can be a fallback if all prefixes cannot fit inside the RA Greg wants to know how many people in the room have read the document. (About 15 hands). How many plan to read it next week (A few more hands). Greg would like more input on the docs Solution 2 (draft-jinchoi-dna-protocol2-01.txt) - Jin ===================================================== Link identification is performed by comparing 2 links to see if they are the same. Linkid differs from landmark because there is only one linkid per link but there can be multiple landmarks per link. Smallest prefix on the link is picked as linkid. RAs have a 'I' (LinkID) bit set for this prefix. Graceful linkid change can be performed using linkid prefix list and linkid lifetime. This scheme takes 600ms to achieve synchronization when prefixes are being added and deleted on the link. The host has never made any wrong decision in any tested scenario. Pascal wants to know if this solution supports Point-to-Multipoint networks. Jin says it does not. Keith thinks it is very useful to have a linkid but does not believe that it has to be an address prefix. He also thinks it is better to pick the most stable prefix instead of the lowest as the linkid. Hesham wants to know if both LinkID and Landmark can be used together. Greg says they can be. Then Hesham wants to know what the difference is? Jim and Jin clarifies that Landmark requires RS first. Greg mentions that he has done some research that proves that LinkID and CompleteRA perform identically in case of movement between DNA links when the routers are up-to-date. Jim will object to proceeding with Landmark as he believes linkid converges faster. James thinks there is not much of a difference between the two schemes. Until the end of the dt discussion the dt had consensus on Landmark but Jin pulled this out at the last moment. Jin mentions that he was always for LinkID and he never supported Landmark. Brett also mentions that the schemes are quite similar. The trade-off is that completeRA takes more bytes but is faster when moving frm non-DNA to DNA (since the host can make the CPL immediately). Landmark/CompleteRA is also quicker in the non movement case. Jin wants to know if completeRA is as good as LinkID, why landmark is needed? Brett mentions that it is just a Optimization. Erik reminds people that hosts need to keep track of multiple linkids in case of renumbering. This was mentioned in version 00 of the draft but removed in version 01. Agrees with Keith that the linkid need not be a prefix in order to be applicable to unmanaged networks. Hesham mentions that a subtype can be added in the option with variable length to carry arbitrary info. Jim would like to merge the two proposals but needs more time to make the decision. He wants the chairs to wait and not force a choice today. Comparison of link identification schemes (Time and Space) - Sathya =================================================================== * Both schemes are very simple. Convergence times and and RA processing times are similar (order N) * Both solutions requires all the routers to learn the set of all prefixes on the link * Both solutions implicitly requires all the routers to use the set of all prefixes on the link as the link id. The difference is the representation of the identity in the RA messages. * Backward compatibility goal may differentiate the two schemes Erik wants to know if the comparison is based on -01 versions of documents. Satya says it is but it is also based on the fundamental design choices Erik mentions an issue on LinkID(#7) about whether a LinkID can be present in the RS. With this linkid looks very similar to landmark. He is worried that people are arguing just about the names. Satya clarifies that he is not portraying LinkID in a bad light and he believes that solution 1 has an advantage because of the completeRA component rather than the Landmark component. Greg agrees with Erik and the picked solution is only the starting point for the evolution of the ultimatesolution. Pro for LinkID: Smaller RA size and better handling of change in prefixes Pro for Landmark: Works better between DNA and non-DNA networks Erik believes either solution can be picked and changed to use the positive characteristics of the other. Hesham agrees with Erik. Since the difference is negligible. Jin wants to point out that an RS maybe required for soln 1 for large number of prefixes, as completeRA may not work with large number of prefixes. Rajeev thinks that landmark may be more conservative this needs to be taken into account while computing space/time. He also wants to know about load balancing. Greg mentions that the load balancing is performed using fastRA. Sathya believes that backward compatibility is an important goal(9). CompleteRA ties all the prefixes and is the differentiator of the solution. Hesham agrees that it is a important goal but thinks that 2461 does not require the routers to store other prefixes and hence cannot be a 'Yes' for CompleteRA. Greg clarifies how this works when a host moves between from a DNA link into a non DNA link. Hesham is satisfied. Jin mentions that CompleteRA has made wrong decisions in a corner cases. LinkId has not made even one wrong decision.Erik explains how linkid can make a mistake (A new router is connected to an AP to which the host moves to, but the router picks a different linkid than the other routers in the network). Both schemes have problems detecting a link change when it actually has not occurred. Jin agrees with Erik. Pascal will vote for neither. CPL is a big requirement (?) and is not always feasible and he would like some recommendations about mobility. Alper is worried about the conditionals in the comparison table. Greg mentions that the conditionals are immaterial when the number of prefixes is less than 30. Erik does not think the differences are big enough to argue about. He thinks that it is important to move forward and not argue about corner cases. Hesham thinks point 9 is the tie breaker and he favors completeRA because of that. Greg will ask some questions but is not ready to do a consensus call Pascal is there any difference in getting RA depending on the scheme. Greg says they both use the same mechanism to acquire an RA (fastRA) and hence do not differ. Vijay thinks that the chairs can get a sense of the room today but the can confirm the consensus call on the list. Vijay thinks the solution should be picked today if the WG is comfortable making that choice. Suresh clarifies that the proposal picked by the WG today is only the starting point for the solution and not the final solution. QUESTION 1: Do people understand enough about the solutions to make the consensus call? Yes: 25 hands No: 5 hands SENSE OF THE ROOM: (WG believes that it can make a decision) QUESTION 2: Which solution should the WG choose as the starting point of the link identification solution? a) CompleteRA/Landmark: 16 hands b) Prefix Linkid: 17 hands There is NO CLEAR CONSENSUS for either link identification scheme c) Can live with either solution - 19 hands d) Who has strong preference for one solution and cannot live with the other - no hands Thomas thinks the right question is ask is "Does the WG think whether we can get to right solution irrespective of the starting point." QUESTION 3: Does the WG think whether we can get to right solution irrespective of the starting point? yes - 25 hands no - 1 hands There is CLEAR CONSENSUS that the WG can come up with the right solution irrespective of which scheme is used as the starting point. ACTION: Chairs will pick an editor(s), get them to write a document and work out the details on the list. (OUT OF TIME) |