Re: [mpls] Another way...

Hello Jie,

   I was mentioning an option of using the PSD offset opcode as an
indicator for the PSD presence.

   In case PSD offset opcode is encoded in the Format-B, then it is in the
same level as proposed "P" bit, so I did not see any reason why this
approach always consumes additional LSE.
   I agree that if anyone wishes to encode an ISD opcode using Format-B
along with a PSD, it may require an additional LSE beyond what the current
approach entails

Thanx,
Jags

On Wed, Mar 20, 2024 at 8:24 PM Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

> Hi Jags,
>
>
>
> Thanks for sharing opinion on this.
>
>
>
> In my understanding the PSD offset opcode is optional and is not needed
> when PSD follows immediately after the EOS.  Making it mandatory for PSD
> would always consume one LSE and would reduce the space available for ISD.
>
>
>
> Another point is the position of the PSD offset opcode in NAS is not
> fixed, which means for a node which only supports PSD, it may need to parse
> the preceding ISDs to find the indicator of PSD. This is not efficient in
> implementation, and also makes the implementation of PSD coupled with ISD.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* mpls <mpls-bounces@ietf.org> *On Behalf Of *Jaganbabu Rajamanickam
> *Sent:* Wednesday, March 20, 2024 8:44 AM
> *To:* loa@pi.nu
> *Cc:* mpls <mpls@ietf.org>
> *Subject:* Re: [mpls] Another way...
>
>
>
> 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 <loa@pi.nu> 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 <haoyu.song@futurewei.com>
> >> 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 <mpls-bounces@ietf.org> On Behalf Of Tony Li
> >> Sent: Wednesday, March 13, 2024 8:29 AM
> >> To: Loa Andersson <loa@pi.nu>
> >> Cc: mpls <mpls@ietf.org>
> >> 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
> >> mpls@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mpls
> >
> >
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>