Re: [mpls] The first nibble issue associated with MPLS encapsulation

Greg Mirsky <gregimirsky@gmail.com> Fri, 08 April 2016 23:05 UTC

Return-Path: <gregimirsky@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 D98A712D529; Fri, 8 Apr 2016 16:05:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 B37xZErWW8a7; Fri, 8 Apr 2016 16:05:52 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 9A79112D0E1; Fri, 8 Apr 2016 16:05:52 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id d68so151617701ywe.1; Fri, 08 Apr 2016 16:05:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=fsZNJKiA0lO0GEWzjNEjsbc5MqkiJCPPc9PvgOB60qQ=; b=ohn+JkbYMpr7NlfudKEVqxMGl0d4ygJvVFY+FilSI1E6W9etLXNYH0Nel0CP/q43H0 yZy/VXf9L2SCQ7/oQGHzJeizfv30qFK+iKDOqKcjxKGfLNl39esVnXVVidKJnUoHihf2 6BbqdStYgLm5fwZSRNeoPW11DHZgF90MxqExewOhOL46cuHBVGkMgEoIU6NJormJIS+2 vYLZr3z1pY5LvxXeOJKd77ukcH5jZEAPcR+4MXMUE8mzyc84e5R/jhX+rndsuow2LJgE CvzIsJt2zX5ftbmkpHVSyMqCG9FR+F6g2JoV3Jm8Yszs4r60+jP2S/Lg43Fgou3oyy7z SGOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fsZNJKiA0lO0GEWzjNEjsbc5MqkiJCPPc9PvgOB60qQ=; b=i75+oaNrOBmuRB6u+oiwbm/XOitpHF2YI7BQoqkjRnYBzO4YVhiE95K7ec4YeQFBK2 BiGdLflKykJOy7VGACnM/85CnoUsRorbnDsoR6xKqRbjvesRLAdSArXa5g5dSau9gf1a 4A+7hfBY0OnWvxFtxLGmB4BEzCL69pZeOtt42NNnVQHlcGnwuxKlJhQ9OhxPRiaS/uDC jJNYmqgCBzSvP/EkQ7Q/sYfoAPMcLLmoe9axrW9wZYBoV5mjTiE9wb0iLJ6n4gv6Zr7Z RPKmcZLVaxBrYk2oKA/EIOECod71yb966ftyQzpboAhmbOgxxmEMgF7QmhIisuJTtzVm tIHA==
X-Gm-Message-State: AD7BkJIl62grfIxr7YxqmS/jcKT/XrdETY1Mb7cMW5o95EUPOr20lmbg5rpg4dx5EnzQTN4oMUbipIackKXkIw==
MIME-Version: 1.0
X-Received: by 10.13.220.197 with SMTP id f188mr5650849ywe.172.1460156751807; Fri, 08 Apr 2016 16:05:51 -0700 (PDT)
Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 16:05:51 -0700 (PDT)
Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 16:05:51 -0700 (PDT)
In-Reply-To: <D32DB725.3F57B%cpignata@cisco.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <B664DB14-0A8C-4437-83E3-F9DA6C0DDA61@cisco.com> <mc51yrrf9n0wxbjsrprt9amf.1460143890063@email.android.com> <CA+RyBmXpZ-Kt77TW-=_kPYmahdw_yUHB5xhy8YtYVq2OcRJxbA@mail.gmail.com> <D32DB725.3F57B%cpignata@cisco.com>
Date: Fri, 08 Apr 2016 16:05:51 -0700
Message-ID: <CA+RyBmW+qonpScnLOfsGorayCvsS0vrFcn+o5nPvOqCOv9Jc3g@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Content-Type: multipart/alternative; boundary="94eb2c07bc90820b460530013ca7"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/SJC59uBDYKJFMlbCjR_eg85hWbw>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "bier@ietf.org" <bier@ietf.org>, sfc@ietf.org, "Dr. Tony Przygienda" <tonysietf@gmail.com>
Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulation
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
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, 08 Apr 2016 23:05:56 -0000

Hi Carlos,
thank you for the clarification. Should we think about establishing the
registry than?
Regards, Greg
On Apr 8, 2016 5:38 PM, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
wrote:

> Greg,
>
> My point, sorry if I was not clear, was that there is no such a thing as a
> ‘first nibble registry’.
>
> Instead, RFC 4928, Section 5, at
> https://tools.ietf.org/html/rfc4928#section-5, says:
>
>    IANA has marked the value 0x1 in the IP protocol version number space
>    as "Reserved" and placed a reference to this document to both values
>    0x0 and 0x1.
>
> And that is reflected as
> http://www.iana.org/assignments/version-numbers/version-numbers.xhtml#version-numbers-1
>
>
> The IANA text in 4928 is additionally followed by a disclaimer:
>
>    Note that this document does not in any way change the policies
>    regarding the allocation of version numbers, including the possible
>    use of the reserved numbers for some future purpose.
>
> Further, RFC 4385 does not specify the ‘first nibble’ as a field. Instead,
> it depicts the actual binary values for the different CW formats. In other
> words, it takes the values from the IP protocol version number and not as a
> new CW Field.
>
> Thanks,
>
> — Carlos.
>
> PS: Sasha, quick typo, s/1119/1190/;
>
> From: Greg Mirsky <gregimirsky@gmail.com>
> Date: Friday, April 8, 2016 at 7:28 PM
> To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> Cc: "sfc@ietf.org" <sfc@ietf.org>, "bier@ietf.org" <bier@ietf.org>, "Dr.
> Tony Przygienda" <tonysietf@gmail.com>, "mpls@ietf.org" <mpls@ietf.org>,
> Xiaohu Xu <xuxiaohu@huawei.com>, Carlos Pignataro <cpignata@cisco.com>
> Subject: Re: [mpls] The first nibble issue associated with MPLS
> encapsulation
>
> Hi Sasha,
> thank you for pointing to existing IANA allocation, though stale. I wonder
> if there is the registry for the first nibble. We, Tony and I, had
> discussed the way the first nibble space managed. If there already is the
> registry, could you please point me to it.
> Regards, Greg
> On Apr 8, 2016 2:31 PM, "Alexander Vainshtein" <
> Alexander.Vainshtein@ecitele.com> wrote:
>
>> Carlos and all,
>> Just for the reference, IANA has defined version 5 (0101) has assigned to ST protocol and refers to RFC 1119. The latter has been obsoleted by RFC 1819, but the IANA
>> assignment still holds.
>>
>> Is there, just in case, any relationship between BIER and ST?
>> Thumb typed on my cellphone
>> Regards,
>> Sasha
>>
>> -------- Original Message --------
>> From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
>> Date: Fri, April 08, 2016 9:25 PM +0300
>> To: Xiaohu Xu <xuxiaohu@huawei.com>
>> CC: mpls@ietf.org, bier@ietf.org, sfc@ietf.org, "Dr. Tony Przygienda" <tonysietf@gmail.com>
>> Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulation
>>
>>
>> Xiaohu, Tony,
>>
>> Please see inline.
>>
>> On Apr 7, 2016, at 2:39 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
>>
>> As for the first nibble issue, will it violate the layering principle of
>> network protocol stacks if the first nibble of any new encapsulation header
>> (which could be an MPLS payload) is used as the "MPLS payload type" field?
>>
>>
>> Reading draft-wang-bier-ethernet-01, Section 3, the “first nibble” is
>> _not_ used as an “MPLS payload type”. Instead, the text describes an
>> anti-aliasing mechanism, much like RFC 4928.
>>
>> The relevant text is:
>>      First nibble: The first 4 bits of the header are set to 0101; this
>>    ensures that the BIER header will not be confused with an IP header
>>    or with the header of a pseudowire packet.
>>
>> Which says “… will not be confused with …"
>>
>> wouldn't it  be more reasonable and sustainable to fix the problem (i.e.,
>> the lack of a protocol field in the MPLS header) by the MPLS header itself?
>>
>>
>>
>>
>> Who says it is a *problem*? There’s no “fixing” needed.
>>
>> By the way, since it's claimed that the NSH is transport-independant, it
>> means the NSH should be able to be transported over MPLS. However, it seems
>> that the first nibble issue has not be considered in the current NSH draft.
>> As a result, when encapsulating NSH over MPLS, the NSH may be
>> mis-interpreted as IP header.
>>
>>
>>
>>
>> There seems to be some massive confusion on this paragraph, on a number
>> of levels. First, NSH is not “claimed to be” transport-independent. It is
>> by charter and by design. Second, the NSH draft does not even include the
>> term “MPLS”, because it does not define transports. The SFC Encapsulation
>> can be used in a transport-agnostic way.
>>
>> One more comment below.
>>
>> Best regards,
>> Xiaohu
>>
>>
>> ------------------------------
>> *发件人:* BIER [bier-bounces@ietf.org] 代表 Tony Przygienda [
>> tonysietf@gmail.com]
>> *发送时间:* 2016年4月5日 22:36
>> *收件人:* bier@ietf.org
>> *主题:* [Bier] comments on draft-wang-bier-ethernet-01
>>
>> after reading
>>
>> a) first nibble: refer to MPLS encaps as "the same value" to keep in sync
>>
>>
>> One comment regarding the “First nibble” text
>> at draft-ietf-bier-mpls-encapsulation-03
>>
>> Since the function of the first nibble is to prevent aliasing with an IP
>> packet, in order for RFC 4928 to specify values of 0x0 and 0x1 for the
>> First Nibble, it had to “Reserve” IP protocol versions of 0 and 1,
>> referencing that RFC (see https://tools.ietf.org/html/rfc4928#section-5).
>>
>> Is the intent to re-assign IPv5 at
>> http://www.iana.org/assignments/version-numbers/ ?
>>
>> Note that RFC 4928 says “REQUIRED” at:
>>
>>    It is REQUIRED, however, that applications depend upon in-order
>>    packet delivery restrict the first nibble values to 0x0 and 0x1.
>>
>> Thanks,
>>
>> — Carlos.
>>
>>
>> b) refer to all other possible fields to MPLS encaps to keep in sync when
>> describing instead of repeating
>> c) you need to describe which kind of ether MACs are allowed, especially
>> on broadcast media, i.e. is it always p2p or can you take advantage of the
>> broadcast ?
>> d) Figure 4: use the architecture/MPLS encoding for the length, don't
>> invent a new one
>> e) who will obtain a new ether type from IEEE? As far I understand, not a
>> trivial process albeit we have several liaisons with IEEE
>>
>> --
>> *We’ve heard that a million monkeys at a million keyboards could produce
>> the complete works of Shakespeare; now, thanks to the Internet, we know
>> that is not true.*
>> —Robert Wilensky
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>>
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>>