draft: draft-zzd-idr-sr-policy-scheduling
Type: Proposed standard
status: Individual Draft
current version: -08
adoption process: TVR needs to set paradigm, Spring SR, and IDR mechanisms
Cross-WG discussion: TVR, Spring
bgp-ls draft: none
Early Allocation: TBD
implementations: TBD
Reviewer: Susan Hares
Reviewer: Susan Hares
old text:/The NLRI defined in [I-D.ietf-idr-segment-routing-te-policy]
contains the SR Policy candidate path./
New text:/The NLRI defined in [I-D.ietf-idr-sr-policy-safi]
contains the SR Policy candidate path./
Note: You are not defining a new tunnel type.
Old text:/ The content of the SR Policy Candidate Path is encoded
in the Tunnel Encapsulation Attribute defined in [RFC9012] using a
new Tunnel-Type called SR Policy Type with codepoint 15. /
New text:/ The content of the SR Policy Candidate Path is encoded
in the Tunnel Encapsulation Attribute defined in [RFC9012] using a
the Tunnel-Type called SR Policy Type with codepoint 15. /
**What's missing: **
Can this Sub-TLV only go in the SR Policy tunnel TLV.
If so please clearly state this in section 3.
What part does this sub-TLV in validating the TLV? Will a malformed sub-TLV cause the TLV to be illegal? Can the Malformed Sub-TLV ignored or does this cause a security issue?
It appears that the Sub-TLV could be repeated at two levels (see section 3) for a tunnel with multiple segments (going over all segments) and at the segment level. How do the two levels interact? Does any usage make the tunnel invalid?
You are extending the [draft-ietf-idr-sr-policy-safi] error handling which extends the [RFC9012] error handling. It would be good to have a section that calls out changes to both.
[draft-ietf-idr-sr-policy-safi] has a good start.
You must add to this the critical information passed by your draft.
Describe how this technology can be monitored or managed by NETCONF/Yang or BGP-LS.
old text:/
When a headend receives a SR Policy form it neighbors or controller,
it SHOULD perform schedule information validation based on the following rules:
New text:/
When a headend receives a SR Policy from it neighbors or controller,
it SHOULD perform schedule information validation based on the following rules:/
**
Draft:** draft-zzd-idr-sr-policy-scheduling
status: individual draft,
**Adoption: ** Paradigm approved in TVR + Spring, IDR mechanisms
version: Revision needed
implementations: unknown
**Authors: **5 authors
Email: https://mailarchive.ietf.org/arch/msg/idr/2BPY7USo_xaonlIkXDYVMvXklrQ/
2nd email: https://mailarchive.ietf.org/arch/msg/idr/iWTnLrBuoj1h4W78TqEc66MDbh0/
Old text:/
This document proposes extensions to BGP SR Policy to indicate the
scheduling time of each candidate path(segment list) and its
associated attributes./
New text:/
This document proposes extensions to BGP mechanism to pass
explicit SR Policy Candidate Paths in order to indicate the
scheduling time of each candidate path(segment list) and its
associated attributes./
Old text:/
[I-D.ietf-idr-segment-routing-te-policy] specifies how BGP may be
used to distribute SR Policy candidate paths. It introduces a BGP
SAFI with new NLRI to advertise a candidate path of a Segment Routing
(SR) Policy./
new text:/
[I-D.ietf-idr-sr-policy-safi] specifies how BGP may be
used to distribute explicit SR Policy candidate paths. It introduces a BGP
SAFI with new NLRI (SR Policy) and a new tunnel type for the BGP Tunnel
Encapsulation Attribute (SR Policy) to advertise a candidate path
of a Segment Routing (SR) Policy./
Old text:/
In order to solve these problesm, this document proposes extensions
to BGP SR Policy to indicate the scheduling time of each candidate
path(segment list) and its associated attributes. /
new text:/
In order to solve these problesm, this document proposes extensions
to BGP SR Policy as defined in [draft-ietf-idr-sr-policy-safi]
to indicate the scheduling time of each explicit candidate
path (segment list). /
replace [draft-ietf-idr-segment-routing-te-policy] to
[draft-ietf-idr-sr-policy-safi].
old text:/
The NLRI defined in [I-D.ietf-idr-segment-routing-te-policy] contains
the SR Policy candidate path. The content of the SR Policy Candidate
Path is encoded in the Tunnel Encapsulation Attribute defined in
[RFC9012] using a new Tunnel-Type called SR Policy Type with
codepoint 15. /
new text:/
The NLRI defined in [I-D.ietf-idr-sr-policy-safi] contains
the SR Policy candidate for an explicit policy. The content of the SR Policy Candidate
Path is encoded in the Tunnel Encapsulation Attribute defined in
[RFC9012] using a new Tunnel-Type called SR Policy (code point 15)./
old text:/ The new SR Policy
encoding structure is expressed as below:/
new text:/ The new SR Policy TLV structure
is listed below:/
Please Give ranges on the definitions.
Here are a few questions that your text should answer:
Is group number zero valid? Are there any invalid group numbers?
Is index of zero valid?
Provide clearer diagram on time block.
[index, reserved] [enable time] [disable time]
are 12 octets of repeating information.
See [draft-ietf-idr-sr-policy-safi] security section.
What you need to update here is the protection of
the critical information for the Scheduled Time Information
Sub-TLVs you have added.
The movement of traffic between SR Candidate
paths based on time may take different skills
to debug problems in code or configuration.
Please provide a short manageability section.