Andrew you assert that explicit null is a significant performance hit. Is that the case? The test for explicit null is skip label if label is zero with no need to look up the label in the main label table (which is very expensive). What do forwarders do here? I had assumed that they special cased the reserved labels.
- Stewart Sent from my iPad > On 30 Nov 2023, at 07:29, Andrew Alston via Datatracker <nore...@ietf.org> > wrote: > > 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. > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
