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

From: Guijuan Wang 3 <[email-masked]>
Date: Thu, 5 Nov 2015 15:29:59 +0000

Dear Authors,

Thanks for drafting this solution, It would be useful if the FRR can be completely independent of refresh. 
I read through it and here is my comment. 

Section 3, page 6, Problem Description:
Per RFC 4090, section 7.2 section Handling Failures, it has required the postpone of sending PathClear, wait another 30s by default. Then the possibility for the first consequence should be lower than the following consequence, better to move it back based on the logic that the major issue comes first. 

Section 4, page 7, Solution Aspects: 
  Read through the whole solution, it requires the supporting of serval other RFCs and also two working-in-progresses RFCs. Better to add “Pre-Requisites” introduction in the beginning of this chapter, then the user for this document know it has to read/implement the prerequisite firstly. 
At the other hand, the major change in the cited [Summary-FRR] and [TE-SCALE-REC] may be monitored and brought back to this document. For example a comment has been raised for the new sub-object definition in [Summary-FRR], it may be changed.
     
Section 4.1.1, page 9, PLR Behavior
Is below paragraph parallel to its former and following paragraphs? If so, please change its format style, that is adding “-“ in the beginning and use same indentations as others. Current style makes me feel it’s the parent of the following 2 paragraphs. 
In this doc, it says:
“In parallel to the attempt made to create NP-bypass or LP-bypass, the PLR SHOULD initiate ...”

Section 4.1.2, page 9, Remote Signaling Adjacency: 
A new hello is introduced, via multiple hops. Better to give the suggested default interval, the hello interval in RFC3209 is 5 ms, it may be too quick for this solution. 

4.1.5. page 11, "Remote" state on MP
Typo, change form to “from” for below sentence.
“the "remote"path state is not signaled explicitly form PLR.”

Section 4.1.1, page 9, first paragraph:
No full words for TED the first time it is mentioned, would you please add it. And would be great if you can give a brief introduction on using the TED to determine routeId.
“If the PLR and the MP are in same area, then the PLR may Utilize the TED to determine the router ID from the interface address in RRO (if NodeID is not included in RRO).”

Section 4.1.1: page 9, paragraph 4:
Whose timeout do you mean by “a timeout” in below paragraph? Also may be better to move the “on the other hand… “ to the paragraph above it. At first glance, the sentence before and after “on the other hand” seems like duplicated.  
In this document, it says: 
"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 subobject in RRO and may immediately trigger PATH downstream."

4.2. page 11, Impact of Failures on LSP State:
In the last paragraph, it says implementation doesn’t need to have a way to distinguish “link-failure” and “node-failure”, but the following statement for handling does distinguish the “link-failure” and “node-failure”, such as LP-MP has different procedures for link and node Failure defined in 4.2.2 and 4.2.3 separately. Is it conflicting? 

Also in the optional way of using node-id based hello to distinguish them, better to give further details on how to distinguish.

4.2. page 11~14, Impact of Failures on LSP State Overall, in this section, several conditions are mentioned and different handling need to be taken based on different conditions combinations, and 7 handling cases are introduced. Is it possible to category them, or simply the combinations based on below 3 considerations?
a.	Distinguishing and understanding 7 cases is a little complex for implementation.
b.	There may be conditions combination that is not enumerated in this document.
c.	Some case handling are very similar such as section 4.2.2 and 4.2.4.

4.5.1, page 19, Detecting Support for Refresh interval Independent FRR Seems the detection mainly counts on the detection procedure for [TE-SCALE-REC] and [SUMMARY-FRR], but this document introduces extra extensions, such as multiple-hop hello, and condition object, there should also a new way to detect the support for them.

Regards
Jean

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 19 Nov 2015 23:29:05 +0800

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; [email-masked]; [email-masked]
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: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Thu, 26 Nov 2015 03:17:38 +0000

Dear authors,
I read this draft and I believe the intent is to provide a tighter control plane synchronization of the PLR and MP roles on a per RSVP session basis such that a LSR will know if it is a MP for a given RSVP session which requested protection. This is done such that the decision to retain or delete the state by the LSR detecting the failure of the link to the previous hop (or the failure of the previous hop itself) is made with the prior knowledge that the LSR is a MP or not on a per RSVP session basis. 

However,  the procedures presented in this document are fairly complex and go at odds with the original intent of making state synchronization based on a soft-state mechanism. In fact, what I fail to find is a compelling argument or data from the field which shows the issue is not resolved via much simpler methods which are used in production networks today. I describe this in the detailed comments below.

Regards,
Mustapha.
---------------------
1. Section 3.1 - Problem Description
"
- If the protected LSP on C times out before D receives signaling
for the backup LSP, then D would receive PathTear from C prior to
receiving signaling for the backup LSP, thus resulting in deleting
the LSP state. This would be possible at scale even with default
refresh time.
"
MA> Since each LSR in the path of a RSVP session which requested protection has to assume it can be a MP without prior knowledge, a simpler method is to reset the refresh timeout for each session as soon as the link to the previous hop failed. In fact, a user configurable MP timeout upon failure, independent of the refresh timeout, can be provided to tune it to the desired value to give enough time to the Path message to be received via the bypass LSP.

2. Section 3.1 - Problem Description:
"
- If upon the link failure C is to keep state until its timeout,
then with long refresh interval this may result in a large amount
of stale state on C. Alternatively, if upon the link failure C is
to delete the state and send PathTear to D, this would result in
deleting the state on D, thus deleting the LSP. D needs a reliable
mechanism to determine whether it is MP or not to overcome this
problem.
" 
MA> What is exactly the issue with state timeout being retained until the refresh timeout? You refer to this as "stale" state but in fact it is desirable to keep the state until node D created the backup PSB. Also, remember that head-end node will perform global revertive MBB and may tear down the LSP before the state timeout.

3. Section 3.1 - Problem Statement:
"
- If head-end A attempts to tear down LSP after step 1 but before
step 2 of the above sequence, then B may receive the tear down
message before step 2 and delete the LSP state from its state
database. If B deletes its state without informing D, with long
refresh interval this could cause (large) buildup of stale state
on D.
"
MA> I am not sure I understand the issue here. If B acting as a PLR receives a PathTear from A, all it needs to do is to check that the primary path neighbor (C in this case) is in down or in cleanup state and send the PathTear over the bypass before deleting its own local state. 
Note here a key assumption is that PLR node B must send triggered Path refresh messages to the MP over the bypass. If node B has to wait to the next refresh interval to send the Path refresh over the bypass, then you can run into the issue described here. 

4. Section 3.1 - Problem Statement:
"
- If B fails to perform local repair in step 1, then B will delete
the LSP state from its state database without informing D. As B
deletes its state without informing D, with long refresh interval
this could cause (large) buildup of stale state on D.
"
MA> Well this is the normal RSVP soft-state behavior and in fact this behavior can occur for defects of link B-C which are not detected and which will not trigger the activation of the bypass LSP. There is nothing abnormal about this and this behavior is not specific to the case when the bypass could not be activated.

5. Section 4.5.2 - Procedures for backward compatibility:
MA> What is the need to set the refresh interval to the default value when a LSR detects that a downstream or upstream neighbour does not support the refresh independent procedures? I assume you meant to change it back to the configured value which may not be the default value of 30 seconds.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 26 Nov 2015 13:53:14 +0800

Mustapha,

Is this a recommendation not to adopt the document as a working group
document?

/Loa

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Thu, 26 Nov 2015 16:16:23 +0000

Hi Loa,
This would be my recommendation but of course I appreciate the feedback from the authors to make sure we can come to a determination that it is worth adding additional procedures to an already complex protocol. 

I have not spent time reviewing the details of the solution (except for my last comments on Section 4.5.2) and that would be next if we can justify the need for additional procedures.

Mustapha.

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Thursday, November 26, 2015 12:53 AM
> To: Aissaoui, Mustapha (Mustapha); Sriganesh Kini; Lucy yong
> Cc: Lizhong Jin; Guijuan Wang 3; [email-masked]; mpls-
> [email-masked]; [email-masked]
> Subject: Re: MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr
> 
> Mustapha,
> 
> > I read this draft and I believe the intent is to provide a tighter control plane
> synchronization of the PLR and MP roles on a per RSVP session basis such that a
> LSR will know if it is a MP for a given RSVP session which requested protection.
> This is done such that the decision to retain or delete the state by the LSR
> detecting the failure of the link to the previous hop (or the failure of the previous
> hop itself) is made with the prior knowledge that the LSR is a MP or not on a per
> RSVP session basis.
> >
> > However,  the procedures presented in this document are fairly complex and go
> at odds with the original intent of making state synchronization based on a soft-
> state mechanism. In fact, what I fail to find is a compelling argument or data from
> the field which shows the issue is not resolved via much simpler methods which
> are used in production networks today. I describe this in the detailed comments
> below.
> >
> > Regards,
> > Mustapha.
> > ---------------------
> > - If the protected LSP on C times out before D receives signaling for
> > the backup LSP, then D would receive PathTear from C prior to
> > receiving signaling for the backup LSP, thus resulting in deleting the
> > LSP state. This would be possible at scale even with default refresh
> > time.
> > "
> > MA> Since each LSR in the path of a RSVP session which requested protection
> has to assume it can be a MP without prior knowledge, a simpler method is to
> reset the refresh timeout for each session as soon as the link to the previous hop
> failed. In fact, a user configurable MP timeout upon failure, independent of the
> refresh timeout, can be provided to tune it to the desired value to give enough time
> to the Path message to be received via the bypass LSP.
> >
> > - If upon the link failure C is to keep state until its timeout, then
> > with long refresh interval this may result in a large amount of stale
> > state on C. Alternatively, if upon the link failure C is to delete the
> > state and send PathTear to D, this would result in deleting the state
> > on D, thus deleting the LSP. D needs a reliable mechanism to determine
> > whether it is MP or not to overcome this problem.
> > "
> > MA> What is exactly the issue with state timeout being retained until the refresh
> timeout? You refer to this as "stale" state but in fact it is desirable to keep the
> state until node D created the backup PSB. Also, remember that head-end node
> will perform global revertive MBB and may tear down the LSP before the state
> timeout.
> >
> > - If head-end A attempts to tear down LSP after step 1 but before step
> > 2 of the above sequence, then B may receive the tear down message
> > before step 2 and delete the LSP state from its state database. If B
> > deletes its state without informing D, with long refresh interval this
> > could cause (large) buildup of stale state on D.
> > "
> > MA> I am not sure I understand the issue here. If B acting as a PLR receives a
> PathTear from A, all it needs to do is to check that the primary path neighbor (C in
> this case) is in down or in cleanup state and send the PathTear over the bypass
> before deleting its own local state.
> > Note here a key assumption is that PLR node B must send triggered Path refresh
> messages to the MP over the bypass. If node B has to wait to the next refresh
> interval to send the Path refresh over the bypass, then you can run into the issue
> described here.
> >
> > - If B fails to perform local repair in step 1, then B will delete the
> > LSP state from its state database without informing D. As B deletes
> > its state without informing D, with long refresh interval this could
> > cause (large) buildup of stale state on D.
> > "
> > MA> Well this is the normal RSVP soft-state behavior and in fact this behavior
> can occur for defects of link B-C which are not detected and which will not trigger
> the activation of the bypass LSP. There is nothing abnormal about this and this
> behavior is not specific to the case when the bypass could not be activated.
> >
> > MA> What is the need to set the refresh interval to the default value when a LSR
> detects that a downstream or upstream neighbour does not support the refresh
> independent procedures? I assume you meant to change it back to the configured
> value which may not be the default value of 30 seconds.
> >

---

From: Chandrasekar Ramachandran <[email-masked]>
Date: Sun, 29 Nov 2015 13:19:22 +0000

Hello Jean,
Thanks for your comments. Please find the responses inline.

> From: Guijuan Wang 3 [mailto:[email-masked]]
> Sent: Thursday, November 05, 2015 9:00 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; Loa Andersson <[email-masked]>
> Subject: RE: MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr
> 
> Dear Authors,
> 
> Per RFC 4090, section 7.2 section Handling Failures, it has required the
> postpone of sending PathClear, wait another 30s by default. Then the
> possibility for the first consequence should be lower than the following
> consequence, better to move it back based on the logic that the major issue
> comes first.

[Chandra] Yes, we will clarify that the references to "router C timing out LSP states" in Section 3 to indicate that as per RFC 4090 the state time out on C would occur after an additional time out cycle.
 
>   Read through the whole solution, it requires the supporting of serval other
> RFCs and also two working-in-progresses RFCs. Better to add “Pre-
> Requisites” introduction in the beginning of this chapter, then the user for
> this document know it has to read/implement the prerequisite firstly.
> At the other hand, the major change in the cited [Summary-FRR] and [TE-
> SCALE-REC] may be monitored and brought back to this document. For
> example a comment has been raised for the new sub-object definition in
> [Summary-FRR], it may be changed.

[Chandra] Yes, we will introduce a new section or sub-section to clarify the pre-requisites. It is true that the bypass association procedure in Summary-FRR draft will be re-specified to use Association object. As the update to that draft has not yet been uploaded, we have not yet modified our draft.

> Is below paragraph parallel to its former and following paragraphs? If so,
> please change its format style, that is adding “-“ in the beginning and use
> same indentations as others. Current style makes me feel it’s the parent of
> the following 2 paragraphs.
> In this doc, it says:

[Chandra] Yes, we will indent the paragraphs "While selecting the destination address ..." because that paragraph is a specific recommendation for selecting destination address.

> A new hello is introduced, via multiple hops. Better to give the suggested
> default interval, the hello interval in RFC3209 is 5 ms, it may be too quick for
> this solution.

[Chandra] Yes, you are correct that the default hello interval specified in RFC 3209 is not suitable for NodeID hello session. The TE-SCALE-REC draft (https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-scaling-rec-00) makes the recommendation of 9 seconds for the hello interval. However, we will also explicitly state in Section 4.1.2 of our draft to follow the recommendation of TE-SCALE-REC draft. 

> “the "remote"path state is not signaled explicitly form PLR.”

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

> No full words for TED the first time it is mentioned, would you please add it.
> And would be great if you can give a brief introduction on using the TED to
> determine routeId.
> “If the PLR and the MP are in same area, then the PLR may Utilize the TED to
> determine the router ID from the interface address in RRO (if NodeID is not
> included in RRO).”

[Chandra] Yes, we will provide some additional text in Section 4.1.1 for this. We will also include TED in Terminology section.

> Whose timeout do you mean by “a timeout” in below paragraph? Also may
> be better to move the “on the other hand… “ to the paragraph above it. At
> first glance, the sentence before and after “on the other hand” seems like
> duplicated.
> "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 subobject in RRO and may
> immediately trigger PATH downstream."

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

> In the last paragraph, it says implementation doesn’t need to have a way to
> distinguish “link-failure” and “node-failure”, but the following statement for
> handling does distinguish the “link-failure” and “node-failure”, such as LP-MP
> has different procedures for link and node Failure defined in 4.2.2 and 4.2.3
> separately. Is it conflicting?

[Chandra] Thanks for pointing out the conflict. The TE-SCALE-REC draft does recommend the use of NodeID based hello session and hence the paragraph "It should be noted that even though this section and the subsequent ..." is in conflict with that recommendation. We will remove this paragraph.

> Also in the optional way of using node-id based hello to distinguish them,
> better to give further details on how to distinguish.

[Chandra] Please refer to my response to your previous comment. We will remove the paragraph and possibly refer to TE-SCALE-REC to clarify regarding failure detection. 

> 4.2. page 11~14, Impact of Failures on LSP State Overall, in this section,
> several conditions are mentioned and different handling need to be taken
> based on different conditions combinations, and 7 handling cases are
> introduced. Is it possible to category them, or simply the combinations based
> on below 3 considerations?

[Chandra] We will classify the 7 sub-sections into 3 categories - LP-MP behavior, NP-MP behavior and Router that is simultaneously LP-MP and NP-MP. Each category will contain the procedures to handle different types of failures, so that it would be clear that all possible combinations are enumerated. The behavior of non-MP should be obvious and does not require the explicit specification.

> 4.5.1, page 19, Detecting Support for Refresh interval Independent FRR
> Seems the detection mainly counts on the detection procedure for [TE-
> SCALE-REC] and [SUMMARY-FRR], but this document introduces extra
> extensions, such as multiple-hop hello, and condition object, there should
> also a new way to detect the support for them.

[Chandra] Section 2.2 of TE-SCALE-REC contains the following recommendation.

    - (If Bypass FRR [RFC4090] is supported,) MUST implement procedures
      specified in [RI-RSVP-FRR] which describes methods to facilitate
      FRR that works independently of the refresh-interval.

Hence the definition of I-bit in Section 2.2.1 of TE-SCALE-REC should include the support for the procedures in RI-RSVP-FRR draft. It should be noted that TE-SCALE-REC has specified a separate flag F-bit to enable implementations to support per-peer flow control without supporting Refresh-independent RSVP.

We will explicitly add the above clarification in Section 4.5.1.

Thanks,
Chandra.

---

From: Chandrasekar Ramachandran <[email-masked]>
Date: Sun, 29 Nov 2015 16:42:14 +0000

Hi Lizhong,
Please refer inline for responses.

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

Hi All

Abstract

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

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

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

Section 4.1.5.

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

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

Section 4.1.5.

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

Section 4.1.5.

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

Section 4.3.3.
M bit

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

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

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

[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:[email-masked]>
Date: 2015-10-22 20:18
To: Sriganesh Kini<mailto:[email-masked]>; Lizhong Jin<mailto:[email-masked]>; Aissaoui, Mustapha (Mustapha)<mailto:[email-masked]>; Lucy yong<mailto:[email-masked]>; Guijuan Wang 3<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr
Sri, Lizhong, Mustapha, Lucy, and Guijuan Wang,

Thanks, Loa
(as MPLS WG chair)

--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 30 Nov 2015 23:07:07 +0800

Hi Chandra,
I am OK with all you replies. Thanks.

Regards
Lizhong
 
From: Chandrasekar Ramachandran
Date: 2015-11-30 00:42
To: [email-masked]; loa; sriganesh.kini; mustapha.aissaoui; lucy.yong; guijuan.wang; draft-chandra-mpls-ri-rsvp-frr; mpls-chairs
CC: mpls
Subject: RE: MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr
Hi Lizhong,
Please refer inline for responses.

Hi All 

Abstract 

Section 4.1.1. 

Section 4.1.5. 

Section 4.1.5. 

Section 4.1.5. 

Section 4.1.5. 

Section 4.1.5. 

Section 4.3.3.
M bit 

M-bit

Section 4.4. 

 

 
Thanks,
Chandra.

Regards
Lizhong
 
From: Loa Andersson
Date: 2015-10-22 20:18

 

 

Thanks, Loa
(as MPLS WG chair)

--