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

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Wed, 16 Feb 2022 13:59:12 -0800

Alvaro Retana 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:
----------------------------------------------------------------------

(1) This specification should formally Update rfc8402.

What is the relationship between this document and rfc8402?  If this document
details the concept introduced in rfc8402, why isn't there a formal Update
relationship?

Even the initial definition of SR Policy in this document (§2) doesn't match
what rfc8402 says.  This document defines it as "a framework that enables the
instantiation of an ordered list of segments", while rfc8402 states it is "an
ordered list of segments."  In §2.2, this document uses the term
"segment-list" for that.

Besides the general topic of clarifying and updating what an SR Policy is, this
document also includes other items that were not present in rfc8402; the list
includes:

   §2.1: "SR Policy MUST be identified through the tuple <headend, color,
   endpoint>."   There's not even a mention of "color" in rfc8402.

   §2.1: "The headend is specified as an IPv4 or IPv6 address and is expected
   to be unique in the domain."  Neither the mechanism to identify a node nor
   the expectation is present in rfc8402.

   §2.1: "The endpoint is specified as an IPv4 or IPv6 address and is expected
   to be unique in the domain."   Same as above.

The SR Database is a new element not in the base architecture.  The text in §3
says that "use of the SR-DB for computation and validation of SR Policies is
outside the scope of this document", but it is then mentioned and used in
§5.1/§5.2.

Accordingly, the added details require additional Security and Manageability
considerations.

I couldn't find a related discussion in the archive.  If I missed it, please
point me in the right direction.

(2) §5.1:

   Types A or B MUST be used for the SIDs for which the reachability
   cannot be verified.  Note that the first SID MUST always be reachable
   regardless of its type.

These two requirements and the text in the description of these types ("...does
not require the headend to perform SID resolution.") results in a
contradiction: Types A and B are not to be resolved, but if they are the first
SID then they MUST.  If it's not a contradiction, then Types A and B would not
be allowed to be the first SID, which is not correct because the most
straightforward mechanism to define a path is to list SR-MPLS Labels or SRv6
SIDs.

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

(0) I support John's DISCUSS.

(1) Is the specification of a headend/endpoint mandatory?  IOW, should the text
in §2.1 about the headend/endpoint being identified by a unique IPv4 or IPv6
address be normative?

(2) §2.1: "An implementation MAY allow the assignment of a symbolic name
comprising of printable ASCII [RFC0020] [RFC5234] characters"

Why are you normatively limiting the name to be represented in ASCII?  Please
internationalize it - use UTF-8.

§2.6 also has similar text.

(3) §2.1: "Such symbolic names MAY identify an SR Policy when the naming scheme
ensures uniqueness."  In this case, the "MAY" is just stating a fact.
s/MAY/may

(4) §2.1: "An SR Policy MAY have multiple names...in the scenario where the
headend receives different SR Policy names"   Describing multiple names as the
case where multiple names are received is not helpful.

(5) §2.2: "the endpoints of the constituent SR Policies and the parent SR Policy
MUST be identical"  To avoid confusion, by "endpoints" you mean "headend and
endpoint", right?

(6) §2.3:

   A headend MAY be informed about a candidate path for an SR Policy
   <color, endpoint> by various means including...

It seems like the "MAY" is only stating a fact -- if so, then s/MAY/may

(7) §2.4: "When signaling is via PCEP...the AS number SHOULD be set to 0 by
default when not available or known."

When is it ok for the ASN to not be set to 0 (when not available or known)?
If that possibility exists, the PCE can use any value (including the real
number or a random one).  What issues exist with uncoordinated (or rogue) PCEs
using potentially arbitrary ASNs?

Why is this action recommended and not required?

(8) This paragraph in §2.5 seems to be missing something"

   The Discriminator is a 32-bit value associated with a candidate path
   that uniquely identifies it within the context of an SR Policy from a
   specific Protocol-Origin as specified below:

"below" where?   I guess you may mean "below in §2.6 (Identification of a
Candidate Path)", but that section says that the "tuple
<Protocol-Origin, originator, discriminator> uniquely identifies a candidate
path" and not just the discriminator as above.

Also, the ":" leads to some text about the default and specific protocols.
Given that this document intends to provide an architecture, I would expect
general consideration about the discriminator, and not pointers to how it can
be signaled or, much less, the process in BGP.  In general, I would expect the
architecture to not rely on solution documents to explain how pieces of the
architecture are derived.

(9) Given the description, it seems possible for a PCE (for example) to
advertise multiple candidate paths with the same Preference, Originator, and
Discriminator.  If that occurs, what is the result of the selection in §2.9?
Would this situation result in multiple active candidate paths?

(10) §2.11: "Only the active candidate path SHOULD be used for forwarding
traffic that is being steered onto that policy."   When is it ok to use
non-active paths?  Why is this action recommended and not required?

(11) §2.12: Several of the "MAY" statements in this section express a fact, not
a normative statement:  s/MAY/may

The operator MAY set this field...
An SR Policy MAY comprise multiple...

(12) §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.

In this sentence, you're recommending both algorithms.  When should one or the
other be used?  There are no qualifiers that lead to the "otherwise" statement.

(13) §4: What is the purpose of enumerating the types of segment-descriptors?
Should the type be indicated when the Segment-List is signaled?  I assume the
answer is yes, but I didn't see that specified anywhere.

(14) §5.1: "The headend detects a mismatch between the SID value and its
context provided for SIDs of type C-through-K"  What does having a mismatch
mean?  Please be specific.

(15) §5.2:

   When the local computation is not possible (e.g., a policy's tail-end
   is outside the topology known to the headend) or not desired, the
   headend MAY send path computation request to a PCE supporting PCEP
   extension specified in [RFC8664].

This action (ask the PCE) is a solution, not an architectural description.  Are
there other external mechanisms that can find a "solution Segment-List"?  It
seems to me that one such mechanism would be in the form of a configured
Segment-List.  If that is correct, please generalize the normative statement
above -- where using PCEP can be an example.

(16) §7: Which are valid states?  Active is one, the text mentions an
"administrative state", what else?   Interoperability is a good reason to
specify the states and not assume that implementations might do the right thing.

(17) §7: "The SR Policy state MUST also reflect the reason when a policy and/or
its candidate path is not active due to validation errors or not being
preferred."

Given that this is a requirement, please provide a list of reasons.  The need
for interoperability (by using rfc2119 language) can only be achieved if the
reasons are standardized.

(18) In general, the text contains a mixture of normative language (rfc2119)
and descriptions that make the contents inconsistent and confusing.  For
example, my interpretation of "an SR Policy and its BSID are removed from the
forwarding plane" (from §8.1) is that it is an absolute requirement.  However,
§8.2 presents the optional "Drop-Upon-Invalid behavior" which then indicates
that there can be cases where my interpretation was not correct.

The point here is that the text in a Standards Track document should not be up
for interpretation.

There are too many cases in the text to list that would have benefitted from
using Normative Language -- I mentioned a couple above.  Ideally, the authors
would make one more pass for clarity.  However, I will probably end up
ABSTAINing because of it.

This point was also raised in the rtg-dir review, which is why I'm not
including it as part of a DISCUSS.

---

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

Hi Alvaro,

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> There were similar comments from Rob for which we have recently posted
updated text in v17. I believe, this document does not need to update
RFC8402 because it is not changing anything in that document. RFC8402
simply introduces SR Policy while this document specifies its internal
constructs, how it is realized/instantiated, and steering mechanisms over
it. At least, that is the objective/view of the authors/WG and we are open
to inputs to update and further clarify the same.

>    to be unique in the domain."   Same as above.

KT> Yes, these are the constructs of SR Policy that are specified by this
document.

> outside the scope of this document", but it is then mentioned and used in

KT> The computation algorithm and related discussions about the use of
SR-DB were asked to be moved out of this standards track document during
the WG process. Those informational sections were moved into
draft-filsfils-spring-sr-policy-considerations
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-17#ref-I-D.filsfils-spring-sr-policy-considerations>
and
kept as a reference in this document. The reference in 5.1 and 5.2 is about
validation of segments and as a result the segment-list and candidate path.
The validation of the "objective" and constraints of the SR Policy was
deemed to be outside the scope of the document. There were several
discussions on and off-list at the IETF meetings in this regard. Perhaps
this thread gives a good summary:
https://mailarchive.ietf.org/arch/msg/spring/W8q3wW0damd4XgG-2cH_qzDeA6E/

> Accordingly, the added details require additional Security and

KT> Could you please clarify/explain a bit further what you feel is missing?

> straightforward mechanism to define a path is to list SR-MPLS Labels or

KT> I don't see a contradiction here. "Types A or B MUST be used for the
SIDs for which the reachability cannot be verified." is not the same as
saying "Type A or B are not to be resolved".

KT> It is not normative since we have the case of an unspecified address as
an endpoint. We could use SHOULD though, if that clarifies.

> §2.6 also has similar text.

KT> My understanding is that there is no compulsion to use UTF-8 for such
purposes. This was discussed in the WG. Please check:
https://mailarchive.ietf.org/arch/msg/spring/Wj3eNx_EBHtDrYVYTCYIlJ2Yq_w/

> ensures uniqueness."  In this case, the "MAY" is just stating a fact.

KT> Ack. Will fix.

> case where multiple names are received is not helpful.

KT> When CPs for the same SR Policy are provisioned via different sources,
then such a scenario may occur.

> MUST be identical"  To avoid confusion, by "endpoints" you mean "headend

KT> We mean the endpoint as in "the tail-end". We are speaking from within
the context of a headend here so the headend is the same.

> It seems like the "MAY" is only stating a fact -- if so, then s/MAY/may

KT> Ack. Will fix.

> Why is this action recommended and not required?

KT> AFAIR PCEP signaling does not carry AS number. So this is a
recommendation, though a local policy or a future PCEP extension could
change that and we don't want to preclude it.

> path" and not just the discriminator as above.

KT> The next three paragraphs that begin with "When .." should be a bullet
list. Looks like it got missed out.

> architecture are derived.

KT> These are informational pointers to the respective protocol specs to
help the reader.

> Would this situation result in multiple active candidate paths?

KT> The ability to signal multiple CPs via PCEP is being introduced
via draft-ietf-pce-segment-routing-policy-cp. The default is for use when
not using that draft and in that case, there would be only a single CP.

> non-active paths?  Why is this action recommended and not required?

KT> The condition was for path protection as described in section 9.3. The
"backup" path is programmed and hence may be used for forwarding while FRR
is active.

> An SR Policy MAY comprise multiple...

KT> Ack. Will fix those.

> other be used?  There are no qualifiers that lead to the "otherwise"

KT> Ack. The semicolon needs to be replaced by "and"  before "otherwise".

> answer is yes, but I didn't see that specified anywhere.

KT> It is used in the protocol specs for reference -
e.g draft-ietf-idr-segment-routing-te-policy

> mean?  Please be specific.

KT> The value of the SID provided does not match the value of the SID
determined through the provided context. Will clarify.

KT> Agree and will change that to an example.

> specify the states and not assume that implementations might do the right

KT> The state here does not mean a single one like up/down. It is referring
to the operational state. Those aspects are covered in
the draft-ietf-spring-sr-policy-yang but also reported via BGP and PCEP
when those protocols are in use. We'll add a reference
to draft-ietf-spring-sr-policy-yang.

> reasons are standardized.

KT> The reason is for debugging and troubleshooting. If something is down
or invalid, then it helps to know why.

> including it as part of a DISCUSS.

KT> Authors will take a pass and get back on this.

Thanks,
Ketan

---

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

Hi Alvaro,

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

Note that we've now tagged the document as updating RFC8402 per the
discussions and feedback from the Telechat earlier today.

Thanks,
Ketan

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

> <https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-17#ref-I-D.filsfils-spring-sr-policy-considerations> and
> KT> It is not normative since we have the case of an unspecified address
> as an endpoint. We could use SHOULD though, if that clarifies.
>
>
>>
>>
> KT> The state here does not mean a single one like up/down. It is
> referring to the operational state. Those aspects are covered in

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 21 Feb 2022 13:44:46 -0800

On February 17, 2022 at 10:06:39 AM, Ketan Talaulikar wrote:

Ketan:

Hi!

I am looking at -18.  Thanks for adding the Updates tag -- you need to
also add text to the Introduction about the update.

Comments inline...

...
> > Besides the general topic of clarifying and updating what an SR Policy is,
> > this document also includes other items that were not present in rfc8402;
> > the list includes:
> >
> > The SR Database is a new element not in the base architecture. The text in
> > §3 says that "use of the SR-DB for computation and validation of SR
> > Policies is outside the scope of this document", but it is then mentioned
> > and used in §5.1/§5.2.
>
> KT> The computation algorithm and related discussions about the use of SR-DB
> were asked to be moved out of this standards track document during the WG
> process. Those informational sections were moved into
> draft-filsfils-spring-sr-policy-considerations and kept as a reference in
> this document. The reference in 5.1 and 5.2 is about validation of segments
> and as a result the segment-list and candidate path. The validation of the
> "objective" and constraints of the SR Policy was deemed to be outside the
> scope of the document. There were several discussions on and off-list at the
> IETF meetings in this regard. Perhaps this thread gives a good summary:

It's ok if the SR-DB is out of scope.

§3 does say that "use of the SR-DB for computation and validation of
SR Policies is outside the scope of this document."  But that (using
the DB for validation) is different than leaving validation completely
out of scope.  In fact, the text in §5.1 doesn't leave segment-list
validation (for example) out of scope when it says this:

   The SR Policy headend does not compute the Segment-List.  The SR Policy
   headend only confirms its validity.

Or when it requires the validation explicitly: "A Segment-List of an
explicit candidate path MUST be declared invalid..."

Leaving the validation out of scope may have been what was intended,
but it is not what the document says.  It is also not clear to me
whether the intent was to leave out of scope how to use the DB (as the
text in §3 says), or to completely leave it out.

The thread was not that easy to follow, with most message being about
support.  Can you point me to where the out-of-scope decision was
reached?  Alternatively, the Chairs can confirm.

> KT> Could you please clarify/explain a bit further what you feel is missing?

For example, for this construct of the SR Policy specified in this
document: "The headend is specified as an IPv4 or IPv6 address and is
expected to be unique in the domain." (§2.1)

What new security and/or manageability considerations does it
introduce?  Can there be a mixture of IPv4 and IPv6 addresses
identifying headends/endpoints?  What happens if there are duplicate
identifiers?  How can it be detected?  Can a rogue node intercept (or
perhaps attract) the traffic of an SR Policy if it advertises one of
these addresses?  ...

Some of the answers may be "nothing", or the issues may be carried
over from rfc8402 -- in those cases, please at least point that out.

...
> > These two requirements and the text in the description of these types
> > ("...does not require the headend to perform SID resolution.") results in a
> > contradiction: Types A and B are not to be resolved, but if they are the
> > first SID then they MUST. If it's not a contradiction, then Types A and B
> > would not be allowed to be the first SID, which is not correct because the
> > most straightforward mechanism to define a path is to list SR-MPLS Labels
> > or SRv6 SIDs.
>
> KT> I don't see a contradiction here. "Types A or B MUST be used for the SIDs
> for which the reachability cannot be verified." is not the same as saying
> "Type A or B are not to be resolved".

True.  However, the description of both types say that "This type does
not require the headend to perform SID resolution."

This is one of those cases where a (non) requirement is mentioned
without Normative language that can lead to a potentially wrong
interpretation. :-(

...
> > (1) Is the specification of a headend/endpoint mandatory? IOW, should the
> > text in §2.1 about the headend/endpoint being identified by a unique IPv4
> > or IPv6 address be normative?
>

The unspecified address is an IPv4 or IPv6 address.

If you use SHOULD, when would it be ok for the identification to not
be an IPv4 or IPv6 address?  Why recommend and not require?

> https://mailarchive.ietf.org/arch/msg/spring/Wj3eNx_EBHtDrYVYTCYIlJ2Yq_w/

I wouldn't say that this thread (it only includes the message you sent
to the list) qualifies as a discussion.   But, yes, there is no
requirement to use UTF-8 -- it is just the nice (and maybe correct)
thing to do knowing that non-English-speaking people may also use this
specification.

[See rfc9003 for an an example of an extension what also considered
the Cyrillic alphabet.]

...
> then such a scenario may occur.

It would be nice if the text included that clarification then: ...via
different sources.

Can multiple names be received from the same source?

...
> > number or a random one). What issues exist with uncoordinated (or rogue)
> > PCEs using potentially arbitrary ASNs?
> >
> recommendation, though a local policy or a future PCEP extension could change
> that and we don't want to preclude it.

First of all, the architecture shouldn't be defined as a function of
what the protocols can do today, it should be defined as a function of
what is needed.

If the ASN can be signaled, when is it ok for it to not be set to 0
(when not available or known)?  If that possibility exists, the PCE
can use any value (including the real number or a random one). What
issues exist with uncoordinated (or rogue) PCEs using potentially
arbitrary ASNs?

...
> KT> The ability to signal multiple CPs via PCEP is being introduced via
> draft-ietf-pce-segment-routing-policy-cp. The default is for use when not
> using that draft and in that case, there would be only a single CP.

Let me try again: if the PCE can advertise multiple paths
(draft-ietf-pce-segment-routing-policy-cp) with the same Preference,
Originator, and Discriminator, how should the selection in §2.9 be
evaluated?

> "backup" path is programmed and hence may be used for forwarding while FRR is
> active.

By definition, the backup is only used when the main path is being
repaired and not used (because it failed).  IOW, in this case only one
path is used at a time.

The text above implies that more than one path can be used at a time.

...
> > This action (ask the PCE) is a solution, not an architectural description.
> > Are there other external mechanisms that can find a "solution Segment-
> > List"? It seems to me that one such mechanism would be in the form of a
> > configured Segment-List. If that is correct, please generalize the
> > normative statement above -- where using PCEP can be an example.
>

The updated text says:

   When the local computation is not possible (e.g., a policy's tail-end
   is outside the topology known to the headend) or not desired, the
   headend MAY send path computation request to a centralized
   computation entity (e.g., to a PCE supporting PCEP extensions
   specified in [RFC8664]).

In the case of manual configuration, the request is not sent anywhere
(as in using a protocol)...   How about this:

   When the local computation is not possible (e.g., a policy's tail-end
   is outside the topology known to the headend) or not desired, the
   headend may rely on an external entity.  For example, a request may
   be sent to a PCE supporting PCEP extensions specified in [RFC8664].

> to the operational state. Those aspects are covered in the
> draft-ietf-spring-sr-policy-yang but also reported via BGP and PCEP when
> those protocols are in use. We'll add a reference to
> draft-ietf-spring-sr-policy-yang.

draft-ietf-spring-sr-policy-yang says that it provides a data-model
for the SR Policy framework defined in this document.  But this
document points there for the states...circular reference.

Even if nor circular, the reference to
draft-ietf-spring-sr-policy-yang should be Normative because it
specifies the sates for the architecture.

You mentioned above that the "state here does not mean a single one
like up/down. It is referring to the operational state."  This is from
draft-ietf-spring-sr-policy-yang:

  typedef policy-oper-state {
    type enumeration {
      enum UP {
        value 1;
        description "SR policy is operationally up";
      }
      enum DOWN {
        value 2;
        description "SR policy is operationally down";
      }
    }
    description "SR policy oper state";
  }

Am I looking in the wrong place?

> > (17) §7: "The SR Policy state MUST also reflect the reason when a policy
> > and/or its candidate path is not active due to validation errors or not
> > being preferred."
> >
> KT> The reason is for debugging and troubleshooting. If something is down or
> invalid, then it helps to know why.

Yes, I understand it helps to know the reason, that's why I'm asking. :-)

Again, please make draft-ietf-spring-sr-policy-yang a Normative reference.

I found a couple of identities in draft-ietf-spring-sr-policy-yang
that fit the bill for the requirement:
candidate-path-not-selected-reason and policy-down-reason.  However,
what I couldn't find is the specification of the conditions when each
of the reasons is to be used.  Most of reasons seem straight forward,
but it would be ideal if the specification was complete.

Thanks!

Alvaro.