Here’s the review from bgpdir. Sue
From: Donald Sharp <[email protected]> Sent: Thursday, July 23, 2026 3:17 AM To: [email protected] Subject: [bgpdir] Review of draft-ietf-bess-mup-safi-01.txt Tetsuya - Here’s my review of draft-ietf-bess-mup-safi-01.txt: Section 3.1: The legal Architecture Type value is 1, what should happen if a 1 is not received? Section 3.1.3.1 Endpoint/Source Address Length use values 32/128(bits), but absence NkdkJdXPPEBannerStart Be Careful With This Message From (Donald Sharp <[email protected]>)<https://godaddy2.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f35a0420cab1f1b2b5175c0a048e015cffdef799437aac2c7202959620d7ea6031e2aef6af1d1a093a52064caccacc042623a339bf350f4137c86784c4402b25650c3654c46127e982807748685560ab90922f92d18f95ac2712e5dc7d871614f01df7f98800aa1cc041e3cbfce6c9d5f04ed4b57d2bfcecf6825c65ff96c0de77a7a734dd668adffe9033e0624eeca5f9ab23ffef5ce125898566a7da9315a18642904b2700a5975829697166e439431f4ea2f32d8f89997dc3f6c4f749236a899ddb7df3d44ad27d631086477ff0de55372018d5f00687a> Learn More<https://godaddy2.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f35a0420cab1f1b2b5175c0a048e015cffdef799437aac2c7202959620d7ea6031e2aef6af1d1a093a52064caccacc042623a339bf350f4137c86784c4402b25650c3654c46127e982807748685560ab90922f92d18f95ac2712e5dc7d871614f01df7f98800aa1cc041e3cbfce6c9d5f04ed4b57d2bfcecf6825c65ff96c0de77a7a734dd668adffe9033e0624eeca5f9ab23ffef5ce125898566a7da9315a18642904b2700a5975829697166e439431f4ea2f32d8f89997dc3f6c4f749236a899ddb7df3d44ad27d631086477ff0de55372018d5f00687a> Potential Impersonation The sender's identity could not be verified and someone may be impersonating the sender. Take caution when interacting with this message. NkdkJdXPPEBannerEnd Tetsuya - Here’s my review of draft-ietf-bess-mup-safi-01.txt: Section 3.1: The legal Architecture Type value is 1, what should happen if a 1 is not received? Section 3.1.3.1 Endpoint/Source Address Length use values 32/128(bits), but absence of Source Address is described as “0 bytes”. This field cannot be both bits and bytes. Section 3.1.4 and 3.1.4.1 Endpoint length covers Address + architecture-specific Identifier. IPv4 max 64, IPv6 max 160. TEID is “0-4 octets” derived from Endpoint Length, but non-octet-aligned lengths are not forbidden. “TEID value of 0 is malformed” conflicts with zero-length TEID used for aggregation - there is no TEID value when length is 0. Section 3.3.9 “MUST delete all the routes from the associated routing instance” on MP_UNREACH or Thype 1 ST is over-broad. Shouldn’t withdraw delete only matching Type 1 ST NLRI’s, not every route? Section 3.3.1 -vs- Section 3.1.1 ISD NLRI has RD + Prefix Length + Prefix, not Address. 3.3.3 requires matching “Address field in the NLRI” to the Prefix-SID locator originator. There does not seem to be an address field, just a cut-n-paste error of some sort? Section 3.1.3.1, 3.1.5 and 5 All three TLV’s say “Applicable to: ST2”. Type 1 ST NLRI includes a TLV’s field, and we are told that they are for use in ST1 and ST2. Source address exists inline in ST1 and as a TLV type 3(ST-2 only). Session parameters(TEID + QFI) duplicates ST1 fixed fields. Can we get a clarification on how this should work for ST1? Type 2 ST - 3.1.4.1, 3.1.5.1 and 3.3.10 ST2 carries TEID in the architecture-specific identifier and may also contain session parameters TLV (TEID + QFI) for the Internetwork Endpoint. There are no rules for both are present and they disagree, or when QFI is optional -vs- required. Route Keys - 3.1.3 BGP route key for Type 1 ST is only RD + Prefix Length + Prefix. TEID, QFI, Endpoint and Source are non-key. Multiple sessions for the same UE prefix collide as one NLRI. Is this inetentional? It should be stated or expanded to fix the possible collision? RT is required for import but not on export/advertise 3.3.4 -vs- 3.3.6 3.3.6 imports DSD via Route Targets. 3.3.4 generation only mandates MUP extended community, never the RT. Should generation guarantee the RT? Communities on MP_UNREACH are not needed? 3.3.2, 3.3.5, 3.3.8 and 3.3.11 Withdrawal procedures require attaching the RT/MUP EC’s. BGP withdrawal is by NLRI key. Are these really necessary to send on withdrawal events? IPv6 Nexthop for AFI=1 not specified - 3.3.1, 3.3.4 Discovery routes MUST set nexthop to PE ipv6 address even when the AFI is ipv4. Do we need explicit encoding rules for this? Thanks! Donald
_______________________________________________ bgpdir mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
