Hi Dhruv, Thank you for your feedback, this is valuable.
I fully agree with your first statement: so far, any PCEP peer is assumed as RSVP-TE-compliant. When no path setup type is explicitly expressed, this must remain the assumption, I am not questioning the default. However, I believe there will be some networks (e.g. SR-enabled) where: - multiple PCEs may support different capabilities while, in the current I-D, the only way for a PCC to identify that RSVP-TE is not supported would be to send a PCReq and get a session-closing "Unsupported path setup type" error; - some PCCs are not actually RSVP-TE-capable, thus PCE-initiated TE-LSPs will also face a session-closing "Unsupported path setup type" error (by the way, I feel we should not close the session in this case). I see two ways to address this case with a reasonable effort: - assume that when path setup types are explicitly expressed (which remains optional), there is no implicit assumption, thus the RSVP-TE capability advertisement proposed below; - stick with this implicit RSVP-TE support by default, which would require an RSVP-TE-NON-SUPPORT TLV some time. Assuming we can agree on the requirement, I prefer to add TLVs to express capabilities rather than disable them. If you believe otherwise, I wonder if the latter proposal would be an acceptable trade-off. Cheers, Julien May. 03, 2017 - dhruv.i...@gmail.com: > Hi Julien, > > In my understanding, PCEP sessions are always RSVP-TE capable. > One may not want any LSP to be signaled by RSVP-TE, in which case > PATH-SETUP-TYPE TLV would be encoded per LSP (in case of SR, this is > MUST anyways by SR I-D). > > Also, isnt this, what we have always done with stateless to stateful > PCE or P2P to P2MP extensions and so on, should we consider > path-setup-type to be different? > > Just some thoughts, lets see what the authors/WG think... > > Regards, > Dhruv > > > On Wed, May 3, 2017 at 7:17 PM, Julien Meuric > <julien.meu...@orange.com <mailto:julien.meu...@orange.com>> wrote: > > [Chair hat off] > > Authors of draft-ietf-pce-lsp-setup-type, > > Reading the I-D, it looks to me that a (small) piece is missing. > Let us > assume that I want my PCEP peers to advertise they are both SR-capable > and RSVP-TE-capable over a given session: the SR-PCE-CAPABILITY TLV is > defined in the SR I-D, but where is the RSVP-TE counterpart? I feel we > should add a 4-byte RSVP-TE-CAPABILITY TLV, with length = 0 and > recommended omission in case of RSVP-TE only. > > My 50 cents, > > Julien > > > May. 02, 2017 - Julien Meuric: > > Dear all, > > > > The aforementioned I-D has been stable for a while. This message > > initiates a 2-week WG Last Call on draft-ietf-pce-lsp-setup-type-04. > > Please send your comments to the PCE mailing list by May 15. > > > > Thanks, > > > > Jon, JP & Julien > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org <mailto:Pce@ietf.org> > > https://www.ietf.org/mailman/listinfo/pce > <https://www.ietf.org/mailman/listinfo/pce> > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org <mailto:Pce@ietf.org> > https://www.ietf.org/mailman/listinfo/pce > <https://www.ietf.org/mailman/listinfo/pce> > > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
