Subject: [Teas] RtgDir review: draft-ietf-teas-rsvp-ingress-protection-11.txt

From: Tomonori Takeda <[email-masked]>
Date: Fri, 8 Dec 2017 16:17:51 +0000

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.

---

From: Huaimo Chen <[email-masked]>
Date: Sat, 16 Dec 2017 17:04:56 +0000

Hi Tomonori,

Thank you very much for your time.
The document has been updated accordingly.

Best Regards,
Huaimo
From: Tomonori Takeda [mailto:[email-masked]]
Sent: Wednesday, December 13, 2017 4:16 AM
To: Huaimo Chen <[email-masked]>
Cc: [email-masked]; Tomonori Takeda <[email-masked]>
Subject: RE: RtgDir review: draft-ietf-teas-rsvp-ingress-protection-11.txt

Hi Huaimo,

Thanks. Your suggestion looks good to me.

Tomonori

From: Huaimo Chen [mailto:[email-masked]]
Sent: Tuesday, December 12, 2017 6:48 AM
To: Tomonori Takeda（武田知典）
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: RtgDir review: draft-ietf-teas-rsvp-ingress-protection-11.txt

Hello Tomonori,

    Thank you very much for your valuable comments, which will help improve the quality of the document a lot.
    The followings (prefixed with [HC]) are the answers to them. Would you mind checking whether they address all your comments?

Best Regards,
Huaimo
-----Original Message-----
From: Tomonori Takeda [mailto:[email-masked]]
Sent: Friday, December 08, 2017 11:18 AM
To: [email-masked]' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]' <[email-masked]<mailto:[email-masked]>>; [email-masked]' <[email-masked]<mailto:[email-masked]>>; [email-masked]' <[email-masked]<mailto:[email-masked]>>
Subject: RtgDir review: draft-ietf-teas-rsvp-ingress-protection-11.txt

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

Summary:

Comments:

[HC] We will add more explanation according to your comments.

Major Issues:
None

Minor Issues:

[HC] For a P2MP LSP, the backup ingress also needs to detect the failure of the primary ingress. We will revise the paragraph quoted above to include both P2P LSP and P2MP LSP. "For a P2P LSP" in the paragraph will be changed to "For an LSP".

"Source Detects Failure" means that the source is responsible for fast detecting the failure of the primary ingress of an LSP. "Backup and Source Detect Failure" means that both the backup ingress and the source are concurrently responsible for fast detecting the failure of the primary ingress. That is that they detect the failure of the primary ingress fast. For example, they may use BFD to detect the failure in 10s of ms.

For "Source Detects Failure", even though the backup ingress must detect the failure of the primary ingress, it may detect the failure slowly such as in (10s of) seconds. We will add "The method may detect the failure of the primary ingress slowly such as in seconds." After the paragraph quoted above.

[HC] When configuring or computing a backup ingress for protecting the primary ingress of an LSP, the backup ingress MUST not be on the LSP except for it is the next hop of the primary ingress. We will add some text in the document accordingly.

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

[HC] We will add more details into the document accordingly. The empty INGRESS_PROTECTION object is for efficient process of ingress protection for a P2MP LSP. For a P2MP LSP, its primary ingress may have more than one PATH messages, each of which is sent to a next hop along a branch of the P2MP LSP. The PATH message along a branch will be selected and sent to the backup ingress with an INGRESS_PROTECTION object containing the Traffic-Descriptor sub-object; all the PATH messages along the other branches will be sent to the backup ingress containing an INGRESS_PROTECTION object without any Traffic-Descriptor sub-object (empty INGRESS_PROTECTION object). For a P2MP LSP, the backup ingress only needs one Traffic-Descriptor.

[HC] Yes. The proxy-ingress MUST reside within the same router as ingress. We will make it explicit in the document accordingly.

[HC] Your understanding is right. This is applicable for off-path. For on-path, we just add an INGRESS_PROTECTION object into the existing PATH message to the backup ingress (i.e., the next hop). We do not send a separate PATH message to the backup ingress (i.e., next hop) for on-path case. We will add more details accordingly.

[HC] It is through configurations. We will add some text about it accordingly.

Nits:

[HC] We will remove this sentence.