Hi Jeffrey,
Sorry for the delaying.
Please see [Bob2] below.
Thanks,
Bob
原始邮件
发件人:Jeffrey(Zhaohui)Zhang <zzh...@juniper.net>
收件人:王玉保10045807;
抄送人:alexander.vainsht...@rbbn.com
<alexander.vainsht...@rbbn.com>;陈然00080434;张征00007940;bess@ietf.org
<bess@ietf.org>;
日 期 :2020年08月25日 00:28
主 题 :RE: Re:[bess] Hub-and-spoke
supportinEVPN:RFC8317vs.draft-wang-bess-evpn-context-label-04
Please see zzh2> below.
Juniper Business Use Only
From: wang.yub...@zte.com.cn <wang.yub...@zte.com.cn>
Sent: Monday, August 24, 2020 11:50 AM
To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>
Cc: alexander.vainsht...@rbbn.com; chen....@zte.com.cn;
ext-zhang.zh...@zte.com.cn <zhang.zh...@zte.com.cn>; bess@ietf.org
Subject: Re:[bess] Hub-and-spoke support
inEVPN:RFC8317vs.draft-wang-bess-evpn-context-label-04
[External Email. Be cautious of content]
Please se in line.
原始邮件
发件人:Jeffrey(Zhaohui)Zhang <zzh...@juniper.net>
收件人:王玉保10045807;
抄送人:alexander.vainsht...@rbbn.com
<alexander.vainsht...@rbbn.com>;陈然00080434;张征00007940;bess@ietf.org
<bess@ietf.org>;
日期:2020年08月24日
22:58
主题:RE: Re:[bess] Hub-and-spoke support
inEVPN:RFC8317vs.draft-wang-bess-evpn-context-label-04
Hi Bob,
Please see zzh> below.
Juniper Business Use Only
From:wang.yub...@zte.com.cn <wang.yub...@zte.com.cn>
Sent: Monday, August 24, 2020 8:30 AM
To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>
Cc: alexander.vainsht...@rbbn.com;
chen....@zte.com.cn;ext-zhang.zh...@zte.com.cn
<zhang.zh...@zte.com.cn>;bess@ietf.org
Subject: Re:[bess] Hub-and-spoke support in
EVPN:RFC8317vs.draft-wang-bess-evpn-context-label-04
[External Email. Be cautious of content]
Hi Jeffrey,
Thanks for your clearifications.
So the EVPN label reiceived from VH1 by a V-Spoke is not only an
upstream-assigned but also a downstream-assigned?
So, what value will the tunnel-type of PTA be assigned to? Ingress-Replication?
Assisted-Replication? P2MP?
Zzh> For MPLS, it’ll just be regular IR or P2MP. For VXLAN, [EVPN_AR]
procedures are used.
The [EVPN-virtual-hub] has no referrence to [EVPN AR], so I don't think it will
be Assisted-Replication.
But when a PE receives a IR-PTA or P2MP-PTA, I think it is not the standard
behavior for it to install the EVPN label both as an incomming-label and as an
outgoing-label.
It should be explicitly described (like the PED labels). And I don't see such
descriptions.
Zzh> If you mean detailed specification on exactly what needs to be done for
each route/PTA, it can be added. The descriptive text is already there on how
it works – the PED labels in v-hub’s IMET route is like regular IMET route’s
label but different PEs
will use a different corresponding label (from the PED attribute) to send
traffic.
[Bob] A single PED label is not enough, I mean the EVPN label.
the PED label is the inner label of the EVPN label.
The EVPN label should be installed both as an outgoing-label (for
flows to VH1) and as an incomming label(for flows from VH1), from the viewpoint
of V-Spoke.
Zzh2> Oh the spec does need to explicitly state that the PED labels are used as
EVPN labels (for multicast), as implied by the following text:
With [RFC 6514], a PED label may only
identify a PE but not a particular VPN. Here the PED label
identifies both the PE and a particular EVI/BD. A V-spoke programs
its context MPLS forwarding table for the V-hub to discard any
traffic with the PED label that the V-hub advertised for this V-
spoke, or pop other PED labels and direct traffic into a
corresponding EVI for L2 forwarding.
[Bob2] RFC7582 defines the original usage of PED labels, but the PED labels is
used for another purpose now,
Will the two usages conflict with each other?
Will the EVPN Hub/Spoke scenario and the RFC7582 scenario coexists in
the same service?
[Bob2] Another use case: When the vHub uses ingress-replication to forward BUM
packets to vSpokes,
The IMET route from the vHub will set Tunnel-Type=IR, and the EVPN
label of its PTA will be still carried.
If the vSpoke should not use the EVPN label of the PTA from the vHub,
I think it should be explicitly described.
Otherwise it is not clear that not both of the two EVPN labels will be
imposed at the same time.
[Bob2] The third use case: When the vHub uses P2MP tunnel to forward BUM
packets to vSpokes,
The PED Labels will be swapped on the stitching PE (similar to the SPE
of MSPW),
The label-swapping will be done both in the per-platform label space
(downstream-assigned label space) and in a context-label-space,
If there are some odinary MVPN service on the same physical nodes as
the Hub/Spoke services at the same time,
and the tunnel-type of these MVPN services is also P2MP,
The PTA labels of these MVPN services will also be swapped in a
context-label-space,
Could these two context-label-spaces actually be the same label space?
Note that many Target-PEs may share the same stitching PE,
All the context-label-spaces (for PED labels or MVPN labels) for these
Target-PEs requires a lot of label (of the same value as the upstream-assigned
PED labels or MVPN labels) in the per-platform label space,
It will be a great challenge for the label allocation.
I suggest that the label for receiving packets from vSpokes and the
label for sending packets to vSpokes should be advertised in different
attributes.
So that the stitching PEs can handle them independently.
Then I have other questions:
1) If the RRs(SPEs, to be precise) between the V-spokes and the V-Hub changed
the IMET route's nexthop to itself,
In what label space should the EVPN label be rewritten? In upstream-assigned
label space? or in downstream-assigned label space?
Zzh> RRs should not change the nexthops. If they are in the data path and do
change nexthop, they need to provide labels in their OWN label space. Those
labels are “upstream assigned” to PEs receiving relayed traffic, and
“downstream assigned” to themselves
when they receive traffic.
[Bob] But how does the SPE know it should do this when the tunnel-type is just
IR or P2MP?
Note that there will be no EVPN instance on the SPE.
so we should not expact that the configurations of EVPN instances will
help in this use case.
Note that the SPE can't do this when it receives a normal EVPN route
whose tunnel-type is just IR or P2MP.
Zzh2> If SPE does not have EVPN instances then it should NOT change the
protocol nexthop. I was assuming that the SPE (Spine PE?) is a hub and has
corresponding configurations.
[Bob2] The SPE here means "Swapping PE" or "Stitching PE" , by whom the BGP
nexthop is changed and the PSN tunnel is swapped. but no EVPN instances awared.
They just stitching two PSN tunnels via the swapping of VPN label.
It is service-agnostic, not service-aware.
After the rewriting, can they still be the same value?
so it is not simply the recever V-spoke's viewpoint,
it is a domain-wide consensus.
The PED labels can be treated in such way just because they shouldn't be
rewritten by the transit-SPEs,
but the EVPN labels should be rewritten.
They are very different in the signalling and data plane behaviors.
The V-spokes can be placed in different geographical position (e.g. two
overseas branches of the same company), they may be in different ASes.
Zzh> Please see “7.5. Multi-homing support”.
2) If the VS1 is an IPv4 node and VS2 is an IPv6 node,
How does the PED-labels-attribute carry the two PED labels?
Zzh> Not sure what you mean here.
[Bob] What I mean is in the following text of RFC6514:
... The attribute is also considered to be malformed if: (a) the PE
Address field is expected to be an IPv4 address, and the length of the
attribute is not a multiple of 7 or (b) the PE Address field is expected to
be an IPv6 address, and the length of the attribute is not a multiple of 19.
...zzh2> Do we already support mixed IPv4/IPv6 PEs (for underlay not overlay)?
[Bob2] I think different AS has different decisions. And the eastern side of a
stitching PE may be IPv4 domain, but the western side of a stitching PE may be
IPv6 domain.
Especailly in ingress replication use case. I think different vSpoke
may be in different AS too.
Zzh2> Jeffrey
Zzh> Jeffrey
Thanks,
Bob
原始邮件
发件人:Jeffrey(Zhaohui)Zhang <zzh...@juniper.net>
收件人:王玉保10045807;
抄送人:alexander.vainsht...@rbbn.com
<alexander.vainsht...@rbbn.com>;陈然00080434;张征00007940;bess@ietf.org
<bess@ietf.org>;
日期:2020年08月24日
18:13
主题:RE: Re:[bess] Hub-and-spoke support in
EVPN:RFC8317vs.draft-wang-bess-evpn-context-label-04
Hi Bob,
Whether a label is upstream-assigned or downstream assigned is from the view of
the receiving router. In this case, the labels are assigned by the v-hub, but
in case of IR traffic
from the v-spokes, the labels are downstream-assigned from the receiving v-hub
point of view; in case of P2MP traffic from the v-hubs, the labels are
upstream-assigned from the receiving v-spokes point of view.
A better way to look at this is actually whether a label in *incoming data
packet* is from this receiving
router’s own label space (notice that this includes DCB/SRGB/SRLB labels) or
from another router’s space. In the former case it is “downstream assigned” or
“from own space”. In the latter case, it is “upstream-assigned” or “from other
spaces”. Notice that
“from other spaces” is more appropriate than “upstream-assigned” because the
those labels are not necessarily assigned from the upstream/sending router’s
space but could be from another router’s space.
An example of “other space” instead of “sender’s space” is in RFC 6513 (not
6514):
11.2.2.
Using PE Distinguisher Labels
If a given P-tunnel is to be used to carry packets traveling along a
bidirectional C-tree, then, EXCEPT for the case described in Sections
11.1 and 11.2.3, the packets that travel on that P-tunnel MUST carry
a PE Distinguisher Label (defined inSection
4), using the
encapsulation discussed inSection
12.3.
When a given PE transmits a given packet of a bidirectional C-group
to the P-tunnel, the packet will carry the PE Distinguisher Label
corresponding to the partition, for the C-group's C-RPA, that
contains the transmitting PE. This is the PE Distinguisher Label
that has been bound to the Upstream PE of that partition; it is not
necessarily the label that has been bound to the transmitting PE.
Jeffrey
Juniper Business Use Only
From:wang.yub...@zte.com.cn <wang.yub...@zte.com.cn>
Sent: Sunday, August 23, 2020 10:23 PM
To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>
Cc: alexander.vainsht...@rbbn.com;
chen....@zte.com.cn;ext-zhang.zh...@zte.com.cn
<zhang.zh...@zte.com.cn>;bess@ietf.org
Subject: Re:[bess] Hub-and-spoke support in EVPN:
RFC8317vs.draft-wang-bess-evpn-context-label-04
[External Email. Be cautious of content]
Hi Jeffrey,
In the following text:
… In case of IR with MPLS unicast tunnels, VH1 must advertise different
labels to different PEs, so that it can identify the sending PE based on the
label in the traffic from a V-spoke.
That “different labels o” should be changed to “different PE distinguisher
labels to”.
And the same EVPN label is advertised to different V-spokes,
Then I still have a question:
Whe VH1 use P2MP tunnel to broadcast BUM packets to all the V-Spokes,
Is that EVPN label a downstream-assigned label?
or it is an upstream-assigned label?
Maybe I was confused by that "labels".
Thanks
Bob
原始邮件
发件人:Jeffrey(Zhaohui)Zhang <zzh...@juniper.net>
收件人:Alexander Vainshtein <alexander.vainsht...@rbbn.com>;王玉保10045807;
抄送人:陈然00080434;张征00007940;bess@ietf.org
<bess@ietf.org>;
日期:2020年08月24日
08:16
主题:RE: [bess] Hub-and-spoke support in EVPN:
RFC8317vs.draft-wang-bess-evpn-context-label-04
Hi Sasha, Bob,
In the following text:
… In case of IR with MPLS unicast tunnels, VH1 must advertise different
labels to different PEs, so that it can identify the sending PE based on the
label in the traffic from a V-spoke.
That “to” should be changed to “for”. Different labels are advertised in a PE
Distinguisher (PED) label attribute,
as explained in the third paragraph:
Notice that an "upstream-assigned" label used by a V-hub to send traffic
with on a P2MP tunnel to identify the source V-spoke is the same
"downstream-assigned" label used by the V-hub to receive traffic on the IR
tunnel from the V-spoke. Therefore, the same PED Label attribute serves two
purposes.
Jeffrey
Juniper Business Use Only
From: Alexander Vainshtein <alexander.vainsht...@rbbn.com>
Sent: Sunday, August 23, 2020 12:37 PM
To: wang.yub...@zte.com.cn; Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>
Cc: chen....@zte.com.cn; ext-zhang.zh...@zte.com.cn
<zhang.zh...@zte.com.cn>;bess@ietf.org
Subject: RE: [bess] Hub-and-spoke support in EVPN: RFC
8317vs.draft-wang-bess-evpn-context-label-04
[External Email. Be cautious of content]
Bob, Jeffrey and all,
Regarding the question “How does VH1 advertise many labels to a single RR with
the same NLRI?”
– my guess (FWIW) is that:
With IR each V-Spoke advertises its Type 3 EVPN route to V-Hub, so that V-Hub
is explicitly aware of each of its associated V-Spokes
V-Hub can then advertise the Unknown MAC Route (UMR) with the same MAC address
(00:00:00:00:00:00) but different IP addresses. in the Type 2 EVPN routes (and
different labels allocated per associated V-Spoke). As a consequence, these
routes would have different
NLRI and will all pass the RR.
One possibility is to use the IP address that identifies the specific V-Spoke
in the Type 3 EVPN route. In this case V-Spoke would receive all such routes
but select one that its own IP address
A better possibility would be for the V-Spoke to allocate a Route Import
Extended Community as defined in Section 7 of RFC 6514 and attach it to the
Type 3 EVPN route it advertises. In this case V-Hub would allocate a dummy IP
address (say from /127 subnet)
per each associated V-Spoke, use it in the UMR with the label for this V-Spoke
and attach the Route Import Extended Community advertised by the specific
V-Spoke to the UMR that is intended for this V-Spoke.
Neither of these options has been explicitly defined in theVirtual
Hub and Spoke in EVPN draft, and the draft has expired.
My 2c,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: alexander.vainsht...@ecitele.com
From: BESS <bess-boun...@ietf.org>On
Behalf Of wang.yub...@zte.com.cn
Sent: Saturday, August 22, 2020 6:39 AM
To: zzh...@juniper.net
Cc: chen....@zte.com.cn; zhang.zh...@zte.com.cn; bess@ietf.org
Subject: Re: [bess] Hub-and-spoke support in EVPN: RFC
8317vs.draft-wang-bess-evpn-context-label-04
Hi Jeffrey,
Maybe I was confused by the last mail.
Let's discuss it on the basis of the text of the [EVPN Virtual Hub] draft.
In section 7.1, it says that:
In case of IR with MPLS
unicast tunnels, VH1 must advertise different labels to different
PEs, so that it can identify the sending PE based on the label in the
traffic from a V-spoke.
I don't understand that sentence in the following questions:
1) How does VH1 advertise many labels to a single RR with the same NLRI?
2) How does the RR recognise that each (instead of only the recent one) of
these labels should be reflected?
3) Will the RR reflect all these labels to all V-Spokes?
4) Will each of the V-Spokes receive only the exact one (which is allocated for
that V-spoke by the VH1) of these labels from the same RR?
Thanks,
Bob
原始邮件
发件人:Jeffrey(Zhaohui)Zhang <zzh...@juniper.net>
收件人:王玉保10045807;bess@ietf.org <bess@ietf.org>;
抄送人:张征00007940;陈然00080434;
日期:2020年08月21日
23:33
主题:RE:
Re:Hub-and-spoke support in EVPN: RFC
8317vs.draft-wang-bess-evpn-context-label-04
Hi Bob,
*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.
What do you mean by*if*in the above statement? It is the designed behavior
with hub and spoke scenario – with that do you still think there is a problem?
RR is only used for route distribution and should not make any difference.
Thanks.
Jeffrey
Juniper Business Use Only
From:wang.yub...@zte.com.cn <wang.yub...@zte.com.cn>
Sent: Thursday, August 20, 2020 9:52 PM
To: bess@ietf.org; Jeffrey (Zhaohui) Zhang
<zzh...@juniper.net>;alexander.vainsht...@rbbn.com
Cc:
alexander.vainsht...@rbbn.com;draft-wang-bess-evpn-context-la...@ietf.org;michael.gorokhov...@rbbn.com;ext-zhang.zh...@zte.com.cn
<zhang.zh...@zte.com.cn>;chen....@zte.com.cn
Subject: Re:Hub-and-spoke support in EVPN: RFC 8317
vs.draft-wang-bess-evpn-context-label-04
[External Email. Be cautious of content]
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 <zzh...@juniper.net>
收件人:Alexander Vainshtein
<alexander.vainsht...@rbbn.com>;draft-wang-bess-evpn-context-la...@ietf.org
<draft-wang-bess-evpn-context-la...@ietf.org>;
抄送人:Michael Gorokhovsky <michael.gorokhov...@rbbn.com>;bess@ietf.org
<bess@ietf.org>;
日期: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 <bess-boun...@ietf.org>On
Behalf Of Alexander Vainshtein
Sent: Thursday, August 20, 2020 9:36 AM
To: draft-wang-bess-evpn-context-la...@ietf.org
Cc: Michael Gorokhovsky <michael.gorokhov...@rbbn.com>;bess@ietf.org
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: alexander.vainsht...@ecitele.com
--------------------------------------------------------------------------------
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
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess