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