Re: [mpls] Another way...

[Tony Li <[e-mail]>]

Hi Jimmy,

It’s really up to the folks defining the opcode. How much ancillary data is required?  How many bits do you want for the offset, if any?

If it’s large, then you’ll need Format C (and D?).  If it’s small, it would fit in Format B or C. And if it’s just a bit, then it can become a flag and be co-located with other flags.

Tony

On Mar 22, 2024, at 10:09 AM, Dongjie (Jimmy) <jie.dong=[e-mail]> wrote:



Hi Jags,

 

If the PSD offset opcode can always be encoded in the format-B LSE (which means its position if fixed), and it is the only opcode in NAS, then the encapsulation overhead is the same as using one Flag bit in format-B LSE.

 

But if there is any ISD which needs to be carried using Format B, the above assumption would be broken. Thus some coordination between the ISD draft and PSD draft on this would be needed.

 

Best regards,

Jie

 

From: Jaganbabu Rajamanickam <[e-mail]>
Sent: Thursday, March 21, 2024 1:10 PM
To: Dongjie (Jimmy) <[e-mail]>
Cc: [e-mail]; mpls <[e-mail]>
Subject: 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) <[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/" target="_blank" rel="nofollow">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" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/mpls
>
>


_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls