Hi Jeffrey and Sasha,
The flows of E-tree services typically are P2MP conections,
But the flows of hub/spoke services typically are MP2MP connections,
the spoke PEs can connect to each other under the assistance of the hub PE.
The hub/spoke services is actually a special pattern of VPLS, whose MP2MP
nature will be persisted.
So they are very different as what Jeffrey has pointed out.
But the hub/spoke secenario is very similar to the AR REPLICATOR/LEAF, IMHO.
And draft-ietf-bess-evpn-virtual-hub already applied a certain extent of AR
REPLICATOR behaviors to the hub PEs.
The only issues remained in draft-ietf-bess-evpn-virtual-hub is that when RRs
exists between hub-PE and spoke-PEs.
If the AR REPLICATOR behaviors are removed from that draft,
I think the hub/spoke scenario can't be well supported because that the RRs are
widely used.
and the AR REPLICATOR behaviors will still be required even if there are no RRs.
And I think the approaches discribed in draft-wang-bess-evpn-context-label-04
can solve the problems caused by RR existence.
Best Regards,
Bob
原始邮件
发件人：Jeffrey(Zhaohui)Zhang <[email protected]>
收件人：Alexander Vainshtein
<[email protected]>;[email protected]
<[email protected]>;
抄送人：Michael Gorokhovsky <[email protected]>;[email protected]
<[email protected]>;
日 期 ：2020年08月20日 22:46
主 题 ：RE: Hub-and-spoke support in EVPN: RFC 8317
vs.draft-wang-bess-evpn-context-label-04
Hub and spoke EVPN and E-tree are different.
However, draft-ietf-bess-evpn-virtual-hub should address the following two at
least:
* MPLS EVPN can't support hub/spoke usecase, where the spoke PEs can
only connect to each other through the hub PE. Especially when at
least two of the spoke PEs are connected to a common route
reflector.
* MPLS EVPN can't work as an AR-REPLICATOR. Because the AR-
REPLICATOR will apply replication for the ingress AR-LEAF too.
But a packet shoud not be sent back to the AR-LEAF where it is
received from.
Jeffrey
Juniper Business Use Only
From: BESS <[email protected]> On Behalf Of Alexander Vainshtein
Sent: Thursday, August 20, 2020 9:36 AM
To: [email protected]
Cc: Michael Gorokhovsky <[email protected]>; [email protected]
Subject: [bess] Hub-and-spoke support in EVPN: RFC 8317 vs.
draft-wang-bess-evpn-context-label-04
[External Email. Be cautious of content]
Dear authors of draft-wang-bess-evpn-context-label-04,
Section 2 “Problem Statement” of draft-wang-bess-evpn-context-label-04 states
that “MPLS EVPN can't support hub/spoke use case, where the spoke PEs can only
connect to each other through the hub PE. Especially when at least two of the
spoke PEs are connected to a common route reflector”.
I have to admit that I do not understand why support of the generic E-Tree
functionality in EVPN defined inRFC 8317 is not sufficient for handling this
use case.
In particular I do not see why connection of Spoke PEs to a common RR affects
the EVPN behavior (or L3vPN Hub-and-Spoke VPN behavior as defined inSection
4.3.5 of RFC 4364) in any way.
Regards, and lots of thanks in advance,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: [email protected]
--------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of
Ribbon Communications Inc. that is confidential and/or proprietary for the sole
use of the intended
recipient. Any review, disclosure, reliance or distribution by others or
forwarding without express permission is strictly prohibited. If you are not
the intended recipient, please notify the sender immediately and then delete
all copies, including any attachments.
--------------------------------------------------------------------------------_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
