Subject: [MBONED] MBONED WG adoption call for draft-szcl-mboned-redundant-ingress-failover

From: Leonard Giuliano <[email-masked]>
Date: Fri, 11 Mar 2022 04:07:29 -0800

We would like to initiate an official call for adoption of the "Multicast 
Redundant Ingress Router Failover" draft:

https://datatracker.ietf.org/doc/draft-szcl-mboned-redundant-ingress-failover/

Please respond on list by Mar 25 if you do/do not support adoption of this
draft in MBONED.

If you are listed as a document author, please respond to this email
whether or not you are aware of any relevant IPR. If you are not listed as
an author and are aware of any relevant IPR, please respond as well.

-Lenny

---

From: <[email-masked]>
Date: Mon, 14 Mar 2022 08:55:06 +0800 (CST)

Hi Lenny,
I support the adoption of this draft as co-author. 
I'm not aware of any IPR related to this draft.
Best Regards,
Sandy

------------------原始邮件------------------
发件人：LeonardGiuliano
收件人：MBONED WG;
日 期 ：2022年03月11日 20:08
主 题 ：[MBONED] MBONED WG adoption call for draft-szcl-mboned-redundant-ingress-failover

We would like to initiate an official call for adoption of the "Multicast
Redundant Ingress Router Failover" draft:
https://datatracker.ietf.org/doc/draft-szcl-mboned-redundant-ingress-failover/
Please respond on list by Mar 25 if you do/do not support adoption of this
draft in MBONED.
If you are listed as a document author, please respond to this email
whether or not you are aware of any relevant IPR. If you are not listed as
an author and are aware of any relevant IPR, please respond as well.
-Lenny
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: Ying Cheng <[email-masked]>
Date: Mon, 14 Mar 2022 09:25:01 +0800

Hi Lenny,

This draft is useful for multicast deployment. As co-auther, I support its adoption. In addition, I am not aware of any relevant IPR.

Thanks and best regards,
Ying

________________________________
程莹 | Ying CHENG
中国联通集团科技创新部 |Science & Technology Innovation Department, China Unicom
Office: +86-10-66259394 | Mobile: +86-18601102971  | E-Mail: [email-masked]

From: Leonard Giuliano<mailto:lenny=[email-masked]>
Date: 2022-03-11 20:07
To: MBONED WG<mailto:[email-masked]>
Subject: [MBONED] MBONED WG adoption call for draft-szcl-mboned-redundant-ingress-failover

-Lenny

_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned
如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 14 Mar 2022 09:48:05 +0800

Hi Lenny and WG,

        This draft is considerably useful, and written well. I support this adoption.

Best regards,

Haojie Wang
China Mobile
[email-masked]
 
From: Leonard Giuliano
Date: 2022-03-11 20:07
To: MBONED WG

 

-Lenny

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 14 Mar 2022 01:05:41 -0400

I support WG adoption.

Question for the authors if RFC 9026 MVPN Fast upstream failover helps with
the redundant IR failover issue presented in the draft?

https://datatracker.ietf.org/doc/html/rfc9026

Kind Regards

Gyan

On Sun, Mar 13, 2022 at 9:48 PM [email-masked] <
[email-masked]> wrote:

> ------------------------------
> Haojie Wang
> China Mobile
> *From:* Leonard Giuliano <lenny=[email-masked]>
> *Date:* 2022-03-11 20:07
> *To:* MBONED WG <[email-masked]>
> *Subject:* [MBONED] MBONED WG adoption call for
> draft-szcl-mboned-redundant-ingress-failover
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: <[email-masked]>
Date: Mon, 14 Mar 2022 16:18:37 +0800 (CST)

Hi Gyan, 
Thanks Gyan! 
The three stanby modes mentioned in RFC9026 are discussed in this draft detailedly. 
The signaling part described in this draft absolutely suitable for the BGP signaling in RFC9026.
Best regards,
Sandy

------------------原始邮件------------------
发件人：GyanMishra
收件人：[email-masked];
抄送人：Leonard Giuliano;MBONED WG;
日 期 ：2022年03月14日 13:06
主 题 ：Re: [MBONED] MBONED WG adoption call for draft-szcl-mboned-redundant-ingress-failover
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

I support WG adoption.

Question for the authors if RFC 9026 MVPN Fast upstream failover helps with the redundant IR failover issue presented in the draft?

Kind Regards

Gyan

On Sun, Mar 13, 2022 at 9:48 PM [email-masked] <[email-masked]> wrote:
Hi Lenny and WG,

Best regards,
Haojie Wang
China Mobile

From: Leonard Giuliano
Date: 2022-03-11 20:07
To: MBONED WG

-Lenny

Gyan Mishra
Network Solutions Architect
Email [email-masked]
M 301 502-1347

---

From: "Holland, Jake" <[email-masked]>
Date: Mon, 14 Mar 2022 11:26:31 +0000

Hi mboned,

I support adoption.

I think this is a good start at outlining approaches to addressing an
important problem, and I can see how an informational doc like this
can be a reference for later docs that provide more fully articulated
solutions.

I have a few concerns* that might require some work, but I think they
can be fleshed out in review.

Best,
Jake

* Some specific concerns, at a high level:

1. the approaches described in section 4 seem to have a very BIER-centric
view.  For instance with PIM or P2MP I'm not sure it makes sense for an
ER to signal the IRs in the ways described, and there might have to be
either a different section to describe what makes sense or doesn't make
sense for networks that rely on tree-building, or to narrow this doc's
scope to BIER.

2. Related to #1, it's not clear how actionable the advice to network
operators in this doc is.  I'm not sure if it makes more sense to change
it to advice for future protocol or configuration modeling solutions, or
to add pointers to published examples of configurations that can implement
the given advice, but I think some work probably needs to happen to make
it more clear who the expected reader is and what they can do with the
information in the doc. 

3. there are a lot of English language grammar issues, especially through
section 4.  IMO it makes it a little hard to read and to review, and it
might be helpful to get an early phase editorial pass

On 03-11, 4:08 AM, "Leonard Giuliano" <lenny=[email-masked]> wrote:

-Lenny

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 14 Mar 2022 10:16:48 -0400

Hi Sandy

Excellent!

Few comments and I would be happy to collaborate with this draft.

RFC 9026 section 4.2 upstream PE behavior describes the 3 modes cold warm
and hot root standby below excerpt:

 Doing neither step a nor step b for a given (C-S,C-G) is called "cold
   root standby".

   Doing step a but not step b for a given (C-S,C-G) is called "warm
   root standby".

   Doing step b (which implies also doing step a) for a given (C-S,C-G)
   is called "hot root standby".

In the draft you call it cold warm and hot standby modes.

As you are describing the 3 modes in detail it would be good to call the

exact same names shown above using exact verbiage “root standby”.

Also throughout the descriptions of the 3 modes I would recommend use
the same semantics used

in RFC 9026 as well as mention the “Standby PE community”

used to signal the Ingres PE optimization.

Also in section 3.2 of your draft I would recommend mentioned RFC 9026
updates to RFC 8562 P2MP procedure IANA allocation for BFD discriminator
optional transitive attribute describing the upstream and downstream
procedure in RFC 9026 section 3.1.6.1 and 3.1.6.2 and how that is utilized
in the three modes bringing it all together.

Also in the abstract and introduction I would mention RFC 9026 as that is
the sole goal of the draft is to describe the details of the MVPN
optimizations for failover redundancy.

I think it maybe good to also describe the gaps even with existing RSVP-TE
P2MP FRR link and node protection and MoFRR as well as local protection
mechanisms LFA / RLFA / TI-LFA  used by operators for triple play services,
gap that still exists in failover  which as well now resolved with MVPN
control plane optimization provided by RFC 9026.

Kind Regards

Gyan

On Mon, Mar 14, 2022 at 4:18 AM <[email-masked]> wrote:

> 主 题 ：Re: [MBONED] MBONED WG adoption call for
> Question for the authors if RFC 9026 MVPN Fast upstream failover helps
> with the redundant IR failover issue presented in the draft?
>
> Subject: [MBONED] MBONED WG adoption call for
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 14 Mar 2022 09:18:52 -0700

Support as co-author.

- Shep

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 14 Mar 2022 09:51:14 -0700

As coauthor, I'm unaware of any IPR associated with this draft.

- Shep

---

From: <[email-masked]>
Date: Tue, 15 Mar 2022 15:49:29 +0800 (CST)

Hi Jake, 
Thank you very much for your support and comments! 
Please find my answer below with Sandy>.

------------------原始邮件------------------
发件人：Holland,Jake
收件人：Leonard Giuliano;MBONED WG;
日 期 ：2022年03月14日 19:27
主 题 ：Re: [MBONED] MBONED WG adoption call for draft-szcl-mboned-redundant-ingress-failover
Hi mboned,
I support adoption.
I think this is a good start at outlining approaches to addressing an
important problem, and I can see how an informational doc like this
can be a reference for later docs that provide more fully articulated
solutions.
I have a few concerns* that might require some work, but I think they
can be fleshed out in review.
Best,
Jake
* Some specific concerns, at a high level:
1. the approaches described in section 4 seem to have a very BIER-centric
view.  For instance with PIM or P2MP I'm not sure it makes sense for an
ER to signal the IRs in the ways described, and there might have to be
either a different section to describe what makes sense or doesn't make
sense for networks that rely on tree-building, or to narrow this doc's
scope to BIER.
Sandy> In fact this section is not only used by BIER enviorment. 
The signaling between IR and ER can be used for multicast service management, the intermediate transport technologies can be BIER, P2MP or PIM. 
Although it seems like strange for PIM because PIM depends on tree building.
2. Related to #1, it's not clear how actionable the advice to network
operators in this doc is.  I'm not sure if it makes more sense to change
it to advice for future protocol or configuration modeling solutions, or
to add pointers to published examples of configurations that can implement
the given advice, but I think some work probably needs to happen to make
it more clear who the expected reader is and what they can do with the
information in the doc.
Sandy> The same with 1. This document only analyzes these technologies but not want to modify them. 
The motivation of this draft is let the network administrator select the suitable solution according to the exact deployment, since there is no the best solution.
For how to make it more clear for the reader, much appreciate if you will give more specific modification information.  
3. there are a lot of English language grammar issues, especially through
section 4.  IMO it makes it a little hard to read and to review, and it
might be helpful to get an early phase editorial pass
Sandy> Thank you! We will do some editorial changs for the grammer.
Best regards,
Sandy
On 03-11, 4:08 AM, "Leonard Giuliano" <lenny=[email-masked]> wrote:
We would like to initiate an official call for adoption of the "Multicast
Redundant Ingress Router Failover" draft:
https://datatracker.ietf.org/doc/draft-szcl-mboned-redundant-ingress-failover/
Please respond on list by Mar 25 if you do/do not support adoption of this
draft in MBONED.
If you are listed as a document author, please respond to this email
whether or not you are aware of any relevant IPR. If you are not listed as
an author and are aware of any relevant IPR, please respond as well.
-Lenny
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: <[email-masked]>
Date: Tue, 15 Mar 2022 17:24:19 +0800 (CST)

Hi Gyan, 
Thank you for your comments! 
Please find my answer below with Sandy>.

------------------原始邮件------------------
发件人：GyanMishra
收件人：张征00007940;
抄送人：lenny=[email-masked];[email-masked];[email-masked];
日 期 ：2022年03月14日 22:17
主 题 ：Re: [MBONED] MBONED WG adoption call for draft-szcl-mboned-redundant-ingress-failover

Hi Sandy

Excellent!

RFC 9026 section 4.2 upstream PE behavior describes the 3 modes cold warm and hot root standby below excerpt:

Doing neither step a nor step b for a given (C-S,C-G) is called "cold    root standby".     Doing step a but not step b for a given (C-S,C-G) is called "warm    root standby".     Doing step b (which implies also doing step a) for a given (C-S,C-G)    is called "hot root standby".
In the draft you call it cold warm and hot standby modes.
As you are describing the 3 modes in detail it would be good to call the
exact same names shown above using exact verbiage “root standby”.
Sandy> OK. We will modify it in next version.

Also throughout the descriptions of the 3 modes I would recommend use the same semantics used
in RFC 9026 as well as mention the “Standby PE community”
used to signal the Ingres PE optimization.
Sandy> In fact we think that the IR and ER may more suitable for general deployment. Because in some cases there may be no VPN deployment. But we can discuss it and find the most suitable word.

Also in section 3.2 of your draft I would recommend mentioned RFC 9026 updates to RFC 8562 P2MP procedure IANA allocation for BFD discriminator optional transitive attribute describing the upstream and downstream procedure in RFC 9026 section 3.1.6.1 and 3.1.6.2 and how that is utilized in the three modes bringing it all together.
Sandy> Good suggestion. We'll consider to add some description for it in next version.

Also in the abstract and introduction I would mention RFC 9026 as that is the sole goal of the draft is to describe the details of the MVPN optimizations for failover redundancy.
Sandy> The MVPN usage is just one usage of the redundant ingress failover. This draft can be used in the environment without MVPN deployment.

I think it maybe good to also describe the gaps even with existing RSVP-TE P2MP FRR link and node protection and MoFRR as well as local protection mechanisms LFA / RLFA / TI-LFA  used by operators for triple play services, gap that still exists in failover  which as well now resolved with MVPN control plane optimization provided by RFC 9026.
Sandy> Good suggestion. We will consider how to describe it in future version.
Best regards,
Sandy

Kind Regards

Gyan

------------------原始邮件------------------
发件人：GyanMishra

Gyan Mishra

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 15 Mar 2022 09:48:37 -0400

Hi Sandy

Welcome!

On Tue, Mar 15, 2022 at 5:24 AM <[email-masked]> wrote:

> root standby".     Doing step a but not step b for a given (C-S,C-G) is
> called "warm    root standby".     Doing step b (which implies also doing
> step a) for a given (C-S,C-G)    is called "hot root standby".
> Sandy> In fact we think that the IR and ER may more suitable for general
> deployment. Because in some cases there may be no VPN deployment. But we
> can discuss it and find the most suitable word.
>

   Gyan> Would that be for IP based networks “non MPLS” or GTM RFC 7716
which as well uses MVPN.  BGP MDT SAFI 66 RFC 6037 PIM core uses MVPN RFC
6513 / 6514 procedures.  I don’t think anyone uses PIM Rosen draft was Pre
MVPN procedures development which provided the separation of control plane
procedures onto RR from data plane forwarding.

> Sandy> The MVPN usage is just one usage of the redundant ingress failover.
> This draft can be used in the environment without MVPN deployment.

    Gyan> I think it would be good to add the scenario for non MVPN use
case and how that would apply as I am thinking it would be non MPLS as well
as all MPLS based would use MVPN procedures.  Another idea would be to spin
up a separate draft for non MVPN do that we don’t confuse or clutter this
draft. I think since it’s not in draft for the adoption call that would be
a significant change as well to add to adopted draft.

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "gongliyan" <[email-masked]>
Date: Wed, 16 Mar 2022 11:05:05 +0800

Hi WG,
I support this adoption. 

Best Regards,
Liyan

-----邮件原件-----
发件人: MBONED [mailto:[email-masked]] 代表 Leonard Giuliano
发送时间: 2022年3月11日 20:07
收件人: MBONED WG
主题: [MBONED] MBONED WG adoption call for

https://datatracker.ietf.org/doc/draft-szcl-mboned-redundant-ingress-failove
r/

-Lenny

---

From: <[email-masked]>
Date: Wed, 16 Mar 2022 14:58:07 +0800 (CST)

Hi Gyan, 
Please find my answers inline with Sandy1>.

------------------原始邮件------------------
发件人：GyanMishra
收件人：张征00007940;
抄送人：lenny=[email-masked];[email-masked];
日 期 ：2022年03月15日 21:48
主 题 ：Re: [MBONED] MBONED WG adoption call for draft-szcl-mboned-redundant-ingress-failover
Hi Sandy

Welcome!

------------------原始邮件------------------
发件人：GyanMishra
收件人：张征00007940;

Gyan> Would that be for IP based networks “non MPLS” or GTM RFC 7716 which as well uses MVPN.  BGP MDT SAFI 66 RFC 6037 PIM core uses MVPN RFC 6513 / 6514 procedures.  I don’t think anyone uses PIM Rosen draft was Pre MVPN procedures development which provided the separation of control plane procedures onto RR from data plane forwarding.
Sandy1> GTM is one of the usage for it. I am not sure if RFC6037 has been deployed. And there is more overlay protocols can be used in BIER environment. For some intermediate transportations there may be some specific name for the edge routers.  So we think that the ingress router or egress router may be the most general name for it. 

Gyan> I think it would be good to add the scenario for non MVPN use case and how that would apply as I am thinking it would be non MPLS as well as all MPLS based would use MVPN procedures.  Another idea would be to spin up a separate draft for non MVPN do that we don’t confuse or clutter this draft. I think since it’s not in draft for the adoption call that would be a significant change as well to add to adopted draft.
Sandy1> This draft does not limit on the MVPN usecase, non-MVPN usecase can be also included. We will consider to add more details about it in the draft. 
Thank you!
Best regards,
Sandy
I think it maybe good to also describe the gaps even with existing RSVP-TE P2MP FRR link and node protection and MoFRR as well as local protection mechanisms LFA / RLFA / TI-LFA  used by operators for triple play services, gap that still exists in failover  which as well now resolved with MVPN control plane optimization provided by RFC 9026.
Sandy> Good suggestion. We will consider how to describe it in future version.
Best regards,
Sandy
Kind Regards
Gyan
On Mon, Mar 14, 2022 at 4:18 AM <[email-masked]> wrote:
Hi Gyan,
Thanks Gyan!
The three stanby modes mentioned in RFC9026 are discussed in this draft detailedly.
The signaling part described in this draft absolutely suitable for the BGP signaling in RFC9026.
Best regards,
Sandy
------------------原始邮件------------------
发件人：GyanMishra

Gyan Mishra

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 18 Mar 2022 02:57:23 +0000

Hi Lenny,

I do support adoption of this draft.

Thanks
Jingrong

-----Original Message-----
From: MBONED [mailto:[email-masked]] On Behalf Of Leonard Giuliano
Sent: Friday, March 11, 2022 8:07 PM
To: MBONED WG <[email-masked]>
Subject: [MBONED] MBONED WG adoption call for draft-szcl-mboned-redundant-ingress-failover

We would like to initiate an official call for adoption of the "Multicast Redundant Ingress Router Failover" draft:

Please respond on list by Mar 25 if you do/do not support adoption of this draft in MBONED.

If you are listed as a document author, please respond to this email whether or not you are aware of any relevant IPR. If you are not listed as an author and are aware of any relevant IPR, please respond as well.

-Lenny