Subject: [Pce] Quick review of draft-chen-pce-sr-ingress-protection-00

From: Dhruv Dhody <[email-masked]>
Date: Mon, 15 Jul 2019 20:56:46 +0530

Hi Authors,

I did a quick review of your I-D, but some key questions came up, it
would be nice if they could be clarified before hand.

(1) It needs to be made clear that why does backup egress needs to
know about the details of the primary SR path at the primary ingress?
Since things are driven by PCE/controller and there is no signalling,
the motivation needs to be different than RFC 8424 for RSVP-TE.  IMHO
the only reason for backup ingress to be aware of these details would
be to detect the failure of the primary ingress itself. And the
benefit offered by that isn't clear.

(2) Once the motivations are cleared up, then we should explore the
use of existing techniques like PCEP-Flowspec [1] instead of defining
new sub-TLVs for traffic description.  I see you have a few new things
like virtual network but not clear how they would be used and why are
tightly coupled for this use-case.

I hope you would focus on these aspects during your presentation.
Discussion on the list would be even better.

Thanks,
Dhruv

[1] https://tools.ietf.org/html/draft-ietf-pce-pcep-flowspec-03

---

From: Huaimo Chen <[email-masked]>
Date: Sun, 21 Jul 2019 03:50:50 +0000

Hi Dhruv,

    Thank you very much for your valuable comments. 
    My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo
-----Original Message-----
From: Dhruv Dhody <[email-masked]> 
Sent: Monday, July 15, 2019 11:27 AM
To: [email-masked]
Cc: [email-masked]
Subject: Quick review of draft-chen-pce-sr-ingress-protection-00

Hi Authors,

I did a quick review of your I-D, but some key questions came up, it would be nice if they could be clarified before hand.

(1) It needs to be made clear that why does backup egress needs to know about the details of the primary SR path at the primary ingress?
Since things are driven by PCE/controller and there is no signalling, the motivation needs to be different than RFC 8424 for RSVP-TE.  IMHO the only reason for backup ingress to be aware of these details would be to detect the failure of the primary ingress itself. And the benefit offered by that isn't clear.

[HC] The information about the primary SR path at the primary ingress is not needed at the backup ingress. We will remove the text related to this from the draft. 
For the backup ingress to detect the failure of the primary ingress, it should know the IP address of the primary ingress node. 
If the primary SR path carries a service which is identified by a service ID or label, then this service ID or label should be sent to the backup ingress node. 
We will update the draft to clarify these.

(2) Once the motivations are cleared up, then we should explore the use of existing techniques like PCEP-Flowspec [1] instead of defining new sub-TLVs for traffic description.  I see you have a few new things like virtual network but not clear how they would be used and why are tightly coupled for this use-case.

[HC] Regarding to using existing Flowspec or new sub-TLVs for traffic description, it seems that there should have some discussions. The latter seems more general and powerful.
For virtual network, we will consider it further.

[HC] We will focus on these in our presentation accordingly.

Thanks,
Dhruv

[1] https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-pce-pcep-flowspec-03&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7C732f5b6ab36d4d187f6b08d70938f2cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636988012506152829&amp;sdata=FnMU0LBRfXa5fI32smojCNrtC3%2BnKn13ofmMb7nnhlU%3D&amp;reserved=0