Re: [mpls] Another way...

[Jaganbabu Rajamanickam <[e-mail]>]

Hello All,

    In the PSD case, we may need a new ISD opcode to indicate the offset of
the start of PSD if PSD is not encoded immediately after the EOS.
    In section 6.1 of our PSD draft (
https://datatracker.ietf.org/doc/draft-jags-mpls-ps-mna-hdr/ ). We already
have mentioned that the new ISD opcode will be allocated with the format
option of Format-B or Format-C.

    I think we could use the same opcode to indicate the presence of PSD as
well. The offset could be zero or Non-Zero value.

    If we use a reserved bit in the Format-B to indicate the presence of
PSD and in case we encode the new PSD offset, then still we need to add an
additional opcode to be encoded.

Thanx,
Jags






On Thu, Mar 14, 2024 at 12:58 AM <[e-mail]> wrote:

> All,
>
> I have been thinking about using an OpCOde for a while, but have been
> reluctant to propose it. Several reasons, but mainly as the encoding grows
> more complicated we would either need a general encoding document or
> include this in the framework. Until we make up our minds there is some
> time and that delays progress of the other drafts.
>
> Another reason is that sometimes it is an entire LSE, and sometimes it
> is not.
>
> If we have just one OpCode after the Format A LSE (Opcode P (for PSD) it
> is no big deal.
>
> Example:
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      MNA-Label=bSPL (TBA)             | TC  |S|    TTL        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Opcode P  |        Data             |R|IHS|S| Res |U| NASL=0|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> and
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      MNA-Label=bSPL (TBA)             | TC  |S|    TTL        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Opcode X  |        Data             |p|IHS|S| Res |U| NASL=0|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Is roughly equivalent :) (I said roughly).
>
> However if there is another OpCOde
>
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      MNA-Label=bSPL (TBA)             | TC  |S|    TTL        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Opcode X  |        Data             |R|IHS|S| Res |U| NASL=1|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Opcode P  |       Ancillary Data          |0|  AD   | NAL=0 |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Is less efficient than
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      MNA-Label=bSPL (TBA)             | TC  |S|    TTL        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Opcode X  |        Data             |p|IHS|S| Res |U| NASL=0|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>
> Note: The discussion we have now about "changing" the format would
> potentially affect the Framework. Or even motivate a general MNA
> encoding document.
>
> Since both the OpCode and the p-bit are ISD, I think they should be
> assigned in draft-ietf-mpls-mna-hdr.
>
>
> /Loa
>
> >
> > In fact, it’s not a whole label.  If we’re talking about PSD, it’s
> > very likely that there’s nothing in ISD except for the PSD indication
> > and this opcode would fit in the Format B LSE without any additional
> > overhead.
> >
> > One could, in principle, generalize this to make the entire Format B data
> > space into extension bits of various flavors, with PSD being only one.
> >
> > We have many extension mechanisms, not just reserved bits.
> >
> > T
> >
> >> On Mar 13, 2024, at 11:36 AM, Haoyu Song <[e-mail]>
> >> wrote:
> >>
> >> I think this is very inefficient. While only a single bit is sufficient
> >> to server the purpose, why dedicate a whole label?
> >>
> >> Haoyu
> >>
> >> -----Original Message-----
> >> From: mpls <[e-mail]> On Behalf Of Tony Li
> >> Sent: Wednesday, March 13, 2024 8:29 AM
> >> To: Loa Andersson <[e-mail]>
> >> Cc: mpls <[e-mail]>
> >> Subject: [mpls] Another way...
> >>
> >>
> >> [WG chair hat: off]
> >>
> >> Hi Loa,
> >>
> >> It occurred to me that another way of indicating the presence of PSD
> >> would be to allocate an opcode to serve this purpose.
> >>
> >> This requires no reserved bits and no pre-definition of any value so it
> >> intrinsically cannot disappear.
> >>
> >> Tony
> >>
> >> _______________________________________________
> >> mpls mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mpls
> >
> >
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>