Hi Jorge, Thank you for preparing these changes and for accommodating. Much appreciated.
Cheers, Med De : Jorge Rabadan (Nokia) <[email protected]> Envoyé : jeudi 5 mars 2026 14:02 À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; The IESG <[email protected]> Cc : [email protected]; [email protected]; [email protected]; [email protected] Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-bess-evpn-ipvpn-interworking-15: (with DISCUSS and COMMENT) Hi Med, Thank you very much for the great review! Revision 17 addresses these two comments (in addition to Ketan’s remarks): --- # 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. [Med] Can we remind that in the text? [jorge] NEW: "The D-PATH Path Attribute MUST NOT appear more than once in the Path Attributes of a given BGP UPDATE message. 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. This behavior follows [RFC7606], including the associated logging considerations." --- ## 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. [Med] I would sort them for reader’s convenience. [jorge] Done. --- Thanks. Jorge From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Date: Monday, March 2, 2026 at 4:19 AM To: Jorge Rabadan (Nokia) <[email protected]<mailto:[email protected]>>, The IESG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: RE: Mohamed Boucadair's Discuss on draft-ietf-bess-evpn-ipvpn-interworking-15: (with DISCUSS and COMMENT) Hi Jorge, all, Thank you for the follow-up and for taking care of the review. I also checked -15/16 diff. I like the changes. I will update my ballot and let you decide whether to implement changes per the comments below. Please see inline. Cheers, Med De : Jorge Rabadan (Nokia) <[email protected]<mailto:[email protected]>> Envoyé : samedi 28 février 2026 22:36 À : BOUCADAIR Mohamed INNOV/NET <[email protected]<mailto:[email protected]>>; The IESG <[email protected]<mailto:[email protected]>> Cc : [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-bess-evpn-ipvpn-interworking-15: (with DISCUSS and COMMENT) 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]<mailto:[email protected]>> Date: Tuesday, January 20, 2026 at 2:02 AM To: The IESG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[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. [Med] Thank you ## 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. [Med] ACK # 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. [Med] ACK. Note that all these benefits can still be provided without having this split, but I understand that this is already implemented and as such. # 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. [Med] Thanks for confirming. 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. [Med] Not sure this will be needed in the future, but let’s see. # 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. [Med] ACK # 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. [Med] This is great, thanks. # 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. [Med] ACK # 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. [Med] This is indeed better. Thanks. # 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 [Med] ACK # 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 [Med] ACK ## Also, please add a normative reference for AIGP (RFC 7311). [jorge] fixed [Med] ACK ---------------------------------------------------------------------- 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. [Med] Thanks # 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. [Med] I do see a value in mentioning this in the text, but leave it to you to decide. # 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? [Med] Any thought about this one? ## Should these IDs be bound to a specific network, interface, etc.? [jorge] ok, we removed that and made sure it is specified later. [Med] ACK # 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. [Med] Thank you. # 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. [Med] OK. # 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. [Med] Can we remind that in the text? # 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. [Med] Thanks # 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. [Med] ACK ## 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. [Med] I would sort them for reader’s convenience. ## 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. [Med] ACK ## 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. [Med] Thanks. ## Change all “PE device” to “PE” ## Idem, change “CE device” to “CE” [jorge] fixed both things. [Med] ACK ## "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. [Med] ACK ## Add a note somewhere near the figure that “tnls” or “tnl” refer to “tunnel(s)”. [jorge] ok, done. [Med] ACK ## :: OLD: SHOULD NOT be propagated:: NEW: SHOULD NOT be propagated: OLD: Applicable references include:: NEW: Applicable references include: [jorge] fixed both things. [Med] ACK ## 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. [Med] ACK. Cheers, Med [1] https://datatracker.ietf.org/doc/statement-iesg-statement-on-assignable-codepoints-for-examples-in-ietf-specifications/ ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
