David,
> 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. When done at the time of IETF Last Call, the authors
> should consider this review together with any other last-call comments
> they receive. Please always CC tsv-dir@xxxxxxxx if you reply to or
> forward this review.
Thanks for your review.
> Document: draft-ietf-l2vpn-vpls-mcast-14
> Reviewer: David L. Black
> Review Date: September 23, 2012
> IETF LC End Date: September 23, 2012
>
> Summary: This draft is basically ready for publication, but has nits that
> should be fixed before publication.
>
> This draft describes multicast optimizations for VPLS via use of MPLS
> multicast distribution trees within the service provider (SP) network.
>
> In general, the techniques in this draft are an improvement, as they
> should typically result in reduction of SP network traffic required
> to carry the same level of multicast traffic originating from the VPLS
> edges. I have reviewed primarily for transport-related topics; while
> I don't have the expertise to review for MPLS and VPLS concerns, I'm
> confident in the expertise of this author team in those technologies.
>
> I found a couple of items that are effectively editorial:
>
> (1) The techniques in this draft appear to add an MPLS label to the
> stack in order to identify the MPLS multicast tree. Does that added
> label raise any MTU concerns in practice?
No more than any other use of label stacking (and there are plenty
of other uses of label stacking). Furthermore, rfc3032 ("MPLS Label
Stack Encoding") does cover the MTU issue.
>
> (2) Two techniques used by this draft - replication of traffic within
> a multicast tree, and flooding of traffic (section 14) - could be
> employed as traffic amplifiers in denial of service attacks. A short
> discussion of this possibility and the applicability of countermeasures
> described in this draft, RFC 4761 and/or RFC 4762 would be good to
> add to the security considerations section.
The Security Consideration section already talks about 4761 and 4762:
Security considerations discussed in [RFC4761] and [RFC4762] apply to
this document.
Suggestion on any additional text would be greatly appreciated.
Yakov.
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA 01748
> +1 (508) 293-7953 FAX: +1 (508) 293-7786
> david.black@xxxxxxx Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
>