Hi Mohamed, Thanks for your through review! Revision 16 addresses your comments. Please let us know if that clears your DISCUSS.
Please see some comments in-line with [jorge]. Thx Jorge From: Mohamed Boucadair via Datatracker <[email protected]> Date: Tuesday, January 20, 2026 at 2:02 AM To: The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Mohamed Boucadair's Discuss on draft-ietf-bess-evpn-ipvpn-interworking-15: (with DISCUSS and COMMENT) 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. Mohamed Boucadair has entered the following ballot position for draft-ietf-bess-evpn-ipvpn-interworking-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ipvpn-interworking/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Jorge, Ali, Eric, John, Wen ,Jim, and Adam, Thank you for the effort put into this specification. Thanks to Qin Wu for the OPSDIR review. See a related point below. The specification is dense but reads well, overall. The document also includes several examples for illustration, which is really helpful. However, I found it a bit unfortunate that protocol machinery aspects are mixed with operational considerations. Separating those would be an enhancement (e.g., such as the approach followed in RFC 9135). I’m not insisting to make a change, but would be happy if you decide to do so :-) Please find below points for DISCUSSion, some of them are process-related. # Process Items ## IETF Last Call Comments Unless I’m mistaken, I don’t see a follow-up or replies to comments received during the IETF LC. I see at least the comments from Qin are unanswered. I’m not echoing some of the points raised there (e.g., update or not of the base BGP spec) as I think that discussion belong to the IETF LC comments. [jorge] Revision 16 addresses all the comments. We have responded to all reviewers, providing our resolutions and expressing our appreciation for their valuable comments. ## Use of documentation values The document includes several examples that with ASN (e.g., Section 6.2). These examples should be updated to make use of the range defined in RFC5398 per the following from an IESG statement on the matter [1]: “Authors must use reserved values for documentation in the usage examples whenever such a range is available for a type covered by the documentation.” [jorge] changed the ASNs to values reserved for documentation. # D-PATH Internal structure CURRENT: Octets v 0 1 2 3 4 5 6 +-----------------------+-----------+ | Global | Local | | Admin | Admin | +-----------------------+-----------+ Figure 6: D-PATH Domain Segment Why providing the internal structure of domain-ids is needed? Which problems are we solving by requiring this split? Of course, Operators can adopt an internal structure if they which so, but I’m not sure that is something that needs to be signaled in the protocol itself. Implementations (especially at the receiver side) should not associate any meaning with these bits. Also, note that getting rid of the split would also help soften issues related to leak of local information that can be inferred from the domain-ID. [jorge] you are right that there is no especial meaning for the receiver, other than comparing the domain-id value with the local ones. However, the authors agreed that defining a structured format, as described above, provides operational benefits. In particular, it allows operators to encode geographic or administrative information if desired, facilitates troubleshooting when inspecting routes in the RIB-In, and helps ensure DOMAIN-ID uniqueness across domains. Furthermore, all current field deployments and implementations use this structured format when configuring the DOMAIN-ID. We believe that adopting a common convention improves operational consistency and simplifies configuration for operators. # Complexity CURRENT: If the act of prepending a new domain causes an overflow in the domain segment (i.e., more than 255 domains), the local gateway PE MUST prepend a new segment and prepend its own domain to this new segment. The specification includes a provision for multiple segment, each segment with up to 255 domains. This adds a complexity to implementations and also can trigger misbehaviors of intermediate nodes that may present a very lengthy list of segments. Do we have or envisage cases where a communication may include 255 interworking PEs? [jorge] D-PATH is defined for use with two specific SAFIs and, as described in this document, is intended for “walled garden” inter-domain scenarios. Also, the mechanism has been deployed for several years, and operational experience indicates that the number of domains carried in a given ISF route is typically limited to a small number. In the initial design discussions, only a single domain segment was permitted. However, early WG feedback indicated the need for a future-proof encoding that avoided a 255-domain limitation. # Consistency CURRENT: 2. The gateway PE MAY advertise that ISF route with a D-PATH attribute into one or more of its configured domains, or * In the above example, if the EVPN route is received without D-PATH, the gateway PE will add the D-PATH attribute with one segment {length=1, <6500:1:EVPN>} when re-advertising to domain 6500:2. These parts (and other similar constructs in the draft) assume that D-PATH will automatically be added, while this is subject to explicit configuration per: CURRENT: By default, the BGP D-PATH attribute is not advertised and MUST be explicitly enabled by configuration on the Gateway PEs. Such text (and similar) should state that ,”assuming this is explicitly configured per Section X”. [jorge] ok, added this in all the cases in section 4. # Behavior Ambiguity There are several parts of the spec which leaves it unspecified when a given behavior is safe to ignore. An example is provided below: CURRENT: The Gateway PE SHOULD NOT copy the above Extended Community types from the original ISF route into the re-advertised ISF route. I’m not listing all of those, but I trust the authors will check through the doc. [jorge] ok. For this one, we clarified the text: NEW: The Gateway PE SHOULD NOT copy the above Extended Community types in "a", "b" and “c" from the original ISF route into the re-advertised ISF route. Certain Extended Communities may influence how the receiving PE processes the route. Propagating such attributes into another domain could therefore lead to unintended behavior. For example, if the BGP Encapsulation Extended Community is propagated into a destination domain that uses a different encapsulation, a receiving PE in that domain might interpret the label field of the EVPN ISF route according to an encapsulation context that does not apply locally [RFC8365]. This could result in the route being discarded or programmed with incorrect encapsulation parameters. # Behavior conflict CURRENT: However, the following Extended Community types SHOULD NOT be propagated:: a. BGP Encapsulation Extended Communities, as defined in [RFC9012]. b. Route Target Extended Communities. Route Targets MUST NOT be propagated and MUST be re-initialized when re-advertising the ISF route into a different domain. The re-initialized Route Target value MAY or MAY NOT match the value used in the original route. There is a conflict between the normative language in the preamble and the one specific in the second bullet. Please fix that. [jorge] good catch, fixed now. # DOMAIN-ID unicity CURRENT: That is, a route is considered looped if it contains at least one DOMAIN-ID that matches any local DOMAIN-ID configured on the Gateway PE, regardless of the ISF_SAFI_TYPE value. How unicity of domain-ids of involved domains is supposed to be ensured? [jorge] The uniqueness of the domain-ids should be guaranteed by the operator’s proper configuration. The structure given to the domain-id may help them to that end. We added this text: NEW The IP-VRF of a Gateway PE that interconnects two domains is associated with two distinct DOMAIN-IDs, one per domain. These DOMAIN-IDs MUST be different (e.g., 6500:1 for EVPN and 6500:2 for IPVPN). Each domain MUST be identified by a unique DOMAIN-ID. All Gateway PEs attached to the same domain MUST use the same DOMAIN-ID value to represent that domain. # RFC4659 is normative This is actually needed for VPN-IPv6 AF. Specifically, this is needed for this SHOULD: CURRENT: Implementations SHOULD apply the relevant error-handling rules specified for each supported route type. Applicable references include:: BGP IP routes: [RFC4760], [RFC8950]. IPVPN routes: [RFC4364], [RFC4659]. [jorge] fixed # draft-ietf-idr-wide-bgp-communities This I-D is normative as it is needed, for example, in the following: CURRENT: When advertising the route into a different domain, the gateway PE SHOULD propagate only the following set of attributes. All other Path Attributes SHOULD NOT be propagated: * AS_PATH * D-PATH (only when advertising IPVPN [SAFI 128] or EVPN routes) * IBGP-only attributes (when advertising to IBGP peers): LOCAL_PREF, ORIGINATOR_ID, CLUSTER_ID * MULTI_EXIT_DISC (MED) * AIGP * COMMUNITY, EXTENDED_COMMUNITY, LARGE_COMMUNITY, and WIDE_COMMUNITY (as defined in [I-D.ietf-idr-wide-bgp-communities]), except where explicitly excluded in Item 4 below. [jorge] fixed ## Also, please add a normative reference for AIGP (RFC 7311). [jorge] fixed ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Interconnection mapping Clarify early in the document whether an interco PE can be multi-homed or is 1:1 assumed? [jorge] We added text in section 3 to clarify that a composite, gateway or composite/gateway PE can interconnect more than two domains. # Inter-connection & bidirectionality You may consider whether symmetric or asymmetric interco PEs are supported by the model. [jorge] PEs that follow these procedures advertise and process ISF routes in accordance with the existing specifications. The best-path selection and forwarding decisions remain unchanged. As a result, symmetric or asymmetric traffic behavior depends solely on how the PEs perform routing and forwarding under the existing specifications. For the moment we assume there is no need to indicate that, but let us know otherwise, please. # DOMAIN-IDs in Section 3 The configuration of DOMAIN-IDs is mentioned at least twice in this section: CURENT: A gateway PE is always configured with multiple DOMAIN- IDs. And A Gateway PE follows the procedures defined in Section 8. A gateway PE is always configured with multiple DOMAIN-IDs. These mentions seems to be provided too early on the document. At least the following is not clear at this stage: ## Should the interco procedure be disable if no DOMAIN-ID is provided? ## Should these IDs be bound to a specific network, interface, etc.? [jorge] ok, we removed that and made sure it is specified later. # ISF_SAFI_TYPE for correct service verification CURRENT: The ISF_SAFI_TYPE field is informational and does not have any impact on the loop detection or BGP Path selection procedures. Conveying ISF_SAFI_TYPE is useful for operations as this can be used to check that intended interworking is in place. Maybe consider adding a note about such use (even as an example). [jorge] Added: NEW: Encoding the ISF_SAFI_TYPE provides operational benefits, as it allows operators to verify that the intended interworking is in place and that the route has traversed the expected domains using the intended ISF SAFIs in each domain. # Provisions for topology hiding CURRENT: Intermediate entries in the list are domains that the ISF IPVPN or EVPN route has transited. Are there deployment cases where intermediate domains would not need to reveal their presence of leaf domains? [jorge] we don’t see any. Intermediate domains need to be revealed in D-PATH so that the loop procedures and best path selection procedures work. # Logging CURRENT: If multiple instances of the D-PATH attribute are present, all instances other than the first MUST be discarded, and the UPDATE message MUST continue to be processed, as per [RFC7606]. Can we mention that this event is logged at least once? [jorge] we want to be consistent with RFC7606 when multiple instances of an attribute exist, and that includes the logging considerations in RFC7606. Let us know if that is not ok. # Automatic behavior are problematic CURRENT: 1. Upon receiving an ISF route, the gateway PE imports the route into the associated IP-VRF and stores the original BGP Path Attributes. For this part (and similar one), please add “assuming no validation error is encountered and absent a policy otherwise” [jorge] added. # Nits ## Introduction OLD: This document defines the concept of an Interworking PE Section 3, NEW: This document defines the concept of an Interworking PE (Section 3), [jorge] fixed. ## Section 3 I’m curious which logic is used for the ordering of the terms in this section. [jorge] we kept adding terms based on what was needed, the terms were normally added together in groups. But we can sort them better if the editor prefers that. ## Figure 1 A “+” near “Eth-Tag x” which needs to be “|” OLD: ----------------------*Bridge | | +------ | | | |Table(BT1)| | +-----------+ / \ \ MPLS/NVO tnl +-------->| *---------* |<--> | Eth | -------+ | | | |Eth-Tag x + |IRB1| | \ / / / Eth / \<-+ | | +----------+ | | | +------ NEW: ----------------------*Bridge | | +------ | | | |Table(BT1)| | +-----------+ / \ \ MPLS/NVO tnl +-------->| *---------* |<--> | Eth | -------+ | | | |Eth-Tag x | |IRB1| | \ / / / Eth / \<-+ | | +----------+ | | | +------ ## Figure 1 CURRENT: | +------------------+ | SAFIs | | | 1 +---+ | -------------------------------------------------+ 128 |BGP| | | EVPN +---+ | For consistency with other SAFIs, listing 70 would be more appropriate than the label. [jorge] fixed both things. ## ISF SAFI When first reading this, it can be misinterpreted as this is about defining a new SAFI, while this is more an alias. [jorge] added: NEW The term “ISF SAFI” does not denote a new SAFI. Rather, it is used as a collective reference to the group of SAFIs mentioned earlier. ## Change all “PE device” to “PE” ## Idem, change “CE device” to “CE” [jorge] fixed both things. ## "peering domain level” Peering has a specific when interconnecting domains. Unless you add a qualifier, I would change to “domain interconnection level” or similar. [jorge] ok, done. ## Add a note somewhere near the figure that “tnls” or “tnl” refer to “tunnel(s)”. [jorge] ok, done. ## :: OLD: SHOULD NOT be propagated:: NEW: SHOULD NOT be propagated: OLD: Applicable references include:: NEW: Applicable references include: [jorge] fixed both things. ## optional means that this is not required OLD: While not required, prioritizing the advertisement of the EVPN route before the IPVPN route is an OPTIONAL optimization. NEW: Prioritizing the advertisement of the EVPN route before the IPVPN route is an OPTIONAL optimization. [jorge] ok, done. Cheers, Med [1] https://datatracker.ietf.org/doc/statement-iesg-statement-on-assignable-codepoints-for-examples-in-ietf-specifications/
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
