IETF-93 dime Session 2015-07-22 1300-1530: Karlin III 13:00 - 13:20, Preliminaries (20 minutes) ------------------------------------------ Audio/Video & Remote Presentation Debugging Presentation: https://www.ietf.org/proceedings/93/agenda/agenda-93-dime Presenters: Jouni Korhonen, Lionel Morand Note Takers: Jean Mahoney Jabber relay: Jean Mahoney Jabber log: http://www.ietf.org/jabber/logs/dime/2015-07-22.html Note well Agenda bash Jouni Korhonen: Group Signaling added to the end of the meeting. Document Status o draft-ietf-dime-agent-overload-01 -> in WG o draft-ietf-dime-doic-rate-control-01 -> in WG o draft-ietf-dime-load-00 -> in WG o draft-ietf-dime-group-signaling-05 -> in WG; recently revised o draft-ietf-dime-e2e-sec-req-03 -> to be submitted to IESG; recently revised o draft-ietf-dime-congestion-flow-attributes-01 -> in AD followup o draft-ietf-dime-4over6-provisioning-03 -> in IETF LC; IANA expert review done o draft-ietf-dime-ovli-08 -> in AD Evaluation; going to IETF LC Steve Donovan: I want to solicit comments on agent overload and rate control. There have been no changes since the last meeting. We need to move the docs forward. ACTION: Remind mailing list to review draft-ietf-dime-agent-overload and draft-ietf-dime-doic-rate-control. Working group draft discussion (30 minutes) ------------------------------------------- 13:20 - 13:40 Diameter Load Information Conveyance, (Steve 20 min) Document: draft-ietf-dime-load-00 Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dime-1.pdf slide 1: Title Steve: The draft is incomplete, provides a first definition. slide 2: draft-ietf-dime-load slide 3: Peer-to-peer mechanism Steve: I believe we have consensus on peer-to-peer. Want to clarify the server load concept before defining the AVP. slide 4: Server Load Martin Dolly: We believe this work needs to be supported due to our network deployment. Steve: Partitioning can be based on users or geography. Sometimes the clients choose the server rather than the agent. I think the base spec is inconsistent on using only Destination-Realm and app-id. We could separate this out if we think we need a bis on the base spec. I don't think that's necessary, and can cover it in a separate section in this doc. Objections? Lionel Morand: It can be indicated in a separate section that Destination-Host could be used in the routing decision. It could be application specific, or context specific. If any node in the middle doesn't support it, it may not work. You can indicate that it is not Diameter base related. Steve: if an application does incorporate the server load concept, we would define the AVPs to do so in this draft. Instead of the Cx, Dx specs, etc. Lionel: A new type of AVP. Steve: for us to decide. Conrad, Deutsche Telekom: You would give hints on how to use the AVP, right? Steve: We'd provide guidelines on how to use the info, but not normative text on how to do load balancing. Conrad: That satisfies me. slide 5: AVP Design Steve: It's a hint, there's not proscriptive behavior tied to it. Thus no capability negotiation. Martin: I don't think we need it here. You're going to use load info to balance traffic in order to avoid overload. There is room for error if you are off. Keep it simpler, and out of sequence. Steve: my thoughts also Lionel: Same Balint Uveges: ... Steve: A restart would wipe out load info. Lionel: needs to be clarified. It assumes that the node sending request that ... any destination or peers, would react to info from the network. Steve: there is no requirement to keep state over restart. slide 6: AVP Design Steve: Agents propagate a server's report and create their own. Or servers could create 2 reports but sometimes there are direct connections between server and client and there's no agent. Jean-Jacques: I prefer a new grouped AVP, some networks only use peer and not server selection. If diameter node looks at server load only, a node that doesn't do server selection doesn't have to look. Conrad: On one side, indicating for server load. How will we mark AVPs from source? Steve: That's the question. The peer AVP will have DiameterID in it. Is one enough? If we pass that through? If there are multiple agents - one from the peer and one from endpoint - we'll need to differentiate. Conrad: We have a History-Info header in SIP, but I don't want it that complicated. It should be an easy mechanism. Steve: This is just giving you additional info to choose the next hop. I agree that it should be straightforward. Lionel: For the second type, server-load case, do we need something else? From a peer it would be from a node that is not a peer. Need something about the freshness of the information received. Steve: A timestamp? Good point. Lionel: could be implementation specific. Need to talk about it. Steve: It might imply that the end point generates the report rather than the agent. slide 7: Security Considerations slide 8: Next Steps Steve: Do we have a decision on server load? Lionel: Be careful about the wording around ... You may use additional routing info that is app-specific. Could be used for routing decision - make it generic. Can't assume that all nodes could use it though. Otherwise a 3GPP decision. Steve: if you have the need to insert Destination-Host in the request, you could use this to influence what to put in Destination-Host. Lionel: This info could be sent to the peer anyways. Steve: Need to flesh out the mechanism parts of the draft. I'll work with JJ on that before Yokohama. Lionel: you need to have review and comments. Need to have people involved. ACTION: Put the server load information in a separate section of the draft, note that it is not Diameter base, and, if any node in the middle does not support it, it may not work. Steve and Jean-Jacques to work on the mechanism part of the draft before Yokohama. 13:40 - 13:50 Diameter Overload Indication Conveyance, (Jouni 10 min) Status Update Document: draft-ietf-dime-ovli-08 Presentation: None Jouni: Draft is in IETF LC. AD had concerns because the co-chairs were both authors. However, we could show that the process was used and issues were traced. No concerns anymore. IANA has allocated code points. There may be some LC comments. Steve: I'll take care of Stephen's LC comments when LC ends. Jouni: We don't need to update based on Ulrich's comments. Lionel: If there is a real concern about text, it can't be done after LC. And it needs to be discussed on list. Jouni: Avoid re-opening items that we had reached rough consensus on. ACTION: Steve to address comments. Individual draft discussion (15 minutes) ---------------------------------------- 13:50 - 14:05 Diameter Routing Message Priority, (Steve 15 min) Document: draft-donovan-dime-drmp-01 Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dime-0.pdf slide 1: Title slide 2: Problem Statement slide 3: DRMP Use Cases Martin: For example, government priority services - first responders HPA (??) Need to coordinate the priority of the phone attach to eNodeB, otherwise this could tear down the work done there. slide 4: DRMP Mechanism slide 5: DRMP Mechanism slide 6: DRMP Mechanism slide 7: Open Questions Martin: Sounds like the Resource-Priority header in SIP based on trust boundary. I as a carrier trust ABC but not XYZ. There's a default value, but local policy sets the values. Steve: The S6a application may set it differently than PCC. Martin: We've talked about this in ATT. There's coexistence of first responses and gov priority, each carrier will create guidelines. ATIS is defining this for North America. It's a national issue. Janet Gunn: Sounds right to me. Steve: Make it application specific so that it's configurable. JJ: It's an operator's local policy to configure policies. If you receive priority from an external network, you'll have to map it to your own priorities. The number of priority levels - you have chosen 5 - is this consistent? enough? In 3GPP, 0 is the highest priority. Steve: I've seen it defined in both directions, we just have to choose one. Martin: I recommend mirroring the Resource-Priority header (RPH) where 0 is highest. Look at RPH namespaces and value ranges. Will indicate if 5 is good enough. Steve: I did that, none has more than 5. I thought 0 was lowest. It may not be consistent across name spaces. I trying to make it consistent with RPH. Janet Gunn: in RFC4412 (RPH) all the namespaces that use numbers for priority have "0' as the HIGHEST priority. I suggest sticking with that convention. Lionel: The value of the priority can change depending on context. Steve: Yes. slide 8: Next Steps Steve: Request to turn into working group item - we had deferred the decision in Dallas. Martin: I support that. There's a 3GPP CT meeting in August. They're working on Push to talk for public safety. Lionel: Show of hands: who's read? Lionel: Make it a wg item? 3 hands Janet Gunn: I have read it and I support making it a WG item. I will comment on the list. Lionel: No? No hands Lionel: This will become a work item, use this doc, will confirm on mailing list. Martin: within US, the nimstick (?) reqs, they would be interested. They were concerned about radio access priority. They would need this in the network, they hadn't concerned it. ACTION: Confirm making DRMP a working group item on the mailing list. Group Signaling --------------- Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-dime-2.pdf Presenter: Marco slide 1: Title slide 2: Summary of the 5th revision slide 3: Summary of the 5th revision slide 4: Next Steps Steve: I'll volunteer to review. Lionel: We can initiate WGLC when it's stable. Need expression of support for the document. Any comments are welcome. Marco: Make a decision and progress it. ACTION: Steve to review the group signaling draft. Wrap-up (nn minutes) -------------------- 14:05 - 14:20 Next Steps / AOB: WG Chairs & ADs (nn minutes) Lionel: Discussion in the opsarea to standardize TACACS, which is a regex-like mechanism defined by Cisco. If you are interested, discussion on opsarea list. Lionel: The security requirements are done, now we need a security draft. Jouni: I'll resurrect the old document. Lionel: I talked with the new AD. He suggested that we write the draft, then get security review, rather than get input up front. Lionel, to the group: please be active in the working group. ACTION: Jouni to resurrect the old security document.