Hi Ron, I completely agree with your statement. So may be we should introduce 2 models:
1) Intra-SP timing 2) Inter-SP timing (requires tunneling) First model can use Multi-segment LSPs, and second model can use single segment LSP. Regards Shahram From: Ron Cohen [mailto:[email protected]] Sent: Tuesday, November 29, 2011 09:05 PM To: Shahram Davari Cc: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt Hi Shahram, In 1588 over Ethernet the decision was to terminate at any hop (and hence update the source Ethernet MAC address at each TC) in order not to violate layerings. To be precise, this was the decision taken by 802.1(AS) members that use the 802.1 baggy pants layer model and insisted on correct layer processing. The 1588 group was not that strict on layering, and the IP encapsulation TC implementation 'breaks the layers' and updates the PTP field while not updating the source IP address - this is similar to other IP applications like NAT etc. Here in PTP over MPLS we are free to make our own decision; if we want to preserve the layering model we should indeed terminate the LSP at each hop (yes, stitching the LSP together - what's wrong about it?, we need to control the path at each hop to set it across the timing enabled LSRs anyhow), or we can keep the current proposal that setups end to end LSPs and use DPI/Break layers, which is ok too. I personally thought (and still think) that a non-breaking PTP over MPLS encapsulation is a needed option, and since the LSP is terminated at each hop in this option I didn't see any logic to add additional Ethernet/IP layers between the MPLS and PTP layers. I thought that this would also fit in well with ITU's more-strict layer modeling. However, at least at that time, ITU sync experts didn't see the need for running PTP over MPLS for distribution of timing within a provider (which is the problem they were interested in), and the problem mainly addressed by the IETF (as I understand it) is to carry multiple timing streams (not necessarily synched to each other) over a 'carrier-of-carriers' that will still provide TC functionality (See my presentation in TICTOC from the IETF in the Netherlands a while back), and for this problem setting end to end LSPs seems to be the right approach (and hence 'breaking the layers'). So basically it depends which problem you want to solve and how strict we want to be with regards to layering. Best, Ron On Wed, Nov 30, 2011 at 12:20 AM, Shahram Davari <[email protected]<mailto:[email protected]>> wrote: Ron, If the LSP is not terminated at a hop and any field inside the packet is updated, that to me is a LV. Unless you are proposing to create one hop LSPs and stitch them together, which I don't think is practical. 1588 over Ethernet and IP updates CRC and HECs and why can't the same be done in mpls. Thx SD Thx Shahram From: Ron Cohen [mailto:[email protected]<mailto:[email protected]>] Sent: Tuesday, November 29, 2011 01:28 PM To: Greg Mirsky <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt Since the approach is that the LSP is signaled as timing-only LSP, PTP can be carried on its own PW hop by hop. The point is that the layer violation is in the assumption that the Ethernet PW/ IP over MPLS runs end to end and the TC fiddles with the PTP bits in mid transit. If the circuits are terminated and regenerated at the TC there is no layer violation. On Tue, Nov 29, 2011 at 11:08 PM, Greg Mirsky <[email protected]<mailto:[email protected]>> wrote: Dear Ron, need to point that only IP and MPLS payload can be carried over MPLS natively, directly. Any other payload, including Ethernet, would require PW. Perhaps PTP can be carried over G-ACh? Regards, Greg On Tue, Nov 29, 2011 at 1:00 PM, Ron Cohen <[email protected]<mailto:[email protected]>> wrote: If the encapsulation was directly over MPLS, i.e. no Ethernet / IP layers in between MPLS and PTP, there were no layers to violate.... On Tue, Nov 29, 2011 at 8:35 PM, Anthony Magee <[email protected]<mailto:[email protected]>> wrote: Hi Yaakov, The layer violation issue is something which I believe needs further discussion. If a higher layer entity is placed inside a device and is used to act as the Transparent Clock i.e. calculating residence time and modifying the correction field in the layer with which that higher layer entity is associated, one could use an identifier such as a label, or a multicast Destination address in order to address that higher layer entity, allowing it to make the change without it being a layer violation. Then on the transmit side, there is nothing specifically incorrect in a device modifying the Source Address of the packet sent from a Transparent Clock within the scope of IEEE 1588 and this would be needed in order to indicate that the device has effectively created a new packet - however, the function of the node is still that of a Transparent Clock. So as long as the various standards are observed and the modifying devices update the packets in a standards compliant manner, I don't see that such a Transparent Clock would constitute a layer violation. Anthony -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Yaakov Stein Sent: 26 November 2011 20:25 To: [email protected]<mailto:[email protected]>; Shahram Davari Cc: '[email protected]<mailto:[email protected]>' Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt Shahram and Stewart If we need intermediate MPLS nodes to perform special processing on 1588oMPLS packets there are several methods to lower the processing requirements. Of course, DPI could be performed to go below the MPLS and IP headers as Shahram said, but as Stewart pointed out this would be prohibitively expensive. Two methods have been proposed. The method of the present draft is to use the standard encapsulations (after ensuring that 1588 is supported) and to inform the intermediate nodes that the particular label value being used is special. For this special label value the node has been informed of what to do, e.g., has the offset of a TC. Any use of TC is necessarily a layer violation (after all, the timestamp is a layer-0 entity and we are placing it in a layer 2 or higher field), but correcting a field inside 1588 in UDP in IP in MPLS is not really that much worse than correcting on in 1588 in UDP in IP in Ethernet. The alternative method that I proposed is to invent a completely new timestamping mechanism. This has the advantage of being applicable to all MPLS packets (and thus can solve other problems), but requires inventing yet another timing distribution protocol. I know that Stewart succeeded in inventing a new packet loss and delay measurement protocol for TP, but I didn't gauge support in TICTOC for something new here. Y(J)S -----Original Message----- From: Stewart Bryant [mailto:[email protected]<mailto:[email protected]>] Sent: Thursday, November 24, 2011 19:30 To: Shahram Davari Cc: '[email protected]<mailto:[email protected]>'; '[email protected]<mailto:[email protected]>' Subject: Re: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt Shahram I will ponder the answer to this question, but will note that you have not addressed my second question which relates to whether there is MPLS WG buy-in for this proposal. - Stewart On 24/11/2011 16:34, Shahram Davari wrote: > Hi Stewart, > > The parsing required by the draft is not complex and almost all MPLS routers > have support it already. The idea was to reuse existing data plane mechanisms > and not invent a new one. This I believe is in the spirit of IETF to reuse > existing mechanisms. > > I don't believe adding a shim makes the design simpler. You still need to > detect that such shim exists and for that you need parsing that doesn't even > exist today. > > > This draft has been implemented by vendors, so we have a working code and I > believe we also have rough consensus. > > Thanks > Shahram > > > > ----- Original Message ----- > From: Stewart Bryant [mailto:[email protected]<mailto:[email protected]>] > Sent: Thursday, November 24, 2011 07:58 AM > To: > [email protected]<mailto:[email protected]><[email protected]<mailto:[email protected]>> > Cc: > [email protected]<mailto:[email protected]><[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]><[email protected]<mailto:[email protected]>> > Subject: Re: [TICTOC] FW: I-D Action: > draft-ietf-tictoc-1588overmpls-02.txt > > Can we wind back to my original points here which have not addressed. > > Why are is the WG proposing a design that needs such complex parsing, > against the ethos of MPLS, when a simpler design would be more > universally applicable? > > Does the WG have any input to suggest that the design will survive a > review by MPLS/PWE3 WG and then by IESG? > > - Stewart > > > On 22/11/2011 09:12, Stewart Bryant wrote: >> Speaking as an individual here, I really have a hard time >> understanding why it is necessary to have quite the egregious layer >> violation that this draft uses. >> >> The idea of having an LSP type that is dedicated to tracking the time >> of passage through the network is a good idea. However MPLS is >> completely geared to the concept that only the LSP endpoints know how >> to resolve the payload type. >> >> The function that you require could be achieved by including a shim >> that contains the time compensation information and adjust the >> payload on egress from the LSP. That would be rather more consistent >> with the MPLS architecture. >> >> I have not seen a request for review by the MPLS or PWE3 WGs and I >> would suggest that you request that sooner rather than later since it >> is inevitable that the draft will be sent there later in it's life, >> and if they do not subscribe to your mode of operation the draft is >> unlikely to progress. >> >> I would also suggest that you discuss the extent of layer violation >> with your AD to make sure he is confident that this draft will pass >> IESG review. >> >> - Stewart >> >> >> _______________________________________________ >> TICTOC mailing list >> [email protected]<mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/tictoc >> > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ TICTOC mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
