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.
The key paragraph is in https://tools.ietf.org/html/rfc6213#section-2
" The problem with this solution is that it assumes that the
transmission and receipt of IS-IS Hellos (IIHs) shares fate with
forwarded data packets. This is not a fair assumption to make given
that the primary use of BFD is to protect IPv4 (and IPv6)
forwarding,
and IS-IS does not utilize IPv4 or IPv6 for sending or receiving its
hellos."
We have seen cases where IPv4/IPv6 data packet delivery has been
compromised - but IS-IS PDU delivery was unaffected. This led to the
following behavior:
1)IS-IS exchanges hellos and bring adjacency up. Routes using the link
are installed
2)BFD session is started and comes up
3)After a time some problem occurs which only impact IP traffic - BFD
session goes down.
4)IS-IS adjacency is brought down due to BFD session down, but IS-IS
continues to send hellos. If they are successfully exchanged then
IS-IS adjacency is almost immediately restored and we resume
installing IP routes using the link even though BFD session never
comes up. Data traffic gets dropped.
Thanks for the explanation.
But that is kinda what I wanted to say.
BFD is failing (because the IP-path is failing), and IS-IS doesn't
realize this, because it thinks that BFD isn't being used (because
"BFD session never comes up".
The extensions in RFC 6213 allow IS-IS to know when both sides support
BFD, which means the sequence changes to:
1)IS-IS exchanges hellos - but adjacency remains in INIT state.
2)BFD session is initiated - IS-IS adjacency remains in INIT state
until BFD session comes up.
Thus IS-IS never installs routes using the link unless we know IP
traffic can be successfully delivered.
We can then use BFD both as a requirement to bring the adjacency up
AND as fast failure detection.
OK. What do you suggest we do to fix this failure case if we do
flooding over TCP ?
- We could make BFD mandatory when flooding over TCP ? If the IP-path
is broken, TCP will fail, but BFD will also fail ?
- We bring the adjacency to UP state, but we don't include it in our own
LSP immediately. Only after the TCP session has been established, we
advertise the new adjacency in our LSP. Would that be enough ? It would
stop routes from being calculated over the new adjacency.
Maybe wait until the TCP connection has been set up, and a pair of IIHs
has been exchanged over it ? (So authentication and other stuff can
be verified for the TCP session).
Or maybe even wait until IIHs have been sent, and then full sets of
CSNPs
are exchanged in both directions ?
That last suggestion starts approaching the way OSPF does this. If I
recall
correctly, OSPF will only include adjacencies in its type-1 LSA after
DDs
have been exchanged, and the full LDSB has been synchronized. Would you
want IS-IS to do the same ?
- If the TCP session breaks, do you want to stop including the adjacency
in the LSP ? This will make things like NSF, process restart and control
plane failover much harder.
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.
[Les:] RFC 6213 was written precisely to address this case - and works
very well.
The fact that BFD is working does not mean it is 100% sure that aal
IP traffic will work. Failures might depend on protocol number,
portnumbers, packetsize, etc. I agree that it is likely that if BFD
works, all of IP will work. But it's no guarantee.
Likewise we have to decide how paranoia we want to be that if IIHs
are exchanged, how sure are we that TCP can exchange LSPs as well ?
Maybe a good compromise would be:
1) don't advertise the adjacency in your LSPs until the TCP flooding
connection has been established. (And maybe IIHs/CSNPs are exchanged).
2) after connection is fully up (IIHs and flooding works), use longer
time-outs to determine whether TCP is still working.
3) when the other side closes a TCP connection (by FIN or RST), don't
stop advertising the adjacency in your LSP immediately. In stead,
for the next 10 seconds or so, try to re-establish the TCP connection
first. If re-establishment doesn't work, then the router can stop
including the adjacency in its LSP.
This would prevent routers advertising new adjacencies that have a
problem
with TCP. But if it works, and suddenly stops working, convergence is
slower (10 seconds or so). But the protocol has the ability to
re-establish
the TCP session, to make it more flexible.
Would that be acceptable ?
[Les:] Actually they have. :-) That's why we wrote RFC 6213 - because
the problem has been seen in the field.
I was talking about a router forwarding traffic.
BFD between router A and router B could work, but B (for some reason)
doesn't forward traffic. That was my extreme example to show that BFD
doesn't protect all weird failure scenarios possible. The question is:
how paranoia does a protocol want to be ?
[Les:] I appreciate your concerns - and it is true that "most of the
time" if we cannot receive IP traffic we likely cannot receive IS-IS
PDUs . But actual field experience has shown this is not always the
case - and when it is not the lack of recognition of the failed state
has major impacts.
I don't think you can ignore this case just because it will happen
infrequently.
We got BFD to protect against that.
But if I understand correctly, you propose that if the TCP session
doesn't
come up, or get torn down later, we also bring down the adjacency, even
when IIHs are still exchanged. That's reasonable, of course. Even if it
makes
things slightly more complicated.
[Les:] I am not suggesting that this aspect of scaling can be ignored.
But I am saying implementations have successfully addressed this with
"smarter implementations" and done so w/o requiring protocol
extensions.
I personally agree with this position.
Vendors should be able to distinguish themselves from the competition.
But people working for operators have a different view.
When this draft got published, we got private email from an operator
addressing a number of issues (mainly when using unnumbered interfaces).
His point was: he wanted to make sure that all corner-cases are handled
identically by all vendors. Or at least in an inter-operable way.
Therefor he wanted every little detail of implementation explicitly
mentioned. I guess seeing your backbone go down because of
vendor-specific
enhancements (or lack thereof) will give you a different view on the
matter.
So I think that if vendors do things that are noticable on the wire,
even
if they should be compatible with standard behaviour, those things
should
be documented at least. Therefor I thought: "if all vendors are gonna
implement their own pacing and their own reliability and their own
high throughput, why not all use the same well-known transport
protocol".
Hence our proposal.
[Les:] I think the details of the "smart implementations" have not
been formally documented because they did not require protocol
extensions (i.e., they are interoperable w implementations which do
not have equal smarts) and they are largely seen as the value add
resulting from significant development/test efforts. Why would I want
to give that knowledge away for free when I might use it to gain a
competitive advantage?
Router vendors do not.
Operators probably do want everything written down.
For themselves and to ensure inter-operability.
Perhaps it is time to revisit that and consider writing some sort of
BCP document - but that is a separate discussion.
If the people who want this knowledge shared, can find someone who can
has that knowledge, and who wants to write it down, they should go
ahead. :)
The thing that surprises me a little that a lot of these protocol
enhancements (or even brand new protocols) would not be necessary
if all implementations were perfect. It seems that in some cases we
try to improve networks not by improving equipment, but by trying
just a slightly different way to do things.
Again, if people think that LSVR is a good idea, then how can they
think that ISIS flooding over TCP is not a good idea ? This is
the base idea for our proposal. A quick look at the LSVR draft
show people from Cisco, Nokia (and Arrcus). (I'm not sure what
Juniper or Arista or other vendors think about using BGP-LS).
[Les:] I do not advocate "just send an CSNP and be done with it" for
the very reasons you mention.
You will see that
https://tools.ietf.org/html/draft-li-lsr-dynamic-flooding-01#section-6.7.2
specifies that normal LSPDB synchronization occurs on adjacency
bringup.
That test mentioned enabling (and thus also disabling) flooding over
specific
adjacencies. When you (re-)enable flooding over an adjacency, you need
to do the synchronization over again. So you need to exchange CSNPs and
transmit any missing LSPs. That's what I meant by writing "and be done
with it".
It's not a complex idea. But when CSNPs get dropped, synchronization
becomes
more expensive (because you transmit LSPs which might not have been
necessary).
I hope using TCP will make synchronization in this case more efficient.
henk.
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
