Thanks, I had missed that both sides send OPEN. -Ekr
On Thu, May 3, 2018 at 3:59 AM, Jonathan Hardwick < jonathan.hardw...@metaswitch.com> wrote: > Hi Eric > > > > Sorry for the slow reply. You are correct – there will be a handshake > failure during PCEP session initialization. One peer will advertise its > only path setup capability as being X (X != RSVP-TE). The other peer > (which does not support this draft) doesn’t advertise any path setup > capability. The first peer concludes that the second peer supports only > RSVP-TE and closes the PCEP session. The relevant passages from the draft > are as follows. > > > > In section 3: > > > > The absence of the PATH-SETUP-TYPE-CAPABILITY TLV from the OPEN > > object is equivalent to a PATH-SETUP-TYPE-CAPABILITY TLV containing a > > single PST of 0 (RSVP-TE signaling protocol) and no sub-TLVs. > > > > In section 5: > > > > If the PCEP > > speaker and its peer have no PSTs in common, then the PCEP speaker > > MUST send a PCErr message with Error-Type = 21 (Invalid traffic > > engineering path setup type) and Error-Value = 2 (Mismatched path > > setup type) and close the PCEP session. > > > > Best regards > > Jon > > > > > > *From:* Eric Rescorla [mailto:e...@rtfm.com] > *Sent:* 04 April 2018 19:28 > *To:* Julien Meuric <julien.meu...@orange.com> > *Cc:* The IESG <i...@ietf.org>; draft-ietf-pce-lsp-setup-t...@ietf.org; > pce-cha...@ietf.org; pce@ietf.org > *Subject:* Re: Eric Rescorla's No Objection on > draft-ietf-pce-lsp-setup-type-09: (with COMMENT) > > > > > > > > On Wed, Apr 4, 2018 at 9:14 AM, Julien Meuric <julien.meu...@orange.com> > wrote: > > Hi Eric, > > As a shepherd, I can address your 2nd concern without waiting for the > authors. > > For both defined TLVs, the backward compatibility is addressed by the > last sentence of sections 3 and 4: > " If a PCEP speaker does not recognize the PATH-SETUP-xxx > TLV, it MUST ignore the TLV in accordance with ([RFC5440])." > > > > Sorry for not being clear. I meant a different case. What happens when an > existing > > PCEP speaker (which is not familiar with this TLV) tries to talk to > someone who > > (a) doesn't use RSVP-TE (b) advertises that fact via this mechanism. I > believe > > you get some kind of handshake failure. Is that correct? > > > > -Ekr > > > > > The exact wording will be updated to address other comments, e.g.: > - MUST -> will, > - Make it explicit that an ignored TLV is similar to an absent TLV, and > implies the only existing method before this I-D, i.e. X == RSVP-TE > signaling (cf. Martin's comment). > > Thanks, > > Julien > > > Apr. 04, 2018 - e...@rtfm.com: > > > Eric Rescorla has entered the following ballot position for > > draft-ietf-pce-lsp-setup-type-09: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Please expand RP and SRP on first use. > > > > What is the backward compatibility story here? I.e., say I only support > method > > X and the peer doesn't know about this TLV at all? How will it behave? > > > > > > >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
