Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

[Huaimo Chen <[e-mail]>]

Hi Greg,

Thanks for your comments!
My answers/explanations are inline below.

Best Regards,
Huaimo
From: Gregory Mirsky [mailto:[e-mail]]
Sent: Tuesday, February 18, 2014 2:23 AM
To: Huaimo Chen; Ross Callon; [e-mail]
Cc: [e-mail]
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Hi Huaimo,
the proposal in question does not and, what I really consider the problem, cannot go  beyond absolutely same continuity monitoring as for RFC 4090. You change interpretation of LoC between R3 and L1 and call it "egress failure" even though it could be just link failure.

[Huaimo] Can you elaborate more on your question?

And to add to my concern is the fact that the proposal does not protect L1-CE link. But egress and the access link can be protected at the service layer if the protection domain set between CE nodes. That will provide true egress protection.

[Huaimo] The protection of the link between egress L1 and CE1 seems not require any RSVP-TE extensions. It should be out scope of the draft.

Because of these considerations I believe that the proposed approach is limited, not practical and offers solution to a problem that already been solved.

[Huaimo] Regarding to your statement "a problem that already been solved.", can you give more details about the existing solution in your mind?


                Regards,
                                Greg

From: Huaimo Chen [mailto:[e-mail]]
Sent: Monday, February 17, 2014 2:09 PM
To: Gregory Mirsky; Ross Callon; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Hi Greg,

Can you give more details about your question?
It seems that the FRR defined in RFC 4090 does not have a requirement that there MUST be a clearly distinguishable detection of a transit node failure for people to use it for protecting the transit node failure.  Egress protection just follows this.

Best Regards,
Huaimo
From: Gregory Mirsky [mailto:[e-mail]]
Sent: Monday, February 17, 2014 4:34 PM
To: Huaimo Chen; Ross Callon; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Hi Huaimo,
without clearly distinguishable detection of Egress Failure error FRR and proposed mechanics are mutually exclusive at PLR (R3 in Fig.1). Hence, I think that there's a question of which protection mechanism takes precedence when both been signaled.

                Regards,
                                Greg

From: Huaimo Chen [mailto:[e-mail]]
Sent: Monday, February 17, 2014 8:04 AM
To: Gregory Mirsky; Ross Callon; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Hi Greg,

    The egress protection draft follows most of the behaviors defined in RFC 4090. Regarding to using  link protection and/or node protection on the upstream node of an egress as PLR, it follows that defined in RFC 4090.

Best Regards,
Huaimo
From: Gregory Mirsky [mailto:[e-mail]]
Sent: Friday, February 14, 2014 12:42 PM
To: Huaimo Chen; Ross Callon; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Hi Huaimo,
AFAIK, you can use either link or node protection, not both at the same PLR. If you believe otherwise, please illustrate with RSVP signaling scenario.

                Regards,
                                Greg

From: Huaimo Chen [mailto:[e-mail]]
Sent: Friday, February 14, 2014 9:16 AM
To: Gregory Mirsky; Ross Callon; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Hi Greg,

    For a transit node of an LSP and the link between the transit node and the upstream node of the transit node, can we use both the link protection define in RFC 4090 for protecting the link and the node protection defined in RFC 4090 for protecting the transit node? If so, will this kind of deployment lead to unpredictable results?

Best Regards,
Huaimo
From: Gregory Mirsky [mailto:[e-mail]]
Sent: Friday, February 14, 2014 12:04 PM
To: Huaimo Chen; Ross Callon; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Hi Huaimo,
thank you for references to the document. I'd point that without demonstrating that node R3 can differentiate link [R3,L1] failure from failure of egress node L1 use of both FRR and egress protection may lead to unpredictable results among which unnecessary use of egress protection vs. FRR might be the least of problem. Scope of a protection domain is determined by end points of continuity monitoring OAM. One is obvious - R3. If you place another one at L1, then it is no different from FRR scenario that protects [R3-L1] and failure of link [L1-CE] is not being monitored, thus it is unprotected by the proposed mechanism. If the second CC OAM end point place at CE to monitor link [L1-CE] as well, then, IMHO, there are clear security concerns.
Again, I believe that this problem being already solved at client layer and server layer has to do nothing.

                Regards,
                                Greg

From: Huaimo Chen [mailto:[e-mail]]
Sent: Friday, February 14, 2014 8:46 AM
To: Gregory Mirsky; Ross Callon; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Hi Greg,

In section 1.2 "Egress Local Protection with FRR" of the draft, we state "The egress nodes of the LSP can be locally protected via the egress  local protection.  All the links and the intermediate nodes of the LSP can be locally protected through using the FRR."  The link between the egress node and the upstream node of the egress is one of all the links of the LSP. Its failure can be protected by the link protection.

In section 5.2.1 of the draft, we state "When the PLR detects the failure of the primary egress, it MUST switch the packets from the primary LSP to the backup LSP to the backup egress. ... ". Here the PLR is the upstream node of the primary egress.

In section 5.2.2 of the draft, we state "When the PLR detects the failure of the primary egress, it redirects the packets from the primary LSP into the backup LSP to backup egress ...". Here the PLR is the upstream node of the primary egress.

    It seems that the draft does not make any suggestion as you mentioned.

Best Regards,
Huaimo
From: Gregory Mirsky [mailto:[e-mail]]
Sent: Thursday, February 13, 2014 6:32 PM
To: Huaimo Chen; Ross Callon; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Hi Huaimo,
since the RFC 4090 is local protection the scope of fault detection mechanism is link OAM. There are two interpretations of link failure that are supported by two modes:

*         link protection

*         node protection
Are you suggesting that interpretation of a failure of immediate link as egress node failure is efficient and preferable to Service OAM?

                Regards,
                                Greg

From: Huaimo Chen [mailto:[e-mail]]
Sent: Thursday, February 13, 2014 1:59 PM
To: Gregory Mirsky; Ross Callon; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Hi Greg,

    FRR defined in RFC 4090 has been used for transit node protection. Do you know any method that is used by FRR and can tell/distinguish different failures reliably?

Best Regards,
Huaimo
From: Gregory Mirsky [mailto:[e-mail]]
Sent: Thursday, February 13, 2014 4:49 PM
To: Huaimo Chen; Ross Callon; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Hi Huaimo,
I believe that any protection mechanism is based on assumption that fault it protects from can be detected. Otherwise, when the protection mechanism will be triggered? If there's no proof that particular failure can be distinguished for other failure scenarios, then I don't find enough justification for additional complexity of protection scheme. Especially when the problem can be solved by other technical means.

                Regards,
                                Greg

From: Huaimo Chen [mailto:[e-mail]]
Sent: Thursday, February 13, 2014 1:39 PM
To: Gregory Mirsky; Ross Callon; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Hi Greg,

It seems that your reason "The draft lacks to demonstrate that claimed goal, egress LSR failure, can be reliably detected." for do not support is not persuasive.

In our draft, there is not any claimed goal, egress LSR failure, can be reliably detected.

We have FRR defined in RFC 4090, which can be used for transit node protection. MUST we  have/describe a method (in RFC 4090) that can reliably detect the transit LSR failure?

Basically, the objective of egress protection is to make sure that the data traffic flows to its destination in the case that the egress fails. It is nice to have a method to detect the egress failure and clearly identify the failure as egress failure. It seems that it is not a MUST for us to have this kind of method. As long as the data traffic flows to its destination through the use of egress protection when the egress fails or some related failures occur, it should be OK.

Best regards,
Huaimo
From: mpls [mailto:[e-mail]] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 4:11 PM
To: Ross Callon; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

do not support

The draft lacks to demonstrate that claimed goal, egress LSR failure, can be reliably detected. Thus benefits of local protection for server layer LSP vs. client layer protection (Service OAM) are questionable, at best. Without that this is exercise in extending RSVP-TE.

                Regards,
                                Greg

From: mpls [mailto:[e-mail]] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

This is to start a poll on adopting draft-chen-mpls-p2mp-egress-protection-11
as an MPLS working group document. Since many of us will be in transit to the
IETF approximately two weeks from now, I will extent the poll by one week (so
that it will be a three week poll).

Please send your comments (support/not support) to the mpls working group
mailing list ([e-mail]<mailto:[e-mail]>).

This poll will end Friday March 7, 2014. Note that this is the Friday of the IETF,
and thus we will each need to plan our review of the document and response
around our travel plans and IETF activities.

Thanks, Ross