Hi Greg, I'm with you. In 'we' I meant the IETF as a standard body, not the TICTOC WG. The 1588 group delegated the definition of 1588-over-Foo to the standard body that is responsible for the 'Foo' transport. Since I believe IETF has the responsibility for 'Foo'=MPLS, its the IETF decision how to standardize the processing of PTP over MPLS and whether to define a specific PTP-over-MPLS encapsulation. Best, Ron
On Wed, Nov 30, 2011 at 7:49 AM, Greg Mirsky <[email protected]> wrote: > Hi Ron, > you've said: > "Here in PTP over MPLS we are free to make our own decision ..." > If by "we" you understand TICTOC WG, then I think I strongly disagree. As > Stewart pointed out the MPLS WG must review and agree to the proposed > mechanism. Thus "we" is the IETF. And even if proposed mechanism to be > accepted then it would not be applicable to Packet Transport Networks as > these are clearly do not allow Layer Violation. > > Regards, > Greg > > > On Tue, Nov 29, 2011 at 9:05 PM, Ron Cohen <[email protected]> wrote: > >> 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]>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]] >>> *Sent*: Tuesday, November 29, 2011 01:28 PM >>> *To*: Greg Mirsky <[email protected]> >>> *Cc*: [email protected] <[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]>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]>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] >>>>> > 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]] On >>>>>> Behalf Of Yaakov Stein >>>>>> Sent: 26 November 2011 20:25 >>>>>> To: [email protected]; Shahram Davari >>>>>> Cc: '[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]] >>>>>> Sent: Thursday, November 24, 2011 19:30 >>>>>> To: Shahram Davari >>>>>> Cc: '[email protected]'; '[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]] >>>>>> > Sent: Thursday, November 24, 2011 07:58 AM >>>>>> > To: [email protected]<[email protected]> >>>>>> > Cc: [email protected]<[email protected]>; >>>>>> > [email protected]<[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] >>>>>> >> 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] >>>>>> https://www.ietf.org/mailman/listinfo/tictoc >>>>>> _______________________________________________ >>>>>> TICTOC mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/tictoc >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> TICTOC mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/tictoc >>>>> >>>>> >>>> >>> >> >
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
