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

Greg Mirsky <gregimirsky@gmail.com> Fri, 08 April 2016 22:28 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 B0F6112D6C1; Fri, 8 Apr 2016 15:28:11 -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 EflBJwUB4_29; Fri, 8 Apr 2016 15:28:09 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 DD88012D17A; Fri, 8 Apr 2016 15:28:08 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id o66so59690836ywc.3; Fri, 08 Apr 2016 15:28:07 -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=gxW+eFOid6SS3OoXP2shRdQuv2sGmLcDM3Gpf42Hqu0=; b=ZAPz/fH1Bs5G9my+27NdFFOcjnbxjTRlYtXsbP5nSFRECdrTzjGzQz9OoHXfu+S/gC 8YPE+C+rn20oQGFbui3wVXKYWy8cQ7i1JOIwErWYpj5aOZp0pACMfVmHMLikkNwI5We+ eMSf5mL2ITXg9852QWTiT1l0zmi9fvOieURvYxa5OtDBvx/tldV40oUrDsXXqLyhlzOs Op9kznwXtsrGDd+vmL1jbrCHCIpJTsfRBV79C3P1sfq05vetOsTNT/Hc/+tA5Fu/m4t9 EgguNYhoENS1X8UxMSTXtIq8CwELBfgEMnAOozqK89BJBvVpzj3+5FuEcxwpRJmNHXhL IPrQ==
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=gxW+eFOid6SS3OoXP2shRdQuv2sGmLcDM3Gpf42Hqu0=; b=NS2nvuu7ZS7jfM9sNbJZqjuv6I7dntbouhe7tTmqptFeWTSL9C6RndTO/CaKdjCQB+ XY+UvI2HFotQv2LWuLrKMFJfPldnyIOOGx15iCATmCcurqWLXcaneFusxyMnSMSq4Eze QfadMue+NEsi4GASRojeigD4OBanMTMpy4nGlBeKRA/8Kcz10Cfbmoo1ZUBF7L+ELQ1s Ta6iuwiLvEZX9OE3R5Nwk8lNRwTR2h0I0iQhzCAw+qKCe0ZoI8Of4tQf0ZLxksaCOU9b nZjQaBZWtwIvVPQQDkrel5liibvDyFXaGgBDZDUsWX/Y86c9jtWq1KF/7Y7ZVCAMbn6d qO2g==
X-Gm-Message-State: AD7BkJKCVo2VTVaaHv24WRtfXYtvkiFfcSkVCMuaSFe4G/6P9V1UskHOY9tV0lQEx7DcroKFvL2BJT2e0vgtRw==
MIME-Version: 1.0
X-Received: by 10.129.159.194 with SMTP id w185mr6163070ywg.297.1460154487311; Fri, 08 Apr 2016 15:28:07 -0700 (PDT)
Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 15:28:07 -0700 (PDT)
Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 15:28:07 -0700 (PDT)
In-Reply-To: <mc51yrrf9n0wxbjsrprt9amf.1460143890063@email.android.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <B664DB14-0A8C-4437-83E3-F9DA6C0DDA61@cisco.com> <mc51yrrf9n0wxbjsrprt9amf.1460143890063@email.android.com>
Date: Fri, 8 Apr 2016 15:28:07 -0700
Message-ID: <CA+RyBmXpZ-Kt77TW-=_kPYmahdw_yUHB5xhy8YtYVq2OcRJxbA@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Content-Type: multipart/alternative; boundary=94eb2c0c01268892a0053000b5b6
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/9uyN95kmtUqkjdnpyl6GE1E8vXg>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "bier@ietf.org" <bier@ietf.org>, "sfc@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 22:28:11 -0000

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