draft: draft-ietf-idr-sr-policy-path-segment
Type: Proposed Standard
status: WG Draft
adopted: draft-li-sr-policy-path-segment-01
current version: -14
Early Allocation: yes
implementations: 1 (Huawei in VRP)
bgp-ls draft: draft-ietf-idr-bgp-ls-sr-policy-path-segment
draft: draft-ietf-idr-sr-policy-path-segment-14
Status: Summary, alll technical issues and editorial issues cleared.
email: response to Sue's -13 review
next steps:
draft: draft-ietf-idr-sr-policy-path-segment-13
Status: Needs revision, but Early Allocation can be done
email: https://mailarchive.ietf.org/arch/msg/idr/pNvmocZVRa1C3o92bhsdtjuttEs/
Issues from -11 resolved: Technical Issues 1-4 from Review-11, but issue-3 is partially resolved
Version -13 states:
/A BGP implementation MUST NOT perform semantic
verification of such fields nor consider the SR Policy update to be
invalid or not usable based on such validation. /
Is there a reason, you do not specifically state the SRPM?
Issues from -11 resolved: NITS 1-2
Issue not resolved from -13: NIT-3
draft: draft-ietf-idr-sr-policy-path-segment-11)
Email: https://mailarchive.ietf.org/arch/msg/idr/n6jJO93bxpU4M8692M974lmSZ3E/
Augments: [RFC9012] by allowing new TLVs in Segment list
Status: Needs revision with new template.
implementation status: Needs two implementations
The abstract, header, and references need to indicate that you are adding TLVs to
Tunnel Encapsulation Attribute for the SR Policy Type.
Abstract change is provided:
Old text:/
A Segment Routing (SR) policy is a set of candidate SR paths
consisting of one or more segment lists with necessary path
attributes. For each SR path, it may also have its own path
attributes, and Path Segment is one of them. A Path Segment is
defined to identify an SR path, which can be used for performance
measurement, path correlation, and end-2-end path protection. Path
Segment can be also used to correlate two unidirectional SR paths
into a bidirectional SR path which is required in some scenarios, for
example, mobile backhaul transport network./
New Text:/
A Segment Routing(SR) policy identifies a set of candidate SR paths
Each SR path is passed in BGP as the SR Policy SAFI NLRI
accompanied with the Tunnel Encapsulation attribute (Tunnel-encaps). Each
SR Path (tunnel) uses a set of TLVs in the Tunnel-encaps attribute
to describe the characteristics of the SR Policy tunnel. One of the TLVs
that describes the tunnel is the Segment list TLV which provides a list
of segments contained in the tunnel. This document specifies a new
Path Segment Sub-TLV to associate a Path Segment ID to the SR Segment List.
The Path Segment ID can be used for performance measurement, path correlation,
and end-2-end path protection. This Path Segment identifier can be also
be used to correlate two unidirectional SR paths into a bidirectional SR path.
Bidirection SR path may be required in some scenarios such as
mobile backhaul transport network./
Hopefully this abstract change will help you make the changes to the
introduction. [RFC9012] needs to be included in the references.
Is there a case when the multiple Path Segment Sub-TLV included in a list
will conflict? (see section 3.0)
The operations defined in [I-D.ietf-idr-sr-policy-safi] do not
include your new Sub-TLV. This document needs to state that:
3-1. Error handling as defined in RFC7606 applies to new Sub-TLVs
as well as SAFI context.
3-2. A BGP Speaker must perform Syntax validation of the new SubTLV
in context. Must validate
a) length of TLVs and sub-TLVs
b) range of values
If determine malformed, it should "treat-as-withdraw",
3-3. Validation of Tunnel Attribute for valid
a) tunnel
b) sub-TLVs associated with it.
3-4.) Validation SR Candidate routes as active route done by SRPM.
Please see the security section in SAFI.
The identification of bi-direction and performance segments
adds to the critical nature of some of the information.
old text:/
In some scenarios, for example, mobile backhaul transport network,
there are requirements to support bidirectional path. /
New text:/
In some scenariose such as mobile backhaul transport network,
there are requirements to support bidirectional path. /
Please use the form "Sub-TLV" consistently.
Change sub-TLV to Sub-TLV.
If you mean to make difference to the TLVs under Reserve segment, define a term.
Error: Run-on sentence please break this sentence into 2 parts
Current:/
The Segment sub-TLVs in the Reverse Path Segment List sub-TLV
provides the information of the reverse SR path, which can be used
for directing egress BFD peer to use specific path for the reverse
direction of the BFD session [I-D.ietf-mpls-bfd-directed] or other
applications./
New:/
The Segment sub-TLVs in the Reverse Path Segment List sub-TLV
provides the information of the reverse SR path. This
Reverse Path Segment list can be used for directing egress
BFD peer to use specific path for the reverse
direction of the BFD session [I-D.ietf-mpls-bfd-directed] or other
applications./