Hi Ron, I agree with your model. It is similar to one I've suggested to consider earlier in our discussion. I think that in this model there's nothing "special" about LSP as it connects TC-capable NEs and no DPI or payload modification required by LSRs.
Regards, Greg On Tue, Nov 29, 2011 at 1:28 PM, Ron Cohen <[email protected]> wrote: > 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
