Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Wed, 5 Dec 2012 14:45:22 +0000

Hello All,
I submitted a slide presentation IETF #83 Paris on the topic of marking SIP signalling to make it practical to troubleshoot sessions that cross multiple networks (http://www.ietf.org/proceedings/83/slides/slides-83-insipid-1.pdf). I proposed to add this function to the session-id work being done by insipid but the feedback was that dispatch should consider the proposal. I have therefore written a requirements draft http://www.ietf.org/internet-drafts/draft-dawes-dispatch-logme-reqs-00.txt as a starting point for discussion which I hope will lead to further work on draft http://tools.ietf.org/id/draft-kaithal-dispatch-sip-log-information-00.txt, which describes something quite similar to the slides I submitted to the Paris meeting.

Regards,
Peter

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Dec 2012 13:41:47 -0500

> I submitted a slide presentation IETF #83 Paris on the topic of marking SIP signalling to make it practical to troubleshoot sessions that cross multiple networks (http://www.ietf.org/proceedings/83…

You've done the right first step by publishing this and commenting on it 
here. The next thing is to see how much interest there is in it.

I have a couple of comments:

- You have two REQ2s.

- I think you should explain more about REQ3.
   On one hand, there are cases when you might
   want/need for this to survive trust boundaries.
   OTOH the administrators of the domains might
   not want to allow this. Its not clear to me
   that you can mandate much here.

- are REQ5 and REQ6 talking about the same
   identifier, or different identifiers?

- there is potential overlap between this and
   Session-ID. Would like to see you discuss
   whether Session-ID satisfies your identifier
   needs.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 5 Dec 2012 14:25:09 -0500 (EST)

I recall during discussion of a similar topic that people from
carriers said that carriers do not diagnose networks by tracing the
signaling of single calls, but rather monitor the usage statistics of
various facilities for anomalies.

I see that the author of this draft is from Vodafone, which is a
carrier, and the mechanism proposed in the draft is to trace the
signaling of single calls.

Is it correct for me to infer that there are occasions where carriers
trace single calls for diagnostic purposes?

Dale

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Thu, 6 Dec 2012 09:00:05 +0000

Hello Dale,
This carrier has SIP-based networks in more than one country, but in the network I am familiar with we have tools that can check for correct operation down to a single-call level.

Regards,
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: 05 December 2012 19:25
To: [email-masked]
Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt

I recall during discussion of a similar topic that people from carriers said that carriers do not diagnose networks by tracing the signaling of single calls, but rather monitor the usage statistics of various facilities for anomalies.

I see that the author of this draft is from Vodafone, which is a carrier, and the mechanism proposed in the draft is to trace the signaling of single calls.

Is it correct for me to infer that there are occasions where carriers trace single calls for diagnostic purposes?

Dale
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Thu, 6 Dec 2012 09:49:59 +0000

Hello Paul,
Thanks for your comments. 

Regarding REQ3 "Log-me marking shall be removed at trust domain boundaries", to expand a little on your comment I imagine that a network would remove any inbound 'log me' marker unless it has an agreement with the source network not to do so. However, the 'log me' marker is most effective if it passes end-to-end. REQ3 asks source networks to behave responsibly and not leave it to the downstream networks to detect and remove a marker that they don't want. I will reword it to try to include these points.

REQ 5 " Log-me marking may include an identifier that indicates the test case that caused it to be inserted, known as a test case identifier" and REQ 6 "Log-me marking may include an identifier of the server that collects logs, known as the diagnostic server identifier." are for different identifiers. The 'test case identifier' in REQ 5 is the name of one test in a set of regression tests, which could be something like 'test 01' or 'paging mode messaging' or 'e3f634'. The 'server identifier' in REQ 6 is the address of a network monitoring server. 

Session-ID provides an end-to-end identifier which is very useful information when checking for correct session setup. However, Session-ID cannot indicate that a particular session is for testing purposes and therefore needs to be logged. If you have to test a particular session and you have Session-ID only (i.e. no log-me marker), the only way to follow signalling end-to-end is to log all signalling in all entities that might be on the path and then search these logs later for the relevant session ID. 

Regards,
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 05 December 2012 18:42
To: [email-masked]
Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt

> I submitted a slide presentation IETF #83 Paris on the topic of marking SIP signalling to make it practical to troubleshoot sessions that cross multiple networks (http://www.ietf.org/proceedings/83…

You've done the right first step by publishing this and commenting on it here. The next thing is to see how much interest there is in it.

- You have two REQ2s.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Dec 2012 11:47:28 -0500

> Session-ID provides an end-to-end identifier which is very useful information when checking for correct session setup. However, Session-ID cannot indicate that a particular session is for testing p…

I realize that Session-ID would not serve as a request for logging.
But perhaps it would serve as an alternative to the "test case 
identifier". I suggest that you think about that. Otherwise, you are 
introducing another identifier that you will have to fight to get people 
to support.

The server-identifier seems to be a entirely different and a bigger 
deal. It seems to suggest that you want all servers on the path to log 
remotely using consistent tools to a common server. I expect you to have 
a huge battle to get anybody to agree to that.

I'm thinking your log request needs some sort of new indicator, and then 
the (so far hypothetical) session-id would serve as the test id to 
coordinate the logs from all the systems. It would then still take some 
sleuthing to find the systems on the path that have logged something, 
but you can query using the session-id. Perhaps the new indicator 
requesting logging could be a new "purpose" value for Call-Info. If so, 
you could even use the corresponding URI to point to a logging server. 
(But still don't count on everything using it.)

	Thanks,
	Paul

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 6 Dec 2012 22:55:42 +0530

Paul,

Sec 3.5 of draft-ietf-insipid-session-id-reqts-03 describes "logme" usecase
for session id. The text is added after discussing about "logme" usecase in
INSIPID WG.

Thanks
Partha

Note:
3.5. Session Signal Logging

   An after the fact search of SIP messages to determine which were part
   of the same transaction or call is difficult when B2BUAs and SBCs are
   involved in the signaling between UAs. Mapping more than one Call-ID
   together can be challenging because all of the values in SIP headers
   on one side of the B2BUA or SBC will likely be different than those
   on the other side. If multiple B2BUAs and/or SBCs are in the
   signaling path, more than two sets of header values will exist,
   creating more of a challenge. Creating a common header value through
   all SIP entities will greatly reduce any challenge for the purposes
   of debugging, communication tracking (such as for security purposes
   in case of theft of service), etc.

   Derived Requirements: REQ1, REQ3, REQ5, REQ6

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Thursday, December 06, 2012 10:17 PM
To: Dawes, Peter, Vodafone Group
Cc: [email-masked]
Subject: Re: [dispatch] draft-dawes-dispatch-logme-reqs-00.txt

On 12/6/12 4:49 AM, Dawes, Peter, Vodafone Group wrote:
> Regarding REQ3 "Log-me marking shall be removed at trust domain
boundaries", to expand a little on your comment I imagine that a network
would remove any inbound 'log me' marker unless it has an agreement with the
source network not to do so. However, the 'log me' marker is most effective
if it passes end-to-end. REQ3 asks source networks to behave responsibly and
not leave it to the downstream networks to detect and remove a marker that
they don't want. I will reword it to try to include these points.
>
> REQ 5 " Log-me marking may include an identifier that indicates the test
case that caused it to be inserted, known as a test case identifier" and REQ
6 "Log-me marking may include an identifier of the server that collects
logs, known as the diagnostic server identifier." are for different
identifiers. The 'test case identifier' in REQ 5 is the name of one test in
a set of regression tests, which could be something like 'test 01' or
'paging mode messaging' or 'e3f634'. The 'server identifier' in REQ 6 is the
address of a network monitoring server.
>
> Session-ID provides an end-to-end identifier which is very useful
information when checking for correct session setup. However, Session-ID
cannot indicate that a particular session is for testing purposes and
therefore needs to be logged. If you have to test a particular session and
you have Session-ID only (i.e. no log-me marker), the only way to follow
signalling end-to-end is to log all signalling in all entities that might be
on the path and then search these logs later for the relevant session ID.

	Thanks,
	Paul

>> I submitted a slide presentation IETF #83 Paris on the topic of marking
SIP signalling to make it practical to troubleshoot sessions that cross
multiple networks
(http://www.ietf.org/proceedings/83/slides/slides-83-insipid-1.pdf). I
proposed to add this function to the session-id work being done by insipid
but the feedback was that dispatch should consider the proposal. I have
therefore written a requirements draft
http://www.ietf.org/internet-drafts/draft-dawes-dispatch-logme-reqs-00.txt
as a starting point for discussion which I hope will lead to further work on
draft
http://tools.ietf.org/id/draft-kaithal-dispatch-sip-log-information-00.txt,
which describes something quite similar to the slides I submitted to the
Paris meeting.