IETF 73 DRINKS Agenda - FINAL Data for Reachability of Inter/tra-NetworK SIP (drinks) Salon F RAI drinks Data for Reachability of Inter/tra-NetworK SIP WG Chair(s): Richard Shockey Alexander Mayrhofer WG Secretary: Debbie Guyton RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com RAI Area Advisor: Jon Peterson jon.peterson@neustar.biz Agenda Bashing. Meeting Notes: David Schwartz suggested item one should be 30 min and item two should be 45 min. Richard said we will see how it goes. We will not fully resolve item 1 here. A. Some more detailed discussion of what is a LRF? How does LRF fit into the use cases etc. (15 Min) Title : Location Routing Function Requirements Author(s) : H. Kaplan Filename : draft-kaplan-drinks-lrf-requirements-00.txt Pages : 7 Date : 2008-07-04 This document describes the requirements for a Location Routing Function Protocol, for inter and intra-domain SIP session routing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-drinks-lrf-requiremen ts-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Look Up Function vs. Location Routing Function discussion Author(s) : G. Schumacher, H. Kaplan Filename : draft-schumacher-drinks-luf-lrf-diff-01.txt Pages : 8 Date : 2008-11-03 This document provides a comparison between the Look Up Function (LUF) and the Location Routing Function (LRF) as used for inter and intra-domain SIP session routing. It also develops the relationship between the two functions. This document is meant for discussion purposes only. Meeting Notes: Hadriel stated that Greg Schumacher could not be here but is probably participating via Jabber. We need to clearly define terms so that we know what we are designing. Question is what does 'target domain' mean? - terminating domain, next domain, next hop? Does it have to be a domain? Domain has semantics for DNS and we may not want that. Jean-Francois questions why we would want anything other than a domain? David Schwartz says it has meaning. You already have some knowledge of the next step. It is included in domain. But domain has context. Maybe we should use a different name. He is suggesting just an 'identifier'. Jean Francois: I don't think domain means it has a route with it. It has to be in the DNS. When you resolve it, it may not resolve. Otmar says he's fine using the domain. Greg Schumacher says it should provide information to reach the terminating destination. Is the goal to modify the terminology in SPEERMINT? Hadriel says he is clarifying the terms from SPEERMINT. Dave Schwartz wants carrier of record information - then use PSTN databases per Jean-Francois. Richard: I want to query a database and get a point to route - it may or may not be to an SSP. Jean Francois: You can get a result that is meaningful for a SIP box. David Schwartz: LRF is going to tell me how to reach him. But it is misleading to not give me a route to the carrier or record. James: Are we saying that the LUF will tell us who and not where? Richard: There may be multiple pathways to get there. The endpoint is the LUF, the LRF is how to get there. This is ultimately a SPEERMINT terminology problem. Slide 3: The slides show why the LUF is not the next-hop. SF addressing is not static, ... Example 2: Transit peering: We need to figure out how to get there. LUF tells you B (not E) and the LRF tells you how to get there. Why LUF is not next-domain. LUF does not have history so loops could occur. What is LRF? It's role is to determine how to reach B. So why split them out? LUF can be easily centralized and should be. Getting to the real world of transit, LRF is more complex and cannot be centralized and should be distributed. LRF almost always changes based on who is asking. Securty/privacy issues are very different. Adam Uzelac: The response in LUF should be in general the same, within a country. Are there multiple LUF queries along the path? Hadriel says yes. Jean Francois: What you have recapped for LUF and LRF is fine. Why do we need to care about where LUF and LRF are? Whether centralized and distributed. Today LUF is both. David Schwartz: Today the LUF and LRF are somewhat coupled. But we should separate the two, the who versus how to get there. We should focus on the private,infrastructure ENUM structure. Hadriel: The LUF is not a route at all, it's an AoR. Richard: Hadriel will make this same presentation to SPEERMINT as well to help make the terminology less ambiguous. Richard: Are we in general rough concensus that this is proper input to SPEERMINT? Jean Francois: This is an individual contribution. today DRINKS doesn't drive input to SPEERMINT. I haven't seen a delta in the definitions that are meaningful enough and that I can sign off. Hadriel: Should we change 'target' to 'terminating domain'? Alex: I sense agreement that the LUF should not provide the next hop. The request is that Hadriel post the deltas to the DRINKS list. Co-chairs: Confirmed this is not a working group document. John Elwell: In the case where the final destination is in an enterprise domain. Suppose it has the Tel URI, what will the LUF give me? The answer depends on the AoR. Enterprises don't always own their own AoR. David Schwartz: The SED can be a little clearer as to the routing information or other information related to session establishment. Consensus: Otmar asked can we all agree that option A on slide 2 is what we want? A hum showed agreement. B. Detailed readout by the Design Team on the DRINKS Use cases. IMHO this will take most of the time slot. (1 Hour) Title : DRINKS Use cases and Protocol Requirements Author(s) : S. Channabasappa Filename : draft-channabasappa-drinks-usecases-requirements-01.txt Pages : 19 Date : 2008-11-03 This document presents use cases that illustrate what constitutes session establishment data, the functional components that need them, and the protocol requirements for provisioning and managing session establishment data within the identified functional components. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-channabasappa-drinks-usecases-requ irements-01.txt Meeting Notes: Sumanth presented for the DRINKS Requirements Design Team. James: Does this specify whether these items are included in the LUF or LRF? Sumanth's answer: TBD. Dave Schwartz: The use cases are co-mingled. The local data repository is a mirrored cache or could have other local routing data. It is still authoritative. Jean Francois: What is the registry containing? LUF or LRF? or both? Penn and I say that it should have both LUF and LRF. Dave Schwartz: You don't need to restrct it but delineating it as they have different properties. Another aspect is a Registry pushing to a Registry. Richard: This is coming. This is the last team item to decide how to cover this. We then reviewed the terminology slides. We then reviewed the provided list of use cases. Hadriel: Why are you assigning public identifies to a Destination Group - the LUF should not be specifying the routing. The detailed routes may be different depending on who is querying. Sumanth said that those in a Destination Group get treated the same way. Ray pointed out that Hadriel had an example on one of his last slides: a circle showing a section of the network. Manjul discussed that the agregating may be for LUF and LRF. David Schwartz said that a diagram may be useful. If you are saying all of these public identifiers go to the same destination, it is really a routing function. David Schwartz: Are we talking about the right side of the @ sign. Then why is it LUF? This is LRF. OTmar from Jabber: Destination Group is a good term. Ideally they can represent domain names and can be used as LUF. James: It also includes a range of TNs. Being a single identity confused me. It's multiple identities. The PBX example as a group makes sense but not call a range an identity. Why routing group? why do you group them together? David Schwartz: Why 'logical'? it's just a grouping. Manjul: Could be for load balancing, geographical considersations, or other purposes David Schwartz: I'd like to see a separation of LUF or LRF in terms of provisioning. The whole number management versus which SSP should be accessed are different problems. Jim: It seemed that the examples did fall into one or the other LUF and LRF so he would like to see this. Jean Francois: It may make sense for use cases and requirements, but the protocol may cover both. We don't need a different design for both. David Schwartz: I don't agree. I think the problem is so different. I may use RESt for one and I may use SOAP for another. The number of times my architecture changes is vastly different from the dynamics of numbers porting. This is a numbering space versus a routing space. Jean-Francois: It does not mean you need to use a separate protocol for LUF or LRF. Also, the idea here is to be able to provision in bulk. Alex: There is agreement in the design team that we will need to provision different objects separately. Hadriel: The complicated real world cases will not have the LRF detail in LUF. He expects the protocols to be different. ESPP is fundamentally not usable for this. David Schwartz: If I look at LUF as an enum NAPTR thing that's one thing, LRF may not follow NAPTR rules. We are hampering our ability to define what LRF needs to do. Having the same protocol contrains me. Sumanth: - Do you see different requirements in provisioning the data? David: Yes Jean Francois: This protocol can be used to configure the routing proxy. Otmar says the focus on a registry bothers me. It should come out of a need from the use cases. In bilateral cases, you may not need one. Penn Pfautz, from Jabber, agrees with comments from David and Hadriel. Hadriel is not sure that a registry distributing down to a routing proxy is the right model. How are the data learned to be provisioned? Is it manually determined and configured? Jim: We are all saying the same things. Take the use cases and determine the requirements and then determine the necessary protocol or protocols. Jean Francois: You may want some of the details of the LRF not to be in the LUF. Adam Uselac: Nothing I have seen in the use cases, or design team would prevent this. Richard: Will the routing area directors give us a problem if we get too far into routing? We are trying to finish a set of use cases that will be incorporated into a requirements document. Then ultimately deliver a protocol that satisfies these requirements. Sumanth noted that we welcome others submitting use cases to the design team. David Schwartz: Selective peering? Results may differ based on data recipient groups. Some dicussion of the schedule followed. David Schwartz: I think it is a little optimistic. Richard: We need to shut this down in 09. David Schwartz: Security section, in central databases there is a question of who accesses the data. Richard said that authorization and authentication will be left off the table for now. C. General discussion of the protocol requirements. (15 Min) JF Mule ? Meeting Notes: Jean-Francois presented general protocol requirements, real-time operations or file-based batch provisioning operations. Low volume versus high volume. He recommended folks read RFC 5381, a good example of a provsioning protocol over SOAP. For real-time, the design team is in agreement for an XML over SOAP WSDL. David Schwartz: SOAP has a lot of overhead, he may prefer to use REST. SOAP has a lot of security overhead. Richard: Why would we use anything other than SOAP/XML? Hadriel asked if we were concerned about the size of overhead? Jean-Francois: It doesn't seem to matter. Ken Cartwright: His observations are that SOAP didn't add any significant overhead. Richard: Even in large bulk cases of 400 million records, Soap vs. CSV, the overhead isn't much based on the size of data and processing time. Ken: Marketability. Soap is more widely used. Adam Roach: you should solicit input early. Sources - LIsa Desseault and Mark Nottingham. David Schwartz: I think it is wrong to just look at what folks use today. When you have small datasets, and upload one number, the overhead is large. Richard: The reason this design group was formed is that no one is going to deploy 4114. Otmar: Regarding SOAP/SML, you are assuming a Registry again and we aren't there yet. Cullen Jennings: We should review and choose the appropriate use of security capabilities in SOAP. There are quite a few security mechanisms there. That doesn't imply you use them all. D. Preliminary discussion of the data model. (15 Min) Meeting Notes: This discussion was presented by Ken Cartwright. He stated that the Working group is not quite ready to talk about a data model. These are some initial thoughts. It was noted taht who provisions the data or who is responsible for the data may be different. David Schwartz asked about transit provider. Ken said that a transit provider can provision a set of resource records that can be used to get to the destination. Ken said the the peering entity is responsible for the object, e.g., public identity. Richard mentioned registrar versus registrant. E.g., SPID vs. Alt-SPID. David Schwart said we should have concepts of both in the near term. Jean-Francois: We should have some sense of identifying that the record is valid and it can be validated that the you are the carrier of record. The public identity is a TN, your IM address, your email - user addresses. Ken said can't the target domain come from the public domain space. E. Issues involving how provisioning Private Peering data fits into the DRINKS model. (15 Min) General Discussion ... Meeting Notes: Richard: The protocol we intend to design should not preclude bi-lateral exchange of data. Otmar doesn't like the concept of a Registry. David Schwartz: What is there for Private Peering? Richard: We have no use cases for this yet. We need to understand what private data is. Hadriel: Tt's data that does exit the domain. Adam Uzelac: I believe the model supports short digit dialing but it's not necessarily public data. I'm thinking of a federated model where I have all the branch offices for Company X. this is private data. Adam Would like to see a timeline. RIchard: Incorporation of use cases becomes the basis for the requirements document. Adam: Is the draft of the interface rqmts for both the LUF and LRF? Richard: yes. Jean-Francois: He noted that we finished the meeting again with LUF and LRF. We should keep the rqmts as general as possible with respect to LUF and LRF. Even the SPEERMINT document does not heavily use the terms LUF and LRF.