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.