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:yakov(_at_)juniper(_dot_)net]
Sent: Tuesday, September 24, 2013 10:27 AM
To: Black, David
Cc: tsv-dir(_at_)ietf(_dot_)org; raggarwa_1(_at_)yahoo(_dot_)com;
y(_dot_)kamite(_at_)ntt(_dot_)com;
lufang(_at_)cisco(_dot_)com; yakov(_at_)juniper(_dot_)net;
ietf(_at_)ietf(_dot_)org; l2vpn(_at_)ietf(_dot_)org;
stbryant(_at_)cisco(_dot_)com; yakov(_at_)juniper(_dot_)net
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 tsv-dir(_at_)ietf(_dot_)org 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(_dot_)black(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------