Hello Deborah, thanks for your review. Regarding your discuss, Sasha had said: I see two possibilities to resolve this controversy: either make the check in question a “real requirement” (i.e., replace MAY with SHOULD or even MUST) or explain why it is safe ... Sasha was thus proposing s/MAY/SHOULD/ or s/MAY/MUST/ as the first option.
The authors have followed Sasha suggestion. The text now reads: An implementation SHOULD check that an IGP node-SID is not associated -m Le 2019-04-09 à 23:09, Deborah Brungard via Datatracker a écrit : > 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
