Re: [bess] New Version Notification for draft-wang-bess-mvpn-upstream-df-selection-03.txt

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Siyu,

For the following:

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
#6.
   ... According to the negotiation community, a distinct
   C-Multicast route for (C-S, C-G) is sent to each multi-homed root PE.
   Leaf PE installs all P-Tunnels rooted from the multi-homed PEs into
   the anycast RPF tunnel checklist of the corresponding multicast
   traffic (C-S, C-G).

> Suggestion : This means, if there are four ingress PEs for the same flow,  all of them will receive the C-multicast route. With the RFC9026 procedure, only two of them will, and the selection can still be based on (s,g).
In summary, I don't see sufficient advantages of developing another solution now that RFC9026 have been implemented and deployed.

>> Reply: In RFC9026, there can be one standby PE or multiple standby PEs.
a) Multiple standby PEs in Section 3.1.6.2:
     'If the site that contains C-S is connected to two or more PEs, a downstream PE will select one as its Primary Upstream PE, while others are considered to be Standby Upstream PEs'.
b) One standby PE in Section 4:
     'In the case where more than two PEs are connected to the C-S site, selection of the Standby PE can be performed using one of the methods of selecting a UMH.'
In our draft, we will modify relevant descriptions so that only one PE will be selected as Standby PE. C-multicast route will only be sent to the selected Standby PE.
The advantage of our approach over RFC9026 has been mentioned in #3.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

My understanding is from the following text:

      If a leaf PE decides to send C-Multicast routes to upstream PEs for a
      given (C-S, C-G), it follows the procedure described in [RFC6514]
      excepting that the RPF route of the c-root has an IDF negotiation
--->community.  According to the negotiation community, a distinct
--->C-Multicast route for (C-S, C-G) is sent to each multi-homed root PE.
   ...

   b.  To perform IDF election for each C-G of a specific multicast
       source C-S, each PE also builds an ordered list of the IP
       addresses of all the multi-homed PE nodes at first.  The
       difference between this option and above is that the election of
       IDF occurs not upon receiving all UMH routes of the other multi-
---->homed PEs of the specfied C-S but upon receiving the C-multicast
---->join of the corresponding C-G.  Assuming an ordered list of N
       elements, the PE with ordinal i is the IDF for a C-G when (C-G
       mod N) = i.  The PE with ordinal j is the Standby IDF when j is
       (C-G mod (N-1)).  The calculation of standby IDF uses the ordered
       IP addresses list without considering the existance of the
       elected IDF element.

To perform (S,G) based selection, all root PEs must receive the C-mcast routes first.

Thanks.
Jeffrey


Juniper Business Use Only

-----Original Message-----
From: Chensiyu (Susie) <chensiyu27=[e-mail]> 
Sent: Monday, February 13, 2023 7:11 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; [e-mail]
Cc: duanfanghong <[e-mail]>
Subject: RE:RE: New Version Notification for draft-wang-bess-mvpn-upstream-df-selection-03.txt

[External Email. Be cautious of content]


Hi, Jeffrey
Thank you very much for your feedback on our draft. We will update a new version of the draft later based on our discussions. Our replies to all suggestions are as follow.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
#1.
   For the "hot root standby"
   mechanism, all the ingress PEs, regardless of the primary or standby
   role, forward (C-S,C-G) flow to other PEs through a P-tunnel, forcing
   the egress PEs to discard all but one, which will cause the steady
   traffic redundancy throughout the backbone network.  In the scenarios
   of enterprise networks crossing provider networks, the waste of
   bandwidth is a crucial issue causing the increasement of the OpEx of
   enterprise networks, and the "warm root standby" mechanism is
   expected to be a better solution.
> Suggestion : The mentioning of Hot Root Standby (HRS) should be removed.
It is specifically designed for scenarios where it is critical for egress PEs to receive but discard duplicates and BW consumption is not a concern. Where BW is a concern, the Warm Root Standby
(WRS) can be used.
This draft should only compare to WRS.

>> Reply : We will modify the first paragraph of the Introduction Section in the new version.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
#2.
   However, there are some problems
   when deploying the "warm root standby" mechanism described in
   [RFC9026].
   a.  Upon the failure of primary ingress PE, the standby ingress PE
       needs to send PIM join hop by hop toward multicast source for
       each multicast flow and the time when the standby ingress PE
       switches to the primary role may be inconsistent with the time
       when the leaf PE determines to accept multicast traffic sent by
       the standby root, causing which the failover time can hardly
       reach the same level of "hot root standby" mechanism.
> Suggestion : This point should be removed because it describes Cold Root Standby. With WRS in RFC9026, traffic already arrives on both PEs.

>> Reply : Agree. We will remove 'the standby ingress PE needs to send PIM join hop by hop toward multicast source'.
                     Actually, upon the failure of primary ingress PE, the leaf PE is the one that needs to send the new C-multicast route towards the standby ingress PE without carrying the Standby PE BGP Community according to RFC9026.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
#3.
   b.  There is no endogenous mechanism for standby ingress PEs to
       discover and detect the failure of primary ingress PEs, resulting
       in the uncertainty in deployment and implementation.

> Question : What's the problem of relying on egress PEs detecting the failure of primary PE?

>>Reply:  It takes longer switchover time. When the egress PE detects the failure of the ingress Primary PE, it will update all relevant C-multicast routes and send them to the standby ingress PE.
                    For example, if there are 1000 (C-S, C-G)s, 1000 C-multicast routes will be updated and resent so that the standby PE can finally forward traffic.
                    (The switchover time will be correspondingly longer than using ingress PE to detect and forward traffic directly.)
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
#4.
   c.  In [RFC9026], the standby ingress PE is determined by using
       "Standby PE Community" carried in the C-Multicast routes.  The
       premise of this mechanism is that all leaf PEs choose the same
       primary and standby ingress PEs, which may not be met due to
       transient unicast routing inconsistencies, the inconsistencies of
       P-Tunnel status determined by each leaf PE or lack of support of
       the Standby PE community on leaf PE, causing that the "warm root
       standby" mechanism is not stable and returns to "hot root
       standby" mode because the standby ingress PE also sends multicast
       traffic to backbone when the condition is not satisfied.

> Suggestion: The potential inconsistent choice among egress PEs is likely because that the tunnel branches may be up to some egress PEs while down to others.
That is actually a good reason for different choices - we don't want some egress PEs to not be able to receive from the primary PE. Besides, MVPN handles that situation well (remember that each egress PE can choose its ingress PE - see the "Another procedure ..." paragraph in https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc6513.html*section-5.1.3__;Iw!!NEt6yMaO-gk!FtW1BVw8oYoBMSyMd7diuprMxPYWtW0v5hXWOV6_iLjmvanu21PyGt8Tf_jiDoTCpigUlSb2FdCKCi6Pa3H2gEfQatRzuR_U$ ).
If it desired to avoid that, the tunnel status consideration can be skipped and you'll get consistency that your draft wants, but both are at the cost of some egress PE may not be able to receive traffic.

>> Reply: Yes, we will think about appropriate solutions to solve this problem.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
#5.
        anycast RPF checking mechanism in dataplane
> Suggestion : The word "anycast" is misleading. You should say that traffic from any of the ingress PEs can be accepted.

>> Reply: Agree. We will update it with a more appropriate word or just use the phrase of 'traffic from any of the ingress PEs can be accepted'.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
#6.
   ... According to the negotiation community, a distinct
   C-Multicast route for (C-S, C-G) is sent to each multi-homed root PE.
   Leaf PE installs all P-Tunnels rooted from the multi-homed PEs into
   the anycast RPF tunnel checklist of the corresponding multicast
   traffic (C-S, C-G).

> Suggestion : This means, if there are four ingress PEs for the same flow,  all of them will receive the C-multicast route. With the RFC9026 procedure, only two of them will, and the selection can still be based on (s,g).
In summary, I don't see sufficient advantages of developing another solution now that RFC9026 have been implemented and deployed.

>> Reply: In RFC9026, there can be one standby PE or multiple standby PEs.
a) Multiple standby PEs in Section 3.1.6.2:
     'If the site that contains C-S is connected to two or more PEs, a downstream PE will select one as its Primary Upstream PE, while others are considered to be Standby Upstream PEs'.
b) One standby PE in Section 4:
     'In the case where more than two PEs are connected to the C-S site, selection of the Standby PE can be performed using one of the methods of selecting a UMH.'
In our draft, we will modify relevant descriptions so that only one PE will be selected as Standby PE. C-multicast route will only be sent to the selected Standby PE.
The advantage of our approach over RFC9026 has been mentioned in #3.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
#7.
   For the scenarios of the same RD, this document introduces a new type
   of UMH route to be sent in MVPN SAFI, of which the NLRI key consists
   of the following fields:

> Suggestion: Instead of advertising the UMH route with the MVPN SAFI, we might as well advertise with the VPN-IP SAFI with RD/RT, and use RT to import into the default instance. It does not need any signaling changes and depending on implementation it may just work. We wrote a draft and circulated internally/ externally back in July 2022, but I am surprised that it was not posted.
I will forward you a copy for your review.
With this, it not only solves MVPN problem, but can also be used for unicast.

>> Reply:  We are reading and understanding the draft and we will reply about it later.

Thanks again for your contribution to this draft. We are looking forward to more feedback from you.
Best wishes,
Susie





-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=[e-mail]]
Sent: Wednesday, February 8, 2023 8:49 AM
To: Chensiyu (Susie) <[e-mail]>; [e-mail]
Cc: duanfanghong <[e-mail]>
Subject: RE: New Version Notification for draft-wang-bess-mvpn-upstream-df-selection-03.txt

Hi Siyu,

Please see comments below.

   For the "hot root standby"
   mechanism, all the ingress PEs, regardless of the primary or standby
   role, forward (C-S,C-G) flow to other PEs through a P-tunnel, forcing
   the egress PEs to discard all but one, which will cause the steady
   traffic redundancy throughout the backbone network.  In the scenarios
   of enterprise networks crossing provider networks, the waste of
   bandwidth is a crucial issue causing the increasement of the OpEx of
   enterprise networks, and the "warm root standby" mechanism is
   expected to be a better solution.

The mentioning of Hot Root Standby (HRS) should be removed.
It is specifically designed for scenarios where it is critical for egress PEs to receive but discard duplicates and BW consumption is not a concern. Where BW is a concern, the Warm Root Standby
(WRS) can be used.

This draft should only compare to WRS.

   However, there are some problems
   when deploying the "warm root standby" mechanism described in
   [RFC9026].

   a.  Upon the failure of primary ingress PE, the standby ingress PE
       needs to send PIM join hop by hop toward multicast source for
       each multicast flow and the time when the standby ingress PE
       switches to the primary role may be inconsistent with the time
       when the leaf PE determines to accept multicast traffic sent by
       the standby root, causing which the failover time can hardly
       reach the same level of "hot root standby" mechanism.

This point should be removed because it describes Cold Root Standby.
With WRS in RFC9026, traffic already arrives on both PEs.

   b.  There is no endogenous mechanism for standby ingress PEs to
       discover and detect the failure of primary ingress PEs, resulting
       in the uncertainty in deployment and implementation.

What's the problem of relying on egress PEs detecting the failure of primary PE?

   c.  In [RFC9026], the standby ingress PE is determined by using
       "Standby PE Community" carried in the C-Multicast routes.  The
       premise of this mechanism is that all leaf PEs choose the same
       primary and standby ingress PEs, which may not be meeted due to
       transient unicast routing inconsistencies, the inconsistencies of
       P-Tunnel status determined by each leaf PE or lack of support of
       the Standby PE community on leaf PE, causing that the "warm root
       standby" mechanism is not stable and returns to "hot root
       standby" mode because the standby ingress PE also sends multicast
       traffic to backbone when the condition is not satisfied.

The potential inconsistent choice among egress PEs is likely because that the tunnel branches may be up to some egress PEs while down to others.
That is actually a good reason for different choices - we don't want some egress PEs to not be able to receive from the primary PE. Besides, MVPN handles that situation well (remember that each egress PE can choose its ingress PE - see the "Another procedure ..." paragraph in https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc6513.html*section-5.1.3__;Iw!!NEt6yMaO-gk!FtW1BVw8oYoBMSyMd7diuprMxPYWtW0v5hXWOV6_iLjmvanu21PyGt8Tf_jiDoTCpigUlSb2FdCKCi6Pa3H2gEfQatRzuR_U$ ).

If it desired to avoid that, the tunnel status consideration can be skipped and you'll get consistency that your draft wants, but both are at the cost of some egress PE may not be able to receive traffic.

   d.  The primary and standby role is fixed for each multicast flow,
       resulting in that ingress PEs cannot perform load balancing for
       multicast traffic.  Only two ingress PEs are selected for all
       multicast stream from a specific multicast source, causing that
       the "warm root standby" mechanism cannot be used in the scenarios
       of client nework multihoming to more than two ingress PEs.

I don't think that is true. The same Single Forward Selection rules in RFC6513, which can do load balancing (see 5.1.3 of RFC6513) among different
(C-S,C-G) flows, can be used to
choose both primary and secondary UMH (the secondary one can be chosen the same way after excluding the primary one). If RFC9026 is not clear about that, it can be clarified.

        anycast RPF checking mechanism in dataplane

The word "anycast" is misleading. You should say that traffic from any of the ingress PEs can be accepted.

   ... According to the negotiation community, a distinct
   C-Multicast route for (C-S, C-G) is sent to each multi-homed root PE.
   Leaf PE installs all P-Tunnels rooted from the multi-homed PEs into
   the anycast RPF tunnel checklist of the corresponding multicast
   traffic (C-S, C-G).

This means, if there are four ingress PEs for the same flow,  all of them will receive the C-multicast route. With the RFC9026 procedure, only two of them will, and the selection can still be based on (s,g).

In summary, I don't see sufficient advantages of developing another solution now that RFC9026 have been implemented and deployed.

   For the scenarios of the same RD, this document introduces a new type
   of UMH route to be sent in MVPN SAFI, of which the NLRI key consists
   of the following fields:

Instead of advertising the UMH route with the MVPN SAFI, we might as well advertise with the VPN-IP SAFI with RD/RT, and use RT to import into the default instance. It does not need any signaling changes and depending on implementation it may just work. We wrote a draft and circulated internally/ externally back in July 2022, but I am surprised that it was not posted.
I will forward you a copy for your review.

With this, it not only solves MVPN problem, but can also be used for unicast.

Thanks.
Jeffrey


Juniper Business Use Only

-----Original Message-----
From: BESS <[e-mail]> On Behalf Of Chensiyu (Susie)
Sent: Monday, November 21, 2022 7:27 AM
To: [e-mail]
Cc: duanfanghong <[e-mail]>
Subject: [bess] FW: New Version Notification for draft-wang-bess-mvpn-upstream-df-selection-03.txt

[External Email. Be cautious of content]


Hi all,
A new version of the draft https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-bess-mvpn-upstream-df-selection/__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyAEwJo9O$  is published, in which the root PEs differentiation issue of UMH route and dual-root protection issue in Segmented Inter-AS Scenario are resolved.
We are looking forward to more comments, it would be appreciated if you can give some valuable suggestions to help us evolve it further .
Regards,
Siyu Chen

-------------------------------------------------------------------------------------------------------

A new version of I-D, draft-wang-bess-mvpn-upstream-df-selection-03.txt
has been successfully submitted by Siyu Chen and posted to the IETF repository.

Name:           draft-wang-bess-mvpn-upstream-df-selection
Revision:       03
Title:          Multicast VPN Upstream Designated Forwarder Selection
Document date:  2022-11-21
Group:          Individual Submission
Pages:          16
URL:            https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-wang-bess-mvpn-upstream-df-selection-03.txt__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyIh-akra$
Status:         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-bess-mvpn-upstream-df-selection/__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyAEwJo9O$
Htmlized:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-wang-bess-mvpn-upstream-df-selection__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyGr5TPdY$
Diff:           https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-wang-bess-mvpn-upstream-df-selection-03__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyDj7YPMP$

Abstract:
   This document defines Multicast Virtual Private Network (VPN)
   extensions and procedures of designated forwarder election performed
   between ingress PEs, which is different from the one described in
   [RFC9026] in which the upstream designated fowarder determined by
   using the "Standby PE Community" carried in the C-Multicast routes.
   Based on the DF election, the failure detcetion point discovery
   mechanism between DF and standby DF is extended in MVPN procedures to
   achieve fast failover by using BFD session to track the status of
   detection point.  To realize a stable "warm root standby", this
   document obsolete the P-Tunnel status determining procedure for
   downstream PEs in regular MVPN by introducing an anycast RPF checking
   mechanism in dataplane as an instead.





The IETF Secretariat



_______________________________________________
BESS mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyIKMC0SE$