Shahram I would note three technical points here.
Firstly the normal practice in MPLS is that when you see the label you know precisely what to do, you do not need to take a further parsing decision. Thus IPv4 and IPv4 and PWs all have a label that is signaled to say the type of payload. Parsing the payload to determine type breaks that model. Secondly, the assumption that the payload can only be one of three types breaks the generality of the design, something that we normally try hard in MPLS to preserve. You do not actually need to know the payload type anywhere other than the endpoints if we reduce the midpoints to only recording dwell time in an abstract way. This more general approach would allow the same mechanism to be used for any timing protocol, i.e. NTP, and 1588v3 etc. In other words it would allow us to introduce a new timing type without needing to upgrade the P routers. Finally the normal practice in MPLS is to minimise the actions in the forwarding path, and this design does not represent that minimization. I also made a point about protocol review, and I would really suggest that you should undertake the wider review to make sure you will get buy-in before you take this approach to completion. - Stewart On 22/11/2011 15:20, Shahram Davari wrote:
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
-- 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
