ietf-wg-idr / draft-ietf-idr-5g-edge-service-metadata

Editing for the 5G Service Metadata
0 stars 2 forks source link

Metadata Path Attributive - Clear definition that Attribute is non-transitive #5

Closed suehares closed 8 months ago

suehares commented 9 months ago

Jeff Haas Problem definition

Transitivity: The transitivity of the new path attribute isn't currently clear in the document. Here are some conflicting sections:

4.1. Metadata Path Attribute The Metadata Path Attribute is an optional transitive BGP Path attribute to carry metrics and metadata about the edge services attached to the egress router.

Here, we're saying the attribute is optional, transitive.

4.1.1. Metadata Path Attribute Handling Procedure [...]

When a BGP Speaker does not recognize some of the Sub-TLVs within one Metadata Path Attribute in a BGP UPDATE message, the BGP Speaker should forward the received BGP UPDATE message without any change if the BGP UPDATE message is marked as transitive.

BGP UPDATEs themselves aren't "transitive". What's the intention here? Simply that if the BGP route is propagated that unrecognized TLVs should be propagated?

Perhaps consider using the RFC 4271 normative definition of Route:

Route A unit of information that pairs a set of destinations with the attributes of a path to those destinations. The set of destinations are systems whose IP addresses are contained in one IP address prefix carried in the Network Layer Reachability Information (NLRI) field of an UPDATE message.

This avoids trying to discuss the UPDATE. UPDATEs are just PDU packing to carry Routes and covers the destination and the Path Attributes.

4.1.2. TLV Format [...]

The second high-order bit (bit 1): set to 0 to indicate that the service-metadata is not transitive. Only intended for the receiving router.

Here, it's marked as non-transitive.

suehares commented 9 months ago

Metadata Path Attribute is non-transitive.

Text to change in section 4.1

Old Text:/ 4.1. Metadata Path Attribute

The Metadata Path Attribute is an optional BGP Path attribute to carry metrics and metadata about the edge services attached to the egress router. /

New Text:/ 4.1. Metadata Path Attribute The Metadata Path Attribute is an optional non-transitive BGP Path attribute to carry metrics and metadata about the edge services attached to the egress router. /

Section 4.1.1

Old text:/ The content of the Sub-TLVs present in the BGP Metadata Path attribute is determined by the configuration. When a BGP Speaker does not recognize some of the Sub-TLVs within one Metadata Path Attribute in a BGP UPDATE message, the BGP Speaker should forward the received BGP UPDATE message without any change if the transitive bit is set to 1 [RFC4271]. The domain ingress nodes SHOULD process the recognized Sub-TLVs carried by the Metadata Path Attribute and ignore the unrecognized Sub-TLVs. By default, a BGP speaker does not report any unrecognized Sub-TLVs

New text:/ The content of the Sub-TLVs present in the BGP Metadata Path attribute is determined by the local bgp peer's capabilities as encoded by local BGP configuration. Multiple Sub-TLVs may be carried by a single BGP Metadata Path Attribute. A BGP Peer receiving a BGP Metadata Path attribute SHOULD ignore Sub-TLVs with unknown types and process the recognized Sub-TLVs. BGP Peers SHOULD not delete any Sub-TLV from the BGP Metadata Path Attribute.

suehares commented 9 months ago

Sue's comment -

The text in 4.1.1 needs to be rewritten into two parts

Part 1 (4.1.1) - Metadata Path Attribute Use outline of content: a) Path attribute is non-transitive, b) Path attribute - unique non-transitive
b.1 - Deployments usage - Communities, Extended Communities, TEA, etc. b.2 - Use case in section 3,
b.3 - Manageability /deployment - section xx, attribute filtering

c) Path attribute has meaning with NLRI (AFI/SAFI) Unicast (1/1, 2/1), Label Unicast (AFI/SAFI - ) [RFC8277], IPv6 Anycast [RFC478[

4.1.2 - Processing of Attribute

Whole attribute a) Originate the path attribute with an NLRI
b) add to routes forward
c) receive a valid path attribute, do not change

[See section on validation]

MetaPath Attribute sequence of Sub-TLV. If unknown Sub-TLV, ignore but pass.

4.1.3 Processing of data in the SubTLVs

Each TLVs is processed as data as data received per sections 4.2-4.4. Section 5 contains the combined processing. Define the combined processing of the TLVS in section.

lindadunbar commented 8 months ago

Question about this suggested text: "The content of the Sub-TLVs present in the BGP Metadata Path attribute is determined by the local bgp peer's capabilities as encoded by local BGP configuration."

The intent is to convey that the choice of which prefix to carry the Metadata Path Attribute is determined by local policies.

The new text for 4.1.1 is: New text:/ @The choice of the Sub-TLVs present in the BGP Metadata Path attribute is determined by the local policies. Multiple Sub-TLVs may be carried by a single BGP Metadata Path Attribute. A BGP Peer receiving a BGP Metadata Path attribute SHOULD ignore Sub-TLVs with unknown types and process the recognized Sub-TLVs. BGP Peers SHOULD not delete any Sub-TLV from the BGP Metadata Path Attribute.

Changed the other text per suggestion in -16 version.

lindadunbar commented 8 months ago

What is the difference between a) Path attribute is non-transitive and b) Path attribute - unique non-transitive

lindadunbar commented 8 months ago

Is the following sentence same as "Path Attribute can be encoded (or packed?) with NLRI (AFI/SAFI) Unicast (1/1, 2/1), Label Unicast (AFI/SAFI - ) [RFC8277], IPv6 Anycast [RFC4786]"?

"Path attribute has meaning with NLRI (AFI/SAFI) Unicast (1/1, 2/1), Label Unicast (AFI/SAFI - ) [RFC8277], IPv6 Anycast [RFC478]"

suehares commented 8 months ago

Jeff states in draft-haas-idr-bgp-attribute-escape:

Non-transitive Path Attributes are only guaranteed to be dropped during BGP route propagation by implementations that do not recognize them.

Unrecognized transitive Path Attributes, if they are accepted by the implementation (and they usually are), will be propagated. However, when they are unrecognized, the "Partial" flag is set indicating that at least one BGP speaker in the propagation path did not recognize the feature. In practice, this flag is solely informational and not used by implementations to change their processing of the attribute when they recognize it.

The text in -15 currently states non-transitive.

suehares commented 8 months ago

closing - as it is being added to -16.