Re: [mpls] Another way...

[Tony Li <[e-mail]>]

[WG chair hat: off]

Loa,

My memory says that there was no reason to preclude it and some benefit for actually having ISD if PSD was present, so that we could indicate that PSD was present.

T


> On Mar 22, 2024, at 1:06 PM, [e-mail] wrote:
> 
> 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
>>> 
>>> 
>> 
> 
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls