Hi,
I cannot find in RFC 5340 where pair of Interface ID/Neighbor Interface
ID are used for two-way check for P2P link. RFC 5340 reuses SPF
algorithm from RFC 2328. RFC 2328 says that W should have link back to
V, but it also says (in footnote 23) that link from W to V does not
necessarily matches to link from V to W. I.e. presence of two
unidirectional links is enough for two-way check to be passed. Is it
correct?
If yes then, what if OSPFv3 router will set Neighbor Interface ID to 0
for P2P link and the neighbor will do the same? How it will be treated
by other routers while calculate SPF?
Also, Neighbor Interface ID is used as reference for corresponding Link
LSA while calculating next-hop. Per my understanding neighbor's IPv6
link-local address is not needed (as well as neighbor's Link LSA),
because LSP will be next-hop in this case.
Thanks.
01.03.2018 20:08, Alexander Okonnikov пишет:
Hi,
Need for advertising of FA by both sides is dictated by OSPFv2 and
IS-IS, because they 1) check presence of adjacency in two directions
and 2) cannot distinguish FA from regular P2P link. If latter was
possible, then it would not be needed to perform two-way check for FA
(presence of FA just in forward direction means that ingress "link" on
remote neighbor is working; otherwise LSP in forward direction would
be broken). It can be generalized to all three protocols: if we can
somehow identify link type as FA, we don't need two-way check for FA.
We also don't need Neighbor Interface ID for FA in OSPFv3 in this case.
Thank you.
01.03.2018 19:56, Acee Lindem (acee) пишет:
Hi Alexander,
*From: *Alexander Okonnikov <alexander.okonni...@gmail.com>
*Date: *Thursday, March 1, 2018 at 11:40 AM
*To: *"Goethals, Dirk (Nokia - BE/Antwerp)"
<dirk.goeth...@nokia.com>, "lsr@ietf.org" <lsr@ietf.org>, Acee Lindem
<a...@cisco.com>
*Subject: *Re: [Lsr] advertising tunnels in IGP
Hi,
I think that problem here is that two LSPs are two independent
unidirectional links, rather than one bidirectional. Moreover, LSPs
in two directions are not pairs (some two LSPs are not associated to
each other), and amount of LSPs in each direction is not necessary
the same. I could assume that some router uses Interface IDs for
two-way check, but it is not so straightforward when we have deal
with FAs.
Acee, two-way check could be disabled on the router that is owner of
FA, but how other routers will distinguish regular P2P from FA?
Good point – all the transit routers need to agree on the interface IDs.
Thanks,
Acee
Thank you.
Best regards,
Alexander Okonnikov
1 марта 2018 г., 19:37 +0300, Acee Lindem (acee) <a...@cisco.com>, писал:
Hi Dirk,
My memory has faded somewhat on Forwarding Adjacency (FA)
implementation. However, since basic MPLS LSPs are
unidirectional, doesn’t the SPF two-way check have to be disabled
anyway? If so, the Remote Interface ID doesn’t matter.
Thanks,
Acee
*From:* Lsr <lsr-boun...@ietf.org> on behalf of "Goethals, Dirk
(Nokia - BE/Antwerp)" <dirk.goeth...@nokia.com>
*Date:* Thursday, March 1, 2018 at 11:06 AM
*To:* "lsr@ietf.org" <lsr@ietf.org>
*Subject:* [Lsr] advertising tunnels in IGP
Hi,
In OSPFv2 (and ISIS), we can add (RSVP) tunnels to the topology
by adding them as a unnumbered link in the router lsa.
In OSPFv3, we can only add a link to the router-lsa if the neighbor
interface ID is known.
So it looks like we can only add a tunnel to the OSPFv3 topology,
if we first exchanging hello packets over the tunnel.
Is that correct?
As this is not needed in the other IGPs, do
we have other possibilities?
Thx,
Dirk
_______________________________________________
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
