[mpls] Re: draft-ihle-mpls-mna-stateless-egress-protection-00

[mpls] Re: draft-ihle-mpls-mna-stateless-egress-protection-00 - alternative approach

Fabian Ihle <fabian.ihle@uni-tuebingen.de> Wed, 06 November 2024 19:24 UTC

Message-ID: <7d9877b5-92dc-4fbb-9488-87bec4fcaf74@uni-tuebingen.de>
Date: Wed, 06 Nov 2024 19:24:28 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: mpls@ietf.org, Stewart Bryant <stewart.bryant@gmail.com>
References: <875286D6-D6D3-49FB-A5E4-2C1426ACA616@gmail.com>
Content-Language: en-US
From: Fabian Ihle <fabian.ihle@uni-tuebingen.de>
In-Reply-To: <875286D6-D6D3-49FB-A5E4-2C1426ACA616@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms060305070306090904000906"
Message-ID-Hash: HUVCL3M5YOFJXPHVXMF4YH55QR5L6CDC
Precedence: list
Subject: [mpls] Re: draft-ihle-mpls-mna-stateless-egress-protection-00 - alternative approach
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/cdK-NSkoJYsCyI3OHHsfNsaUF1w>

Hi Stewart,

thanks for the feedback! I like the idea as it is more generalized and 
simpler. Maybe there will be other use cases in the future that will 
benefit from a general "pop N LSEs" network action as well.

Regarding the MNA header with multiple MNA network actions, we could 
define a constraint like "the 'pop N network actions' action must always 
be on top of the NAS". This way, the other network actions remain 
untouched and we just have to repair the NASL field (decrement it by N).

I have yet to think about the application labels.

Best,

Fabian

On 06.11.24 13:37, Stewart Bryant wrote:
> An alternative strategy to encoding the alternate path labels “strangely” in the MNA header and then needing to construct a new stack by reformatting the MNA data into real labels is to have an MNA action : IF no repair POP n else ignore (or POP) action.
>
>
> So the stack looks like
>
> LSE to PLR
> MNA Action POP n if no repair
> LSE to C’
> LSE to C’'
> Etc
>
> Note that delivery is not the only thing you need to worry about you need worry about the application labels which both egress nodes need to worry about.
>
> So what happens
>
> At the PLR it is determined if the link to C is up and C is alive.
>
> If C is OK POP (or cleans) MNA header and the labels to the value n in its parameter. In the above case n = 2.
>
> If C is not OK POP (or cleans) MNA header
>
> At this point we now have a set of LSEs at TOS that will execute the repair and get the packet to the alternate exit for C.
>
> Note that the solution needs to consider what happens to the MNA header if more than one MNA action is present (proposed solution and this alternate) and what happens to application labels which need to be understood at C and the alternate to C.
>
> This seems simpler and much more aligned with the existing MPLS architecture.
>
> Best regards
>
> Stewart
>
>
> _______________________________________________
> mpls mailing list -- mpls@ietf.org
> To unsubscribe send an email to mpls-leave@ietf.org

-- 
Fabian Ihle
Universität Tübingen
Fachbereich Informatik Lehrstuhl Kommunikationsnetze
Wilhelm-Schickard-Institut für Informatik
Sand 13, 72076 Tübingen

Raum: B303
Telefonnr.: +49 7071 29-70545
E-Mail: fabian.ihle@uni-tuebingen.de
Internet: uni-tuebingen.de

Attachment: smime.p7s

[mpls] draft-ihle-mpls-mna-stateless-egress-prote… Stewart Bryant
[mpls] Re: draft-ihle-mpls-mna-stateless-egress-p… Fabian Ihle

[mpls] Re: draft-ihle-mpls-mna-stateless-egress-protection-00 - alternative approach

Attachment: smime.p7s