Hi, Les: The method to retrieve the topology information for inter-area scenario that described in the current draft is more easily deployment and less requirements for the connections between the controller and underlying routers. The ELC, ERLD and MSD are capabilities of the routers and can be flooded via the mechanisms described in RFC7770. If there is no draft described the details process, we can cooperate to write one.
Acee has pointed out that these OSPF areas are often under one administrative scope, and they know the address allocation philosophy of their underlying networks, then can assure the reliability of the retrieved topology. Anyway, the aim of this draft is to let reader know how to use the introduced extension, not merely the extension itself. Best Regards Aijun Wang China Telecom > On Feb 22, 2019, at 13:56, Les Ginsberg (ginsberg) <[email protected]> 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 <[email protected]> > Sent: Thursday, February 21, 2019 3:27 PM > To: John E Drake <[email protected]> > Cc: Les Ginsberg (ginsberg) <[email protected]>; Acee Lindem (acee) > <[email protected]>; [email protected] > 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 > <[email protected]> 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 <[email protected]> On Behalf Of Les Ginsberg (ginsberg) > Sent: Monday, February 18, 2019 8:22 AM > To: Acee Lindem (acee) <[email protected]>; [email protected] > 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 <[email protected]> On Behalf Of Acee Lindem (acee) > Sent: Wednesday, February 13, 2019 5:26 AM > To: [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
