Thanks a lot to Jim and Andrew.We will add the text.BRWeiqiang
---原始邮件---
发件人: Andrew Alston - IETF <andrew-i...@liquid.tech>
发送时间: 2023-11-30 21:58:27
收件人: James Guichard <james.n.guich...@futurewei.com>
Cheng Li <c...@huawei.com>
Stewart Bryant <stewart.bry...@gmail.com>
抄送: "draft-ietf-spring-mpls-path-segm...@ietf.org"
<draft-ietf-spring-mpls-path-segm...@ietf.org>
"spring-cha...@ietf.org" <spring-cha...@ietf.org>
"spring@ietf.org" <spring@ietf.org>
"bruno.decra...@orange.com" <bruno.decra...@orange.com>
主题: Re: [spring] Andrew Alston's Discuss
ondraft-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> Date: Thursday, 30
November 2023 at 16:56 To: Cheng Li <c...@huawei.com>, Andrew Alston - IETF
<andrew-i...@liquid.tech>, Stewart Bryant <stewart.bry...@gmail.com> Cc:
draft-ietf-spring-mpls-path-segm...@ietf.org
<draft-ietf-spring-mpls-path-segm...@ietf.org>, spring-cha...@ietf.org
<spring-cha...@ietf.org>, spring@ietf.org <spring@ietf.org>,
bruno.decra...@orange.com <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> Sent: Thursday, November 30, 2023 8:24 AM To:
Andrew Alston - IETF <andrew-ietf=40liquid.t...@dmarc.ietf.org> Stewart Bryant
<stewart.bry...@gmail.com> Cc: draft-ietf-spring-mpls-path-segm...@ietf.org
spring-cha...@ietf.org spring@ietf.org James Guichard
<james.n.guich...@futurewei.com> 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.¶
”
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> On Behalf Of Andrew Alston - IETF Sent:
Thursday, November 30, 2023 2:11 PM To: Stewart Bryant
<stewart.bry...@gmail.com> 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 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> Date: Thursday, 30 November
2023 at 11:04 To: Andrew Alston - IETF <andrew-i...@liquid.tech> Cc: The IESG
<i...@ietf.org>, draft-ietf-spring-mpls-path-segm...@ietf.org
<draft-ietf-spring-mpls-path-segm...@ietf.org>, spring-cha...@ietf.org
<spring-cha...@ietf.org>, spring@ietf.org <spring@ietf.org>,
james.n.guich...@futurewei.com <james.n.guich...@futurewei.com>,
bruno.decra...@orange.com <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> 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
> 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
> > > > ----------------------------------------------------------------------
> 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://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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
