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

"Aijun Wang" <wangaijun@tsinghua.org.cn> Tue, 24 July 2018 23:53 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02075130E67 for <lsr@ietfa.amsl.com>; Tue, 24 Jul 2018 16:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNNNY9MXu2Fw for <lsr@ietfa.amsl.com>; Tue, 24 Jul 2018 16:53:52 -0700 (PDT)
Received: from m88102.mail.qiye.163.com (m88102.mail.qiye.163.com [106.2.88.102]) by ietfa.amsl.com (Postfix) with ESMTP id CFEEC130E26 for <lsr@ietf.org>; Tue, 24 Jul 2018 16:53:51 -0700 (PDT)
Received: from WangajPC (unknown [219.142.69.77]) by m88102.mail.qiye.163.com (Hmail) with ESMTPA id 81FC7415AF; Wed, 25 Jul 2018 07:53:39 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: "'Ketan Talaulikar (ketant)'" <ketant@cisco.com>, "'Acee Lindem (acee)'" <acee@cisco.com>, "'Peter Psenak (ppsenak)'" <ppsenak@cisco.com>, 'Rob Shakir' <rjs@rob.sh>
Cc: "'Dongjie (Jimmy)'" <jie.dong@huawei.com>, chopps@chopps.org, lsr@ietf.org
References: <001601d42259$a860fff0$f922ffd0$@org.cn> <5B558E76.3010703@cisco.com> <003201d42265$cd011af0$670350d0$@org.cn> <5B55ABB5.60806@cisco.com> <003f01d42275$5ec00eb0$1c402c10$@org.cn> <5B55BC38.3050605@cisco.com> <CAHxMReYo_e+dDJ611X3eihV0WCToYqFDa2c+CLnfzhF8_L2YDA@mail.gmail.com> <003701d422ff$a1b203b0$e5160b10$@org.cn> <5B56E18C.4060903@cisco.com> <a1de561505bb4d46855dfadb3a59b239@XCH-ALN-008.cisco.com> <44287233-F703-4B4A-A70A-622AE7C1811D@cisco.com> <dd4a6c2e9825470ba1bd2c8cec76de11@XCH-ALN-008.cisco.com>
In-Reply-To: <dd4a6c2e9825470ba1bd2c8cec76de11@XCH-ALN-008.cisco.com>
Date: Wed, 25 Jul 2018 07:53:37 +0800
Message-ID: <003701d423a9$8ac4de70$a04e9b50$@org.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHUI1vQB2aOPXBr0kadIEZqLLPUHKSehQgQgACEW6A=
Content-Language: zh-cn
X-HM-Spam-Status: e1ktWUFJV1koWUFKTEtLSjdXWQgYFAkeWUFLVUtXWQkOFx4IWUFZMjUtOj cyP0FLVUtZBg++
X-HM-Sender-Digest: e1kSHx4VD1lBWUc6MBg6MCo5CDohAyoRVgswTzA*Ti0wCQNVSlVKTkhJ T0xNT0hLS0JOVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZDB4ZWUEdGhcIHldZ CAFZQUpCTkJJN1dZEgtZQVlJSkJVSk9JVU1CVUxMWQY+
X-HM-Tid: 0a64ceb66ed19865kuuu81fc7415af
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/VTD-7_TVDH6nRUQWDlbbNzWAuUY>
Subject: [Lsr] 答复: 答复: 答复: 答复: Regarding OSPF extension for inter-area topology retrieval
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jul 2018 23:53:57 -0000

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:ketant@cisco.com] 
发送时间: 2018年7月24日 23:56
收件人: Acee Lindem (acee); Peter Psenak (ppsenak); Aijun Wang; 'Rob Shakir'
抄送: 'Dongjie (Jimmy)'; chopps@chopps.org; lsr@ietf.org
主题: RE: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

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