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:Alexander.Vainshtein@ecitele.com]
> *Sent:* Sunday, December 20, 2015 10:05 PM
> *To:* Yaakov Stein
> *Cc:* draft-ietf-mpls-residence-time@tools.ietf.org
> *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
>
>      *
>
>  4. *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.
>  5. *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.
>  6. *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 <yaakov_s@rad.com <mailto:yaakov_s@rad.com>>
> *Sent:* Saturday, December 19, 2015 7:44 PM
> *To:* draft-ietf-mpls-residence-time@tools.ietf.org 
> <mailto:draft-ietf-mpls-residence-time@tools.ietf.org>
> *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 reference/draft-ietf-tictoc-1588overmpls/(awaiting PROTO
>   writeup)as an alternative solution to this problem.
>
>
>   Y(J)S
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls