Re: [bess] Question and comments on the EVPN IP Aliasing draft

[Jorge Rabadan (Nokia)]

Hi Sasha,

We just published version 08.
We made some changes in section 3.1 based on your comments.

Note that the draft does not really create a new situation for the AD per EVI 
route in which it could be imported in different VRF types. Prior to this 
document the A-D per EVI route could also be imported in a MAC-VRF or a VPWS 
type of service.

Thanks!
Jorge

From: Alexander Vainshtein 
Date: Thursday, July 13, 2023 at 2:25 AM
To: Jorge Rabadan (Nokia) 
Cc: bess@ietf.org , 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org 

Subject: RE: RE: Question and comments on the EVPN IP Aliasing draft

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Jorge,
Again, lots of thanks for your response.

I have doubts regarding your statement “the IP A-D per EVI route carries the 
BGP encapsulation extended community” in the context of pure EVPN-MPLS.

1.   My reading of Section 5.3.1 of RFC 
8365, nodes that 
support only MPLS encapsulation are not required to add this Extended Community 
to any EVPN routes, and the nodes that receive EVPN routes without this 
Extended Community attached assume MPLS encapsulation

2.   Section 4.4.1 of RFC 9136 also does not require adding this Extended 
Community to EVPN IP Prefix routes, only mentions that it (as well as the 
Router’s MAC Extended Community) “may be added”

3.   Last but not least, Encapsulation Extended community is not mentioned 
at all in Section 3.1 of the 
draft
 that defines construction of IP per-EVI  A-D routes.
With regard to your statement “we never specified how to import routes with a 
single label if they come with multiple route targets and they match different 
MAC-VRFs and IP-VRFs” : I agree that this has never been specified, but, IMHO, 
this was not really needed, because, until now, the standards defining these 
routes have never allowed any alternatives. From my POV the draft creates a new 
situation, where, locking just at the NLRI of the EVPN Type 1 route, it is 
impossible to decide whether it will be installed in the FDB of a MAC-VRF/BD, 
or in the RIB (and FIB) of an IP-VRF.
So I think some text in the draft clarifying this would be most useful.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
Sent: Tuesday, July 11, 2023 9:06 PM
To: Alexander Vainshtein 
Cc: bess@ietf.org; draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org
Subject: [EXTERNAL] Re: RE: Question and comments on the EVPN IP Aliasing draft

Hi Sasha,

In-line too.

Thanks.
Jorge

From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Tuesday, July 11, 2023 at 9:27 AM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Cc: bess@ietf.org mailto:bess@ietf.org>>, 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org
 
mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>>
Subject: RE: RE: Question and comments on the EVPN IP Aliasing draft

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Jorge,
Lots of thanks for your response.

Please see more comments inline below.

Regards,
Sasha

From: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Sent: Tuesday, July 11, 2023 6:35 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Cc: bess@ietf.org; 
draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org
Subject: [EXTERNAL] Re: RE: Question and comments on the EVPN IP Aliasing draft

Hi Sasha,

Let me try to reply to your questions:

How can a PE that receives an EVPN Type 1 route decide whether it is a per-EVI 
Ethernet A-D route or a per-EVI IP A-D route?
[jorge] The IP A-D per EVI route carries a route target of an IP-VRF.
[[Sasha]] Yes, I have assumed the same. But what is supposed to happen if an 
A-D per-EVI route carries RTs that match both some IP-=VRF and some MAC-VRF in 
the receiving PE? Should such a route be simply treated as an error (and, if 
yes, what would be the action on it), or should one of the two possibilities 
given priority? Such a route clearly could not be installed in both places.
[jorge] I don’t think we need to specify that in the draft, in the same way we 
never specified how to import routes with a single label if they come with 
multiple route targets and they match different MAC-VRFs and IP-VRFs. Clearly 
if the advertising PE does as specified, it will send different routes for ESIs 
in MAC-VRFs or in IP-VRFs. So what you are describing is a non-expected 
scenario. Even so, the receiving PE could potentially import it in two places 
(I don’t see why not), but the ro

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

[Jorge Rabadan (Nokia)]

Hi Jeffrey,

Thanks for reviewing.
Please see my comments in-line with [Jorge]. All those are addressed in version 
08.

Thx
Jorge

From: Jeffrey (Zhaohui) Zhang 
Date: Tuesday, September 26, 2023 at 1:55 PM
To: 'Ali Sajassi (sajassi)' , John E Drake 
, Jorge Rabadan (Nokia) 
Cc: 'BESS' 
Subject: Questions on draft-sajassi-bess-evpn-ip-aliasing-07

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Hi,

To prepare for the adoption call, I read the draft and have some questions and 
nit comments. If a point has been discussed before, a link to the email archive 
is appreciated.

   ... If H1 is
   locally learned only at one of the multi-homing PEs, PE1 or PE2, due
   to LAG hashing, PE3 will not be able to build an IP ECMP list for the
   H1 host route.

Perhaps remove the red text so that it is clear that "due to LAG hashing" is 
for "H1 is locally learned only …" rather than for "PE3 will not be able to …".
[Jorge] ok, done.

For the following three subsections:

1.1.  Ethernet Segments for Host Routes in Symmetric IRB
   …
   With Asymmetric IRB [RFC9135], …

1.2.  Inter-subnet Forwarding for Prefix Routes in the Interface-less
  IP-VRF-to-IP-VRF Model

   In the Interface-less IP-VRF-to-IP-VRF model described in [RFC9136]
   …

1.3.  Ethernet Segments for Prefix routes in IP-VRF-to-IP-VRF use-cases

   This document also enables fast convergence and aliasing/backup path
   to be used even when the ESI is used exclusively as an L3 construct,
   in an Interface-less IP-VRF-to-IP-VRF scenario [RFC9136].

Do we need to discuss the asymmetric model? It seems to be irrelevant.
[Jorge] in the asymmetric model, the remote nodes are attached to the same 
broadcast domain as the multi-homing PEs. Hence, Aliasing/Backup functions are 
fully defined in the existing specs and you are right, we don’t need to specify 
new procedures. The asymmetric model would only be relevant for section 1.1, 
and that’s why section 1.1 describes how the existing procedures provide a 
solution for asymmetric IRB.

Both 1.2 and 1.3 mention “Interface-less IP-VRF-to-IP-VRF scenario” in RFC9136 
though they are about different scenarios. Perhaps the section titles could be 
more accurate – in fact, they could be more consistent with the a/b/c use cases 
preceding 1.1. The following is a suggestion:

1.1. MAC/IP routes with symmetric IRB
1.2. IP Prefix routes with interface-less model
1.3. IP Prefix routes with ESI being a pure L3 construct
[Jorge] it’s a fair point, I modified the titles, inspired by you suggestion, 
as follows:
“1.1.  Multi-Homing for MAC/IP Advertisement Routes in Symmetric IRB
1.2.  Multi-Homing for IP Prefix Routes in the Interface-less IP-VRF-to-IP-VRF 
Model
1.3.  Multi-Homing for IP Prefix routes with Layer 3 Ethernet Segments”

In 1.3.1:

   In these use-cases, sometimes the CE supports a single BGP session to
   one of the PEs (through which it advertises a number of IP Prefixes
   seating behind itself) and yet, it is desired that remote PEs can
   build an IP ECMP list or backup IP list including all the PEs multi-
   homed to the same CE.

I initially wondered with how PE2 would know to forward traffic to the CE since 
it does not learn the routes from the CE, until it came to me that PE1 will 
re-advertise type-5 routes to every PE. I also see it is explicitly mentioned 
in 4.2. It would be good to briefly mention it in 1.3.1 as well.

It’s also worth pointing out that both PE1 and PE2 can multi-path via each 
other.

[Jorge] ok, I added the following. Let me know if it helps. The multi-path bit 
across a local and a RT-5 is probably feasible if there are other CEs attached 
to PE2, but I believe it would complicate the use case.

“This document provides a solution so that PE3 considers PE2 as a next-hop in 
the IP ECMP list for CE1's prefixes, even if PE2 did not advertise the IP 
Prefix routes for those prefixes in the first place. The solution uses an ESI 
in the IP Prefix routes advertised from PE1 so that, when imported by PE2, PE2 
installs the route as local, since PE2 is also attached to the Ethernet Segment 
identified by the ESI.”

1.3.2 does not seem to be a different use case from 1.3.1. It can be viewed as 
a special case of 1.3.1 – PEC’s attachment to the ES is down. Perhaps fold 
1.3.2 into 1.3.1 as a special case?
[Jorge] that’s correct, I added the following text, let me know if it helps:

“There are two use cases analyzed and supported by this document:
IP Aliasing for EVPN IP Prefix routes
IP Aliasing in a Centralized Routing Model
Both use cases are resolved by the same procedures, and the scenario in Section 
1.3.2 can be considered a special case of Section 1.3.1.”

For the following:

4.1.2.  IP A-D per ES route and SRv6 Transport

   When an SRv6 transport is used, each IP A-D per ES route MUST carry
   an SRv6 L3 Service TLV within the BGP Prefix-SID attribute [RFC9252].
  

Re: [bess] [Editorial Errata Reported] RFC9135 (7683)

[Rebecca VanRheenen]

Hi Andrew,

We are unable to verify this erratum that the submitter marked as editorial.  
Please note that we have changed the “Type” of the following errata 
report to “Technical”.  As Stream Approver, please review and set the 
Status and Type accordingly (see the definitions at 
https://www.rfc-editor.org/errata-definitions/).

You may review the report at: 
https://www.rfc-editor.org/errata/eid7683

Please see https://www.rfc-editor.org/how-to-verify/ for further 
information on how to verify errata reports.

Further information on errata can be found at: 
https://www.rfc-editor.org/errata.php.

Thank you.

RFC Editor/rv


> On Oct 19, 2023, at 12:56 AM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC9135,
> "Integrated Routing and Bridging in Ethernet VPN (EVPN)".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7683
> 
> --
> Type: Editorial
> Reported by: Denis Vrkic 
> 
> Section: 4.2.
> 
> Original Text
> -
>  2.  However, if PE2 is configured for asymmetric IRB mode, PE2 will
>   advertise TS4 MAC/IP information in a MAC/IP Advertisement route
>   with a zero Label2 field and no Route Target identifying IP-VRF1.
>   In this case, PE2 will install TS4 information in its ARP table
>   and BT1.  When a packet from TS2 to TS4 arrives at PE1, a longest
>   prefix match on IP-VRF1's route table will yield the local IRB
>   interface to BT1, where a subsequent ARP and bridge table lookup
>   will provide the information for an asymmetric forwarding mode to
>   PE2.
> 
> Corrected Text
> --
>  2.  However, if PE2 is configured for asymmetric IRB mode, PE2 will
>   advertise TS4 MAC/IP information in a MAC/IP Advertisement route
>   with a zero Label2 field and no Route Target identifying IP-VRF1.
>   In this case, PE1 will install TS4 information in its ARP table
>   and BT1.  When a packet from TS2 to TS4 arrives at PE1, a longest
>   prefix match on IP-VRF1's route table will yield the local IRB
>   interface to BT1, where a subsequent ARP and bridge table lookup
>   will provide the information for an asymmetric forwarding mode to
>   PE2.
> 
> Notes
> -
> PE1 will use ARP table for forwarding traffic to PE2 - seems like typo
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC9135 (draft-ietf-bess-evpn-inter-subnet-forwarding-15)
> --
> Title   : Integrated Routing and Bridging in Ethernet VPN (EVPN)
> Publication Date: October 2021
> Author(s)   : A. Sajassi, S. Salam, S. Thoria, J. Drake, J. Rabadan
> Category: PROPOSED STANDARD
> Source  : BGP Enabled ServiceS
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
> 

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Genart early review of draft-ietf-bess-evpn-ac-aware-bundling-03

[Russ Housley via Datatracker]

Reviewer: Russ Housley
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
.

Document: draft-ietf-bess-evpn-ac-aware-bundling-03
Reviewer: Russ Housley
Review Date: 2023-10-20
IETF LC End Date: unknown
IESG Telechat date: unknown

Summary: Almost Ready


Major Concerns:

Section 8: Please clearly identify the IANA registry.


Minor Concerns:

General: Several places, the document includes reference of the form
"[RFC7432] section x.y.z".  It would be much more clear to use the form
"Section x.y.z of [RFC7432]".

Section 6.1 has "attachment circuit ID Extended Community" below the
figure.  Is this a caption?  If so, please center the caption and add a
figure number.


Nits:

General: s/draft/document/ (prepare for publication as an RFC)

Abstract: s/EVPN (Ethernet VPNs) provides/An EVPN (Ethernet VPN) provides/

Section 1: s/This draft proposes/This document specifies/

Section 1.1: s/MAC-2 it can not determine which AC this MAC belongs to/
  /MAC-2, it can not determine the AC associated with this MAC/

Section 1.2: s/which subnet this IGMP membership request belong to/
  /which subnet this IGMP membership request belongs/

Section 1.2: s/forearded to/forwarded to/

Section 3: s/multiple VLAN are configured on/multiple VLAN are configured/

Section 3: s/defined in [RFC7432]/defined in [RFC7432]./

Section 4.1.1.2: s/non multihome/non-multihomed/

Section 4.1.1.2: s/defined in [RFC7432]/defined in [RFC7432]./

Section 4.2.1: s/section 13.1/Section 13.1./

Section 4.2.2: s/in [RFC7432]/in [RFC7432]./

Section 5: s/In this case/In this case,/

Section 6.2: s/is faily large/is fairly large/

Section 6.2: s/This approach is complexifying/This approach adds complexity to/

Section 6.2: s/There is drawback/There is a drawback/
   


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess