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<mailto: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<mailto: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
