Acee - Thanx for reviving this thread.
In fairness, Qin did respond - and we exchanged a couple of emails on this thread - though I would not say that we had reached closure. He also sent an email to PCE WG asking for an update on their position - but to date I have seen no response to that. So for me - this topic is still open for further discussion - both by the authors and the LSR/PCE WGs. Les > -----Original Message----- > From: Acee Lindem (acee) > Sent: Saturday, June 22, 2019 1:36 PM > To: [email protected] > Cc: [email protected]; Les Ginsberg (ginsberg) <[email protected]> > Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support- > 01.txt > > Authors - can you respond to Les' comments? > Thanks, > Acee > > On 6/3/19, 2:22 AM, "Lsr on behalf of Les Ginsberg (ginsberg)" <lsr- > [email protected] on behalf of [email protected]> wrote: > > A few - somewhat tardy - concerns about this draft. > > 1)During adoption call it was mentioned that PCE WG had not taken a > position on this draft. Since I don't follow PCE WG (apologies) I need to ask > - > has that status changed?? > > 2)As discussed during the adoption call, the draft removes the restriction > specified in RFC 5088/5089 of not allowing further PCE related > advertisements in Router Capability TLV/Router Information LSA. > Acee had mentioned that he thought this was no longer a concern because > in RFC 7770 multiple OSPF Router Information LSA support was introduced. > But this is really not relevant to the reason that the restriction was > originally > introduced. > > The restriction was introduced because of general concern that using IGPs > to advertise information not directly relevant to the operation of the IGP as > a > routing protocol is sub-optimal and negatively impacts the performance of > the primary IGP functions. > > I am aware that this is a line that has been crossed (in modest ways) more > than once - and I am not categorically opposing the extensions proposed - > but I do wonder if this is the most appropriate way to advertise the new > attributes - particularly since this does not solve the general case - it only > applies when the PCE is also an LSR. I think a broader discussion of this > issue > is warranted. > > 3)If the draft goes forward in its current form, it updates RFC 5088/5089 > in a > significant way (the removal of restriction against additional PCE related IGP > advertisements) - in which case I wonder if it would be better to write an RFC > 5088/89 bis document rather than an extension document. > > And, BTW, do you know why the HTML version of the document has no > table of contents? > > Les > > > > -----Original Message----- > > From: Lsr <[email protected]> On Behalf Of [email protected] > > Sent: Sunday, June 02, 2019 8:45 PM > > To: [email protected] > > Cc: [email protected] > > Subject: [Lsr] I-D Action: > draft-ietf-lsr-pce-discovery-security-support- > 01.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Link State Routing WG of the IETF. > > > > Title : IGP extension for PCEP security capability > support in the > PCE > > discovery > > Authors : Diego R. Lopez > > Qin Wu > > Dhruv Dhody > > Michael Wang > > Daniel King > > Filename : > draft-ietf-lsr-pce-discovery-security-support-01.txt > > Pages : 10 > > Date : 2019-06-02 > > > > Abstract: > > When a Path Computation Element (PCE) is a Label Switching Router > > (LSR) participating in the Interior Gateway Protocol (IGP), or even a > > server participating in IGP, its presence and path computation > > capabilities can be advertised using IGP flooding. The IGP > > extensions for PCE discovery (RFC 5088 and RFC 5089) define a method > > to advertise path computation capabilities using IGP flooding for > > OSPF and IS-IS respectively. However these specifications lack a > > method to advertise PCEP security (e.g., Transport Layer > > Security(TLS), TCP Authentication Option (TCP-AO)) support > > capability. > > > > This document proposes new capability flag bits for PCE-CAP-FLAGS > > sub-TLV that can be announced as attribute in the IGP advertisement > > to distribute PCEP security support information. In addition, this > > document updates RFC 5088 and RFC 5089 to allow advertisement of > Key > > ID or Key Chain Name Sub-TLV to support TCP AO security capability. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security- > > support/ > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-ietf-lsr-pce-discovery-security-support- > 01 > > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-pce-discovery- > security- > > support-01 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security- > > support-01 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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
