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
