Re: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-01.txt

Qin -

Thanx for the prompt response.
Responses inline.

> -----Original Message-----
> From: Qin Wu <bill.wu@huawei.com>
> Sent: Monday, June 03, 2019 5:09 AM
> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; lsr@ietf.org
> Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-
> 01.txt
> 
> Hi, Les:
> Thanks for your comments, see my reply inline.
> -----邮件原件-----
> 发件人: Lsr [mailto:lsr-bounces@ietf.org] 代表 Les Ginsberg (ginsberg)
> 发送时间: 2019年6月3日 14:22
> 收件人: lsr@ietf.org
> 主题: Re: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-01.txt
> 
> 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??
> 
> Due to low priority of this work in PCE and heavy agenda when we
> proceeded this work earlier in PCE, we made very little progress.
> This has been a little bit changed during adoption call and we authors were
> also active in both PCE and LSR WG
> see the following link:
> https://mailarchive.ietf.org/arch/msg/lsr/wVZ7iELBEqYzvnKwdRR8MNoN6zQ
> 

[Les:] Yes - I had noted Julien's post in my search of the archives. But he was making comments as an individual on the content of the draft. I do not see that he was making any comment regarding the position of the PCE WG.
I am wondering if in the intervening 6 months the PCE WG has taken a position on this.

> 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.
> [Qin]: It seems your argument also applies to RFC5088/5089.

[Les:] Indeed - which is why the limitation of "this much and no more" was put into RFC 5088/5089.

> 
> 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.
> [Qin]: Sure, but RFC5088/89 has already provide way to carry additional info.
> We could use some other out-band mechanism to carry additional info
> beyond PCED sub-TLVs defined in RFC5088/89, but do you think
> 1. use one protocol to convey all information needed
> 2. use two protocol to convey information separately
> Which one is optimal?

[Les:] What are you going to do when the PCE is not also an LSR?
My concern is two fold:

1)That we further use the IGPs to carry non-IGP information.
(Again - this would not be the first time - but we should do this carefully.)

2)That in cases where the PCE is NOT an LSR this extension would be of no use - so it seems you will have to define an alternate means of signaling this info anyway.

> 
> 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.
> [Qin]: We don't' have too many changes going to RFC5088/89, so it is expense
> to make bis document, it is cheaper to leverage RFC updates attribute tool.

[Les:] Given that the draft contradicts what is written in RFC 5088/5089, by writing a bis draft readers do not have to consult two different documents to get the full story.
The "extra work" is modest because you simply cut and paste the original text and then make the necessary modifications and additions.

I am not insisting on this - but asking you to consider it - as it would make life easier for future readers.

   Les

> And, BTW, do you know why the HTML version of the document has no table
> of contents?
> [Qin]:It is weird, seems we are using wrong boilerplate, I will see how to fix
> this.
> 
>    Les
> 
> 
> > -----Original Message-----
> > From: Lsr <lsr-bounces@ietf.org> On Behalf Of internet-drafts@ietf.org
> > Sent: Sunday, June 02, 2019 8:45 PM
> > To: i-d-announce@ietf.org
> > Cc: lsr@ietf.org
> > 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-supp
> > ort-01
> > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-pce-discovery-sec
> > urity-
> > support-01
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-securit
> > y-
> > 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
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr