Re: [mpls] Label encoding in LDP

Alexander Okonnikov <alexander.okonnikov@gmail.com> Fri, 21 June 2019 12:06 UTC

Return-Path: <alexander.okonnikov@gmail.com>
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 0E73712022A for <mpls@ietfa.amsl.com>; Fri, 21 Jun 2019 05:06:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Level:
X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dT1k-w-aOxi7 for <mpls@ietfa.amsl.com>; Fri, 21 Jun 2019 05:06:11 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF538120106 for <mpls@ietf.org>; Fri, 21 Jun 2019 05:06:10 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id b11so4922256lfa.5 for <mpls@ietf.org>; Fri, 21 Jun 2019 05:06:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3bFqyvm6z9yNbVfbz2JThSjPq31HZa9sg6APiveUw/U=; b=oFjZuVbpadIvzfDAkbfmweJGfi0EBAItxeQEa5IyCDBQZjjLoQtUY5amzBGbDNr2yk GACdFpM+wFybaEzGXgosBXLluBVqwDs6ngT1pp7TN1OkO5A+RHHQuTsp8ATaTf8PeLkw 3vQVk+9w+S2j4iCZoghAiH8qRmkUYEOKd9zNUvO8+cXTHC+KntjOsLCZmz55EdUBS+5K MpOzoMSvPJ8gOgu7yzQkw0BePDOCFoR2u6v27guuK0ZgoKGTuhnaw+SxV7oaz9NyfqCK 2ggayDRWFTO3sQSC3wJaSKfY/9bAnL45DqzF9T6NTGk6nkFSeRWDCl50UDyD8rICqOqJ GWKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=3bFqyvm6z9yNbVfbz2JThSjPq31HZa9sg6APiveUw/U=; b=YSrFxqocrFeKkzRq9m8S4LpkT1VrRSbpxPgY5RGN3Twdnht9liJJqTyPsY9x+IRFGW 48IuGwL8AsjzAta+HEhKYLKsvot29ykiV4HGxdLaI7dGuGP0XZPIgPwYOl0MkACPY7Y6 uPKL76MvyDfK/15NTy0GsiOirhJH3q+LOQOeXKqUqutrqCkaO37YfnFZjtw6XcJRxmiE +I0aGUtFkrDeAKkLQGsNRJYPYnSvVyAwZ5IYAN8DnYvz4wjbP2jYTbnXRReBwnk5EIeh x/N0zMWcNU2UwFWLzYH9AtFZPGYnkHGpfN8cBxHGabJy3MeKhITqcCZKO0eY/mHEAE9D ILsQ==
X-Gm-Message-State: APjAAAXZshqP5W5UkSVw2wy9SIKDLa1xBe5WC268gLW5MLKUOCjJ/iyF 7iHRb9Q275KS9+Cwl4/T5VQ=
X-Google-Smtp-Source: APXvYqxd7SH6m9k20x4NPee5sUpxippEScqmy0G08kMvlNsCdP+m2xiveJtRlzfykZT+WCmvfP/3wg==
X-Received: by 2002:a05:6512:30a:: with SMTP id t10mr18205888lfp.22.1561118768980; Fri, 21 Jun 2019 05:06:08 -0700 (PDT)
Received: from secretmaker-195.ip.peterstar.net (secretmaker-195.ip.PeterStar.net. [217.195.72.195]) by smtp.gmail.com with ESMTPSA id e14sm358039lfd.84.2019.06.21.05.06.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jun 2019 05:06:08 -0700 (PDT)
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Message-Id: <AA236CF8-25AF-41AA-A058-886A2B73066E@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C982AD26-4791-4097-860C-3A820E720523"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 21 Jun 2019 15:06:07 +0300
In-Reply-To: <CAEh1p15S8WD_f1e4pQzRNh1W88sZQifo+_2wfXhzzDLFwhpZew@mail.gmail.com>
Cc: mpls@ietf.org
To: Ramakrishna Rao Desetti <ramakrishnadtv@gmail.com>
References: <CAEh1p17W5V=VZHvHdxYEN8x1dYVXdKCTNuDyEuhDND0bNJEL0A@mail.gmail.com> <81DCFE10-1966-4DD0-B6A2-FC199D6478A6@gmail.com> <CAEh1p15S8WD_f1e4pQzRNh1W88sZQifo+_2wfXhzzDLFwhpZew@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/Ws3UZHQymDt627DFnn-suUFwZ6g>
Subject: Re: [mpls] Label encoding in LDP
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 21 Jun 2019 12:06:13 -0000

Hi Ramakrishna,

Per my understanding, RFC 3036 says that 20-bit value to be filled in to 32-bit field. It doesn't say that it should be encoded in 20 most significant bits, hence, it is to be encoded in 20 least significant bits. RFC 3036 refers to RFC 3032 regarding what is 20-bit label entity, not regarding label value positioning in 32-bit field. On the other hand, RFC 5036 provides additional figure, where it is explicitly shown, that label value to be encoded in 20 most significant bits of 32-bit field, like it is being done for label value in label stack entry per RFC 3032. However, "label" and "label in label stack entry" are not the same things, though they are both - label field in Generic Label TLV in RFC 3036 and label stack entry in RFC 3032 - 32 bits in length. Hence, in your case netbsd implementation and another commercial implementation follow encoding rules from RFC 3036.

This difference between RFC 3036 and RFC 5036 means that implementations, that follow RFC 5036 in part of generic label encoding, are not backward compatible with RFC 3036 based implementations.

> 21 июня 2019 г., в 14:50, Ramakrishna Rao Desetti <ramakrishnadtv@gmail.com>; написал(а):
> 
> Hi Alexander,
> 
> My impression is that RFC 5036 and RFC 3036 do not differ in terms of intended label encoding.
> However, RFC 5036 does add more material to clarify the intended encoding.
> 
> Thanks,
> Ramakrishna.
> 
> 
> On Thu, Jun 20, 2019 at 9:30 PM Alexander Okonnikov <alexander.okonnikov@gmail.com <mailto:alexander.okonnikov@gmail.com>> wrote:
> Hi Ramakrishna,
> 
> It seems that many of implementations follow RFC 3036 in part of General Label TLV encoding, while claim support of RFC 5036. RFC 5036 specifies another format of encoding, as you mentioned, though it doesn't notice that difference in section 7.
> 
>> 20 июня 2019 г., в 13:45, Ramakrishna Rao Desetti <ramakrishnadtv@gmail.com <mailto:ramakrishnadtv@gmail.com>> написал(а):
>> 
>> Hi,
>> 
>> I request a clarification on label encoding in LDP.
>> The reason is it appears implementations do not seem to follow what is specified
>> in the LDP standard.
>> 
>> I have reproduced the relevant text from RFC 5036:
>> 
>> "
>> 3.4.2.1.  Generic Label TLV
>> 
>>    An LSR uses Generic Label TLVs to encode labels for use on links for
>>    which label values are independent of the underlying link technology.
>>    Examples of such links are PPP and Ethernet.
>> 
>>     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
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |0|0| Generic Label (0x0200)    |      Length                   |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |     Label                                                     |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>>    Label
>>       This is a 20-bit label value represented as a 20-bit number in a 4
>>       octet field as follows:
>> 
>>        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
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       |     Label                             |                       |
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>>       For further information, see [RFC3032].
>> "
>> 
>> I have tested with 3 systems: Netbsd, wireshark, and a popular commercial
>> vendor.
>> 
>> In all these cases, the label is encoded as shown below:
>> 
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |     Label                                                     |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>> But from the RFC, it should be encoded as shown below:
>> 
>>       This is a 20-bit label value represented as a 20-bit number in a 4
>>       octet field as follows:
>> 
>>        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
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       |     Label                             |                       |
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>> Note that these two representations are not same.
>> 
>> For example, suppose label is 3. Then in the first representation, it is sent
>> on the wire as:
>> 
>> 0x00, 0x00, 0x00, 0x03.
>> 
>> Where as, in the 2nd representation, it is sent on the wire as:
>> 
>> 0x00, 0x00, 0x30, 0x00.
>> 
>> Am I missing something?
>> 
>> I request your comments.
>> 
>> Thanks and regards,
>> Ramakrishna DTV.
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org <mailto:mpls@ietf.org>
>> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
>