search

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

Repository for draft-ietf-idr-sr-policy-safi Issues
0 stars 0 forks source link

RTG-DIR Issue 10: Section 2.1 - What gets passed to SRPM #12

Closed suehares closed 3 months ago

suehares commented 4 months ago

RTG-DIR Issue 10: Section 2.1 - What gets passed to SRPM

Text:/ SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint> Attributes: Tunnel Encapsulation Attribute (23) Tunnel Type: SR Policy (15) Binding SID SRv6 Binding SID Preference Priority Policy Name Policy Candidate Path Name Explicit NULL Label Policy (ENLP) Segment List Weight Segment Segment ... ... Figure 2: SR Policy Encoding /

Jeffrey: Policy Name seems to be a property for policy not the candidate path. What if the names do not match among different candidate paths of the same policy?

suehares commented 3 months ago

RFC9256 states:

An implementation MAY allow the assignment of a symbolic name comprising printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E) to an SR Policy to serve as a user-friendly attribute for debugging and troubleshooting purposes. Such symbolic names may identify an SR Policy when the naming scheme ensures uniqueness. The SR Policy name MAY also be signaled along with a candidate path of the SR Policy (refer to Section 2.2). An SR Policy MAY have multiple names associated with it in the scenario where the headend receives different SR Policy names along with different candidate paths for the same SR Policy via the same or different sources.

suehares commented 3 months ago

Shepherd's technical comment on RFC9256 versus "Policy Name"

The use of multiple names for the SR Policy where each name may be associated with a different SR Candidate Paths for the Policy is a confusing concept. On the surface, it appears to work against common mechanisms for BGP routes.

This usage is not a problem with the draft-ietf-idr-sr-policy-safi, but an outgrowth of approved text for Segment Routing architecture.