Yakov,
First of all, thank you for overlooking the "off-by-one" error on
the year :-) -
> > Review Date: September 23, 2012
> > IETF LC End Date: September 23, 2012
Of course, 2013 was intended, twice ;-).
On the two items (both are editorial, IMHO):
> > (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).
I concur, which is why I noted this item as editorial - I don't think
it's an actual issue.
> Furthermore, rfc3032 ("MPLS Label
> Stack Encoding") does cover the MTU issue.
A sentence to that effect (lots of uses of label stacking, MTU effects
are both well understood and not a problem in practice) with a
reference to RFC 3032 should suffice.
> > (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.
I'd suggest an initial sentence:
Replication of traffic within a multicast tree, and flooding
of traffic (see section 14) could be employed as traffic
amplifiers in denial of service attacks.
Followed by a sentence or sentences that list a few important applicable
countermeasures (your choice), explaining why each is applicable and
indicating where each is described (this document, RFC 4761 or RFC 4762).
Thanks,
--David
> -----Original Message-----
> From: Yakov Rekhter [mailto:[email protected]]
> Sent: Tuesday, September 24, 2013 10:27 AM
> To: Black, David
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> Subject: Re: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14
>
> 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 [email protected] 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
> > [email protected] Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> >
