Subject: [spring] Deborah Brungard's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT)

From: Deborah Brungard via Datatracker <[email-masked]>
Date: Tue, 09 Apr 2019 14:09:20 -0700

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.

---

From: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Wed, 10 Apr 2019 08:07:00 +0000

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