Hi Donald, Thank you so much for the detail review. Our comments (on behalf of the authors) are inlined #Keyur
From: Susan Hares <[email protected]> Date: Thursday, July 23, 2026 at 12:19 AM To: BESS <[email protected]> Cc: Mankamana Mishra (mankamis) <[email protected]>; Zheng Zhang <[email protected]> Subject: [bess] FW: [bgpdir] Review of draft-ietf-bess-mup-safi-01.txt 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? #Keyur: We will add the relevant text that indicates any other Architecture Type value received should be ignored and the NLRI should be silently ignored. An implementation MAY log an error for any analysis. 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. #Keyur: Good point yes.. 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. #Keyur: TEID may not be present in which case TEID has no value. If TEID is present then the IPv4 (for example) will have a length of 64 and in that case, 0 value of TEID is invalid. We can add a clarification to make it clear. 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? #Keyur: Correct. Will fix the text. 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? #Keyur: Correct. Will clarify the text. 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? #Keyur: Will add the clarification text. To summarize; the ST2 route addresses roaming as well as non-roaming use case and TLVs are meant to apply appropriately. 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. #Keyur: This would be a function of policy. The MUP architecture draft section 6.2 does make a reference. We can definitely add text to suggest when QFI is option -vs- required. (https://datatracker.ietf.org/doc/html/draft-ietf-dmm-mup-architecture). 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? #Keyur: Yes. RT is required for import but not on export/advertise 3.3.4 -vs- 3.3.6 #Keyur: will fix the text. 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? #Keyur: will fix the text. Communities on MP_UNREACH are not needed? 3.3.2, 3.3.5, 3.3.8 and 3.3.11 #Keyur: Correct. Withdrawal procedures require attaching the RT/MUP EC’s. BGP withdrawal is by NLRI key. Are these really necessary to send on withdrawal events? #Keyur: Sorry dont get the comment. We are suggesting to send on MP_UNREACH attribute. 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? #Keyur: Not really as various modes are typically supported. Best Regards, Keyur Thanks! Donald [EXTERNAL]
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
