[bess] Some questions on the  comparisons on PBB-EVPN (RFC7623)  and VXLAN EVPN

Hi folks, I have some questions on EVPN, would you kindly help to get an answer? Here are the questions: 1）The PBB EVPN per RFC7623 is defined in MPLS network only. and it seems that the PBB EVPN in VXLAN network or SRv6 network is not defined yet, so my question is how

Re: [bess] Some questions on E-Tree (RFC8317)  services with VXLAN Encapsulation: is it feasible? is it necessary? is it under  definition already?

Thanks for your explanations. So the extensions is based on GENEVE and RFC8317, Glad to see your working on EVPN extensions for GENEVE in the future. I have mixed GENEVE with VXLAN, and I didn't see a leaf-label extension in GENEVE, so I asked the question. I get the point now, Best

Re: [bess] Some questions on E-Tree (RFC8317)  services with VXLAN Encapsulation: is it feasible? is it necessary? is it under  definition already?

Thanks for your explanations. So the extensions is based on GENEVE and RFC8317, Glad to see your working on EVPN extensions for GENEVE in the future. I have mixed GENEVE with VXLAN, and I didn't see a leaf-label extension in GENEVE, so I asked the question. I get the point now, Best

Re: [bess] Some questions on E-Tree (RFC8317)  services with VXLAN Encapsulation: is it feasible? is it necessary? is it under  definition already?

Thanks for your explanations. So the extensions is based on GENEVE and RFC8317, Glad to see your working on EVPN extensions for GENEVE in the future. I have mixed GENEVE with VXLAN, and I didn't see a leaf-label extension in GENEVE, so I asked the question. I get the point now, Best

Re: [bess] Some questions on E-Tree (RFC8317)  services with VXLAN Encapsulation: is it feasible? is it necessary? is it under  definition already?

Thanks for your explanations. So the extensions is based on GENEVE and RFC8317, Glad to see your working on EVPN extensions for GENEVE in the future. I have mixed GENEVE with VXLAN, and I didn't see a leaf-label extension in GENEVE, so I asked the question. I get the point now, Best

Re: [bess] Some questions on E-Tree (RFC8317)  services with VXLAN Encapsulation: is it feasible? is it necessary? is it under  definition already?

Hi Adrian, Thanks for your detailed specification!O(∩_∩)O~ Your reply is exactly what I want to express. I suggest to define a B flag for the SRP in PCInitiate message too. Hope PCE-GMPLS draft could take it into consideration. And thanks Dhruv for the help!O(∩_∩)O~ Best Regards, Quan

Re: [bess] Some questions on E-Tree (RFC8317)  services with VXLAN Encapsulation: is it feasible? is it necessary? is it under  definition already?

Thanks for your explanations. So the extensions is based on GENEVE and RFC8317, Glad to see your working on EVPN extensions for GENEVE in the future. I have mixed GENEVE with VXLAN, and I didn't see a leaf-label extension in GENEVE, so I asked the question. I get the point now, Best

Re: [bess] Some questions on E-Tree (RFC8317)  services with VXLAN Encapsulation: is it feasible? is it necessary? is it under  definition already?

Hi Adrian, Thanks for your detailed specification!O(∩_∩)O~ Your reply is exactly what I want to express. I suggest to define a B flag for the SRP in PCInitiate message too. Hope PCE-GMPLS draft could take it into consideration. And thanks Dhruv for the help!O(∩_∩)O~ Best Regards, Quan

Re: [bess] [ALU] Some questions about PBB EVPN (RFC7623)

Hi Jorge, Thank you very much for your help. I am still not sure about my understanding about Question 2. Please see if my understanding is correct. > Question 2: > > RFC 7623 6.2.2.1. says that: > > In the case where per-I-SID load-balancing is desired among

[bess] [BESS] Discussions about DF-election FSM.

Hi Jorge, I read the draft-ietf-bess-evpn-df-election-framework-08 and find it seemed not clear in the DF election FSM . I didn't find clear explanation about when to advertise the ES route(RT-4) according to the FSM. I think it is the DF_TIMER (not ES_UP) event that triggers the

[bess] [BESS] Discussions on modulus-based DF Alg with AC-DF=1

Hi Jorge, I am not sure about my understanding about modulus-based DF Alg with AC-DF=1. I think the modulus is per VLAN basis in the usecase, which means that each VLAN has an independent modulus and an independent candidate list. Is that right? It is described in

Re: [bess] [BESS] Discussions about DF-election FSM.

I agree with you with that it is literally clear in RFC7432. So the DF timer in RFC7432 and draft-ietf-bess-evpn-df-election-framework is the same timer, And it's only used to collect the remote routes for the same ES (but delay the usage of them) , So the timer is not used in the

[bess] [BESS] A few comments on draft-ietf-bess-evpn-yang-07

Hi everyone, 1) I think the choice node named "ac-or-pw" gives up the probability to support vES and I-ESI +--rw ethernet-segments +--rw ethernet-segment* [name] +--rw (ac-or-pw)? | +--:(ac) | | +--rw ac*

Re: [bess] EVPN Multihoming and Symmetric IRB

Hi Muthu, Please see in line with the label "[Bob]". Regards, Bob 原始邮件 发件人：MuthuArulMozhiPerumal 收件人：王玉保10045807; 抄送人：bess@ietf.org ; 日 期 ：2019年04月25日 14:08 主 题 ：Re: [bess] EVPN Multihoming and Symmetric IRB Hi Bob, Thanks for your response. Please see

[bess] An use-case that RFC 8584 (EVPN DF Framework)  works not so well and its solution .

Hi everyone, I reviewed the draft-09 of RFC 8584 a few days ago, and found that the DF Election FSM can't work well after the ES goes UP for the second time. I described it in detail in this mail: https://mailarchive.ietf.org/arch/msg/bess/9fK2HHdish3b5Hosa5ZU4NKwX7o And I think the

[bess] An use-case that RFC 8584 (EVPN DF Framework)  works not so well and its solution .

Hi everyone, I reviewed the draft-09 of RFC 8584 a few days ago, and found that the DF Election FSM can't work well after the ES goes UP for the second time. I described it in detail in this mail: https://mailarchive.ietf.org/arch/msg/bess/9fK2HHdish3b5Hosa5ZU4NKwX7o And I think the

Re: [bess] [Mail regarding rfc7432]Could you clarify which IP address we use to construct P2P tunnel for ingress replication.

Hi Yang Huang, It is clear that the received ORIP (Originating Router's IP in IMET route） technically can't be used to construct P2P tunnel for ingress replication as it is pointed out by Jorge , especially in the Option B usecase. But when the BGP next hop and the PMSI tunnel

[bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-00 and/or draft-ietf-bess-evpn-inter-subnet-forwarding

Hi Ali and everyone, I reviewed the [EVPN IP Aliasing] draft and found that it conflicts with draft-ietf-bess-evpn-inter-subnet-forwarding-05 in MPLS encapsulation. draft-sajassi-bess-evpn-ip-aliasing-00 section 2.1 Constructing Ethernet A-D per EVPN Instance Route ... ...

[bess] [BESS] Conflicting rules among the Yang models on the association between IRB/AC interface and IP-VRF/MAC-VRF instance.

Hi all, I find some conflicting rules about interface-to-VRF binding between draft-ietf-rtgwg-ni-model-12 and draft-ietf-bess-l2vpn-yang-09.txt. It is as below: RULE1: [NI-model] Section 3.2 says that: The bind-network-instance-name leaf provides the association between an

Re: [bess] EVPN Multihoming and Symmetric IRB

Hi Muthu and everyone else, The IP Aliasing in Symmetric IRB is described in draft-sajassi-bess-evpn-ip-aliasing-00 . It works well for each local host learned on the IRB interface. I think when the IRB interface itself is configured with an anycast Gateway IP-address for its

Re: [bess] [BESS] Conflicting rules among the Yang models on the association between IRB/AC interface and IP-VRF/MAC-VRF instance.

Hi all, I find some conflicting rules about interface-to-VRF binding between RFC8529 and draft-ietf-bess-l2vpn-yang-09.txt. Thanks Acee for reminding me to check the changes in the new version of these documents. And I update the original mail as below after the checking:

[bess] Comments on the ND refresh message in draft-ietf-bess-evpn-proxy-arp-nd-08

Hi Jorge, The ND refresh message is assumed to be a NS message with its Sender's IP = Link Local Address in section 4.4 of draft-ietf-bess-evpn-proxy-arp-nd-08. An ARP refresh issued by the PE will be an ARP-Request message with the Sender's IP = 0 sent from the

[bess] Review of draft-ietf-bess-l2vpn-yang-10

Hi authors, I reviewed the draft and I have a question on the endpoint with the choice of "ac" case. When we configure the "ac" case of the "endpoint" node according to this draft, is it still necessary or not for us to configure the "bind-network-instance-name" leaf of the

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

Hi Jeffrey, Sorry for the delaying. Please see [Bob2] below. Thanks, Bob 原始邮件 发件人：Jeffrey(Zhaohui)Zhang 收件人：王玉保10045807; 抄送人：alexander.vainsht...@rbbn.com ;陈然00080434;张征7940;bess@ietf.org ; 日 期 ：2020年08月25日 00:28 主 题 ：RE: Re:[bess] Hub-and-spoke

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

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

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

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

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

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

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? The

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

Please se in line. 原始邮件 发件人：Jeffrey(Zhaohui)Zhang 收件人：王玉保10045807; 抄送人：alexander.vainsht...@rbbn.com ;陈然00080434;张征7940;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,

Re: [bess] [**EXTERNAL**] Re: Issues w/ draft-boutros-bess-elan-services-over-sr

Hi Ali and Sami, I read the list of your discussions in the mail list, and I have some understandings on the topic. I hope these understandings can be helpful to move the discussion further. I think the "PBB EVPN over SRv6 underlay" solution will be complex, if we address too

[bess] Fw:New Version Notification for draft-wang-bess-evpn-cmac-overload-reduction-02.txt

Hello All, I submitted a draft to propose an approach to improve EVPN high scalability, faster network convergence, and reduced operational complexity, we call it light-weighted EVPNs because of these advantages. The newest update of it can be found at

Re: [bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-02

Hi Jorge, I still don't agree that the procedures on Leaf-5 are already in draft-ietf-bess-evpn-prefix-advertisement-11. Note that the key of RT1 route is , not just . Take the DGW1 of the Bump-in-the-wire use case for example, If the DGW1 receives a RT-5 route R5 (IPL=24,

[bess] Comments on  draft-ietf-bess-evpn-prefix-advertisement

Hi Jorge, In our discussion in another thread, we discussed two types ot the use cases of draft-ietf-bess-evpn-prefix-advertisement, They are the GW-IP as overlay index use cases (just let me call them GW-IP-Style use-cases for short) and the Bump-in-the-wire use case. I think it is

Re: [bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-02

Hi Jorge, I don't agree with you for that the recursive resolution for such ESI overlay index is already there. Current recursive resolution is very different from such ESI overlay index. Please see in-line with [Yubao]. Thanks, Yubao 原始邮件

Re: [bess] Comments on  draft-ietf-bess-evpn-prefix-advertisement

Hi Jorge, Thank you for your email. I know that EVPN application will pick up one. But my question is how can you make sure that the exact one in your expectation will be picked out? Other scenarios just need to pick up one for all RT-2 routes that refers to that ESI, but the

Re: [bess] Query about Ethernet Tag Id for TYpe-5 routes (RFC 9136)

Hi Jorge and Vinayak, I don't understand this use case of RFC9136 very well either, because when a BD of VLAN-aware bundle EVI is used in Bump-in-the-wire use case, I don't sure how the IP prefixes routes are recursively rosolved. I hope to share my understandings to help to make

Re: [bess] Questions on draft-sajassi-bess-evpn-ip-aliasing-03

Hi Jorge, please see in-line with [Yubao2] 原始邮件 发件人：Rabadan,Jorge(Nokia-US/MountainView) 收件人：王玉保10045807; 抄送人：bess@ietf.org; 日 期 ：2021年11月09日 20:23 主 题 ：Re: Questions on draft-sajassi-bess-evpn-ip-aliasing-03 Hi Yubao, Please see in-line. Thanks. Jorge

Re: [bess] Comments on  draft-ietf-bess-evpn-prefix-advertisement and draft-wang-bess-evpn-distributed-bump-in-the-wire

Hi Jorge, Please see in-line with [yubao]. Thanks Yubao 原始邮件 发件人：Rabadan,Jorge(Nokia-US/MountainView) 收件人：王玉保10045807; 抄送人：bess@ietf.org; 日 期 ：2021年11月12日 04:06 主 题 ：Re: Re:Comments on draft-ietf-bess-evpn-prefix-advertisement and

Re: [bess] Questions on draft-sajassi-bess-evpn-ip-aliasing-03

Hi Jorge, Please see my comments with [Yubao3]. Thanks Yubao 原始邮件 发件人：Rabadan,Jorge(Nokia-US/MountainView) 收件人：王玉保10045807; 抄送人：bess@ietf.org; 日 期 ：2021年11月12日 03:43 主 题 ：Re: Re:Questions on draft-sajassi-bess-evpn-ip-aliasing-03 Hi Yubao, Please see my

Re: [bess] Comments on  draft-ietf-bess-evpn-prefix-advertisement and draft-wang-bess-evpn-distributed-bump-in-the-wire

Hi Jorge, Please see in-line with [yubao]. Thanks Yubao 原始邮件 发件人：Rabadan,Jorge(Nokia-US/MountainView) 收件人：王玉保10045807; 抄送人：bess@ietf.org; 日 期 ：2021年11月13日 03:00 主 题 ：Re: Re:Comments on draft-ietf-bess-evpn-prefix-advertisement and

Re: [bess] Questions on draft-sajassi-bess-evpn-ip-aliasing-03

Hi Jorge, Thanks for your response. If the use case b's route advertisement details are clearly described, It will not be confusing just because of what it is called. It is confusing just because its own RT-5 route advertisement is not clear while the refered route advertisement and

[bess] Questions on draft-sajassi-bess-evpn-ip-aliasing-03

Hi Jorge, I read the draft, and have the following questions: 1) on section 1.2 Inter-subnet Forwarding for Prefix Routes in the Interface-less IP-VRF-to-IP-VRF Model The RT-1 per EVI route of ESI1 in Figure 2 is not an IP A-D per EVI route, but a normal Ethernet

Re: [bess] Contradiction for the RFC 7432 definition of the fast convergence (withdrawal) for single-homed CEs

Hi Eduard, I am not saying that the mass-withdraw for single-homed ES don't have any benifits. What I have noticed is that when we extend a mass-withdraw feature for single-homed ES, the route resolution for zero ESI RT-2 can not be simply updated, if those updates would exclude current

Re: [bess] Query about Ethernet Tag Id for TYpe-5 routes (RFC 9136)

Hi Vinayak, The Bump-in-the-wire with a VLAN-aware BD is just slightly implied in the terminlogy section of RFC9136. It is not mentioned in the main body of RFC9136. So a few critical details are still absent, while there may be already different implementations up to now, I think

Re: [bess] Contradiction for the RFC 7432 definition of the fast convergence (withdrawal) for single-homed CEs

Hi Eduard, I don't think an Ethernet A-D per ES route with a zero ESI is better to use, Because each single-homed CE is an individual ES, that's why MAC mobility happens between two zero ESIs (for different single-homed ethernet segments) but not happens between the same ESI (local

Re: [bess] Contradiction for the RFC 7432 definition of the fast convergence (withdrawal) for single-homed CEs

Hi Eduard, It is just a configuration-decision whether to configure a single-homed ES with a non-zero ESI, thus it is not RFC violation from the viewpoint of the implementation. But if the RT-2 routes whose ESI is zero will not be installed unless there is an Ethernet A-D per ES route

Re: [bess] Contradiction for the RFC 7432 definition of the fast convergence (withdrawal) for single-homed CEs

Hi Eduard, I just haven't noted that in RFC7432 a RT-1 per ES/EVI (with ESI=0) route should be advertised for each single-homed ES. RFC7432 just says that all RT-2 routes of a single-homed ES should be advertised with ESI=0, and then it MUST be installed into the dataplane based on

[bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-02

Hi Jorge, This is the detailed explanation of the question I asked in the IETF 111 meeting. In page 7 of slides-111-bess-sessa-evpn-ip-aliasing, when leaf-5 send traffic to leaf-2, how does leaf-2 find the corresponding ARP entry for 20.0.0.2 or 20.0.0.1 or 20.1.1.3 ? I guess the

Re: [bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-02

Hi Jorge, Thanks for your email, but I still don't understand why an ESI is needed here. I know there is a static-route 1.1.1.1 on Leaf-2, but my question is that how leaf-2 knows the overlay nexthop of 50.0.0.0/24 is 1.1.1.1 (by which that ARP entry is found out at last)? As you

Re: [bess] Comments on draft-sajassi-bess-evpn-ip-aliasing-02

Hi Jorge, Please see in-line with [Yubao_2]. Thanks, Yubao 原始邮件 发件人：Rabadan,Jorge(Nokia-US/MountainView) 收件人：王玉保10045807; 抄送人：bess@ietf.org; 日 期 ：2021年07月28日 18:18 主 题 ：Re: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02 Hi Yubao, Please see in-line

Re: [bess] [Idr] Review request for draft-ietf-bess-srv6-services-11

Hi Ketan， Thanks for your reply, Please see inline below. Thanks Yubao 原始邮件 发件人：KetanTalaulikar 收件人：王玉保10045807; 抄送人：draft-ietf-bess-srv6-servi...@ietf.org;BESS; 日 期 ：2022年03月04日 14:08 主 题 ：Re: [bess] [Idr] Review request for draft-ietf-bess-srv6-services-11 Hi

[bess] Comments on L2-Attr Extended Community of draft-ietf-bess-rfc7432bis-04

Hi authors, I read draft-ietf-bess-rfc7432bis-04 and I have the follwing questions and comments: 1) In section 7.11.1, F bit (flow label capability) of L2 Attr Extended Community is conveyed in Inclusive Multicast routes only, and F bit will not be conveyed in Etherne A-D per EVI

[bess] Questions on rfc7432

Hi authors, In RFC7432, when an IMET route is sent, how to set the Tunnel Identifier of its PMSI tunnel is clearly described. But when that IMET route (whose tunnel type is Ingress Replication) is received, it seems that there are no explicit descriptions about how to determine the

Re: [bess] Comments on L2-Attr Extended Community of draft-ietf-bess-rfc7432bis-04

Hi authors, I also have some other comments on draft-ietf-bess-rfc7432bis-04, they are about entropy label, flow label and control word, maybe some of them are also related to the OPE TLV of draft-heitz-bess-evpn-option-b or RFC7447. 5) Is the entropy label in the

Re: [bess] [Idr] Review request for draft-ietf-bess-srv6-services-11

Hi authors, I reviewed this draft and I don't understand this sentence very well: "The SRv6 Endpoint behavior of the Service SID thus signaled is entirely up to the originator of the advertisement" Is it saying that when PE1 receives an Ethernet A-D per ES route whose SRv6 SID

Re: [bess] [Idr] Review request for draft-ietf-bess-srv6-services-11

Hi Ketan, Thanks for your clarification. It's very clear now in that update. After read the new version, now I have other questions: When an ASBR receives a L3VPN route along with an implicit-null MPLS label, and that ASBR doesn't recognize the SRv6-specific TLVs, Is there a risk

Re: [bess] [Idr] Review request for draft-ietf-bess-srv6-services-11

Thank you for your reply. I have missed this paragraph. That section have described it already. 原始邮件 发件人：KetanTalaulikar 收件人：王玉保10045807; 抄送人：draft-ietf-bess-srv6-servi...@ietf.org;BESS; 日 期 ：2022年03月20日 14:59 主 题 ：Re: [bess] [Idr] Review request for

[bess] Whether the TC/S field of the ESI label field can be used to carry a portion of Arg.FE2 according to draft-ietf-bess-srv6-services-15 ?

Hi authors, There may be conflicting description in draft-ietf-bess-srv6-services-15#section-6.1.1 on the usage of Transposition Length. The 24-bit ESI label field of the ESI label extended community carries the whole or a portion of the Argument part of the SRv6 SID

Re: [bess] Whether the TC/S field of the ESI label field can be used to carry a portion of Arg.FE2 according to draft-ietf-bess-srv6-services-15 ?

Hi Ketan, Thanks for your clarifications. But I still don't notice that RFC7432 has said that the label value is 24 bits, I just found these paragraphs in RFC7432 or rfc7432bis: The MPLS Label1 field is encoded as 3 octets, where the high-order 20 bits contain the label

Re: [bess] Whether the TC/S field of the ESI label field can be used to carry a portion of Arg.FE2 according to draft-ietf-bess-srv6-services-15 ?

Hi Ketan, Thanks for your further explanations. Please see in line with [Yubao2]. Thanks, Yubao 原始邮件 发件人：KetanTalaulikar 收件人：王玉保10045807; 抄送人：draft-ietf-bess-srv6-servi...@ietf.org;BESS; 日 期 ：2022年06月17日 15:44 主 题 ：Re: Whether the TC/S field of the ESI label field

Re: [bess] Whether the TC/S field of the ESI label field can be used to carry a portion of Arg.FE2 according to draft-ietf-bess-srv6-services-15 ?

Hi Ketan, Please see in line with [Yubao]. Thanks, Yubao 原始邮件 发件人：KetanTalaulikar 收件人：王玉保10045807; 抄送人：draft-ietf-bess-srv6-servi...@ietf.org;BESS; 日 期 ：2022年06月17日 13:33 主 题 ：Re: Whether the TC/S field of the ESI label field can be used to carry a portion of

[bess] Discussion about F (Flow label) bit of draft-ietf-bess-rfc7432bis  section 7.11

Hi all, The F bit is defined in EVPN L2-Attr extended community of draft-ietf-bess-rfc7432bis-07. When the RT-1 per EVI route including that L2-attr pass through a node which does not recognize a L2-attr EC, there will be two cases: Case1: that node change the MPLS label of that RT-1

Re: [bess] Discussion about F (Flow label) bit of draft-ietf-bess-rfc7432bis  section 7.11

Hi Jorge, Thank you for your response. I talk about EVPN VPLS per https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-07#name-evpn-layer-2-attributes-ext. That section of rfc7432bis extends L2-Attr EC (which is defined in EVPN VPWS) to EVPN VPLS. And my case 2 taks

Re: [bess] Discussion about F (Flow label) bit of draft-ietf-bess-rfc7432bis  section 7.11

Hi Jorge, The gateway in my previous mail is not a L3 gateway. We can take a virtual hub node of https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-virtual-hub-00 for an example, as I had mentioned in the previous mail. Such L2 gateway is a bit like the gateway of

Re: [bess] Questions on VLAN-based/VLAN-bundle Service Interface of rfc7432bis

Hi Ali, Thank you for your response. 1）If two VIDs on the same physical interface of an ES are getting mapped to BD1, but the is advertised via Eth AD per EVI route with Eth-tag of non-zero, can BD1 still be called as VLAN-bundle service interface? I think it is not VLAN-aware bundle

[bess] Questions on VLAN-based/VLAN-bundle Service Interface of rfc7432bis

Hi All, I have encountered a use case that I don't know if it's VLAN-based service interface or VLAN-bundle service interface. When two individual subinterfaces on the same ES are attached to the same BD which is the only one BD (whose Ethernet Tag ID is zero) of its EVI, which Service

Re: [bess] Discussion about F (Flow label) bit of draft-ietf-bess-rfc7432bis  section 7.11

Hi Jorge, Lots of thanks for your explanation. The IMET route will not be propagated so the F bit inside it will not be propagated even if the L2 attr is not recognised by the L2 gateway. But the flow label cannot be used for BUM packets, is this a design object to avoid some other

[bess] Discussion on draft-rabadan-bess-evpn-inter-domain-opt-b and draft-ietf-bess-evpn-virtual-hub.

Hi authors, I noticed that draft-rabadan-bess-evpn-inter-domain-opt-b tries to summarize the impact of the Inter-Domain Option-B connectivity in the EVPN procedures. And I noticed that, when there is an inter-domain option-b node between virtual hub nodes and virtual spoke nodes, how

Re: [bess] Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b

Hi Jorge, I think the description in draft-rabadan-bess-evpn-inter-domain-opt-b is OK. But I don't know why the RD of AD per ES route is limited to type 1 RD. That's why I talk about this together with rfc7432bis. If the scenario from draft-rabadan-bess-evpn-inter-domain-opt-b has shown

Re: [bess] [EXTERNAL] Re: Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b

Hi Sasha, Thanks for your helpful notes. There is only one method to determine the RD of A-D per ES routes in the original years of RFC7432, but now there are at least two methods to determine the RD of A-D per ES routes. If it is the only reason why RFC7432 restrict the RD of A-D per

Re: [bess] [EXTERNAL] Re:[EXTERNAL] Re: Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b

Hi Sasha, When a MAC-VRF use a type 1 RD, is it expected that the RD of the EVPN Instance has differnet RD on different PE? When a MAC-VRF use a type 2 RD, is it expected that the RD of the EVPN Instance has the same RD on different PE? In many deployment, whether the RD of the EVPN

Re: [bess] Discussion on draft-rabadan-bess-evpn-inter-domain-opt-b and draft-ietf-bess-evpn-virtual-hub.

Hi Jeffrey, Please see Yubao2> below. Thanks, Yubao 原始邮件 发件人：Jeffrey(Zhaohui)Zhang 收件人：王玉保10045807;draft-rabadan-bess-evpn-inter-domain-op...@ietf.org;draft-ietf-bess-evpn-virtual-...@ietf.org;jorge.raba...@nokia.com; 抄送人：bess@ietf.org; 日 期 ：2023年05月15日 22:18 主 题

[bess] Discussion on modulo-based DF-Election of draft-ietf-bess-rfc7432bis-07

Hi all, I noticed that the DF-election for VLAN-based/VLAN-bundle service interface has been modified in section 8.5 of rfc7432bis. "3. When the timer expires, each PE ... ... The ordinals are used to determine which PE node will be the DF for a given EVPN instance on the Ethernet

Re: [bess] [EXTERNAL] Re:[EXTERNAL] Re:[EXTERNAL] Re: Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b

Hi Sasha, I agree with you on the following: 1) in the case of EVPN, it is really important to guarantee that MAC-VRFs that locally represent the same EVI in different PEs are assigned with different RDs. 2) Type 1 RD is easier to achieve above goal, especially when the RD is

Re: [bess] Discussion on modulo-based DF-Election of draft-ietf-bess-rfc7432bis-07

Hi Jorge, Thanks for your explanation. I doubt that the meaning of Ethernet Tag is not consistent in rfc7432bis. There are some examples. 1) section 13.1 "If P2MP LSPs are being used, the packet MUST be sent on the P2MP LSP of which the PE is the root, for the associated with the

[bess] Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b

Hi Authors, It seems that draft-rabadan-bess-evpn-inter-domain-opt-b has conflicting discription with rfc7432 about the RD-type of AD per ES routes: Section 3.1.3 of draft-rabadan-bess-evpn-inter-domain-opt-b-00: "If that is the case, now the A-D per ES routes can use the route