NSIS Meeting THURSDAY, November 9, 2006 0900-1130 Morning Session I Grande Ballroom A Scribes: Al Morton, Andrew McDonald, Hannes Tschofenig Agenda Bashing -------------- John starts with the agenda and changes the order of the presentation since Dave Oran needs to switch back and forth between NSIS and MMUSIC Robert: Does the last milestone refer to an existing milestone. John: That refers to the state machine draft but it needs to cover more than just the state machine Gabor's draft on 3GPP2 requirements will be an AD sponsored draft and will get a 2 weeks review period to become RFC. Martin is talking to the 3GPP2 persons regarding extensions. Finalizing GIST - Robert Hancock -------------------------------- - update on all IETF LC comments - discussion of open issues John goes through his presentation slides. Version -11 released just after montreal lots of discuss comments: lars, security ADs, Adrian Farrel (routing area review) some easy to handle, some hard issues available in tracker will go through another wglc once ready Protocol changes - none particularly major, but -12 will be incompatible with -11 (legacy nat detection) Hannes: Is there an impact on the existing NAT traversal document with regard to the new NAT text? Robert: none at all. doesn't change interaction with non-legacy nats. about decting nats by noticing changes in header. Robert continues with his presentation and talks about technical clarifications some implementation guidance some important things that were implicit now being made explicit path-splitting issue comment from brian carpenter (in iesg review): what should nsis do where a path splits? modifications to service interface to avoid precluding the possibility of nsis understanding multiple routes for a given flow in a more complete way routing state errors security comments from sam/russ sid randomness requirement clarifications needed could you make d-mode secure? possibly, if can do out-of-band key negotiation Hannes: We spoke about this in the past and concluded that in the general space it is not possible to run D-Mode with security. Henning: It depends on the deployment environment. In some environments (dense deployment environment) it is possible whereas in other it isn't. We could craft an applicability statement but it would not make a lot of sense. Robert: this is not a protocol extension, it is a statement of possible future extensions Robert: Specification currently doesn't explain how gist manages, validates, etc uathentication identities of signaling peers. Solution: hannes will write something. Should we document the benefits of a dense deployment? Don't intend to do anything in base spec. Hannes: realistically appears in a single domain, but in that case people don't care much about security Henning: disagree slightly with hannes. even in single domain want to stop customers from spoofing messages. Internet2 might be such a domain. Hannes: I referred to a administrative domains rather than something like Internet2 which would again consist of many admin. domains. John: A description of the security aspects with regard to the deployment environment might go into the applicability document Henning: I hope that the main document is not dependent on this document. John: No. Robert continues with the slides and talks about Router Alert Options. "I Hate Router Alert" Similar concept to RSVP, Robert described the thought process. For IPv6, it looks like this should work in theory, but in practice FreeBSD and Linux implementations are really broken in this regard, and they would not work for RSVPv6 either. In IPv4, there is no registry for RAO values, semantics are vaugue. Optimistic case, need to open a registry in RFC 2113 update. should be OK, Pessimistic case, packet is deleivered to the local UDP stack, where it is discarded. Practical experience: most support optimistic scenarios and the experience says that they are valid. There are some bad actors. In general there are problems with Firewalls. Assistance: Need more tests Need people to fix implementations. Need someone to sort out RAO specs to avoid this in the future. John: Clarified that the problem needs to be fixed for RSVP as well, so NSIS can count on that. Where should this issue be addressed by IETF? Need the RAO value field to be recognized. Possibly invite router vendors to Interop events, but current testing says we're OK on this. Magnus: Need to hear from other Ads. Adrian: Concern aboyut the word Fix used with these scpes. Robert: Clarified to avoid possible misinterpretation. Adrian: Probably have to ditch UDP, RH's 3rd solution bullet. The Ignore aspects of the RAO spec need to be fixed. Henning: Concern that the non-UDP solution will not work, can't pass FW/NAT. Dave Oran: Don't be obsessed about the specs. How do we fix implementations? If NSIS and RSVP are are important enough, then people will fix the implementations. There are contingencies we can adopt/document, but initial experience says that the optimistic scenarios. Henning: we can make changes in the future, if necessary, a non-UDP encap. in the case that we get the probablilities of each outcome wrong. Adiran: the danger is to GIST itself, not to the Internet. Dave: The direction of future packet handling in ASICS is to ignore IPv4 options completely, but that's what we want: ignored if not processed. So conclude that GIST will not harm Internet, and there is a contingency for the non-UDP option if needed as a contingency. UDP encapsulation is the major advantage over RSVP. Robert talks about practical IPv4 experience: John: does this packet loss break gist? Robert: no, just means query takes a long time to time out. but, we always knew that might happen with firewalling. Robert: would be good to get more experience from others Hannes: based on an e-mail from dan wing, henning peters and christian dickmann did some tests - i'm not sure if results were sent to nsis list. particularly in dsl networks packets disappeared. Martin: probably mostly a problem of home dsl routers John: Clarified that the problem needs to be fixed for RSVP as well, so NSIS can count on that. Robert: My impression is the problems are similar or smaller for GIST. John: If people are planning to use RSVP then they encounter the same problems. John: I would like to talk to the ADs and to have some suggestions whether the Internet Area or the TSVWG about some feedback. Robert: There are consumers of the router alert option outside TSVWG as well. Roland: There were some recent changes in Linux and hence it depends a lot on the installed base. There are other problems, such as root privileges to set the RAO option. Martin: All Linux and FreeBSD implementations deal poorly with RAO. There is no good interface for the application. Robert: Someone should sort out the RAO specs. Henning: We have a chicken-and-egg problem. The number of Linux routers that are used in core routers is fairly small. We need an interopability event with router vendors (access router + something bigger) to see what really happens. Robert: We have tested major router vendors. Currently, we haven't seen problems but we have only tested IPv4. Magnus: We should fix the specs. Adrian: At the moment the implementations follow the specs. It is great to document what happens in other implementations and to change things. Don't call it fixing. Adrian: There are two things: a) A network where no NSIS support is available. We are fairly lucky since most implementations ignore it. b) The experience of RSVP showed us to drop UDP encapsulation by using another protocol other than udp to ensure correct interception. Robert: what is your interpretation of the rao value interception? adrian: treat as if zero Adrian: If you put a non-0 value in there then it would be treated as a 0 value in there. Henning: I am confused about the path forward. We had this in the spec for 3 years. Are we doing last minute changes that don't work on the end systems. Dave: don't want to ditch udp - would lose one of the beneifts compared to rsvp - gets it through nats Henning: Two types of brokenness a) we cause collateral damage - doesn't seem to be true b) we shoot ourselves in out own foot what we decide is not irreversible - if we get the probabilities wrong, can do a non-udp encpsulation need to make sure we don't prevent ourselves from doing something in the future - and i don't think we are Adrian: I understand that. My comment came quite late. We should learn from that and that's early review. David Oran: There was an early review by the Alex Zinen. David: Fixing the spec does not help to get the implementation fixed. It is up to produce something that is compelling to use. John: I would like Robert to talk to Adrian. There is a problem with RAO. RSVP would suffer from the same problems. Robert: There is a difference since RSVP has installed base. David: UDP encapsulation has any hope to get through the NAT. If you want to distinguish from RSVP then UDP encapsulation is a good thing. John: It would be good to document what people tested from real-world networks. Hannes mentioned these tests. Adrian: agree with that summary. you are not doing something that damages the internet. only risk is that break this protocol itself. dave: one danger point: the direction that the high end asics are going is to forward packets and ignore all ip options. will prevent any sort of signalled qos from working. have talked to semiconductor developers - they ignore all ip options, just forward. Finalizing QSPEC - Jerry Ash ---------------------------- - Update on latest revision - Discussion of Mandatory parameters in the QSPEC and how to achieve some level of QoS model interoperability Jerry says: people supported the need for interoperability, but not necessarily the se of QSpec-1 parameters only remapping exmple that made sense was token bucket to a bandwidth source traffic description made mandatory in form of tmod (traffic model) parameter: token bucket set Jerry continues: all other qspec parameters are optional. reservation can fail if constraint is not met (either because parameter not understood, or because of admission control failure). the additional flexibility previously considered is not useful. Henning: That sounds like the RSVP model. Dave: Identical. Jerry: It is a mathematical way to specify Henning: There are other ways to specify it but that's fine. Juergen: on this 'allowing simpler control plane' - one aim of working group is simplifying control plane. Jerry: Yes. Someone could argue that we're more complicated by stacking. David: If that was the goal then we failed a few years a ago. Jerry: This version is certainly a lot simpler than the previous version. Georgios: The E flag processing hasn't changed. Jerry: Yes. Kept the same. Roland: I like your proposal. I would also propose to remove the Y.1541 and DSTE class contraints. Is a QNE allowed to add such a parameter for local use? Jerry: We haven't excluded it. I cannot think about an example where you would like todo it. Roland: Parameters that are added where only relevant for local semantics (like in the RMD case). We thereby eliminate also stacking. Dave: If you need the funtionality of QoS domains doing particular things and to signal those things. There are three possible ways: (1) Add optional parameters when it enters the domain (Roland's suggestions) (2) Stacking (which was in the document before) (3) Recursion in the NSLP (you might not even need to include the private parameters). It might requires the input from implementers to see what protocol mechanisms provide the desired functionality. Robert: We have the third functionality for other reasons (e.g., aggregation). How much do we need the others? Georgios: I agree with Robert. We also need (2). Jerry: Maybe I interpreted Roland's proposal differently. Roland: My assumption wants that a QNI only wants to signal the QSPEC defined parameters. Georgios: We only need to decide between (1) or (2). Dave: From a protocol stand point you only need 1 mechanism. Jukka: In slide 7 you say stacking was removed and in slide 8 it shows up. John: Slide 7 just shows the proposals. The proposal to remove stacking was rejected. Georgios: We need to writeup an email, have a discussion and need to move forward. John: (3) provides everything. Georgios: No, it does not. We need (2). John: You should be able to provide the equivalent functionality with (3) without using (2). John: How clear is it to you what needs to be done to update the draft? Jerry: I hope to have consensus. Georgios: We could decide whether to use (1) or (2). Discussion between Hannes, John, Roland, Georgios, and Robert whether we can decide between (1) and (2) here. John: take to the list. will have a call for consensus and then update draft. Finalizing QoS NSLP - Jukka Manner ---------------------------------- - Update on latest revision - discussion of any open issues Jukka starts his presentation. various changes from -11 summary refreshes needed for scalability Slide 5: Robert: Clarify when it is the same. Roland: Useful when multiple sessions are deleted as mentioned by the Panasonic people. Hence, not only useful for summary refreshes. Useful to have this object anyway. Jukka: Do people that this is useful? Georgos: I agree. Jukka: summary refresh and tearing Georgios: I have only looked at summary refreshes. Jukka - Stacking: Slide 7 Georgios: I think the proposal by Roland would simplify the NSLP. I support Roland's proposal. Jerry: Which proposal do we have now? Jukka: Within the local domain we carry two QSPECs. Roland suggests to use only one QSPEC that changes. Dave: I have just sent to the list. I have a question. If you wish you have the constraint for the state machine inside the domain is congruent with the e2e SM then you can go for Rolands proposal. If you want to decouple the SM then there is an argue for decoupling the two SM for admission control. Dave: I believe you that there is an existence proof that stacking works. Georgios: We already had recursion in the past and there was no arguement about it. John: We want a clean solution and we want to see whether we can only need to have more than one solution out of the three solution. Georgios: The motivation is already given in the many emails we had. Performance increase is an example. John: You will get higher performance with option (1) and (2). Jerry: I would need examples to understand the discussions. Georgios: Stacking is different to recursion, in my opinion. If we need to make a decision then we need to answer two questions: a) Do we need recursion? b) Should we decide on (1) or (2)? John: We need examples and implementers feedback. Finalizing NAT/FW NSLP - Martin Stiemerling ------------------------------------------- - Update on latest revision - discussion of any open issues Martin is starting his presentation on the NATFW NSLP. Martin mentioned that there are two implementations. Roland mentioned that they will soon release another one. Interop Report -------------- Luis gave a report about the interop. Roland mentioned that it would be nice to have an interop in February. Luis: We have to take our students in consideratins. John: Have you documented the tests? Luis: Some tests were documented. There is, however, nothing to show. John: It would be good to document something. Remaining time, updates on other charter items roland: what is status of mobility draft? doesn't seem to cover things that I think it ought to. John: please send that comment to list. also, probably need a new editor for that document. Hannes: needs some tidying up. still a nebulous mobility object flying around that doesn't exist anywhere. needs to be removed.