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

From: Ross Callon <[email-masked]>
Date: Mon, 17 Feb 2014 21:08:53 +0000

This is to start a poll on adopting draft-chen-mpls-p2mp-ingress-protection-11
as an MPLS working group document. Since this call will continue through the
IETF meeting in London, 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 Tuesday March 11, 2014. This is of course the Tuesday after
the IETF.

Thanks, Ross

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 17 Feb 2014 21:12:53 +0000

Support!
(as an author)

Best Regards,
Huaimo
From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Monday, February 17, 2014 4:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11

Thanks, Ross

---

From: Lizhenbin <[email-masked]>
Date: Tue, 18 Feb 2014 01:10:40 +0000

Support as the contributor.

Regards,
Robin

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

Thanks, Ross

---

From: Haoweiguo <[email-masked]>
Date: Tue, 18 Feb 2014 05:50:03 +0000

Support!

Thanks

weiguo

________________________________
发件人: mpls [[email-masked]] 代表 Lizhenbin [[email-masked]]
发送时间: 2014年2月18日 9:10
收件人: Ross Callon; [email-masked]
抄送: [email-masked]
主题: [mpls] 答复: Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11

Regards,
Robin

Thanks, Ross

---

From: Qin Wu <[email-masked]>
Date: Tue, 18 Feb 2014 06:57:42 +0000

Support.

Regards!
-Qin
From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Tuesday, February 18, 2014 5:09 AM
To: [email-masked]
Cc: [email-masked]
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11

Thanks, Ross

---

From: weiqiang cheng <[email-masked]>
Date: Tue, 18 Feb 2014 17:21:11 +0800

Support!
B.R.
Weiqiang Cheng

2014-02-18 14:57 GMT+08:00 Qin Wu <[email-masked]>:

>  Support.
>
>
>
> Regards!
>
> -Qin
>
> *From:* mpls [mailto:[email-masked]] *On Behalf Of *Ross Callon
> *Sent:* Tuesday, February 18, 2014 5:09 AM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* [mpls] Poll for Adoption
> draft-chen-mpls-p2mp-ingress-protection-11
>
>
>
> This is to start a poll on adopting
> draft-chen-mpls-p2mp-ingress-protection-11
>
> mailing list ([email-masked]).
>
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 18 Feb 2014 15:55:09 +0530

Support!

---

From: Dorian Davis <[email-masked]>
Date: Tue, 18 Feb 2014 09:24:42 -0500 (EST)

Support! 

------------------
Dorian Davis
[email-masked]

-----Original Message-----
From: Lizhenbin <[email-masked]>
To: Ross Callon <[email-masked]>; mpls <[email-masked]>
Cc: mpls-chairs <[email-masked]>
Sent: Tue, Feb 18, 2014 6:40 am
Subject: [mpls] 答复: Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11

Regards,
Robin

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

Thanks, Ross

---

From: Young Lee <[email-masked]>
Date: Tue, 18 Feb 2014 08:36:05 -0800 (PST)

Support.
 
Young

On Monday, February 17, 2014 3:09 PM, Ross Callon <[email-masked]> wrote:

   
   
Thanks, Ross

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 18 Feb 2014 14:48:30 -0500

I support the adoption of this draft.

Cheers,
Andy

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 18 Feb 2014 20:09:43 +0000

do not support

Proposed solution cannot offer complete protection as in its root is misconception that running multiple CC sessions between two nodes can help with detecting failure of a node (sections 3.1, 3.2, and 3.4). The only viable case presented in section 3.3 where CE is monitoring access link to the ingress. This is well-known case, e.g. Ethernet First Mile, and can be addressed in many different ways already.

                Regards,
                                Greg

From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Monday, February 17, 2014 1:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11

Thanks, Ross

---

From: LEI LIU <[email-masked]>
Date: Tue, 18 Feb 2014 12:56:07 -0800

Yes, support as a co-author.

Thanks,
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: Emily <[email-masked]>
Date: Wed, 19 Feb 2014 17:00:52 +0800

Support.

Best regards,
Emily

---

From: Boris Zhang <[email-masked]>
Date: Mon, 24 Feb 2014 14:17:53 -0500

Support !

Boris Zhang
TELUS INC.

From: Huaimo Chen [mailto:[email-masked]]
Sent: February 23, 2014 09:17 PM
To: Boris Zhang
Subject: Please support INgress Protection Draft
Importance: High

Hi Boris,

Can you help support our Ingress Protection draft as a contributor?

Best Regards,
Huaimo
From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Monday, February 17, 2014 4:09 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11

Thanks, Ross

---

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

Hi Greg,

It seems that your reason for do not support is not persuasive.
     Regarding to  your statement "The only viable case presented in section 3.3 where CE is monitoring access link to the ingress. This is well-known case, e.g. Ethernet First Mile, and can be addressed in many different ways already." , can you provide details on one of many different ways in your mind that provides protections of  the ingress of an MPLS TE LSP?

Best Regards,
Huaimo
From: mpls [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Tuesday, February 18, 2014 3:10 PM
To: Ross Callon; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11

do not support

                Regards,
                                Greg

Thanks, Ross

---

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

Hi Huaimo,
I don't consider WG poll as a contest in art of persuasion. I've merely provided my technical opinion.
As for your question, my opinion is protection of ingress LSR, and egress LSR for that matter, is outside of scope of server LSP and can be easily addressed for client layer. And in my opinion MPLS WG should not spend more time discussing standardization of attempts to solve these. Though it may be reasonable to preserve them as Experimental.

                Regards,
                                Greg

From: Huaimo Chen [mailto:[email-masked]]
Sent: Wednesday, February 26, 2014 1:25 PM
To: Gregory Mirsky; Ross Callon; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11

Hi Greg,

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

do not support

                Regards,
                                Greg

Thanks, Ross

---

From: Yimin Shen <[email-masked]>
Date: Wed, 26 Feb 2014 22:46:58 +0000

Support (as a co-author)

Thanks,

/Yimin

Thanks, Ross

---

From: Alia Atlas <[email-masked]>
Date: Wed, 26 Feb 2014 18:50:10 -0500

I do support this draft as a good starting place for a working group
document.  It still needs work - I'd love to see discussion of the two
approaches described in it - but I think it is a good place to start.

Greg, the concern about distinguishing between link and node failure is
interesting.  There are four different approaches in the draft because
there can be different deployment scenarios which make each valid.  When
considering the different cases, the concern is always whether the traffic
might be duplicated or not.  Obviously, if the traffic source decides, then
no duplication is possible.  If the backup ingress can determine that there
is no functional path from the ingress, then that is a different case where
traffic duplication can be avoided.  If the potential merge point does
stream selection (as is done with MoFRR), then that allows yet other
decision points.   Different deployment scenarios are the key here.    We
did actually go down the road of how one would need to set up BFD sessions
to verify failure - but that is also deployment-specific and got rather
lengthy.

Alia

On Wed, Feb 26, 2014 at 4:33 PM, Gregory Mirsky <[email-masked]
> wrote:

> As for your question, my opinion is protection of ingress LSR, and egress
> LSR for that matter, is outside of scope of server LSP and can be easily
> addressed for client layer. And in my opinion MPLS WG should not spend more
> time discussing standardization of attempts to solve these. Though it may
> be reasonable to preserve them as Experimental.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* Huaimo Chen [mailto:[email-masked]]
> *Sent:* Wednesday, February 26, 2014 1:25 PM
> *To:* Gregory Mirsky; Ross Callon; [email-masked]
> *Subject:* RE: [mpls] Poll for Adoption
>      Regarding to  your statement "The only viable case presented in
> section 3.3 where CE is monitoring access link to the ingress. This is
> well-known case, e.g. Ethernet First Mile, and can be addressed in many
> different ways already." , can you provide details on one of many different
> ways in your mind that provides protections of  the ingress of an MPLS TE
> LSP?
>
>
>
> Best Regards,
>
> Huaimo
>
> *From:* mpls [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Gregory Mirsky
> *Sent:* Tuesday, February 18, 2014 3:10 PM
> *To:* Ross Callon; [email-masked]
> *Subject:* Re: [mpls] Poll for Adoption
> Proposed solution cannot offer complete protection as in its root is
> misconception that running multiple CC sessions between two nodes can help
> with detecting failure of a node (sections 3.1, 3.2, and 3.4). The only
> viable case presented in section 3.3 where CE is monitoring access link to
> the ingress. This is well-known case, e.g. Ethernet First Mile, and can be
> addressed in many different ways already.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* mpls [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Ross Callon
> *Sent:* Monday, February 17, 2014 1:09 PM
> *To:* [email-masked]

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 27 Feb 2014 00:25:03 +0000

Hi Alia,
the problem with stream selection by a transient LSR on the LSP is that access links between CE and redundant PEs would not be monitored. Thus I see such scenario of little value as it is no different from "classical" RFC 4090. I believe that protection domain has the same scope, boundaries as OAM domain and that defines limits of what can be protected. To protect ingress, and egress for that point, domain must encompass CEs. Ethernet Service OAM (CFM/Y.1731) got it well through MD/MEG Levels in, for example, this picture:
[Relationship Among MEPs, MIPs,  and Maintenance Domain Levels]

                Regards,
                                Greg

From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, February 26, 2014 3:50 PM
To: Gregory Mirsky
Cc: Huaimo Chen; Ross Callon; [email-masked]; [email-masked]
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11

I do support this draft as a good starting place for a working group document.  It still needs work - I'd love to see discussion of the two approaches described in it - but I think it is a good place to start.

Greg, the concern about distinguishing between link and node failure is interesting.  There are four different approaches in the draft because there can be different deployment scenarios which make each valid.  When considering the different cases, the concern is always whether the traffic might be duplicated or not.  Obviously, if the traffic source decides, then no duplication is possible.  If the backup ingress can determine that there is no functional path from the ingress, then that is a different case where traffic duplication can be avoided.  If the potential merge point does stream selection (as is done with MoFRR), then that allows yet other decision points.   Different deployment scenarios are the key here.    We did actually go down the road of how one would need to set up BFD sessions to verify failure - but that is also deployment-specific and got rather lengthy.

Alia

On Wed, Feb 26, 2014 at 4:33 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Huaimo,
I don't consider WG poll as a contest in art of persuasion. I've merely provided my technical opinion.
As for your question, my opinion is protection of ingress LSR, and egress LSR for that matter, is outside of scope of server LSP and can be easily addressed for client layer. And in my opinion MPLS WG should not spend more time discussing standardization of attempts to solve these. Though it may be reasonable to preserve them as Experimental.

                Regards,
                                Greg

From: Huaimo Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, February 26, 2014 1:25 PM
To: Gregory Mirsky; Ross Callon; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11

Hi Greg,

Best Regards,
Huaimo

do not support

                Regards,
                                Greg

Thanks, Ross

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Ravi Torvi <[email-masked]>
Date: Wed, 26 Feb 2014 23:23:54 -0500

I support this draft as a co-author.

Greg,

Protection domain for classic FRR (for node protection) includes a PLR,
 MP., and Path that avoids failed node.

Options listed in the draft does not stretch OAM domain beyond what FRR
node protection would require. However, in some cases, responsibilities
have been moved to MP.

One of the option that Alia mentioned, involves a Transit LSP as merge
point. Stream selection could be based on a layout of BFD sessions that
involved merge point.

IOW merge point need not switch stream if it is not explicitly detected by
set of BFD sessions failure.

Thanks,
Ravi

On Wednesday, February 26, 2014, Gregory Mirsky <[email-masked]>
wrote:

>  Hi Alia,
>
> the problem with stream selection by a transient LSR on the LSP is that
> access links between CE and redundant PEs would not be monitored. Thus I
> see such scenario of little value as it is no different from "classical"
> RFC 4090. I believe that protection domain has the same scope, boundaries
> as OAM domain and that defines limits of what can be protected. To protect
> ingress, and egress for that point, domain must encompass CEs. Ethernet
> Service OAM (CFM/Y.1731) got it well through MD/MEG Levels in, for example,
> this picture:
>
>
>
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* Alia Atlas [mailto:[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>]
>
> *Sent:* Wednesday, February 26, 2014 3:50 PM
> *To:* Gregory Mirsky
> *Cc:* Huaimo Chen; Ross Callon; [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>;
> [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
> On Wed, Feb 26, 2014 at 4:33 PM, Gregory Mirsky <
> [email-masked]> wrote:
>
> Hi Huaimo,
>
> different ways already." , can
>

-- 
http://www.google.com/profiles/pratiravi

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 27 Feb 2014 06:06:05 +0000

Hi Ravi,
I think that we can try to find time next week for more detailed discussion if authors and anyone else would be interested.
In the meantime I'm still holding to my conclusions.

                Regards,
                                Greg

From: Ravi Torvi [mailto:[email-masked]]
Sent: Wednesday, February 26, 2014 8:24 PM
To: Gregory Mirsky
Cc: Alia Atlas; Ross Callon; [email-masked]; [email-masked]
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11

Greg,

Protection domain for classic FRR (for node protection) includes a PLR,  MP., and Path that avoids failed node.

Options listed in the draft does not stretch OAM domain beyond what FRR node protection would require. However, in some cases, responsibilities have been moved to MP.

One of the option that Alia mentioned, involves a Transit LSP as merge point. Stream selection could be based on a layout of BFD sessions that involved merge point.

IOW merge point need not switch stream if it is not explicitly detected by set of BFD sessions failure.

Thanks,
Ravi

On Wednesday, February 26, 2014, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alia,
the problem with stream selection by a transient LSR on the LSP is that access links between CE and redundant PEs would not be monitored. Thus I see such scenario of little value as it is no different from "classical" RFC 4090. I believe that protection domain has the same scope, boundaries as OAM domain and that defines limits of what can be protected. To protect ingress, and egress for that point, domain must encompass CEs. Ethernet Service OAM (CFM/Y.1731) got it well through MD/MEG Levels in, for example, this picture:
[Relationship Among MEPs, MIPs,  and Maintenance Domain Levels]

                Regards,
                                Greg

From: Alia Atlas [mailto:[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>]
Sent: Wednesday, February 26, 2014 3:50 PM
To: Gregory Mirsky
Cc: Huaimo Chen; Ross Callon; [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>; [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
Subject: Re: [mpls] Poll for Adoption draft-chen-mpls-p2mp-ingress-protection-11

Alia

Hi Huaimo,

                Regards,

                                Greg

Hi Greg,

     Regarding to  your statement "The only viable case presented in section 3.3 where CE is monitoring access link to the ingress. This is well-known case, e.g. Ethernet First Mile, and can be addressed in many different ways already." , can

---

From: Markus Jork <[email-masked]>
Date: Thu, 27 Feb 2014 22:47:28 +0000

Support (as contributor).

-Markus

Thanks, Ross