Re: [ippm] Magnus Westerlund's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS and COMMENT)

[Henrik Nydell <[e-mail]>]

Understood, yes I believe that is above the STAMP itself. It can be added
as an optional TLV to STAMP if it is desirable to fetch this type of
information from the reflector endpoints.

On Wed, Sep 11, 2019 at 11:36 AM Magnus Westerlund <
[e-mail]> wrote:

> Hi Henrik,
>
> On Wed, 2019-09-11 at 10:30 +0200, Henrik Nydell wrote:
> > See below for PTP/NTP comment
> >
> > On Wed, Sep 11, 2019 at 9:53 AM Magnus Westerlund <
> > [e-mail]> wrote:
> > >
> > > On Tue, 2019-09-10 at 12:43 -0700, Greg Mirsky wrote:
> > >
> > > > >         3.  Section 4.1.1.:
> > > > >         Timestamp is eight octets long field.  STAMP node MUST
> > > > > support
> > > > >       Network Time Protocol (NTP) version 4 64-bit timestamp
> > > format
> > > > >       [RFC5905], the format used in [RFC5357].  STAMP node MAY
> > > > > support
> > > > >       IEEE 1588v2 Precision Time Protocol truncated 64-bit
> > > > > timestamp
> > > > >       format [IEEE.1588.2008], the format used in [RFC8186].
> > > > >
> > > > >         Is the clock source here something that may be relevant
> > > or
> > > > > simply
> > > > >         information the management functions should capture. I
> > > > > think there is a
> > > > >         similar issue to that of RTP faced when it comes to
> > > > > understand what the
> > > > >         timestamp actually represent and thus be used
> > > correctly.
> > > > > RTP clock
> > > > >         source specification is RFC 7273
> > > > >         (https://datatracker.ietf.org/doc/rfc7273/)
> > > >
> > > > GIM>> NTP and PTP encodings have a different interpretation of
> > > the
> > > > Fraction field of the Timestamp field. In my experience, PTP
> > > format
> > > > is native for the data plane, while NTP is more used at the
> > > control
> > > > plane. Original extension to TWAMP has been described in RFC
> > > 8186.
> > >
> > > I think you missunderstood. When I talk about clock source, I am
> > > actually referring to identifying the particular clock that the
> > > node
> > > use to derive the included timestamp from.
> > >
> > > And likely this is a moot point in this document where the clock
> > > source
> > > information belongs in the management layer, e.g. in the YANG data
> > > model.
> >
> >
> > In section 4.1.1 of draft-ietf-ippm-stamp there is a definition of
> > the Z-bit in the error correction field that denotes if the clock
> > source is NTP or PTP
> >
>
> Yes, to be clear I have no issue with if the format is NTP or PTP. That
> was not my comment. It was a comment if the protocol should identify
> which particular NTP or PTP server the node is using. For example for a
> node on my network having NTP based clock it matters if that NTP server
> is sth1.ntp.se which is a stratum 1 server distributing certified
> swedish time, or if I use europe.pool.ntp.org where I would use any NTP
> server part of the pool indicating that they are in europe.
>
>
> However, I am convinced that information is of interest the information
> should be in the management layer.
>
>
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>

-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[e-mail]
<http://accedian.com>
<https://www.facebook.com/accedian/>  <https://twitter.com/Accedian>
<https://www.linkedin.com/company/accedian-networks?originalSubdomain=ca>
<http://www.accedian.com>
*accedian.com <http://accedian.com>*

-- 


Avis de confidentialité

Les
 informations contenues dans le présent 
message et dans toute pièce qui 
lui est jointe sont confidentielles et 
peuvent être protégées par le 
secret professionnel. Ces informations sont 
à l’usage exclusif de son ou
 de ses destinataires. Si vous recevez ce 
message par erreur, veuillez 
s’il vous plait communiquer immédiatement 
avec l’expéditeur et en 
détruire tout exemplaire. De plus, il vous est 
strictement interdit de 
le divulguer, de le distribuer ou de le reproduire 
sans l’autorisation 
de l’expéditeur. Merci.


Confidentiality notice

This

 e-mail message and any attachment hereto contain confidential 
information 
which may be privileged and which is intended for the 
exclusive use of its 
addressee(s). If you receive this message in error,
 please inform sender 
immediately and destroy any copy thereof. 
Furthermore, any disclosure, 
distribution or copying of this message 
and/or any attachment hereto 
without the consent of the sender is 
strictly prohibited. Thank you.