[prev in list] [next in list] [prev in thread] [next in thread]
List: ms-ospf
Subject: Re: [Lsr] =?utf-8?b?562U5aSNOiAgIOetlOWkjTogIOetlOWkjTogUmVnYXJkaW5n?=
From: "Dongjie (Jimmy)" <jie.dong () huawei ! com>
Date: 2018-07-25 6:32:33
Message-ID: 76CD132C3ADEF848BD84D028D243C927A70FA502 () NKGEML515-MBS ! china ! huawei ! com
[Download RAW message or body]
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:acee@cisco.com]
> Sent: Tuesday, July 24, 2018 10:37 PM
> To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Peter Psenak (ppsenak)
> <ppsenak@cisco.com>; Aijun Wang <wangaijun@tsinghua.org.cn>; 'Rob Shakir'
> <rjs@rob.sh>
> Cc: Dongjie (Jimmy) <jie.dong@huawei.com>; chopps@chopps.org; lsr@ietf.org
> Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area
> topology retrieval
>
> Hi Ketan,
>
> On 7/24/18, 7:44 AM, "Ketan Talaulikar (ketant)" <ketant@cisco.com> 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 <wangaijun@tsinghua.org.cn>; 'Rob Shakir' <rjs@rob.sh>
> Cc: 'Dongjie (Jimmy)' <jie.dong@huawei.com>; chopps@chopps.org; Ketan
> Talaulikar (ketant) <ketant@cisco.com>; lsr@ietf.org; Acee Lindem (acee)
> <acee@cisco.com>
> 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:rjs@rob.sh]
> > *发送时间:*2018年7月24日7:04
> > *收件人:*Peter Psenak
> > *抄送:*Dongjie (Jimmy); chopps@chopps.org; Ketan Talaulikar (ketant);
> > Aijun Wang; lsr@ietf.org; 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=40cisco.com@dmarc.ietf.org
> > <mailto:40cisco.com@dmarc.ietf.org>>
> > 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>=40cisco.com@dmarc.ietf.org
> > <mailto:40cisco.com@dmarc.ietf.org>]
> > > 发送时间: 2018年7月23日18:20
> > > 收件人: Aijun Wang; 'Peter Psenak'; chopps@chopps.org
> > <mailto:chopps@chopps.org>
> > > 抄送: lsr@ietf.org <mailto:lsr@ietf.org>; '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>=40cisco.com@dmarc.ietf.org
> > <mailto:40cisco.com@dmarc.ietf.org>]
> > > > 发送时间: 2018年7月23日16:15
> > > > 收件人: Aijun Wang; chopps@chopps.org
> <mailto:chopps@chopps.org>
> > > > 抄送: lsr@ietf.org <mailto:lsr@ietf.org>; '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
> > > > Lsr@ietf.org <mailto:Lsr@ietf.org>
> > > > https://www.ietf.org/mailman/listinfo/lsr
> > > >
> > > > _______________________________________________
> > > > Lsr mailing list
> > > > Lsr@ietf.org <mailto:Lsr@ietf.org>
> > > > https://www.ietf.org/mailman/listinfo/lsr
> > > >
> > >
> > > _______________________________________________
> > > Lsr mailing list
> > > Lsr@ietf.org <mailto:Lsr@ietf.org>
> > > https://www.ietf.org/mailman/listinfo/lsr
> > >
> > > .
> > >
> >
> > _______________________________________________
> > Lsr mailing list
> > Lsr@ietf.org <mailto:Lsr@ietf.org>
> > https://www.ietf.org/mailman/listinfo/lsr
> >
>
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic