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

[Cheng Li <[e-mail]>]

Hi Andrew,

I agree with Stewart and Alexander.
This is a common processing in MPLS, and nothing new is introduced to Path Segment since it is a normal local label. So I think we might no need to add text for this ?
As suggested by Bruno, making clear that the Path Segment is a local label can avoid many discussion, because people know how to deal with a local segment. Thanks for Bruno’s suggestion.

Hope this can address your concern.

Thanks,
Cheng




From: spring <[e-mail]> On Behalf Of Alexander Vainshtein
Sent: Thursday, November 30, 2023 9:23 AM
To: Stewart Bryant <[e-mail]>; Andrew Alston <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [spring] [EXTERNAL] Re: Andrew Alston's Discuss on draft-ietf-spring-mpls-path-segment-20: (with DISCUSS and COMMENT)

Stewart, Andrew and all,
I concur with Stewart.

RFC 4182<https://datatracker.ietf.org/doc/html/rfc4182> clearly states that if the IPv4 or IPv6 Explicit Null label is found at the top of the stack but is not the bottom-of-stack label, it must be popped, and the next label processed in the usual way.

This situation is encountered in many cases (e.g. if the operator configures LDP not to use PHP for some reason while using LDP tunnel LSPs to carry BGP/MPLS IP VPN traffic), and I am not aware of any performance degradation in these scenarios.

I do not see why the case of the Path Segment should be special in any way.

My 2c



Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
From: spring <[e-mail]<mailto:[e-mail]>> on behalf of Stewart Bryant <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, November 30, 2023 10:05:09 AM
To: Andrew Alston <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: [spring] Andrew Alston's Discuss on draft-ietf-spring-mpls-path-segment-20: (with DISCUSS and COMMENT)

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 <[e-mail]<mailto:[e-mail]>> 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/<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/<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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spring



Disclaimer

This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.