[HC]: We have made it clear in the document through revising the texts.
When a periodical LSP is configured, the paths for all the scheduled
intervals of the LSP is computed once.
If there is no path for some (e.g., one) of the intervals,
the constraints for the periodical LSP is not satisfied and
the LSP will not be set up at all.
Section 4.4, second paragraph, last sentence: If the path cannot be set, is the
previous LSP left in effect? Or does the failure result in no there being no
scheduled LSPs in effect?
[HC]: We have added the texts explicitly stating that
the previous LSP will not be impacted if the path for new
requirements cannot be set.Section 5.1 first paragraph: Why is TCP called out here?
[HC]: We have removed TCP.
You should be explicit about whether it's ok to have both grace periods and
elastic bounds at the same time. The TLV allows that to happen. I'm not sure
what it would mean, and I suspect it's unlikely that you would have two
implementers compute the consequences the same way.
[HC]: We have added some texts to say that only one of them is used.
Section 5.2.1, definition of the R bit: You should call out that relative time
is in seconds (I think?) when the R bit is 1, and you need a discussion
somewhere about the necessity of synchronized clocks and potential problems
with transmission delay when the R bit is 1.
[HC]: You are right. The relative time is in seconds.
We have explicitly stated this and had some discussions about
synchronizing clocks and potential problems with transmission delay.Section 5.2.1, definition of Start-Time: Why must a value of 0 not be used? Is
this true for both R=1 and R=0? For R=1, a start time value of 1 vs a start
time value of 0 may, in practice, be indistinguishable (because of transmission
or processing delay).
[HC]: When R=1, Start-Time=0 means right now.
Because of transmission and processing delay, this cannot be achieved.
