Re: [mpls] Regarding adopting draft-song-mpls-extension-header - do we need post stack data?

[Joel Halpern <[e-mail]>]

It would be good to see a full description so we could understand if it 
can be dealt with by ISD, and what problems it solves.

Yours,

Joel

On 2/22/2023 1:17 PM, Stewart Bryant wrote:
> No, but it should probably be added to the use-case draft.
>
> There is a close friend of this application and mode of operation documented in RFC 8169
>
> - Stewart
>
>> On 22 Feb 2023, at 18:03, Joel Halpern <[e-mail]> wrote:
>>
>> Is there a draft with a description of this use case?
>>
>> Yours,
>>
>> Joel
>>
>> On 2/22/2023 12:58 PM, Stewart Bryant wrote:
>>> iOAM is  not the only use case, that is another in the latency control/deterministic networking area, which is in itself fundamental to the ambitions of the 5G/6G world. Some of these approaches require a timestamp in the packet and it is not clear that we can shoehorn this into the MPLS stack itself.
>>>
>>> I can also see a need for more sophisticated security models than we have at the moment, and again I doubt that we can fit these in the stack.
>>>
>>> So I do not think that we should preclude PSD at this stage.
>>>
>>> Now I suppose we might push ahead with the ISD components in advance of PSD, but we should be most careful not to preclude PSD from the design.
>>>
>>> Stewart
>>>
>>>> On 21 Feb 2023, at 11:32, Joel Halpern <[e-mail]> wrote:
>>>>
>>>> Since I just saw another email that aluded to this quesiton, and I have been thinking about it for some time, I thought I should post now.
>>>>
>>>> Poststtack data is admittedly powerful.  But it is not at all clear to me that we need that power.  And it adds significant complication to the MNA processing in many regards.
>>>>
>>>> The primary use case I could find reviewing drafts for post stack data is for IOAM data accumulation.  The direct export (postcard) proposals would remove the need for that.  And accumulating poststack data in a packet either means trying to estimate how much room to leave, generally wasteful, or even worse inserting information lengthening a packet at many hops, which is expensive and complicated.
>>>>
>>>> Why not just stick with the one piece of poststack data we have, the GAL/GACH, and handle everything else with in-stack data.
>>>>
>>>> Yours,
>>>>
>>>> Joel
>>>>
>>>> _______________________________________________
>>>> mpls mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mpls