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

[wang.yubao2]

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 
收件人：王玉保10045807;bess@ietf.org ;
抄送人：张征7940;陈然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 
Sent: Thursday, August 20, 2020 9:52 PM
To: bess@ietf.org; Jeffrey (Zhaohui) Zhang ; 
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 
; 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 



收件人：Alexander Vainshtein 
;draft-wang-bess-evpn-context-la...@ietf.org
 ;



抄送人：Michael Gorokhovsky ;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 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 ;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 

[bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-18.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : BGP Control Plane for the Network Service Header in 
Service Function Chaining
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Jim Uttaro
  Luay Jalil
Filename: draft-ietf-bess-nsh-bgp-control-plane-18.txt
Pages   : 71
Date: 2020-08-21

Abstract:
   This document describes the use of BGP as a control plane for
   networks that support Service Function Chaining (SFC).  The document
   introduces a new BGP address family called the SFC Address Family
   Identifier / Subsequent Address Family Identifier (SFC AFI/SAFI) with
   two route types.  One route type is originated by a node to advertise
   that it hosts a particular instance of a specified service function.
   This route type also provides "instructions" on how to send a packet
   to the hosting node in a way that indicates that the service function
   has to be applied to the packet.  The other route type is used by a
   Controller to advertise the paths of "chains" of service functions,
   and to give a unique designator to each such path so that they can be
   used in conjunction with the Network Service Header defined in RFC
   8300.

   This document adopts the SFC architecture described in RFC 7665.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-18
https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-18


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-17.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : BGP Control Plane for the Network Service Header in 
Service Function Chaining
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Jim Uttaro
  Luay Jalil
Filename: draft-ietf-bess-nsh-bgp-control-plane-17.txt
Pages   : 71
Date: 2020-08-21

Abstract:
   This document describes the use of BGP as a control plane for
   networks that support Service Function Chaining (SFC).  The document
   introduces a new BGP address family called the SFC Address Family
   Identifier / Subsequent Address Family Identifier (SFC AFI/SAFI) with
   two route types.  One route type is originated by a node to advertise
   that it hosts a particular instance of a specified service function.
   This route type also provides "instructions" on how to send a packet
   to the hosting node in a way that indicates that the service function
   has to be applied to the packet.  The other route type is used by a
   Controller to advertise the paths of "chains" of service functions,
   and to give a unique designator to each such path so that they can be
   used in conjunction with the Network Service Header defined in RFC
   8300.

   This document adopts the SFC architecture described in RFC 7665.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-17
https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-17


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Jeffrey (Zhaohui) Zhang]

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 
Sent: Thursday, August 20, 2020 9:52 PM
To: bess@ietf.org; Jeffrey (Zhaohui) Zhang ; 
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 
; 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 mailto:zzh...@juniper.net>>
收件人：Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>;draft-wang-bess-evpn-context-la...@ietf.org
 
mailto:draft-wang-bess-evpn-context-la...@ietf.org>>;
抄送人：Michael Gorokhovsky 
mailto:michael.gorokhov...@rbbn.com>>;bess@ietf.org
 mailto: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 mailto: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 
mailto: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 

Re: [bess] Last Call: (Propagation of ARP/ND Flags in EVPN) to Proposed Standard

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Luc,

Thanks for your email.
I think having similar text in the abstract and beginning of the introduction 
is not uncommon, especially if it helps people to get the gist of the document 
just by reading the abstract.
Nevertheless we can make all the changes that help the readability during the 
IESG review.

Thanks.
Jorge

From: Luc André Burdet 
Date: Friday, August 21, 2020 at 5:29 AM
To: last-c...@ietf.org 
Cc: Bocci, Matthew (Nokia - GB) , Vigoureux, Martin 
(Nokia - FR/Paris-Saclay) , bess-cha...@ietf.org 
, draft-ietf-bess-evpn-na-fl...@ietf.org 
, bess@ietf.org 
Subject: Re: [bess] Last Call:  
(Propagation of ARP/ND Flags in EVPN) to Proposed Standard
Hi,

Apologies for writing only during WGLC, I am only just becoming familiar with 
this draft.

I find the Abstract and Introduction are repetitive (copy paste).
Would the authors consider shortening/rewriting the Abstract, in favour of the 
Introduction, to remove the duplication?

Regards,
Luc André

Luc André Burdet |  Cisco  |  laburdet.i...@gmail.com  |  Tel: +1 613 254 4814


On 2020-08-14, 12:00, "BESS on behalf of The IESG"  wrote:


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'Propagation of ARP/ND Flags in EVPN'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2020-08-28. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the 
beginning
of the Subject line to allow automated sorting.

Abstract


   An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or
   IPv6 addresses associated with a MAC address.  Remote PEs can use
   this information to populate their ARP/ND tables on IRB interfaces or
   their proxy-ARP/ND tables in Broadcast Domains (BD).  PEs can then
   reply locally (act as an ARP/ND proxy) to IPv4 ARP requests and IPv6
   Neighbor Solicitation messages and reduce/suppress the flooding
   produced by the Address Resolution procedure.  However, the
   information conveyed in the MAC/IP route may not be enough for the
   remote PE to reply to local ARP or ND requests.  For example, if a PE
   learns an IPv6->MAC ND entry via EVPN, the PE would not know if that
   particular IPv6->MAC pair belongs to a host, a router or a host with
   an anycast address, as this information is not carried in the EVPN
   MAC/IP Advertisement routes.  Similarly, other information relevant
   to the IP->MAC ARP/ND entries may be needed.  This document defines
   an Extended Community that is advertised along with an EVPN MAC/IP
   Advertisement route and carries information relevant to the ARP/ND
   resolution, so that an EVPN PE implementing a proxy-ARP/ND function
   can reply to ARP Requests or Neighbor Solicitations with the correct
   information.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-na-flags/



No IPR declarations have been submitted directly on this I-D.





___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess