Hi Alexander,
You don't need a nhop for tunnels, so why would you need
to distinguish the interfaces?
Dirk
Op 2/03/2018 om 7:26 schreef Alexander
Okonnikov:
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
|
