Re: [mpls] Another way...

[[e-mail]]

Jags, all,

I remember that we discussed whether a packet could carry both ISD and
PSD, but I don't remember if we reached a consensus either way.

Anyone remember?

/Loa


> 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) <[e-mail]>
> 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 <[e-mail]> *On Behalf Of *Jaganbabu
>> Rajamanickam
>> *Sent:* Wednesday, March 20, 2024 8:44 AM
>> *To:* [e-mail]
>> *Cc:* mpls <[e-mail]>
>> *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 <[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
>>
>>
>