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

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 <zhang.zheng@zte.com.cn> 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
> 收件人：wanghaojie@chinamobile.com;
> 抄送人：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
> MBONED@ietf.org
> 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?
>
> https://datatracker.ietf.org/doc/html/rfc9026
>
> Kind Regards
>
> Gyan
>
> On Sun, Mar 13, 2022 at 9:48 PM wanghaojie@chinamobile.com <
> wanghaojie@chinamobile.com> wrote:
> Hi Lenny and WG,
>
> This draft is considerably useful, and written well. I support this
> adoption.
>
> Best regards,
> Haojie Wang
> China Mobile
> wanghaojie@chinamobile.com
>
> From: Leonard Giuliano
> Date: 2022-03-11 20:07
> To: MBONED WG
> 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:
>
>
> 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
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned
> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned
> --
>
> Gyan Mishra
> Network Solutions Architect
> Email gyan.s.mishra@verizon.com
> M 301 502-1347
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*