David,
> 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.
How about if I'll add the following at the end of 5.5:
Aggregation procedures would require two labels stack.
This does not introduce any new implications on MTU,
as even VPLS multicast supported by ingress
replication requires two labels stack.
> > > (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.
I'll add this.
> 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).
I would greately appreciated if you would help me with "a sentence
or sentences" to cover this. I don't think RFC4761 or RFC4762
describe any of such countermeasures.
Yakov.
>
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:yakov@xxxxxxxxxxx]
> > Sent: Tuesday, September 24, 2013 10:27 AM
> > To: Black, David
> > Cc: tsv-dir@xxxxxxxx; raggarwa_1@xxxxxxxxx; y.kamite@xxxxxxx;
> > lufang@xxxxxxxxx; yakov@xxxxxxxxxxx; ietf@xxxxxxxx; l2vpn@xxxxxxxx;
> > stbryant@xxxxxxxxx; yakov@xxxxxxxxxxx
> > Subject: Re: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-1
4
> >
> > 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
> > > ----------------------------------------------------
> > >
> > >
>
>