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... > > ---------------------------------------------------------------------- > > 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. 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? ... 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." 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? > > (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.] ... > > (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. Can multiple names be received from the same source? ... > > (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. 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? ... > > (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? > > (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). 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. ... > > (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]. > > (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. 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." > > > > 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. Thanks! Alvaro. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
