Last Call Review of draft-ietf-teas-rsvp-ingress-protection-11
review-ietf-teas-rsvp-ingress-protection-11-rtgdir-lc-takeda-2017-12-10-00

Request Review of draft-ietf-teas-rsvp-ingress-protection
Requested rev. no specific revision (document currently at 17)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2017-11-30
Requested 2017-11-13
Requested by Deborah Brungard
Authors Huaimo Chen, Raveendra Torvi
Draft last updated 2017-12-10
Completed reviews Rtgdir Last Call review of -11 by Tomonori Takeda (diff)
Secdir Last Call review of -13 by Joseph Salowey (diff)
Genart Last Call review of -13 by Robert Sparks (diff)
Assignment Reviewer Tomonori Takeda
State Completed
Review review-ietf-teas-rsvp-ingress-protection-11-rtgdir-lc-takeda-2017-12-10
Reviewed rev. 11 (document currently at 17)
Review result Has Issues
Review completed: 2017-12-10

Review
review-ietf-teas-rsvp-ingress-protection-11-rtgdir-lc-takeda-2017-12-10

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-rsvp-ingress-protection-11.txt
 Reviewer: Tomonori Takeda
 Review Date: Dec. 8th
 IETF LC End Date: Not known 
 Intended Status: Experimental

Summary:
I have some minor concerns about this document that I think should be resolved before publication.

Comments:
This document describes experimental extensions to RSVP-TE for local protection of the ingress node of a P2MP or P2P LSP. I think this document explains extensions/procedures well, but I think there are a few points which needs more explanation. Especially, since there are multiple modes (such as source-detect/backup-source-detect, relay-message method/proxy-ingress method and on-path/off-path) defined, it is sometimes difficult to track the content.

Major Issues:
None

Minor Issues:

1) "Source Detects Failure" and "Backup and Source Detect Failure"
Sections 2.1 & 2.2 describes "Source Detects Failure" and "Backup and Source Detect Failure".
I am not clear about the difference. For example, even for "Source Detects Failure", it says 

  "For a P2P LSP, after the primary ingress fails, the backup ingress
   MUST use a method to reliably detect the failure of the primary
   ingress before the PATH message for the LSP expires at the next hop
   of the primary ingress."

This means that even for "Source Detects Failure", the backup ingress needs to detect the failure of the primary ingress.
Also, what happens for P2MP LSP? The backup ingress does not need to detect the failure of the primary ingress?

2) "On-path" and "off-path"
Section 3 describes "on-path" and "off-path" as follows.

  "If a backup ingress is not any node of the LSP, we call it is off-path.  If a
   backup ingress is a next-hop of the primary ingress of the LSP, we
   call it is on-path."

What happens if a backup ingress is on the LSP but not the next-hop (say, a second-hop) of the primary ingress of the LSP?

3) INGRESS_PROTECTION object without any Traffic-Descriptor sub-object (empty INGRESS_PROTECTION object)
There are several text for empty INGRESS_PROTECTION object (such as section 5.1.1 and 5.2.1).
I am not clear about use cases for empty INGPRESS_PROTECTION object. Can you elaborate a bit more?
(I am guessing that for parameter changes, such as bandwidth change, regular INGRESS_PROTECTION object will be used.)

4) Router model for "Proxy-Ingress Method"
Section 5.1.2 describes "Proxy-Ingress Method".
Is it a MUST that proxy-ingress resides within the same router as ingress?
If so, I suggest to make it explicit in the document.

5) Ingress behavior for "Relay-Message Method".
Section 5.2.1 describes ingress behavior for "Relay-Message Method".
It says:

  "To protect the primary ingress of an LSP, the primary ingress MUST do
   the following after the LSP is up."

My understanding is that after the LSP is up, a separate PATH message (separate for setting up the primary LSP) is sent from the ingress to the backup ingress.
Is this applicable for off-path as well as on-path? I suggest to make it explicit in the document.

6) Backup ingress behavior for "Relay-Message Method" and "Proxy-Ingress Method".
Sections 5.3.1.1 and 5.3.1.2 describes backup ingress behavior for "Relay-Message Method" and "Proxy-Ingress Method".
As the document says, backup ingress behavior is different for "Relay-Message Method" and "Proxy-Ingress Method". How the backup ingress determines whether it should behave as "Relay-Message Method" or "Proxy-Ingress Method"? Is it inferred from the PATH message or is it configured on the backup ingress or something else?


Nits:
1) In Section 1.1, it says 
"Source S detects the failure of Ia and switches the traffic within 10s of ms."
This document does not specify how Source S detect failures. Therefore, it may not be appropriate to say that Source S can detect and switch the traffic within 10s of ms.