Re: [bess] Questions on draft-sajassi-bess-evpn-ip-aliasing-03
Hi Yubao, We’ll try to clarify further in the next revision, but I hope the three use cases and procedures are clear now. Thanks for the feedback. Jorge From: wang.yub...@zte.com.cn Date: Saturday, November 13, 2021 at 3:56 AM To: Rabadan, Jorge (Nokia - US/Mountain View) Cc: bess@ietf.org Subject: Re: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 the route advertisement of other two use cases (a and c) are both not suitable for it. Thanks Yubao 原始邮件 发件人：Rabadan,Jorge(Nokia-US/MountainView) 收件人：王玉保10045807; 抄送人：bess@ietf.org; 日 期 ：2021年11月13日 03:00 主 题 ：Re: Re:Questions on draft-sajassi-bess-evpn-ip-aliasing-03 Hi Yubao, Thanks for taking the time to respond. It sounds like you are arguing that the reference to bump-in-the-wire in this draft is confusing. I’m personally ok to remove it for the next version if it helps. Although it should already be there, I’ll make sure it is clear that the document addresses symmetric IRB (RFC9135) and interface-less model (RFC9136) only. Thanks. Jorge From: wang.yub...@zte.com.cn Date: Friday, November 12, 2021 at 7:16 AM To: Rabadan, Jorge (Nokia - US/Mountain View) Cc: bess@ietf.org Subject: Re: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 comments with [jorge2]. Thx Jorge From: wang.yub...@zte.com.cn Date: Wednesday, November 10, 2021 at 3:55 AM To: Rabadan, Jorge (Nokia - US/Mountain View) Cc: bess@ietf.org Subject: Re: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 From: wang.yub...@zte.com.cn Date: Tuesday, November 9, 2021 at 9:06 AM To: Rabadan, Jorge (Nokia - US/Mountain View) Cc: bess@ietf.org Subject: 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 A-D per EVI route, in other words, its MPLS label identifies a BD, not an IP-VRF. is my understanding correct? [jorge] not really, it is an IP A-D per EVI route as explained in section 3. In RFC9136 Interface-less IP-VRF-to-IP-VRF Model, the inter-subnet-forwarding from H3 to H1 will pass through PE1/PE2's IP-VRF instance via the MPLS label of the IP-VRF's instance, but in the RFC9316 Bump-in-the-wire instance, the inter-subnet-forwarding from H3 to H1 will not pass through PE1/PE2's IP-VRF instance because of the RT-1 per EVI route's MPLS Label's L2 context. But this section refers to both the above two use cases of RFC9136, So which behavior will be followed by this use case? [jorge] see above, the IP A-D per EVI route includes the route-target and label of the IP-VRF as explained in section 3. [Yubao2] I get your meanings now, I mistake the RT-1 per EVI route of use case b (section 1.2) as a Ethernet A-D per EVI route because of the following text: In the Interface-less IP-VRF-to-IP-VRF model described in [I-D.ietf-bess-evpn-prefix-advertisement] there is no Overlay Index and hence no recursive resolution of the IP Prefix route to either a MAC/IP Advertisement or an Ethernet A-D per ES/EVI route, which means that the fast convergence and aliasing/backup path functions are disabled. Although the use-case is different, in a sense the recursive resolution of an IP Prefix route to an Ethernet A-D per ES/ EVI route is already described in section 4.3 of [I-D.ietf-bess-evpn-prefix-advertisement], Bump-in-the-Wire Use-Case, but that section does not describe aliasing. [jorge2] note that the above text is describing the use-cases. The concept of the IP A-D per ES/EVI route is defined later in section 3. [Yubao3] We should note that RFC9136 section 3 is just the route resolution procedures, But the use case b of draft-sajassi-bess-evpn-ip-aliasing-03 is a use case including route advertisement, route resolution, data packet forwarding. If they are only the same in the route resolution procedures, it will be confusing to treat it as a Bump-in-the-wire Use
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 the route advertisement of other two use cases (a and c) are both not suitable for it. Thanks Yubao 原始邮件 发件人：Rabadan,Jorge(Nokia-US/MountainView) 收件人：王玉保10045807; 抄送人：bess@ietf.org; 日 期 ：2021年11月13日 03:00 主 题 ：Re: Re:Questions on draft-sajassi-bess-evpn-ip-aliasing-03 Hi Yubao, Thanks for taking the time to respond. It sounds like you are arguing that the reference to bump-in-the-wire in this draft is confusing. I’m personally ok to remove it for the next version if it helps. Although it should already be there, I’ll make sure it is clear that the document addresses symmetric IRB (RFC9135) and interface-less model (RFC9136) only. Thanks. Jorge From: wang.yub...@zte.com.cn Date: Friday, November 12, 2021 at 7:16 AM To: Rabadan, Jorge (Nokia - US/Mountain View) Cc: bess@ietf.org Subject: Re: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 comments with [jorge2]. Thx Jorge From: wang.yub...@zte.com.cn Date: Wednesday, November 10, 2021 at 3:55 AM To: Rabadan, Jorge (Nokia - US/Mountain View) Cc: bess@ietf.org Subject: Re: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 From: wang.yub...@zte.com.cn Date: Tuesday, November 9, 2021 at 9:06 AM To: Rabadan, Jorge (Nokia - US/Mountain View) Cc: bess@ietf.org Subject: 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 A-D per EVI route, in other words, its MPLS label identifies a BD, not an IP-VRF. is my understanding correct? [jorge] not really, it is an IP A-D per EVI route as explained in section 3. In RFC9136 Interface-less IP-VRF-to-IP-VRF Model, the inter-subnet-forwarding from H3 to H1 will pass through PE1/PE2's IP-VRF instance via the MPLS label of the IP-VRF's instance, but in the RFC9316 Bump-in-the-wire instance, the inter-subnet-forwarding from H3 to H1 will not pass through PE1/PE2's IP-VRF instance because of the RT-1 per EVI route's MPLS Label's L2 context. But this section refers to both the above two use cases of RFC9136, So which behavior will be followed by this use case? [jorge] see above, the IP A-D per EVI route includes the route-target and label of the IP-VRF as explained in section 3. [Yubao2] I get your meanings now, I mistake the RT-1 per EVI route of use case b (section 1.2) as a Ethernet A-D per EVI route because of the following text: In the Interface-less IP-VRF-to-IP-VRF model described in [I-D.ietf-bess-evpn-prefix-advertisement] there is no Overlay Index and hence no recursive resolution of the IP Prefix route to either a MAC/IP Advertisement or an Ethernet A-D per ES/EVI route, which means that the fast convergence and aliasing/backup path functions are disabled. Although the use-case is different, in a sense the recursive resolution of an IP Prefix route to an Ethernet A-D per ES/ EVI route is already described in section 4.3 of [I-D.ietf-bess-evpn-prefix-advertisement], Bump-in-the-Wire Use-Case, but that section does not describe aliasing. [jorge2] note that the above text is describing the use-cases. The concept of the IP A-D per ES/EVI route is defined later in section 3. [Yubao3] We should note that RFC9136 section 3 is just the route resolution procedures, But the use case b of draft-sajassi-bess-evpn-ip-aliasing-03 is a use case including route advertisement, route resolution, data packet forwarding. If they are only the same in the route resolution procedures, it will be confusing to treat it as a Bump-in-the-wire Use-Case plus ip-aliasing. I still note that the route advertise ment is not clearly discribed in . for example, how can we know which ESI
Re: [bess] Questions on draft-sajassi-bess-evpn-ip-aliasing-03
Hi Yubao, Thanks for taking the time to respond. It sounds like you are arguing that the reference to bump-in-the-wire in this draft is confusing. I’m personally ok to remove it for the next version if it helps. Although it should already be there, I’ll make sure it is clear that the document addresses symmetric IRB (RFC9135) and interface-less model (RFC9136) only. Thanks. Jorge From: wang.yub...@zte.com.cn Date: Friday, November 12, 2021 at 7:16 AM To: Rabadan, Jorge (Nokia - US/Mountain View) Cc: bess@ietf.org Subject: Re: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 comments with [jorge2]. Thx Jorge From: wang.yub...@zte.com.cn Date: Wednesday, November 10, 2021 at 3:55 AM To: Rabadan, Jorge (Nokia - US/Mountain View) Cc: bess@ietf.org Subject: Re: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 From: wang.yub...@zte.com.cn Date: Tuesday, November 9, 2021 at 9:06 AM To: Rabadan, Jorge (Nokia - US/Mountain View) Cc: bess@ietf.org Subject: 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 A-D per EVI route, in other words, its MPLS label identifies a BD, not an IP-VRF. is my understanding correct? [jorge] not really, it is an IP A-D per EVI route as explained in section 3. In RFC9136 Interface-less IP-VRF-to-IP-VRF Model, the inter-subnet-forwarding from H3 to H1 will pass through PE1/PE2's IP-VRF instance via the MPLS label of the IP-VRF's instance, but in the RFC9316 Bump-in-the-wire instance, the inter-subnet-forwarding from H3 to H1 will not pass through PE1/PE2's IP-VRF instance because of the RT-1 per EVI route's MPLS Label's L2 context. But this section refers to both the above two use cases of RFC9136, So which behavior will be followed by this use case? [jorge] see above, the IP A-D per EVI route includes the route-target and label of the IP-VRF as explained in section 3. [Yubao2] I get your meanings now, I mistake the RT-1 per EVI route of use case b (section 1.2) as a Ethernet A-D per EVI route because of the following text: In the Interface-less IP-VRF-to-IP-VRF model described in [I-D.ietf-bess-evpn-prefix-advertisement] there is no Overlay Index and hence no recursive resolution of the IP Prefix route to either a MAC/IP Advertisement or an Ethernet A-D per ES/EVI route, which means that the fast convergence and aliasing/backup path functions are disabled. Although the use-case is different, in a sense the recursive resolution of an IP Prefix route to an Ethernet A-D per ES/ EVI route is already described in section 4.3 of [I-D.ietf-bess-evpn-prefix-advertisement], Bump-in-the-Wire Use-Case, but that section does not describe aliasing. [jorge2] note that the above text is describing the use-cases. The concept of the IP A-D per ES/EVI route is defined later in section 3. [Yubao3] We should note that RFC9136 section 3 is just the route resolution procedures, But the use case b of draft-sajassi-bess-evpn-ip-aliasing-03 is a use case including route advertisement, route resolution, data packet forwarding. If they are only the same in the route resolution procedures, it will be confusing to treat it as a Bump-in-the-wire Use-Case plus ip-aliasing. I still note that the route advertise ment is not clearly discribed in . for example, how can we know which ESI should be carried in a RT-5 route? This is not described in RFC9136 Bump-in-the-wire use case either, because there is no IP-VRF on NVEs. So the route advertisement behavior of draft-sajassi-bess-evpn-ip-aliasing-03 use case b is not clearly defined both in this draft and in RFC9136 Bump-in-the-wire. [Yubao2] These two concepts Ethernet A-D per ES/EVI route and IP A-D per ES/EVI route in this draft may be confusing. To me an ethernet A-D per EVI route means that its route-target identifies a MAC-VRF as per [RFC7432]. an IP A-D per EVI route means that its route-target identifies a IP-VRF as per this draft. When they will be used by a RT-5 route with an ESI overlay index
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 comments with [jorge2]. Thx Jorge From: wang.yub...@zte.com.cn Date: Wednesday, November 10, 2021 at 3:55 AM To: Rabadan, Jorge (Nokia - US/Mountain View) Cc: bess@ietf.org Subject: Re: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 From: wang.yub...@zte.com.cn Date: Tuesday, November 9, 2021 at 9:06 AM To: Rabadan, Jorge (Nokia - US/Mountain View) Cc: bess@ietf.org Subject: 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 A-D per EVI route, in other words, its MPLS label identifies a BD, not an IP-VRF. is my understanding correct? [jorge] not really, it is an IP A-D per EVI route as explained in section 3. In RFC9136 Interface-less IP-VRF-to-IP-VRF Model, the inter-subnet-forwarding from H3 to H1 will pass through PE1/PE2's IP-VRF instance via the MPLS label of the IP-VRF's instance, but in the RFC9316 Bump-in-the-wire instance, the inter-subnet-forwarding from H3 to H1 will not pass through PE1/PE2's IP-VRF instance because of the RT-1 per EVI route's MPLS Label's L2 context. But this section refers to both the above two use cases of RFC9136, So which behavior will be followed by this use case? [jorge] see above, the IP A-D per EVI route includes the route-target and label of the IP-VRF as explained in section 3. [Yubao2] I get your meanings now, I mistake the RT-1 per EVI route of use case b (section 1.2) as a Ethernet A-D per EVI route because of the following text: In the Interface-less IP-VRF-to-IP-VRF model described in [I-D.ietf-bess-evpn-prefix-advertisement] there is no Overlay Index and hence no recursive resolution of the IP Prefix route to either a MAC/IP Advertisement or an Ethernet A-D per ES/EVI route, which means that the fast convergence and aliasing/backup path functions are disabled. Although the use-case is different, in a sense the recursive resolution of an IP Prefix route to an Ethernet A-D per ES/ EVI route is already described in section 4.3 of [I-D.ietf-bess-evpn-prefix-advertisement], Bump-in-the-Wire Use-Case, but that section does not describe aliasing. [jorge2] note that the above text is describing the use-cases. The concept of the IP A-D per ES/EVI route is defined later in section 3. [Yubao3] We should note that RFC9136 section 3 is just the route resolution procedures, But the use case b of draft-sajassi-bess-evpn-ip-aliasing-03 is a use case including route advertisement, route resolution, data packet forwarding. If they are only the same in the route resolution procedures, it will be confusing to treat it as a Bump-in-the-wire Use-Case plus ip-aliasing. I still note that the route advertise ment is not clearly discribed in . for example, how can we know which ESI should be carried in a RT-5 route? This is not described in RFC9136 Bump-in-the-wire use case either, because there is no IP-VRF on NVEs. So the route advertisement behavior of draft-sajassi-bess-evpn-ip-aliasing-03 use case b is not clearly defined both in this draft and in RFC9136 Bump-in-the-wire. [Yubao2] These two concepts Ethernet A-D per ES/EVI route and IP A-D per ES/EVI route in this draft may be confusing. To me an ethernet A-D per EVI route means that its route-target identifies a MAC-VRF as per [RFC7432]. an IP A-D per EVI route means that its route-target identifies a IP-VRF as per this draft. When they will be used by a RT-5 route with an ESI overlay index, they will be different in route advertisement, recursive resolution and forwarding behavior too. But in the above text of draft-sajassi-bess-evpn-ip-aliasing-03, it seems that the route advertisement, recursive resolution and forwarding behavior in the draft is just the same as RFC9136 secion 4.3 Bump-in-the-wire use case. I think it will be confusing. The most obvious difference
Re: [bess] Questions on draft-sajassi-bess-evpn-ip-aliasing-03
Hi Yubao, Please see my comments with [jorge2]. Thx Jorge From: wang.yub...@zte.com.cn Date: Wednesday, November 10, 2021 at 3:55 AM To: Rabadan, Jorge (Nokia - US/Mountain View) Cc: bess@ietf.org Subject: Re: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 From: wang.yub...@zte.com.cn Date: Tuesday, November 9, 2021 at 9:06 AM To: Rabadan, Jorge (Nokia - US/Mountain View) Cc: bess@ietf.org Subject: 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 A-D per EVI route, in other words, its MPLS label identifies a BD, not an IP-VRF. is my understanding correct? [jorge] not really, it is an IP A-D per EVI route as explained in section 3. In RFC9136 Interface-less IP-VRF-to-IP-VRF Model, the inter-subnet-forwarding from H3 to H1 will pass through PE1/PE2's IP-VRF instance via the MPLS label of the IP-VRF's instance, but in the RFC9316 Bump-in-the-wire instance, the inter-subnet-forwarding from H3 to H1 will not pass through PE1/PE2's IP-VRF instance because of the RT-1 per EVI route's MPLS Label's L2 context. But this section refers to both the above two use cases of RFC9136, So which behavior will be followed by this use case? [jorge] see above, the IP A-D per EVI route includes the route-target and label of the IP-VRF as explained in section 3. [Yubao2] I get your meanings now, I mistake the RT-1 per EVI route of use case b (section 1.2) as a Ethernet A-D per EVI route because of the following text: In the Interface-less IP-VRF-to-IP-VRF model described in [I-D.ietf-bess-evpn-prefix-advertisement] there is no Overlay Index and hence no recursive resolution of the IP Prefix route to either a MAC/IP Advertisement or an Ethernet A-D per ES/EVI route, which means that the fast convergence and aliasing/backup path functions are disabled. Although the use-case is different, in a sense the recursive resolution of an IP Prefix route to an Ethernet A-D per ES/ EVI route is already described in section 4.3 of [I-D.ietf-bess-evpn-prefix-advertisement], Bump-in-the-Wire Use-Case, but that section does not describe aliasing. [jorge2] note that the above text is describing the use-cases. The concept of the IP A-D per ES/EVI route is defined later in section 3. [Yubao2] These two concepts Ethernet A-D per ES/EVI route and IP A-D per ES/EVI route in this draft may be confusing. To me an ethernet A-D per EVI route means that its route-target identifies a MAC-VRF as per [RFC7432]. an IP A-D per EVI route means that its route-target identifies a IP-VRF as per this draft. When they will be used by a RT-5 route with an ESI overlay index, they will be different in route advertisement, recursive resolution and forwarding behavior too. But in the above text of draft-sajassi-bess-evpn-ip-aliasing-03, it seems that the route advertisement, recursive resolution and forwarding behavior in the draft is just the same as RFC9136 secion 4.3 Bump-in-the-wire use case. I think it will be confusing. The most obvious difference between these two use case is that, The inter-subnet forwarding from H3 to H1 will use a MPLS label which identifies a MAC-VRF according to Bump-in-the-wire use case, But in this draft it is not the same behavior. This difference will lead to other differences on route advertisement and recursive resolution too. [jorge] we can clarify further, but an IP A-D per EVI route uses a label that identifies the IP-VRF, which is what is required in the symmetric IRB and interface-less scenarios that this draft builds upon. Section 3 explains how the IP A-D per EVI route is built. 2) On section 5.3 Constructing the EVPN IP Routes Is the RT-5 construction of the second use case (section 1.2) the same as the third use case (section 1.3) ? I mainly concerns the Route Targets and the Ethernet Tag ID of the RT-5 routes. especailly when the BD (to which the ESI of section 1.2 is attched) is of VLAN-aware service interface. [jorge] the IP Prefix routes and MAC/IP advertisement routes are constructed as per section 5.3, hence the IP Prefix routes ethernet tag id is 0. This document does not change the use of the Ethernet Tag ID. [Yubao2] As I explained above, if they are the same
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 From: wang.yub...@zte.com.cn Date: Tuesday, November 9, 2021 at 9:06 AM To: Rabadan, Jorge (Nokia - US/Mountain View) Cc: bess@ietf.org Subject: 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 A-D per EVI route, in other words, its MPLS label identifies a BD, not an IP-VRF. is my understanding correct? [jorge] not really, it is an IP A-D per EVI route as explained in section 3. In RFC9136 Interface-less IP-VRF-to-IP-VRF Model, the inter-subnet-forwarding from H3 to H1 will pass through PE1/PE2's IP-VRF instance via the MPLS label of the IP-VRF's instance, but in the RFC9316 Bump-in-the-wire instance, the inter-subnet-forwarding from H3 to H1 will not pass through PE1/PE2's IP-VRF instance because of the RT-1 per EVI route's MPLS Label's L2 context. But this section refers to both the above two use cases of RFC9136, So which behavior will be followed by this use case? [jorge] see above, the IP A-D per EVI route includes the route-target and label of the IP-VRF as explained in section 3. [Yubao2] I get your meanings now, I mistake the RT-1 per EVI route of use case b (section 1.2) as a Ethernet A-D per EVI route because of the following text: In the Interface-less IP-VRF-to-IP-VRF model described in [I-D.ietf-bess-evpn-prefix-advertisement] there is no Overlay Index and hence no recursive resolution of the IP Prefix route to either a MAC/IP Advertisement or an Ethernet A-D per ES/EVI route, which means that the fast convergence and aliasing/backup path functions are disabled. Although the use-case is different, in a sense the recursive resolution of an IP Prefix route to an Ethernet A-D per ES/ EVI route is already described in section 4.3 of [I-D.ietf-bess-evpn-prefix-advertisement], Bump-in-the-Wire Use-Case, but that section does not describe aliasing. [Yubao2] These two concepts Ethernet A-D per ES/EVI route and IP A-D per ES/EVI route in this draft may be confusing. To me an ethernet A-D per EVI route means that its route-target identifies a MAC-VRF as per [RFC7432]. an IP A-D per EVI route means that its route-target identifies a IP-VRF as per this draft. When they will be used by a RT-5 route with an ESI overlay index, they will be different in route advertisement, recursive resolution and forwarding behavior too. But in the above text of draft-sajassi-bess-evpn-ip-aliasing-03, it seems that the route advertisement, recursive resolution and forwarding behavior in the draft is just the same as RFC9136 secion 4.3 Bump-in-the-wire use case. I think it will be confusing. The most obvious difference between these two use case is that, The inter-subnet forwarding from H3 to H1 will use a MPLS label which identifies a MAC-VRF according to Bump-in-the-wire use case, But in this draft it is not the same behavior. This difference will lead to other differences on route advertisement and recursive resolution too. 2) On section 5.3 Constructing the EVPN IP Routes Is the RT-5 construction of the second use case (section 1.2) the same as the third use case (section 1.3) ? I mainly concerns the Route Targets and the Ethernet Tag ID of the RT-5 routes. especailly when the BD (to which the ESI of section 1.2 is attched) is of VLAN-aware service interface. [jorge] the IP Prefix routes and MAC/IP advertisement routes are constructed as per section 5.3, hence the IP Prefix routes ethernet tag id is 0. This document does not change the use of the Ethernet Tag ID. [Yubao2] As I explained above, if they are the same, is the RT-5 construction of the use case c (section 1.3) the same as RFC9136 Bump-in-the-wire use case? 3) On section 5.3.1 Route Resolution Is the Route Resolution of the second use case (section 1.2) the same as the third use case (section 1.3) ? Will the route resolution of the second use case(section 1.2) need a BD and an IRB interface on PE3? I note that in RFC9136 section 4.3 Bump-in-the-wire use case, the RT-1 per EVI route is advertised in a normal BD. It says that: (1) Assuming TS2 is the active TS in ESI23, NVE2 advertises
Re: [bess] Questions on draft-sajassi-bess-evpn-ip-aliasing-03
Hi Yubao, Please see in-line. Thanks. Jorge From: wang.yub...@zte.com.cn Date: Tuesday, November 9, 2021 at 9:06 AM To: Rabadan, Jorge (Nokia - US/Mountain View) Cc: bess@ietf.org Subject: 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 A-D per EVI route, in other words, its MPLS label identifies a BD, not an IP-VRF. is my understanding correct? [jorge] not really, it is an IP A-D per EVI route as explained in section 3. In RFC9136 Interface-less IP-VRF-to-IP-VRF Model, the inter-subnet-forwarding from H3 to H1 will pass through PE1/PE2's IP-VRF instance via the MPLS label of the IP-VRF's instance, but in the RFC9316 Bump-in-the-wire instance, the inter-subnet-forwarding from H3 to H1 will not pass through PE1/PE2's IP-VRF instance because of the RT-1 per EVI route's MPLS Label's L2 context. But this section refers to both the above two use cases of RFC9136, So which behavior will be followed by this use case? [jorge] see above, the IP A-D per EVI route includes the route-target and label of the IP-VRF as explained in section 3. 2) On section 5.3 Constructing the EVPN IP Routes Is the RT-5 construction of the second use case (section 1.2) the same as the third use case (section 1.3) ? I mainly concerns the Route Targets and the Ethernet Tag ID of the RT-5 routes. especailly when the BD (to which the ESI of section 1.2 is attched) is of VLAN-aware service interface. [jorge] the IP Prefix routes and MAC/IP advertisement routes are constructed as per section 5.3, hence the IP Prefix routes ethernet tag id is 0. This document does not change the use of the Ethernet Tag ID. 3) On section 5.3.1 Route Resolution Is the Route Resolution of the second use case (section 1.2) the same as the third use case (section 1.3) ? Will the route resolution of the second use case(section 1.2) need a BD and an IRB interface on PE3? I note that in RFC9136 section 4.3 Bump-in-the-wire use case, the RT-1 per EVI route is advertised in a normal BD. It says that: (1) Assuming TS2 is the active TS in ESI23, NVE2 advertises the following BGP routes: * Route type 1 (Ethernet A-D route for BD-10) containing: ESI = ESI23 and the corresponding tunnel information (VNI field), as well as the BGP Encapsulation Extended Community as per [RFC8365]. * Route type 5 (IP Prefix route) containing: IPL = 24, IP = SN1, ESI = ESI23, and GW IP address = 0. The EVPN Router's MAC Extended Community defined in [RFC9135] is added and carries the MAC address (M2) associated with the TS behind which SN1 sits. M2 may be learned by policy; however, the MAC in the Extended Community is preferred if sent with the route. This RT-1 per EVI route will not just be used by the RT-5 routes for IP forwarding, it will also be used by the MAC forwarding of BD-10. When it is used in IP forwarding and MAC forwarding, it will be the same route. If this is correct, it will need a BD on PE3 to be resolved to. [jorge] the resolution is the same for the three cases, based on section 5.3.1. It happens in the context of the IP-VRF, but now considering the IP A-D routes (which carry the IP-VRF route-target). For use-cases 2 and 3, this is applicable to the interface-less and even interface-ful unnumbered IP-VRF-to-IP-VRF model (we can clarify this in future versions). Thanks, Yubao ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
