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://www.rfc-editor.org/rfc/rfc6513.html#section-5.1.3).
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:[email protected]]
Sent: Wednesday, February 8, 2023 8:49 AM
To: Chensiyu (Susie) <[email protected]>; [email protected]
Cc: duanfanghong <[email protected]>
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://www.rfc-editor.org/rfc/rfc6513.html#section-5.1.3).
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 <[email protected]> On Behalf Of Chensiyu (Susie)
Sent: Monday, November 21, 2022 7:27 AM
To: [email protected]
Cc: duanfanghong <[email protected]>
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
[email protected]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!HdrJ7-G-GzTAivmylUCtos02On6dZ0TiNLBVUuR9CcafA0rrdXSyAEluuJqj13mO0jxEdhdrR2FGjnJ7iMxq4w_iyIKMC0SE$
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
