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

Ben Campbell <ben@nostrum.com> Mon, 10 October 2011 18:08 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470C421F8C13; Mon, 10 Oct 2011 11:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.3
X-Spam-Level:
X-Spam-Status: No, score=-100.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LIST=2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n31n6cwuGwgQ; Mon, 10 Oct 2011 11:08:18 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AC56321F8BFB; Mon, 10 Oct 2011 11:08:18 -0700 (PDT)
Received: from dn3-53.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p9AI8F5k091675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Oct 2011 13:08:17 -0500 (CDT) (envelope-from ben@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset="windows-1252"
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <4E8F896A.4040305@cisco.com>
Date: Mon, 10 Oct 2011 13:08:15 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <D9934090-B1F6-4F5F-9333-8B39C446DA7C@nostrum.com>
References: <65E76746-02D2-4116-8306-7A41B425D50F@nostrum.com> <4E8F896A.4040305@cisco.com>
To: Luca Martini <lmartini@cisco.com>
X-Mailer: Apple Mail (2.1244.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
X-Mailman-Approved-At: Tue, 11 Oct 2011 08:03:46 -0700
Cc: "gen-art@ietf.org Review Team" <gen-art@ietf.org>, "PWE3 WG (E-mail)" <pwe3@ietf.org>, draft-ietf-pwe3-static-pw-status.all@tools.ietf.org, The IETF <ietf@ietf.org>
Subject: Re: [PWE3] [Gen-art] Gen-ART Last Call Review of draft-ietf-pwe3-static-pw-status-08
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Oct 2011 18:08:19 -0000

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.

[…]