Subject: [bess] Need reviews of bess-multicast-damping [Was: Re: WG Last Call for draft-ietf-bess-multicast-damping-01]

From: Martin Vigoureux <[email-masked]>
Date: Tue, 8 Dec 2015 10:27:24 +0100

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-masked]
>> https://www.ietf.org/mailman/listinfo/bess
>>
>>
>
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>
>

---

From: "VAN DE VELDE, Gunter (Gunter)" <[email-masked]>
Date: Tue, 8 Dec 2015 10:33:25 +0000

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/

---

From: <[email-masked]>
Date: Fri, 18 Dec 2015 17:17:07 +0100

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.

> 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.

> 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.

> 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. ").

> 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…

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.

> 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.

> 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 wh…

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-masked] on behalf of [email-masked]> 
>>>> [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.