Skip to main content

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 revision 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
I-D 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 A. Salowey (diff)
Genart Last Call review of -13 by Robert Sparks (diff)
Assignment Reviewer Tomonori Takeda
State Completed
Request Last Call review on draft-ietf-teas-rsvp-ingress-protection by Routing Area Directorate Assigned
Reviewed revision 11 (document currently at 17)
Result Has issues
Completed 2017-12-10
review-ietf-teas-rsvp-ingress-protection-11-rtgdir-lc-takeda-2017-12-10-00
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.