Stewart, I have seen a reference to an ITU-T Q13/15 work item about partial on-path support in a presentation<http://www.ietf.org/proceedings/86/slides/slides-86-tictoc-8.pdf> from the TICTOC WG session at IETF-85. I have no idea what happened with this item after that; in particular, I have not seen My gut feeling says that you may well be right when you say “all bets are off”, but I defer who know better.
Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected] From: mpls [mailto:[email protected]] On Behalf Of Stewart Bryant Sent: Wednesday, December 23, 2015 2:44 PM To: Gregory Mirsky; [email protected]; [email protected] Subject: Re: [mpls] FW: draft-ietf-mpls-residence-time-00 On 22/12/2015 23:27, Gregory Mirsky wrote: Dear All, responses to comments by Yaakov. Appreciate your consideration, comments, questions. Happy holidays and happy New Year! Regards, Greg From: Alexander Vainshtein [mailto:[email protected]] Sent: Sunday, December 20, 2015 10:05 PM To: Yaakov Stein Cc: [email protected]<mailto:[email protected]> Subject: Re: draft-ietf-mpls-residence-time-00 Yaakov, Lots of thanks for your comments. I have not yet discussed these comments with my colleagues, so I can only speak for myself. Please see below some personal (and incomplete responses). 1. Standard vs. Experimental track: I believe this is for the WG chairs and Routing ADs to decide, and we shall follow their guidance. 2. The term/phrase "on-path support": Makes sense to me, the Introduction section looks like a reasonable place to add it. 3. What happens if only some nodes support RTM: As I see it, there are two possible aspects of this question: * MPLS-wise, the TTL-based mechanism defined in the draft guarantees that only the nodes that support RTM handle the residense time-related info. The non-supporting nodes simply forward the labeled packet in the usual way. * Synchronization-wise: I defer to my colleagues to answer what is the impact of partial on-path support on the quality of synchronization. I would think this was best expressed as "all bets are off" - Stewart * 1. Discussion of proposed control plane updates with the relevant WGs: I believe this is for the WG chairs and Routing ADs to decide, and we shall follow their guidance. Personally I think that keeping of the elements of a solution in one document is preferable to distributing them across multiple documents, each with its own overhead. 2. Replacing the term "scratch pad": I can live with a different name for this field - "That which we call a rose/By any other name would smell as sweet". If you have any specific suggestion, it would help. 3. Reference to draft-ietf-tictoc-1588overmpls: I believe that this should be an Informational reference, and I do not have any problems with adding it. I also think that such references should be reciprocal. I think that your comments can be handled together with the rest of the WG LC comments. Is this OK with you? Regards, and, again, lots of thanks for your careful review. Sasha ________________________________ From: Yaakov Stein <[email protected]<mailto:[email protected]>> Sent: Saturday, December 19, 2015 7:44 PM To: [email protected]<mailto:[email protected]> Subject: draft-ietf-mpls-residence-time-00 Authors, I am no longer subscribed to the MPLS list, and so am sending you my comments directly. I previously asked for a use case or cases justifying the need for a mechanism for residence time correction over MPLS. The MPLS WG people who commented on the TICTOC draft insisted on it being EXPERIMENTAL in status mainly for this reason. I object to this draft being standards track for the same reason. This draft corresponds to what is called in TICTOC “on-path support”. It would be useful to use the phrase to help people understand what is being proposed. How do existing networks have to be modified to exploit this draft? What happens if only some nodes support this draft (partial support)? Section 4 has a list of control protocol upgrades. When we were advancing the aforementioned TICTOC WG draft we were told that this work needed to be carried out within or at least with active participation of the relevant WGs, such as OSPF, ISIS, and CCAMP. I objected to the use of the term “scratch pad” for a field which was dedicated entirely to TCF. I see that this terminology remains in https://tools.ietf.org/html/draft-ietf-mpls-residence-time-00 . Please referencedraft-ietf-tictoc-1588overmpls (awaiting PROTO writeup) as an alternative solution to this problem. Y(J)S _______________________________________________ mpls mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
