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

[Robert Raszuk <[e-mail]>]

Hi Jie, Dear WG,

Looks like your comments are spot on.

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).
>

If those are real numbers and limitations (considering different vendor's
hardware) then I am a bit puzzled what is the practical goal of this entire
ISD effort ?

> the same ISD needs to be replicated several times in the label stack

When I see any design which requires replicating data in the packet's
headers just to fit legacy architectures to me this is a clear indication
that it's time to start over or give up.

Regards,
Robert.
PS. Back to MNA-passive only mode ...



> 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
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>