IETF Logo Mail Archive

Re: [mpls] Label encoding in LDP

Alexander Okonnikov <alexander.okonnikov@gmail.com> Thu, 20 June 2019 16:00 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 4781012012B for <mpls@ietfa.amsl.com>; Thu, 20 Jun 2019 09:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 kf4KbZ2gNMeE for <mpls@ietfa.amsl.com>; Thu, 20 Jun 2019 09:00:55 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 012E212010D for <mpls@ietf.org>; Thu, 20 Jun 2019 09:00:54 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id v24so3163815ljg.13 for <mpls@ietf.org>; Thu, 20 Jun 2019 09:00:54 -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=gBrV40YHgHc+RvrrwRdQ0aHgjHcnpmNMXTVy6PYG1cY=; b=NAMaU8Ue2qLH1MVS3RH1UhS9d0qIYZauQGTaLMqpTua8JOH0CT0XGr7JHah/SbOaR3 dR0C6PvVQsqHyY+7eSziZrpCoTrVpf6TXw+NPRiT7uOGxLWQsxr4YhKGdlXFA7Bp4jNK Xwp6udjpq6KxXWFsXL0uLqZLoF1bgM7OGE5DIUD/IKUNCYTUrs2PP9+rzwtuGW0mUWkl 4KX29GP05puFrHNN34nOoI7+L10MGrKQs0BDsZiccmwaxWz31+St6y3rR/JMApC1cpGQ inMztFQdcUYjsSsSUsA1vu1lchizKmBd5fiiqgp1DYRwaa5HkvOqJUfEf55uMb9+YR7p 97fw==
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=gBrV40YHgHc+RvrrwRdQ0aHgjHcnpmNMXTVy6PYG1cY=; b=gMZDoliyHuVtUdCJ3EXFVty31308wQVuTugE0Fh6U+p+qCY7G0GyuYY4dddxXenrxs xYQNpuCK+QErR4OegYBcyzIrbk2dZRET9dSaY4T8kaVn1zua4cf1L+NTZUZLWxWz8jmT kMgP4PP6BQMoGuIQv6qOhMpey5igUd9OtJAKD5mYyoK6HvSdMziYLhrIrxxOqm5jnVIo cYiwhgTaNcTY4azeYRh7A3zlsqu9wNwH18EdlWltF+gvoHGjACUS0dRspnvjvTly5k5y ly4kFGY8+W6IzL7gVnrvNfoOSjLFAP/AZXhCsA4EwmL9eQ1lZMIqVV9keJuhCK7ezmws tIUg==
X-Gm-Message-State: APjAAAW2A82fkJtlv4gAvO7qXEdZvS7mNzcbjmErskLcpMWbCluaOeWW SFoDauhszJcYZr3apz4Z8oI=
X-Google-Smtp-Source: APXvYqzPvt4AHeYM9vNIQPOgxFmNm0xsgyuY9u5JQFXipoUP1cTmFqv/e26ac76ZLdbhIb1qFN35gA==
X-Received: by 2002:a2e:124c:: with SMTP id t73mr37477771lje.190.1561046453176; Thu, 20 Jun 2019 09:00:53 -0700 (PDT)
Received: from secretmaker-199.ip.peterstar.net (secretmaker-199.ip.PeterStar.net. [217.195.72.199]) by smtp.gmail.com with ESMTPSA id f16sm14761lfc.81.2019.06.20.09.00.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jun 2019 09:00:52 -0700 (PDT)
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Message-Id: <81DCFE10-1966-4DD0-B6A2-FC199D6478A6@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2225FEFC-9E59-4DED-8E7D-5C2DAC48FA1B"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 20 Jun 2019 19:00:51 +0300
In-Reply-To: <CAEh1p17W5V=VZHvHdxYEN8x1dYVXdKCTNuDyEuhDND0bNJEL0A@mail.gmail.com>
Cc: mpls@ietf.org
To: Ramakrishna Rao Desetti <ramakrishnadtv@gmail.com>
References: <CAEh1p17W5V=VZHvHdxYEN8x1dYVXdKCTNuDyEuhDND0bNJEL0A@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/0bEPOKaUX1R3Pc0QS-CfgWVL3AA>
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: Thu, 20 Jun 2019 16:00:58 -0000

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> написал(а):
> 
> 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
> https://www.ietf.org/mailman/listinfo/mpls

v2.23.0 | Report a Bug | By Email