>From the draft:
===
> The mechanism described in this document is considered useful for network
> scenarios in which
> the required number of NRP is small, as no control protocol extension is
> required. For network
> scenarios where the number of required NRP is large, more scalable solution
Support.
As the mechanism described in the draft has already been implemented by the
three
largest vendors of ISP-class routers, and that software has been deployed in
real networks
today, we better document this asap in an RFC.
henk.
> On 11/17/2023 6:23 PM CET Yingzhen Qu wrote:
>
Hi Tony,
> Yes, I'm advocate for putting things elsewhere, but that proposal has
> met with crickets. You don't get it both ways: no capabilities in the
> protocol and nowhere else does not work.
I'm not sure I know what you are talking about.
Did you write a draft?
> Because the thought of
Hi Tony,
> Some exist today. There are many TLVs where they have never been specified.
My point was: multipart TLVs exist today, before the introduction of the
capability advertisement. So when you look at a LSPDB, you still don't know for
sure which routers support multipart TLVs. Some might,
Hi Tony,
> If we want to introduce MP-TLVs, that change would warrant the existence of
> the flag.
Multipart TLVs already exist today.
As discussed here, after introducing a "software capability TLV", if a router
doesn't
advertise any of those new capabilities, we still don't know
I object the introduction of a new major concept, called "zone".
It adds nothing to solve problems we can not already solve.
It just adds unnecessary complexity and technical debt.
(12) In protocol design, perfection has been reached not when there
is nothing left to add, but when there is
Hello Tianran,
Warning, long email again.
What's the criterion to evaluate the benefit?
As people have asked before, did any provider or
enterprise ever use rfc8099 in their network ?
As I wrote, one of my criteria is rfc1925. I like
technology to be understandable. I like protocols to
be
Huaimo Chen wrote on 2020-07-14 06:09:
2). IS-IS TTZ abstracts a zone to a single node. A zone is any target
block or piece of an IS-IS area, which is to be abstracted. This seems
more flexible and convenient to users.
I don't agree that this convenience is really beneficial.
I actually
It’s very clear that this is inadequate.
It's not so clear to me, sorry.
Does anyone have an example (link or jpg) of a (sensible) topology
that would not work with multiple levels of hierarchy, but works
nicely/better with area-proxies (or FRs) ? Just curious.
The structure of legacy
IS-IS
I support the area-proxy draft.
I think both the area-proxy draft and the flood-reflection drafts are
a bit hacky. However, the result of the area-proxy draft has a certain
elegance: only one L2 LSP per area in the backbone.
The flood-reflection draft is just messy, imho.
1) The edge-routers
Mitchel wrote:
IS-IS has two levels of neighbors via hello level 1s (LSAs) and hello
level 2s :, so immediate is somewhat relative..
As Tony said, Level-2 neighbors are still directly adjacent.
There might be layer-2 switches between them.
But there are never layer-3 routers between 2
On Friday I wrote:
I still think we'll end up re-implementing a new (and weaker) TCP.
Christian Hopps wrote 2020-05-04 01:27:
Let's not be too cynical at the start though! :)
I wasn't trying to be cynical.
Let me explain my line of reasoning two years ago.
When reading about the
Hello all,
Two years ago, Gunter Van de Velde and myself published this draft:
https://tools.ietf.org/html/draft-hsmit-lsr-isis-flooding-over-tcp-00
That started this discussion about flow/congestion control and ISIS
flooding.
My thoughts were that once we start implementing new algorithms
Hello Les,
Thanks for taking the time to respond.
[Les:] Base specification defines partialSNPInterval (2 seconds).
Clearly w faster flooding we should look at decreasing this
timer - but we certainly should not do away with it.
That was the point I was trying to make:
You kept mentioning
Les Ginsberg (ginsberg) schreef op 2019-07-23 22:29:
It is a mistake to equate LSP flooding with a set of independent P2P
“connections” – each of which can operate at a rate independent
of the other.
Of course, if some routers are slow, convergence in parts of the network
might be slow. But
Hello Robert,
Tony brought up the example of a partioned network.
But there are more examples.
E.g. in a network there is a router with a 1000 neighbors.
(When discussing distributed vs centralized flooding-topology
reduction algorithms, I've been told these network designs exist).
When such
Hello Les,
Les Ginsberg (ginsberg) wrote on 2019-07-24 07:17:
If you accept that, then it makes sense to look for the simplest way
to do flow control and that is decidedly not from the RX side. (I
expect Tony Li to disagree with that – but I have already
outlined why it is more complex to
Les Ginsberg (ginsberg) wrote 2018-11-07 17:06:
The problem that RFC6213 tries to solve is a case where one of the
neighbors is thinking that the other does not support BFD. And thus
the lack of BFD is not used as an indication that something is wrong.
Right ?
[Les:] This is not correct.
Jeffrey Haas wrote 2018-11-07 20:56:
I guess my question to those who live in IGP land is how often is this
a
problem? In the case of an IGP, the backpressure means you have
databases
that are out of sync and end up with bad forwarding.
As discussed below, if you have multiple flooding
Hi Jeff,
Jeffrey Haas wrote on 2018-11-06 05:20:
I'm ambivalent of the transport, but agree that TCP shouldn't be the
default
answer.
I picked TCP because every router has a working TCP implementation.
And TCP is good enough for BGP. And thus also considered good enough
for LSVR. If
nt all its CSNPs yet ? With reliable transport for LSPs and
SNPs these worst-case scenarios will improve.
Apologies for the long text.
I hope it explains our goals and proposal a bit more.
henk.
Les
-Original Message-
From: Lsr On Behalf Of Henk Smit
Sent: Monday, November 05, 2
Thanks, Tony.
We picked TCP because every router on the planet already has a TCP stack
in it.
That made it the obvious choice.
Our draft described a TVL in the IIHs to indicate a router's
ability to use TCP for flooding.
That TLV has several sub-TVLs.
1) the TCP port-number
2) an IPv4
22 matches
Mail list logo
