Re: [trill] [RTG-DIR] Routing Area Directorate QA review of draft-ietf-trill-transport-over-mpls-02
Kingston Smiler <kingstonsmiler@gmail.com> Sat, 04 March 2017 19:14 UTC
Return-Path: <kingstonsmiler@gmail.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 6B46E129572; Sat, 4 Mar 2017 11:14:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Hj9iq81ZkdZo; Sat, 4 Mar 2017 11:14:47 -0800 (PST)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (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 2CE20129519; Sat, 4 Mar 2017 11:14:47 -0800 (PST)
Received: by mail-wr0-x22b.google.com with SMTP id u48so92845694wrc.0; Sat, 04 Mar 2017 11:14:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GZmSBVorzR7ElOWwi/7Lh6F0ti4i3g4cDuOBRYu9xFA=; b=qeE8H71s/msTi3o19NtpySnbduBxBmyjlh2Ecsg2OFGr9GpXL//ZmUcBRGF/ZEHvs8 dCVaw/s2CXupMlhzw8+f2PGXRtd53r0DP/5ozaz/djcPB/nXnX7nSxcxAfNNebxB9Y27 lfBNazuEU+/oyeZIC6I4naxvcY+yEBeTfqce/01SouDesJtF0jG/lyAT87MxDXTh13J6 tD3rp45EBxsVNQG2DIhf9I4paK8Zc9j5HiClpHAu6QHFStKgKOUVyVlx6hlQoLJZsLij lEw4N1RPthPD3GD2Ghq5b5yCuPCQqnVSg3NZwVfpaihg41edrqQ4vxrssmsgE8rWBmGi RxGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GZmSBVorzR7ElOWwi/7Lh6F0ti4i3g4cDuOBRYu9xFA=; b=bjDOUGuSfFPQgl6UAlnGoIURuXqINYnORU0HMfH3xHFISjQmmrk7364fNp66nDYFlc BANBzznC8YbMqZUqF0O419Tph80djKvhq2vc77Bu1unO1HX5bFGnncBSG4nEj1TYQIXx X+IjSnwXZ96Mts6iPbJ8xhiU9J0tqjPfMjtVPaLQr++9gT6PJT5c6Lcygat7HBplIpuh zWlW52a0AjPUA48FOL0DF8hUgx9gXhk+nLGLBEKMMaU8vNERJa1hWV41WS0n3a8vBz4o OldtAlAq+KV3RCeAXsn848AZ1mvxDnRexN4JuHQlVIOSSutgm4L0YJ++8OD7YNQ20AxP ejMw==
X-Gm-Message-State: AMke39mJOvwQT1c8m7snEOVjw1h1c8DtOiOfVeELbkC+I/wRpyYv6uEr0vcPXoWxKE8hD0iBKY+ijcrQg1N4Hg==
X-Received: by 10.223.161.156 with SMTP id u28mr7678480wru.203.1488654885561; Sat, 04 Mar 2017 11:14:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.153.164 with HTTP; Sat, 4 Mar 2017 11:14:45 -0800 (PST)
In-Reply-To: <058301d2951a$3ae0b920$b0a22b60$@ndzh.com>
References: <8FA0B47D-32C0-41D0-BBDD-35F430DC44EE@nokia.com> <CAA=duU1GQvSgXiiXH9dB9C5wuV+0xXpz4cj1uSvhSMT56Sda5Q@mail.gmail.com> <058301d2951a$3ae0b920$b0a22b60$@ndzh.com>
From: Kingston Smiler <kingstonsmiler@gmail.com>
Date: Sun, 05 Mar 2017 00:44:45 +0530
Message-ID: <CAM4Z69TgMqxETB3H3pY1NJNo3qkKwVqxpuoTA302vOipSEqOrQ@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary="f403045f225ea5aeef0549ec79cb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/vqoP8dKtYUCS21GrG8HJxXrUTjk>
Cc: "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>, 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:14:49 -0000
Hi Andrew and Matthew, Thanks for the review. We are working on the revised draft Regards, S. Kingston Smiler. On Sun, Mar 5, 2017 at 12:35 AM, Susan Hares <shares@ndzh.com> wrote: > 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