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 response and please check inline below.

We have also just posted an update to address some of the comments below
and from other ADs.

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

On Tue, Feb 22, 2022 at 3:14 AM Alvaro Retana <[e-mail]>
wrote:

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

KT> Ack. Fixed.


>
> Comments inline...
>
>
> > > ----------------------------------------------------------------------
> > > DISCUSS:
> > > ----------------------------------------------------------------------
> ...
> > > 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 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/
>
> 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.
>

KT> The SRDB is not out of scope. The path computation algorithm and the
verification of the path constraints is out of scope. The SID validation
and resolution are within the scope of the document and that requires the
SRDB. We've clarified this in the text.


>
> 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.
>
>
>
> > > Accordingly, the added details require additional Security and
> Manageability
> > > considerations.
> >
> > 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?  ...
>

KT> We have added some text in this regard in the draft. The detection
mechanism for duplicate prefix advertisements though is out of the scope of
this document.


>
> 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.
>
>
>
> ...
> > > (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".
>
> True.  However, the description of both types say that "This type does
> not require the headend to perform SID resolution."
>

KT> We will remove that sentence from both types since it is not necessary.
The other segment types describe the resolution to be performed from the
different contexts provided to the MPLS label or SRv6 SID.


>
> This is one of those cases where a (non) requirement is mentioned
> without Normative language that can lead to a potentially wrong
> interpretation. :-(
>
>
>
> > > ----------------------------------------------------------------------
> > > COMMENT:
> > > ----------------------------------------------------------------------
> ...
> > > (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.
>
> 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?
>

KT> I think I understand the point. The uniqueness is about the ability to
resolve the IP address to a unique node in the SR domain to be able to
identify a headend and a tailend. We've clarified this in the text.


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

KT> There are existing implementations and deployments of this draft as
well as the same being signaled via corresponding protocol extensions in
BGP and PCEP. If this is not a requirement, then we would like to avoid
change at this stage.


>
>
>
> ...
> > > (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.
>
> It would be nice if the text included that clarification then: ...via
> different sources.
>

KT> Ack. Clarified.


>
> Can multiple names be received from the same source?
>

KT> Yes. Since the unit of signaling in the protocols is the CP.
Theoretically, the same source could send different CPs of the same Policy
with different Policy names.


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

KT> True. That would be the case in an ideal world. Practically, the WGs
have ended up with the desire and requirement for having multiple protocols
to signal the same construct and there is the need for some normalization.


>
> 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> I will leave this question for the PCEP WG if and when they decide to
add support for ASN to be signaled. It does not make any impact from this
specification perspective since it is only used to identify the originator.


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

KT> Then it would be the same CP. The second update would overwrite the
first one.


>
>
>
>
> > > (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.
>
> By definition, the backup is only used when the main path is being
> repaired and not used (because it failed).


KT> This is not accurate. At the time FRR is triggered, one does not know
whether what was the active path can be repaired or not. So, depending on
what has been provisioned as backup, it may be that the next best path is
used as the backup (so it will be considered active after control plane
convergence) OR it may be an entirely different path that may not become
active because the original active path was repaired or a 3rd path now
becomes the active path after control plane convergence. Please also see
the next comment.


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

KT> That is not the intention and we've clarified in the text while using
MUST.


>
>
>
> ...
> > > (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.
>
> 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].
>
> KT> Ack. Fixed.


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

KT> Making a normative reference to the YANG model draft would result in a
circular reference. The intention of this document is to provide a
high-level requirement - e.g. whether instantiated or not, which CP is
active, reason for not being active, etc.  The YANG model is then expected
to specify the more detailed operational state.


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

KT> The work on the YANG model is by no means complete (IMHO). But there
are more operation states - e.g., sr-policy-types:policy-oper-state,
sr-policy-types:binding-sid-oper-state, is-best-candidate-path,
non-selection-reason, is-valid, etc.


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

KT> As mentioned in my response to the comment above, the work on the YANG
model seems like taking longer in the WG. The model is perhaps the best way
to capture these states' information and the model can (rather should)
reference the appropriate sections of this specification to clarify the
intent. IMHO that would perhaps be the right way to progress this work
towards publication.

Thanks,
Ketan



>
>
>
> Thanks!
>
> Alvaro.
>