Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-pwe3-static-pw-status-08

[Ben Campbell <[e-mail]>]

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.

[…]