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

[Joel Halpern <[e-mail]>]

I actually find the question confusing.

There may be some existing devices that will be able to be upgraded to 
handle MNS (ISP with or without PSD) in the fast path.  But most devices 
will require significant upgrades.  As such, the readable label stack 
depth is likely to change in conjunction with the upgrade.

Also, I expect that some kinds of enhancements (handling entropy label 
in MNA) are going to be doable on more devices than others (inserting 
information into the bottom of the label stack.)  So the question of 
which implementations can provide us with which capabilities once this 
has had time to roll out seems very hard to evaluate.  (I would love to 
hear from the folks who specialize in building chips to do this as to 
whether they see any issues in any of the dimensions we are discussing.)

Yours,

Joel

On 2/23/2023 4:29 AM, Stewart Bryant wrote:
> I do not know, but I have heard numbers as small as 4 for edge devices and as small as 8 for core devices, although SR has increased these numbers.
>
> Others may have more up today information and of course we have the survey that we did, but I do not have that to immediate hand.
>
> - Stewart
>
>> On 23 Feb 2023, at 07:23, Dongjie (Jimmy) <[e-mail]> wrote:
>>
>> Hi Joel and Stewart,
>>
>> One major motivation of introducing ISD was to adapt to the limitation of readable label depth of the legacy hardware.
>>
>> Do you know the number of readable label depth supported by usual legacy devices? That may set an upper bound to the size of ISD, and the amount of data that can be carried with it.
>>
>> Best regards,
>> Jie
>>
>>> -----Original Message-----
>>> From: mpls [mailto:[e-mail]] On Behalf Of Joel Halpern
>>> Sent: Thursday, February 23, 2023 2:04 AM
>>> To: Stewart Bryant <[e-mail]>
>>> Cc: [e-mail]
>>> Subject: Re: [mpls] Regarding adopting draft-song-mpls-extension-header - do
>>> we need post stack data?
>>>
>>> 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
>>> _______________________________________________
>>> mpls mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls