[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
- [PWE3] Fwd: tsv-dir review of draft-ietf-pwe3-fat… Andrew G. Malis