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

[Tony Li <[e-mail]>]

There are mechanisms for routers to advertised their readable label stack depth in their IGP.  So a less theoretical approach would be for our operational brethren to query their IGP and report back. I would expect a fairly peaky histogram.  SR based networks would be particularly aware of this.

Hardware folks have been indirectly involved in the design of existing solutions and they have directed us away from several encoding options, such as continuation bits. Instead, we have been using length fields.

Tony


> On Feb 23, 2023, at 6:00 AM, Joel Halpern <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls