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. ## 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.” # 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. # 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? # 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”. # 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. # 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. # 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? # 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]. # 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. ## Also, please add a normative reference for AIGP (RFC 7311). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Interconnection mapping Clarify early in the document whether an interco PE can be multi-homed or is 1:1 assumed? # Inter-connection & bidirectionality You may consider whether symmetric or asymmetric interco PEs are supported by the model. # 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.? # 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). # 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? # 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? # 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” # 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), ## Section 3 I’m curious which logic is used for the ordering of the terms in this section. ## 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. ## ISF SAFI When first reading this, it can be misinterpreted as this is about defining a new SAFI, while this is more an alias. ## Change all “PE device” to “PE” ## Idem, change “CE device” to “CE” ## "peering domain level” Peering has a specific when interconnecting domains. Unless you add a qualifier, I would change to “domain interconnection level” or similar. ## Add a note somewhere near the figure that “tnls” or “tnl” refer to “tunnel(s)”. ## :: OLD: SHOULD NOT be propagated:: NEW: SHOULD NOT be propagated: OLD: Applicable references include:: NEW: Applicable references include: ## 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. 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]
