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

From: <[email-masked]>
Date: Wed, 28 Jul 2021 06:14:27 +0800 (CST)

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 GW-IP 1.1.1.1 will be advertised as overlay index along with the ESI.

But the draft-ietf-bess-evpn-prefix-advertisement-11 does not define an IP Prefix Advertisement Route with both GW-IP and ESI both as overlay index.

I suggest that this should be updated if you want to do so.

And the preference of ESI overlay index should be considered higher than GW-IP overlay index for Leaf-5's sake.

But the preference of ESI overlay index should be considered lower than (or maybe they should both be used? ) GW-IP overlay index for Leaf-2's sake

These are new rules that can't be found in draft-ietf-bess-evpn-prefix-advertisement-11 .

But on the contary,  if the IP Prefix Advertisement Route has a GW-IP overlay index,

It can support the same protection procedures without any ESI overlay index.

( The details to do such protection using GW-IP overlay index I have described in draft-wang-bess-evpn-arp-nd-synch-without-irb-06. )

So I don't get the point why we need two redundant overlay index?

Can you clearify it?

Maybe an IP Prefix Route Style with a GW-IP overlay index is engough here.

And such Route Style is in compliance with  draft-ietf-bess-evpn-prefix-advertisement-11 already.

Another question is that: If the ESI overlay index is advertised, when will the IP A-D per EVI route of Leaf-2 be withdrawn?

When the IRB interface on Leaf-2 fails?

When one of the three ACs fails?

When all of the three ACs fails?

If you want to do so, I suggest that the ESI-1 to be configured onto the IRB interfaces,

But in Figure 2 of  draft-sajassi-bess-evpn-ip-aliasing-02, I see the ESI is configured on the ACs of the BDs.

Is anything I have misunderstood?

Best,

Yubao

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Wed, 28 Jul 2021 06:46:08 +0000

Hi Yubao,

Thanks for your email. Yes, you misunderstood the use-case 😊 but these are good questions, we will clarify in the next revision.

  1.  The IP Prefix routes are advertised with the ESI and always a zero-GW-IP.
     *   Three co-authors of this draft are also co-authors of draft-ietf-bess-evpn-prefix-advertisement and the latter explicitly prohibits the use of non-zero ESI and non-zero GW-IP simultaneously. So you will not see the use of the GW-IP in draft-sajassi-bess-evpn-ip-aliasing.
     *   In fact that is also one of my comments for draft-mackenzie-bess-evpn-l3aa-proto-00: using non-zero ESI *and* non-zero GW-IP in the IP Prefix routes is non-backwards compatible and will break interoperability with existing RRs. But I will send a separate email with my comments.

  1.  About the use-case of slide 7:
     *   As mentioned, the (virtual) ES is associated to the VNF loopback, i.e. 1.1.1.1, and its operational state is tied to the reachability of that loopback.
     *   On leaf-1/2/3/4, the reachability of the loopback is determined by a static-route or IGP, and can be used along with BFD to speed up fault detection.
     *   As an example, suppose leaf-2 has a static-route to 1.1.1.1 with next-hops {20.0.0.1,20.0.0.2,20.0.0.3}, and 1.1.1.1 is associated to ES-1.

                        i.   The ARP resolution to those next-hops is done as usual, nothing especial, it’s done as soon as the static-route is added.

                      ii.   ES-1 will be oper-up as long as the static route is active in the IP-VRF route-table. When it goes inactive, ES-1 will go down and the AD routes withdrawn.

                     iii.   Obviously, and individual AC going down in leaf-2 will not make the static-route inactive, hence will not bring down the ES. The IRB going down will make the static-route inactive, hence the ES will go down.

     *   A similar example would work with an IGP instead of a static route to 1.1.1.1.

I think that should clarify your questions.
Let me know otherwise.

Thanks.
Jorge

From: [email-masked] <[email-masked]>
Date: Wednesday, July 28, 2021 at 12:14 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Comments on draft-sajassi-bess-evpn-ip-aliasing-02

Hi Jorge,

In page 7 of slides-111-bess-sessa-evpn-ip-aliasing<https://datatracker.ietf.org/meeting/111/materials/slides-111-bess-sessa-evpn-ip-aliasing-00>, 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 ?

These are new rules that can't be found in draft-ietf-bess-evpn-prefix-advertisement-11<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-3.2> .

( The details to do such protection using GW-IP overlay index I have described in draft-wang-bess-evpn-arp-nd-synch-without-irb-06<https://datatracker.ietf.org/doc/html/draft-wang-bess-evpn-arp-nd-synch-without-irb-06>. )

Can you clearify it?

And such Route Style is in compliance with  draft-ietf-bess-evpn-prefix-advertisement-11<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-3.2> already.

But in Figure 2 of  draft-sajassi-bess-evpn-ip-aliasing<https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-02#section-1.3>-02, I see the ESI is configured on the ACs of the BDs.

Best,

Yubao

---

From: <[email-masked]>
Date: Wed, 28 Jul 2021 15:52:36 +0800 (CST)

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 illustrated in slide 7, Leaf-2 can't get this information from VNF-1 directly, 

Leaf-2 just have to get this informatio from the IP Prefix Route Advertisement  of Leaf-1 or Leaf-4,

But you explained that these route are advertised without GW-IP. 

I don't understand it very well.

maybe you mean we can inferred from the ESI field that the overlay nexthop is the static-route 1.1.1.1 whose ESI is ESI-1?

This approach maybe works.

but the IP address 1.1.1.1 can be directly advertised as GW-IP overlay index along with prefix 50.0.0.0/24 naturally if we don't manually change its behavior.

so why should we bother to infer from a manual-configured ESI? 

Yubao

原始邮件

发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：[email-masked];
日 期 ：2021年07月28日 14:46
主 题 ：Re: Comments on draft-sajassi-bess-evpn-ip-aliasing-02

Hi Yubao,

 

The IP Prefix routes are advertised with the ESI and always a zero-GW-IP.

Three co-authors of this draft are also co-authors of draft-ietf-bess-evpn-prefix-advertisement and the latter explicitly prohibits the use of non-zero ESI and non-zero GW-IP simultaneously. So you will not see the use of the GW-IP in draft-sajassi-bess-evpn-ip-aliasing.

In fact that is also one of my comments for draft-mackenzie-bess-evpn-l3aa-proto-00: using non-zero ESI *and* non-zero GW-IP in the IP Prefix routes is non-backwards compatible and will break interoperability with existing RRs. But I will send a separate email with my comments.

About the use-case of slide 7:

As mentioned, the (virtual) ES is associated to the VNF loopback, i.e. 1.1.1.1, and its operational state is tied to the reachability of that loopback.

On leaf-1/2/3/4, the reachability of the loopback is determined by a static-route or IGP, and can be used along with BFD to speed up fault detection.

As an example, suppose leaf-2 has a static-route to 1.1.1.1 with next-hops {20.0.0.1,20.0.0.2,20.0.0.3}, and 1.1.1.1 is associated to ES-1.

A similar example would work with an IGP instead of a static route to 1.1.1.1.

Let me know otherwise.

Thanks.

Jorge

 

 

Hi Jorge,

 

Can you clearify it?

 

 

 

Best,

Yubao

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Wed, 28 Jul 2021 10:18:14 +0000

Hi Yubao,

Please see in-line with [jorge].
Thanks.
Jorge

From: [email-masked] <[email-masked]>
Date: Wednesday, July 28, 2021 at 9:53 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02

Hi Jorge,

[jorge] leaf-2 does a recursive resolution. It has a RT5 for 50.0.0.0/24 with next-hop e.g., Leaf-1, and ESI=ESI-1. So when Leaf-2 receives packets with IP DA = 50.0.0.x, it will have a route installed pointing at the local ESI-1, and the local ESI-1 is associated to 1.1.1.1, for which leaf-2 has a route (static or igp).

[jorge] but it does get it via RT5 with ESI, which is resolved locally.

[jorge] see above. Hope it helps now.

[jorge] Some points:

  *   The ESI can be auto derived as indicated in the draft
  *   Using the GW-IP as overlay-index is used in interface-ful models and the use-cases resolved by an RT2 in draft-ietf-bess-evpn-prefix-advertisement. Non upgraded PEs may have an issue with the resolution. However the ESI as an overlay-index resolved to AD routes is documented in the prefix-advertisement draft.
  *   Here we really want to use the ESI as an overlay index and resolve based on the AD routes, which gives a consistent solution for the three use cases in the draft, and other things like e.g., not only aliasing, but also primary/backup behavior

Yubao

原始邮件

a.       Three co-authors of this draft are also co-authors of draft-ietf-bess-evpn-prefix-advertisement and the latter explicitly prohibits the use of non-zero ESI and non-zero GW-IP simultaneously. So you will not see the use of the GW-IP in draft-sajassi-bess-evpn-ip-aliasing.

b.       In fact that is also one of my comments for draft-mackenzie-bess-evpn-l3aa-proto-00: using non-zero ESI *and* non-zero GW-IP in the IP Prefix routes is non-backwards compatible and will break interoperability with existing RRs. But I will send a separate email with my comments.

2.       About the use-case of slide 7:

a.       As mentioned, the (virtual) ES is associated to the VNF loopback, i.e. 1.1.1.1, and its operational state is tied to the reachability of that loopback.

b.       On leaf-1/2/3/4, the reachability of the loopback is determined by a static-route or IGP, and can be used along with BFD to speed up fault detection.

c.       As an example, suppose leaf-2 has a static-route to 1.1.1.1 with next-hops {20.0.0.1,20.0.0.2,20.0.0.3}, and 1.1.1.1 is associated to ES-1.

1. The ARP resolution to those next-hops is done as usual, nothing especial, it’s done as soon as the static-route is added.

2. ES-1 will be oper-up as long as the static route is active in the IP-VRF route-table. When it goes inactive, ES-1 will go down and the AD routes withdrawn.

3. Obviously, and individual AC going down in leaf-2 will not make the static-route inactive, hence will not bring down the ES. The IRB going down will make the static-route inactive, hence the ES will go down.

d.       A similar example would work with an IGP instead of a static route to 1.1.1.1.

Thanks.
Jorge

Hi Jorge,

Can you clearify it?

Best,

Yubao

---

From: <[email-masked]>
Date: Wed, 28 Jul 2021 20:06:09 +0800 (CST)

Hi Jorge,

Please see in-line with [Yubao_2].

Thanks,

Yubao

原始邮件

发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：[email-masked];
日 期 ：2021年07月28日 18:18
主 题 ：Re: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02

Hi Yubao,

Thanks.

Jorge

 

Hi Jorge,

[jorge] Some points:

The ESI can be auto derived as indicated in the draft

Using the GW-IP as overlay-index is used in interface-ful models and the use-cases resolved by an RT2 in draft-ietf-bess-evpn-prefix-advertisement. Non upgraded PEs may have an issue with the resolution. However the ESI as an overlay-index resolved to AD routes is documented in the prefix-advertisement draft.

[Yubao_2] Non-upraded PEs may have an issue to resolution an ESI to an static-route too.

                  I don't think these two similar issues should be a big concern.

                 Most of protocol extensions have similar issues.

                The ESI overlay index is just used in the bump in the wire use case in draft-ietf-bess-evpn-prefix-advertisement.

        In that use case, the ESI is configured on L2 ACs and its Ethernet A-D per EVI is advertised for a BD,

        But in the use case we discussed here, there are no BD1 or BD2 on Leaf-5.

        They are very different use cases and forwarding procedures.

        Even in the Bump-in-the-wire use case, although the RT-5 route has the ESI23 as overlay index,

        but how does the DGWs know which BD should that ESI23 belongs to ?

        Note that many BDs(or MAC-VRFs) can advertise Ethernet A-D per EVI routes for the same ESI23 independently.

        so I think Bump-in-the-wire is very different from the ESI for static-route.

        And the control-plane defined in Bump-in-the-wire may be not so sufficient for the ESI for static-route.

Here we really want to use the ESI as an overlay index and resolve based on the AD routes, which gives a consistent solution for the three use cases in the draft, and other things like e.g., not only aliasing, but also primary/backup behavior

[Yubao_2]  Use GW-IP overlay index, primary/backup behavior can also be supported.

                  Leaf-1/2/3/4 will advertise a RT-5 route for 1.1.1.1 separately, and they can advertise different preferences/metrics separately.

                  GW-IP overlay index can be a consistent solution whether the PE-CE BGP sessions are established between Leaf-1/2/3/4 and VNF-1 or between DGW and VNF-1.

Yubao

 

原始邮件

收件人：王玉保10045807;

抄送人：[email-masked];

日 期 ：2021年07月28日 14:46

Hi Yubao,

 

 

 

Let me know otherwise.

Thanks.

Jorge

 

 

Hi Jorge,

 

Can you clearify it?

 

 

 

Best,

Yubao

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Wed, 28 Jul 2021 13:23:04 +0000

Hi Yubao,

Assuming we agree we can’t have a RT5 with non-zero GW-IP and non-zero ESI, I’ll try to compare using a) gw-ip *or* b) ESI in the RT5 for this use case when leaf-5 is a non-upgraded PE:

a) non-zero GW-IP. Suppose if Leaf-5 is a non-upgraded PE but it complies with draft-evpn-prefix-advertisement. Leaf-5 receives a RT5 with GW-IP=1.1.1.1, and will expect a RT2 to resolve the overlay index. So Leaf-5 will not forward any traffic till that RT2 is received. You could extend your suggestion to advertise an RT2 with the VNF loopback, but the MAC could not be the VNF MAC, or you would run into issues. Also the RT2 would need IP-VRF route-target and label. Also we don’t want to do that, we want to leave the RT2 for either the interface-ful model, or the symmetric IRB model. Using RT2s in the interface-less model would bring ambiguity and issues.

b) non-zero ESI. A non-upgraded Leaf-5 receives the RT5 with non-zero ESI and will expect a RT1 to resolve the overlay index as per draft-evpn-prefix-advertisement. When the RT1 comes along, it may not do aliasing, but it will forward the traffic.

(b) is the solution we chose in this draft because it is simpler (no complexity associated to RT2s) and it is already there also for ESes associated to physical links.

If you want to use the VNF loopback for the resolution of the RT5 to another RT5, please use a different attribute, and not the GW-IP since it will cause backwards interop issues.

About your comment that RT5s can be advertised with all the leaf nodes with different attributes, sure, then you rely on the bgp best path selection done on the Leaf-5, nothing new. Here we want the simple primary/backup signaling decided by the multihomed leaf nodes, in the same way it is done for L2.

Thanks.
Jorge

Date: Wednesday, July 28, 2021 at 2:06 PM

Hi Jorge,

Thanks,

Yubao

原始邮件

Hi Jorge,

[jorge] Some points:

·         The ESI can be auto derived as indicated in the draft

·         Using the GW-IP as overlay-index is used in interface-ful models and the use-cases resolved by an RT2 in draft-ietf-bess-evpn-prefix-advertisement. Non upgraded PEs may have an issue with the resolution. However the ESI as an overlay-index resolved to AD routes is documented in the prefix-advertisement draft.

        Even in the Bump-in-the-wire<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-4.3> use case, although the RT-5 route has the ESI23 as overlay index,

·         Here we really want to use the ESI as an overlay index and resolve based on the AD routes, which gives a consistent solution for the three use cases in the draft, and other things like e.g., not only aliasing, but also primary/backup behavior

Yubao

原始邮件

1.       Three co-authors of this draft are also co-authors of draft-ietf-bess-evpn-prefix-advertisement and the latter explicitly prohibits the use of non-zero ESI and non-zero GW-IP simultaneously. So you will not see the use of the GW-IP in draft-sajassi-bess-evpn-ip-aliasing.

2.       In fact that is also one of my comments for draft-mackenzie-bess-evpn-l3aa-proto-00: using non-zero ESI *and* non-zero GW-IP in the IP Prefix routes is non-backwards compatible and will break interoperability with existing RRs. But I will send a separate email with my comments.

1.       As mentioned, the (virtual) ES is associated to the VNF loopback, i.e. 1.1.1.1, and its operational state is tied to the reachability of that loopback.

2.       On leaf-1/2/3/4, the reachability of the loopback is determined by a static-route or IGP, and can be used along with BFD to speed up fault detection.

3.       As an example, suppose leaf-2 has a static-route to 1.1.1.1 with next-hops {20.0.0.1,20.0.0.2,20.0.0.3}, and 1.1.1.1 is associated to ES-1.

1.       A similar example would work with an IGP instead of a static route to 1.1.1.1.

Thanks.
Jorge

Hi Jorge,

Can you clearify it?

Best,

Yubao

---

From: <[email-masked]>
Date: Wed, 28 Jul 2021 23:35:33 +0800 (CST)

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

原始邮件

日 期 ：2021年07月28日 21:23

Hi Yubao,

 

[Yubao] I don't think the GW-IP have to expect a RT2 to resolve the overlay index.

        It just need to expect to find the GW-IP in the FIB, regardless of that which form of route will be resolved.

        In this use case, it will be another RT5 route for 1.1.1.1.

        As you have pointed out, this is nothing new. so it will works.

 

[Yubao] If you mean the procedures in the Bump-in-the-wire use case,

        I would say that the ESI23 will expect a RT1 to resolve the overlay index,

        But not a random RT1 of ESI23, it Must be the RT1 of an expected BD.

        But an IP-VRF may have many BDs attached to it, all of them may advertise a RT1 for ESI23.

        Which BD's RT1 should the ESI23 of that RT5 be resolved?

        The Bump-in-the-wire contains such requirements, but this use case don't.

        I don't think they can be considered as the same procedure.

        So I don't think that a non-upgraded Leaf-5 should act as you have expected.

[Yubao] I don't agree with that it is already there. please see my above explanation.

        I don't see any other usage of ESI overlay index in RT5 route, except for the Bump-in-the-wire use case.

        Are there other ESI usage specifications for RT5 that I have missed out ?

 

[Yubao] Interfaceful mode says that the GW-IP overlay index will be used for the recursive route resolution,

        not for just a pre-restricted RT1, it just happens to be a RT1 in that use case.

        just like it happens to be another RT5 in this use case.

        So I think the gap between Interfaceful mode and this use case is more smaller

        than the gap between Bump-in-the-wire and this use case.

        Because in Bump-in-the-wire use case that expected RT1 need to be found out among lots of competitors of the same ESI.

[Yubao] This is the orignal text in Interfaceful mode  :

        o GW IP address=IRB-IP of the SBD (this is the Overlay Index

          that will be used for the recursive route resolution).

[Yubao] I don't think the route-type is pre-restricted before the recursive route resolution. it is techincally not necessary.

             If you know draft-ietf-bess-evpn-prefix-advertisement has said that  in wich section , let me know please.

[Yubao] Maybe you mean it is the same way as L2 EVPNs on Leaf-5, 

        But it will be differnt way on Leaf-2 and on Leaf-5.

        I think the difference between L2 and L3 service is just in expectation,

        But Leaf-2 don't have to be so different from Leaf-5.

        Will the dataplane be extended on Leaf-2 ?

Thanks.

Jorge

 

 

Hi Jorge,

 

Thanks,

Yubao

 

原始邮件

收件人：王玉保10045807;

抄送人：[email-masked];

日 期 ：2021年07月28日 18:18

Hi Yubao,

Thanks.

Jorge

 

Hi Jorge,

[jorge] Some points:

 

 

 

        

 

 

Yubao

 

原始邮件

收件人：王玉保10045807;

抄送人：[email-masked];

日 期 ：2021年07月28日 14:46

Hi Yubao,

 

 

 

Let me know otherwise.

Thanks.

Jorge

 

 

Hi Jorge,

 

Can you clearify it?

 

 

 

Best,

Yubao

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Wed, 28 Jul 2021 16:14:05 +0000

Hi Yubao,

More in-line.

Thanks.
Jorge

Date: Wednesday, July 28, 2021 at 5:35 PM

Hi Jorge,

[jorge] The resolution of an RT5 with non-zero ESI to a RT1 is already in draft-ietf-bess-evpn-prefix-advertisement. The resolution of an RT5 with non-zero ESI to a local ESI for the synchronization or the route-table belongs to the ip-aliasing draft. See more below.

Thanks,

Yubao

原始邮件

<<<<<<<<<<<<<<<<<
[jorge] I don’t think I pointed that out. Let me clarify:

  *   A RT5 that uses the NLRI next-hop for resolution (so no overlay index) can be resolved to another RT5. That is, if the RT5’s next-hop was 1.1.1.1 and you have another RT5 for 1.1.1.1/32, I agree that is not new. But this is not the case we are discussing.
  *   A RT5 that uses a GW-IP overlay index for resolution it is expecting a RT2 as per draft-ietf-bess-evpn-prefix-advertisement:
“    . If an NVE receives an RT-5 that specifies an Overlay Index, the
       NVE cannot use the RT-5 in its IP-VRF unless (or until) it can
       recursively resolve the Overlay Index.
<snip>
     . 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.”

<<<<<<<<<<<<<<<<<

[Yubao] If you mean the procedures in the Bump-in-the-wire<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-4.3> use case,
        I would say that the ESI23 will expect a RT1 to resolve the overlay index,
        But not a random RT1 of ESI23, it Must be the RT1 of an expected BD.
        But an IP-VRF may have many BDs attached to it, all of them may advertise a RT1 for ESI23.
        Which BD's RT1 should the ESI23 of that RT5 be resolved?
        The Bump-in-the-wire contains such requirements, but this use case don't.
        I don't think they can be considered as the same procedure.
        So I don't think that a non-upgraded Leaf-5 should act as you have expected.
<<<<<<<<<<<<<<<<<<<<<<
[jorge] I’m referring to this text in draft-ietf-bess-evpn-prefix-advertisement. As specified in the ip-aliasing draft, to import the RT1 we slap the IP-VRF route-target on it:

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

        Are there other ESI usage specifications for RT5 that I have missed out ?
<<<<<<<<<<<<<<<<<<<<<<
[jorge] I’m referring to sections 3.1 and 3.2 in draft-ietf-bess-evpn-prefix-advertisement which specify the rules of use for the RT5. Doing anything different than what is in 3.1 and 3.2 will bring backwards compatibility issues.
<<<<<<<<<<<<<<<<<<<<<<

[Yubao] Interfaceful mode<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-4.4.2> says that the GW-IP overlay index will be used for the recursive route resolution,

[Yubao] This is the orignal text in Interfaceful mode<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-4.4.2>  :

[Yubao] I don't think the route-type is pre-restricted before the recursive route resolution. it is techincally not necessary.
             If you know draft-ietf-bess-evpn-prefix-advertisement<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11> has said that  in wich section , let me know please.
<<<<<<<<<<<<<<<<<<<<<<<
[jorge] From the prefix-advertisement draft:

. If an NVE receives an RT-5 that specifies an Overlay Index, the

       NVE cannot use the RT-5 in its IP-VRF unless (or until) it can

       recursively resolve the Overlay Index.

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

     . 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.
If your implementation resolves an RT5 with non-zero GW-IP to a RT5, it is something else not defined in the prefix-advertisement draft. But do not expect other implementations following the prefix-advertisement draft to resolve it to anything different than a RT2.
<<<<<<<<<<<<<<<<<<<<<<<

<<<<<<<<<<<<<<<<<<<<<<<<
[jorge] yes, I mean similar forwarding as in L2 EVPN. The primary/backup mode is of course optional, the main use case is the aliasing mode.
<<<<<<<<<<<<<<<<<<<<<<<<

Thanks.
Jorge

Hi Jorge,

Thanks,

Yubao

原始邮件

Hi Jorge,

[jorge] Some points:

1.       The ESI can be auto derived as indicated in the draft

2.       Using the GW-IP as overlay-index is used in interface-ful models and the use-cases resolved by an RT2 in draft-ietf-bess-evpn-prefix-advertisement. Non upgraded PEs may have an issue with the resolution. However the ESI as an overlay-index resolved to AD routes is documented in the prefix-advertisement draft.

1.       Here we really want to use the ESI as an overlay index and resolve based on the AD routes, which gives a consistent solution for the three use cases in the draft, and other things like e.g., not only aliasing, but also primary/backup behavior

Yubao

原始邮件

Thanks.
Jorge

Hi Jorge,

Can you clearify it?

Best,

Yubao

---

From: <[email-masked]>
Date: Thu, 29 Jul 2021 14:36:19 +0800 (CST)

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 <RD, ESI, Ethernet Tag ID>,  not just <ESI, Ethernet Tag ID>.

Take the DGW1 of the Bump-in-the-wire use case for example,

If the DGW1 receives a RT-5 route R5 (IPL=24, IP=SN1, ESI=ESI23) 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 ?

Because that the RD of RT-1 route in  Bump-in-the-wire is not the same as yours.

Thus the procedures of that use case is not the same as the discussed use case.

Doing anything different than what is in section 4.3 will not interoperate with non-upgraded DGW1.

Actually, I have used ESI as overlay index in the early revision of draft-wang-bess-evpn-arp-nd-synch-without-irb .

But later I found that the route resolution of the Bump-in-the-wire use case is not the same as I have expected at that time.

But the GW-IP overlay index is much better.

So I mainly use the GW-IP Overlay index, I just use the ESI Overlay index when there is already an ESI (e.g. the ESI is configured for other purpose), 

I don't think we need to configure an ESI just for using it as overlay index.

Note that even in Bump-in-the-wire use case, the ESI23 is configured for BD-10 (see Figure 7 of IP prefix advertisement), not just for using it as overlay index.

Please see more in-line with [Yubao_3]

Thanks,

Bob.

原始邮件

日 期 ：2021年07月29日 00:14

Hi Yubao,

More in-line.

Thanks.

Jorge

 

 

Hi Jorge,

[Yubao_3] As I discussed above, the resolution procedures there is very different from here. 

          Please see more in-line below with [Yubao_3] 

 

 

Thanks,

Yubao

原始邮件

收件人：王玉保10045807;

抄送人：[email-masked];

日 期 ：2021年07月28日 21:23

Hi Yubao,

 

 

<<<<<<<<<<<<<<<<< 

A RT5 that uses the NLRI next-hop for resolution (so no overlay index) can be resolved to another RT5. That is, if the RT5’s next-hop was 1.1.1.1 and you have another RT5 for 1.1.1.1/32, I agree that is not new. But this is not the case we are discussing.

A RT5 that uses a GW-IP overlay index for resolution it is expecting a RT2 as per draft-ietf-bess-evpn-prefix-advertisement:

<snip>

[Yubao_3] The NLRI next-hop just should be resolved in the underlay network, it can't be resolved to another RT-5.

       The draft-ietf-bess-evpn-prefix-advertisement just talks about the use cases it contains,

       So it uses the phrase "can only be done", not "MUST only be done", it is very cautious.

       In old use cases (e.g. Interfaceful mode), we should make sure the GW-IP can be resolved to RT-2.

       But in new use cases, it is not necessary to be restricted to that.

       If I extend a new Extended Community to replace the GW-IP, it will bring us no better benefits than the GW-IP itself.

       The GW-IP that is resolved to RT5 will bring no harms to existing implements.

     

<<<<<<<<<<<<<<<<< 

 

<<<<<<<<<<<<<<<<<<<<<< 

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

[Yubao_3] Please see my above explanations. Just an ESI is not enough.

          This is just the necessary condition for Bump-in-the-wire use case, not the sufficient condition for that use case.

          Not the necessary condition for other use cases either.

<<<<<<<<<<<<<<<<<<<<<< 

 

<<<<<<<<<<<<<<<<<<<<<< 

[Yubao_3] As my above explanation, the entire rules are very different actually. 

          These two section's just covers the necessary condition of the Bump-in-the-wire use case,

          They can't cover the sufficient condition of the ESI resolution of the Bump-in-the-wire use case.

          Just think about two RT1 routes (with the same ESI and different RD) both matches the recursive lookup.

          It is typical use case where an IP-VRF have more than one BDs on the same ES been attached to it.

<<<<<<<<<<<<<<<<<<<<<< 

 

 

 

 

<<<<<<<<<<<<<<<<<<<<<<< 

. If an NVE receives an RT-5 that specifies an Overlay Index, the        NVE cannot use the RT-5 in its IP-VRF unless (or until) it can        recursively resolve the Overlay Index.      . 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.      . 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. 
If your implementation resolves an RT5 with non-zero GW-IP to a RT5, it is something else not defined in the prefix-advertisement draft. But do not expect other implementations following the prefix-advertisement draft to resolve it to anything different than a RT2.

[Yubao_3] We should not expect other implementations to arbitrarily resolve an RT5 with non-zero ESI to any existing RT1 of that             ESI ,  they should be cautious about that. Other attributes have to be checked during the recursive lookup.

          That's why I don't agree that the ESI overlay index approach in the discussed use case will have better backward compatiblilities.

<<<<<<<<<<<<<<<<<<<<<<< 

 

<<<<<<<<<<<<<<<<<<<<<<<< 

[Yubao_3] Do you think a non-upgraded DGW1 (see Figure 7 of IP prefix advertisement) will load-balance traffics to both NVE2 and NVE3 ? In draft-ietf-bess-evpn-prefix-advertisement-11 both NVE2 and NVE3 will advertise RT5 routes but only one of them advertises RT1 route. But in your implementation, Both NVE2 and NVE3 should advertise RT1 routes but only one of them will advertise RT5 route. They are just two different control-plane procedures. 

<<<<<<<<<<<<<<<<<<<<<<<< 

Thanks.

Jorge

 

 

Hi Jorge,

 

Thanks,

Yubao

 

原始邮件

收件人：王玉保10045807;

抄送人：[email-masked];

日 期 ：2021年07月28日 18:18

Hi Yubao,

Thanks.

Jorge

 

Hi Jorge,

[jorge] Some points:

 

 

 

        

 

 

Yubao

 

原始邮件

收件人：王玉保10045807;

抄送人：[email-masked];

日 期 ：2021年07月28日 14:46

Hi Yubao,

 

 

 

Let me know otherwise.

Thanks.

Jorge

 

 

Hi Jorge,

 

Can you clearify it?

 

 

 

Best,

Yubao

 

 

n

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 29 Jul 2021 09:00:17 +0000

Hi Yubao,

Of course it is ok to disagree.

But to be clear, I’m not saying draft-sajassi-bess-evpn-ip-aliasing matches everything draft-ietf-bess-evpn-prefix-advertisement specifies, otherwise there would be no reason for draft-sajassi-bess-evpn-ip-aliasing 😉

What I’m saying is that draft-ietf-bess-evpn-prefix-advertisement was written based on the following principles:

  *   Section 3 specified how the RT5 had to be used
  *   Section 4 described some use-cases that followed section 3, with the understanding that new use-cases were possible in the future with new documents, as long as the rules in section 3 were respected
draft-sajassi-bess-evpn-ip-aliasing is not the bump-in-the-wire case in draft-ietf-bess-evpn-prefix-advertisement, but a new use case that follows the above reasoning, that is, follows the rules in section 3.

You are suggesting to use a GW-IP overlay-index in the RT5, that is resolved to another RT5, something not allowed in section 3 of draft-ietf-bess-evpn-prefix-advertisement. I explained why we did not do that in draft-sajassi-bess-evpn-ip-aliasing.

Now, about the bump-in-the-wire use-case of draft-ietf-bess-evpn-prefix-advertisement, we can discuss it in a different thread. But I would like to close this one to avoid confusing others, unless you have additional comments about draft-sajassi-bess-evpn-ip-aliasing.

Thanks.
Jorge

Date: Thursday, July 29, 2021 at 8:36 AM

Hi Jorge,

Take the DGW1 of the Bump-in-the-wire<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-4.3> use case for example,

Because that the RD of RT-1 route in  Bump-in-the-wire<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-4.3> is not the same as yours.

Actually, I have used ESI as overlay index in the early revision of draft-wang-bess-evpn-arp-nd-synch-without-irb<https://datatracker.ietf.org/doc/html/draft-wang-bess-evpn-arp-nd-synch-without-irb-02#section-6> .

Note that even in Bump-in-the-wire use case, the ESI23 is configured for BD-10 (see Figure 7 of IP prefix advertisement<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-4.3>), not just for using it as overlay index.

Thanks,

Bob.

原始邮件

More in-line.

Thanks.
Jorge

Hi Jorge,

Thanks,

Yubao

原始邮件

·         A RT5 that uses the NLRI next-hop for resolution (so no overlay index) can be resolved to another RT5. That is, if the RT5’s next-hop was 1.1.1.1 and you have another RT5 for 1.1.1.1/32, I agree that is not new. But this is not the case we are discussing.

·         A RT5 that uses a GW-IP overlay index for resolution it is expecting a RT2 as per draft-ietf-bess-evpn-prefix-advertisement:

<<<<<<<<<<<<<<<<<

[Yubao_3] Do you think a non-upgraded DGW1 (see Figure 7 of IP prefix advertisement<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-4.3>) will load-balance traffics to both NVE2 and NVE3 ? In draft-ietf-bess-evpn-prefix-advertisement-11<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-4.3> both NVE2 and NVE3 will advertise RT5 routes but only one of them advertises RT1 route. But in your implementation, Both NVE2 and NVE3 should advertise RT1 routes but only one of them will advertise RT5 route. They are just two different control-plane procedures.

<<<<<<<<<<<<<<<<<<<<<<<<

Thanks.
Jorge

Hi Jorge,

Thanks,

Yubao

原始邮件

Hi Jorge,

[jorge] Some points:

Yubao

原始邮件

Thanks.
Jorge

Hi Jorge,

Can you clearify it?

Best,

Yubao

n

---

From: <[email-masked]>
Date: Fri, 30 Jul 2021 08:26:13 +0800 (CST)

Hi Jorge,

It will be good to discuss draft-ietf-bess-evpn-prefix-advertisement in a new thread.

But I should clearify that I discussed Bump-in-the-wire with you just because draft-sajassi-bess-evpn-ip-aliasing has many references to that use case,

and you have assumed that draft-sajassi-bess-evpn-ip-aliasing can cooperate with non-upgraded DGW1 node (e.g. think about that if it happens to be your Leaf-5 node) of Bump-in-the-wire use case.

Actually we can not expect non-upgraded Bump-in-the-wire DGWs to do that.

Later I will start a new thread to discuss draft-ietf-bess-evpn-prefix-advertisement.

Thanks,

Yubao

原始邮件

日 期 ：2021年07月29日 21:00

Hi Yubao,

 

 

Section 3 specified how the RT5 had to be used

Section 4 described some use-cases that followed section 3, with the understanding that new use-cases were possible in the future with new documents, as long as the rules in section 3 were respected

 

 

 

Thanks.

Jorge

 

Hi Jorge,

 

 

 

 

Thanks,

Bob.

 

原始邮件

收件人：王玉保10045807;

抄送人：[email-masked];

日 期 ：2021年07月29日 00:14

Hi Yubao,

More in-line.

Thanks.

Jorge

 

 

Hi Jorge,

 

 

 

 

Thanks,

Yubao

原始邮件

收件人：王玉保10045807;

抄送人：[email-masked];

日 期 ：2021年07月28日 21:23

Hi Yubao,

 

 

<<<<<<<<<<<<<<<<< 

<snip>

 

       

<<<<<<<<<<<<<<<<< 

 

<<<<<<<<<<<<<<<<<<<<<< 

<<<<<<<<<<<<<<<<<<<<<< 

 

<<<<<<<<<<<<<<<<<<<<<< 

 

<<<<<<<<<<<<<<<<<<<<<< 

 

 

 

 

<<<<<<<<<<<<<<<<<<<<<<< 

 

<<<<<<<<<<<<<<<<<<<<<<< 

 

<<<<<<<<<<<<<<<<<<<<<<<< 

         

<<<<<<<<<<<<<<<<<<<<<<<< 

Thanks.

Jorge

 

 

Hi Jorge,

 

Thanks,

Yubao

 

原始邮件

收件人：王玉保10045807;

抄送人：[email-masked];

日 期 ：2021年07月28日 18:18

Hi Yubao,

Thanks.

Jorge

 

Hi Jorge,

[jorge] Some points:

 

 

 

        

 

 

Yubao

 

原始邮件

收件人：王玉保10045807;

抄送人：[email-masked];

日 期 ：2021年07月28日 14:46

Hi Yubao,

 

 

 

Let me know otherwise.

Thanks.

Jorge

 

 

Hi Jorge,

 

Can you clearify it?

 

 

 

Best,

Yubao

 

 

n

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 30 Jul 2021 13:07:16 +0000

Hi Yubao,

The resolution of an ESI overlay index is indeed in draft-ietf-bess-evpn-prefix-advertisement. The new use case adds the aliasing/backup function in the context of the IP-VRF.

Thanks.
Jorge

Date: Friday, July 30, 2021 at 2:26 AM

Hi Jorge,

Thanks,

Yubao

原始邮件

·         Section 3 specified how the RT5 had to be used

·         Section 4 described some use-cases that followed section 3, with the understanding that new use-cases were possible in the future with new documents, as long as the rules in section 3 were respected
draft-sajassi-bess-evpn-ip-aliasing is not the bump-in-the-wire case in draft-ietf-bess-evpn-prefix-advertisement, but a new use case that follows the above reasoning, that is, follows the rules in section 3.

Thanks.
Jorge

Hi Jorge,

Thanks,

Bob.

原始邮件

More in-line.

Thanks.
Jorge

Hi Jorge,

Thanks,

Yubao

原始邮件

1.       A RT5 that uses the NLRI next-hop for resolution (so no overlay index) can be resolved to another RT5. That is, if the RT5’s next-hop was 1.1.1.1 and you have another RT5 for 1.1.1.1/32, I agree that is not new. But this is not the case we are discussing.

2.       A RT5 that uses a GW-IP overlay index for resolution it is expecting a RT2 as per draft-ietf-bess-evpn-prefix-advertisement:

<<<<<<<<<<<<<<<<<

<<<<<<<<<<<<<<<<<<<<<<<<

Thanks.
Jorge

Hi Jorge,

Thanks,

Yubao

原始邮件

Hi Jorge,

[jorge] Some points:

Yubao

原始邮件

Thanks.
Jorge

Hi Jorge,

Can you clearify it?

Best,

Yubao

n