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 <[email protected]> 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) <[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
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
