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

["Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>]

Hi Yubao,

More in-line.

Thanks.
Jorge


From: [e-mail] <[e-mail]>
Date: Wednesday, July 28, 2021 at 5:35 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: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.

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

Current recursive resolution is very different from such ESI overlay index.



Please see in-line with [Yubao].



Thanks,

Yubao


原始邮件
发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：[e-mail];
日 期 ：2021年07月28日 21:23
主 题 ：Re: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02
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.


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

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


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.

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

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


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


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.

[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,
        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<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-4.4.2>  :



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

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.


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


From: [e-mail] <[e-mail]>
Date: Wednesday, July 28, 2021 at 2:06 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: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;
抄送人：[e-mail];
日 期 ：2021年07月28日 18:18
主 题 ：Re: Re:Comments on draft-sajassi-bess-evpn-ip-aliasing-02
Hi Yubao,

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

From: [e-mail] <[e-mail]>
Date: Wednesday, July 28, 2021 at 9:53 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: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)?

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

As you illustrated in slide 7, Leaf-2 can't get this information from VNF-1 directly,

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

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.

[jorge] see above. Hope it helps now.

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?

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



[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<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,

        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.





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




原始邮件
发件人：Rabadan,Jorge(Nokia-US/MountainView)
收件人：王玉保10045807;
抄送人：[e-mail];
日 期 ：2021年07月28日 14:46
主 题 ：Re: Comments on draft-sajassi-bess-evpn-ip-aliasing-02
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.

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.       About the use-case of slide 7:

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

1.       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: [e-mail] <[e-mail]>
Date: Wednesday, July 28, 2021 at 12:14 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: 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<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 ?

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<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-3.2> .



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<https://datatracker.ietf.org/doc/html/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<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11#section-3.2> 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<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.



Is anything I have misunderstood?



Best,

Yubao