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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Joel, 

The question is about how much ISD based ancillary data the legacy hardware can support, considering their limitations in the readable label depth. 

By "significant upgrades", do you mean software or hardware upgrades, or both? Since the question is about the size of ISD the legacy hardware can support, hardware upgrade is considered out of scope. 

Considering the information from Stewart, it seems for the legacy hardware to support ISD, the total length of ISD can only be no more than 3 LSEs, including the SPL, the action indicators and ancillary data. There needs to be some space left for the forwarding and service labels. 

For SR-MPLS, there is one more concern with the size of ISD: to support hop-by-hop scope, the same ISD needs to be replicated several times in the label stack, which leaves much smaller space for carrying the SR SIDs. What is worse is that the larger the ISD, the lower the encapsulation efficiency (considering a case where every SR SID follows with an ISD).

Thus it was always my understanding that space in ISD is limited, which may be used for carrying the indicator and limited size of ancillary data, and PSD is necessary for the extensibility of MNA solution. 

Thoughts?

Best regards,
Jie

> -----Original Message-----
> From: Joel Halpern [mailto:[e-mail]]
> Sent: Thursday, February 23, 2023 10:00 PM
> To: Stewart Bryant <[e-mail]>; Dongjie (Jimmy)
> <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [mpls] Regarding adopting draft-song-mpls-extension-header -
> do we need post stack data?
> 
> 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