Re: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

[Alexander Vainshtein <[e-mail]>]

Manay,
Please see some answers inline below.

Regards,
     Sasha

> -----Original Message-----
> From: Bhatia, Manav (Manav) [mailto:[e-mail]]
> Sent: Friday, July 19, 2013 11:12 AM
> To: Alexander Vainshtein; S. Davari
> Cc: [e-mail]; [e-mail]
> Subject: RE: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls
> 
> Hi Sasha,
> 
> > 1) reserved label is not backward compatible with existing routers. One
> > of the requirements is that routers that are not PTP aware can just
> > switch the packet normally.  Using a reserved label can't achieve this
> > requirement, since routers that don't understand it will drop it or
> > sent it to CPU.
> > [[Sasha]]  Is not this concern  applicable to any new reserved label?
> > And routers that use network processors as forwarding engines could
> > easily overcome this issue by upgrading their microcode.
> > But I agree that this is a valid concern.
> 
> This is a huge concern because not all routers use network processors that can
> be reprogrammed.
> 
> The current solution works with any router that can set up an MPLS path.
> 
> >
[[[Sasha]]]  I have already stated that backward compatibility of the solution is a valid concern.
However, I do not believe this concern is really huge.
I suspect that presence of routers that are not capable for providing on-path support for PTP represents a problem by and of itself when it comes to accurate recovery of ToD. I defer to ITU-T SG15 that is now working on "partial on-path support for PTP" to decide what - and under what restrictions - one could expect in this scenario. 
Meanwhile, as you say, the routers that do not support extended special purpose labels would most probably send the packets with such labels on top of the label stack for SW processing; and SW usually is upgradeable. So the outcome would be additional unaccounted for delay generated by non-compliant routers - but it would be there in any case, right?

>>
> > 2) there are multiple encapsulations for PTP such as Ethernet with
> > optional VLAN or UDP/IP. An intermediate LSR doesn't know the whether
> > the payload is IP or Ethernet or VLAN. This means for each PTP
> > encapsulation type you probably need a different reserved label.
> > [[Sasha]] IMHO and FWIW support of PTP over UDP/IP would suffice in the
> > absolute majority of cases.
> >
> > 3) the area director has asked us to create a more generalized way of
> > carrying timing over MPLS to be usable with new timing protocols that
> > need TC. Using reserved label would require different reserved label
> > for each new timing protocol.
> > [[Sasha]] I do not think so. "New timing protocols" would be hopefully
> > still run on top of UDP/IP and hence could be easily identifiable by
> > looking at the appropriate UDP port.
> 
> That's bordering on speculation. The current solution is oblivious to a new
> timing protocol. Today it can be used for both PTP and NTP. With reserved
> labels, we will need a new label (and a firmware upgrade) each time a new
> protocol needs to be supported.
> 
[[[Sasha]]] I do not understand this statement. On-path support has to be aware of the specific clock distribution protocol for which it provides support to be of any use in "transit" nodes (e.g., it should now where the "correction field" or its analog sits within the packet).
If you want this support to be multi-protocol, then your HW has to be multi-protocol as well, and some form of protocol identification is required.
> >
> > 4) the extended reserved label draft is fairly new and didn't exist
> > when this draft was progressing.
> > [[Sasha]] This is definitelt true. But it does not justify (for me)
> > setting up dedicated LSPs for timing distribution.
> 
> No offence, am trying to understand - whats the problem that you see with
> setting up a dedicated LSP for timing distribution?
> 
[[[Sasha]]] One use case (which i see as a real one) is clock distribution across a BGP/MPLS VPN instance that combines delivery of traffic to/from eNodeB (mobile backhaul) with delivery of ToD to these nodes. 

> Cheers, Manav


This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.