Hi Alexander, Acee, Peter, Thanks for your prompt suggestions. Alexander, I’m also in favor of having something as simple as in OSPFV2. So, I’m somewere on the same track as you, i.e. 1) a flexible bidirectional check when nbrid=0, similar as unnumbered p2p in OSPFv2 2) during next hop resolution, when nbrid=0, pick up the local tunnelinfo iso neigbors ip address.
Thanks, Dirk _____________________________ From: Alexander Okonnikov <alexander.okonni...@gmail.com> Sent: donderdag, maart 1, 2018 6:54 PM Subject: Re: [Lsr] advertising tunnels in IGP To: Acee Lindem (acee) <a...@cisco.com>, Goethals, Dirk (Nokia - BE/Antwerp) <dirk.goeth...@nokia.com>, <lsr@ietf.org> 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><mailto:alexander.okonni...@gmail.com> Date: Thursday, March 1, 2018 at 11:40 AM To: "Goethals, Dirk (Nokia - BE/Antwerp)" <dirk.goeth...@nokia.com><mailto:dirk.goeth...@nokia.com>, "lsr@ietf.org"<mailto:lsr@ietf.org> <lsr@ietf.org><mailto:lsr@ietf.org>, Acee Lindem<a...@cisco.com><mailto: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><mailto: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><mailto:lsr-boun...@ietf.org> on behalf of "Goethals, Dirk (Nokia - BE/Antwerp)" <dirk.goeth...@nokia.com><mailto:dirk.goeth...@nokia.com> Date: Thursday, March 1, 2018 at 11:06 AM To: "lsr@ietf.org"<mailto:lsr@ietf.org><lsr@ietf.org><mailto: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<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
