[spring] Andrew Alston's Discuss on draft-ietf-spring-mpls-path-segment-20: (with DISCUSS and COMMENT)

[Andrew Alston via Datatracker <[e-mail]>]

Andrew Alston has entered the following ballot position for
draft-ietf-spring-mpls-path-segment-20: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'd like to have a discussion as regards how this will function in scenarios
using UHP.

My understanding is that by default SR-MPLS implements PHP - so the router that
receives a packet with a PSID will normally find the PSID at top of stack (it
may be the only label but it will be top stack).  This however changes in the
case of explicit NULL - which may or may not be BoS.  Normally explicit NULL
would be popped on egress - however, in this case the explicit NULL would have
to be "ignored (stepped over)" such that the PSID could be processed - and then
on egress the explicit NULL and the PSID would have to be popped. 
Alternatively, the explicit NULL would need to be popped, the PSID processed,
and then the PSID popped.  I'm not quite sure what the implications of this
would be, though, at minimum, this could potentially result in significant
performance degradation.   Either way, lets discuss because I think this
scenario does need addressing.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Firstly, thanks for the document, I found this a relatively easy read.

A few nits and comments below.

Section 1 3rd paragraph is missing a space on the second line, and that
paragraph may actually be easier to read if you put the Sectional references in
brackets, such that Section 3.1 becomes (Section 3.1) etc.

In Section 2 you write "The value of the TTL field in the MPLS label stack
entry containing a PSID can be set to any value except 0.  If a PSID is the
bottom label, the S bit MUST be set."  Now, I am presuming that the the PSID
does NOT need to be at the bottom of stack.  This is based on my reading of
section 3.4.  In the example, you are pushing s-PSID followed by two BSID's and
then a final e-PSID.  Am I correct in thinking you could have a situation which
each BSID is followed by a PSID, such that you are including the s-PSID for
B->C and the s-PSID for C->D?

If I am correct in this reading - I would suggest that you explicitly state
that if the PSID is NOT the bottom label, the S bit must NOT be set.  (So as
suggested text, "If a PSID is the bottom label, the S bit MUST be set. 
Conversely if the PSID is followed by subsequent labels, the S bit MUST NOT be
set"

As another random note - it may be worth working with the authors of
draft-ietf-idr-segment-routing-te-policy to add PSID into the SR Policy
Encoding in the same way that BSID's are specified.