Need to describe the scale of the prefixes with Metadata Path Attribute attached

[lindadunbar]

Added the following to the Section 4.1.1:

Only a small subset of BGP UPDATE messages include the Metadata Path Attribute. The choice of which prefix to carry the Metadata Path Attribute is determined by local policies. The Metadata Path Attribute can be included in a BGP UPDATE message [RFC4271] together with other BGP Path Attributes [IANA-BGP-PARAMS], such as Communities [RFC4360], NEXT_HOP, Tunnel Encapsulation Path Attribute [RFC9012], etc.

[suehares]

Confirm that section 4.1.1 - has all the sub-families listed in this text:

-23 text:/ Can be packed with NLRI(AFI/SAFI) Unicast (1/1, 2/1), Label Unicast (AFI/SAFI - ), IPv6 Anycast ./

The text needs to specify AFI/SAFI of each one.

I believe that you mentioned 2 other prefixes in video chat.

[lindadunbar]

added in v-22

[lindadunbar]

Add an AS-Scope SubTLV inside the Section 5 (Service Metadata Propagation Scope)

5.1. AS-Scope SubTLV

To address the potential issue where the NO-ADVERTISE well-known community of the BGP UPDATE message can be dropped by some routers, a new AS-Scope Sub-TLV can be included in the Metadata Path Attribute to prevent the Metadata Path Attribute from being leaked to unintended Autonomous Systems (ASes). The AS-Scope Sub-TLV will enforce stricter control over the propagation of the metadata by associating it with specific AS numbers.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AS-Scope Sub-Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-Scope AS-Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 9: AS-Scope Sub-TLV

• AS-Scope Sub-Type (16 bits): AS-Scope Sub-type=7 (specified in this document).

• Length (8 bits) Specifies the total length in octets, excluding the sub-Type and the length field. The Length is 6 for the AS- Scope Sub-Type.

• Reserved (8 bits): Reserved for future use.

• In-Scope AS-Value (32 bits): AS value that is recognized by the BGP speaker in the domain.

5.1.1. AS-Scope Value Checking Procedure

When a router receives a BGP UPDATE message containing the AS-Scope Sub-TLV, it must perform the following steps to process the AS-Scope value:

• AS Recognition: The router will check the AS value in the AS-Scope Sub-TLV.

• If the AS value matches the local AS or a recognized AS in its configuration, the router will process the update as usual. If the AS value does not match or is not recognized, the router MUST drop the BGP UPDATE message containing the AS-Scope Sub-TLV.

• Forwarding Rules: The AS-Scope Sub-TLV ensures that the Metadata Path Attribute is only propagated within the intended ASes, thereby preventing unauthorized dissemination of sensitive metadata.

• Non-Transitive: The AS-Scope Sub-TLV is marked as non-transitive to ensure it is not forwarded beyond the intended scope.

  Example Usage:

  Consider a scenario where a router in AS 65001 advertises a BGP UPDATE message with the AS-Scope Sub-TLV set to AS 65001. When another router in AS 65002 receives this update, it will check the AS-Scope Sub-TLV value:

  Since AS 65002 does not match the AS value 65001, the router in AS 65002 will drop the update, preventing the metadata from leaking into AS 65002.

  This mechanism ensures that the metadata remains confined to the intended ASes, enhancing the security and control over the propagation of BGP metadata. draft-ietf-idr-5g-edge-service-metadata-22-July_21.txt

[jhaas-pfrc]

I believe this issue is addressed. Closing issue.