NSIS WG at IETF74, San Francisco Thu Mar 26 15:10:00 PDT 2009 Agenda http://tools.ietf.org/wg/nsis/agenda?item=agenda74.html Audio ftp://videolab.uoregon.edu/pub/videolab/media/ietf74/ietf74-franciscan_a-thurs-pm.mp3 ( NSIS starts at 3h 2min 35sec ) Names, in order of appearance: Martin: Martin Stiemerling Magnus: Magnus Westerlund Jukka: Jukka Manner Georgios: Georgios Karagiannis Hannes: Hannes Tschofenig Roland: Roland Bless Russ: Russel Housley John: John Adams Scott: Scott Bradner Stewart: Stewart Bryant Tom: Tom Walsh Monique: Monique Morrow Henning: Henning Schulzrinne Lars: Lars Eggert Martin: - scribes, notetakers, note well, blue sheets, agenda [ slides http://www3.ietf.org/proceedings/09mar/slides/nsis-5.pdf ] - Status of WG documents - Status of RAO personal draft. - RAO drafts by others in routing area. Look promising. Magnus: Some other drafts in Routing Area, will probably move to INT. Martin: - GIST status Magnus: IESG telechat on april 9th will show where we will end up. Unfortunate that it has taken many years. Experimental is still possible while proposed standard of course wanted. Jukka: [ slides http://www3.ietf.org/proceedings/09mar/slides/nsis-5.pdf ] - INFO object - Discussed on the list - Should an IANA repository be created for NSLP level error codes? Georgios: Agrees with Jukkas reasoning. Is for an IANA repository. Hannes: Seems reasonable. Didnt notice the similarity earlier. Jukka: Basically just a change of the QoS error code to 8 bits. Hannes: Should the IANA code space be segmented? Jukka: Joint list of codes/class, fex Class success. List all the codes and the NSLP supports the codes it wants Roland: It is not required that all defined code points are understood by the nslp? Jukka: Correct. All must not be understood by every application. Hannes: About IESG status. Has Jukka talked to new IESG members? Groupthink behaviour by the IESG? (Use wine?) Russ: We like to approve documents. Dont count on the change to fix it though. Time has been spent discussing it. New ADs are up to speed. Jukka: [ slides http://www3.ietf.org/proceedings/09mar/slides/nsis-3.ppt ] - Extensibility draft status. - Last call asap. Martin: This doc is important - meant for people who do not know all the specs so well. Georgios: I have read the draft. Did not find any particular problems. Hannes: Why cant it be sent right away, since the "pre last call last call" was extensive. Jukka: Would a one week WG last call be enough? Magnus: A two week last call would not delay the document significantly. About the other docs; Im going to start reading them. Jukka: Ext draft to the front of the queue? Magnus: You decide. Martin: [ slides http://www3.ietf.org/proceedings/09mar/slides/nsis-4.ppt ] - Mobility draft status. - All open issues have been closed. - WGLC after next revision? Jukka: Roland has tested mobility. Roland: QoS nslp and MIP have been tested to work together. I will go through the document and see whether it is consistent with our experiences. Georgios: [ slides http://www3.ietf.org/proceedings/09mar/slides/nsis-1.ppt ] - Status of RMD draft. - Comments from Phil Eardley have been addressed. - Restart WGLC after the meeting. - Lots of comments over the years already. Jukka: Many comments over the years and some expert reviews. We can conclude the document has been sufficiently reviewed. Martin: [ slides http://www3.ietf.org/proceedings/09mar/slides/nsis-0.ppt ] - SCTP draft status. John: [ slides http://www3.ietf.org/proceedings/09mar/slides/nsis-2.ppt ] Presentation on: ITU-T (Question 5/11) liaison statement. Flow state aware qos state management. Documented as Y.2121(?) sender initiated in-band signaling. and Q.flowstatesig (available through the datatracker) Scott: The liaison statement and the Q.flowstatesig doc are available through the datatracker. Stewart: How do I know there is a signaling payload attached to the packet? It has to know the signaling field is attached to the packet. In the case of an IPv4 packet it looks like an ordinary packet, how does it know it is a special IPv4 packet? Second, how does this thing work through a NAT? John: In the absence of the blessing of the IETF we are using the experimental code field. The EXP field of the IP header. As you go through the NAT, the signaling goes through the NAT in-band. If flows are aggregated by private addresses, the system only handles it in that way. The document explains it in more detail. Jukka: havent read the doc. Does the system use data from the data flow packets? John: Yes. In the user field of an IP packet there is additional information for routers. Jukka: NSIS is a separate signaling protocol. User data packets are not touched. John: Yes, to me on reading RSVP that your in-band is more like in-path. Scott: This is a terminology confusion. In-band means different things in the IETF and in ITU-T/telephony. John: I want to come back to the question of scope. If the IETF declares it is not interested in signaling that is in packet, eventually the IETF and ITU-T might end going separate ways. Would be an undesirable outcome. Tom: I support your effort. Lets send something back to ITU-T in collaboration. Could you go through how IPv4 and IPv6 are used, what kind of changes might be needed? John: We have only considered access networks, i.e. there is not router in the path between where we send and where we receive. Allow flow state aware access boxes and end systems to interact. Using experimental fields in both IPv4 and IPv6. Protocol data in packet payload. Roland: We must understand if this fits the model of nsis? Are you really using in-band signaling? Every packet has signaling in it? John: No. Signaling packets are just embedded in the data flow. Martin: What is embedded? John: In the flow. In the flow of those packets from the ... Roland: What does the box in the middle do? What does the receiver do? John: Pull the signaling packet out, process it and forward it. The receiver pulls it out, processes it and discards it or responds to it. Roland: I did not fully understand all the details in the document. I dont know if it is a good match. Hannes: I appreciate you coming here. There is surely a terminology confusion. Would not say in-band out of band, on path off path etc are so clear. About NATs. There might not be so many on the signaling path, but NATs are mentioned in the document, carrier grade NATs etc, so there might be an issue. RSVP and other protocols dont do particularly well with NATs. Scott: NATs are addressed in the doc. I want to go up a level. In-band means such different things. Work might not continue in this WG. Might be many other places in the IETF. John: The ITU wants to move forward with its work. I invite IETF to consider where this work might be done. Scott: Agreement between ietf and itu. The ITU-T frames requirements to the IETF and IETF looks at them and decides if it will do work on them. I suggest to write an ID and ask for the specific code points. Monique Morrow: Write a contribution for July. Scott: Submit a personal ID. Does not have to go through the working group. Do it through the liaison process as well. Henning: These sound like code point issues. Sounds quite similar to D-mode in GIST. Somebody familiar with both technologies should find out. How are "special packets" marked. If one way is okay and our way is not. Do we need to send GIST to the ITU to be standardized. Does not make sense. Lars: IETF has asked for what changes to protocols and Internet architecture would be needed. This content would go into a draft. Which code points are in use? Experimental ranges are used for now? John: Yes. I didnt think there was anything else we could do. Lars: The ID would ask for real codepoints. How it would change ip and udp or tcp etc. and motivate these changes. Martin: Close mic line. Magnus and Georgios? Magnus: Nothing to say. Georgios: Are you willing to use NSIS instead of the data packet based signaling system you are using now? Hannes: We are talking past each other now. We need somebody to line up the terminology. This might well be something like D-mode in GIST. Magnus: We are going to send a liaison response, from the whole IETF. Community will get opportunity to give input. Lars: What is the ITUs schedule associated with this? John: Meeting in may and one in the summer/autumn. Scheduled to conclude at the end of this year. Jukka: Official agenda over.