Subject: Re: [spring] draft-ietf-spring-segment-routing-policy

From: Yu Tianpeng <[email-masked]>
Date: Tue, 13 Nov 2018 20:34:37 +0800

+spring

On Wed, Nov 14, 2018 at 1:58 AM Yu Tianpeng <[email-masked]>
wrote:

> Dear authors,
> I have read the document and some comments as below, hope will help.
>
> 2.1
> <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02#section-2.1>.
> Identification of an SR Policy
>
> [Tim]: I suggest we define a default color value 0x00000000 as “default
> behavior” or “best effort”. This value will help further interoperability
> between vendors. The other values are left user-defined.
>
> Or we can say if the color is not specified, we should use 0x00000000 as
> default one. Also, I suggest we mention the higher value is, the higher SLA
> it indicates.
>
>
>
> 2.12
> <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02#section-2.12>.
> Priority of an SR Policy
>
> [Tim]: Suggest to change the title to Re-compute priority to avoid
> confusing with preference defined previously.
>
>
>
> 2.13
> <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02#section-2.13>.
> Summary
>
> [Tim]: Priority defined in 2.12 is not listed in the example.
>
>
>
> In addition, a Segment-List MAY be declared invalid when:
>
> [Tim]: Another case is: Its last label is not explicit-null neither. If I
> understand correctly, the logic of the two criteria is “AND” instead of
> “OR” right? I suggest we mention the logic here.
>
>
>
> 2.9
> <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02#section-2.9>.
> Active Candidate Path
>
> [Tim] [I-D.filsfils-spring-sr-policy-considerations] The reference link of
> this part does not work.
>
>
>
> 6.2.1
> <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02#section-6.2.1>.
> Frequent use-case: unspecified BSID
>
> [Tim]: Suggest we change the title to “SR Policy specified BSID”
>
> The BSID of all candidate paths are empty in such case, I don’t think we
> should use the word “unspecified BSID” which looks like a reserved BSID.
>
>
>
>
>
> 6.2.3
> <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02#section-6.2.3>.
> Specified-BSID-only
>
> [Tim]: An implementation MAY support the configuration of the
> Specified-BSID-only restrictive behavior on the headend for all SR Policies
> or individual SR Policies.
>
> It should be as below right?
>
> An implementation MAY support the configuration of the Specified-BSID-only
> restrictive behavior on the headend for all SR candidate paths or
> individual SR candidate paths.
>
>
>
>
>
> 8.6
> <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02#section-8.6>.
> Per-Flow Steering
>
> [Tim]: I have concerns that BSID is programmed into the forwarding plane
> as in “6.2
> <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02#section-6.2>.
> BSID of an SR Policy” it is mentioned that “the BSID SHOULD NOT be used as
> an identification of an SR Policy.”
>
> I suppose we at least mention if we use per-flow steering, we should not
> use Specified-BSID-only which lead to inpersistent BSID.
>
> Thanks.
> Regards,
> Tim
>

---

From: Yu Tianpeng <[email-masked]>
Date: Tue, 13 Nov 2018 17:58:24 +0000

Dear authors,

2.1

2.12

2.13

2.9

6.2.1

6.2.3

8.6

[Tim]: I have concerns that BSID is programmed into the forwarding plane as
in “6.2
<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02#section-6.2>.
BSID of an SR Policy” it is mentioned that “the BSID SHOULD NOT be used as
an identification of an SR Policy.”

Thanks.
Regards,
Tim