Dear Shahram, et al., I'd like to take a step back and revisit, I think it might have been discussed, different model. Assume that PTP-capable NEs advertize their capability, i.e. through IGP TE extension, and that MPLS domain is MPLS-TP network. Then a graph of LSPs provisioned to connect PTP-capable NEs. The graph can be used to flood IP-encapsulated PTP or map MS-PW for Ethernet-encapsulated PTP. Do you think that such transport would be sufficient for 1588-over-MPLS?
Regards, Greg On Tue, Nov 22, 2011 at 7:43 AM, Shahram Davari <[email protected]> wrote: > Hi Sasha, > > Good point. This has been pointed out by other as well. It is still > possible to use facility FRR, but now you need 2 FRR tunnels, one Special > FRR tunnel using a PTP label for carrying PTP LSPs and another normal FRR > tunnel for carrying other LSPs. This is possible but not efficient. > > Thanks > Shahram > > -----Original Message----- > From: Alexander Vainshtein [mailto:[email protected]] > Sent: Tuesday, November 22, 2011 7:38 AM > To: Shahram Davari > Cc: [email protected]; [email protected]; [email protected] > Subject: RE: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt > > Shahram, > Lots of thanks for a prompt clarification. > > But doesn't it mean that facility protection mode in FRR is effectively > not applicable to PTP LSPs? > > Regards, > Sasha > > > > -----Original Message----- > > From: Shahram Davari [mailto:[email protected]] > > Sent: Tuesday, November 22, 2011 5:34 PM > > To: Alexander Vainshtein > > Cc: [email protected]; [email protected]; [email protected] > > Subject: RE: [TICTOC] FW: I-D Action: > draft-ietf-tictoc-1588overmpls-02.txt > > > > Hi Sasha, > > > > Good question. We have mentioned in the draft that any label pushed such > > as FRR case must also be a PTP label. We have also provided extension to > > signaling so that labels are identified as being PTP label. > > > > Thanks > > Shahram > > > > -----Original Message----- > > From: Alexander Vainshtein [mailto:[email protected]] > > Sent: Tuesday, November 22, 2011 7:31 AM > > To: Shahram Davari > > Cc: [email protected]; [email protected]; [email protected] > > Subject: RE: [TICTOC] FW: I-D Action: > draft-ietf-tictoc-1588overmpls-02.txt > > > > Shahram, > > I must admit that I have not been following discussions about PTP over > > MPLS, but I would like to clarify an issue that stems from reading your > > response to Stewart. > > > > If I interpret you correctly, you say that, instead of sending PTP in > PWs you > > are going to send them in dedicated LSPs. The advantage is that the > transit > > nodes may derive the need to examine PRP packets by just looking at the > > labels at the top of stack. > > > > The question is: what is supposed to happen if, for some reason, a > transit > > node pushes yet another label on top of what has been originally > allocated > > for a PTP-carrying LSP? FRR (in the facility mode when multiple LSPs > would > > be tunneled in the same bypass) is one valid example IMO, but there could > > be more. > > > > Regards, > > Sasha > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On > Behalf > > > Of Shahram Davari > > > Sent: Tuesday, November 22, 2011 5:21 PM > > > To: [email protected]; [email protected] > > > Cc: [email protected] > > > Subject: Re: [TICTOC] FW: I-D Action: > draft-ietf-tictoc-1588overmpls-02.txt > > > > > > Hi Stewart, > > > > > > Thanks for your valuable input. Since these PTP LSPs are defined to > only > > > carry IP or Ethernet encapsulated 1588 packets, the LSRs could easily > parse > > > them without requiring to know the Payload type per PW label. In other > > > words if the LSP is a PTP LSP then the payload type is knwon and we > don't > > > need to keep the payload type state per PW label. So I don't think we > are > > > doing any layer violation. > > > > > > All an LSR has to do is to go to the BoS and check the first nibble > after BoS > > > label to find out whether payload is IPv4 (nibble = '0100'), IPv6 > (nibble = > > > '0110'), OAM (nibble = '0001') or Ethernet (nibble = '0000') traffic. > Only IP > > and > > > Ethernet traffic needs further parsing to verify the 1588 packets. So > really > > no > > > knowledge of the payload type per PW label is required and therefore I > > > think no layer violation. > > > > > > > > > Best Regards, > > > Shahram > > > > > > > > > > > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On > Behalf > > > Of Stewart Bryant > > > Sent: Tuesday, November 22, 2011 1:13 AM > > > To: [email protected] > > > Cc: [email protected] > > > Subject: Re: [TICTOC] FW: I-D Action: > draft-ietf-tictoc-1588overmpls-02.txt > > > > > > > > > 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 > > > > > > > > > _______________________________________________ > > > TICTOC mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/tictoc > > > > > > This e-mail message is intended for the recipient only and contains > > information which is CONFIDENTIAL and which may be proprietary to ECI > > Telecom. If you have received this transmission in error, please inform > us by > > e-mail, phone or fax, and then delete the original and all copies > thereof. > > > > > > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. > > > > _______________________________________________ > TICTOC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc >
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
