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

[Linda Dunbar <[e-mail]>]

Donatas,

Thank you! The revision that addressed your comments and suggestions has been posted: https://datatracker.ietf.org/doc/draft-ietf-idr-5g-edge-service-metadata/

Linda

From: Donatas Abraitis <[e-mail]>
Sent: Friday, May 29, 2026 12:24 PM
To: Linda Dunbar <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: draft-ietf-idr-5g-edge-service-metadata-32 early Bgpdir review

Thanks, better :)
--
Donatas


On 29 May 2026, at 21:35, Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:

Donatas,

Thank you very much for accepting most of the proposed changes. For the remaining one issue, please see the proposed resolution below marked by [Linda2].

Linda

From: Donatas Abraitis <[e-mail]<mailto:[e-mail]>>
Sent: Friday, May 29, 2026 12:42 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: draft-ietf-idr-5g-edge-service-metadata-32 early Bgpdir review

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.

[Linda2] Good point. To avoid implying that LOCAL_PREF is limited only to traditional iBGP use within a single AS, how about making the following wording change:
Old:
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.

New:
The Site Preference Index is not intended to replace LOCAL_PREF or change the LOCAL_PREF semantics defined by BGP. LOCAL_PREF expresses operator routing policy according to the BGP deployment in which it is used. By contrast, 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.

Thank you,

Linda

On Fri, May 29, 2026 at 4:45 AM Linda Dunbar <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Wednesday, May 27, 2026 1:40 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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