IETF Logo Mail Archive

Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

Aijun Wang <wangaijun@tsinghua.org.cn> Fri, 22 February 2019 07:22 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 C799D12F1A5 for <lsr@ietfa.amsl.com>; Thu, 21 Feb 2019 23:22:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level:
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 pc0Mxe07bS-t for <lsr@ietfa.amsl.com>; Thu, 21 Feb 2019 23:22:01 -0800 (PST)
Received: from m21397.mail.qiye.163.com (m21397.mail.qiye.163.com [223.252.213.97]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4B1130E5D for <lsr@ietf.org>; Thu, 21 Feb 2019 23:22:00 -0800 (PST)
Received: from [100.1.133.149] (unknown [106.121.151.136]) by m21397.mail.qiye.163.com (Hmail) with ESMTPA id DEDC0143AC6; Fri, 22 Feb 2019 15:21:51 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-6F2A172B-6D17-4BC4-B8FA-037C8EAB6575"
Mime-Version: 1.0 (1.0)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <CA+wi2hPUSbrC1M5rc06CYD4BaNDAz3shz=MBosP2nBQnbZps9Q@mail.gmail.com>
Date: Fri, 22 Feb 2019 15:20:34 +0800
Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <DA65CDAE-C6D7-428E-B9D8-204BDB070960@tsinghua.org.cn>
References: <A4351C7F-183D-4490-BD3C-5ADC5C087F84@cisco.com> <BYAPR11MB3638721E27A230B39F174D5EC1630@BYAPR11MB3638.namprd11.prod.outlook.com> <BYAPR05MB50292A0A6C19E8A4851930C8C77E0@BYAPR05MB5029.namprd05.prod.outlook.com> <3B426740-F8DF-4E2B-8322-98E2EF2ACD31@tsinghua.org.cn> <BYAPR11MB36388DF801A22788E9F93F88C17F0@BYAPR11MB3638.namprd11.prod.outlook.com> <CA+wi2hPUSbrC1M5rc06CYD4BaNDAz3shz=MBosP2nBQnbZps9Q@mail.gmail.com>
To: Tony Przygienda <tonysietf@gmail.com>
X-HM-Spam-Status: e1kIGBQJHllBS1VLV1koWUFKTEtLSjdXWS1ZQUlXWQkOFx4IWUFZMjUtOj cyP0FLVUtZBg++
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Pio6Ezo*FDkCGC9RTDw2SC8I SRgwCRxVSlVKTk5LQ0lLSkpDSE5OVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS01VSklKVUpOSlVKSE1ZV1kIAVlBSU5CSkw3Bg++
X-HM-Tid: 0a691414f6307f6bkuukdedc0143ac6
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/7mJICBRqKJv3Kx8nc_zlCvzRJKk>
Subject: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 22 Feb 2019 07:22:05 -0000

Hi, Tony:
Not got well all your comments :(
Wish the explanation in previous mail to Les can change your impression to this draft a bit.

Best Regards.

Aijun Wang
China Telecom

> On Feb 22, 2019, at 14:42, Tony Przygienda <tonysietf@gmail.com> wrote:
> 
> I read it during some mildly boring phone conference here ;-) I do (unsuprisingly) tend to agree with Mr. Ginsberg here. Putting originator on prefix, well, ok, I understand how people got there instead of having a clean router LSA with its loopback hanging of it (which would be IMO the right abstraction but alas, IP decided originally that interfaces have addresses and routers, well, don't. Overall not the best architecture remedied by loopback hacks since forever then. I digress ...). So putting router-id on type-3 loopback serves its purpose of "how do I get to this node across topology abstractions [areas]". Allows central entities (controllers and such) to get to every node in the topology without violating abstractions (too much ;-). Cleaner solutions would be thinkable but more complex obviously. But coming back to this draft, alas, trying to build the whole topology distribution tails-up, i.e. redistribute topology view behind prefixes which are really leafs-of-topology strikes me just another confused slippery slope just like re-encoding one protocol's native formats into another protocol :-P ... And if the authors suffer from mild bout of over-creativity I suggest to split that part into an informational draft ... 
> 
> --- tony 
> 
>> On Thu, Feb 21, 2019 at 9:56 PM Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote:
>> Aijun –
>> 
>>  
>> 
>> Controllers already have a reliable way to learn topology information for all areas.
>> 
>> There is therefore no need for the topology discovery solution you propose – and all the more so because your proposal does not work in all cases and you have no definition of how a controller could tell when the information can be trusted and when it can’t.
>> 
>>  
>> 
>> The only thing which is needed is to define a way to identify the source router-id of prefixes which are leaked between areas – which is what I have asked you to limit the draft to do.
>> 
>>  
>> 
>> The mention of ELC/ERLD/MSD in your draft is spurious since you actually haven’t defined any way to advertise that information between areas (nor do I want you to do so).  It should be removed.
>> 
>>  
>> 
>> I say again, this draft in its current form is not ready to be adopted.
>> 
>>  
>> 
>>    Les
>> 
>>  
>> 
>>  
>> 
>> From: Aijun Wang <wangaijun@tsinghua.org.cn> 
>> Sent: Thursday, February 21, 2019 3:27 PM
>> To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
>> Cc: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Acee Lindem (acee) <acee@cisco.com>; lsr@ietf.org
>> Subject: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01
>> 
>>  
>> 
>> Hi, John:
>> 
>>  
>> 
>> Thanks for your review and comments.
>> 
>> The use cases and original thought in this draft are different from that  described in RFC7794. We have pointed out that RFC7794 has the similar extension for ISIS and indicated that the extension for ISIS can also be used in the use cases described in our draft. What’ other content do you think it is needed further?
>> 
>> RFC 7770  solves mainly the advertising of router’s capabilities, it shouldn’t be used for transmitting the information about the prefixes.
>> 
>>  
>> 
>> Best Regards.
>> 
>>  
>> 
>> Aijun Wang
>> 
>> China Telecom
>> 
>> 
>> On Feb 21, 2019, at 23:41, John E Drake <jdrake=40juniper.net@dmarc.ietf.org> wrote:
>> 
>> Hi,
>> 
>>  
>> 
>> I agree with Les.  I think the draft should be recast to indicate that it is providing OSPF parity with RFC 7794.
>> 
>> Can’t topology discovery be done using RFC 7770?
>> 
>>  
>> 
>> Yours Irrespectively,
>> 
>>  
>> 
>> John
>> 
>>  
>> 
>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Les Ginsberg (ginsberg)
>> Sent: Monday, February 18, 2019 8:22 AM
>> To: Acee Lindem (acee) <acee@cisco.com>; lsr@ietf.org
>> Subject: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01
>> 
>>  
>> 
>> To the extent that the draft defines functionality equivalent to that defined in IS-IS RFC 7794 – specifically a means to advertise the source router-id of a given advertisement – it defines a necessary and useful extension to the OSPF protocol – and I support that work.
>> 
>>  
>> 
>> However, in its current form the draft discusses use of this mechanism for inter-area topology discovery. This idea is seriously flawed – as has been discussed extensively on the WG list.
>> 
>> The draft also discusses uses cases related to ERLD, the direction for which is very much uncertain at this time.
>> 
>>  
>> 
>> I therefore feel that the current content of the draft is not what I would expect to see approved by the WG as an RFC and therefore have significant reservations about moving forward with the existing content.
>> 
>>  
>> 
>> I do want to see a draft addressing the source router-id advertisement gap move forward – and if this draft is reduced to focus on that then I can enthusiastically support adoption – but in its current form I cannot indicate support.
>> 
>>  
>> 
>>    Les
>> 
>>  
>> 
>>  
>> 
>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Acee Lindem (acee)
>> Sent: Wednesday, February 13, 2019 5:26 AM
>> To: lsr@ietf.org
>> Subject: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01
>> 
>>  
>> 
>> This begins a two week adoption poll for the subject draft. Please send your comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.
>> 
>>  
>> 
>> All authors have responded to the IPR poll and there is one  https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext
>> 
>> It is listed multiple times but references the same CN201810650141.
>> 
>>  
>> 
>> Thanks,
>> 
>> Acee
>> 
>>  
>> 
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>> 
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

v2.23.0 | Report a Bug | By Email