[Dime] More verbose notes from Dime 93

["A. Jean Mahoney" <[e-mail]>]

Hi all,

And here are the more detailed notes from the session.

Jean


------------------------------------------------------

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.

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.

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

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.