Re: [trill] [RTG-DIR] Routing Area Directorate QA review of draft-ietf-trill-transport-over-mpls-02

["Andrew G. Malis" <[e-mail]>]

I’ve got some comments on Matthew’s review, inline.

On Mon, Feb 27, 2017 at 10:44 AM, Bocci, Matthew (Nokia - GB) <
[e-mail]> 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