'By sticking to the existing encapsulation, both these cases can be supported' - this assumes that in the intra-carrier case each LSR (not only the edge LSRs) can terminate and regenerate IP/Ethernet PW, which I don't think is true in the general case, i.e. in particular you assume that each LSR has IP and/or Ethernet Interfaces. It seems more plausible for me to assume that each PTP-aware-LSR should be able to terminate and regenerate direct-PTP--over-MPLS messages (or PWs), similar to the assumption that each LSR need to be able to 'terminate and regenerate' OAM messages. Best, Ron
On Thu, Dec 1, 2011 at 11:38 PM, Shahram Davari <[email protected]> wrote: > Hi,**** > > ** ** > > I think that there are 2 cases:**** > > ** ** > > **1) **Intra-carrier: In this case the 1588 is providing a single > 1588 domain timing throughout the carrier’s network for the carrier. The > LERs are Master/Slave or BC. In this case the PTP message is terminated at > LERs and therefore any encapsulation can be used in the network.**** > > **2) **Inter-carrier: In this case Carrier A is just tunneling the > PTP messages of carrier B. Carrier A should not terminate PTP messages and > the LERs are TC (not BC). In this case we have to tunnel carrier B’s PTP > packets that may be Ethernet or IP encapsulated. **** > > ** ** > > The motivation for the draft is to support both cases. By sticking to > existing encapsulation, both these cases can be supported.**** > > ** ** > > Thanks**** > > Shahram **** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Laurent Montini (lmontini) > *Sent:* Thursday, December 01, 2011 10:59 AM > > *To:* Lars Ellegaard; Greg Mirsky > *Cc:* [email protected] > *Subject:* Re: [TICTOC] FW: I-D Action: > draft-ietf-tictoc-1588overmpls-02.txt**** > > ** ** > > Hi Lars,**** > > ** ** > > No misunderstanding.**** > > PTPoUDP/IP – slave/LER-BC/master – PTPo[...]oMPLS — slave/LER-BC-master > — PTPoETH**** > > ** ** > > What do you mean by DPI configuration?**** > > ** ** > > Thx,**** > > Laurent**** > > ** ** > > *From:* Lars Ellegaard [mailto:[email protected]] > *Sent:* jeudi 1 décembre 2011 15:13 > *To:* Laurent Montini (lmontini); Greg Mirsky > *Cc:* [email protected] > *Subject:* RE: [TICTOC] FW: I-D Action: > draft-ietf-tictoc-1588overmpls-02.txt**** > > ** ** > > Hi Laurent**** > > Agree that encapsulations can be different on slave and master side (even > different to different slaves) of a BC.**** > > I don’t follow you here: “As such, LER can receive PTP messages with IP > mapping, and, by implementing BC function, could send the same PTP messages > over an LSP with some MPLS encapsulation and receiving LER can transmit > with Ethernet mapping. “ PTP frames will not pass a BC, but terminated on > the slave side and generated on master side. Maybe I misunderstand?**** > > **** > > I don’t see adding a FRR label as a problem as long as the DPI > configuration is updated.**** > > **** > > Thx**** > > Lars**** > > **** > > **** > > *From:* Laurent Montini (lmontini) [mailto:[email protected]] > *Sent:* 01 December 2011 14:49 > *To:* Lars Ellegaard; Greg Mirsky > *Cc:* [email protected] > *Subject:* RE: [TICTOC] FW: I-D Action: > draft-ietf-tictoc-1588overmpls-02.txt**** > > **** > > Hi Lars,**** > > **** > > Master and slave ports of a BC can have different, distinct encapsulations > (mappings) as long as PTP message information are preserved.**** > > As such, LER can receive PTP messages with IP mapping, and, by > implementing BC function, could send the same PTP messages over an LSP with > some MPLS encapsulation and receiving LER can transmit with Ethernet > mapping. **** > > In this draft, the original encap tends to be preserved over the LSP with > assumption that LER is either an ordinary or a boundary clock. **** > > Actually LER in this draft might be PTP unaware, thus not providing any > timing assistance but only MPLS transport, with the risk to impair the > quality of the timing distribution. **** > > One key point, I guess for all LSRs between two LERs (assuming OC or BC), > is either to use the same encapsulation to keep the timestamp point unique > or to define an unique timestamp point for their residence time > measurement. The first option should be fine for most intra-carrier cases > (except, e.g., when adding a label for FRR tunnel) when the second option > could allow adding extra label e.g., for FRR or CSC in inter-carrier cases. > **** > > **** > > Thanks,**** > > Laurent**** > > **** > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Lars Ellegaard > *Sent:* mardi 29 novembre 2011 22:27 > *To:* Greg Mirsky > *Cc:* [email protected] > *Subject:* Re: [TICTOC] FW: I-D Action: > draft-ietf-tictoc-1588overmpls-02.txt**** > > **** > > Hi Greg**** > > You are of course right.**** > > My point is merely that if the PTP frame arrives at the MPLS network > encapsulated in Ethernet (for example) the other end (PTP application) > would expect the same encapsulation.**** > > I suppose that in princple the Ethernet header could be stripped, the PTP > frame carried in G-Ach, and then a new, identical Ethernet header added > again?**** > > Rgds**** > > Lars**** > > **** > > *From:* Greg Mirsky [mailto:[email protected]] > *Sent:* 29 November 2011 22:15 > *To:* Lars Ellegaard > *Cc:* Ron Cohen; [email protected] > *Subject:* Re: [TICTOC] FW: I-D Action: > draft-ietf-tictoc-1588overmpls-02.txt**** > > **** > > Hi Lars, > I think that non-MPLS portions are outside of scope for 1588 Over MPLS > document. > > Regards, > Greg**** > > On Tue, Nov 29, 2011 at 1:12 PM, Lars Ellegaard <[email protected]> wrote:*** > * > > And there are cases where MPLS transport is only a part of the e2e path*** > * > > **** > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Greg Mirsky > *Sent:* 29 November 2011 22:09 > *To:* Ron Cohen**** > > > *Cc:* [email protected] > *Subject:* Re: [TICTOC] FW: I-D Action: > draft-ietf-tictoc-1588overmpls-02.txt**** > > **** > > 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**** > > **** > > *CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, > is for the sole use of the intended recipient(s) and may contain > confidential and privileged information. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply e-mail and destroy all copies > of the original message.***** > > **** > > *CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, > is for the sole use of the intended recipient(s) and may contain > confidential and privileged information. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply e-mail and destroy all copies > of the original message.***** > > *CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, > is for the sole use of the intended recipient(s) and may contain > confidential and privileged information. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply e-mail and destroy all copies > of the original message.***** > > _______________________________________________ > TICTOC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc > >
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
