headers
lizhong.jin | 1 Jul 2011 13:46
Picon

Re: [mpls] Request comments for HSMP LSP


Hi Edward, Lamberto and all,
Sorry for the later reply. And no, when apply HSMP LSP to VPLS, the path from leaf PE to root PE is exactly the shortest path. mLDP leaf will send mapping message to root node, choosing the path with routing table, and this path is the shortest path from leaf to root.

We have updated the draft with more clarification of the use cases, and added new use case of VPLS application.
You can get the new draft from link: http://tools.ietf.org/html/draft-jin-jounay-mpls-mldp-hsmp-03

Thank you.
Lizhong


>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 9 Jan 2011 02:50:16 +0100
> From: Lamberto Sterling <lamberto.sterling <at> gmail.com>
> Subject: Re: [mpls] Request comments for HSMP LSP
> To: maillist.ed <at> gmail.com, lizhong.jin <at> zte.com.cn
> Cc: l2vpn <at> ietf.org, mpls <at> ietf.org, Ice <ice <at> cisco.com>,
>    tictoc <at> ietf.org,   N.Leymann <at> telekom.de
> Message-ID:
>    <AANLkTi=CbhP10iM7=wXcb=e9oV0cqwaTKjY7ArZquoW1 <at> mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi guys,
> Sorry for the email subject. Change it now.
>
> Lamberto
>
> On Sat, Jan 8, 2011 at 5:19 PM, Lamberto Sterling <
> lamberto.sterling <at> gmail.com> wrote:
>
> > Hi Lizhong, Edward,
> > It seems that it is a good idea to apply HSMP LSP to VPLS, and the
> > broadcast/unicast/unknow packet would be optimized. However, the path from
> > leaf to root may not be the best path compared with current VPLS using P2P
> > LSP, which is not a critical issue.
> >
> > Thanks
> > Lamberto
> >
> >
> >
> >>
> >> ------------------------------
> >>
> >>
> >> Date: Wed, 5 Jan 2011 15:50:45 +0800
> >> From: lizhong.jin <at> zte.com.cn
> >> Subject: Re: [mpls] Request comments for HSMP LSP
> >> To: Ed <maillist.ed <at> gmail.com>
> >> Cc: l2vpn <at> ietf.org, mpls <at> ietf.org, Ice <ice <at> cisco.com>,
> >>        N.Leymann <at> telekom.de,   tictoc <at> ietf.org
> >> Message-ID:
> >>        <
> >> OF4BA0BF75.A883E04C-ON4825780F.002802E4-4825780F.002B2AB9 <at> zte.com.cn>
> >> Content-Type: text/plain; charset="us-ascii"
> >>
> >> Hi Edward,
> >> Thank you for the comments. I add l2vpn maillist in cc list. I agree with
> >> the application you proposed, and in order to improve the scalability of
> >> VPLS, P2MP PW multiplexed to HSMP LSP could be used for VPLS. Actually
> >> this is a good application case for P2MP PW with reverse path (section
> >> 4.4, draft-ietf-pwe3-p2mp-pw-00). We can add some description about this
> >> use case.
> >>
> >> Regards
> >> Lizhong
> >>
> >>
> >> Ed <maillist.ed <at> gmail.com> wrote on 2011-01-05 15:05:30:
> >>
> >> > Hi Lizhong,
> >> >
> >> > I think one possible application for HSMP LSPs is to reduce the
> >> > overall broadcast/multicast utilization on a VPLS. In current VPLS
> >> > implementations with a full mesh of P2P LSPs between PEs, broadcast,
> >> > multicast and unknown traffic are not efficiently propagated on the
> >> > physical links between PEs and Ps.
> >> >
> >> > In the VPLS implementation scenario with HSMP LSPs, each PE signals
> >> > a HSMP LSP with itself as a root to all other PEs in the VPLS.
> >> > Thereafter, all broadcast/multicast/unknown traffic from this PE
> >> > will use this HSMP LSP. Unicast traffic from a particular PE (e.g.
> >> > PE1) to another PE (e.g. PE2) will be sent from leaf to root using
> >> > the HSMP LSP where PE2 is the root.
> >> >
> >> > This simplifies the VPLS implementation by:
> >> > -          Reducing traffic utilization from broadcast, multicast
> >> > and unknown traffic
> >> > -          Reducing the total number of LSPs maintained by each PE
> >> > (i.e. instead of requiring a full mesh of LSPs, now only require one
> >> > HSMP LSP per PE).
> >> >
> >> > This is similar to the idea expressed in  draft-key-l2vpn-etree-
> >> > frwk-03.txt (in a more general sense).
> >> >
> >> > What do you think? Would HSMP LSP be suitable for this?
> >> >
> >> > Regards,
> >> > Edward
> >> >
> >> >
> >> >
> >> > On Wed, Jan 5, 2011 at 5:24 PM, <lizhong.jin <at> zte.com.cn> wrote:
> >> >
> >> > Hi all,
> >> > During IETF 79 Beijing, we made a presentation for HSMP LSP at MPLS
> >> session.
> >> > HSMP LSP has several use cases described in the draft, e.g, time
> >> > synchronization in MPLS network, IPTV scenario, or P2MP PW. It would
> >> > be appreciated if you could give more scenarios for HSMP LSP. Please
> >> > review the draft, and any comments are welcome.
> >> >
> >> > The draft link is: http://tools.ietf.org/html/draft-jin-jounay-mpls-
> >> > mldp-hsmp-01
> >> >
> >> > Thank you.
> >> > Authors of draft-hsmp.
> >> > --------------------------------------------------------
> >> >
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/mpls/attachments/20110109/e5b476e5/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> mpls mailing list
> mpls <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>
> End of mpls Digest, Vol 81, Issue 12
> ************************************
>

-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. 
_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Permalink | Reply | 0 comments |
headers
Tal Mizrahi | 4 Jul 2011 14:00
Favicon

[ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

Hi,

 

I have posted a new draft that discusses Checksum updates in time synchronization protocols.

http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-00

Comments will be welcome.

 

Thanks.

Tal.

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Permalink | Reply | 5 comments |
headers
internet-drafts | 4 Jul 2011 15:08
Picon
Favicon

I-D Action: draft-ietf-tictoc-ptp-mib-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Timing over IP Connection and Transfer of Clock Working Group of the IETF.

	Title           : Precision Time Protocol Version 2 (PTPv2) Management Information Base
	Author(s)       : Vinay Shankarkumar
                          Laurent Montini
                          Tim Frost
                          Greg Dowd
	Filename        : draft-ietf-tictoc-ptp-mib-00.txt
	Pages           : 67
	Date            : 2011-07-04

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in TCP/IP-based internets.
   In particular, it defines objects for managing networks using
   Precision Time Protocol.

   This memo specifies a MIB module in a manner that is both compliant
   to the SNMPv2 SMI, and semantically identical to the peer SNMPv1
   definitions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tictoc-ptp-mib-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tictoc-ptp-mib-00.txt
Permalink | Reply | 0 comments |
headers
Greg Dowd | 11 Jul 2011 17:29
Favicon

Re: [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

Is the use model you envision for NTP to support hardware timestamping at the edge?  In NTP, the addition of an extension field requires the presence of the MAC.  This requires the dissemination and maintenance of keys as well as the defined MAC checking.  How would this model work if the NTP packet did  have the MAC?  This extension field would be covered by the MAC and the authenticator would fail.  Or do you expect this block would have the key info and update the MAC as well?  And, how would it work if the MAC isn’t there.  Would the update not be used?

 

In PTP, there is a TC protocol function which necessitates the modification of the packet.  In NTP, as it is defined as a UDP protocol, there is not as clear a path to how lower stack layers modify the PDUs.

 

If you define this simply at the edge, I’m not sure how much value this additional UDP checksum update adds?  Is there a model you have in mind?

 

 

 

 

From: tictoc-bounces <at> ietf.org [mailto:tictoc-bounces <at> ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: tictoc <at> ietf.org; ntpwg <at> lists.ntp.org
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

Hi,

 

I have posted a new draft that discusses Checksum updates in time synchronization protocols.

http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-00

Comments will be welcome.

 

Thanks.

Tal.

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Permalink | Reply | 4 comments |
headers
Tal Mizrahi | 12 Jul 2011 16:44
Favicon

Re: [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

Hi Greg,

 

Thanks for your feedback.

 

> In NTP, the addition of an extension field requires the presence of the MAC.

[TM] According to RFC5905 “The extension fields are used to add optional capabilities, for example, the Autokey security protocol”. So indeed, the only extension field currently defined is for security purposes, but the current draft proposes to use a newly defined extension field, independent of the MAC usage.

 

> How would this model work if the NTP packet did  have the MAC? 

[TM] The current draft is more useful for cases where the MAC is not used, since this draft is about simplifying the implementation of intermediate nodes. When the MAC is used, it would mean that the intermediate node would have to compute the MAC, and only then to perform the Checksum update.

 

> If you define this simply at the edge, I’m not sure how much value this additional UDP checksum update adds?  Is there a model you have in mind?

[TM] The idea is that the intermediate node (an ASIC/FPGA) assigns the packet’s timestamp field, significantly improving the accuracy. The benefit of this improvement is negligible if the path between the NTP nodes consists of a large number of hops, BUT when there is a small number of hops this improvement is significant. An example use-case I have in mind is in the wireless backhaul, where the RBS and RNC synchronize over a CES, either using PTP or NTP. When NTP is used in this case, high precision is required, and can benefit from timestamping at the intermediate node.

 

Regards,

Tal.

 

From: Greg Dowd [mailto:GDowd <at> symmetricom.com]
Sent: Monday, July 11, 2011 6:29 PM
To: Tal Mizrahi; tictoc <at> ietf.org; ntpwg <at> lists.ntp.org
Subject: RE: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

Is the use model you envision for NTP to support hardware timestamping at the edge?  In NTP, the addition of an extension field requires the presence of the MAC.  This requires the dissemination and maintenance of keys as well as the defined MAC checking.  How would this model work if the NTP packet did  have the MAC?  This extension field would be covered by the MAC and the authenticator would fail.  Or do you expect this block would have the key info and update the MAC as well?  And, how would it work if the MAC isn’t there.  Would the update not be used?

 

In PTP, there is a TC protocol function which necessitates the modification of the packet.  In NTP, as it is defined as a UDP protocol, there is not as clear a path to how lower stack layers modify the PDUs.

 

If you define this simply at the edge, I’m not sure how much value this additional UDP checksum update adds?  Is there a model you have in mind?

 

 

 

 

From: tictoc-bounces <at> ietf.org [mailto:tictoc-bounces <at> ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: tictoc <at> ietf.org; ntpwg <at> lists.ntp.org
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

Hi,

 

I have posted a new draft that discusses Checksum updates in time synchronization protocols.

http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-00

Comments will be welcome.

 

Thanks.

Tal.

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Permalink | Reply | 1 comment |
headers
Greg Dowd | 12 Jul 2011 18:51
Favicon

Re: [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

Hi Tal,

                The MAC is a necessary component in the current protocol when extensions are present.  The parsing of incoming packets uses frame size as mechanism for determining the code path to take in addition to its obvious utility value in autokey.  The relevant section in 5905 is the first sentence in the NTP Extension Field Format section 7.5.

In NTPv4, one or more extension fields can be inserted after the

   header and before the MAC, which is always present when an extension

   field is present.

 

 

From: Tal Mizrahi [mailto:talmi <at> marvell.com]
Sent: Tuesday, July 12, 2011 7:44 AM
To: Greg Dowd; tictoc <at> ietf.org; ntpwg <at> lists.ntp.org
Subject: RE: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

Hi Greg,

 

Thanks for your feedback.

 

> In NTP, the addition of an extension field requires the presence of the MAC.

[TM] According to RFC5905 “The extension fields are used to add optional capabilities, for example, the Autokey security protocol”. So indeed, the only extension field currently defined is for security purposes, but the current draft proposes to use a newly defined extension field, independent of the MAC usage.

 

> How would this model work if the NTP packet did  have the MAC? 

[TM] The current draft is more useful for cases where the MAC is not used, since this draft is about simplifying the implementation of intermediate nodes. When the MAC is used, it would mean that the intermediate node would have to compute the MAC, and only then to perform the Checksum update.

 

> If you define this simply at the edge, I’m not sure how much value this additional UDP checksum update adds?  Is there a model you have in mind?

[TM] The idea is that the intermediate node (an ASIC/FPGA) assigns the packet’s timestamp field, significantly improving the accuracy. The benefit of this improvement is negligible if the path between the NTP nodes consists of a large number of hops, BUT when there is a small number of hops this improvement is significant. An example use-case I have in mind is in the wireless backhaul, where the RBS and RNC synchronize over a CES, either using PTP or NTP. When NTP is used in this case, high precision is required, and can benefit from timestamping at the intermediate node.

 

Regards,

Tal.

 

From: Greg Dowd [mailto:GDowd <at> symmetricom.com]
Sent: Monday, July 11, 2011 6:29 PM
To: Tal Mizrahi; tictoc <at> ietf.org; ntpwg <at> lists.ntp.org
Subject: RE: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

Is the use model you envision for NTP to support hardware timestamping at the edge?  In NTP, the addition of an extension field requires the presence of the MAC.  This requires the dissemination and maintenance of keys as well as the defined MAC checking.  How would this model work if the NTP packet did  have the MAC?  This extension field would be covered by the MAC and the authenticator would fail.  Or do you expect this block would have the key info and update the MAC as well?  And, how would it work if the MAC isn’t there.  Would the update not be used?

 

In PTP, there is a TC protocol function which necessitates the modification of the packet.  In NTP, as it is defined as a UDP protocol, there is not as clear a path to how lower stack layers modify the PDUs.

 

If you define this simply at the edge, I’m not sure how much value this additional UDP checksum update adds?  Is there a model you have in mind?

 

 

 

 

From: tictoc-bounces <at> ietf.org [mailto:tictoc-bounces <at> ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: tictoc <at> ietf.org; ntpwg <at> lists.ntp.org
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

Hi,

 

I have posted a new draft that discusses Checksum updates in time synchronization protocols.

http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-00

Comments will be welcome.

 

Thanks.

Tal.

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Permalink | Reply | 0 comments |
headers
David L. Mills | 13 Jul 2011 19:53
Picon
Favicon

Re: [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

Greg,

The MAC is intended to protect against a message modification attack, which surely is not the object here. In principle, the MAC can be omitted and an extension field can be used in much the same way as a transparent bridge in PTP.

Dave

Greg Dowd wrote:

Is the use model you envision for NTP to support hardware timestamping at the edge?  In NTP, the addition of an extension field requires the presence of the MAC.  This requires the dissemination and maintenance of keys as well as the defined MAC checking.  How would this model work if the NTP packet did  have the MAC?  This extension field would be covered by the MAC and the authenticator would fail.  Or do you expect this block would have the key info and update the MAC as well?  And, how would it work if the MAC isn’t there.  Would the update not be used?

 

In PTP, there is a TC protocol function which necessitates the modification of the packet.  In NTP, as it is defined as a UDP protocol, there is not as clear a path to how lower stack layers modify the PDUs.

 

If you define this simply at the edge, I’m not sure how much value this additional UDP checksum update adds?  Is there a model you have in mind?

 

 

 

 

From: tictoc-bounces <at> ietf.org [mailto:tictoc-bounces <at> ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: tictoc <at> ietf.org; ntpwg <at> lists.ntp.org
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

Hi,

 

I have posted a new draft that discusses Checksum updates in time synchronization protocols.

http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-00

Comments will be welcome.

 

Thanks.

Tal.

_______________________________________________ ntpwg mailing list ntpwg <at> lists.ntp.org http://lists.ntp.org/listinfo/ntpwg 

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Permalink | Reply | 1 comment |
headers
Greg Dowd | 13 Jul 2011 20:22
Favicon

Re: [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

The NTPv4 protocol, and the implementation, currently don’t have the ability to distinguish an extension from a MAC uniquely.  I would rather see a “NOOP” MAC (with keyid 0 or -1) function defined which would let nodes process and drop the frame with auth failure and not a malformed packet. 

 

Looking beyond the protocol state machine, how could we include some indicator in the frame that it had been modified?  Perhaps we could make some extension mandatory?  One issue with the way TCs work in PTP is that they are all doing a read-modify-write against the correction field.  It is not possible to distinguish either the number or the timing characteristics of the elements modifying the time.  In a closed point-to-point protocol like telecom style PTP this is not an issue as the links, and the capabilities of the TC elements, are well-defined and managed.  In NTP, it would be useful to develop a “profile” which would define this NTP application over a controlled or managed network.  It could specifically call out the usage of hardware timestamps where available, the format and/or requirement to generate an extension, the restrictions on use of authenticators or autokey, the impact on the utility value of the dispersion/root distance fields, etc.

 

 

 

Greg Dowd

gdowd at symmetricom dot com (antispam format)

Symmetricom, Inc.

www.symmetricom.com

"Everything should be made as simple as possible, but no simpler" Albert Einstein

From: David L. Mills [mailto:mills <at> udel.edu]
Sent: Wednesday, July 13, 2011 10:54 AM
To: Greg Dowd
Cc: Tal Mizrahi; tictoc <at> ietf.org; ntpwg <at> lists.ntp.org
Subject: Re: [ntpwg] [TICTOC] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

Greg,

The MAC is intended to protect against a message modification attack, which surely is not the object here. In principle, the MAC can be omitted and an extension field can be used in much the same way as a transparent bridge in PTP.

Dave

Greg Dowd wrote:

Is the use model you envision for NTP to support hardware timestamping at the edge?  In NTP, the addition of an extension field requires the presence of the MAC.  This requires the dissemination and maintenance of keys as well as the defined MAC checking.  How would this model work if the NTP packet did  have the MAC?  This extension field would be covered by the MAC and the authenticator would fail.  Or do you expect this block would have the key info and update the MAC as well?  And, how would it work if the MAC isn’t there.  Would the update not be used?

 

In PTP, there is a TC protocol function which necessitates the modification of the packet.  In NTP, as it is defined as a UDP protocol, there is not as clear a path to how lower stack layers modify the PDUs.

 

If you define this simply at the edge, I’m not sure how much value this additional UDP checksum update adds?  Is there a model you have in mind?

 

 

 

 

From: tictoc-bounces <at> ietf.org [mailto:tictoc-bounces <at> ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, July 04, 2011 5:01 AM
To: tictoc <at> ietf.org; ntpwg <at> lists.ntp.org
Subject: [TICTOC] [ntpwg] New draft: draft-mizrahi-tictoc-checksum-trailer-00

 

Hi,

 

I have posted a new draft that discusses Checksum updates in time synchronization protocols.

http://tools.ietf.org/html/draft-mizrahi-tictoc-checksum-trailer-00

Comments will be welcome.

 

Thanks.

Tal.

 

 

_______________________________________________

ntpwg mailing list

ntpwg <at> lists.ntp.org

http://lists.ntp.org/listinfo/ntpwg

 

_______________________________________________
TICTOC mailing list
TICTOC <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
Permalink | Reply | 0 comments |
headers
Karen O'Donoghue | 14 Jul 2011 17:50
Picon
Favicon

draft agenda for ietf81 tictoc meeting

Folks,

Below is a draft agenda for the upcoming tictoc meeting. Please send 
Yaakov and I any changes and additions as soon as possible.

Regards,
Karen

IETF-81 TICTOC WG Agenda
========================

Thursday, 28 July 2011, 1520-1720 EDT
(1940 - 2140 UTC / 1220 - 1420 PDT)

1.   Administrivia and Agenda Bashing

2.   ITU-T SG15/Q13 update

3.   IPsec security for packet based synchronization
      draft-xu-tictoc-ipsec-security-for-synchronization-01

4.   Time Synchronization Protocol Security Requirements

5.   Precision Time Protocol Version 2 (PTPv2) Management Information Base
      draft-ietf-tictoc-ptp-mib-00

6.   Transporting PTP messages (1588) over MPLS Networks
      draft-ietf-tictoc-1588overmpls-01

7.   UDP Checksum Trailer in Timing Protocols
      draft-mizrahi-tictoc-checksum-trailer-00.txt

8.   Network Time Mechanisms for Improving Computer Clock Accuracy
      draft-marlow-tictoc-computer-clock-accuracy-00

9.   Additional NTP Discussion Topics

10.  Wrap-up / Way Forward
Permalink | Reply | 0 comments |
headers
Karen O'Donoghue | 28 Jul 2011 16:51
Favicon

reminder and remote participation information for today's meeting

Folks,

As previously discussed, there will be a face to face meeting of the 
tictoc wg here at IETF 81. Note that I am cross-posting this to the ntp 
wg as well as there is related discussions there.

For remote participation, there is an audio stream to listen and a 
jabber channel for submitting comments/questions. The easiest way to 
directly access the information is: http://tools.ietf.org/agenda/81/
General information is available at: 
http://www.ietf.org/meeting/81/remote-participation.html

IETF-81 TICTOC WG Agenda
========================

Thursday, 28 July 2011, 1520-1720 EDT
(1940 - 2140 UTC / 1220 - 1420 PDT)

1.   Administrivia and Agenda Bashing

2.   ITU-T SG15/Q13 update

3.   IPsec security for packet based synchronization
      draft-xu-tictoc-ipsec-security-for-synchronization-01

4.   Time Synchronization Protocol Security Requirements

5.   Precision Time Protocol Version 2 (PTPv2) Management Information Base
      draft-ietf-tictoc-ptp-mib-00

6.   Transporting PTP messages (1588) over MPLS Networks
      draft-ietf-tictoc-1588overmpls-01

7.   UDP Checksum Trailer in Timing Protocols
      draft-mizrahi-tictoc-checksum-trailer-00.txt

8.   Network Time Mechanisms for Improving Computer Clock Accuracy
      draft-marlow-tictoc-computer-clock-accuracy-00

9.   Additional NTP Discussion Topics

10.  Wrap-up / Way Forward
Permalink | Reply | 0 comments |

Gmane