[mpls] FW: draft-ietf-mpls-residence-time-00

[Gregory Mirsky <[e-mail]>]

Dear All,
responses to comments by Yaakov.
Appreciate your consideration, comments, questions.

Happy holidays and happy New Year!

                Regards,
                                Greg

From: Alexander Vainshtein [mailto:[e-mail]]
Sent: Sunday, December 20, 2015 10:05 PM
To: Yaakov Stein
Cc: [e-mail]
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.

  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 <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, December 19, 2015 7:44 PM
To: [e-mail]<mailto:[e-mail]>
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