Subject: Re: [mpls] MPLS-RT review of draft-villamizar-mpls-forwarding

From: Gregory Mirsky <[email-masked]>
Date: Mon, 1 Apr 2013 17:59:23 +0000

Hi Curtis,
Thank you for careful consideration of my comments.
I've re-read the 1588overmpls recently and I think that rather than spending our time on wordsmithing what it does or should do in your document I'll turn my attention to the 1588overmpls document. Especially since it is planned for TICTOC WG LC this month.

	Regards,
		Greg 

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Saturday, March 30, 2013 1:36 PM
To: [email-masked]
Cc: Gregory Mirsky; [email-masked]; [email-masked]; Loa Andersson; [email-masked]; Martin Vigoureux; Eric Osborne (eosborne); Thomas Nadeau; Thomas Beckhaus
Subject: Re: MPLS-RT review of draft-villamizar-mpls-forwarding

Greg,

I've added the following (new text following "+" signs):

   PTP or NTP may be carried over MPLS
   <xref target="I-D.ietf-tictoc-1588overmpls" />.  Generally NTP will
   be carried within IP with IP carried in MPLS
   <xref target="RFC5905" />.  Both PTP and NTP benefit from accurate
   time stamping of incoming packets and the ability to insert
   accurate time stamps in outgoing packets.
+  PTP correction which occurs when forwarding requires updating a  
+ timestamp compensation field based on the difference between packet  
+ arrival at an LSR and packet transmit time at that same LSR.

Does this address any remaining PTP issues?

Curtis

In message <[email-masked]>
Curtis Villamizar writes:

In message <[email-masked]>
Gregory Mirsky writes:
 
> Hi Curtis,
>  
> back to our discussion on 1588overMPLS. I've attached slide from deck 
> presented at TICTOC meeting in Orlando as illustration of what I mean 
> by "PTP distribution through MPLS network".
>  
> PTP/NTP Transport over MPLS network can be done without any special 
> PTP LSP (another slide from the same deck)
>  
>  
>         Regards,
>                 Greg

Greg,

Perhaps I am missing your point.  Unless the point it to marvel over the artwork in the otherwise not very informative slides.

There are two encapsulations shown:

    LSP     LSP
    IP      PW
    UDP     CW
    PTP     Ethernet
            PTP

This just makes it a little hard for the midpoint LSR to do the PTP correction field update, but otherwise ... so what.

If the LSP midpoint nodes make no corrections, then accuracy suffers.

The midpoint LSR must either: 1) know that the payload is IP or know that the payload is PW (it doens't today), or guess based on CW or lack of, and 2) know that the packet might contain PTP, and 3) look at every packet in the LSP.

I mentioned in the draft that a timestamp has to be captured when a packet is received and generated and inserted when a packet is sent.
I also mentioned that the offset is variable.  For example in the PW case, the Ethernet header could have a VLAN ID.

The PTP forwarding correction requires updating a timestamp compensation field based on the difference between packet arrival and packet send times.  Perhaps what you are saying is that we don't call out the need to support that difference plus offset (offset by the existing compensation).  Of course, the offset and receive stamp can be added together in software or in less critically time constrained hardware, with the send stamp subtracted as close to packet transmit time as possible.

If that is not what you meant, then what exactly is your point?

Curtis