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

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 17 Mar 2022 22:42:33 +0530

Hi Roman,

Could you please check the latest revision below and my responses to your
discussion points and comments in the email thread below?

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

Please let us know your feedback on whether the responses and draft updates
address your concerns.

Thanks,
Ketan

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

> 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:
>
>> Hi Roman,
>>
>> Thanks for your review and comments/inputs. Please check inline below for
>> responses.
>>
>>
>> On Thu, Feb 17, 2022 at 3:36 AM Roman Danyliw via Datatracker <
>> [email-masked]> wrote:
>>
>>> 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.
>>>
>>
>> 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.
>>
>>
>>>
>>> ** 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
>>> ?
>>>
>>
>> KT> Those protocol specs normatively refer to this document. Your
>> understanding is correct about the parts of those documents.
>>
>>
>>>
>>> ----------------------------------------------------------------------
>>> 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”?
>>>
>>
>> KT> Ack. Will clarify.
>>
>>
>>>
>>> ** 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.
>>>
>>
>> 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.
>>
>>
>>>
>>> ** Section 2.3.  It would be helpful if the precise mechanism to signal
>>> the
>>> 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 believe it is Section 5.2.2 of
>>> [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 didn’t find any reference to a “Protocol Origin” or this section in
>>> [I-D.ietf-idr-segment-routing-te-policy].
>>>
>>
>> KT> Please check my previous comment.
>>
>>
>>>
>>> ** 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?
>>>
>>
>> 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.
>>
>>>
>>> ** 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.
>>>
>>
>> KT> This is an overview and the actual model is being specified
>> in draft-ietf-spring-sr-policy-yang
>>
>>
>>>
>>> ** 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?
>>>
>>
>> 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.
>>
>>
>>>
>>> ** 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?
>>>
>>
>> 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.
>>
>>
>>>
>>> ** 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.
>>>
>>
>> KT> I refer again to the dependency between this SPRING and the other
>> protocol specs.
>>
>> Thanks,
>> Ketan
>>
>>
>

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 18 Mar 2022 01:02:45 +0000

Hi Ketan!

I’m clipping the text a bit to make it readable …

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

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

On Thu, Feb 17, 2022 at 3:36 AM Roman Danyliw via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-spring-segment-routing-policy-17: Discuss

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

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

** Section 2.5

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.

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.

[Roman] Understood that the WG considers this an architecture document, however, it is being published as proposed standard.  For that reason, I’m making these particular comments about explicitly referencing the expected normative behavior.

** Section 2.6.

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?

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

[Roman] Specifically about Section 2.6 and 2.7, thanks for confirming that I read the other documents correctly.  Is there a reason the text doesn’t explicitly reference this relevant the normative behavior?

Thanks,
Roman

---

From: Ketan Talaulikar <[email-masked]>
Date: Fri, 18 Mar 2022 11:19:38 +0530

Hi Roman,

My understanding is that you would like us to put references to the
relevant BGP and PCEP documents in sections 2.6 (CP name) and 2.7
(Preference).

Can you please confirm so we can include those changes in the next update
(once submission re-opens)?

Thanks,
Ketan

On Fri, Mar 18, 2022 at 6:33 AM Roman Danyliw <[email-masked]> wrote:

> [Roman] Understood that the WG considers this an architecture document,
> however, it is being published as proposed standard.  For that reason, I’m
> making these particular comments about explicitly referencing the expected
> normative behavior.
>
>
> ** Section 2.6.
> [Roman] Specifically about Section 2.6 and 2.7, thanks for confirming that
> I read the other documents correctly.  Is there a reason the text doesn’t
> explicitly reference this relevant the normative behavior?
>
>
>
>
> Thanks,
>
> Roman
>
>

---

From: Ketan Talaulikar <[email-masked]>
Date: Sun, 20 Mar 2022 08:53:50 +0530

Hi Roman,

We've just submitted an update to address your comments:
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-21

Please let us know if it addresses your concerns.

Thanks,
Ketan

On Fri, Mar 18, 2022 at 11:19 AM Ketan Talaulikar <[email-masked]>
wrote:

>> [Roman] Specifically about Section 2.6 and 2.7, thanks for confirming
>> that I read the other documents correctly.  Is there a reason the text
>> doesn’t explicitly reference this relevant the normative behavior?
>>
>>
>>
>>
>> Thanks,
>>
>> Roman
>>
>>