Softwire WG Agenda IETF 89 FRIDAY, March 7, 2014 0900-1130 Friday Morning Session I Minute taker: Ole Troan, Cong Liu 1. Agenda Bashing, WG & Document Status (Chairs) 5 minutes No comments. 2. Lightweight 4over6 WGLC discussion - 30 minutes, Ian Farrer Presenting Three open LC issues discussed: 1. Fragmentation and ICMP handling 2. interface and prefix selection 3. Cross reference to MAP-E draft Ian: Suggests adding DCCP reference for RFC5597 to MAP Ole: Separating DHCP option text and specification draft. Either way will work, as long as it is in sync with the MAP-DHCP draft. Suresh: Remove the text of cross reference all together Wojciech: I'm fine with option 4, but I prefer the proposed new wording that rationalises the existence of these two drafts. Suresh/Woj: What should be added to MAP-E? Woj: The same text in 'reverse'. Suresh/Ted/Woj/Ian: Discussing cross-references. Qi Sun: I'd like to remove the text. I don't think it should be there. Suresh: If you fight over small things, it will delay the draft. Suresh/Qi Sun: Trying to understand "why" Qi wants to take the text out. No answer. Ted: I think we're stuck here. It is difficult to get consensus on, giving that it is a layer 9 thing; it is useful to have guidance but I'm not sure this is good guidance. Just say what you think on the IETF mailing list, and that goes into the IETF consensus process. IESG is going to consider both of this documents at the same time. If you throw it at the IESG you can end this discussion now. There is a really good chance of the IESG wanting to change it. This is going to be argued over in the IESG anyway. Suresh: Not convinced. If we don't even have this text. If the text is there then a larger section of the IESG may not ask for it. Ted: You're thinking of the number of discusses are going to increase this. Suresh: I don't want the document to come back to the working group. Ted: The IESG may refuse to do this, but we have talked about this before. If the working group cannot agree on a solution lets do two solutions. I don't think they'll require Tom's document. Then we can do Tom's document later. If they require text then let them propose text. Ted/Suresh: Ensuing discussion on cross-reference text. Woj: We're deferring this to the IESG. Ted: I think the reason is, this is marketing text. It is uncomfortable to hear "this is the advertising" of what your draft should be. Suresh: Proposing alternative text: Remove "marketing" text. Just state what MAP-E does with algorithmic mapping. Bernie: Leave it in it is useful. Simon: Did we agree to have the same text in both drafts? Woj: Same text, but it has to be reveresed? Simon: Same two paragraphs in both drafts? Ted: The only thing different would be the reference. Ole: Drop the text. It doesn't represent the output of the working group anyway. Brian: Write an applicability statement. Suresh: It is a little more complex, since the solutions are overlapping Brian: Write some applicability statement later. Ted: What Brian said. Applicability statements. It doesn't give enough information to make a decision. This text isn't sufficient to make a decision and have to read both documents anyway. I agree with Ole it isn't important to put it in. Woj: There are no other text in any of the other drafts, explaining what the characteristics of the methods are. Bernie: This is just intending to inform the reader about the other option. Suresh: The only options is either 2 or 4. Consensus call on the list. Ian: Also add the reverse text option. Woj: I'm still kind of upset, what's the rationale to the objection of this text. Suresh: Two options on the table Ted: You cannot make a statement... the only basis for a consensus is a vote. Ole: Coin toss Ted, Suresh, Wojciech continues how consensus can be determined. Ted: If you do this as a vote it sets a bad precedence. Woj: This text helps contextualize the mechanisms. Ted: The WG shouldn't have a coin toss, because your interpretation is correct. Suresh: As a chair, adding or removing this text does not change the document. That can be coin toss. Either of them makes no difference for interoperability. Qi: I'm OK with option 1. Guilamme: I'd like an applicability statement anyway. Suresh: Qi, I have to pick on you. What are you objecting to? Suresh: Qi: Propose text. Ted: Why was the original text added to the draft? Woj: The original text motivated itself by pointing out problems with the MAP draft. Summary: ***Suresh: 3. Cross-reference: As chair I'll decide that we keep the text with the proposed changes. MAP does aggregation and mesh. Qi to propose new text. 1. Fragmentaiton/ICMP: Agreed on mailing-list. 2. Ian: Solution agreed on mailing list. Ian to post new text. Do another short 1-week LC again MAP-DHCP: Ole and Ian to update MAP-DHCP ready for WGLC. Ian: Clarification: What's happening next? ***Suresh: All documents LW46/MAP-E/MAP-DHCP done through IESG at the same time. Ted: Prefer to also include 4rd, MAP-T as well. 3. MAP-T WGLC discussion - 20 minutes No discussion. 4. 4rd WGLC discussion - 20 minutes No discussion. 5. DS-Lite Failure Detection and Failover - 10 minutes, Jing Huang Ian: Clarification: AFTR may use anycast, how does that work with a stateful CGN? How does the anycast work in this case? Ales: Detecting AFTR failure? What kind of failure are you detecting? You aren't checking a tunnel, but you are checking the AFTR state. Branimir: Clarification for the anycast? It defies the point of anycast. Ole: The draft states why anycast can't be used in this scenario Ian: Question if you can add multiple AFTRs in DHCP option, how to reinstante NAT state when moving from one AFTR to another. Ole: Compare to how 6rd does it? Cong: What's the preference of the 3 solutions? No WG action 6. Radius Extension for Lightweight 4over6 - 10 minutes, Cong Liu Roberta: Why do we need two different ways of doing RADIUS for LW46 and MAP? Author: You are suggesting a unified RADIUS document? Roberta: Only asking why we need two? Can they be combined? Qi Sun: Different requirements for RADIUS. Sheng: The scenario of this draft is different than the current working group draft. Both IPv4 and IPv6 address come from the RADIUS. The scenario is different. ??/Qi/Author/Roberta: Architecture discussion ensues. No WG action 7. Recommendation for Prefix Binding in the Softwire DS-Lite Context - 10 minutes, Qi Sun Erik Kline: What is the relationship between this client prefix attribute and the information that would be handed to the client in a DHCPv6 PD? Suresh: Clarifying question. Qi: It is for the AFTR to restrict how many translation entries can be used. Erik: It sounded to me like there is redundant information here. No WG action. 8. IPv4 Prefix for IPv6 Transitional Technology - 10 minutes, Ales Wojciech: All of the solution drafts require something like this. This is a good suggestion. A generalisation / a default. Is that correct? Ales: There is no default, this is trying to propose the default to be this prefix. Ales: This address never leaves the device Ian: In 6333 it is for troubleshooting on the AFTR Lorenzo: In 464XLAT it can be used as, it never leaves the device. Otherwise the implementation thinks it doesn't have an address. It gets intercepted and translated to IPv6. Ian: I don't think it applies to that. Woj: It could be a default? Ian: Moot point. Lorenzo: This only applies when you have no public address. Woj: It might be useful to have a default. It makes it like DS-lite CPE. Ian: If both 464XLAT and DS-lite coexists this is going to be a problem. Ole: 2 options to reolve conflict. Either in IANA registry or leave it up to the implementation to keep track. Support of the latter. Wojciech: I support Ole's suggestion for co-existence. Ian: What does the XLAT draft suggest for address? Does it require an XLAT RFC update? Suresh: Do you need another /29? Lorenzo: It would be rather unlikely to do DS-lite and XLAT on the same box. Suresh: Can we do a /28? With the /29 inside. ***Suresh: Take the draft jointly with v6ops / softwire 9. Unified IPv6 Transition Framework With Flow-based Forwarding - 10 minutes, Cong Liu Ian/Lorenzo: Asking questions on the architecture. Simon: Flow is a 5 tuple? Woj: Would there ever be a case where the CPE wouldn't forward to the BR? Could the controller 'deny' it? Lorenzo: Per flow too expensive, not useful for DS-Lite and NAT64, might be useful for MAP-E/lw4o6. Suresh: The switches are really dumb, the controller tells them what to do. Satoru: This is helpful for lw4o6 to enable mesh mode. Many: Discussing the benefits of SDN / Openflow. And on it goes...