> a) Check if there is anything hindering the evolution of this draft to
> an RFC.
was i unclear?
> the draft passed wglc in 1948. it is awaiting two
> implementations, as is the wont of the idr wg.
randy
On 9/17/20 1:51 PM, Douglas Fischer wrote:
But 30 Seconds for an IXP? It does not make any sense!
Those packets are stealing CPU cycles of the Control Plane of any
router in the LAN.
Especially given how some exchanges lock the mac address of
participants. You could probably get away with ARP
If you look just to the normal situations...
1.2K vs 576K may not represent very much.
But if you look tho ARP Requests Graphs on a significative topology
changing on a big IXP, and also look to CPU-per-process graphs, maybe what
I'm suggesting could be more explicit.
I'm talking of good boxes fr
On Thu, 17 Sep 2020 at 20:51, Douglas Fischer wrote:
> Why should we spend CPU Cycles with 576K ARP Requests a day(2K participants,
> 5 min ARP-Timeout).
> Instead of 1.2K ARP Requests a day(2K participants, 4 hours ARP-Timeout)?
> I would prefer to use those CPU cycles to process other things l
Well...
My idea with the initial mail was:
a) Check if there is anything hindering the evolution of this draft to an
RFC.
b) Bet in try to make possible a thing that nowadays could be considered
impossible, like:
"How to enable the BFD capability on a route-server with 2000 BGP
Sessions withou
About this comparison between CAM-Table Timeout, and ARP-Table Timeout.
I tend to partially agree with you...
Ethernet is a so widely used protocol to sever scenarios.
We need to consider the different needs of the type of communications.
For example:
I'm not a big fan of Mikrotik/RouterOS.
But
MPLSoUDP is not the technology you should be looking at, SRoUDP (RFC8663) is.
draft-bookham-rtgwg-nfix-arch describes an architecture that makes use of it to
provide an end2end SR path.
Cheers,
Jeff
On Sep 17, 2020, 9:32 AM -0700, James Bensley ,
wrote:
>
>
> On 17 September 2020 11:05:24 CEST,
On 17/Sep/20 19:36, mark seery wrote:
Private line was a common term for leased lines. Leased lines were not
encrypted by the operator, AFAIK. This terminology morphed to virtual
private line, Ethernet Private Line, virtual private LAN service
(VPLS), etc.
"In telecommunication, a privat
> On Sep 17, 2020, at 9:24 AM, Mark Tinka wrote:
>
>> For operators already offering FR/ATM services, it was a replacement, using
>> the same principles of traffic separation over a common infrastructure,
>> without encryption as part of the service. So from that perspective only, it
>> was
> On Sep 17, 2020, at 8:28 AM, Mark Tinka wrote:
>
>
>
> On 16/Sep/20 23:22, Anoop Ghanwani wrote:
>
>> It depends on the definition of VPN. In terms of services like
>> MPLS-based VPNs, it refers to the extension of a Private network
>> over a shared infrastructure, allowing entities usi
On 17 September 2020 11:05:24 CEST, Saku Ytti wrote:
>On Thu, 17 Sep 2020 at 11:03, James Bensley
>wrote:
>
>> MPLSoUDP lacks transport engineering features like explicit paths,
>FRR LFA and FRR rLFA, assuming only a single IP header is used for the
>transport abstraction [1]. If you want stu
On 17/Sep/20 17:56, mark seery wrote:
For operators already offering FR/ATM services, it was a replacement, using the
same principles of traffic separation over a common infrastructure, without
encryption as part of the service. So from that perspective only, it was not
much of a change f
On 17/Sep/20 01:30, Łukasz Bromirski wrote:
And that’s fine. The fact that some Intellectual Property[1] was created
by one vendor or another (disclaimer - I work for Cisco) shouldn’t be
by default something that discredits the idea. And BTW, if You look into
the history of how SR started, it
On 16/Sep/20 23:22, Anoop Ghanwani wrote:
It depends on the definition of VPN. In terms of services like
MPLS-based VPNs, it refers to the extension of a Private network
over a shared infrastructure, allowing entities using the shared
infrastructure to have their own private address space and
Spot on.
And on the point of protection ... in all cases it is orthogonal to the
service itself. If you want to use it you enable it regardless if your
packet's transport is IPv4, IPv6, MPLS or any SR flavor.
Sure if you need to traffic engineer your services some form of path
control is required
On Thu, 17 Sep 2020 at 11:03, James Bensley wrote:
> MPLSoUDP lacks transport engineering features like explicit paths, FRR LFA
> and FRR rLFA, assuming only a single IP header is used for the transport
> abstraction [1]. If you want stuff like TI-LFA (I assume this is supported in
> SRm6 and
>
> If the traffic is that important then the public internet is the wrong
> way to transport it.
Nonsense.
It is usually something said by those who do not know how to use Internet
as a transport in a reliable way between two endpoints.
In your books what is Internet good for ? Torrent and por
On 16 September 2020 23:51:03 CEST, Robert Raszuk wrote:
>Hi Ron,
>
>> If you want an IPv6 underlay for a network offering VPN services
>
>And what's wrong again with MPLS over UDP to accomplish the very same
>with
>simplicity ?
>
>MPLS - just a demux label to a VRF/CE
>UDP with IPv6 header pl
18 matches
Mail list logo
