Hi,
Thanks for the response. Some comments inline. I removed sections that seem to
be resolved.
Thanks!
Ben.
On Oct 7, 2011, at 6:21 PM, Luca Martini wrote:
Ben,
Thank you for the review .
Some comments below.
Luca
On 10/04/11 16:13, Ben Campbell wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments you
may receive.
Document: draft-ietf-pwe3-static-pw-status-08
Reviewer: Ben Campbell
Review Date: 2011-10-04
IETF LC End Date: 2011-10-05
Summary: The draft is almost ready for publication as a proposed standard,
but there are a few minor issues and editorial issues that need addressing
first.
Major issues:
None
Minor issues:
-- 5.3:
Has the work group considered how the retransmit scheme and 30 second
refresh default will scale to very large deployments? Seems like this could
result in a lot of retransmissions.
Yes. that is correct. This will most likely not scale for large deployments.
We have another document draft-ietf-pwe3-status-reduction-00.txt that
addresses this issue.
That extension is not necessary for most common small deployments in the
order of 100 PWs per access PE.
That's reasonable--a few words to that effect might be helpful.
[…]
-- 5.3.1, 1st paragraph: "The receiving PE will then set its timeout timer
according to the timer value that is in the packet received, regardless of
what timer value it sent."
It's probably worth making a normative statement here, since it seems like
this could easily result in an argument if the PEs disagree on the timer
value.
An argument between who ?
Between the sending and receiving PE.
I see a problem is the fact that we need to state a good practice
implementation policy.
Basically the PE should not insist on the value that was just refused.
I'll add some text to clarify this.
What that what you intended ?
Something along those lines, yes.
[…]
-- 5.5, last paragraph:
This could use some elaboration. What is the purpose of having to send both
ways?
Keep the state of S-PEs in sync between LDP and the in-band bypass mode.
That is what is stated here.
S-PEs are PE that are in the middle of the path. They can also originate
PW status messages , but only using LDP.
There is fairly complicated state machine described in rfc6073 that
would break if the messages are not sent in LDP as well.
That makes sense. A sentence to that effect might be helpful (but not
absolutely required)
[…]
-- 8 : IANA Considerations
It would help to include the formal definition tables here, or reference
them here. Also, can you include the URLs for each registry?
Tables have always been called out by name. What are "formal definition
tables" ?
I do not understand this comment. Iana section is quite clear.
I meant figures instead of tables. But on reflection, I should have said
"sections". For example, section 5.1 of this draft formally defines the PW OAM
message. It would be helpful if the IANA consideration section for PW OAM
referred back to that section. A reader who is tracing back to an RFC from an
IANA definition will often start out looking in the IANA consideration section,
and such a reference makes things a bit friendlier when the definition is in
another section of the document.
[…]
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf