Hi Andrew, Many thanks for your review and comments.
Let me reply to your comments in this email and reply to your discuss later in another email. Please see inline. Respect, Cheng -----Original Message----- From: Andrew Alston via Datatracker <nore...@ietf.org> Sent: Thursday, November 30, 2023 8:30 AM To: The IESG <i...@ietf.org> Cc: draft-ietf-spring-mpls-path-segm...@ietf.org; spring-cha...@ietf.org; spring@ietf.org; james.n.guich...@futurewei.com; bruno.decra...@orange.com; bruno.decra...@orange.com Subject: Andrew Alston's Discuss on draft-ietf-spring-mpls-path-segment-20: (with DISCUSS and COMMENT) 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. [Cheng]Fixed, thank you so much. I did not check it carefully because I trust the Markdown to XML tools. Will check it carefully next time. 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? [Cheng]Yes, a PSID might not be the last label in the stack, so S bit is not set in this case. 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" [Cheng] No problem, added. 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. [Cheng]Thanks, currently, we have several related draft in IDR and PCE WG. The goal is to separate the content so that the original SR policy is not delayed by this draft. Thank you again! _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
