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

[Chandrasekar Ramachandran <[e-mail]>]

Hi Lizhong,
Please refer inline for responses.

From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, November 19, 2015 8:59 PM
To: loa <[e-mail]>; sriganesh.kini <[e-mail]>; mustapha.aissaoui <[e-mail]>; lucy.yong <[e-mail]>; guijuan.wang <[e-mail]>; draft-chandra-mpls-ri-rsvp-frr <[e-mail]>; mpls-chairs <[e-mail]>
Cc: mpls <[e-mail]>
Subject: Re: MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr

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?

[Chandra] Will the following text replacing the second paragraph in Abstract be sufficient?

“In order to eliminate the reliance on refresh timeouts in RSVP, the routers should unambiguously determine when a particular LSP state should be deleted. Coupling the states corresponding to a particular LSP with the corresponding RSVP-TE signaling adjacencies will help in scenarios other than FRR using bypass tunnels. However, in scenarios involving FRR using bypass tunnels, additional tear down messages will be required. Refresh-interval independent RSVP FRR (RI-RSVP-FRR) consists of procedures defined in this document to enable LSP state clean up required in scenarios not covered by procedures defined in [TE-SCALE-REC].”

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.

[Chandra] We have received similar comment from Guijuan. As the procedures for inclusion of new sub-object for bypass association will be spelt out in SUMMARY-FRR draft, we will remove this paragraph to avoid confusion. The following paragraph was my response to Guijuan on the same sub-section.

From mail sent to Guijuan:
[Chandra] Actually, the time out indicated here is not related to state time out. But I agree that this paragraph is a bit confusing. As the procedures are expected to be specified in SUMMARY-FRR draft, we will remove the last paragraph (the one starting with "After signaling protection availability ...") and combine the previous two paragraphs. That is, we will merge the two paragraphs "In parallel to the attempt made ..." and "If the bypass LSP comes up, then the PLR should include ...".

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?

[Chandra] Yes, we will replace references to HOP with RSVP_HOP.

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."

[Chandra] Will the following modified sentence be better?
“The RSVP_HOP object in “remote” Path state contains the address that the PLR uses to send NodeID hello messages to MP”.

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

[Chandra] Yes, we will make it explicit in this point.

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".

[Chandra] Yes, will correct in the typo in next revision.

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?

[Chandra] TTL value should be set to 255. We will make it explicit in the draft.

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".

[Chandra] We will replace the existing M-bit specification with the following text.

M-bit
If M-bit is set to 1, then the PathTear message should be processed based on the condition whether the receiving router is Merge Point or not.
If M-bit is set to 0, then the PathTear message should be processed as normal PathTear message.

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.

[Chandra] The state of LSP being locally repaired is a pre-condition before step 3. However, it is quite possible that the PLR (router B) may have started local repair of the LSP even before step 1. But  it is conceivable that backup LSP signaling for a particular LSP to be delayed owing to LSP scale (or other dimensions of scale) and the Ingress receives management event during this period. That is why, one cannot explicitly state when the local repair actions are initiated.

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.

[Chandra] In the specific case you describe, the state cleanup on router C may occur through two different ways. One way is through route D sending ResvTear to C. That is, when router D receives “remote” PathTear from router B, router D will propagate PathTear downstream (if there is any downstream router along the LSP) and will send ResvTear upstream to router C. The other way is router A sending “remote” PathTear to C when router A find that router C is no longer its NP-MP. We will make state this explicitly in this section.

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

[Chandra] The gmpls-lsp-fastreroute draft is not specific to packet LSPs, while ri-rsvp-frr is specific to packet LSPs implementing facility bypass FRR defined in RFC 4090 (and that is why this draft is in mpls wg rather than teas wg). However, we will go through gmpls-lsp-fastroute more closely to consider how the ri-rsvp-frr procedures impact the gmpls draft.

Thanks,
Chandra.

________________________________
Regards
Lizhong

From: Loa Andersson<mailto:[e-mail]>
Date: 2015-10-22 20:18
To: Sriganesh Kini<mailto:[e-mail]>; Lizhong Jin<mailto:[e-mail]>; Aissaoui, Mustapha (Mustapha)<mailto:[e-mail]>; Lucy yong<mailto:[e-mail]>; Guijuan Wang 3<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>
Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>
Huawei Technologies (consultant)     phone: [phone]