Re: [Lsr] advertising tunnels in IGP

[Alexander Okonnikov <[e-mail]>]

My concern is about management aspect - how two or more interfaces with 
the same ID will be treated by management system?


02.03.2018 10:35, Peter Psenak пишет:
> On 02/03/18 08:25 , Dirk Goethals wrote:
>> Hi Alexander,
>> You don't need a nhop for tunnels, so why would you need
>> to distinguish the interfaces?
>
> right. No need to, given that you relaxed the 2WC by using zeros for 
> interface IDs? ECMP on the tunnel-head is a local matter.
>
> thanks,
> Peter
>> 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 <[e-mail]>, писал:
>>>> 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 <[e-mail]
>>>>> Sent: donderdag, maart 1, 2018 6:54 PM
>>>>> Subject: Re: [Lsr] advertising tunnels in IGP
>>>>> To: Acee Lindem (acee) <[e-mail]>, Goethals, Dirk (Nokia -
>>>>> BE/Antwerp) <[e-mail]>, <[e-mail]
>>>>>
>>>>>
>>>>> 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 <[e-mail]
>>>>>>> *Date: *Thursday, March 1, 2018 at 11:40 AM
>>>>>>> *To: *"Goethals, Dirk (Nokia - BE/Antwerp)"
>>>>>>> <[e-mail]>, "[e-mail]" <[e-mail]>, Acee
>>>>>>> Lindem<[e-mail]
>>>>>>> *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) <[e-mail]>,
>>>>>>> писал:
>>>>>>>
>>>>>>> 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 <[e-mail]> on behalf of "Goethals, Dirk
>>>>>>> (Nokia - BE/Antwerp)" <[e-mail]
>>>>>>> *Date:* Thursday, March 1, 2018 at 11:06 AM
>>>>>>> *To:* "[e-mail]"<[e-mail]
>>>>>>> *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
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/lsr
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Lsr mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/lsr
>>>>>
>>>>
>>
>> .
>