Hi Gunter, all,
VAN DE VELDE, Gunter (Gunter) :
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.
First thank you very much for this review.
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.
Answers below.
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.
Ok, we can explain that the direction which is dampened it PE->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?
I think the introduction already explain the kind of tradeoff that is
implied:
"This document describes procedures, remotely inspired from existing BGP
route damping, aimed at protecting these control planes while at the
same time avoiding negative effects on the service provided, although at
the expense of a minimal increase in average of bandwidth use in the
network."
I will add " This will allow control the tradeoff made between
minimizing the dynamicity and reducing bandwidth consumption." to the
paragraph of section 3 that you quote.
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?
I don't understand your suggestion (the control of state dynamicity
would not be independent of what ?).
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 algo’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?
Although we could make some guesses, and possibly end up guessing well,
if we were to try to explain we would have to speculate what were the
reasons for such an algo to be chosen for unicast BGP damping, beyond
what RFC2439 already says ("An exponential decay function has the
property that previous instability can be remembered for a fairly long
time. ").
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?
The question of route dampening in these context is relevant I think
(even for IP VPNs, not only E-VPNs), but this goes much beyond the scope
of the document (which is focused on multicast) and applies to all type
of routes (not only to P-tunnel related routes addressed in section 6.2).
I don't think we can reasonably address the whole issue in this document.
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?
I will remove "possibly", which does not add any information already
present in the document.
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?
I'm not sure I follow the scenario you describe, but I don't see a
potential for traffic to leak beyond what is acceptable from an ACL
standpoint.
Best,
-Thomas
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
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
