Subject: [spring] Roman Danyliw's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 16 Feb 2022 14:06:03 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-spring-segment-routing-policy-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

There appear to be a few places where additional pointers or specification is
needed to ensure interoperability.

** Section 2.5
   When signaling is via PCEP, the method to uniquely signal an
   individual candidate path along with its discriminator is described
   in [I-D.ietf-pce-segment-routing-policy-cp].

Where is the explanation of discriminator in this reference?  “Discriminator”
appears in Sections 3.1, 3.2, 4.1.2, and 5.2.2.  In the first three section it
is simply named but not explained.  In the last section, it isn’t explained
beyond being defined as 32-bits.

** Section 2.6.
  Candidate paths MAY also be assigned or signaled with a symbolic name
   comprising printable ASCII [RFC0020] [RFC5234] characters

How these candidate paths names are signaled isn’t defined.  I believe it is
per Section 5.2.3 of draft-ietf-pce-segment-routing-policy-cp and Section 2.4.7
of draft-ietf-idr-segment-routing-te-policy.

** Section 2.7.  How is the candidate path preference signaled?  Is that
draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1 and
https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support John Scudder and Alvaro Retana's DISCUSS positions.

** Section 2.1.
   The color is an unsigned non-zero 32-bit numerical value that
   associates the SR Policy with an intent or objective (e.g.  low-
   latency).

Should “numeric value” be “integer”?

** Section 2.1
   The SR Policy name
   MAY also be signaled along with a candidate path of the SR Policy
   (refer to Section 2.2).

-- It would be helpful to explicitly state either here or in Section 2.2 that
Section 2.4.8 of [I-D.ietf-idr-segment-routing-te-policy] and Section 5.2.1 of 
[I-D.ietf-pce-segment-routing-policy-cp] apply for the guidance on how this
naming is signaled. Section 2.2 doesn’t discuss signaling the name.

-- Both of these document need to be normative reference since there is
dependency on them for interoperable behavior.

** Section 2.2. Typo. s/heirarchical/hierarchical/

** Section 2.3.  It would be helpful if the precise mechanism to signal the
Protocol-Origin was cited.

-- I believe it is Section 5.2.2 of [I-D.ietf-pce-segment-routing-policy-cp]

-- I didn’t find any reference to a “Protocol Origin” or this section in
[I-D.ietf-idr-segment-routing-te-policy].

** Section 2.4.
   When signaling is via BGP SR Policy, the ASN and Node Address are
   provided by BGP (refer to [I-D.ietf-idr-segment-routing-te-policy])
   on the headend.

[I-D.ietf-idr-segment-routing-te-policy] needs to be a normative reference (as
stated before due to the text in Section 2.1)

** Section 2.5.    Per “When provisioning is via configuration, this is an
implementation's configuration model-specific unique identifier for a candidate
path”, what is a “configuration model-model-specific unique identifier?  What
scope of the uniqueness?

** Section 2.13.  This section says “the information model is the following”,
but I don’t follow where that information model (IM) is per the definition in
RFC3444.  The text here appears be an example with hard-coded parameter values.

** Section 4.
   Based on the desired dataplane, either the MPLS label stack or the
   SRv6 Segment Routing Header [RFC8754] is built from the Segment-
    List.

Do SRv6 SRH and MPLS label stacks support all the segment types enumerated
here?  For example, does Type E and F, IPv4 segments, work with a SRv6 SRH?

** Section 4.
   When the algorithm is not specified for the SID types above which
   optionally allow for it, the headend SHOULD use the Strict Shortest
   Path algorithm if available; otherwise, it SHOULD use the default
   Shortest Path algorithm.  The specification of the algorithm enables
   the use of the IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific
   SIDs in SR Policy.

Does this imply that [I-D.ietf-lsr-flex-algo] should be a normative reference?

** Section 10.  Given that this document has a dependency on
[I-D.ietf-idr-segment-routing-te-policy] and
[I-D.ietf-pce-segment-routing-policy-cp] to concrete implement SR Policy, their
security considerations should apply.

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 17 Feb 2022 20:38:49 +0530

Hi Roman,

Thanks for your review and comments/inputs. Please check inline below for
responses.

> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/

KT> I have not yet reviewed that document and will do so to pass the
comments to the authors of that document. As a reminder, this is an
architecture document in SPRING that is then realized using protocol
extensions/mechanisms that are specified in their respective WG documents.

> https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1

KT> Those protocol specs normatively refer to this document. Your
understanding is correct about the parts of those documents.

KT> Ack. Will clarify.

> dependency on them for interoperable behavior.

KT> Please see one of my previous responses on the architecture and
protocol specifications split across documents.

> ** Section 2.2. Typo. s/heirarchical/hierarchical/

KT> Ack.

> Protocol-Origin was cited.

KT> It is not something that is signaled - refer to "The head-end assigns
different Protocol-Origin values to each source of SR Policy information.".
It is like an "administrative distance" that is used to attach preference
to routes learned via different protocols like OSPF, IS-IS, and BGP.  This
is local on the headend.

> [I-D.ietf-pce-segment-routing-policy-cp]

KT> Ack but likely we'll need to remove section number references or
revalidate them at publication given how these documents have been moving
along and their interdependencies.

> [I-D.ietf-idr-segment-routing-te-policy].

KT> Please check my previous comment.

> path”, what is a “configuration model-model-specific unique identifier?

KT> Please refer to draft-ietf-spring-sr-policy-yang - we could not be more
specific or provide exact pointer here since that document is still under
development.

> RFC3444.  The text here appears be an example with hard-coded parameter

KT> This is an overview and the actual model is being specified
in draft-ietf-spring-sr-policy-yang

> here?  For example, does Type E and F, IPv4 segments, work with a SRv6 SRH?

KT> What goes into the packet, at the end of the day, are MPLS labels or
SRv6 SIDs. The segment types introduce the different context types that are
used to specify a segment especially in the signaling protocols.

> Does this imply that [I-D.ietf-lsr-flex-algo] should be a normative

KT>  We enable the specification of an algorithm that was introduced by
RFC8402. A later enhancement carved out a range of algos from there for IGP
Flexible Algorithm. The reference is informative to indicate that one could
use IGP Flex Algo as well.

> security considerations should apply.

KT> I refer again to the dependency between this SPRING and the other
protocol specs.

Thanks,
Ketan

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 17 Feb 2022 23:53:05 +0530

Hi Roman,

We've just posted an update for the document to address the comments raised
by you and other ADs:
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-18

Thanks,
Ketan

On Thu, Feb 17, 2022 at 8:38 PM Ketan Talaulikar <[email-masked]>
wrote:

> KT> Please refer to draft-ietf-spring-sr-policy-yang - we could not be
> more specific or provide exact pointer here since that document is still
> under development.
>
>>