Minutes for DIME at IETF-93
minutes-93-dime-1

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.