Re: [trill] [RTG-DIR] Routing Area Directorate QA review of draft-ietf-trill-transport-over-mpls-02
"Susan Hares" <shares@ndzh.com> Sat, 04 March 2017 19:09 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB759129580; Sat, 4 Mar 2017 11:09:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.946
X-Spam-Level:
X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2B9SrD7e7jG; Sat, 4 Mar 2017 11:09:55 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C26CE129519; Sat, 4 Mar 2017 11:09:54 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.29;
From: Susan Hares <shares@ndzh.com>
To: "'Andrew G. Malis'" <agmalis@gmail.com>, "'Bocci, Matthew (Nokia - GB)'" <matthew.bocci@nokia.com>
References: <8FA0B47D-32C0-41D0-BBDD-35F430DC44EE@nokia.com> <CAA=duU1GQvSgXiiXH9dB9C5wuV+0xXpz4cj1uSvhSMT56Sda5Q@mail.gmail.com>
In-Reply-To: <CAA=duU1GQvSgXiiXH9dB9C5wuV+0xXpz4cj1uSvhSMT56Sda5Q@mail.gmail.com>
Date: Sat, 04 Mar 2017 14:05:02 -0500
Message-ID: <058301d2951a$3ae0b920$b0a22b60$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0584_01D294F0.520CD400"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGCA568JvJrW7wv57ie05NblKPEFwJ1BxMKohKE4IA=
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/3KxkWVFRQRg8Yg4FF7yaprB5RkI>
Cc: rtg-dir@ietf.org, draft-ietf-trill-transport-over-mpls@ietf.org, trill@ietf.org
Subject: Re: [trill] [RTG-DIR] Routing Area Directorate QA review of draft-ietf-trill-transport-over-mpls-02
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Mar 2017 19:09:57 -0000
Andrew and Matthew: Thank you for the review. Sue From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Andrew G. Malis Sent: Monday, February 27, 2017 11:43 AM To: Bocci, Matthew (Nokia - GB) Cc: rtg-dir@ietf.org; draft-ietf-trill-transport-over-mpls@ietf.org; trill@ietf.org Subject: Re: [RTG-DIR] Routing Area Directorate QA review of draft-ietf-trill-transport-over-mpls-02 I’ve got some comments on Matthew’s review, inline. On Mon, Feb 27, 2017 at 10:44 AM, Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com> wrote: Routing Area Directorate QA review of draft-ietf-trill-transport-over-mpls-02 Hi, I have been assigned the QA reviewer for this draft. The general guidelines for QA reviews can be found at: https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa These state: "When reviewing a draft at WG Adoption, the QA Reviewer should determine whether the draft is readable, understandable, makes sense and is a good start for a WG draft. Any issues the QA Reviewer finds are written down, sent to the mailing list and discussed for future versions" Here is my review of this draft: ** Summary. Generally, the draft is well written - thank you. I have a few minor comments below, mostly related to the relationship between TRILL over MPLS and established VPLS mechanisms. ** Is the draft readable? Yes. There are a few minor grammatical errors and it would help if the draft was proof-read to weed-out these. An example is: Abstract "..that are separated by MPLS provider network." s/by MPLS/by an MPLS ** Is the draft understandable? Yes, provided the reader is familiar with TRILL, MPLS and VPLS. ** Does it make sense? I think it is mostly clear, but I have a few comments, as follows: Section 3.4. MPLS encapsulation for VPLS model "Use of VPLS [RFC4762] to interconnect TRILL sites requires no changes to a VPLS implementation, in particular the use of Ethernet pseudowires between VPLS PEs. A VPLS PE receives normal Ethernet frames from an RBridge (i.e., CE) and is not aware that the CE is an RBridge device. As a result, an MPLS-encapsulated TRILL packet within the MPLS network will use the format illustrated in Appendix A of [RFC7173]." It doesn't look like the encapsulation shown in Appendix A of RFC7173 takes account of the case where PBB VPLS [RFC7041] is used in the provider's MPLS network, but I would have thought this would still be a valid VPLS type to transport TRILL. It might be worth qualifying your reference with some text to state that this is just an example in the non-PBB case. Andy: As the author of this paragraph, I agree with Matthew’s comment. We can change the last sentence to say: "As an example, an MPLS-encapsulated TRILL packet within the MPLS network will use the format illustrated in Appendix A of [RFC7173] for the non-PBB case, or in the PBB case, with the additional header fields illustrated in [RFC7041]." Section 4.1.1: "TIR devices are a superset of the VPLS-PE devices defined in [RFC4026] with the additional functionality of TRILL." Is this really true? Later you state that TIRs use PPP PWs, not the Ethernet PWs used in VPLS. It is also not clear if TRILL needs some of the LDP or BGP signaling extensions used for VPLS. Wouldn't it be cleaner just to define a TIR as a new kind of PE? Andy: I also agree with this comment. Section 6. VPTS Model Versus VPLS Model "An issue with the above rule is that if a pseudowire between PEs fails, frames will not get forwarded between the PEs where pseudowire went down." I think this is only true for a simple full mesh VPLS where there are not other protection mechanisms. I am not sure this is applicable to H-VPLS with PW redundancy, for example, which I think is likely to be a widespread deployment case for the VPLS model of TRILL over MPLS. Andy: I agree. In addition, see section 4.4 of RFC 4742, which allows the use of spanning tree in a VPLS network to provide redundancy in the case of a failure in the VPLS. Best regards Matthew Cheers, Andy
- [trill] Routing Area Directorate QA review of dra… Bocci, Matthew (Nokia - GB)
- Re: [trill] [RTG-DIR] Routing Area Directorate QA… Andrew G. Malis
- Re: [trill] [RTG-DIR] Routing Area Directorate QA… Susan Hares
- Re: [trill] [RTG-DIR] Routing Area Directorate QA… Kingston Smiler
- Re: [trill] [RTG-DIR] Routing Area Directorate QA… Kingston Smiler
- Re: [trill] [RTG-DIR] Routing Area Directorate QA… Andrew G. Malis
- Re: [trill] [RTG-DIR] Routing Area Directorate QA… Mohammed Umair
- Re: [trill] [RTG-DIR] Routing Area Directorate QA… Andrew G. Malis
- Re: [trill] [RTG-DIR] Routing Area Directorate QA… Mohammed Umair
- Re: [trill] [RTG-DIR] Routing Area Directorate QA… Andrew G. Malis