Subject: [mpls] on MIAD ADI requirement draft RE: Agenda for the MPLS Open DT 2021-10-14

From: Haoyu Song <[email-masked]>
Date: Thu, 14 Oct 2021 18:15:34 +0000

Hi Matthew and Stewart,

Thank you for publishing the draft! This is a great start for further discussion. Below are some of my questions after a quick review. Thanks!

  1.  "Neither an ADI or ancilliary data must be delivered to a node that is not capable of processing it."
I guess this sentence means "An ADI or ancillary data must not be ...". If so, what does the "node" mean? If it can be a network node (e.g., P router), I think it's possible for it to be unaware of the ADI/AD but still can forward the packet. Any clarification here?

  1.  "The mechanism to indicate that Ancilliary Data is present MUST operate in the context of the top of stack LSE."
Do you mean the ADI must be top of stack label?

  1.  "ADIs can only be inserted at LERs, ..."
Do we formally decide that we'll never allow an LSR to initiate or terminate a network function/AD? If so, what makes we believe this must be limited to LER?

  1.  " A solition must be provided to verify the authenticity of  ancillary data processed to LSRs. "
Do you mean "solution .... processed by"? Not sure we need this to be a "must", otherwise this may create unbearable burden to the system.

  1.  "The design of the ADIs and ancillary data must not expose confidential information to the LSRs."
What are considered "confidential information"? Any example or definition? I think this needs to be clarified.

Best regards,
Haoyu

From: mpls <[email-masked]> On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Thursday, October 14, 2021 5:45 AM
To: Loa Andersson <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: Re: [mpls] Agenda for the MPLS Open DT 2021-10-14

Loa

I have posted a first draft for the MIAD requirements here.

draft-bocci-mpls-miad-adi-requirements-00 - Requirements for MPLS Label Stack Indicators for Ancillary Data (ietf.org)<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-bocci-mpls-miad-adi-requirements%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb6c20ceda8734c7bb4ca08d98f108617%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637698123407271600%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GinuVkgLbjoz0M7rulzo4C%2BvPRMpP8yERqhQ6EeI8R8%3D&reserved=0>

Maybe we can take a look during the Requirements slot on the Open DT agenda.

Matthew

From: mpls <[email-masked]<mailto:[email-masked]>> on behalf of Loa Andersson <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 13 October 2021 at 10:12
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, DetNet Chairs <[email-masked]<mailto:[email-masked]>>
Subject: [mpls] Agenda for the MPLS Open DT 2021-10-14
MPLS Open DT,

I have posted the agenda for tomorrow:

https://trac.ietf.org/trac/mpls/wiki/2021-10-14-agenda<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fmpls%2Fwiki%2F2021-10-14-agenda&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb6c20ceda8734c7bb4ca08d98f108617%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637698123407271600%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZigZ8bL%2BhJhcnxx2VFTk6ym7YsZ%2BGkRNizELJdCGtrM%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%7Cb6c20ceda8734c7bb4ca08d98f108617%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637698123407281557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5572UBJD4YqBJsDmTncYB9K5XO%2FI15WaNxilNlwSW1Q%3D&reserved=0>

---

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Mon, 18 Oct 2021 08:55:23 +0000

Hi Haoyu

Thank you for your comments.

Please see below.

Matthew

From: Haoyu Song <[email-masked]>
Date: Thursday, 14 October 2021 at 19:15
To: Bocci, Matthew (Nokia - GB) <[email-masked]>, Loa Andersson <[email-masked]>, [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, DetNet Chairs <[email-masked]>
Subject: on MIAD ADI requirement draft RE: [mpls] Agenda for the MPLS Open DT 2021-10-14
Hi Matthew and Stewart,

  1.  “Neither an ADI or ancilliary data must be delivered to a node that is not capable of processing it.”
I guess this sentence means “An ADI or ancillary data must not be …”. If so, what does the “node” mean? If it can be a network node (e.g., P router), I think it’s possible for it to be unaware of the ADI/AD but still can forward the packet. Any clarification here?

MB> Yes, agreed. What we meant here was, assuming we have some sort of exception mechanism for ancillary data that causes the data to be inspected, for example an SPL, that exception must only be targeted to occur at LSRs that are capable of processing the ancillary data. i.e. we must be sure it can recognize the ADI and process it rather than drop or mis-route the packet.

  1.  “The mechanism to indicate that Ancilliary Data is present MUST operate in the context of the top of stack LSE.”
Do you mean the ADI must be top of stack label?

MB> This is something we need a discussion on but, in essence, what we are saying is that it must be consistent with the MPLS architecture. An LSR just does a swap of the top label, or a pop and forward, but unless it is doing something like scanning the stack looking for an ELI it doesn’t change the fundamentals of MPLS forwarding behaviour based on labels below the top of stack. Even in the ELI case, it still forwards to an ECMP next hop where that top label is valid. Besides, the ADI is for ancillary data so it is subordinate to the basic MPLS forwarding decision.

  1.  “ADIs can only be inserted at LERs, …”
Do we formally decide that we’ll never allow an LSR to initiate or terminate a network function/AD? If so, what makes we believe this must be limited to LER?

MB> Well, it could terminate it similar to what we do with GAL when TTL expires, but if it was to insert it in an LSP wouldn’ it effectively require a pair of back-to-back LERs (although I suppose it is possible that you could have a ‘swap-to-ADI’ function if an ADI at the top of stack is all you need)?

  1.  ” A solition must be provided to verify the authenticity of ancillary data processed to LSRs. “
Do you mean “solution …. processed by”? Not sure we need this to be a “must”, otherwise this may create unbearable burden to the system.

MB> This is only a requirement on the development work, not on an implementation.

  1.  “The design of the ADIs and ancillary data must not expose confidential information to the LSRs.”
What are considered “confidential information”? Any example or definition? I think this needs to be clarified.

MB> I think we need to continue to maintain the existing principles of separation /isolation between the underlying MPLS network and overlay. One example might be if we encode ancillary data in the stack then that might be based on an IP SA/DA in the payload, but the mechanism shouldn’t require us to encode the actual SA/DA in the stack but rather some anonymized version of it that only achieves what we want to achieve for the network function. I think this is solution-specific, though, and any solution drafts need to have security considerations text that addresses these concerns.

Best regards,
Haoyu

Loa

Matthew

/Loa

--

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 21 Oct 2021 07:42:45 -0700

Hi Matthew,

On Oct 18, 2021, at 01:55, Bocci, Matthew (Nokia - GB) <[email-masked]> wrote:

> “The mechanism to indicate thatAncillary Data is present MUST operate in the context of the top of stack LSE.”

I’m not sure what this means, except possibly, the ADI MUST NOT be the top of stack LSE.  There were some suggestions that the FAI could be at the top of stack, accompanied by some label gymnastics to get the forwarding label.  This rules that option out (which I’m happy about).

Here’s some alternate text:

"The mechanism to indicate that Ancillary Data is present MUST allow for simple forwarding of MPLS packets based on the top of stack LSE.  A node MAY (SHOULD?) go further, though, to find the ADI within the label stack and act upon it."

> MB> This is something we need a discussion on but, in essence, what we are saying is that it must be consistent with the MPLS architecture. An LSR just does a swap of the top label, or a pop and fo…

I don’t know the full scope of the Requirements doc, but the FAI has a dual purpose: to indicate that certain forwarding actions are to be taken, and to carry relevant data for those actions.  An ADI (and its data) by itself isn’t much use.  Think of the ELI carrying an Entropy Label, but without the semantics of “load balance using this”.  Pretty useless. Or, for a more current example, carrying a GISS without saying, "this is the slice indicator; take the appropriate action”.  Essentially, “here’s a 32-bit field.  Have a nice day!” :)

One can say that the action is implicit in the type of data carried, but I prefer being explicit and more general.  FAI — forwarding actions indicator — focuses on the action, indicates the associated data, and is inclusive of cases (like NFFRR) where there isn’t associated data.

:k

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 21 Oct 2021 16:24:44 +0100

> On 21 Oct 2021, at 15:42, Kireeti Kompella <[email-masked]> wrote:
> 
> Hi Matthew,
> 
> On Oct 18, 2021, at 01:55, Bocci, Matthew (Nokia - GB) <[email-masked] <mailto:[email-masked]>> wrote:
> 

MPLS always operates in the context of the top of stack.

Sure when the FEC is IP it does some rummaging around for other information but when the FEC is not IP I don’t think it does that. It certainly should not.

By binding the operation of these new features to the ToS we avoid painting ourselves into any corners and get the option to revise or exclude the operation in the light of experience.

- Stewart