Sorry, I missed one more comment below:

Section 7 

Security Considerations

[Lizhong] the single side provisioning mode will allow one node to trigger another


   node to setup LSP. This will introduce some security issue for the remote node. 


   Some administrative police may be introduced to allow/deny others to trigger LSP setup.







Regards

Lizhong




 

From:

 

lizho.jin at gmail.com

Date:

 2015-02-19 17:21

To:

 

teas

; 

draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp

CC:

 

rtg-dir at ietf.org

; 

rtg-ads

; 

teas

Subject:

 RtgDir Review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-02




Hello

 

I have been selected as the Routing Directorate reviewer for this draft.

The Routing Directorate seeks to review all routing or routing-related

drafts as they pass through IETF last call and IESG review, and

sometimes on special request. The purpose of the review is to provide

assistance to the Routing ADs. For more information about the Routing

Directorate, please see ​

http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

 

Although these comments are primarily for the use of the Routing ADs, it

would be helpful if you could consider them along with any other IETF

Last Call comments that you receive, and strive to resolve them through

discussion or by updating the draft.

 

Document: 

draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-02

Reviewer: Lizhong Jin

Review Date: 19 February 2015

IETF LC End Date: N/A

Intended Status: Standard Track

 

Summary:

The document is basically ready for publication. I found some minor 

issues, and hope

to see the clarification.

Commnets:

I paticipate the initial discussion of this draft. I am lucky to review 

it again. Overall, the

processing rule of independent provisioning hope to be explicitly 

described. 

No major issues, some minor issues need to be clarified.

Major issues: No

Minor issues:

Section 3.2

In each of the situations described above, both provisioning models


   are applicable.


[Lizhong]: for the second situations above, how could you let the reverse LSP 


   to be existed before the forward LSP for single side provisioning? Wouldn't the 

reverse LSP trigger another 

reverse LSP?

Section 3.2.1. 

   For the single sided provisioning model, creation of reverse LSP1 is


   triggered by LSP2 or creation of reverse LSP2 is triggered by LSP1. 


   When creation of reverse LSP2 is triggered by LSP1, LSP1 is


   provisioned first (or refreshed if LSP1 already exists) at node A. 


[Lizhong]: LSP1 and LSP2 is in Firgure1? Better to explicitly say that in

the document.

 A similar procedure is used if LSP2 is provisioned first at node B


   and the creation of reverse LSP1 at node A is either triggered by


   LSP2 or the reverse LSP1 existed.  In all three scenarios, the two


   unidirectional LSPs are bound together to form an associated


   bidirectional LSP based on identical (Extended) ASSOCIATION Objects


   in the two LSPs' Path messages.


[Lizhong]: I doubt if the following scenario is realistic in Single Sided Provisioning. 


   LSP2 is provisioned first, reverse LSP1 at node A is existed before LSP2.


   The what is the Association Type in reverse LSP1? Before LSP2, will the reverse 

LSP1 trigger another LSP? 

Section 5.  Processing Rules


   In general, the processing rules for the ASSOCIATION Object are as


   specified in [RFC4872] and Extended ASSOCIATION Object are specified


   in [RFC6780].  Following sections describe the rules for processing


   (Extended) ASSOCIATION and REVERSE_LSP objects for associated


   bidirectional LSPs.


[Lizhong]: across the draft, it is not explicitly saying what is the processing 

rules for independent provisioning. It is better to say it here or other place.

Section 5.1

(Extended)
ASSOCIATION Objects with both single sided and double sided


   Association Types MUST NOT be added in the same Path message.


[Lizhong]: what if two types exist together? Only use the first one?

Section 5.2

The REVERSE_LSP Object MUST NOT be
included in a REVERSE_LSP Object.


[Lizhong]: typo here?

Section 5.3

In particular, any object that was
copied as part of initial Path message creation MUST

be copied when
modified.  


[Lizhong]: not understood "copied when modified", is it "copied after modified"?




In both cases, when the egress node receives a PathTear message the


   node MUST remove the associated reverse LSP using Standard PathTear


   message processing.  Tear down of the reverse LSP for other reasons


   SHOULD NOT trigger removal of the initiating LSP, but SHOULD result


   in the egress node sending a PathErr with Error code "Admission


   Control Failure (01) [RFC2205]" and Sub-code "Reverse LSP Failure"


   defined in this document.


[Lizhong]: the above description is not accurate. What if the egress node have

forward LSP down because of local link down? In that case, it will not receive

PathTear, it is still need to tear down the reverse LSP? It should say, whenever 

the forward LSP is down, the reverse LSP SHOULD be removed. 




Regards

Lizhong