Re: [Lsr] 答复: 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

["Dongjie (Jimmy)" <[e-mail]>]

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

> -----Original Message-----
> From: Acee Lindem (acee) [mailto:[e-mail]]
> Sent: Tuesday, July 24, 2018 10:37 PM
> To: Ketan Talaulikar (ketant) <[e-mail]>; Peter Psenak (ppsenak)
> <[e-mail]>; Aijun Wang <[e-mail]>; 'Rob Shakir'
> <[e-mail]>
> Cc: Dongjie (Jimmy) <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area
> topology retrieval
> 
> Hi Ketan,
> 
> On 7/24/18, 7:44 AM, "Ketan Talaulikar (ketant)" <[e-mail]> 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
> 
>     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 <[e-mail]>; 'Rob Shakir' <[e-mail]>
>     Cc: 'Dongjie (Jimmy)' <[e-mail]>; [e-mail]; Ketan
> Talaulikar (ketant) <[e-mail]>; [e-mail]; Acee Lindem (acee)
> <[e-mail]>
>     Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for
> inter-area topology retrieval
> 
>     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 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
>     >
>     > Network R&D and Operation Support Department
>     >
>     > China Telecom Corporation Limited Beijing Research Institute,Beijing,
> China.
>     >
>     > *发件人:*Rob Shakir [mailto:[e-mail]]
>     > *发送时间:*2018年7月24日7:04
>     > *收件人:*Peter Psenak
>     > *抄送:*Dongjie (Jimmy); [e-mail]; Ketan Talaulikar (ketant);
>     > Aijun Wang; [e-mail]; Acee Lindem (acee)
>     > *主题:*Re: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area
>     > topology retrieval
>     >
>     > +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=[e-mail]
>     > <mailto:[e-mail]>>
>     > wrote:
>     >
>     >     Hi Aijun,
>     >
>     >     On 23/07/18 13:07 , Aijun Wang wrote:
>     >     > Hi, Peter:
>     >     >
>     >     > For routers that connected by LAN, the router will establish
> adjacent
>     >     > 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
>     >     > 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?
>     >
>     >     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.
>     >
>     >     > 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.
>     >
>     >     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
>     >
>     >     >
>     >     > Best Regards.
>     >     >
>     >     > Aijun Wang
>     >     > Network R&D and Operation Support Department
>     >     > China Telecom Corporation Limited Beijing Research
> Institute,Beijing, China.
>     >     >
>     >     > -----邮件原件-----
>     >     >发件人: Peter Psenak [mailto:ppsenak
>     >     <mailto:ppsenak>=[e-mail]
>     >     <mailto:[e-mail]>]
>     >     >发送时间: 2018年7月23日18:20
>     >     >收件人: Aijun Wang; 'Peter Psenak'; [e-mail]
>     >     <mailto:[e-mail]>
>     >     >抄送: [e-mail] <mailto:[e-mail]>; '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.
>     >     >
>     >     > The idea you are proposing simply does not work.
>     >     >
>     >     > thanks,
>     >     > Peter
>     >     >
>     >     >
>     >     >>
>     >     >> Best Regards.
>     >     >>
>     >     >> Aijun Wang
>     >     >> Network R&D and Operation Support Department China Telecom
> Corporation
>     >     >> Limited Beijing Research Institute,Beijing, China.
>     >     >>
>     >     >> -----邮件原件-----
>     >     >>发件人: Peter Psenak [mailto:ppsenak
>     >     <mailto:ppsenak>=[e-mail]
>     >     <mailto:[e-mail]>]
>     >     >>发送时间: 2018年7月23日16:15
>     >     >>收件人: Aijun Wang; [e-mail]
> <mailto:[e-mail]>
>     >     >>抄送: [e-mail] <mailto:[e-mail]>; '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.
>     >     >>
>     >     >> 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-topo
>     >     >>> l ogy-ext/>, 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-osp
>     >     >> f-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-
>     >     >>> e xt-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.
>     >     >>>
>     >     >>
>     >     >> _______________________________________________
>     >     >> Lsr mailing list
>     >     >>[e-mail] <mailto:[e-mail]>
>     >     >>https://www.ietf.org/mailman/listinfo/lsr
>     >     >>
>     >     >> _______________________________________________
>     >     >> Lsr mailing list
>     >     >>[e-mail] <mailto:[e-mail]>
>     >     >>https://www.ietf.org/mailman/listinfo/lsr
>     >     >>
>     >     >
>     >     > _______________________________________________
>     >     > Lsr mailing list
>     >     >[e-mail] <mailto:[e-mail]>
>     >     >https://www.ietf.org/mailman/listinfo/lsr
>     >     >
>     >     > .
>     >     >
>     >
>     >     _______________________________________________
>     >     Lsr mailing list
>     >     [e-mail] <mailto:[e-mail]>
>     >     https://www.ietf.org/mailman/listinfo/lsr
>     >
> 
>