[Idr] Re: draft-ietf-idr-5g-edge-service-metadata-32 early Bgpdir review

[Donatas Abraitis <[e-mail]>]

Thanks for answering my questions, looks good to me, just one comment still
"hot" to me :)

>
[Linda] We agree that Section 4.2 should explain why the Site Preference
Index is not simply represented by LOCAL_PREF. How about adding the
following text to Section 4.2 (right after the second paragraph):
*The Site Preference Index is not intended to replace LOCAL_PREF or change
the LOCAL_PREF semantics defined by BGP. LOCAL_PREF expresses local routing
policy within an AS, while the Site Preference Index carries
service-specific site metadata associated with an edge-service route.
Different services at the same site can have different Site Preference
Index values, and local policy may use those values, together with
LOCAL_PREF and other BGP attributes, when selecting among candidate routes
for metadata-aware services.*

[Donatas] "within as AN" is correct, but not complete. If an implementation
has draft-uttaro-idr-bgp-oad (also RFC 7938), then this (wording) might be
changed a bit.


On Fri, May 29, 2026 at 4:45 AM Linda Dunbar <[e-mail]>
wrote:

> Donatas,
>
> Thank you very much for the detailed comments and suggestions. Please see
> the proposed resolution below marked by [Linda].
>
> Linda
>
> -----Original Message-----
> From: Donatas Abraitis via Datatracker <[e-mail]>
> Sent: Wednesday, May 27, 2026 1:40 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: draft-ietf-idr-5g-edge-service-metadata-32 early Bgpdir review
>
> Document: draft-ietf-idr-5g-edge-service-metadata
> Title: BGP Extension for 5G Edge Service Metadata
> Reviewer: Donatas Abraitis
> Review result: Not Ready
>
> My $0.02, I believe these need addressing before WGLC progresses:
>
> RFC 7606 error handling is not specified. It does not specify the
> malformed EMP-attribute handling in RFC 7606 terms (attribute discard,
> treat-as-withdraw, AFI/SAFI disable, session reset).
>
> [Linda] Since the Edge Metadata Path Attribute carries optional
> non-transitive metadata and is not required for BGP reachability, malformed
> Edge Metadata Path information should not cause the route to be withdrawn.
> We can add the following sentence to the end of Section 9 (Validation and
> Error Handling):
> *“**If an Edge Metadata Path Attribute does not have any valid Sub-TLVs,*
> *or its Attribute Flags are inconsistent with the optional non-transitive*
> *definition of this attribute, the "attribute discard" procedure of*
> *[RFC7606] is applied.**”*
>
> Behavior under route aggregation is undefined. I could not find any text
> on how the EMP attribute behaves when an aggregator combines routes
> carrying different EMP values, or some with and some without EMP.
>
> [Linda] The draft does not define EMP behavior under general BGP route
> aggregation because EMP is an optional non-transitive attribute scoped to
> the metadata distribution domain. The intended deployment model is for
> egress routers to advertise metadata for specific edge-service routes
> toward ingress routers or RRs, rather than through intermediate aggregation
> points.
> That said, you are correct that some clarification would be helpful. How
> about adding the following paragraph to the end of Section 4.1.2:
> *“**The Edge Metadata Path Attribute is intended to describe the specific
> edge service route to which it is attached. This document does not define
> aggregation of Edge Metadata Path Attribute values across multiple BGP
> routes. A BGP speaker that locally originates an aggregate route MUST NOT
> infer or copy Edge Metadata from component routes unless it explicitly
> originates new Edge Metadata for the aggregate route by local policy**.*
> *”*
>
> AS-Scope cannot express the multi-AS case that the draft itself permits.
> §10 says "A single BGP Administrative Domain can consist of one AS or
> multiple ASes." But the AS-Scope Sub-TLV in §6.1 carries exactly one 32-bit
> AS value, and §4.1.3's duplicate-Sub-TLV rule says only the first
> occurrence is used.
> There is therefore no way to express a multi-AS scope. Or we should
> clearly say that for this Sub-TLV. Or AS-Scope must carry a list?
> [Linda] Thank you for catching this. The intended encoding is that the
> AS-Scope Sub-TLV can carry one or more 32-bit AS values in a single
> Sub-TLV. The Length field determines how many AS values are present.
> Therefore, a multi-AS metadata distribution domain can be expressed by
> including multiple AS values in the same AS-Scope Sub-TLV, rather than by
> repeating the AS-Scope Sub-TLV.
> Section 6.1 Length field description needs to reflect this:
> Old:
> Length (8 bits)">Specifies the total length in octets, excluding the
> sub-Type and the length field. For the AS-Scope Sub-Type, the Length SHOULD
> be 6
> New:
> *Length: Specifies the total length in octets of the value field,
> excluding the Sub-Type and Length fields. For the AS-Scope Sub-TLV, the
> value field consists of the Reserved field followed by one or more 32-bit
> In-Scope AS values. Therefore, the Length field is **1** + 4*N, where N
> is the number of In-Scope AS values and N MUST be at least 1.*
>
> Old:
> In-Scope AS-Value (32 bits):">AS value that is recognized by the BGP
> speaker in the domain.
>
> New:
> *In-Scope AS-Value: One or more 32-bit AS values that identify ASes within
> the intended metadata distribution domain. When multiple ASes are included,
> they are encoded as consecutive 32-bit AS values within the same AS-Scope
> Sub-TLV. A receiver considers the AS-Scope check successful if the local
> AS, or an AS recognized by local configuration as part of the same metadata
> distribution domain, matches any of the included AS values.*
>
>
> AS-Scope is missing AS 0 and confederation handling. §6.1.1 should add:
> An AS-Scope value of 0 MUST be treated as invalid per RFC 7607.
> Confederation behavior (RFC 5065): does AS-Scope refer to member-AS or
> confederation-identifier?
> [Linda] That is a very good point. How about adding the following
> paragraphs after the first paragraph of Section 6.1.1?
> *An AS-Scope value of 0 is invalid and MUST NOT be used. A receiver that
> encounters an AS-Scope value of 0 MUST ignore that AS value. If all AS
> values carried in the AS-Scope Sub-TLV are invalid, the receiver MUST treat
> the AS-Scope check as failed.*
>
> *When BGP confederations [RFC5065] are used, AS-Scope values refer to
> member-AS numbers for sessions within the confederation, and to the
> confederation identifier for sessions outside the confederation.*
>
> Best-path-selection placement is under-specified for interop. §7.1
> helpfully states metadata-aware policy applies after LOCAL_PREF, but §7.3
> defers preference computation entirely to local policy, and §7.5 falls back
> to RFC
> 4271 only on ties. With multiple Sub-TLVs present (Site Preference,
> Service Delay Prediction, Site Availability), the ordering and combination
> rules are not specified. Two conformant implementations could pick
> different best paths from the same UPDATE set. Please specify either a
> default algorithm or a deterministic ordering.
>
> [Linda] The intent of this document is not to define a new default BGP
> best-path algorithm or a mandatory ordering among EMP Sub-TLVs. Different
> services may need different policy treatment; for example, one deployment
> may prioritize service delay, while another may prioritize site
> availability or site preference. Therefore, the combination of multiple
> metadata values is intentionally left to local policy.
>
> However, we agree that the draft should explicitly state that there is no
> default ordering among Sub-TLVs and that an implementation must not use EMP
> metadata for best-path selection unless local policy specifies which
> metadata is used and how it is combined. How about adding the following
> clarifying text to Section 7.3.
> *This document does not define a default ordering or weighting among Edge
> Metadata Sub-TLVs. When more than one recognized metadata Sub-TLV is
> present, the local policy MUST specify which Sub-TLVs are used and how
> their values are ordered, weighted, or otherwise combined for preference
> computation. In the absence of such local policy, a BGP speaker MUST NOT
> use the Edge Metadata Path Attribute to alter best-path selection and MUST
> evaluate the route using ordinary BGP policy and tie-breaking procedures.*
>
> And Adding the following sentence to the end of Section 7.5:
> *Different local policies may result in different selected paths;
> deployments that require consistent route selection across multiple
> decision points SHOULD configure consistent metadata-aware policy on those
> decision points.*
>
> Relationship to LOCAL_PREF should be justified in-line for Site Preference
> Index. §4.2 introduces a per-site preference index but doesn't explain why
> LOCAL_PREF semantics are insufficient. A short rationale paragraph in §4.2
> would close the obvious reviewer question.
> [Linda] We agree that Section 4.2 should explain why the Site Preference
> Index is not simply represented by LOCAL_PREF. How about adding the
> following text to Section 4.2 (right after the second paragraph):
> *The Site Preference Index is not intended to replace LOCAL_PREF or change
> the LOCAL_PREF semantics defined by BGP. LOCAL_PREF expresses local routing
> policy within an AS, while the Site Preference Index carries
> service-specific site metadata associated with an edge-service route.
> Different services at the same site can have different Site Preference
> Index values, and local policy may use those values, together with
> LOCAL_PREF and other BGP attributes, when selecting among candidate routes
> for metadata-aware services.*
>
>
> Relationship to existing work — AIGP (RFC 7311) and NHC
> (draft-ietf-idr-nhc).
> Please add a short subsection (in §1 or §3) explaining why this requires a
> new attribute rather than extensions to AIGP or NHC. Both have overlapping
> goals (additional metric/characteristic information across iBGP within a
> trusted domain). Without this comparison, the draft will keep attracting
> the same reviewer questions.
>
> [Linda] How about adding the following subsection to Section 3?
> *3.4. Relationship to Existing BGP Metric/Characteristic Attributes*
> *AIGP [RFC7311] carries accumulated IGP metric information for use in BGP
> path selection within an administrative domain. Other IDR work, such as
> NHC, has discussed carrying characteristics associated with the BGP next
> hop. The Edge Metadata Path Attribute defined in this document carries
> different information: service- and site-specific metadata associated with
> selected edge-service routes, such as site preference, site availability,
> service delay prediction, and service-oriented resource information.*
>
> *These metadata values are not accumulated network path metrics and are
> not only characteristics of the BGP next hop. Different services reachable
> through the same egress router or at the same site may have different
> metadata values. Therefore, this document defines a separate attribute to
> carry edge-service metadata, while allowing local policy to combine that
> metadata with other BGP attributes when applicable.**.*
>
> Sub-TLV count bound / DoS. §4.1.3 handles "more than allowed" per-Sub-TLV
> cases but no upper bound exists on total Sub-TLVs per EMP attribute. Please
> add either a normative maximum or a requirement that implementations
> enforce a configurable upper bound, and reflect this in §11.
>
> [Linda] How about adding the following text to Section 4.1.3 after the
> first paragraph:
> *An implementation MUST enforce an upper bound on the total number of
> Sub-TLVs accepted in a single Edge Metadata Path Attribute. The bound MAY
> be configurable and MUST have an implementation-defined default value. If
> the number of Sub-TLVs in an Edge Metadata Path Attribute exceeds the
> configured or implementation-defined bound, the receiver MUST treat the
> Edge Metadata Path Attribute as unusable for metadata-based route selection
> and handle the attribute according to Section 9**.*
>
> In Section 11 Security Considerations, add the following text after the
> first paragraph:
> *The Sub-TLV count limit specified in Section 4.1.3 helps reduce exposure
> to resource-exhaustion attacks caused by excessively large Edge Metadata
> Path Attributes.*
>
> Update-frequency characterisation for measurement-bearing Sub-TLVs. §8
> covers MRAI and operator-set minimum intervals, but Raw Measurement (§4.5)
> and Service Delay Prediction (§4.4) Sub-TLVs are inherently dynamic. Please
> state expected churn and recommended dampening/hysteresis explicitly.
> Currently §8's "default minimum interval ... 30 seconds" is presented as
> guidance but its relation to actual measurement update rate is unclear.
> Modern BGP implementations use MRAI as 0…
>
> [Linda] good point. How about adding the following text in Section 8,
> after the second paragraph:
> *Measurement-bearing Sub-TLVs, such as the Service Delay Prediction
> Sub-TLV and Raw Measurement Sub-TLV, can be derived from local measurements
> that change more frequently than BGP UPDATEs should be advertised. The
> measurement collection interval is deployment specific and is independent
> of the interval at which changed metadata is advertised in BGP.
> Implementations SHOULD apply dampening, hysteresis, or threshold-based
> change detection before advertising updated Edge Metadata Path Attribute
> values, so that small or short-lived measurement fluctuations do not cause
> excessive BGP UPDATE churn.*
>
> Also make the following changes:
> Old:
> The default minimum interval for metrics change advertisement, set at 30
> seconds, is designed to balance responsiveness with stability.
>
> New:
> A default minimum interval of 30 seconds for advertising Edge Metadata
> Path Attribute changes is RECOMMENDED to balance responsiveness with
> stability, unless a deployment configures a different interval*.*
>
>
> Spec bugs:
>
> §6.1: AS-Scope Length is wrong. The text says "the Length SHOULD be 6".
> The encoding is Reserved (1 octet) + In-Scope AS-Value (4 octets) = 5
> octets.
> Compare §4.2 Site Preference Index (identical structure, correctly says
> Length=5).
> [Linda] Yes, fixed in v33.
>
> §8: MRAI characterisation is misleading. "The MRAI timer (typically 30
> seconds for iBGP)" — the 30-second figure is the eBGP default per RFC 4271
> §9.2.1.1.
> iBGP MRAI is typically 0 in modern deployments and vendor defaults. Since
> the draft's timeliness argument depends on this, please correct.
> [Linda] good point. How about the following changes:
> Old:
> The advertisement interval is governed by the underlying BGP mechanisms,
> such as the MRAI timer (typically 30 seconds for iBGP).
>
> New:
> *The advertisement interval is governed by the underlying BGP mechanisms
> and implementation behavior, including any configured MRAI timer. This
> document does not rely on a specific MRAI value for metadata update pacing*
> .
>
> §12.3: section cross-references in the IANA Sub-TLV table are wrong. Site
> Preference says "[this document:4.3]" (actual section is 4.2); Site
> Physical Availability says "[this document:4.4]" (actual 4.3); AS-Scope
> says "[this document:5.1]" (actual 6.1). Several others likely off-by-one.
> Please re-sync the table.
>
> [Linda] Thank you for catching this. They have been updated in v33
>
>
> Nits:
>
> §3.2: typo "parkets" → "packets".
> [Linda] fixed,
>
> §3.2: only IPv4-in-IPv4 (RFC 2003) is mentioned. Please cover IPv6-in-IPv6
> (RFC 2473), or generalize the language to "an IP-in-IP encapsulation
> appropriate for the address families involved".
> [Linda] How about the following wording change in Section 3.2 first
> paragraph?
> Old:
> For routes that carry the Metadata Path Attribute but lack the Tunnel
> Encapsulation Path Attribute, it is recommended that the ingress router
> encapsulate the original packet using an IP-in-IP header.
> New:
> *For routes that carry the Metadata Path Attribute but lack the Tunnel
> Encapsulation Path Attribute, it is recommended that the ingress router
> encapsulate the original packet using an IP-in-IP encapsulation appropriate
> for the address families involved.*
>
>
> §2 Terminology: "edge service Management function" is used in §3.1 but not
> defined. Please add a definition or remove the term.
> [Linda] How about adding the following to Section 2:
> *Edge Service Management Function: A local or centralized function that
> interprets Edge Metadata Path Attribute values and applies
> deployment-specific policy to assist in selecting the preferred path or
> egress router for an edge service. How this function is implemented is
> outside the scope of this document.*
>
> §4.1.1 Characteristics list: §4.1 calls the attribute "optional
> non-transitive", but the Characteristics bullet list in §4.1.1 only says
> "non-transitive". For completeness, the list should also state the
> attribute is Optional and indicate the Path Attribute flag-bit pattern
> (Optional, Non-Transitive, not Partial, length-encoding) per RFC 4271 §4.3.
> [Linda] will change to “optional non-transitive” in the v33.
>
>
> §4.1.3: the case of a single recognized Sub-TLV with an invalid value
> falls under "treat the attribute as present but unusable" via the "none
> recognized for selection" rule. A one-sentence cross-reference confirming
> this would prevent confusion.
> [Linda] We will add one sentence in Section 4.1.3 clarifying that if the
> only recognized Sub-TLVs contain invalid values and are ignored according
> to their Sub-TLV definitions, the Edge Metadata Path Attribute is treated
> as present but unusable for metadata-based route selection.
>
>
>
>


-- 
Donatas