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]
*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 <[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 reference/draft-ietf-tictoc-1588overmpls/(awaiting PROTO
writeup)as an alternative solution to this problem.
Y(J)S
_______________________________________________
mpls mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
