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

[Ketan Talaulikar <[e-mail]>]

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 <[e-mail]>
wrote:

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