Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00

["Ackermann, Michael" <[e-mail]>]

Hi Mark,
 
Regards to what is being done to track response times in today's V4 networks.   The solutions I am aware of and that are currently run by many enterprises, including my own, are proprietary solutions offered by several different vendors.   All are expensive, complex and require a significant hardware/software infrastructure.   These tools require substantial training and usually protracted professional services contracts to design, set up and customize, for maximum effectiveness within any specific environment.     And of course as others have said, the effectiveness of ALL these tools depends upon accurate time synchronization.  
 
It is certainly not my position to denigrate these tools, as we use them and depend upon them for critical network management information.   However, they are expensive to acquire and operate, and the costs go far beyond financial.   
To add to the effort, expense and overhead, those of us in our 2nd and third generations  with these tools, realize what huge scalability issues exist as we add additional regions, sites, nodes and applications to the mix.   Each requires agents, collectors, and possibly multiple server/DW components.    
 Now Imagine the simplicity, efficiency, accuracy and affordability of something baked right into the protocol as is being proposed in the PDM for IPV6. 
 
My final comment is on the time synchronization we use for these tools today.   In most cases we utilize NTP, which has worked fine for us since we optimized our NTP architecture several years ago.    Not all nodes need to have highly accurate levels of time synchronization.   Some do not need it at all.   NTP lends itself well to these various situations, and enterprises just need to design a NTP infrastructure that achieves the various required Stratum levels for each respective node being monitored.   That can be as easy/cheap as a 3rd level reference clock in a Windows Domain.  Or as accurate as a directly connect Stratum 1 clock source.    Build whatever is required for each needed situation/node.    
 
Hope the above hits on some of the areas you were citing.   In any event I would look forward to exploring some of these areas with you and others jointly.  

Thanks

Mike



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Mark ZZZ Smith
Sent: Sunday, September 01, 2013 12:10 AM
To: Bill Jouris; Randy Bush
Cc: IPv6 Ops WG; Al Morton
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00






>________________________________
> From: Bill Jouris <[e-mail]>
>To: Randy Bush <[e-mail]> 
>Cc: IPv6 Ops WG <[e-mail]>; Al Morton <[e-mail]> 
>Sent: Sunday, 1 September 2013 2:48 AM
>Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00
> 
>
>
>No question that there are lots of systems which do not have their clocks synchronized.  Indeed, a lot of PCs aren't even synchronized to the nearest 10 seconds, let alone anything finer.
>
>
>But then, a lot of PCs aren't in need of synchronization.  Nobody (except maybe the individual user) is concerned about response time for them -- or going to consider doing anything about response times that aren't a matter of tens of minutes, and on an on-going basis.   
>
>
>
>The issue is all of the systems where response times DO matter.  Those clocks do get synchronized already, because there is a need that justifies the effort required to do so.  The challenge then becomes, How do we measure transmission times between those systems once they convert to IPv6?  When there is no way in IPv6 to record those times, that is a problem.  
>

As far as I'm aware there is no way to record those times specifically in IPv4. So how is it being done now in IPv4, "before IPv6"?

I don't think the answer isn't NTP, because NTP runs over UDP, and therefore can and does run over both IPv4 and IPv6.

I don't think the answer is  PTP/IEEE 1588 because that's both a fairly recent development and is only single LAN rather than Internet scale.


>
>
>And this isn't the only approach that is being considered -- just the only one (that I am aware of) which doesn't involve adding extra hardware at the end-points.  (Hardware which will also require some kind of clock synchronization.)
>
> 
>Bill Jouris
>Inside Products, Inc.
>www.insidethestack.com
>831-659-8360
>925-855-9512 (direct)
>
>
>
>
>________________________________
> From: Randy Bush <[e-mail]>
>To: Nalini Elkins <[e-mail]> 
>Cc: IPv6 Ops WG <[e-mail]>; Al Morton <[e-mail]> 
>Sent: Saturday, August 31, 2013 6:01 AM
>Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00
> 
>
>> If you are arguing that time synchronization cannot be done to the
>> millisecond or microsecond level
>
>not arguing.  just trying to explain to you that a lot of engineering
>and research have shown that ntp, pee cees running unix or linux with
>gps, ... do not have millisecond accuracy on stamping packets over the
>net.  folk are trying to save you wasted effort.  
>
>randy
>_______________________________________________
>v6ops mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>_______________________________________________
>v6ops mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops


The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.