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 <sha...@ndzh.com> wrote: > Andrew and Matthew: > > > > Thank you for the review. > > > > Sue > > > > *From:* rtg-dir [mailto:rtg-dir-boun...@ietf.org] *On Behalf Of *Andrew > G. Malis > *Sent:* Monday, February 27, 2017 11:43 AM > *To:* Bocci, Matthew (Nokia - GB) > *Cc:* rtg-...@ietf.org; draft-ietf-trill-transport-over-m...@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.bo...@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 mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
