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

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 11 Nov 2021 20:06:36 +0000

Hi Yubao,

I realized I did not respond to this (my apologies), and you reflected the same questions in your slides about draft-wang-bess-evpn-distributed-bump-in-the-wire during the BESS session.
I think it is okay if you want to describe a “distributed” bump-in-the-wire scenario, but I don’t understand why you need any new extension.

  *   In your slide 5, the RT5s can be resolved to the proper RT1, based on the ESI overlay index. The ESI is unique (cannot be configured in multiple ESes) and the RT1 for the ESI carries the route-target of the BD, hence you have all the information to resolve the RT5. What are you missing?

  *   In your slide 6 you have a use-case with two ACs in the same ESI23, and you seem to use the ethernet tag ID to encode the ACI. Can you not use a different virtual Ethernet Segment per BD instead, and use RT1s for each ESI? In that way you don’t need to use the ethernet-tag-id, which is used for vlan-aware-bundle in general.

Thanks.
Jorge

From: [email-masked] <[email-masked]>
Date: Friday, July 30, 2021 at 5:18 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: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 Bump-in-the-wire use case need to pick the exact one per each RT-5 route.

That's the difference.

In the example I have described , if the IP-VRF picks up the RT1 route R1_BD2<RD=BD-20, ESI23, 0>,

The data packets to SN1 will be sent over another BD (BD-20), and BD-20 can't reach SN1.

That's the problem.

Note that BD-20 and BD-10 are on the same ES but on different VLAN of that ES.

This problem requires the EVPN Application to use both R5's RD and ESI overlay index to ensure that only R1_BD1 will be picked out.

As far as I know, such approach has never been used in symmetric IRB, for ARP/ND tables and for interface-ful models up to now.

Whe should note that EVPN not only have port-based service interface, but also have VLAN-based service interface.

When the EVPN Instances on ESI23 uses VLAN-based service interface, and these BDs are integrated with the same Routing Instance (IP-VRF),

How can the IP-VRF pick out the exact one (behind which the prefix SN1 of that RT-5 lies there) from many RT-1 routes (one per BD) ?

Do you think that each one (if it is picked out) of them will reach SN1 ?

If anything about the problem statement is not clear, let me know where is it please.

This is the example (based on  Figure 7 of [IP Prefix Advertisement]<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-4.3> ) I have described for problem statement, I repeat it here:

"To be clear, If the DGW1 receives a RT-5 route R5 (IPL=24, IP=SN1, ESI=ESI23, from NVE2) and two RT1 routes R1_BD1<RD=BD-10, ESI23, 0> and R1_BD2<RD=BD-20, ESI23, 0>.

These two RT1 routes both can be imported into the same IP-VRF instance.

Which RT-1 route will  R5's ESI overlay index be resolved to?

The R1_BD1 or the R1_BD2 ?"

Thanks,

Yubao

原始邮件
发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：[email-masked];
日 期 ：2021年07月30日 21:47
主 题 ：Re: Comments on  draft-ietf-bess-evpn-prefix-advertisement
Hi Yubao,

For GW-IP overlay indexes, until the PE does not receive at least one RT2 for the GW-IP, you can’t resolve the RT5. If you receive multiple for the same IP with the same key, it is bgp best path selection. If you receive multiple for the same IP, different key, the EVPN application picks up one. Implementations have been doing that selection for symmetric IRB, for ARP/ND tables and for interface-ful models for years, why is it a problem.

Similar for ESI as overlay index.

Thanks.

Jorge

From: [email-masked] <[email-masked]>
Date: Friday, July 30, 2021 at 5:01 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: 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 better to discuss it more clearly in a new thread.

1) For the GW-IP-Style use cases, thank you for telling me that the following text may be contradictory (But I don't think it is like that, I will explain it later)  with my approach :

     ". If the RT-5 specifies a GW IP address as the Overlay Index,

       recursive resolution can only be done if the NVE has received and

       installed an RT-2 (MAC/IP route) specifying that IP address in

       the IP address field of its NLRI."

     It seems that we have to find out that RT-2 before the recursive resolution.

     I just don't know that how can we know there is such a RT-2 before the recursive resolution ?

    We should note that the keys of that RT-2 is <RD, IP, MAC>, but the GW-IP is just an IP.

    So how can we find out that RT-2 just using an IP before the recursive resolution?

2) For the ESI as overlay index use cases, there is similar text as the following:

                 ". If the RT-5 specifies an ESI as the Overlay Index, recursive

                 resolution can only be done if the NVE has received and installed

                an RT-1 (Auto-Discovery per-EVI) route specifying that ESI."

Given that the keys of RT-1 are <RD, ESI, Ethernet Tag ID>,

So how can we find out that RT-2 before recursive resolution just using <ESI, Ethernet Tag ID> ?

3) For Bump-in-the-wire use case, we would find many RT-1 routes for that ESI even after the recursive rosolution.

    Just take the Figure 7 of [IP Prefix Advertisement]<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-4.3> for example,

    How can DGW1 in that Figure find out the exact RT-1 of <ESI23, BD-10> ?

    We should note that the RDs of BDs are different from the RD of that IP-VRF.

   To be clear, If the DGW1 receives a RT-5 route R5 (IPL=24, IP=SN1, ESI=ESI23, from NVE2) and two RT1 routes R1_BD1<RD=BD-10, ESI23, 0> and R1_BD2<RD=BD-20, ESI23, 0>.

  These two RT1 routes both can be imported into the same IP-VRF instance.

  Which RT-1 route will  R5's ESI overlay index be resolved to?

  The R1_BD1 or the R1_BD2 ?

4) For Bump-in-the-wire use case, Both of NVE2 and NVE3 will advertise a RT-5 route to DGW1,

     Will the common ESI23 of these two RT-5 routes be resolved to the same RT-1 route? and how?

     Note that even the RD of BD-10 will be different on NVE2 and NVE3.

     When they are the same RD,I think there wil be method that the RT-5 from NVE3 can be resolved to the same RT-1 from NVE2.

5) For Bump-in-the-wire use case, If NVE3 advertise another RT-5 route R5b for another BD (say BD-20) but for the another prefix (e.g. SN2) of the same IP-VRF.

     If the RD of that R5b is the same as R5 (see question 3), will the ESI23 of R5b be resolved to the same RT-1 as what R5 will be resolved to?

     It seems that they will,  according current procedures. But is this result in expectation ?

     Note that ESI23 is provisioned on attachment ports, but both BD-10 and BD-20 can have an separate AC on the same port.

Regards,

Yubao

---

From: <[email-masked]>
Date: Fri, 12 Nov 2021 15:04:15 +0800 (CST)

Hi Jorge,

Please see in-line with [yubao].

Thanks

Yubao

原始邮件

发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：[email-masked];
日 期 ：2021年11月12日 04:06
主 题 ：Re: Re:Comments on  draft-ietf-bess-evpn-prefix-advertisement and draft-wang-bess-evpn-distributed-bump-in-the-wire 

Hi Yubao,

[Yubao] Thanks for your response, I will explain why we need the Supplementary Overlay Index (or the ACI-specific Ethernet A-D mode) in the following.

In your slide 5, the RT5s can be resolved to the proper RT1, based on the ESI overlay index. The ESI is unique (cannot be configured in multiple ESes) and the RT1 for the ESI carries the route-target of the BD, hence you have all the information to resolve the RT5. What are you missing?

[Yubao] In my slide 5, I mainly wan't to say that, when there are two Bump-in-the-wire instances in the same IP-VRF,

        Those RT-5 routes don't known which source MAC should their corresponding data packets be encapsulated with, 

        even if their ESI are different.

        The notes2 in slide 5 is mainly talking about the use case of slide 6.

        But Those RT-5 routes don't known inside which BD should their ESI be resolved either, even if their ESI are different.

        So I put it together with notes1 in the slide 5, but I have no time to explain the reasons in the prensetation.

        So, as I explained above, the information is not enough even if their ESI are different, that's why we let the RT5 routes carry the export Router-Targets of the BD/SBD.

        Please note that in slide 5, there are no SBD. Those RT-1 per EVI routes will be imported into BD-10 or BD-20 respectively.

[Yubao] Some paragraphs from RFC9136 section 4.3 Bump-in-the-wire may help us to understand this:

        *  The IP packet destined to IPx is encapsulated with:

           -  Inner source MAC = IRB1 MAC.

           -  Inner destination MAC = M2 (this MAC will be obtained from

              the EVPN Router's MAC Extended Community received along

              with the RT-5 for SN1).  Note that the EVPN Router's MAC

              Extended Community is used in this case to carry the TS's

              MAC address, as opposed to the MAC address of the NVE/PE.

           -  Tunnel information for the NVO tunnel is provided by the

              Ethernet A-D route per EVI for ESI23 (VNI and VTEP IP for

              the VXLAN case).

In your slide 6 you have a use-case with two ACs in the same ESI23, and you seem to use the ethernet tag ID to encode the ACI. Can you not use a different virtual Ethernet Segment per BD instead, and use RT1s for each ESI? In that way you don’t need to use the ethernet-tag-id, which is used for vlan-aware-bundle in general.

[Yubao] We can't use different vES per BD instead, because we can't assume that BD-10 and BD-20 is always a new BD, which is created after draft-wang-bess-evpn-distributed-bump-in-the-wire.

        These BDs may be already there for a long time before they will be given a virtual-appliance (VA1 or VA2) who will make them become to BDs of bump-in-the-wire instances in the future.

        So, before the evolution, they have nothing different from normal BDs, I don't think there are any motivations for them to be deployed in the form of vES other than a normal ESI.

        The vESes have other disadvantages, for example, the RT-4 routes will be increased. the service carving will be complicated, the management will be complicated, etc.

Thanks.

Jorge

 

 

Hi Jorge,

That's the difference.

That's the problem. 

 

 

 

This is the example (based on  Figure 7 of [IP Prefix Advertisement] ) I have described for problem statement, I repeat it here:

 

Thanks,

Yubao

原始邮件

收件人：王玉保10045807;

抄送人：[email-masked];

日 期 ：2021年07月30日 21:47

Hi Yubao,

Thanks.

Jorge

 

 

Hi Jorge,

 

 

 

 

    Just take the Figure 7 of [IP Prefix Advertisement] for example, 

 

 

 

Regards,

Yubao

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 12 Nov 2021 12:57:15 +0000

Hi Yubao,

Thanks for explaining, although I’m afraid we disagree on both things 😊 but that’s ok. Others can chime in as well.

  *   If you receive an RT1 with ESI-1 and a route-target identifying BD1, the RT5 with ESI-1 can be resolved to the RT1, hence the traffic will use the IRB connected to BD1 (and the MAC of the IRB as MAC SA). You have all the information, so it is up to the implementation how to use it or if it can use it.
  *   I also disagree with the reasons you give to not use a virtual ES. The virtual ES spec is implemented and deployed for a long time now.
Thanks.
Jorge

From: [email-masked] <[email-masked]>
Date: Friday, November 12, 2021 at 8:04 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re:Comments on  draft-ietf-bess-evpn-prefix-advertisement and draft-wang-bess-evpn-distributed-bump-in-the-wire

Hi Jorge,

Thanks

Yubao

原始邮件

·         In your slide 5, the RT5s can be resolved to the proper RT1, based on the ESI overlay index. The ESI is unique (cannot be configured in multiple ESes) and the RT1 for the ESI carries the route-target of the BD, hence you have all the information to resolve the RT5. What are you missing?

              the VXLAN case).

·         In your slide 6 you have a use-case with two ACs in the same ESI23, and you seem to use the ethernet tag ID to encode the ACI. Can you not use a different virtual Ethernet Segment per BD instead, and use RT1s for each ESI? In that way you don’t need to use the ethernet-tag-id, which is used for vlan-aware-bundle in general.

Thanks.
Jorge

Hi Jorge,

That's the difference.

That's the problem.

Thanks,

Yubao

原始邮件

Thanks.

Jorge

Hi Jorge,

Regards,

Yubao

---

From: <[email-masked]>
Date: Sat, 13 Nov 2021 12:08:44 +0800 (CST)

Hi Jorge,

 

Thanks

Yubao

原始邮件

日 期 ：2021年11月13日 03:00

Hi Yubao,

If you receive an RT1 with ESI-1 and a route-target identifying BD1, the RT5 with ESI-1 can be resolved to the RT1, hence the traffic will use the IRB connected to BD1 (and the MAC of the IRB as MAC SA). You have all the information, so it is up to the implementation how to use it or if it can use it.

[Yubao] I agree with you on that such implementation can be used in slide 5. but I haven't considered it is as a good choice because of the following considerations:

        the first reason is that: this requires the RT-1 per EVI routes of BD-10 and BD-20 to be imported into the context of the IP-VRF,

        But we would like to treat BD-10 and BD-20 as normal BDs of [RFC9135], 

        I don't think a normal BD of [RFC9135] would import all or parts of its RT-1 per EVI routes into the context of the IP-VRF of its IRB.

        because that behavior will burden the IP-VRF if no Bump-in-the-wire RT-5 routes will be received in the future.

        the second reason is that: If the use case of slide 5 is slightly changed, that implementation will not work.

        Now we can imagine that VA1 and VA2 are provisioned on the same pair of TS nodes, and these TS nodes are attached to NVE2 and NVE3 using ESI23 as illustrated in slide 6.

        In this use case, that implementation will not work. But the RT-5 routes with a route-target identifying a BD (described in slide 5) will work well. 

        Note that slide 5 is still a centerlized Bump-in-the-wire use case, but BD-10 and BD-20 are assumed to be all configured on all the DGWs.

        The supplementary overlay index is mainly used in slide 6, which is a distributed Bump-in-the-wire use case and not all of the NVEs should be configured with BD-10 or BD-20.

        That's why the left side of slide 6 is a NVE node, but the left side of slide 5 is a DGW node.

        The slide 5 is about the route processing improvement in centerlized multiple Bump-in-the-wire insances, whether ESI23a and ESI23b is the same ESI23 or not. 

        The slide 6 is about the route processing improvement in distributed multiple Bump-in-the-wire insances, especially when ESI23a and ESI23b is the same ESI23. 

I also disagree with the reasons you give to not use a virtual ES. The virtual ES spec is implemented and deployed for a long time now.

[Yubao] I agree with you on that the vES draft is there for a long time, but not long enough than [draft-ietf-bess-evpn-inter-subnet-forwarding].

        What we have concerned on is that, hove a existing normal BD of [draft-ietf-bess-evpn-inter-subnet-forwarding] can be smoothly evolved into a distributed Bump-in-the-wire or a IP-aliasing-enhanced symmetric IRB.

               Even in the future, there would be some normal BDs of [draft-ietf-bess-evpn-inter-subnet-forwarding] which don't use a vES at the network operator's choice.

        we want to help these deployments to be soothly evolved into a distributed Bump-in-the-wire or a IP-aliasing-enhanced symmetric IRB.

        I think that we can't assume that the original form of BDs of [draft-ietf-bess-evpn-inter-subnet-forwarding] will not be deployed after the vES is introduced.

Thanks.

Jorge   

 

 

Hi Jorge,

 

Thanks

Yubao

 

原始邮件

收件人：王玉保10045807;

抄送人：[email-masked];

日 期 ：2021年11月12日 04:06

Hi Yubao,

 

 

 

 

 

 

 

 

              the VXLAN case).

 

 

 

Thanks.

Jorge

 

 

Hi Jorge,

That's the difference.

That's the problem. 

 

 

 

 

Thanks,

Yubao

原始邮件

收件人：王玉保10045807;

抄送人：[email-masked];

日 期 ：2021年07月30日 21:47

Hi Yubao,

Thanks.

Jorge

 

 

Hi Jorge,

 

 

 

 

 

 

 

Regards,

Yubao