Re: [mpls] Another way...

[Haoyu Song <[e-mail]>]

+1

If we consider that the NAS can be replicated and its size can be changed enroute, the pointer mechanism can be very tricky.

Haoyu

From: mpls <[e-mail]> On Behalf Of Dongjie (Jimmy)
Sent: Thursday, March 21, 2024 10:24 AM
To: Jaganbabu Rajamanickam <[e-mail]>; [e-mail]
Cc: mpls <[e-mail]>
Subject: Re: [mpls] Another way...

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]<mailto:[e-mail]>> On Behalf Of Jaganbabu Rajamanickam
Sent: Wednesday, March 20, 2024 8:44 AM
To: [e-mail]<mailto:[e-mail]>
Cc: mpls <[e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Tony Li
>> Sent: Wednesday, March 13, 2024 8:29 AM
>> To: Loa Andersson <[e-mail]<mailto:[e-mail]>>
>> Cc: mpls <[e-mail]<mailto:[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]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/mpls
>
>


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