Subject: [Lsr] advertising tunnels in IGP

From: Dirk Goethals <[email-masked]>
Date: Thu, 1 Mar 2018 17:05:42 +0100

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

---

From: Peter Psenak <[email-masked]>
Date: Thu, 01 Mar 2018 17:21:13 +0100

Hi Dirk,

> we have other possibilities?

well, one can manually configure the local/remote interface IDs to match 
on both sides and advertise as such.

thanks,
Peter
> Thx,
> Dirk
>
>
>
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: "Goethals, Dirk (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 1 Mar 2018 16:34:36 +0000

Peter,
Indeed.
Thx,
Dirk

Outlook voor Android<https://aka.ms/ghei36> downloaden

________________________________
From: Peter Psenak <[email-masked]>
Sent: Thursday, March 1, 2018 5:21:13 PM
To: Goethals, Dirk (Nokia - BE/Antwerp); [email-masked]
Subject: Re: [Lsr] advertising tunnels in IGP

Hi Dirk,

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 1 Mar 2018 16:36:55 +0000

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-masked]> on behalf of "Goethals, Dirk (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thursday, March 1, 2018 at 11:06 AM
To: "[email-masked]" <[email-masked]>
Subject: [Lsr] advertising tunnels in IGP

Hi,

---

From: Alexander Okonnikov <[email-masked]>
Date: Thu, 1 Mar 2018 19:40:17 +0300

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?
Thank you.

Best regards,
Alexander Okonnikov

---

From: Peter Psenak <[email-masked]>
Date: Thu, 01 Mar 2018 17:49:31 +0100

Hi Acee,

On 01/03/18 17:36 , Acee Lindem (acee) wrote:
> 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.

no, you have to advertise FA from both sides so that TWC passes.

thanks,
Peter

>
> Thanks,
> Acee
>
> *From: *Lsr <[email-masked]> on behalf of "Goethals, Dirk (Nokia -
> BE/Antwerp)" <[email-masked]>
> *Date: *Thursday, March 1, 2018 at 11:06 AM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[Lsr] advertising tunnels in IGP
>
> Hi,

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 1 Mar 2018 16:55:10 +0000

On 3/1/18, 11:49 AM, "Peter Psenak (ppsenak)" <[email-masked]> wrote:

    Hi Acee,

Ok - then we need something and if we have parallel FAs with the same endpoint, then we should have something unique (since the problem with parallel P2P links is solved in OSPFv3 we should solve the same problem with FAs). It would be good to use something associated with the LSP rather than the outgoing interface (which could change). Perhaps a short draft is in order... 

Thanks,
Acee 

    thanks,
    Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 1 Mar 2018 16:56:46 +0000

Hi Alexander,

From: Alexander Okonnikov <[email-masked]>
Date: Thursday, March 1, 2018 at 11:40 AM
To: "Goethals, Dirk (Nokia - BE/Antwerp)" <[email-masked]>, "[email-masked]" <[email-masked]>, Acee Lindem <[email-masked]>
Subject: Re: [Lsr] advertising tunnels in IGP

Hi,

Good point – all the transit routers need to agree on the interface IDs.

Thanks,
Acee

Thank you.

Best regards,
Alexander Okonnikov

Hi Dirk,

Thanks,
Acee

Hi,

---

From: Alexander Okonnikov <[email-masked]>
Date: Thu, 1 Mar 2018 20:08:22 +0300

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-masked]>
> *Date: *Thursday, March 1, 2018 at 11:40 AM
> *To: *"Goethals, Dirk (Nokia - BE/Antwerp)" <[email-masked]>, 
> "[email-masked]" <[email-masked]>, Acee Lindem <[email-masked]>
> *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?
>
>     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-masked]> on behalf of "Goethals, Dirk
>     (Nokia - BE/Antwerp)" <[email-masked]>
>     *Date:* Thursday, March 1, 2018 at 11:06 AM
>     *To:* "[email-masked]" <[email-masked]>
>     *Subject:* [Lsr] advertising tunnels in IGP
>
>     Hi,

---

From: Alexander Okonnikov <[email-masked]>
Date: Thu, 1 Mar 2018 20:54:40 +0300

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 пишет:
> 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.
>
>
>> *To: *"Goethals, Dirk (Nokia - BE/Antwerp)" 
>> <[email-masked]>, "[email-masked]" <[email-masked]>, Acee Lindem 
>> <[email-masked]>
>> 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.
>>
>>     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: "Goethals, Dirk (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 1 Mar 2018 20:06:11 +0000

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-masked]>
Sent: donderdag, maart 1, 2018 6:54 PM
Subject: Re: [Lsr] advertising tunnels in IGP
To: Acee Lindem (acee) <[email-masked]>, Goethals, Dirk (Nokia - BE/Antwerp) <[email-masked]>, <[email-masked]>

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.

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.

From:Alexander Okonnikov <[email-masked]><mailto:[email-masked]>
Date: Thursday, March 1, 2018 at 11:40 AM
To: "Goethals, Dirk (Nokia - BE/Antwerp)" <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, Acee Lindem<[email-masked]><mailto:[email-masked]>
Subject: Re: [Lsr] advertising tunnels in IGP

Hi,

Thanks,
Acee

Thank you.

Best regards,
Alexander Okonnikov

1 марта 2018 г., 19:37 +0300, Acee Lindem (acee) <[email-masked]><mailto:[email-masked]>, писал:

Hi Dirk,

Thanks,
Acee

From:Lsr <[email-masked]><mailto:[email-masked]> on behalf of "Goethals, Dirk (Nokia - BE/Antwerp)" <[email-masked]><mailto:[email-masked]>
Date: Thursday, March 1, 2018 at 11:06 AM
To: "[email-masked]"<mailto:[email-masked]><[email-masked]><mailto:[email-masked]>
Subject: [Lsr] advertising tunnels in IGP

Hi,

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Peter Psenak <[email-masked]>
Date: Fri, 02 Mar 2018 07:07:49 +0100

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:
> To: Acee Lindem (acee) <[email-masked]>, Goethals, Dirk (Nokia -
> BE/Antwerp) <[email-masked]>, <[email-masked]>
>
>
> Hi,
>
>>> *From:*Alexander Okonnikov <[email-masked]>
>>> <[email-masked]>, "[email-masked]" <[email-masked]>, Acee
>>> Lindem<[email-masked]>
>>>     *From:*Lsr <[email-masked]> on behalf of "Goethals, Dirk
>>>     *To:* "[email-masked]"<[email-masked]>

---

From: Alexander Okonnikov <[email-masked]>
Date: Fri, 2 Mar 2018 09:26:21 +0300

Hi Peter,

How then several interfaces could be distinguished?

Thank you.

Best regards,
Alexander Okonnikov

2 марта 2018 г., 9:07 +0300, Peter Psenak <[email-masked]>, писал:
> > From: Alexander Okonnikov <[email-masked]
> > BE/Antwerp) <[email-masked]>, <[email-masked]
> >
> >
> > Hi,
> >
> > > > *From:*Alexander Okonnikov <[email-masked]
> > > > Lindem<[email-masked]
> > > > (Nokia - BE/Antwerp)" <[email-masked]
> > > > *To:* "[email-masked]"<[email-masked]

---

From: Dirk Goethals <[email-masked]>
Date: Fri, 2 Mar 2018 08:25:31 +0100

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,

Thank you.

Best regards,

Alexander Okonnikov

2 марта 2018 г., 9:07 +0300, Peter Psenak
<[email-masked]>, писал:

Hi Dirk,

you can set the Local/Remote ID for any FA tunnel to 0 and all
would

thanks,

Peter

Alexander,

I’m also in favor of having something as simple as in
OSPFV2.

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

To: Acee Lindem (acee) <[email-masked]>, Goethals,
Dirk (Nokia -

BE/Antwerp) <[email-masked]>,
<[email-masked]

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

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),

Thanks.

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.

Hi Alexander,

*From:*Alexander Okonnikov
<[email-masked]

<[email-masked]>, "[email-masked]"
<[email-masked]>, Acee

Lindem<[email-masked]

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-masked]>, писал:

Hi Dirk,

My memory has faded somewhat on Forwarding Adjacency
(FA)

unidirectional, doesn’t the SPF two-way check have to be
disabled

Thanks,

Acee

*From:*Lsr <[email-masked]> on behalf of
"Goethals, Dirk

Hi,

In OSPFv2 (and ISIS), we can add (RSVP) tunnels to the
topology

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,

Is that correct?

Thx,

Dirk

Lsr mailing list

[email-masked]

Lsr mailing list

[email-masked]

---

From: Peter Psenak <[email-masked]>
Date: Fri, 02 Mar 2018 08:35:04 +0100

> 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,
>>
> .

---

From: Alexander Okonnikov <[email-masked]>
Date: Fri, 2 Mar 2018 10:58:08 +0300

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