Subject: [mpls] Agenda for the Open DT meeting 2022-04-07.

From: Loa Andersson <[email-masked]>
Date: Tue, 5 Apr 2022 00:36:45 +0800

Open DT,

I have placed the proposed agenda for the meeting on Thursday at:

https://trac.ietf.org/trac/mpls/wiki/2022-04-07-agenda

/Loa

PS

I had an AP to see if we should change the time for the meeting due to 
the change to DST in the US and Europe. For this meeting I have not been 
able to do the poll. Will do for the meeting next week. So it stays at 
11pm Beijing time.

-- 
Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Loa Andersson <[email-masked]>
Date: Fri, 8 Apr 2022 00:40:17 +0800

Folks,

I have placed my notes fron the meeting in the agenda for the meeting, 
so it will be found following the link below.

/Loa

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Apr 2022 21:15:33 +0200

Dear WG,

I would like to state that I agree with comments made by Jie & Haoyu that
the presented solution is a rather significant departure from main MPLS
architecture and requires new data plane changes to fetch and process ISDs
and PSDs (even if still MPLS based).

However I have a bit more fundamental question to this proposal.

I can see that it could be made to work with LDP or RSVP based LSPs.

But it is very unclear to me how the proposed solution would work with
concept of domain wide MPLS labels. Especially considering requirement that
not all LSR nodes need to execute given function on a specific packets.

Is support of MNA compatible work with SR-MPLS considering as example case
where there is no transit segment endpoints, but just ingress and egress
LSRs. Let's take basic execution of in-situ OAM (postcard mode) on just few
specific P routers. For simplicity let's assume that MNA and that function
is supported on all P routers in the domian.

How would P nodes inspecting the arriving packets know that the encoded
action is for them to execute ?

Kind regards,
Robert

On Thu, 7 Apr 2022 at 18:40, Loa Andersson <[email-masked]> wrote:

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 7 Apr 2022 12:28:59 -0700

Hi Robert,
I' try to answer the IOAM-related question.
An IOAM monitoring session is expected to have a unique identifier. That
identifier can be provisioned to P nodes that are required to produce
op-path telemetry information for the monitored flow.

Regards,
Greg

---

From: Haoyu Song <[email-masked]>
Date: Thu, 7 Apr 2022 19:32:49 +0000

Hi Robert,

Thank you for the discussion and question. While I'm not trying to answer the question, I'd like to clarify that while I believe the architecture should be made as simple as possible, I also think there are some applications for them the actions should be kept in data plane and the extra data required by these actions needs to be encapsulated in MPLS packets. IOAM is such an example. Even for the postcard mode as described in IOAM-DEX, a header is needed to tell each node what data to collect. Since the header is already standardized, we can simply make it a PSD item.

Best regards,
Haoyu

From: mpls <[email-masked]> On Behalf Of Robert Raszuk
Sent: Thursday, April 7, 2022 12:16 PM
To: Loa Andersson <[email-masked]>
Cc: [email-masked]
Subject: Re: [mpls] Notes from Open DT meeting 2022-04-07.

Dear WG,

I would like to state that I agree with comments made by Jie & Haoyu that the presented solution is a rather significant departure from main MPLS architecture and requires new data plane changes to fetch and process ISDs and PSDs (even if still MPLS based).

But it is very unclear to me how the proposed solution would work with concept of domain wide MPLS labels. Especially considering requirement that not all LSR nodes need to execute given function on a specific packets.

Is support of MNA compatible work with SR-MPLS considering as example case where there is no transit segment endpoints, but just ingress and egress LSRs. Let's take basic execution of in-situ OAM (postcard mode) on just few specific P routers. For simplicity let's assume that MNA and that function is supported on all P routers in the domian.

How would P nodes inspecting the arriving packets know that the encoded action is for them to execute ?

Kind regards,
Robert

On Thu, 7 Apr 2022 at 18:40, Loa Andersson <[email-masked]<mailto:[email-masked]>> wrote:
Folks,

On 2022-04-05 00:36, Loa Andersson wrote:
> https://trac.ietf.org/trac/mpls/wiki/2022-04-07-agenda<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fmpls%2Fwiki%2F2022-04-07-agenda&data=04%7C01%7Chaoyu.song%40futurewei.com%7C790741cfd4554d26357e08da18cae3d5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637849556962811209%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Hktbii20vbmPyI36cQ%2FjGc5rlqxVeumzu%2BLCaWFR%2FLQ%3D&reserved=0>

/Loa

--
Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
Bronze Dragon Consulting             phone: +46 739 81 21 64

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C790741cfd4554d26357e08da18cae3d5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637849556962811209%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=n8t9K7xDu0a6g2b5bzpra3PA%2Bcsex0BVw%2BWlgkKEF%2Fo%3D&reserved=0>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Apr 2022 21:36:42 +0200

Hi Greg,

Well In-Situ OAM was just an example of an action.

But your answer actually brings a very interesting yet orthogonal to the
original question a new consideration :)

How said IOAM identifiers (many as there can be millions of flows) is
connected with ISD (or PSD) encoded action ?

Thx a lot,
R.

On Thu, 7 Apr 2022 at 21:29, Greg Mirsky <[email-masked]> wrote:

>> Is support of MNA compatible work with SR-MPLS considering as example
>> case where there is no transit segment endpoints, but just ingress and
>> egress LSRs. Let's take basic execution of in-situ OAM (postcard mode) on
>> just few specific P routers. For simplicity let's assume that MNA and that
>> function is supported on all P routers in the domian.
>>

---

From: Tony Li <[email-masked]>
Date: Thu, 7 Apr 2022 12:36:12 -0700

Hi Robert,

> But it is very unclear to me how the proposed solution would work with concept of domain wide MPLS labels. Especially considering requirement that not all LSR nodes need to execute given function o…

MNA would operate in the same way with domain wide labels as with hop-by-hop labels. Each LSR would consult the topmost label, scan the label stack and discover the Network Action Indicator.  It would then parse the Network Action Sub-stack and process it accordingly.

How to specify which nodes need to perform the contained functions is very much a matter for specific solutions.  From what I’ve seen, solutions typically encode the scope as part of the sub-stack, either specifying hop-by-hop for every node along the path or ingress-to-egress for only the last node on the path.  While we have discussed a ’select’ scope, I have yet to see a fully fleshed out solution for this and there is still some debate as to whether or not select is actually necessary. In any case, this is really a good question for the specific solution proposals.

> How would P nodes inspecting the arriving packets know that the encoded action is for them to execute ?

Yes, MNA is compatible with SR-MPLS.  P nodes would perform the process outlined above.

Note that this is somewhat similar to what is done already with the entropy label, so there is precedent for this in the architecture.  Of course, we are adding functionality.

Tony

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 7 Apr 2022 12:38:59 -0700

Hi Robert,
I believe that the IOAM session identifier will be present in IOAM-in-MPLS
shim, whether as ISD or PSD.

Regards,
Greg

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Apr 2022 21:47:36 +0200

Hi Tony,

Sounds to me that action 'scope' is an afterthought not a principle of the
proposed architecture.  IMHO that should be part of the framework and not
so much a specific solution based on the framework.

I still do not see how using domain wide label from ingress to egress one
could execute given action on specific P nodes. Sure one could think of a
solution to encode list of such nodes in the PSD but this would be rather
(to say it gently) quite inelegant.

And I must disagree with the EL analogy, As we know handling of ELI for LDP
based LSPs (rfc6790) is completely different then handling of ELI in
SR-MPLS enabled networks (rfc8662).

Kind regards,
Robert

On Thu, 7 Apr 2022 at 21:36, Tony Li <[email-masked]> wrote:

> MNA would operate in the same way with domain wide labels as with
> hop-by-hop labels. Each LSR would consult the topmost label, scan the label
> stack and discover the Network Action Indicator.  It would then parse the
> Network Action Sub-stack and process it accordingly.
>
> How to specify which nodes need to perform the contained functions is very
> much a matter for specific solutions.  From what I’ve seen, solutions
> typically encode the scope as part of the sub-stack, either specifying
> hop-by-hop for every node along the path or ingress-to-egress for only the
> last node on the path.  While we have discussed a ’select’ scope, I have
> yet to see a fully fleshed out solution for this and there is still some
> debate as to whether or not select is actually necessary. In any case, this
> is really a good question for the specific solution proposals.
>
>
> Note that this is somewhat similar to what is done already with the
> entropy label, so there is precedent for this in the architecture.  Of
> course, we are adding functionality.
>
> Tony
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Apr 2022 21:50:47 +0200

So are you saying that every node in the entire domain upon finding the
iOAM encoded action will need to retrieve embedded in each packet IOAM
session ID and compare it with list of locally configured session IDs to
see if there is an intersection and if it should execute iOAM function or
not ?

Whow.

No more questions :)

Thx,
Robert.

---

From: Tony Li <[email-masked]>
Date: Thu, 7 Apr 2022 12:56:14 -0700

Hi Robert,

> Sounds to me that action 'scope' is an afterthought not a principle of the proposed architecture.  IMHO that should be part of the framework and not so much a specific solution based on the framework. 

Welcome to work in progress. :)

We have yet to decide whether ‘select' is even a requirement, much less what it should do.  Contributions welcome.

> I still do not see how using domain wide label from ingress to egress one could execute given action on specific P nodes. Sure one could think of a solution to encode list of such nodes in the PSD but this would be rather (to say it gently) quite inelegant. 

I don’t claim to have a good solution for this either.

<Personal opinion hat>
AFAICT, select is a solution looking for a problem. Until we see a real problem for it to solve, we should consider jettisoning it.
</Personal opinion hat>

> And I must disagree with the EL analogy, As we know handling of ELI for LDP based LSPs (rfc6790) is completely different then handling of ELI in SR-MPLS enabled networks (rfc8662). 

My point was that the architecture already supports scanning the label stack and having something other than the topmost label affect forwarding.

Regards,
T

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Apr 2022 22:03:51 +0200

Hi Tony,

> <Personal opinion hat>
> AFAICT, select is a solution looking for a problem. Until we see a real
> problem for it to solve, we should consider jettisoning it.
> </Personal opinion hat>
>

Well consider domain wide labels across three areas and single LSP end to
end between PEs. I think it would be quite useful and practical to get iOAM
postcards from ABRs when packets cross area boundaries for selected flows
of selected apps.

Kind regards,
R.

---

From: Haoyu Song <[email-masked]>
Date: Thu, 7 Apr 2022 20:17:40 +0000

Hi Greg,

I'm curious where is the concept of IOAM session specified?
My understanding is that IOAM run statelessly. A capable node, unless it's configured to not process IOAM, should process it if it finds the IOAM header in a packet. The head node determines on which packets the IOAM header is added.

Regards,
Haoyu

From: mpls <[email-masked]> On Behalf Of Greg Mirsky
Sent: Thursday, April 7, 2022 12:39 PM
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]
Subject: Re: [mpls] Notes from Open DT meeting 2022-04-07.

Hi Robert,
I believe that the IOAM session identifier will be present in IOAM-in-MPLS shim, whether as ISD or PSD.

Regards,
Greg

On Thu, Apr 7, 2022 at 12:35 PM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

But your answer actually brings a very interesting yet orthogonal to the original question a new consideration :)

How said IOAM identifiers (many as there can be millions of flows) is connected with ISD (or PSD) encoded action ?

Thx a lot,
R.

On Thu, 7 Apr 2022 at 21:29, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,
I' try to answer the IOAM-related question.
An IOAM monitoring session is expected to have a unique identifier. That identifier can be provisioned to P nodes that are required to produce op-path telemetry information for the monitored flow.

Regards,
Greg

On Thu, Apr 7, 2022 at 12:14 PM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Dear WG,

Kind regards,
Robert

On 2022-04-05 00:36, Loa Andersson wrote:
> https://trac.ietf.org/trac/mpls/wiki/2022-04-07-agenda<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fmpls%2Fwiki%2F2022-04-07-agenda&data=04%7C01%7Chaoyu.song%40futurewei.com%7C6bb3483203a44e8b1e0108da18ce6338%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637849571968049992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TidgS84HmJvxdfDcYar5pq0jGb7fT4sHPU8cYeDEi0s%3D&reserved=0>

/Loa

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C6bb3483203a44e8b1e0108da18ce6338%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637849571968049992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5yaBcNaHwAe1nmwSClOxjmkaxlpaovr48%2Fm0i4UegYY%3D&reserved=0>
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C6bb3483203a44e8b1e0108da18ce6338%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637849571968049992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5yaBcNaHwAe1nmwSClOxjmkaxlpaovr48%2Fm0i4UegYY%3D&reserved=0>

---

From: John E Drake <[email-masked]>
Date: Thu, 7 Apr 2022 20:47:11 +0000

Robert,

This is what we had been considering:

For segment routing, as a placeholder, we will follow the RFC 8662 model and place an NAS  at regular intervals throughout the MPLS label stack, with the understanding that the current copy of the NAS will eventually rise to the top of stack.  For hop-by-hop, every node processes the current copy of the NAS and the node that pops the forwarding label that exposes it has to remove it.  For select, *only* the node that pops the forwarding label that exposes it processes and removes it.  For label swapping, we can place the NAS immediately after the top of stack label.

Yours Irrespectively,

John

Juniper Business Use Only
From: mpls <[email-masked]> On Behalf Of Robert Raszuk
Sent: Thursday, April 7, 2022 3:48 PM
To: Tony Li <[email-masked]>
Cc: [email-masked]
Subject: Re: [mpls] Notes from Open DT meeting 2022-04-07.

[External Email. Be cautious of content]

Hi Tony,

Kind regards,
Robert

On Thu, 7 Apr 2022 at 21:36, Tony Li <[email-masked]<mailto:[email-masked]>> wrote:

Hi Robert,

How to specify which nodes need to perform the contained functions is very much a matter for specific solutions.  From what I've seen, solutions typically encode the scope as part of the sub-stack, either specifying hop-by-hop for every node along the path or ingress-to-egress for only the last node on the path.  While we have discussed a 'select' scope, I have yet to see a fully fleshed out solution for this and there is still some debate as to whether or not select is actually necessary. In any case, this is really a good question for the specific solution proposals.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Apr 2022 22:53:19 +0200

Hi John,

> For select, *only* the node that pops the forwarding label that exposes
it processes and removes it.

I am afraid that does not work for lots of deployments which use SR-MPLS as
pure replacement for LDP and use just single ingress to egress transport
domain wide label.

Requirement to artificially make transit nodes as segment endpoints would
IMO be way too much to ask.

Yours,
Robert.

On Thu, 7 Apr 2022 at 22:47, John E Drake <[email-masked]> wrote:

> For segment routing, as a placeholder, we will follow the RFC 8662 model
> and place an NAS  at regular intervals throughout the MPLS label stack,
> with the understanding that the current copy of the NAS will eventually
> rise to the top of stack.  For hop-by-hop, every node processes the current
> copy of the NAS and the node that pops the forwarding label that exposes it
> has to remove it.  For select, *only* the node that pops the forwarding
> label that exposes it processes and removes it.  For label swapping, we can
> place the NAS immediately after the top of stack label.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> *From:* mpls <[email-masked]> *On Behalf Of * Robert Raszuk
> *Sent:* Thursday, April 7, 2022 3:48 PM
> *To:* Tony Li <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [mpls] Notes from Open DT meeting 2022-04-07.
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Tony,
>
>
>
> And I must disagree with the EL analogy, As we know handling of ELI for
> LDP based LSPs (rfc6790) is completely different then handling of ELI in

---

From: John E Drake <[email-masked]>
Date: Thu, 7 Apr 2022 20:56:09 +0000

We’re open to suggestions

Sent from my iPhone

On Apr 7, 2022, at 4:52 PM, Robert Raszuk <[email-masked]> wrote:

Hi John,

> For select, *only* the node that pops the forwarding label that exposes it processes and removes it.

I am afraid that does not work for lots of deployments which use SR-MPLS as pure replacement for LDP and use just single ingress to egress transport domain wide label.

Requirement to artificially make transit nodes as segment endpoints would IMO be way too much to ask.

Yours,
Robert.

On Thu, 7 Apr 2022 at 22:47, John E Drake <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Yours Irrespectively,

John

Juniper Business Use Only
From: mpls <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Thursday, April 7, 2022 3:48 PM
To: Tony Li <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Notes from Open DT meeting 2022-04-07.

Hi Tony,

Kind regards,
Robert

Hi Robert,

Tony

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 7 Apr 2022 14:35:56 -0700

Hi Haoyu,
I think that there might be an operational value in controlling IOAM
capability per a flow. If that is the case, then we can discuss using the
Reserved field in IOAM-in-MPLS shim proposed in draft-gandhi-mpls-ioam-sr
<https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-ioam-sr-02>.

Regards,
Greg

On Thu, Apr 7, 2022 at 1:17 PM Haoyu Song <[email-masked]> wrote:

> Hi Greg,
>
>
>
> I’m curious where is the concept of IOAM session specified?
>
> My understanding is that IOAM run statelessly. A capable node, unless it’s
> configured to not process IOAM, should process it if it finds the IOAM
> header in a packet. The head node determines on which packets the IOAM
> header is added.
>
>
>
> Regards,
>
> Haoyu
>
>
>
> *From:* mpls <[email-masked]> *On Behalf Of * Greg Mirsky
> *Sent:* Thursday, April 7, 2022 12:39 PM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* [email-masked]
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fmpls%2Fwiki%2F2022-04-07-agenda&data=04%7C01%7Chaoyu.song%40futurewei.com%7C6bb3483203a44e8b1e0108da18ce6338%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637849571968049992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TidgS84HmJvxdfDcYar5pq0jGb7fT4sHPU8cYeDEi0s%3D&reserved=0>
>
> /Loa
>
> >
> > /Loa
> >
> > PS
> >
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C6bb3483203a44e8b1e0108da18ce6338%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637849571968049992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5yaBcNaHwAe1nmwSClOxjmkaxlpaovr48%2Fm0i4UegYY%3D&reserved=0>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C6bb3483203a44e8b1e0108da18ce6338%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637849571968049992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5yaBcNaHwAe1nmwSClOxjmkaxlpaovr48%2Fm0i4UegYY%3D&reserved=0>
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Apr 2022 17:50:25 -0400

Robert, I am not following yur statement.  If you have the case wher 
eyou want some specific intermediate node to process some isntruction, 
you are going to have to add a label indicating that to the stack.  that 
label is the one which, when removed, reveals the "selective" action in 
stack data.  So it seems quite sensible.

The ability to do that is an inherent part of the MPLS design and 
particularly the design of SR-MPLS.

When you don't need such control, then you don't use it.  And you won't 
have any selective actions in the stack.

Yours,
Joel

On 4/7/2022 4:53 PM, Robert Raszuk wrote:
> I am afraid that does not work for lots of deployments which use SR-MPLS 
> as pure replacement for LDP and use just single ingress to egress 
> transport domain wide label.
> 
>     Robert,____
>     __ __
>     This is what we had been considering:____
> 
>     __ __
> 
>     For segment routing, as a placeholder, we will follow the RFC 8662
>     model and place an NAS  at regular intervals throughout the MPLS
>     label stack, with the understanding that the current copy of the NAS
>     will eventually rise to the top of stack.  For hop-by-hop, every
>     node processes the current copy of the NAS and the node that pops
>     the forwarding label that exposes it has to remove it.  For select,
>     *only* the node that pops the forwarding label that exposes it
>     processes and removes it.  For label swapping, we can place the NAS
>     immediately after the top of stack label. __ __
> 
>     __ __
> 
>     Yours Irrespectively,____
> 
>     __ __
> 
>     John____
> 
>     __ __
> 
>     __ __
> 
>     Juniper Business Use Only____
> 
>     *From:* mpls <[email-masked] <mailto:[email-masked]>>
>     *On Behalf Of * Robert Raszuk
>     *To:* Tony Li <[email-masked] <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [mpls] Notes from Open DT meeting 2022-04-07.____
> 
>     __ __
> 
>     *[External Email. Be cautious of content]____*
> 
>     __ __
> 
>     Hi Tony, ____
> 
>     __ __
> 
>     Sounds to me that action 'scope' is an afterthought not a principle
>     of the proposed architecture.  IMHO that should be part of the
>     framework and not so much a specific solution based on the
>     framework. ____
> 
>     __ __
> 
>     I still do not see how using domain wide label from ingress to
>     egress one could execute given action on specific P nodes. Sure one
>     could think of a solution to encode list of such nodes in the PSD
>     but this would be rather (to say it gently) quite inelegant. ____
> 
>     __ __
> 
>     And I must disagree with the EL analogy, As we know handling of ELI
>     for LDP based LSPs (rfc6790) is completely different then handling
>     of ELI in SR-MPLS enabled networks (rfc8662). ____
> 
>     __ __
> 
>     Kind regards,
>     Robert____
> 
>     __ __
> 
>     On Thu, 7 Apr 2022 at 21:36, Tony Li <[email-masked]
>     <mailto:[email-masked]>> wrote:____
> 
>         __ __
> 
>         Hi Robert, ____
> 
>         __ __
> 
>             But it is very unclear to me how the proposed solution would
>             work with concept of domain wide MPLS labels. Especially
>             considering requirement that not all LSR nodes need to
>             execute given function on a specific packets. ____
> 
>         __ __
> 
>         __ __
> 
>         MNA would operate in the same way with domain wide labels as
>         with hop-by-hop labels. Each LSR would consult the topmost
>         label, scan the label stack and discover the Network Action
>         Indicator.  It would then parse the Network Action Sub-stack and
>         process it accordingly.____
> 
>         __ __
> 
>         How to specify which nodes need to perform the contained
>         functions is very much a matter for specific solutions.  From
>         what I’ve seen, solutions typically encode the scope as part of
>         the sub-stack, either specifying hop-by-hop for every node along
>         the path or ingress-to-egress for only the last node on the
>         path.  While we have discussed a ’select’ scope, I have yet to
>         see a fully fleshed out solution for this and there is still
>         some debate as to whether or not select is actually necessary.
>         In any case, this is really a good question for the specific
>         solution proposals.____
> 
>         __ __
> 
>         __ __
> 
>             Is support of MNA compatible work with SR-MPLS considering
>             as example case where there is no transit segment endpoints,
>             but just ingress and egress LSRs. Let's take basic execution
>             of in-situ OAM (postcard mode) on just few specific P
>             routers. For simplicity let's assume that MNA and that
>             function is supported on all P routers in the domian. ____
> 
>             __ __
> 
>             How would P nodes inspecting the arriving packets know that
>             the encoded action is for them to execute ?____
> 
>         __ __
> 
>         __ __
> 
>         Yes, MNA is compatible with SR-MPLS.  P nodes would perform the
>         process outlined above.____
> 
>         __ __
> 
>         Note that this is somewhat similar to what is done already with
>         the entropy label, so there is precedent for this in the
>         architecture.  Of course, we are adding functionality.____
> 
>         __ __
> 
>         Tony____
> 
>         __ __
> 
>         __ __
> 
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 8 Apr 2022 00:02:11 +0200

Hi Joel,

> you are going to have to add a label indicating that to the stack.

What you state above is true for legacy model where action and scope is all
embedded into each packet. I am not proposing that.

I am proposing complete departure from it (yet 100% compatible with
existing MPLS data plane) as briefly described in my previous emails
exchange with Tony.

Honestly stuffing ISDs and PSDs into existing label stack I find to be not
attractive enough to compete with SRv6. It's almost like reinventing the
wheel yet with significant cost associated with it. (By cost I mean both
packet overhead as well as CAPEX).

Perhaps there will be few customers ready to go for it (never underestimate
the power of marketing), but I am afraid instead of doing something much
better and strategic for MPLS folks are still trying to merely catch-up
with a subset of SR  NP. I do not understand why.

Kind regards,
Robert

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Apr 2022 18:07:34 -0400

If you want to propose a completely different way of using the MPLS data 
plane, and you want the WG to consider it, then please, write it up in a 
draft.  Until you do, I for one am going to assume we are discussing the 
known or formally proposed behaviors.

Having said that, if I understand your proposal properly, it requires 
having a label which (subject to remapping along the path) has the 
correct meaning at every special purpose node on that path.  And goes 
with only that path.  That sounds like the very difficult to scale path 
advertisement approach that was proposed by others years ago.  But as 
with all members of this community, you are free to tilt and any 
windmill you choose.

Yours,
Joel

On 4/7/2022 6:02 PM, Robert Raszuk wrote:
> What you state above is true for legacy model where action and scope is 
> all embedded into each packet. I am not proposing that.
> 
> Honestly stuffing ISDs and PSDs into existing label stack I find to be 
> not attractive enough to compete with SRv6. It's almost like 
> reinventing the wheel yet with significant cost associated with it. (By 
> cost I mean both packet overhead as well as CAPEX).
> 
> Perhaps there will be few customers ready to go for it (never 
> underestimate the power of marketing), but I am afraid instead of doing 
> something much better and strategic for MPLS folks are still trying to 
> merely catch-up with a subset of SR  NP. I do not understand why.
> 
> Kind regards,
> Robert
> 
> 
> 
> On Thu, 7 Apr 2022 at 23:50, Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     that
>      > On Thu, 7 Apr 2022 at 22:47, John E Drake <[email-masked]
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Robert,____
>      >
>      >     __ __
>      >
>      >     *From:* mpls <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >     *To:* Tony Li <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:____
>      >
>      >         __ __
>      >
>      >         Hi Robert, ____
>      >
>      >         __ __
>      >
>     ____
>      > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mpls>
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 8 Apr 2022 00:41:29 +0200

Hi Joel,

Thank you. And just for the record:

> having a label which (subject to remapping along the path)

No remapping of ALI is required anywhere along the path.

+

> That sounds like the very difficult to scale path
> advertisement approach that was proposed by others years ago.

I never mentioned in the discussed context "path advertisement".

- -

Perhaps your above conclusions are caused by mentioning reference to IP TE
draft - if so not intended. Here I am only proposing to use subset of it.

Kind regards,
R.

On Fri, 8 Apr 2022 at 00:07, Joel M. Halpern <[email-masked]> wrote:

> >      > Requirement to artificially make transit nodes as segment
> endpoints
> >      > would IMO be way too much to ask.
> >      >
> >      > Yours,
> >      > Robert.
> >      >
> >      >

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 8 Apr 2022 02:53:47 +0000

Hi Tony and Robert,

Please find some comments inline:

From: mpls [mailto:[email-masked]] On Behalf Of Tony Li
Sent: Friday, April 8, 2022 3:36 AM
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]
Subject: Re: [mpls] Notes from Open DT meeting 2022-04-07.

Hi Robert,

[Jie] As I have mentioned in the past DT meetings, the above behavior is somehow different from the processing of entropy label as specified in RFC 6790. A transit node can simply use “as much of the whole label stack” as keys for load-balancing, thus it is not required to scan the label stack to find the ELI/EL.

Quoting from RFC 6790:

 “Transit LSRs MAY operate with no change in forwarding behavior.  The
   following are suggestions for optimizations that improve load
   balancing, reduce the amount of packet data processed, and/or enhance
   backward compatibility.

   If a transit LSR recognizes the ELI, it MAY choose to load balance
   solely on the following label (the EL); otherwise, it SHOULD use as
   much of the whole label stack as feasible as keys for the load-
   balancing function.  In any case, reserved labels MUST NOT be used as
   keys for the load-balancing function.”

[Jie] Similar to the comment above, “scanning the label stack to find ELI” is not the required behavior in entropy label processing. Thus I’d suggest to be clear about where we are, and discuss whether it is reasonable to make this the default behavior for MPLS packet processing.

Best regards,
Jie

Tony

---

From: Loa Andersson <[email-masked]>
Date: Sat, 9 Apr 2022 14:10:53 +0800

Sent from my iPhone
Tony snd Robert,

Inline please. 

> On 8 Apr 2022, at 03:56, Tony Li <tony.li@
> 
> <Personal opinion hat>
The use case I’ve heard, is when someone want to turn on a counter, and count “something”, [all packets, packets in a flow, dropped packets, or whatever] until the next packet arrives with the turn off and report trigger. I told the use case team. They said “hmmm interesting, but I have mot heard more than that. 

/Loa