Hi Stewart, I don't see how this design is better than the one that we have in the current TICTOC WG document. Let me address the objections that you have raised.
1. Layer Violation Both designs do layer violation. Even yours does, since each LSR has to understand that it's a special MPLS packet and has to deep inspect and modify a few fields in the shim header. I don't think looking at a layer violation is a valid thing to do because transparent clocking by itself is layer violation. Even in the current WG draft if one only implements boundary clocks then there would be no layer violation. 2. Parsing the MPLS payload to determine the kind of packet it is. In the current WG draft you don't need to parse the packet to determine what needs to be done with it. When the LSP was set up you knew the exact offset at which you had to do your rewrite. The LSR knows exactly what it needs to do when it sees the packet with a specific MPLS label. While I will agree that the approach that you have suggested will also work and could also be explored. I don't necessarily see ours not working or it breaking the basic tenets of the MPLS. Cheers, Manav > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Stewart Bryant > Sent: Sunday, November 27, 2011 5:43 AM > To: Yaakov Stein > Cc: '[email protected]' > Subject: Re: [TICTOC] FW: I-D Action: > draft-ietf-tictoc-1588overmpls-02.txt > > Yaakov > > I was not thinking of a particularly radical packet type. > > A label stack, a 64 bit delay field, and then any timing > payload you like (specific details out of scope for the draft). > > The P routers then just add and subtract the current time > from the delay field to update it with the dwell time. > > The Edge will know what the timing payload type is and can > make the TC correction based on the delay field. > > The important point is that this works for any packet type > that needs to know delay, be that a timing payload such as > 1588v2, 1588v3, NTPv4, NTPv5 etc etc. It also as Yaakov notes > works for any other payload type such as a payload that needs > to perform synchronous delivery at multiple disjoint > endpoints, or a 1+1 protection system that is required to > provide synchronied streams etc etc. > > - Stewart > > On 26/11/2011 20:24, Yaakov Stein wrote: > > 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
