Next Steps in Signaling (nsis) ============================== Chair(s): John Loughney Secretary(ies): Hannes Tschofenig Jabber scribe: Roland Bless http://www.ietf.org/meetings/ietf-logs/nsis@rooms.jabber.ietf.org/2006-03-23.html Meeting Minutes: Paulo Mendes / Andrew McDonald THURSDAY, March 23, 2006 0900-1130 Morning Session I 1510-1610 Afternoon Session II * Agenda Bashing ---------------- Slides available at: http://www3.ietf.org/proceedings/06mar/slides/nsis-6.ppt - John: GIST will be sent to Transport AD, QoS NSLP needs more discussion & a revision, QSPEC, Y.1541&RMD got only minimal review, need more review before we can progress. John says that no further work will be added to the charter if the existing work is not completed. - Henning: He suggests to have (at least) two designated reviewers being assigned to the documents. - Hannes: He suggests when people ask whether there is support for their new work they also have todo a review of the old documents. * GIST update ------------- Slides are available at: http://www3.ietf.org/proceedings/06mar/slides/nsis-2.ppt - Hannes: transport level security can be extended without hacking the document - John: John says that he wants to provide an implementation report to the IESG. Experience showed that the implementations are actually quite simple. This would make the IESG happier. * QoS NSLP ---------- Slides are available at: http://www3.ietf.org/proceedings/06mar/slides/nsis-16.ppt - John: talked to IESG, for v4 only single RAO value, so need to dig through protocol headers, IPv6 supports more values... - John: Do we want this also for IPv4? - Andrew: ACK flag - ongoing discussion - Andrew: Rerouting needs more dicsussion - Andrew: Draft needs at least one more update... - John: QSPEC stacking seems to be big issue - Jerry Ash: Error codes and QSPEC related errors also needs clarification. Also discussion on intermediate domains and mandatory parameters, reaction to missing parameters etc. * QSPEC ------- Slides are available at: http://www3.ietf.org/proceedings/06mar/slides/nsis-7.ppt - John speaks about the QSPEC and QOSM idea (and the problems that can appear in various situations) - John (talking as an individual): would like to see 'opportunistic qos reservation'. Admit the reservation where possible. Inform end hosts of the results so that they can keep it or tear down as they see fit. - Robert: Yes. Also note that we allow QoS unaware regions, so would not be good if we failed because of a region that supports some sort of QoS. - John: Other people may want to use QSpec elsewhere, so want to make sure we get it right. Hannes: QoS error conditions need clarifying. Need to clarify split between NSLP and QSpec. Interested in QSpec from Diameter QoS perspective. * Y.1541 QoSM ------------- Slides are available at: http://www3.ietf.org/proceedings/06mar/slides/nsis-8.ppt - Jerry Ash: No updates; Completed WGLC, no comments on the list. - John Loughney: So probably not 'successfully completed WGLC'. May need revisions based on QoS NSLP and QSpec discussions. - Hannes: Reviewed the document and it looks good, and only some small fixes are needed. * RMD QoSM ---------- Slides are available at: http://www3.ietf.org/proceedings/06mar/slides/nsis-12.ppt - Attila: Updates for priority handling and error codes - Attila: Final updates to NSLP and QSpec might require some updates for the RMD QoSM as well. - Attila: Received a few comments from pre-congestion notification work authors and from David Black - David Black: Quick summary of my comments. Delayed until after the non-bar bar bof yesterday. RMD is really just doing bandwidth management. Just doing EF services, probably shouldn't talk about AF at all. I also have a problem with the congestion management stuff. In particular the congestion remarking. IANA considerations section is also missing. - Georgios Karagiannis: some of the comments can be solved by clarification in text. I'm not sure if we can solve the remarking comments explicitly. We can emphasis the responsibility of operator in choosing number of DSCPs. We can give guidelines. - David: We have never dealt with this issue before because nobody ever asked for 16 DSCPs. My objection is to the carte blanche nature of the language. Would like a SHOULD rather than a MUST. Operator needs to know why they want more than one DSCP, otherwise they should use only one. - Paulo Mendes: Too late for too many changes. However, it is not clear how this can be used for AF classes. Even title is misleading - not for all Diffserv. Also, in a Diffserv network a method that requires some action for every flow is not so good. - Georgios: These comments could be solved by an applicability statement. * Controlled Load QoSM ---------------------- Slides are available at: http://www3.ietf.org/proceedings/06mar/slides/nsis-13.ppt - John: This draft has been discussed before; it is currently not a charter item. Considerations also from the bar bof. - Robert: Controlled load service seems to be a useful example for NSIS deployment. Defines replication of RSVP/Intserv behaviour. QoS Model includes token bucket parameters from RSVP/Intserv. MTU discovery removed, but may still be interesting. Draft has been updated with detailed parameters from RFC2211. Updated appendix: gives more detailed information on sender/receiver initiation, including replicaion of RSVP behaviour Some half-open issues. Identifies options for construct QoS NSLP query messages to replicate RSVP PATH. How to interwork with RSVP - may need further study. Still some protocol fine tuning needed. Verify scope: refining definition of CLS or just providing new freedom for how to invoke it. Should we start considering CL-ECN extensions. Should it become WG item? - John: History of CL draft. Authors thought would useful as proof of concept. People indicated interest in the path. Yesterdays non-bar (water only) bof regarding CL PHBs (Bob Briscoe's work). General sense yesterday was of interest in that work. - Jerry: Briscoe work is not signalling. - Robert: That work includes edge-to-edge signalling. But no signalling in the interior. - David: when considering this new PCN work vs. traditional CL, I prefer this new work. But is less capable then full flow classification. - David: ECN has mechanisms for marking packets for congestion. Also needs signalling packet to sender - we originally knew how to do this for TCP. PCN has signalled feedback mechanism to feed back to CAC. - John: Who is interested in the traditional controlled load service? half a dozen or so Who is interested in this new style controlled load? a few more Will bring up on list: do we do one qos model for both, or separate ones? * NAT/Firewall NSLP ------------------- Slides are available at: http://www3.ietf.org/proceedings/06mar/slides/nsis-5.ppt - Martin: Should now be more or less finalized. 3GPP2 is looking for Network Firewall Configuration and Control Protocol. Has been presented to the 3GPP2 (by John). They are in favour of NAT/FW NSLP as their NFCCP, but with a number of issues: port range (added in -09), icmp support (added in -10), query for firewall capabilities (still open), mobile ipv6 support (separate draft in progress), one shot signalling message to teardown all policy rules (added in -10) - Martin: Notification storms: method provided to send a single message where otherwise one per session would be required - Martin: New section added on conceptual states for signalling sessions - Martin: Couple of non serious pending issues - Martin: Think we can fix last items and then go to WGLC. Should get revision by first week of April - John: Ok, then can go to WGLC. - Robert: How will you fix RAO? - Martin: Probably leave it unresolved at WGLC - John: I am going to fix it. * Applicability Statement of NSIS Protocols in Mobile Environments ------------------------------------------------------------------ Slides are available at: http://www3.ietf.org/proceedings/06mar/slides/nsis-0.ppt - Seong-Ho: Various open issues: mobility objects, branch identifiers, etc - Seong-Ho: We need comments from the NSLP authors - Ted Hardie: How do you distinguish between netlmm and OSPF routing-changes? - Hannes: If CoA doesn?t change, it looks like a route change - Robert: No quite. - Hannes: Btw, this document is aimed at solid mobility proposals, and not meant to analyse any mobility proposal under development. - Martin: Currently document really covers only the QoS NSLP. You need to work on that. - Hannes: Added some text on NAT-firewalls. The consequence of mobility is different for QoS-NSLP and NAT-NSLP * Hy Path --------- Slides are available at: http://www3.ietf.org/proceedings/06mar/slides/nsis-11.ppt Luis: Work been going on for two years at Eu funded project (EuQoS), looking to use NSIS for signalling Need to signal all domains between end points, but user does not support NSIS. Need to follow signaling path, but go between resource managers A solution: NSIS signalling at edges of domains which communicate with resource managers (RMs) A second problem: what if don't have NSIS border routers Proposal: Signalling directly between RMs, query routing protocol at egress border routers to determine next RM HyPath: a hybrid proposal - combine information from routing protocol and nsis interception of signalling. Use NSIS at edge where available, otherwise direct RM to RM communication using information from egress border router. John: General question: is this something some of the partners are actually looking at deploying? Luis: France Telecom and Telefonica are involved and looking at how they could use this Luis: We've developed GIST and QoS NSLP implementations. Will be doing NAT/FW. * Partly-Decoupled Signalling in NSIS ------------------------------------- Slides are available at: http://www3.ietf.org/proceedings/06mar/slides/nsis-1.ppt - Robert: First time formerly discussed. Started out as a very broad problem statment. Had reviews from various people. Not new protocol work - applicability statement. Using protocol with new goals. Discussion covers mainly the solution approach. - Robert: Overall goal is to maximise the amount of signalling protocol stack that may be moved off forwarding nodes, while retaining the automatic coupling to topology that path coupled signalling provides. Want to retain compatibility with pure path coupled approach. Technical approach based on GIST design. GIST has two parts: Query message (responsible for coupling to topology), everything else Method: route query as normal, but allow it to be backhauled away from path - Robert: what next? would like wg to adopt. Believe almost done - not a protocol development exercise. - John: How does this fit to Luis' work? - Robert: This is much less ambitious. Doesn't try to address totally NSIS unaware domains. - Paulo: Does this work with all NSLPs? Also, later I see there is work in interdomain qos how does this fit together? - Robert: There is some parts in the off path interdomain model that may be superseded by this. This is applicable to all NSLPs - does not change GIST service interface not the same as saying it is applicable to all signalling applications - that depends on having mechanisms to perform the necessary signalling application actions on the forwarding nodes - Jerry: Relates to work in ITU RACF. Have you talked to other SDOs about this? - Robert: Other people involved in draft have. - Jerry: we haven't sent liaisons to such groups - John: I'll talk to liaisons about this - Hannes: We (John, myself) have talked to ITU and others about this - Hui-Lan Lu: I am the ITU liason to IETF and chair of group working on RACF. We have sent a liaison on RACF draft. You should look at the requirements to see whether they fit with NSIS off path as discussed here. [Magnus on Jabber: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=195] - Magnus Westerlund: need to talk off-line about chartering of this - I don't see this as unreasonable, but need to understand full implications - Ted Hardie: To avoid lots of last call comments, need to be more precise by making design choices or describe how to make those choices in sufficient detail to make reviewers happy. - Jerry: Responding to Hui Lan-Lu - good to hear that a liaison is coming - Robert: I would be enthusiastic to see if we can address at least part of that problem. If we can't, then that is another interworking problem we have to deal with. - Hannes: Regarding the ability to control the forwarding node there is work on diameter for QoS in DIME. - Juergen: the control protocol is part of the signalling application - John: what I think Ted said: if we don't specify protocols need to specify properties required - John: Would people support this becoming a working group item? at least a dozen hands - John: Would anyone oppose? no hands * Extensibility --------------- Slides also attached to: http://www3.ietf.org/proceedings/06mar/slides/nsis-6.ppt - John: I keep getting writers block on this. - John: Currently individual draft. Allison thought that it should go to the IESG at same time or soon after protocol drafts. Need to describe some of the design decisions that need to be made when designing new NSLPs, etc. Aim to avoid the mess in other places, such as RADIUS. Discussion of new NSLP features, NSLP versioning, QoS model interaction. - Hannes: Should NSLPs reference this document? - John: my opinion is that NSLPs should not normatively depend on this document. NSLPs should be complete for implementors on their own. - Hannes: How should we proceed with this document? - John: Probably should become wg document, but want more comments. Might be appropriate to go in when revise charter. - Robert: Should be wg item as soon as possible - Hannes: I also would like to see this document being moved forward as soon as possible. - Robert: Who should create object space registry? - John: All details should be in the NSLP documents. - Robert: What about isntructions to iana to create registry - John: Need to work this out - Robert: could say "create this if it doesn't already exist" - Magnus: probably a good idea to have a good guidelines in one place - John: we should cross check against Thomas Narten's IANA rules bis draft - Robert: I feel we should keep QoS model stuff out. This maybe shuld be pushed into QSPec. - Al Morton: I support the qos model interaction discussion in this draft. - Martin: I think this sort of doc is a policy check in 10 years. A check for future NSLP authors as to what they should do. - Jerry: I agree with Rob. Need to be consistent about QSpec extensibility. THURSDAY, March 23, 2006 1510-1610 Afternoon Session II Metering NSLP ------------- Slides are available at: - Juergen: Presented 2 or 3 times before - nothing particularly new. Also presented at IPFix. Does not really fit into IPFix, since they don't have the NSIS protocol expertise. * NSIS operation over tunnels ----------------------------- Slides are available at: http://www3.ietf.org/proceedings/06mar/slides/nsis-4.ppt - Henning: Closed session binding code. - Henning: Discussion of race condition between e2e and tunnel sessions. - Henning: Open issue: Tunnel capability discovery - John: sense of room in Vancouver was that this would fit in working group, just need to free up room on charter first * GIST over SCTP ---------------- Slides are available at: http://www3.ietf.org/proceedings/06mar/slides/nsis-9.ppt - Hannes: Presentation given previously to NSIS WG. - Hannes: Minor changes since -00 version. Reflecting GIST -08 to -09 changes. - Hannes: Next steps: TLS over SCTP, usage examples/scenarios - John: anyone interested in this? dozen hands or so anyone against? none * NAT Traversal for GIST ------------------------ Slides are available at: http://www3.ietf.org/proceedings/06mar/slides/nsis-3.ppt - Hannes: Gives guidelines to implementors of GIST. Now provides additional description of a cookie mechanism when used with NAT traversal that does not cause Denial of Service vulnerabilities. Removed GIST-unaware NAT traversal - that fits in a separate document. - Martin: I have major problems with this draft e.g. talks about NSLP not carrying message identification information - Robert: Precise statement is that the flow related information in the NSLP does not need to be translated - Hannes: Certainly true for QoS NSLP - Martin: I'm not against this, provided it doesn't require 25% code change in GIST - Robert: My hope is that it doesn't require any code changes, except maybe the cookie construction. Requires work in NAT, which GIST doesn't define. - Martin: In my view it is not ready for WG to adopt. - John: Maybe do more work. People should review it. - Robert: I think the draft should be adopted. - Hannes relaying Christian Dickmann on Jabber: the NAT traversal draft requires very little code changes in normal GIST nodes * Inter-Domain QoS Model ------------------------ Slides are available at: http://www3.ietf.org/proceedings/06mar/slides/nsis-10.ppt - Luis: Interdomain and intradomain control agents. New parameters for QoS model. Describes use of combining intradomain signalling (e.g. Y.1541, RMD) and interdomain signalling Uses separate QoS model for interdomain signalling - Jerry: You refer to Y.1541 and RMD as intradomain. I think they are both interdomain. Also, what does this add to existing QoS models and stacking? - Luis: This is also designed to work between domains that don't support NSIS. - Georgios: You also use centralised resource management - Luis: Not important here. The entities at ingress map to intradomain QoS. - Paulo Mendes: What has a domain - an operator - to gain with this? The operator is still exposing his network. - Robert: (comment on Egress ID Parameter) You are identifying the list of interfaces that the qos applies - Luis: I think the interfaces are for when message is sent from one domain to another, to identify the sender address. I'm not sure. - Robert: This may be the right way to do this for research. Wrong way to do it in long term. We've been careful to keep addresses out of signalling application. Would need to work out right way to do it. - Hannes: Responding to Paulo. regarding issue of operators not wanting to expose network, what does it mean? - Paulo: PHBs belong inside networks, not between networks. I see this in QSpec. - Luis: QoS model not yet defined for interdomain connection - would need to take this in to account. - Georgios: Diffserv could also be used end-to-end. I don't understand problem. - Paulo: This goes back to Fred Baker's draft. If PHB such as AF1 is used in one network, the properties may be different in another for the same DSCP. - Paulo: SLS between networks - Georgios: doesn't mean you can't do it - Paulo: but you can't signal the DSCP end-to-end - Hannes and Giorgios: reacted to Paulo?s comments about the use of code points (e2e or edge-to-edge as said by Paulo) - John: Code points are meaningful inside a domain, but more comments are required about use of the draft. * Diagnostic NSLPs ------------------ Slides are available at: http://www3.ietf.org/proceedings/06mar/slides/nsis-15.ppt - Hannes: Meant to go along a path. Aims to be like RFC2475. There are a number of design alternatives. - Martin: I like this work, but see a problem in which information you can gain from this for other NSLPs. - Hannes: Provide more information than just the ping. - Martin: You can only learn things about nodes where this NSLP is located - may not be nodes where you have QoS or NAT/FW NSLP. - Juergen: I wonder why the particular doesn't support it. Decision made that don't need it, now saying maybe we do need it. Also, discovering NSLPs supported - shouldn't it be in GIST. An NSLP is the wrong place to put this. - Hannes: Purpose of this is to consider design options. - Luis: I've found this useful in implmentation work, and also for operational work as an alternative to traceroute. I see this in same way as a useful tool to check configuration of NSIS equipment. - John: So this could be an experimental NSLP - for diagnostics, not deployment. - Robert: Haven't said who it is useful for - protocol designers, implementors, operators, end users. How much do you want to allow users to find out about others users state? - Hannes: aim for operators, not end users - Robert: Regarding Juergen's question - this may be a good candidate for a shareable object between NSLPs. I'm not sure how you would do such a shareable object, but seems right place to put it. Freestanding NSLP is useful from an implementation testing point of view, but not long term. - John: send comments to list * Additional NSIS Communication Patterns ---------------------------------------- Slides are available at: http://www3.ietf.org/proceedings/06mar/slides/nsis-18.ppt -Martin: Currently have two patterns: path coupled MRM and loose end MRM May be other communication patterns of interest to other signalling applications * Echo-pattern: spreads out from a GIST node for a configurable number of hops, and then results comes back. * Path-directed search pattern: this is a little more theoretical. Go along data path, but also take some steps to the side. So, communication spreads to the side of the path as well. Can detect nodes along side of the path offering a particular service. - John: Would people be interested in Martin and Marcus writing this up as a draft? - Georgios: I think it would be good to see applicability statement - use cases - Hannes: We can probably chat about this over a beer. I'm not sure exactly about the use case. Looks nice on slides, but more is needed. - Robert: Generally I like these ideas - you see these patterns in various systems. We only have 8 experimental MRM codes. Do we need more? This is an interesting research topic. Should fit in to GIST, but involves communication with more than one peer, so involves changes to state management. - John: Sounds like people would read the draft * Chair/Meeting Conclusion -------------------------- - Roland: is it of interst to work on interdomain aggregation? As aggregation is currently defined with codepoints, does not work between domains. Early charter mentioned that RSVP had a lack in the interdomain area. I'm thinking of writing a draft in this area. - John: any interest? a few hands - John: need people to review current drafts once they are well on the way to ADs, we will look at rechartering have a number of potential work items there don't wait for future times - continue working on individual drafts