Agreed. Also as use cases go that does delve into implementation aspects of which can vary significantly.
So to your point as Les and Chris mentioned the focus of LSR and drafts published is on the protocol extension. How it’s used is out of scope and could be a draft in another WG. In this case moreso not pertinent since the primary use case gets into the weeds on a TEAS or PCE topiic. Thanks Gyan On Fri, Oct 16, 2020 at 1:04 AM Ketan Talaulikar (ketant) <ket...@cisco.com> wrote: > Hi Gyan, > > > > Thanks for your review and feedback. Please check inline below. > > > > *From:* Gyan Mishra <hayabusa...@gmail.com> > *Sent:* 16 October 2020 10:11 > *To:* Aijun Wang <wangai...@tsinghua.org.cn> > *Cc:* Christian Hopps <cho...@chopps.org>; Jeff Tantsura < > jefftant.i...@gmail.com>; John E Drake <jdrake= > 40juniper....@dmarc.ietf.org>; Les Ginsberg (ginsberg) <ginsberg= > 40cisco....@dmarc.ietf.org>; > draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr@ietf.org; > lsr-...@ietf.org; lsr-cha...@ietf.org > *Subject:* Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 > > > > I support advancement of the draft. > > > > This draft follows along the lines of ISIS RFC 7794 to provide an > extension to identify the prefix originator attribute using an originating > router TLV and a reachable prefix. A node in ospf is represented by a > router-id which technically can be a random 4 octet prefix that does not > have to be reachable entry in the IGP RIB. > > > > The reachability prefix is important in cases where the originator > router-id is not in the RIB or in traffic engineering inter as path > instantiation use case where the router-id originator node is advertised, > however since the TEDs database link attributes are not known > inter-as,having the reachability address is important as defined in the > draft. This feature can also be used identifying the prefix originator in > a normal user case other then the traffic engineering scenario such as for > troubleshooting which is common to view all the prefixes advertised by a > node by Prefix type. > > > > There maybe cases where you need to create a database filter or policy > and if you can use this feature as a means of controlling prefix > advertisements based on source node that can be powerful and could have > ubiquitous use cases. > > > > With regards to the appendix it does appear to be pertinent, as the use > case appears to be the primary focal point and reason for the draft by the > authors. I don’t think that having the appendix precluding other use > cases by any means. > > *[KT] The Introduction section of the draft does touch upon some of the > primary use-cases that authors believe have more wide-spread applicability. > You have also alluded to some of them and then you have also brought out > some newer use-cases/applications of the extensions in this draft. There > were other use-cases in previous versions like ELC which later went away > based on how we addressed that in draft-ietf-ospf/isis-mpls-elc documents. > I am sure there will be newer use-cases. The focus of the draft is primary > to capture the protocol extensions since that is what we work on in LSR. > The scope of the use-cases may be beyond LSR and in other areas (e.g. TEAS > perhaps for the one in the appendix ?). Regarding the use-case in the > appendix, it would be fair to say that it was primary focal point for some > of the authors.* > > > > *I will leave it to the WG consensus on what content we should be sending > to the IESG.* > > > > *Thanks,* > > *Ketan* > > > > Kind Regards > > > > Gyan > > > > On Thu, Oct 15, 2020 at 9:51 PM Aijun Wang <wangai...@tsinghua.org.cn> > wrote: > > Hi, Les, John and Jeff: > > Let's reply you all together. > In my POV, The standard document should not define solely the protocol > extension, but their usages in the network deployment. As I known, almost > all the IETF documents following this style. > And, before adopting one work, we have often intense discussion for what's > their usages. > Such discussion in the mail list and statements in the document can > certainly assist the reader/user of the document get the essence of the > standard, and follow them unambiguously. > > Regarding the contents of appendices, as stated in the section, "The > Appendix A heuristic to rebuild the topology can normally be used if all > links are numbered." I think this can apply almost most of the operator's > network, and facilitate the inter-area TE path calculation for central > controller, or even for the head-end router that located in one area that > different from the tail-end router. > > Keeping the contents of appendices does not have the negative impact of > the protocol extension, it is just one reference for the usage of this > extension. > One can select not refer to it, if their networks are deployed with large > amount of unnumbered links. But for others, the heuristic applies. > > Best Regards > > Aijun Wang > China Telecom > > > > -----Original Message----- > From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of > Jeff Tantsura > Sent: Friday, October 16, 2020 5:28 AM > To: John E Drake <jdrake=40juniper....@dmarc.ietf.org> > Cc: Christian Hopps <cho...@chopps.org>; lsr-cha...@ietf.org; Les > Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>; lsr@ietf.org; > lsr-...@ietf.org; draft-ietf-lsr-ospf-prefix-origina...@ietf.org > Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 > > +1 > > Regards, > Jeff > > > On Oct 15, 2020, at 11:33, John E Drake <jdrake= > 40juniper....@dmarc.ietf.org> wrote: > > > > Hi, > > > > I agree with Les. This is a simple protocol extension for a specific > purpose and there is no reason to include speculation about its use for > other purposes, particularly when it is inherently not suited for them. > > > > Yours Irrespectively, > > > > John > > > > > > Juniper Business Use Only > > > >> -----Original Message----- > >> From: Lsr <lsr-boun...@ietf.org> On Behalf Of Les Ginsberg (ginsberg) > >> Sent: Thursday, October 15, 2020 12:33 PM > >> To: Christian Hopps <cho...@chopps.org>; lsr@ietf.org > >> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; > >> draft-ietf-lsr-ospf-prefix- origina...@ietf.org > >> Subject: Re: [Lsr] WG Last Call > >> draft-ietf-lsr-ospf-prefix-originator-06 > >> > >> [External Email. Be cautious of content] > >> > >> > >> I support moving this document forward. > >> Similar functionality in IS-IS has proved useful. > >> > >> I would however like to repeat comments I made earlier in the review > >> of this document. > >> The content of the Appendices should be removed. > >> The Appendices define and discuss deriving topology information from > >> prefix advertisements - which is flawed and should not be done. > >> Perhaps more relevant, the purpose of the document is to define > >> protocol extensions supporting advertisement of the originators of a > >> prefix advertisement. There is no need to discuss how this mechanism > >> might be used to build topology information. > >> This document should confine itself to defining the protocol > >> extensions - similar the RFC 7794. > >> > >> If the authors do not agree to do this, I would encourage this point > >> to be discussed during IESG review. > >> > >> Les > >> > >>> -----Original Message----- > >>> From: Lsr <lsr-boun...@ietf.org> On Behalf Of Christian Hopps > >>> Sent: Wednesday, October 14, 2020 11:15 PM > >>> To: lsr@ietf.org > >>> Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org; > >>> lsr-cha...@ietf.org; lsr- a...@ietf.org; Christian Hopps > >>> <cho...@chopps.org> > >>> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 > >>> > >>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for: > >>> > >>> > >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-i > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-i> > >>> et > >>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-gk!TaSzQThghtCFOuYPS2VjLq > >>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ > >>> > >>> The following IPR has been filed > >>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__ > <https://urldefense.com/v3/__https:/datatracker.ietf.org/ipr/3448/__>;! > >>> !NEt6yMaO- > >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz > >>> 5KtUHQ$ > >>> > >>> Authors, > >>> > >>> Please indicate to the list, your knowledge of any other IPR > >>> related to this work. > >>> > >>> Thanks, > >>> Chris. > >> > >> _______________________________________________ > >> Lsr mailing list > >> Lsr@ietf.org > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr> > >> __;!!NEt > >> 6yMaO- > >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdmw8 > >> Lc$ > > > > _______________________________________________ > > 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 > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > > > *M 301 502-1347 13101 Columbia Pike > <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> > <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>*Silver > Spring, MD > <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
