IETF Logo Mail Archive

Re: [mpls] Another way...

loa@pi.nu Thu, 14 March 2024 04:58 UTC

Return-Path: <loa@pi.nu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8742C14F6B1 for <mpls@ietfa.amsl.com>; Wed, 13 Mar 2024 21:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wb8F-_nMeNnr for <mpls@ietfa.amsl.com>; Wed, 13 Mar 2024 21:58:05 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B13C14F6AB for <mpls@ietf.org>; Wed, 13 Mar 2024 21:58:04 -0700 (PDT)
Received: from pi.nu (localhost.localdomain [127.0.0.1]) by pipi.pi.nu (Postfix) with ESMTP id 07E853A8FE2; Thu, 14 Mar 2024 05:58:02 +0100 (CET)
Received: from 124.106.198.177 (SquirrelMail authenticated user loa@pi.nu) by pi.nu with HTTP; Thu, 14 Mar 2024 05:58:02 +0100
Message-ID: <8e38ed70e0429b891cd89261e4221df9.squirrel@pi.nu>
In-Reply-To: <11840BF7-650C-4665-9E8D-8173F1451856@tony.li>
References: <EC290C02-4B81-4ABF-B1D8-A36849C104AC@tony.li> <BY3PR13MB4787EBC452CB744B3EEFCC799A2A2@BY3PR13MB4787.namprd13.prod.outlook.com> <11840BF7-650C-4665-9E8D-8173F1451856@tony.li>
Date: Thu, 14 Mar 2024 05:58:02 +0100
From: loa@pi.nu
To: Tony Li <tony.li@tony.li>
Cc: Haoyu Song <haoyu.song@futurewei.com>, Loa Andersson <loa@pi.nu>, mpls <mpls@ietf.org>
User-Agent: SquirrelMail/1.4.22
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/nwfgg1zsXLdQByqeyF2-VMQZQPU>
Subject: Re: [mpls] Another way...
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2024 04:58:08 -0000

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
>
>

v2.23.0 | Report a Bug | By Email