Also, speaking as WG member: I support adoption.
Thanks, Acee From: Lsr <lsr-boun...@ietf.org> on behalf of Acee Lindem <a...@cisco.com> Date: Tuesday, February 19, 2019 at 10:19 AM To: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com>, Aijun Wang <wangai...@tsinghua.org.cn>, "lsr@ietf.org" <lsr@ietf.org> Subject: Re: [Lsr] 答复: Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01 Speaking as WG member: Hi Les, Aijun, et al, After much discussion, we made the discovery all non-normative. If this is not the case, we’ll certainly fix this prior to publication. Given that the use case is a single OSPF routing domain that is under a single administrative control, there is no reason that the constraints (nothing but numbered P2P links) could not be imposed as deployment policies. The LSR working is currently “flooded” with contention and I don’t see that this is even worth arguing about. Thanks, Acee From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> Date: Monday, February 18, 2019 at 11:43 PM To: Aijun Wang <wangai...@tsinghua.org.cn>, Acee Lindem <a...@cisco.com>, "lsr@ietf.org" <lsr@ietf.org> Subject: RE: [Lsr] 答复: Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01 Aijun – The fact that you have acknowledged the limitations pointed out by others (notably Peter) is a good thing – but it doesn’t alter the fact that what you have proposed cannot be trusted. Routers outside of an area have no way of knowing whether the area in question has unnumbered links or has true LANs – so of what value is the information which is advertised? Your argument seems to be – “well at least some of the time an area may have only numbered links/no true LANs and therefore it is OK to use the topology information and hope the assumptions hold” – but for many of us this is exactly what makes the idea unappealing – that it cannot be relied upon and there is no way to know when it can be relied upon. Look, you have one very good idea – add support for source router-id. Let’s please move forward with that. If you still feel that you want to pursue the topology retrieval idea write a separate draft and allow the WG to make a decision on that independently. I do not like my vote in favor of a proven idea (source router id) to be held hostage by coupling it with an idea (topology discovery) whose shortcomings have been clearly identified. Les From: Lsr <lsr-boun...@ietf.org> On Behalf Of Aijun Wang Sent: Monday, February 18, 2019 6:40 PM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Acee Lindem (acee) <a...@cisco.com>; lsr@ietf.org Subject: [Lsr] 答复: Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01 Hi, Les: Thanks for your comments. After the previous discussion within WG list, I had changed the description about the inter-area topology retrieval scenario, which is the original source of this draft that is different from RFC7794. We point out such use case can be applied where each link between routers is assigned a unique prefix, which is very common within the operator network(in Appendix B. “Special consideration on Inter-Area Topology Retrieval ”). Would you like to point out the situation that such process can’t be applied and the current draft has not mentioned yet? Or we can discuss it after its adoption. We can remove such part before its publication if the situation you referred is common to the operator or enterprise network. Best Regards. Aijun Wang Network R&D and Operation Support Department China Telecom Corporation Limited Beijing Research Institute,Beijing, China. 发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 发送时间: 2019年2月18日 21:22 收件人: Acee Lindem (acee); lsr@ietf.org<mailto:lsr@ietf.org> 主题: 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-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem (acee) Sent: Wednesday, February 13, 2019 5:26 AM To: lsr@ietf.org<mailto: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