--- 1/draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-06.txt 2015-03-03 12:14:33.955379400 -0800 +++ 2/draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07.txt 2015-03-03 12:14:33.995380368 -0800 @@ -1,21 +1,21 @@ TEAS Working Group Fei Zhang, Ed. Internet-Draft Huawei Intended status: Standards Track Ruiquan Jing -Expires: August 28, 2015 China Telecom +Expires: September 4, 2015 China Telecom Rakesh Gandhi, Ed. Cisco Systems - February 24, 2015 + March 3, 2015 RSVP-TE Extensions for Associated Bidirectional LSPs - draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-06 + draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07 Abstract This document describes Resource reSerVation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single sided provisioning. The @@ -409,23 +409,23 @@ Extended Association ID: For both single sided and double sided provisioning, Extended Association ID, when used, MUST be set to a value selected by the node that originates the association for the bidirectional LSP. 4.4. REVERSE_LSP Object Definition 4.4.1. REVERSE_LSP Object Format - The REVERSE_LSP Object in the forward LSP Path message is used to - carry information to be used by the reverse LSP. The object also - indicates that the LSP is the forward LSP of a single sided + The REVERSE_LSP Object is carried in the Path message of a forward + LSP to provide information to be used by the reverse LSP. The object + also indicates that the LSP is the forward LSP of a single sided provisioned associated bidirectional LSP. The Object has the following format: Class_Num = 203, C_Type = 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | @@ -436,21 +436,21 @@ 4.4.2. REVERSE_LSP Subobjects Subobjects are used to override the default contents of Path message of a Reverse LSP, see Section 5.2. The contents of a REVERSE_LSP Object is zero or more variable length subobjects that have the same format as RSVP Objects, see Section 3.1.2 of [RFC2205]. Any Object that may be carried in a Path message MAY be carried in the REVERSE_LSP Object. Subobject ordering MUST follow any Path message Object ordering requirements. - Examples of the Path message objects that can be carried in the + Examples of the Path message Objects that can be carried in the REVERSE_LSP Object are (but not limited to): - SENDER_TSPEC [RFC2205] - EXPLICIT_ROUTE Object (ERO) [RFC3209] - SESSION_ATTRIBUTE Object [RFC3209] - ADMIN_STATUS Object [RFC3473] - LSP_REQUIRED_ATTRIBUTES Object [RFC5420] - PROTECTION Object [RFC3473] [RFC4872] 5. Processing Rules @@ -714,39 +714,33 @@ Error Code = 01: "Admission Control Failure" (see [RFC2205]) o "Admission Control Failure/Reverse LSP Failure" (TBA) There are no other IANA considerations introduced by this document. 7. Security Considerations This document introduces two new Association Types for the (Extended) ASSOCIATION Object, double sided associated bidirectional LSP and - single sided associated bidirectional LSP. For the double sided - associated bidirectional LSP, no new security issues relating to the - (Extended) ASSOCIATION Object are introduced. For the single sided - associated bidirectional LSP, the initiating node triggers an LSP - creation on the remote node by signaling a REVERSE_LSP Object. This - introduces a security issue on the remote node. An administrative - policy may be provisioned on the remote node to deny the triggering - of a reverse LSP by an initiating node. - - The REVERSE_LSP Object in the forward LSP Path message of the single - sided associated bidirectional LSP may carry parameters for the - reverse LSP. This does allow for additional information to be - conveyed, but this information is not fundamentally different from - the information that is already carried in RSVP. Therefore, there - are no new risks or security considerations introduced by this - object. + single sided associated bidirectional LSP. The introduction of these + types, by themselves, introduce no additional information to + signaling. Related security considerations are already covered for + this in RFC6780. - Otherwise, this document introduces no additional security - considerations. For a general discussion on MPLS and GMPLS related + The REVERSE_LSP Object is carried in the Path message of a forward + LSP of the single sided associated bidirectional LSP. It can carry + parameters for the reverse LSP. This does allow for additional + information to be conveyed, but this information is not fundamentally + different from the information that is already carried in a + bidirectional LSP message. The processing of such messages are + already subject to local policy, as well as security considerations + discussions. For a general discussion on MPLS and GMPLS related security issues, see the MPLS/GMPLS security framework [RFC5920]. 8. Acknowledgement The authors would like to thank Lou Berger and George Swallow for their great guidance in this work, Jie Dong for the discussion of recovery, Lamberto Sterling for his valuable comments on the section of asymmetric bandwidths, Attila Takacs for the discussion of the provisioning model and Lou Berger, Daniel King and Deborah Brungard for the review of the document. At the same time, the authors would