[PWE3] Fwd: tsv-dir review of draft-ietf-pwe3-fat-pw-06

"Andrew G. Malis" <amalis@gmail.com> Sun, 22 May 2011 21:26 UTC

Return-Path: <agmalis@gmail.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 186EDE066A for <pwe3@ietfa.amsl.com>; Sun, 22 May 2011 14:26:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9GVO1GOGN7o for <pwe3@ietfa.amsl.com>; Sun, 22 May 2011 14:26:51 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1D28DE0651 for <pwe3@ietf.org>; Sun, 22 May 2011 14:26:50 -0700 (PDT)
Received: by qwc23 with SMTP id 23so4045079qwc.31 for <pwe3@ietf.org>; Sun, 22 May 2011 14:26:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=zYDpF9IG82k4SW85V3lxOuimpj5XRsYXqhOjBUewJwA=; b=VQmExpBSpq/BkkKtj+zd4r+Rctw+AJpmWgUrCIKTA6A0kQnISIOXszgDd4MDGP1QqO B9M+rKXDYdNk1HqIqz8ZETCdkkJ8aj2TQdBTd5FvLOB3nhEN5C+oXtR5tvJpOPZNaO/e 1RfjJAKW+VYImK4iyKBZdXf0kDx5tAOKdgfzI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; b=Zz6UJO91J9PKb/xUajqb3wrSZvgA5tSDPbsbbmhcXs+jV4sfJQnaYkoF2jaRGQla3i +mOpLtKxhSQKauRKg/t65pkBBq+1KwHpbZOkUKBpfZv3f+p5eSkvALa0XAX2rlNGij8b QS4FTgYh2rNyd8sPPw3dwhvWNL37Q8Yb2ILbE=
Received: by 10.229.52.34 with SMTP id f34mr1165955qcg.275.1306099610242; Sun, 22 May 2011 14:26:50 -0700 (PDT)
MIME-Version: 1.0
Sender: agmalis@gmail.com
Received: by 10.229.184.9 with HTTP; Sun, 22 May 2011 14:26:30 -0700 (PDT)
In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05E6A0F3@PALLENE.office.hd>
References: <AcwWKCW9msdBC8rsRp2Fg158oYElsQ==> <791AD3077F94194BB2BDD13565B6295D05E6A0F3@PALLENE.office.hd>
From: "Andrew G. Malis" <amalis@gmail.com>
Date: Sun, 22 May 2011 17:26:30 -0400
X-Google-Sender-Auth: fcA8clbdNfDskvgiEHKGIMNWeV4
Message-ID: <BANLkTimWTJ6GM9L8c8E1rFAwsVx-8Uvn9Q@mail.gmail.com>
To: pwe3@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: [PWE3] Fwd: tsv-dir review of draft-ietf-pwe3-fat-pw-06
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: Sun, 22 May 2011 21:26:52 -0000

All,

I just noticed that this hadn't been sent to the pwe3 list, so I'm
forwarding it for completeness.

Cheers,
Andy

---------- Forwarded message ----------
From: Rolf Winter <Rolf.Winter@neclab.eu>
Date: Thu, May 19, 2011 at 9:24 AM
Subject: tsv-dir review of draft-ietf-pwe3-fat-pw-06
To: "draft-ietf-pwe3-fat-pw@tools.ietf.org"
<draft-ietf-pwe3-fat-pw@tools.ietf.org>
Cc: "tsv-area@ietf.org" <tsv-area@ietf.org>, "ietf@ietf.org"
<ietf@ietf.org>, "tsv-dir@ietf.org" <tsv-dir@ietf.org>


Hello,

I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. The authors should consider
this review together with any other last-call comments they receive.
Please always CC tsv-dir@ietf.org if you reply to or forward this
review.

Generally, this is a well written document. This draft is basically
ready for publication, but has a few nits the authors might consider
before publication.

And here go my comments. First a few on the content but most are
purely editorial.


CONTENT:

Section 3 says:
"If a flow LSE is present, it MUST be checked to determine whether it
carries a reserved label.  If it is a reserved label the packet is
processed according to the rules associated with that reserved label,
otherwise the LSE is discarded."
However section 1.2 states:
"Note that the flow label MUST NOT be an MPLS reserved label."
Isn't that a contradiction to a certain extend. I mean, if there is a
reserved label in the flow LSE, isn't that an error and should not be
processed?

section 8.4:
The second bullet in the section under: "The issues described above
are mitigated by the following two factors:". I wonder whether that
isn't a bit farfetched. I mean, in principle you suggest that
customers could change e.g. the way their applications behave to let
the ingress PE to be able to better apply the flow label. That sounds
like asking a customer to change something on their application end to
have a better network connectivity.

section 8.5.
Isn't a bigger problem here that you cannot guarantee that the OAM
packets follow the same ECMP path and that violates the fate sharing
requirement?

section 12:
You essentially say that the behaviour of IP packets are well defined
regarding congestion and nothing needs to be done. Other payload needs
to be dealt with by PW congestion avoidance (whatever that means). So
IP packets that are not reacting to congestion (such as UDP) are no
concern but other packets with the same behaviour are? Is that a
correct reading of the text?


EDITORIAL:

Abstract:
Remove the "END" at the end.

Intro:
page 3. first para: s/equipments[RFC4385]/equipments [RFC4385]/
page 3. first para: s/times )/times)/
page 3. fourth para: s/the type PW/the type of PW/
page 3. fourth para: s/[RFC5286] ./[RFC5286]./

section 1.2:
page 5. first para: s/which knows flow LSE/which knows a flow LSE/

section 2:
s/identify flows/identifies flows/

section 4:
page 7: s/is unable process/is unable to process/

section 4.1:
page 8: s/(seeSection 11 )/(see Section 11)/
page 8: s/T= 0/T=0/

section 7:
s/Ingress and Egress PE's/ingress and egress PEs/

section 8.1:
page 12: s/past[I-D.stein-pwe3-pwbonding]/past [I-D.stein-pwe3-pwbonding]/

section 8.3:
page 12: s/An example of such a case is the of the/An example of such
a case is the one of the/ or /An example of such a case is the/

section 8.4:
Option one says: "The operator can choose to do nothing and the system
will work as it does without the flow label."
Isn't this option to not use the flow label. If so a better wording
would maybe be: "The operator can choose to do nothing, i.e. to not
employ the flow label"
Option 3: 2/flows,/flows./

Why is section 9 not section 8.7? I mean it is concerned with
applicability which is what section 8 is about.

section 9:

s/This is can be regarded as/This can be regarded as/

section 10:

s/be will preceded/be preceded/

section 12:

s/multiple ECMP/multiple ECMPs/

Best,

Rolf


NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
London W3 6BL | Registered in England 2832014