Hi Les,
Comments inline.
Les Ginsberg (ginsberg) schreef op 2018-11-07 05:09:
1)IS-IS PDUs are sent directly over layer 2 - whereas TCP (or other
transport) are sent over Layer3.
This means we have a potential fate sharing issue where IIHs (which
continue to be sent over Layer 2 in your proposal (as I understand it)
may be successfully exchanged but the transport session set up to send
LSPs/SNPs may fail. This is the exact issue RFC 6213 has addressed.
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 ?
When using TCP, both neighbors are aware that they want/need to use TCP.
Because both advertise the capability in a TVL in the IIH.
So this problem won't occur. The solution of RFC 6213 is to include
a new BFD-TLV in the IIHs. Well, our proposal also includes a TLV in
the IIH. Same solution.
Another thing that might be noteworthy is that we propose to use
ISIS-Flooding-over-TCP only on p2p interfaces. Because we believe
that the majority of large IS-IS networks (in data-centers at least)
will configure all their ethernet-interfaces to be p2p.
The problem-description in section 2 in RFC6213 seems to indicate
a situation with 3 routers (A, B and C) connected via one interface.
Correct ? So that's a multi-point interface. If we would want to do
Flooding-over-TCP on multi-point interfaces, we will need a much
more complex algorithm (involving the DIS, and potentially a
backup DIS too). Not worth it, imho. The benefits of this proposal
is that a) it's simple, and b) it's using existing technology (TCP).
What should happen if IIHs are being successfully exchanged, the
neighbors both indicate support for the extension, but the transport
session fails to come up or goes down?
Would you follow similar behavior to RFC 6213 i.e., bring the
adjacency down? If so, how would you determine when you can bring the
adjacency up?
That is a good question.
I appreciate you have indicated this as TBD in Section 7.6 of the
draft, but you also say in Section 7.5 that adjacency should NOT go
down when transport session fails - which implies we can have an
ongoing condition where an adjacency is up but
flooding cannot be done- which is a pathological condition.
My gut feeling says we should not tear down the adjacency.
What if two routers can exchange IIHs and do proper flooding of
LSPs. But they can not exchange IP packets ? This could happen.
IS-IS does not have a way to deal with this. IS-IS would keep
advertising the link to the rest of the network. And blackhole
traffic. But people have never complained about this risk before.
Why ? My guess is that implementations are good enough that we
know ip-forwarding almost works. It is my opinion that we can
be just as sure that TCP between two directly connected routers
will work just as good. If not, it's probably a bug. Just as likely
that ip-forwarding won't work between the same two routers.
The reason I propose to not tear down the adjacency is that it
makes other things much more complex. The state of the TCP connection
itself would introduce new state that makes it harder to do things
like non-stop-forwarding, graceful restart, process restarts,
fail-over to a hot-standby 2nd control-plane, etc.
2)Your statements regarding existing flooding limitations of IS-IS are
rather dated. Many years ago implementations varied from the base
specification by allowing much faster flooding and contiguous flooding
bursts on an interface in support of fast convergence. There are
existing and successful deployments of an instance with thousands of
neighbors and thousands of nodes in a network and sub-second
convergence is supported. So the statement that the existing protocol
per interface flooding is a blocking factor in highly meshed
topologies is not (IMO) accurate. The more accurate characterization
of the flooding problem in dense topologies is the amount of redundant
flooding (i.e., a node may receive many copies of a new LSP) - which
your proposal does nothing to address (I understand it was not
intended to address this problem which you discuss in a different
draft).
I worked on IS-IS in the nineties. Yes, my knowledge is outdated.
However, I've not seen any RFC or draft or documents that indicate
how to do better flooding. That means implementors have to reinvent
the wheel. Packet-pacing, high-bandwidth, back-pressure, etc will
steer implementations towards proprietary solutions that will resemble
things that TCP does. If so, why not use TCP ? Or another existing
transport protocol that does even better ?
We're trying to solve flooding issues. In very dense networks. And
in networks with many routers. The requirements document that I read
earlier this year mentions 10k routers. Tony Li suggested last month
to me that flooding algorithms should be able to deal with situations
where single routers have 1k adjacencies. If we want to improve the
protocol, I think we should also improve the situation where we need
to flood 10k LSPs over a single adjacency. That's the problem we try
to solve here.
My point here is that there are existing implementations which would
get no benefit from your proposal. It might be argued that someone
writing a new implementation may find it simpler to make use of a
transport mechanism like TCP - but I do not think there is compelling
data that demonstrates that the scalability of an implementation using
your proposal is better than that of many existing implementations.
When I worked at cisco in the nineties, that IS-IS implementation
could deal with 250 routers in a double full mesh. That's 500
adjacencies per router. Those routers were running 100MHz and 200MHz
mips cpus. Some were even cisco 7000s with 68040 cpus. That worked.
With my outdated knowledge, I can not understand who a datacenter
fabric where routers have 64 or 128 adjacencies could be a problem.
Not with a proper implementation. But we're trying to fix that too.
This then suggests that for existing implementations the main
motivation to support your proposal is to help other implementations
which have not optimized their existing implementations. :-)
Comments?
Proper IS-IS implementations should split up in 3 threads at least.
One thread for maintaining adjacencies, one for doing flooding and
one for doing SPFs (and route-installs). That way an SPF doesn't
hold up flooding. And heavy flooding or long SPFs don't break
adjacencies. How many implementations in the field do that ?
Heck, I've even seen today's implementations that do not split
off adjacency-maintenance as a separate process or thread.
Anyway, the question is: if you want to have 10k LSPs in your
flooding domain, do we depend on custom improvements, or do
we want something that's documented ?
One of the things that inspired me to do this proposal was LSVR.
LSVR uses BGP-LS to transport LSPs. Why ? The word on the street
is that "BGP scales so much better". Why does BGP scale so good ?
Imho there is one main reason: BGP uses TCP for transport.
Now I don't like LSVR (and I don't like BGP-LS). Because LSVR
seems to re-invent the wheel, with no real improvements over
IS-IS, except for the fact that it uses BGP which uses TCP.
If that's the main benefit of LSVR, then why not just use
TCP and be done with it ?
BTW, there is another reason for our proposal. With the incoming
drafts about flooding-topology-reduction, there is a new problem.
All these proposals have situations where non-flooding adjacencies
suddenly change to flooding adjacencies. When that happens, the
LSDBs need to be synchronized again. To do that, all of them
propose "just send a CSNP and be done with it". Well, the more
LSPs, the more CNSPs that need to be sent. With 10k LSPs that's
110 CSNPs. CSNPs are not reliable. This re-synchronization happens
when there is churn in the IGP. Are we sure CSNPs aren't dropped
somewhere ? Can we start sending LSPs because we know the neighbor
has sent 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 <lsr-boun...@ietf.org> On Behalf Of Henk Smit
Sent: Monday, November 05, 2018 8:22 PM
To: tony...@tony.li
Cc: lsr@ietf.org
Subject: Re: [Lsr] IS-IS over TCP
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 address
3) and/or an IPv6 address
We can change the first sub-TVL so that it indicates:
1) 1 or 2 bytes indicating what protocol to use
2) the remainder of the sub-TLV is an indicator what port-number
or other identifier to use to connect over that protocol.
This way we can start improving IS-IS with TCP today.
And add/replace it with other protocols in the future.
henk.
tony...@tony.li schreef op 2018-11-06 04:51:
> Per the WG meeting, discussing on the list:
>
> This is good work and I support it.
>
> I would remind folks that TCP is NOT the only transport protocol
> available and that perhaps we should be considering QUIC while we’re
> at it. In particular, flooding is a (relatively) low bandwidth
> operation in the modern network and we could avoid slow-start issues
> by using QUIC.
>
> Tony
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
