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

[Ketan Talaulikar <[e-mail]>]

Hi Alvaro,

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


On Thu, Feb 17, 2022 at 3:29 AM Alvaro Retana via Datatracker <
[e-mail]> wrote:

> 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.
>

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.


>
> 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.
>

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


>
>
> 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
<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
> Manageability
> considerations.
>

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


>
>
> 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.
>

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".


>
> ----------------------------------------------------------------------
> 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?
>

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

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/


>
>
> (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
>

KT> Ack. Will fix.


>
>
> (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.
>

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


>
>
> (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?
>

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.


>
>
> (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
>

KT> Ack. Will fix.


>
>
> (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?
>

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.


>
>
> (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.
>

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


>
> 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.
>

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


>
>
> (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?
>

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.


>
>
> (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?
>

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.


>
>
> (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...
>

KT> Ack. Will fix those.

>
>
> (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.
>

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


>
>
> (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.
>

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


>
>
> (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.
>

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


>
>
> (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.
>

KT> Agree and will change that to 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.
>

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.


>
>
> (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.
>

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


>
>
> (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.
>

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

Thanks,
Ketan