Re: [bess] Hub-and-spoke support in EVPN: RFC8317vs.draft-wang-bess-evpn-context-label-04

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

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<https://tools.ietf.org/html/rfc6513#section-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 in Section 4<https://tools.ietf.org/html/rfc6513#section-4>), using the
   encapsulation discussed in Section 12.3<https://tools.ietf.org/html/rfc6513#section-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: [e-mail] <[e-mail]>
Sent: Sunday, August 23, 2020 10:23 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail] <[e-mail]>; [e-mail]
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 <[e-mail]<mailto:[e-mail]>>
收件人：Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>;王玉保10045807;
抄送人：陈然00080434;张征00007940;[e-mail] <[e-mail]<mailto:[e-mail]>>;
日 期 ：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 <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, August 23, 2020 12:37 PM
To: [e-mail]<mailto:[e-mail]>; Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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:

  1.  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
  2.  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<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bess-evpn-virtual-hub__;!!NEt6yMaO-gk!WKVkJ-irCOyTVP5djlQuIzgfXg66-SyCjLFitEIGM_8Xoc5v-qkB1_b0yaQUB5zS$> draft, and the draft has expired.

My 2c,
Sasha

Office: [phone]
Cell:      [phone]
Email:  [e-mail]<mailto:[e-mail]>

From: BESS <[e-mail]<mailto:[e-mail]>>On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Saturday, August 22, 2020 6:39 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
收件人：王玉保10045807;[e-mail] <[e-mail]<mailto:[e-mail]>>;
抄送人：张征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:[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, August 20, 2020 9:52 PM
To: [e-mail]<mailto:[e-mail]>; Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>;[e-mail]<mailto:[e-mail]>;[e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
收件人：Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;
抄送人：Michael Gorokhovsky <[e-mail]<mailto:[e-mail]>>;[e-mail] <[e-mail]<mailto:[e-mail]>>;
日期：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 <[e-mail]<mailto:[e-mail]>>On Behalf Of Alexander Vainshtein
Sent: Thursday, August 20, 2020 9:36 AM
To: [e-mail]<mailto:[e-mail]>
Cc: Michael Gorokhovsky <[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]>
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<https://urldefense.com/v3/__https:/clicktime.symantec.com/36xQigUG4RGdoD2wAe2KZmc6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.org*2Fhtml*2Frfc8317__*3B*21*21NEt6yMaO-gk*21QRZOPg7Or-dqLm0vGwqM2vyyPBISCyDo4uu4Jq2MEDW8fuSMZV6tLNIvZnaam81J*24__;JSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!WKVkJ-irCOyTVP5djlQuIzgfXg66-SyCjLFitEIGM_8Xoc5v-qkB1_b0yR6fkr9r$> 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<https://urldefense.com/v3/__https:/clicktime.symantec.com/3MMGdJCygJXKdNbkgQDnxRG6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.org*2Fhtml*2Frfc4364*2Asection-4.3.5__*3BIw*21*21NEt6yMaO-gk*21QRZOPg7Or-dqLm0vGwqM2vyyPBISCyDo4uu4Jq2MEDW8fuSMZV6tLNIvZunniYWF*24__;JSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!WKVkJ-irCOyTVP5djlQuIzgfXg66-SyCjLFitEIGM_8Xoc5v-qkB1_b0yZC6Hh8v$>) in any way.

Regards, and lots of thanks in advance,
Sasha

Office: [phone]
Cell:      [phone]
Email:  [e-mail]<mailto:[e-mail]>


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