Hi Peter, How then several interfaces could be distinguished?
Thank you. Best regards, Alexander Okonnikov 2 марта 2018 г., 9:07 +0300, Peter Psenak <[email protected]>, писал: > Hi Dirk, > > you can set the Local/Remote ID for any FA tunnel to 0 and all would > just work fine. There are implementations doing that :) > > thanks, > Peter > > > On 01/03/18 21:06 , Goethals, Dirk (Nokia - BE/Antwerp) wrote: > > 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 <[email protected] > > Sent: donderdag, maart 1, 2018 6:54 PM > > Subject: Re: [Lsr] advertising tunnels in IGP > > To: Acee Lindem (acee) <[email protected]>, Goethals, Dirk (Nokia - > > BE/Antwerp) <[email protected]>, <[email protected] > > > > > > 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 <[email protected] > > > > *Date: *Thursday, March 1, 2018 at 11:40 AM > > > > *To: *"Goethals, Dirk (Nokia - BE/Antwerp)" > > > > <[email protected]>, "[email protected]" <[email protected]>, Acee > > > > Lindem<[email protected] > > > > *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) <[email protected]>, > > > > писал: > > > > > > > > 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 <[email protected]> on behalf of "Goethals, Dirk > > > > (Nokia - BE/Antwerp)" <[email protected] > > > > *Date:* Thursday, March 1, 2018 at 11:06 AM > > > > *To:* "[email protected]"<[email protected] > > > > *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 > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
