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

From: Ross Callon <[email-masked]>
Date: Thu, 13 Feb 2014 19:46:26 +0000

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 ([email-masked]<mailto:[email-masked]>).

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

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 13 Feb 2014 19:58:40 +0000

Support!
(as an author)

Best Regards,
Huaimo

From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 2:46 PM
To: [email-masked]
Cc: [email-masked]
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Thanks, Ross

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 13 Feb 2014 16:00:32 -0500

Ross,

This draft is already pretty well baked, with 12 revisions, lots of
discussion, and an RT review already. It's also very useful
functionality. It's long overdue for becoming a WG draft.

Cheers,
Andy

On Thu, Feb 13, 2014 at 2:46 PM, Ross Callon <[email-masked]> wrote:
> This is to start a poll on adopting
> draft-chen-mpls-p2mp-egress-protection-11
>
> mailing list ([email-masked]).
>
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 13 Feb 2014 21:10:45 +0000

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:[email-masked]] On Behalf Of Ross Callon
Sent: Thursday, February 13, 2014 11:46 AM
To: [email-masked]
Cc: [email-masked]
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Thanks, Ross

---

From: Katherine Zhao <[email-masked]>
Date: Thu, 13 Feb 2014 21:38:13 +0000

Support.

Regards,
Katherine

Thanks, Ross

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 13 Feb 2014 21:38:49 +0000

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:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Thursday, February 13, 2014 4:11 PM
To: Ross Callon; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

do not support

                Regards,
                                Greg

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

Thanks, Ross

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 13 Feb 2014 21:48:30 +0000

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:[email-masked]]
Sent: Thursday, February 13, 2014 1:39 PM
To: Gregory Mirsky; Ross Callon; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Hi Greg,

Best regards,
Huaimo
To: Ross Callon; [email-masked]<mailto:[email-masked]>

do not support

                Regards,
                                Greg

Thanks, Ross

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 13 Feb 2014 21:59:28 +0000

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:[email-masked]]
Sent: Thursday, February 13, 2014 4:49 PM
To: Huaimo Chen; Ross Callon; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Hi Huaimo,

                Regards,
                                Greg

To: Gregory Mirsky; Ross Callon; [email-masked]<mailto:[email-masked]>

Hi Greg,

Best regards,
Huaimo

do not support

                Regards,
                                Greg

Thanks, Ross

---

From: Richard Li <[email-masked]>
Date: Thu, 13 Feb 2014 22:09:41 +0000

Hi Ross,

This draft documents the result of some elaborated work jointly by people from vendors, operators and academia.

In view of its usefulness, its importance and its technical integrity, I support its adoption.

Regards,

Renwei

Thanks, Ross

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 13 Feb 2014 23:31:41 +0000

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

Sent: Thursday, February 13, 2014 1:59 PM

Hi Greg,

Best Regards,
Huaimo
To: Huaimo Chen; Ross Callon; [email-masked]<mailto:[email-masked]>

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best regards,
Huaimo

do not support

                Regards,
                                Greg

Thanks, Ross

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 14 Feb 2014 00:04:28 +0000

Hi Huaimo,
another question in connection to our discussion:

*         in authors opinion, is it possible for FRR protection of link between R3 and L1 (Fig.1) and L1 egress node protection to coexist.

Regards,
        Greg

Sent: Thursday, February 13, 2014 3:32 PM

Hi Huaimo,

*         link protection

*         node protection

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best regards,
Huaimo

do not support

                Regards,
                                Greg

Thanks, Ross

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 14 Feb 2014 09:25:41 +0530

Support!!

This I.D. is in good place to be a adopted by the working group.

Regards,
Dhruv

---

From: Lizhenbin <[email-masked]>
Date: Fri, 14 Feb 2014 06:44:14 +0000

Support as the contributor.

The draft is mature after a long-term work. We also implemented the prototype to verify the solution. In P2MP MPLS and BGP-based MVPN solutions, reliability is an important requirement. If the end-to-end protection mechanisms are adopted, that is, two P2MP tunnel are set up for 1:1 or 1+1 protection, some users always concerns that there will be duplicated traffic spanning the whole network and it will cause the bandwidth waste. So the local protection mechanism is of much importance to cope with such concerns in the actual deployment. I sincerely hope the draft can be adopted by WG.

Best Regards,
Robin

发件人: mpls [mailto:[email-masked]] 代表 Ross Callon
发送时间: 2014年2月14日 3:46
收件人: [email-masked]
抄送: [email-masked]
主题: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Thanks, Ross

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 14 Feb 2014 16:45:51 +0000

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
Sent: Thursday, February 13, 2014 6:32 PM

Hi Huaimo,

*         link protection

*         node protection

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best regards,
Huaimo

do not support

                Regards,
                                Greg

Thanks, Ross

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 14 Feb 2014 16:57:21 +0000

Hi Greg,

Why not?
It seems that section 1.2 "Egress Local Protection with FRR" of the draft indicates that that is the way it should go.

Best Regards,
Huaimo
From: Gregory Mirsky [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 7:04 PM
To: Gregory Mirsky; Huaimo Chen; Ross Callon; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Hi Huaimo,

Regards,
        Greg

Hi Huaimo,

*         link protection

*         node protection

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best regards,
Huaimo

do not support

                Regards,
                                Greg

Thanks, Ross

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 14 Feb 2014 17:04:17 +0000

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

Sent: Friday, February 14, 2014 8:46 AM

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

*         link protection

*         node protection

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best regards,
Huaimo

do not support

                Regards,
                                Greg

Thanks, Ross

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 14 Feb 2014 17:15:55 +0000

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
Sent: Friday, February 14, 2014 12:04 PM

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

*         link protection

*         node protection

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best regards,
Huaimo

do not support

                Regards,
                                Greg

Thanks, Ross

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 14 Feb 2014 17:41:52 +0000

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

Sent: Friday, February 14, 2014 9:16 AM

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

*         link protection

*         node protection

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best regards,
Huaimo

do not support

                Regards,
                                Greg

Thanks, Ross

---

From: Emily <[email-masked]>
Date: Sat, 15 Feb 2014 12:09:18 +0800

Support.

Best regards,
Emily

---

From: Mach Chen <[email-masked]>
Date: Mon, 17 Feb 2014 01:38:59 +0000

Support.

Best regards,
Mach

From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Friday, February 14, 2014 3:46 AM
To: [email-masked]
Cc: [email-masked]
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Thanks, Ross

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 17 Feb 2014 16:04:19 +0000

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
Sent: Friday, February 14, 2014 12:42 PM

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

*         link protection

*         node protection

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best regards,
Huaimo

do not support

                Regards,
                                Greg

Thanks, Ross

---

From: LEI LIU <[email-masked]>
Date: Mon, 17 Feb 2014 09:51:26 -0800

Support.

Best regards,
Lei

-- 
-- 
__________________________________
Best Regards,

Sincerely Yours,
Lei Liu, Ph.D
--------------------
Photonic Transport Network Laboratory,
KDDI R&D Laboratories Inc.,
2-1-15 Ohara Fujimino-shi, Saitama, Japan
TELE: +81-49-278-7536
FAX: +81-49-278-7510
ZIP: 356-8502
E-mail: [email-masked] / [email-masked]

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 17 Feb 2014 21:33:49 +0000

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

Sent: Monday, February 17, 2014 8:04 AM

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

*         link protection

*         node protection

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best regards,
Huaimo

do not support

                Regards,
                                Greg

Thanks, Ross

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 17 Feb 2014 22:08:35 +0000

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
Sent: Monday, February 17, 2014 4:34 PM

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

*         link protection

*         node protection

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best regards,
Huaimo

do not support

                Regards,
                                Greg

Thanks, Ross

---

From: Vero Zheng <[email-masked]>
Date: Tue, 18 Feb 2014 01:37:16 +0000

Yes/Support

Cheers, Vero

Thanks, Ross

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 18 Feb 2014 07:23:13 +0000

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. 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.
Because of these considerations I believe that the proposed approach is limited, not practical and offers solution to a problem that already been solved.

                Regards,
                                Greg

Sent: Monday, February 17, 2014 2:09 PM

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

*         link protection

*         node protection

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best regards,
Huaimo

do not support

                Regards,
                                Greg

Thanks, Ross

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 26 Feb 2014 21:05:50 +0000

Hi Greg,

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

Best Regards,
Huaimo
Sent: Tuesday, February 18, 2014 2:23 AM

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.

[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

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

*         link protection

*         node protection

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best regards,
Huaimo

do not support

                Regards,
                                Greg

Thanks, Ross

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 26 Feb 2014 21:38:10 +0000

Hi Huaimo,
I think that I've provided sufficient information to why I consider this proposal is outside of WG interest already.

                Regards,
                                Greg

Sent: Wednesday, February 26, 2014 1:06 PM

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

*         link protection

*         node protection

                Regards,
                                Greg

Hi Greg,

Best Regards,
Huaimo

Hi Huaimo,

                Regards,
                                Greg

Hi Greg,

Best regards,
Huaimo

do not support

                Regards,
                                Greg

Thanks, Ross