Updated. Thanks to Andrew and Jim.
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-path-segment Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-mpls-path-segment-22 Cheng From: Andrew Alston - IETF <andrew-i...@liquid.tech> Sent: Thursday, November 30, 2023 2:58 PM To: James Guichard <james.n.guich...@futurewei.com>; Cheng Li <c...@huawei.com>; Stewart Bryant <stewart.bry...@gmail.com> Cc: draft-ietf-spring-mpls-path-segm...@ietf.org; spring-cha...@ietf.org; spring@ietf.org; bruno.decra...@orange.com Subject: Re: [spring] Andrew Alston's Discuss on draft-ietf-spring-mpls-path-segment-20: (with DISCUSS and COMMENT) That works for me – especially considering the performance clause in section 2 (which following the update based on John’s discuss which seemed to link it to post stack performance hits is now adequate to address that) So yeah – if there are no objections, I’m good with Jim’s text Thanks Andrew Internal All Employees From: James Guichard <james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>> Date: Thursday, 30 November 2023 at 16:56 To: Cheng Li <c...@huawei.com<mailto:c...@huawei.com>>, Andrew Alston - IETF <andrew-i...@liquid.tech<mailto:andrew-i...@liquid.tech>>, Stewart Bryant <stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>> Cc: draft-ietf-spring-mpls-path-segm...@ietf.org<mailto:draft-ietf-spring-mpls-path-segm...@ietf.org> <draft-ietf-spring-mpls-path-segm...@ietf.org<mailto:draft-ietf-spring-mpls-path-segm...@ietf.org>>, spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> <spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>>, spring@ietf.org<mailto:spring@ietf.org> <spring@ietf.org<mailto:spring@ietf.org>>, bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> Subject: RE: [spring] Andrew Alston's Discuss on draft-ietf-spring-mpls-path-segment-20: (with DISCUSS and COMMENT) Hi Cheng, Andrew can confirm but I think the following additional text should satisfy his discuss: “Behavior relating to the use of explicit null directly preceding the PSID is undefined in this document.” Andrew, please confirm. Authors, please add this text to the document if there are no objections. Thanks! Jim From: Cheng Li <c...@huawei.com<mailto:c...@huawei.com>> Sent: Thursday, November 30, 2023 8:24 AM To: Andrew Alston - IETF <andrew-ietf=40liquid.t...@dmarc.ietf.org<mailto:andrew-ietf=40liquid.t...@dmarc.ietf.org>>; Stewart Bryant <stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>> Cc: draft-ietf-spring-mpls-path-segm...@ietf.org<mailto:draft-ietf-spring-mpls-path-segm...@ietf.org>; spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; James Guichard <james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>>; bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> Subject: RE: [spring] Andrew Alston's Discuss on draft-ietf-spring-mpls-path-segment-20: (with DISCUSS and COMMENT) Hi Andrew, Talking existing labels (Including Explicit Null and others) as existing implementation, in section 2, we have a paragraph to explain that processing PSID may have some performance impact. “ The addition of the PSID will require the egress to read and process the PSID label in addition to the regular processing. This additional processing may have an impact on forwarding performance.¶<https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-path-segment-21#section-2-6> ” It is true that performance will be impacted by adding any extra processing. I think this is what you are looking for? But you are welcome to provide some next text to make it more clear if this is not enough for you 😊 Thanks, Cheng From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On Behalf Of Andrew Alston - IETF Sent: Thursday, November 30, 2023 2:11 PM To: Stewart Bryant <stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>> Cc: draft-ietf-spring-mpls-path-segm...@ietf.org<mailto:draft-ietf-spring-mpls-path-segm...@ietf.org>; spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>; bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> Subject: Re: [spring] Andrew Alston's Discuss on draft-ietf-spring-mpls-path-segment-20: (with DISCUSS and COMMENT) Hi Stewart, So, let me try and articulate this better – My reading of 4182 (With Alexander referred to in a former email) is that if the explicit NULL is not BoS – it gets popped and the next label rises to the top and the “disposition of the packet” is based on the label that has now risen to the top of the stack. Now, normally if that was the case – I would assume that this would be a pop / swap – (pop the explicit null and swap the next label, and forward based on it – in the egress packet pipeline – nice and simple) In this case however – you have two options – either – on ingress – skip over the explicit NULL, process the PSID, and then on egress pop the explicit null and the psid in a double label pop. Alternatively – you can on egress – pop the explicit NULL, process the PSID, pop the PSID and then forward. Both methods would work – the question is – would these have potential performance impacts. Alexander is completely correct in the fact that RFC4182 states if an IPv4 explicit null label is found at top of stack – and is not BoS – then it must be popped – and the “disposition of the packet” is then based on the next label. The issue here is that “disposition of the packet” isn’t very clearly defined – and I’d argue this is a corner case when you start implementing stuff like PSID. I also note that in the document, there is reference to potential performance impact from POST PSID – This seems to be related to the use of GAL. I feel that we need to deal with both scenarios in the document. As such – as a simple proposal – text that says something along the lines of “Behavior relating to the use of explicit null directly preceding the PSID is undefined in this document and implementation dependent and may potentially have an impact on forwarding performance.” Alternatively – if that addition to the text doesn’t provide enough insight into the rationale behind it – I’d be happy to suggest more concrete text. I do however still feel that this case needs to be dealt with in the document. Thanks Andrew Internal All Employees From: Stewart Bryant <stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>> Date: Thursday, 30 November 2023 at 11:04 To: Andrew Alston - IETF <andrew-i...@liquid.tech<mailto:andrew-i...@liquid.tech>> Cc: The IESG <i...@ietf.org<mailto:i...@ietf.org>>, draft-ietf-spring-mpls-path-segm...@ietf.org<mailto:draft-ietf-spring-mpls-path-segm...@ietf.org> <draft-ietf-spring-mpls-path-segm...@ietf.org<mailto:draft-ietf-spring-mpls-path-segm...@ietf.org>>, spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> <spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>>, spring@ietf.org<mailto:spring@ietf.org> <spring@ietf.org<mailto:spring@ietf.org>>, james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com> <james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>>, bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> Subject: Re: [spring] Andrew Alston's Discuss on draft-ietf-spring-mpls-path-segment-20: (with DISCUSS and COMMENT) CAUTION: This email has originated from a free email service commonly used for personal email services, please be guided accordingly especially if this email is asking to click links or share information. 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<mailto: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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C01%7Candrew-ietf%40liquid.tech%7Cb3b8d996aa9143e600ee08dbf17b07ee%7C687926120f0e46cbb16afcb82fd80cb1%7C0%7C0%7C638369282957776990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=kTOkABoFY4ZmJcM0Mf7Zpk%2F2DYzTXiYrtL6JVSPagNQ%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-mpls-path-segment%2F&data=05%7C01%7Candrew-ietf%40liquid.tech%7Cb3b8d996aa9143e600ee08dbf17b07ee%7C687926120f0e46cbb16afcb82fd80cb1%7C0%7C0%7C638369282957784266%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wLDwb3dO9N7IYcTg7ETLbIaPXUIlWh7zewf6fkSgXs0%3D&reserved=0<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<mailto:spring@ietf.org> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=05%7C01%7Candrew-ietf%40liquid.tech%7Cb3b8d996aa9143e600ee08dbf17b07ee%7C687926120f0e46cbb16afcb82fd80cb1%7C0%7C0%7C638369282957789599%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NJXFmhvIcr0PmwXaZagF65p9sx9WGKgw%2Fm%2FEBESGv%2BI%3D&reserved=0<https://www.ietf.org/mailman/listinfo/spring>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
