Subject: [Lsr] Regarding OSPF extension for inter-area topology retrieval

From: "Aijun Wang" <[email-masked]>
Date: Mon, 23 Jul 2018 15:49:16 +0800

(Sorry for my previous mail sent wrongly to the IDR mail list, please reply
on this thread within the LSR wg)

Hi, Peter:

I am Aijun Wang from China Telecom, the author of draft about
<https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-inter-area-topology-ex
t/> "OSPF extension for inter-area topology retrieval", which is presented
by Mr.Jie Dong during the IETF102 meeting.

Thanks for your comments on the presentation material
<https://datatracker.ietf.org/meeting/102/materials/slides-102-lsr-ospf-inte
r-area-topology-retrieval-00> .

Below are my explanation that regarding to the question about "how it
retrievals the inter-area topology based on the extension information":

Let's see the graph that illustrates in Fig.1 at section 3
<https://tools.ietf.org/html/draft-wang-lsr-ospf-inter-area-topology-ext-00#
section-3>  of the draft(I copy it also below for your conveniences ):

Assuming we want to rebuild the connection between router S1 and router S2
that locates in area 1:

1)       Normally, router S1 will advertise prefix N1 within its router LSA

2)       When this router LSA reaches the ABR router R1, it will convert it
into summary LSA, add the "Source Router Information", which is router id of
S1 in this example, as proposed in this draft.

3)       R1 then floods this extension summary LSA to R0, which is running
BGP-LS protocol with IP SDN Controller. The controller then knows the
prefixes of N1 is from S1.

4)       Router S2 will do the similar process, and the controller will also
knows the prefixes N1 is also from S2

5)       Then it can reconstruct the connection between S1 and S2, which
prefix is N1. The topology within Area 1 can then be recovered accordingly.

Does the above explanation can answer your question. if so, I can add it
into the context of this draft in updated version.

Best Regards.

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

---

From: Peter Psenak <[email-masked]>
Date: Mon, 23 Jul 2018 10:14:46 +0200

Hi Aijun,

you are trying to reconstruct the topology of the remote area based on 
the fact that two routers are connected to the same subnet. It does not 
work because:

1. connections between routers can be unnumbered
2. routers can be connected via LAN, in which case only DR announces the 
prefix.

In summary, what you propose does not work.

thanks,
Peter

On 23/07/18 09:49 , Aijun Wang wrote:
> (Sorry for my previous mail sent wrongly to the IDR mail list, please
> reply on this thread within the LSR wg)
>
> Hi, Peter:
>
> I am Aijun Wang from China Telecom, the author of draft about “OSPF
> extension for inter-area topology retrieval”
> <https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-inter-area-topology-ext/>,
> which is presented by Mr.Jie Dong during the IETF102 meeting.
>
> <https://datatracker.ietf.org/meeting/102/materials/slides-102-lsr-ospf-inter-area-topology-retrieval-00>.
>
> Below are my explanation that regarding to the question about “how it
> retrievals the inter-area topology based on the extension information”:
>
> Let’s see the graph that illustrates in Fig.1 at section 3
> <https://tools.ietf.org/html/draft-wang-lsr-ospf-inter-area-topology-ext-00#section-3>
> of the draft(I copy it also below for your conveniences ):
>
> Assuming we want to rebuild the connection between router S1 and router
> S2 that locates in area 1:
>
> 1)Normally, router S1 will advertise prefix N1 within its router LSA
>
> 2)When this router LSA reaches the ABR router R1, it will convert it
> into summary LSA, add the “Source Router Information”, which is router
> id of S1 in this example, as proposed in this draft.
>
> 3)R1 then floods this extension summary LSA to R0, which is running
> 4)Router S2 will do the similar process, and the controller will also
> 5)Then it can reconstruct the connection between S1 and S2, which prefix
> is N1. The topology within Area 1 can then be recovered accordingly.
>

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 23 Jul 2018 17:16:11 +0800

Hi, Peter:

Actually, I consider mainly the point-to-point connection and the numbered
interface, which are normal in our network.
For the two situations that you mentioned, I will investigation the possible
solutions and feedback you later.

For the point-to-point and numbered interface, do you have other questions
then?

Best Regards.

Aijun Wang

-----邮件原件-----
发件人: Peter Psenak [mailto:ppsenak=[email-masked]] 
发送时间: 2018年7月23日 16:15
收件人: Aijun Wang; [email-masked]
抄送: [email-masked]; 'Ketan Talaulikar (ketant)'; 'Acee Lindem (acee)';
'Dongjie (Jimmy)'
主题: Re: [Lsr] Regarding OSPF extension for inter-area topology retrieval

Hi Aijun,

you are trying to reconstruct the topology of the remote area based on the
fact that two routers are connected to the same subnet. It does not work
because:

1. connections between routers can be unnumbered 2. routers can be connected
via LAN, in which case only DR announces the prefix.

thanks,
Peter

On 23/07/18 09:49 , Aijun Wang wrote:
> <https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-inter-area-topol
> ogy-ext/>, which is presented by Mr.Jie Dong during the IETF102 
> meeting.
>
<https://datatracker.ietf.org/meeting/102/materials/slides-102-lsr-ospf-inte
r-area-topology-retrieval-00>.
> <https://tools.ietf.org/html/draft-wang-lsr-ospf-inter-area-topology-e
> xt-00#section-3> of the draft(I copy it also below for your 
> conveniences ):
>
> 5)Then it can reconstruct the connection between S1 and S2, which 
> Does the above explanation can answer your question. if so, I can add 
> it into the context of this draft in updated version.
>
> Best Regards.
>
> Aijun Wang
>

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

---

From: Peter Psenak <[email-masked]>
Date: Mon, 23 Jul 2018 12:19:33 +0200

Hi Aijun,

> For the point-to-point and numbered interface, do you have other questions

the fact that two routers announce the same subnet, does not mean they
are connected together by p2p link. Anycast prefix is an example.

The idea you are proposing simply does not work.

thanks,
Peter

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 23 Jul 2018 19:07:38 +0800

Hi, Peter:

For routers that connected by LAN, the router will establish adjacent
neighbor with DR, but not only DR advertises the connected prefixes. DR and
DRother will all advertise type 1 and type 2 LSA with each other, then the
process and proposal described in this draft will still work.
We seldom use the ip unnumbered features in our network, can we ignore it
then? Or other persons has some idea on such situation?
Anycast prefixes are often /32 long, this can be easily filtered by SDN
controller because the link prefixes between two routers will be no larger
than /32 for IPv4 network.

Best Regards.

Aijun Wang

-----邮件原件-----
发件人: Peter Psenak [mailto:ppsenak=[email-masked]] 
发送时间: 2018年7月23日 18:20
收件人: Aijun Wang; 'Peter Psenak'; [email-masked]
抄送: [email-masked]; 'Ketan Talaulikar (ketant)'; 'Acee Lindem (acee)';
'Dongjie (Jimmy)'
主题: Re: [Lsr] 答复: Regarding OSPF extension for inter-area topology
retrieval

Hi Aijun,

On 23/07/18 11:16 , Aijun Wang wrote:
> Hi, Peter:
> 
> Actually, I consider mainly the point-to-point connection and the 
> numbered interface, which are normal in our network.
> For the two situations that you mentioned, I will investigation the 
> possible solutions and feedback you later.
> 
> For the point-to-point and numbered interface, do you have other 
> questions then?

the fact that two routers announce the same subnet, does not mean they are
connected together by p2p link. Anycast prefix is an example.

thanks,
Peter

> 
> Best Regards.
> 
> Aijun Wang
> Network R&D and Operation Support Department China Telecom Corporation 
> Limited Beijing Research Institute,Beijing, China.
> 
> -----邮件原件-----
> the fact that two routers are connected to the same subnet. It does 
> not work
> because:
> 
> 1. connections between routers can be unnumbered 2. routers can be 
> connected via LAN, in which case only DR announces the prefix.
> 
>> <https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-inter-area-topo
>> l ogy-ext/>, which is presented by Mr.Jie Dong during the IETF102 
>> meeting.
>>
>> <https://tools.ietf.org/html/draft-wang-lsr-ospf-inter-area-topology-
>> e xt-00#section-3> of the draft(I copy it also below for your 
>> conveniences ):
>>
>> into summary LSA, add the “Source Router Information”, which is 
>> router id of S1 in this example, as proposed in this draft.
>>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 23 Jul 2018 13:30:00 +0200

Hi Aijun,

On 23/07/18 13:07 , Aijun Wang wrote:
> neighbor with DR, but not only DR advertises the connected prefixes. 

only the Network LSA includes the network mask, other routers would
include the interface address only.

> DR and

the fact that you do not use unnumbered is not really relevant. IETF
defines solutions that MUST work for all possible scenarios, not only
for a specific one.

> than /32 for IPv4 network.

protocol allows to advertise the same prefix with an arbitrary mask from
multiple routers without these routers being directly connected. Your
proposal is based on the assumptions that are incorrect.

thanks,
Peter

> .

---

From: Rob Shakir <[email-masked]>
Date: Mon, 23 Jul 2018 19:03:48 -0400

+1 to Peter. We should not define fragile solutions within the IETF.

There are also a multitude of other solutions here already:

1) IGP adjacency with one router in each area (at a minimum - probably two
for a robust system) over a tunnel. Deployed in many networks for years.
2) BGP-LS to one router (ditto robustness comment) in each area.
3) streaming telemetry of the LSDB contents via gNMI.

All these solutions exist in shipping implementations - please let’s not
add to the system complexity of the IGP here.

r.
On Mon, Jul 23, 2018 at 12:30 Peter Psenak <ppsenak=
[email-masked]> wrote:

> are

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 24 Jul 2018 11:37:21 +0800

Hi, Peter:

For point-to-point interface, as described in  OSPFv2(RFC2328 12.4.1.1.  Describing point-to-point interfaces) <https://tools.ietf.org/html/rfc2328#page-130> , the router LSA will include two links description for each interface, within which the “type 3 link”(stub network) will describe the subnet mask of the point-to-point interface.

For broadcast/NBMA interface, the DR will be elected and it will generate the network LSA which will include also the subnet mask of the connected interface.

For unnumbered and virtual link, if you consider we should include them also for all possible scenarios even if we seldom use them in large network, we can consider expand the summary LSA to cover it, as done by this draft.

For Anycast prefixes situation that you described(although we seldom plan our network in such way), the PCE controller will not deduce the wrong information from the reported information------Different router advertise the same prefix, why can’t they be connected in logically? 

On summary, the ABR can know and report the originator of the connected interface’s prefixes, and also the connected information for the unnumbered/virtual link from the traditional router LSA/network LSA message, thus can transfer them to the router that run BGP-LS, then to the PCE controller to retrieval the topology.

To Rob: 

BGP-LS is one prominent method to get the underlay network topology and has more flexibility to control the topology export as described in RFC 7752 <https://tools.ietf.org/html/rfc7752#section-1> . 

Solution 1) that you proposed is possible, but we will not run two different methods to get the topology.

Solution 2) is also one possible deployment, but it eliminates the advantage of the BGP-LS, in which it needs several interaction points with the underlay network. and such deployment is not belong to redundancy category as information got from different areaes are different.

Solution 3)--Streaming telemetry technology should be used mainly for the monitor of network devices, it requires the PCE controller to contact with every router in the network, is also not the optimal solution when compared with BGP-LS.

We can update the current draft to include all possible scenarios that we are not aiming at beginning for integrity consideration. The proposed extension does not add to complexity of IGP. What we discussed here is the complexity of IGP protocol itself.

Best Regards.

Aijun Wang

发件人: Rob Shakir [mailto:[email-masked]] 
发送时间: 2018年7月24日 7:04
收件人: Peter Psenak
抄送: Dongjie (Jimmy); [email-masked]; Ketan Talaulikar (ketant); Aijun Wang; [email-masked]; Acee Lindem (acee)
主题: Re: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

1) IGP adjacency with one router in each area (at a minimum - probably two for a robust system) over a tunnel. Deployed in many networks for years. 
2) BGP-LS to one router (ditto robustness comment) in each area. 
3) streaming telemetry of the LSDB contents via gNMI.

All these solutions exist in shipping implementations - please let’s not add to the system complexity of the IGP here.

r. 

On Mon, Jul 23, 2018 at 12:30 Peter Psenak <ppsenak=[email-masked]> wrote:

Hi Aijun,

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Tue, 24 Jul 2018 10:21:32 +0200

Hi Aijun,

On 24/07/18 05:37 , Aijun Wang wrote:
> _Hi, Peter:_
>
> For point-to-point interface, as described in  OSPFv2(RFC2328 12.4.1.1.  Describing point-to-point interfaces)  <https://tools.ietf.org/html/rfc2328#page-130>, the router LSA will include two links description for each interface, within which the “type 3 link”(stub network) will describe the subnet mask of the point-to-point interface.
>
> For broadcast/NBMA interface, the DR will be elected and it will
> generate the network LSA which will include also the subnet mask of the
> connected interface.
>
> For unnumbered and virtual link, if you consider we should include them
> also for all possible scenarios even if we seldom use them in large
> network, we can consider expand the summary LSA to cover it, as done by
> this draft.

there is no way to address unnumbered p2p case your way, because there 
is no Summary LSA generated to other area in such case.

Anyway, reconstructing a topology of a remote area based on the prefix 
announcements that come from it is a broken concept. I have given you 
several examples where your proposal does not work.

thanks,
Peter

>
> For Anycast prefixes situation that you described(although we seldom
> plan our network in such way), the PCE controller will not deduce the
> wrong information from the reported information------Different router
> advertise the same prefix, why can’t they be connected in logically?
>
> On summary, the ABR can know and report the originator of the connected
> interface’s prefixes, and also the connected information for the
> unnumbered/virtual link from the traditional router LSA/network LSA
> message, thus can transfer them to the router that run BGP-LS, then to
> the PCE controller to retrieval the topology.
>
> _To Rob: _
>
> BGP-LS is one prominent method to get the underlay network topology and
> has more flexibility to control the topology export as described in RFC
> 7752 <https://tools.ietf.org/html/rfc7752#section-1>.
>
> Solution 2) is also one possible deployment, but it eliminates the
> advantage of the BGP-LS, in which it needs several interaction points
> with the underlay network. and such deployment is not belong to
> redundancy category as information got from different areaes are different.
>
> Solution 3)--Streaming telemetry technology should be used mainly for
> the monitor of network devices, it requires the PCE controller to
> contact with every router in the network, is also not the optimal
> solution when compared with BGP-LS.
>
> We can update the current draft to include all possible scenarios that
> we are not aiming at beginning for integrity consideration. The proposed
> extension does not add to complexity of IGP. What we discussed here is
> the complexity of IGP protocol itself.
>
> Best Regards.
>
> Aijun Wang
>
> *发件人:*Rob Shakir [mailto:[email-masked]]
> *发送时间:*2018年7月24日7:04
> *收件人:*Peter Psenak
> *抄送:*Dongjie (Jimmy); [email-masked]; Ketan Talaulikar (ketant);
> Aijun Wang; [email-masked]; Acee Lindem (acee)
> *主题:*Re: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area
> topology retrieval
>
> 1) IGP adjacency with one router in each area (at a minimum - probably
> two for a robust system) over a tunnel. Deployed in many networks for
> years.
> On Mon, Jul 23, 2018 at 12:30 Peter Psenak
> <ppsenak=[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi Aijun,
>
>     >发件人: Peter Psenak [mailto:ppsenak
>     <mailto:ppsenak>=[email-masked]
>     <mailto:[email-masked]>]
>     >发送时间: 2018年7月23日18:20
>     <mailto:[email-masked]>
>     >抄送: [email-masked] <mailto:[email-masked]>; 'Ketan Talaulikar
>     (ketant)'; 'Acee Lindem (acee)';
>     > 'Dongjie (Jimmy)'
>     >>发件人: Peter Psenak [mailto:ppsenak
>     <mailto:ppsenak>=[email-masked]
>     <mailto:[email-masked]>]
>     >>发送时间: 2018年7月23日16:15
>     >>收件人: Aijun Wang; [email-masked] <mailto:[email-masked]>
>     >>抄送: [email-masked] <mailto:[email-masked]>; 'Ketan Talaulikar
>     (ketant)'; 'Acee Lindem (acee)';
>     >> 'Dongjie (Jimmy)'
>     >>[email-masked] <mailto:[email-masked]>
>     >>[email-masked] <mailto:[email-masked]>
>     >[email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 24 Jul 2018 11:44:40 +0000

Hi Aijun,

Your draft introduces the Source Router ID which is, by itself, an useful protocol extension. However, the use-case on inter-as topology retrieval has issues which has been shared by many of us at the mike, offline and on the list.

Could you consider de-coupling the two?

Also, if the proposal for learning inter-AS as described by you works for your own specific network design (and you don't think any of the points made affect that decision), then please go ahead. However, I do not see the point of trying to get that as an IETF document?

Thanks,
Ketan

-----Original Message-----
From: Peter Psenak (ppsenak) 
Sent: 24 July 2018 04:22
To: Aijun Wang <[email-masked]>; 'Rob Shakir' <[email-masked]>
Cc: 'Dongjie (Jimmy)' <[email-masked]>; [email-masked]; Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>
Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

Hi Aijun,

On 24/07/18 05:37 , Aijun Wang wrote:
> generate the network LSA which will include also the subnet mask of 
> the connected interface.
>
> For unnumbered and virtual link, if you consider we should include 
> them also for all possible scenarios even if we seldom use them in 
> large network, we can consider expand the summary LSA to cover it, as 
> done by this draft.

there is no way to address unnumbered p2p case your way, because there is no Summary LSA generated to other area in such case.

Anyway, reconstructing a topology of a remote area based on the prefix announcements that come from it is a broken concept. I have given you several examples where your proposal does not work.

thanks,
Peter

> On summary, the ABR can know and report the originator of the 
> connected interface’s prefixes, and also the connected information for 
> the unnumbered/virtual link from the traditional router LSA/network 
> LSA message, thus can transfer them to the router that run BGP-LS, 
> then to the PCE controller to retrieval the topology.
>
> _To Rob: _
>
> BGP-LS is one prominent method to get the underlay network topology 
> and has more flexibility to control the topology export as described 
> in RFC
> we are not aiming at beginning for integrity consideration. The 
> proposed extension does not add to complexity of IGP. What we 
> discussed here is the complexity of IGP protocol itself.
>
> Best Regards.
>
> Aijun Wang
>
> All these solutions exist in shipping implementations - please let’s 
> not add to the system complexity of the IGP here.
>
> r.
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 24 Jul 2018 14:37:13 +0000

Hi Ketan, 

On 7/24/18, 7:44 AM, "Ketan Talaulikar (ketant)" <[email-masked]> wrote:

    Hi Aijun,
    
    Your draft introduces the Source Router ID which is, by itself, an useful protocol extension.

I agree. What is the use case for advertisement in IS-IS? Perhaps this could be used as the primary motivation. 

   However, the use-case on inter-as topology retrieval has issues which has been shared by many of us at the mike, offline and on the list.

And this could be moved to an appendix or even completely. 

Thanks,
Acee 

    
    Thanks,
    Ketan
    
    -----Original Message-----
    From: Peter Psenak (ppsenak) 
    Sent: 24 July 2018 04:22
    To: Aijun Wang <[email-masked]>; 'Rob Shakir' <[email-masked]>
    Cc: 'Dongjie (Jimmy)' <[email-masked]>; [email-masked]; Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>
    Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology retrieval
    
    Hi Aijun,

    
    
    thanks,
    Peter

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 24 Jul 2018 15:55:45 +0000

Ack and IMHO the reference to this inter-AS use-case should be removed as it is very specific and works in very limited cases as opposed to rfc5392 which presented a proper OSPF solution for this specific problem (rfc5316 does same for IS-IS).

Thanks,
Ketan

-----Original Message-----
From: Acee Lindem (acee) 
Sent: 24 July 2018 10:37
To: Ketan Talaulikar (ketant) <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; Aijun Wang <[email-masked]>; 'Rob Shakir' <[email-masked]>
Cc: 'Dongjie (Jimmy)' <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

Hi Ketan, 

    Hi Aijun,

Thanks,
Acee 

    
    Thanks,
    Ketan
    
    -----Original Message-----
    From: Peter Psenak (ppsenak) 
    Sent: 24 July 2018 04:22
    To: Aijun Wang <[email-masked]>; 'Rob Shakir' <[email-masked]>
    Cc: 'Dongjie (Jimmy)' <[email-masked]>; [email-masked]; Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>
    Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology retrieval
    
    Hi Aijun,

    
    
    thanks,
    Peter

---

From: Rob Shakir <[email-masked]>
Date: Tue, 24 Jul 2018 12:21:56 -0400

On 23 July 2018 at 23:37, Aijun Wang <[email-masked]> wrote:

> *To Rob: *

What is the other method that you're running alongside an IGP adjacency?
This is a single method that just uses the IGP protocol that you have today.

> advantage of the BGP-LS, in which it needs several interaction points with
> the underlay network. and such deployment is not belong to redundancy
> category as information got from different areaes are different.
>

Yes, the information is different but this is why you have areas within the
IGP. Are you implying that your controller cannot merge topologies from
different areas? I'd suggest that this is something that is relatively
trivial to add into that code, rather than changing the code running on
your routers.

> Solution 3)--Streaming telemetry technology should be used mainly for the
> monitor of network devices, it requires the PCE controller to contact with
> every router in the network, is also not the optimal solution when compared
> with BGP-LS.
>

This is not true. LSDB export via streaming telemetry (for the entire LSDB)
is possible in today's running code with IS-IS, and models are written for
OSPF's LSDB. The controller just needs to interact with one device per area
per the existing discussion.

Assertion that this is not the optimal solution seems more like opinion to
me. Some justification would be useful for us to understand why the
existing solutions that are shipping aren't suitable. Why should we further
complicate protocols that ship for everyone if there is no technical reason
to do so?

> extension does not add to complexity of IGP. What we discussed here is the
> complexity of IGP protocol itself.
>

 You're asking for information that is explicitly partitioned (based on the
fact that your network is partitioned into areas) to be exported into an
area simply to reduce the number of adjacencies between a controller and
the network to N (where N is the redundancy of the controller) rather than
N*areas -- why is this the right trade-off?

r.

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 25 Jul 2018 07:53:37 +0800

Hi, Ketan and Acee:

I am working on the other use cases of "Source Router ID" extension, which may corresponding to that in RFC7794. Once finished, I will update the draft.
RFC5392 and RFC5316 are for inter-AS TE extension, not inter-area scenario and solution that proposed in this draft.

-----邮件原件-----
发件人: Ketan Talaulikar (ketant) [mailto:[email-masked]] 
发送时间: 2018年7月24日 23:56
收件人: Acee Lindem (acee); Peter Psenak (ppsenak); Aijun Wang; 'Rob Shakir'
抄送: 'Dongjie (Jimmy)'; [email-masked]; [email-masked]
主题: RE: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

Thanks,
Ketan

-----Original Message-----
From: Acee Lindem (acee) 
Sent: 24 July 2018 10:37
To: Ketan Talaulikar (ketant) <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; Aijun Wang <[email-masked]>; 'Rob Shakir' <[email-masked]>
Cc: 'Dongjie (Jimmy)' <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

Hi Ketan, 

    Hi Aijun,

Thanks,
Acee 

    
    Thanks,
    Ketan
    
    -----Original Message-----
    From: Peter Psenak (ppsenak) 
    Sent: 24 July 2018 04:22
    To: Aijun Wang <[email-masked]>; 'Rob Shakir' <[email-masked]>
    Cc: 'Dongjie (Jimmy)' <[email-masked]>; [email-masked]; Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>
    Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology retrieval
    
    Hi Aijun,

    
    
    thanks,
    Peter

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 25 Jul 2018 11:39:50 +0800

Hi, Peter:

Actually, only the unnumbered scenario that you insisted has no straightforward solution for the topology reconstruction. As I had explained previously, unnumbered interface deployment is very seldom within our network, because it is unavailable for remote testing and management.
If we still need to cover it, one viable way is to let "summary LSA" also announced it, with "Link State ID" is identical to the neighboring router, and the proposed "source router ID" is the original router itself. PCE/SDN controller can then recognize and reconstruct the topology correctly under such scenario.

>From the view of other point, let the "summary LSA" carry the "source router ID" can aid us reconstruct the underlay multi-area topology in most of common scenario, will do no harm to the traditional IGP flooding and SPF calculation. I am also investigating other use case of this extension as suggested by Acee and Ketan.

Very thanks for your comments to this draft again, and wish you can work together with us for the suitable solution.

Best Regards.

Aijun Wang

-----邮件原件-----
发件人: Peter Psenak [mailto:ppsenak=[email-masked]] 
发送时间: 2018年7月24日 16:22
收件人: Aijun Wang; 'Rob Shakir'
抄送: 'Dongjie (Jimmy)'; 'Ketan Talaulikar (ketant)'; [email-masked]; 'Acee Lindem (acee)'; [email-masked]
主题: Re: [Lsr] 答复: 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

Hi Aijun,

thanks,
Peter

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 25 Jul 2018 11:50:16 +0800

Hi, Rob:

If we use BGP-LS to get the underlay topology, we will not consider deployment other methods such as IGP adjacency or LSDB telemetry, although all of them are applicable.

If we deploy BGP-LS adjacency with routers in multi-area to get the full multi-area topology, it will be no different with the traditional IGP adjacency, increase the complexity that BGP-LS solution itself can reduce.

On the other hand, if we do not solve such scenario, isn’t BGP-LS one complete solution for underlay IGP topology gathering?

Best Regards.

Aijun Wang

发件人: Rob Shakir [mailto:[email-masked]] 
发送时间: 2018年7月25日 0:22
收件人: Aijun Wang
抄送: Dongjie (Jimmy); [email-masked]; Peter Psenak; Ketan Talaulikar (ketant); [email-masked]; Acee Lindem (acee)
主题: Re: [Lsr] 答复: 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

To Rob: 

What is the other method that you're running alongside an IGP adjacency? This is a single method that just uses the IGP protocol that you have today.

Yes, the information is different but this is why you have areas within the IGP. Are you implying that your controller cannot merge topologies from different areas? I'd suggest that this is something that is relatively trivial to add into that code, rather than changing the code running on your routers.

This is not true. LSDB export via streaming telemetry (for the entire LSDB) is possible in today's running code with IS-IS, and models are written for OSPF's LSDB. The controller just needs to interact with one device per area per the existing discussion. 

Assertion that this is not the optimal solution seems more like opinion to me. Some justification would be useful for us to understand why the existing solutions that are shipping aren't suitable. Why should we further complicate protocols that ship for everyone if there is no technical reason to do so?

 You're asking for information that is explicitly partitioned (based on the fact that your network is partitioned into areas) to be exported into an area simply to reduce the number of adjacencies between a controller and the network to N (where N is the redundancy of the controller) rather than N*areas -- why is this the right trade-off?

r.

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 25 Jul 2018 08:08:28 +0200

pretty obvious +1 here

--- tony

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 25 Jul 2018 06:32:33 +0000

Hi Acee, Ketan and Aijun, 

I also agree that the introduction of source router ID could be a generic useful extension to OSPF, we already have this in IS-IS [RFC 7794]. 

As for the inter-area topology retrieval use case, I tend to agree that there can be multiple ways to achieve this, thus it would make sense to decouple this specific use case with the generic extension. 

Best regards,
Jie

> From: Acee Lindem (acee) [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2018 10:37 PM
> To: Ketan Talaulikar (ketant) <[email-masked]>; Peter Psenak (ppsenak)
> <[email-masked]>; Aijun Wang <[email-masked]>; 'Rob Shakir'
> <[email-masked]>
> Cc: Dongjie (Jimmy) <[email-masked]>; [email-masked]; [email-masked]
>    However, the use-case on inter-as topology retrieval has issues which has
> been shared by many of us at the mike, offline and on the list.
> 
>     Also, if the proposal for learning inter-AS as described by you works for your
> own specific network design (and you don't think any of the points made affect
> that decision), then please go ahead. However, I do not see the point of trying to
> get that as an IETF document?
> 
>     Thanks,
>     Ketan
> 
>     Cc: 'Dongjie (Jimmy)' <[email-masked]>; [email-masked]; Ketan
> Talaulikar (ketant) <[email-masked]>; [email-masked]; Acee Lindem (acee)
> <[email-masked]>
>     > For point-to-point interface, as described in  OSPFv2(RFC2328 12.4.1.1.
> Describing point-to-point interfaces)
> <https://tools.ietf.org/html/rfc2328#page-130>, the router LSA will include two
> links description for each interface, within which the “type 3 link”(stub network)
> will describe the subnet mask of the point-to-point interface.
>     >
>     there is no way to address unnumbered p2p case your way, because there is
> no Summary LSA generated to other area in such case.
> 
> announcements that come from it is a broken concept. I have given you several
> examples where your proposal does not work.
> 
>     thanks,
>     Peter
> 
>     >
> “OSPF
>     >     >>> Assuming we want to rebuild the connection between router S1
> and
>     >     >>> router
>     >     >>> China Telecom Corporation Limited Beijing Research
> Institute,Beijing,
>     >     >> China.
>     >     >>>
>     >     >>

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 25 Jul 2018 00:32:25 -0700

Not going to repeat all the comments made before, +1

Regards,
Jeff

> On Jul 24, 2018, at 23:08, Tony Przygienda <[email-masked]> wrote:
> 
> pretty obvious +1 here 
> 
> --- tony 
>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 25 Jul 2018 09:49:25 +0200

Hi Aijun,

On 25/07/18 01:53 , Aijun Wang wrote:
> Hi, Ketan and Acee:
>
> I am working on the other use cases of "Source Router ID" extension, which may corresponding to that in RFC7794.

you want to use Extended Prefix LSA for advertising the "Source router 
ID", not the Summary LSA.

thanks,
Peter

> Once finished, I will update the draft.