Deborah Brungard has entered the following ballot position for draft-ietf-spring-segment-routing-mpls-19: 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/iesg/statement/discuss-criteria.html for more information about IESG 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-mpls/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I didn't see a fix/response to one of Sasha's identified items in his RTG Dir review: - 1. The text in Section 1 states “An implementation MAY check that an IGP node-SID is not associated with a prefix that is owned by more than one router within the same routing domain, If so, it SHOULD NOT use this Node-SID, MAY use another one if available, and SHOULD log an error”. Sasha suggested MAY/s/SHOULD or MUST, saying this aligns with Section 3.2/RFC8402, which uses the wording "MUST NOT" be used by another router. I agree with Sasha, to align, it would be a "MUST", so why the softer requirement? Also, how does an implementation "check"? Wouldn't it be simply "An implementation MUST ensure that an.."? Or the operator (NMS) needs to ensure (e.g. RFC8402 says typically allocated by policy of the operator)? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Noting Mirja's comment asking why is this not Informational, I agree with the current track as "PS" as it does define (using RFC2119 keywords) procedures (labels). Nit: Section 2 I had difficulty parsing the first bullet: >From a control plane perspective, [RFC3031] does not mandate a single signaling protocol. Segment Routing makes use of various control plane protocols such as link state IGPs [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The flooding mechanisms of link state IGPs fits very well with label stacking on ingress. Future control layer protocol and/or policy/configuration can be used to specify the label stack. /suggest/ From a control plane perspective, [RFC3031] does not mandate a single control protocol or use of a control protocol. Segment Routing makes use of various control plane protocols such as link state IGPs [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The flooding mechanisms of link state IGPs fits very well with label stacking on ingress. Future control layer protocols are not precluded and/or management policy/configuration can be used to specify the label stack. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
