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

["Bocci, Matthew (Nokia - GB)" <[e-mail]>]

Hi Haoyu

Thank you for your comments.

Please see below.

Matthew

From: Haoyu Song <[e-mail]>
Date: Thursday, 14 October 2021 at 19:15
To: Bocci, Matthew (Nokia - GB) <[e-mail]>, Loa Andersson <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, DetNet Chairs <[e-mail]>
Subject: on MIAD ADI requirement draft RE: [mpls] Agenda for the MPLS Open DT 2021-10-14
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?


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

From: mpls <[e-mail]> On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Thursday, October 14, 2021 5:45 AM
To: Loa Andersson <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; DetNet Chairs <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> on behalf of Loa Andersson <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 13 October 2021 at 10:12
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, DetNet Chairs <[e-mail]<mailto:[e-mail]>>
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: [e-mail]<mailto:[e-mail]>
Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>
Bronze Dragon Consulting             phone: [phone]

_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
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>