RTG-DIR Issue 19: Section 2.4.4.2.2 - what is the significance of the Flags and SRv6 Endpoint Behavior and SID Structure?

suehares commented 4 months ago

RTG-DIR Issue 19: Section 2.4.4.2.2 - what is the significance of the Flags and SRv6 Endpoint Behavior and SID Structure?

2.4.4.2.2. Segment Type B

Figure 12: Type B Segment sub-TLV

Flags: 1 octet of flags as defined in Section 2.4.4.2.3.
SRv6 SID: 16 octets of IPv6 address.
SRv6 Endpoint Behavior and SID Structure: Optional, as defined in Section 2.4.4.2.4.

Jeffrey: When this is part of a segment list, what is the significance of the Flags and SRv6 Endpoint Behavior and SID Structure?

Ketan: Please refer to sections 2.4.4.2.3 and 2.4.4.2.4 - will elaborate on your further comments on those sections.

suehares commented 3 months ago

Text in section 2.4.4.2.3

 V-Flag: This flag, when set, is used by SRPM for "SID
  verification" as described in Section 5.1 of [RFC9256].

  B-Flag: This flag, when set, indicates the presence of the SRv6
  Endpoint Behavior and SID Structure encoding specified in
  Section 2.4.4.2.4.

RFC9256 states in section 5.1:
(The text in bold below is just for emphasis for review. It is not in the original text)

A segment list of an explicit candidate path MUST be declared invalid when any of the following is true:

It is empty.
Its weight is 0.
It comprises a mix of SR-MPLS and SRv6 segment types.
The headend is unable to perform path resolution for the first SID into one or more outgoing interface(s) and next-hop(s).
The headend is unable to perform SID resolution for any non-first SID of type C through K into an MPLS label or an SRv6 SID.
The headend verification fails for any SID for which verification has been explicitly requested.

"Unable to perform path resolution" means that the headend has no path to the SID in its SR database.

SID verification is performed when the headend is explicitly requested to verify SID(s) by the controller via the signaling protocol used. Implementations MAY provide a local configuration option to enable verification on a global or per-policy or per-candidate path basis.

"Verification fails" for a SID means any of the following:

The headend is unable to find the SID in its SR-DB
The headend detects a mismatch between the SID value provided and the SID value resolved by context provided for SIDs of type C through K in its SR-DB.
The headend is unable to perform SID resolution for any non-first SID of type C through K into an MPLS label or an SRv6 SID.

In multi-domain deployments, it is expected that the headend may be unable to verify the reachability of the SIDs in remote domains. Types A or B MUST be used for the SIDs for which the reachability cannot be verified. Note that the first SID MUST always be reachable regardless of its type.

suehares commented 3 months ago

Shepherd's comment on SID Validation

The explicit segment lists are declared invalid if:

It is empty.
Its weight is 0.
It comprises a mix of SR-MPLS and SRv6 segment types.

Is the BGP tunnel an explicit segment list or a dynamic segment list? If the BGP SR Candidate Route is an explicit segment list, then why do you handle the basics prior to installing the BGP NLRI with the invalid TEA prior to passing this information to the SRPM?

suehares commented 3 months ago

Merging in Issue-18 from Jeffrey Zhang

-04 status: Technical, must be resolved

text:/ 2.4.4.2. Segment Sub-TLVs

The Segment sub-TLVs are optional and MAY appear multiple times in the Segment List sub-TLV./

Jeffrey: Why are they optional? What is the use case of an empty segment list?

Ketan: Without a SL or an empty SL, the SRPM would not be able to instantiate the CP in the forwarding. However, that is for the SRPM to decide. We do not bring that sort of validation into BGP.

suehares commented 3 months ago

Merging in RTG-DIR Issue-21

text: V-Flag: This flag, when set, is used by SRPM for "SID verification" as described in Section 5.1 of [RFC9256].

Jeffrey: I have trouble understanding the V-Flag. How is the headend supposed to verify the BSID or any segment in the segment list?

Ketan: Please refer to section 5.1 of the RFC9256. https://mailarchive.ietf.org/arch/msg/rtg-dir/pzT0P9XId3qV3iCd-mgpZUvul7A/

suehares commented 3 months ago

Mergin in RTG-DIR Review, Issue 29: - I-Flag in section 2.4.2

Type: Technical, editorial github link: https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/34

text:

I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It is used by SRPM as described in section 8.2 in [RFC9256]. The flag indicates that the CP is to perform the "drop upon invalid" behavior when no valid CP is available for this SR Policy. In this situation, the CP with the highest preference amongst those with the "drop upon invalid" config is made active to drop traffic steered over the SR Policy.

Shepherd's comment-1: The text in RFC9256 does not define "CP". Perhaps all that is needed is to use SR Candidate Policy (SR-CP). This section must be upgraded to indicate what CP means.

Shepherd's comment-2: The SRPM in section 8.2 states

An SR Policy MAY be enabled for the Drop-Upon-Invalid behavior. This would entail the following:

an invalid SR Policy and its BSID is kept in the forwarding plane with an action to drop,

any steering of a service (PW), destination (BGP-VPN), flow, or packet on the related SR Policy is maintained with the action to drop all of this traffic.

What does it mean when this specification in section 2.4.2 states: "In this situation, the CP with the highest preference amongst those with the "drop upon invalid" config is made active to drop traffic steered over the SR Policy."

It appears the SRPM identifies the set of SR Candidate Policies with "I-Flag" set are collected, and the highest preference is made active so the traffic is dropped.

suehares commented 1 month ago

closed merged into issue https://github.com/ietf-wg-idr/draft-ietf-idr-sr-policy-safi/issues/32

ietf-wg-idr / draft-ietf-idr-sr-policy-safi