Hi, I had had a read through the document. I think it is a nice clear document which is well written and is to me ready for publication. Below are a few topics that crossed my mind when digging through the text. I leave it to the authors/WG to identify if they are idnits or more serious considerations which need more text before submitting.
Section 3. The procedures described in this document allows the network operator to configure multicast VPN PEs so that they can delay the propagation of multicast state prune messages, when faced with a rate of multicast state dynamicity exceeding a certain configurable threshold. GV> This is the delay of Prune towards the SP side and the customer side? Maybe interesting to point out if its dampening towards the C’side or the P’side of the PE. To be practical, such a mechanism requires configurability, in particular, needs to offer means to control when damping is triggered, and to allow delaying a multicast state Prune for a time increasing with the churn of this multicast state. GV> Would it make sense to spell out the exact trade-off that is made here? Dynamicity vs SP state-stability? Section 4.2: These mechanisms are not considered suitable to meet the goals spelled out in Section 1 <https://tools.ietf.org/html/draft-ietf-bess-multicast-damping-01#section-1>, the main reasons being that: GV> What about adding a line specifying that fiddling with these timers does Not give independent control to the SP to control Backbone state dynamicity? Section5.1: Figure-of-merit: …. GV> Maybe an explanation why exponential back off is used compared to a simple linear trigger would be interesting. While I know exponential back off alto’s are used a lot and see the benefit of adaptive back-off, it is maybe interesting to document in the draft or make a reference to a description why exponential back off is selected? Section 6.2: GV> In the realm of SDN and EVPN I see many of these EVPN’s be dynamic in location and existence (spin’d up on-demand) in the DC… There are even drafts to make an Ethernet fully virtual by means of Virtual Ethernet Segments… I was wondering how this proposal impacts the operation within this technology realm. My first guess will be more as additional (more as average) BW consumption at the benefit of less state dynamicity inside the core… Maybe different set of configured parameters for this environment can be suggested? Section 7.1: In the context of multicast VPNs, these procedures would be enabled on PE routers. Additionally in the case of C-multicast routing based on BGP extensions ([RFC6514 <https://tools.ietf.org/html/rfc6514>]) these procedures can be enabled on ASBRs, and possibly Route Reflectors as well. GV> What does “possibly” mean? Can it be used? Or can it not be used? Does the possible means that there are some considerations? Section 9: Security Considerations GV> I agree with the text.. One item is that cast may stream longer to points in the network it is not-desired. Is there potential for leaked multicast streams due to highly dynamic service VPNs which may of converged faster as the Multicast pruning due to dampening? Be well, G/ On 08/12/15 10:27, "BESS on behalf of Martin Vigoureux" <[email protected] on behalf of [email protected]> wrote: >WG, > >we are reiterating the request below; we would highly appreciate reviews >from the WG before moving forward. > >Thank you >M&T > >Le 21/11/2015 01:29, Martin Vigoureux a écrit : >> WG >> >> This WG LC has ended some time ago but without any comment on the draft. >> It might not have any flaw but I'd like to have the evidence that the >> document has been reviewed. >> Please take a moment to read it and get back to this list to share your >> views. >> >> Thanks >> -m >> >> >> Le 13/10/2015 15:40, Martin Vigoureux a écrit : >>> Hello Working Group, >>> >>> This email starts a Working Group Last Call on >>> draft-ietf-bess-multicast-damping-01 [1] which is considered mature and >>> ready for a final working group review. >>> >>> Please read the document if you haven't read the most recent >>> version yet, and send your comments to the list, no later than >>> *27th of October*. >>> >>> *Coincidentally*, we are also polling for knowledge of any IPR that >>> applies to draft-ietf-bess-multicast-damping, to ensure that IPR has >>> been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, >>> 3669 and 5378 for more details). >>> >>> *If* you are listed as a document author or contributor of >>> draft-ietf-bess-multicast-damping-01 please respond to this email and >>> indicate whether or not you are aware of any relevant IPR. >>> >>> Thank you, >>> M&T >>> >>> [1] https://tools.ietf.org/html/draft-ietf-bess-multicast-damping-01 >>> >>> _______________________________________________ >>> BESS mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/bess >>> >>> >> >> _______________________________________________ >> BESS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/bess >> >> > >_______________________________________________ >BESS mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
