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) <ginsb...@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 <wangai...@tsinghua.org.cn> > *Sent:* Thursday, February 21, 2019 3:27 PM > *To:* John E Drake <jdrake=40juniper....@dmarc.ietf.org> > *Cc:* Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Acee Lindem (acee) < > a...@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....@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-boun...@ietf.org> *On Behalf Of *Les Ginsberg (ginsberg) > *Sent:* Monday, February 18, 2019 8:22 AM > *To:* Acee Lindem (acee) <a...@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-boun...@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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_search_-3Fsubmit-3Ddraft-26id-3Ddraft-2Dwang-2Dlsr-2Dospf-2Dprefix-2Doriginator-2Dext&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=yONjTFGQ4o2Kn4-71l1WNkaIh-ck54I626wsy_xfbfM&s=QSvTQLLyqhq6OcKx4iGyD3Xp7jvD_Hc_t03Lvct3CJE&e=> > > 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
