Dear IPPM (and SPRING) participants,
I'm solliciting interest in a new network monitoring metric which allows to
detect and locate congested interfaces. Important properties are
* Same scalability as ICMP ping in the sense one measurement relation
required per monitored connection
*
Hi Zafar, et al.,
I apologize for the unintended confusion but when I've said that I'll
review the updates I was under the impression (self-imposed) that a new
version has been published already. I'll be glad to review the updates in
the working version and share my notes if you can kindly send it
Hi Pablo,
On Sat, 21 Dec 2019 at 04:38, Pablo Camarillo (pcamaril)
wrote:
>
> Hi Ron,
>
> I guess we are making some progress here but going in some circles. So far we
> have moved from “this violates RFC8200” to “there are no use-cases or
> benefits” to “this is complex for an ASIC” to “what
Yimin,
Again, lots of thanks for a prompt response.
I am adding the SPRING WG list to the distribution of this message, because,
from my POV, it raises an issue that should be answered – one way or another –
by the SPRING experts.
I do not think that agree that End.DT6 requires augmentation
Mark,
The point that you are making has already been addressed at the mailer (and
indeed you have participated in such discussion)
https://mailarchive.ietf.org/arch/msg/spring/pGS5O53VTDSt2tpc7mm3FVVd0Xk/
https://mailarchive.ietf.org/arch/msg/spring/i0faTfqB-NduzI2VyMyQ6R60dQw/
Mark, no need to drag this conversation to the other corner either ..
Pablo pasted the email thread, here once again:
https://mailarchive.ietf.org/arch/msg/spring/yRkDJlXd71k0VUqagM3D77vYcFI/
If you think it's not closed, then go back to the email trail and keep adding
to it. I'm curious to
Gyan,
As I (and other WG members) have explained in the past, PSP is not trying to
provide any feature parity with MPLS.
It enables new use-cases that have been provided by other members in the list.
[1], [2] and [5].
From operational perspective it is not complex as explained in [3].
There is
