Re: [mpls] MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr

["[e-mail]" <[e-mail]>]

Hi All 
I reviewed review of draft-chandra-mpls-ri-rsvp-frr as the member of MPLS 
Review Team. I think the document resolves a real problem in FRR, and it is 
useful and technically sound. At the same time, I have several questions, and
would appreciate to resolve them before WG adoption. 

Abstract 
[Lizhong] When I finish reading Abstract, I hope to know what is the 
refresh-interval independent FRR. Could you add the key point of the 
solution in the Abstract section? 

Section 4.1.1. 
- After signaling protection availability, if the PLR finds that 
the protection becomes unavailable then it SHOULD attempt to make 
protection available. The PLR SHOULD wait for a time out before 
removing SUMMARY_FRR_BYPASS_ASSIGNMENT sub-object in RRO and 
triggering PATH downstream. On the other hand, the PLR need not 
wait for a time out to add SUMMARY_FRR_BYPASS_ASSIGNMENT sub- 
object in RRO and may immediately trigger PATH downstream. 
[Lizhong] what is "On the other hand" referring here? A bit confused. 

Section 4.1.5. 
The "remote" state is identical to the protected LSP path 
state except for the difference in HOP object. The HOP object 
[Lizhong] HOP is RSVP_HOP, right? If true, could you use RSVP_HOP as 
defined in RFC2205? 

Section 4.1.5. 
corresponding to the "remote" path state contains the address of 
remote node signaling adjacency with PLR. 
[Lizhong] a bit confused the above description. The HOP object contains 
the address of PLR, right? Then it seems it should be described as: 
"corresponding to the "remote" path state contains the address of 
remote node signaling adjacency with MP." 

Section 4.1.5. 
- MP receives PathTear, or 
[Lizhong] here, PathTear refers to normal or "Remote" PathTear, right? 

Section 4.1.5. 
Unlike the normal path state that is either locally generated on 
Ingress or created from PATH message from Phop node, the "remote" 
path state is not signaled explicitly form PLR. 
[Lizhong] typo, "form" should be "from". 

Section 4.1.5. 
Such message tearing down 
"remote" path state is called "Remote PathTear. 
[Lizhong] What's the TTL value of "Remote" PathTear message? 

Section 4.3.3.
M bit 
This bit indicates that the message SHOULD be processed based on the 
condition whether the receiving node is Merge Point or not. 
[Lizhong] should define the value of M bit. What's the meaning of "1" or "0". 

Section 4.4. 
If the Ingress wants to tear down the LSP because of a management 
event while the LSP is being locally repaired at a transit PLR, it 
would not be desirable to wait till backup LSP signaling to perform 
state cleanup. 
[Lizhong] The state "being locally repaired" refers to the state after 
step 1, before step 2 in section 3, right? Hope to describe explicitly. 

Section 4.4.1. PLR Behavior on Local Repair Failure 
[Lizhong] Consider the case in figure 1, if link between B and C fail, 
then B will send "remote" PathTear to D, and then D will send pathTear 
downstream. But How to clear the state on node C? We need some way to 
let A to send "remote" PathTear to C. 

The last one is, will you consider the impact to bidirectional LSP FRR described 
in draft-ietf-teas-gmpls-lsp-fastreroute-03?



Regards
Lizhong
 
From: Loa Andersson
Date: 2015-10-22 20:18
To: Sriganesh Kini; Lizhong Jin; Aissaoui, Mustapha (Mustapha); Lucy yong; Guijuan Wang 3; [e-mail]; [e-mail]
Subject: MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr
Sri, Lizhong, Mustapha, Lucy, and Guijuan Wang,
 
You have be selected as MPLS-RT reviewers for 
draft-chandra-mpls-ri-rsvp-frr-02.
 
Note to authors: You have been CC'd on this email so that you can know
that this review is going on. However, please do not review your own
document.
 
Reviews should comment on whether the document is coherent, is it
useful (ie, is it likely to be actually useful in operational networks), 
and is the document technically sound?
 
We are interested in knowing whether the document is ready to be
considered for WG adoption (ie, it doesn't have to be perfect at this
point, but should be a good start).
 
Reviews should be sent to the document authors, WG co-chairs and WG
secretary, and CC'd to the MPLS WG email list. If necessary, comments
may be sent privately to only the WG chairs.
 
If you have technical comments you should try to be explicit about what
needs to be resolved before adopting it as a working group document, and
what can wait until the document is a working group document and the
working group has the revision control.
 
Are you able to review this draft by November 12, 2015? Please respond
in a timely fashion.
 
Thanks, Loa
(as MPLS WG chair)
 
 
 
-- 
 
 
Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]