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

Hi Sandy

Welcome!

On Tue, Mar 15, 2022 at 5:24 AM <zhang.zheng@zte.com.cn> wrote:

> Hi Gyan,
> Thank you for your comments!
> Please find my answer below with Sandy>.
>
>
> ------------------原始邮件------------------
> 发件人：GyanMishra
> 收件人：张征00007940;
> 抄送人：lenny=40juniper.net@dmarc.ietf.org;mboned@ietf.org;
> wanghaojie@chinamobile.com;
> 日 期 ：2022年03月14日 22:17
> 主 题 ：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”.
> 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.
>

   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.

>
> 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.

    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.

>
>
> 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 <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
> --
>
> 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*