Re: [mpls] Available IP version numbers.
Uma Chunduri <umac.ietf@gmail.com> Mon, 19 April 2021 20:29 UTC
Return-Path: <umac.ietf@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 6973E3A42C4 for <mpls@ietfa.amsl.com>; Mon, 19 Apr 2021 13:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.196
X-Spam-Level:
X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 68SJGG1gL2yg for <mpls@ietfa.amsl.com>; Mon, 19 Apr 2021 13:29:29 -0700 (PDT)
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 944B03A42C1 for <mpls@ietf.org>; Mon, 19 Apr 2021 13:29:29 -0700 (PDT)
Received: by mail-yb1-xb29.google.com with SMTP id 82so40357892yby.7 for <mpls@ietf.org>; Mon, 19 Apr 2021 13:29:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5StrgInt7ggJ//e+ukWbTRJZlIO7X0tcV4AQTYonEYE=; b=KKTTOYsWbhJ74Rptn8aTieDhYK+ASaFTrBEDx9UKwJP9ppj8PGKZkvf5ItAQxw3ZpH HZE7ZKvH4D7p/knDWdbJdV0nIXVFjI/GMM5raxhVe2WOFNOJFv0U2CYmM9Fcvy2ivFZd QNb1gmQskoZfVXhiNCxKAlwnxfR1D+i7qYLZjsVBqAoa7RTyEst5gnkbzCYfNax6qd6E 2Wgnb0xes2K/kGloG0BhmfrRzsv/nK8j7zknIH3BLxnyagBnpQ0Oc10stRj9fVwGrrAY BI35jjL25jFXULp9Gf/no15VTUJ/5Wg0V9p+WmcaG3QZodqJxNqrz4Aa2fdcdN9bvojO lFKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5StrgInt7ggJ//e+ukWbTRJZlIO7X0tcV4AQTYonEYE=; b=ogP4LejBT1VpQbBHW7hQiXg6XEIMM3qCgNxtTKfwBcpDUB1nkMLhw/I0iY7R0Wj7kl 8jFO9FjdgzWzTsiFc5039u75C5klOVA/PFy2d0YpdXV6xkzsCIEz/qfYZQQyAm3UPnw9 oSUXadJdm2A8TE9h1vfwsAwN/hZanzPTcc14gjcOTAko8C59/4gm92MpWZNMmziCUpNQ 02+kMqDP6tPgPenFcSfddQwLkgTHus2kxDxJqQjDzi8rOTx/RHTxLG/ZvBWB6GkFY7tJ vvvfWABsiOMUvSwJypJ1Ezeb/OHAk2jqJOV8GVC0yHLcVgs1p1eqzYlKnJ4yj1aDmBjL TTBg==
X-Gm-Message-State: AOAM530JfD08Mzv8FS+SdAqKCJT77mYwdiAEhsNBMrkuiWIEk7q2hxkO JGOwS4BJFJV7zNEXJPHpnat7LQVDBWU1KJ29MUg=
X-Google-Smtp-Source: ABdhPJyNiOkzgTaq+DWrB7srmGJgHSzggva/M37xO13IkDU8gruxV9wTLlh94qY2llE1GkuHSf5apJDkLqPGmjd5z2A=
X-Received: by 2002:a25:4946:: with SMTP id w67mr19959393yba.141.1618864168225; Mon, 19 Apr 2021 13:29:28 -0700 (PDT)
MIME-Version: 1.0
References: <A5C8DFA9-3601-4838-9461-727CC40507B1@gmail.com> <003701d7354d$4810e660$d832b320$@sergey.dev> <36cdf547-47b0-09f2-c168-588477f7af1c@joelhalpern.com> <001b01d73551$47ba6520$d72f2f60$@sergey.dev> <CA+RyBmXsWqNtiLrK2scjjQUKC5j0MHi=OqHmaPi4O8DBAaoKQg@mail.gmail.com>
In-Reply-To: <CA+RyBmXsWqNtiLrK2scjjQUKC5j0MHi=OqHmaPi4O8DBAaoKQg@mail.gmail.com>
From: Uma Chunduri <umac.ietf@gmail.com>
Date: Mon, 19 Apr 2021 13:29:17 -0700
Message-ID: <CAF18ct5NcrdBDvfGa=4mLjjFPZu=d56nq8bfHWKfnEepCjyORQ@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: ietf@sergey.dev, mpls <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000afcd8005c0592f12"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/fQ1hk0dH2eMeeZbjwECtpp9lkuY>
Subject: Re: [mpls] Available IP version numbers.
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: Mon, 19 Apr 2021 20:29:34 -0000
Hi Greg, +1 2 Broad categories here: a. If we are seeking to have a new ether type - we don't have to worry about the backward compatibility (while yes, we may seek to maintain some aspects same for reusability purposes) as upgrade is needed to process the packet header (labels + BoS stuff) with new ether type. b. If the same ether type of current MPLS is sought, this is a critical piece for not impacting the existing functionality for the not upgraded nodes. Again 2 cases here (i) If the underlying circuit is IP based - then the discussion here is completely valid and first nibble value has to be different and non-conflicting (ii) For non-IP circuits an existing LSR will obviously not interpret/assume it's IPv4/IPv6 packet underneath (and not use the header fields for ECMP). So it's critical to care for b (i) as has been discussed or being discussed for backward compatibility on this aspect.. Thx! -- Uma C. On Mon, Apr 19, 2021 at 12:51 PM Greg Mirsky <gregimirsky@gmail.com> wrote: > Hi Sergey, > I think that when we are looking at how systems interpret MPLS payload, as > I understand it, we have two scenarios - MPLS LSP and MPLS PW. In the > former, an IP packet is a native payload. Thus the BoS label element (LE) > is followed by an IPv4 or IPv6 packet is valid. Also, it could be G-ACh or > BIER, respectively identified by 0x01 and 0x05 in the first nibble. An > encapsulation other than IP uses MPLS PW encapsulation. And the BoS LE is > followed by PW CW or ACH. Note that RFC 8469 > <https://tools.ietf.org/html/rfc8469> RECOMMENDS using PW CW for Ethernet > PWs to avoid possible misinterpretation of the payload. > That all might not be "a standard-defined paradigm", but a de facto > standard on the wire. And, in my opinion, we must consider that to ensure > the backward compatibility of any change we may introduce. > > Regards, > Greg > > On Mon, Apr 19, 2021 at 12:22 PM <ietf@sergey.dev> wrote: > >> Joel, >> I agree with that. >> >> But my point it - it seems there's an implicit assumption that IP header >> follows an MPLS label stack, which may or may not be the case. First nibble >> is not a protocol identifier in a classical sense (except for >> LSR-guessing). >> We can't rely on a nibble as a unique identifier by itself; so is there >> even a point in using anything besides 0x0 (to avoid LSR-guessing)? There >> might be, but it is not obvious in a current form of just taking a new >> number. >> And if we were to use a new number - it is not an IP version number (as >> long as we are not claiming that an IP header follows. Yes, 0x0 and 0x1 >> were reserved by IANA for rfc4928 usecase, but this is not, strictly >> speaking, a standard-defined paradigm). >> >> -- >> Sergey >> >> -----Original Message----- >> From: Joel M. Halpern <jmh@joelhalpern.com> >> Sent: Monday, April 19, 2021 12:04 PM >> To: ietf@sergey.dev; 'Loa Andersson' <loa.pi.nu@gmail.com>; 'mpls' < >> mpls@ietf.org> >> Subject: Re: [mpls] Available IP version numbers. >> >> If we are defining a protocol carried with its own ethertype (e.g. >> MPLS), there is no neeed for an IP version differentiation. >> >> It can in fact be argued that IPv6 could have used a different header >> format, and assumed that the media woudl indicate the new protocol. >> However, because we knew that it needed to interwork with, be mixed with, >> and be diagnosed with existing IPv4 packets it was far more robust to build >> the packet format in such a way that it was reliably distinguishable from >> IPv4. Which means a different starting nibble. >> >> We could have skipped it. (Historically, we got there the other way. >> We started by thinking we would use the same ethertype for both. And >> then also realized that had problems. So we have a belt and suspenders; >> dual identification. Which is often a good design paradigm.) >> >> Yours, >> Joel >> >> PS: In the MPLS context the is further complicated by devices which look >> at the data after the end of the stack and try to guess what it is. >> Typically to support ECMP / LAG. >> >> On 4/19/2021 2:53 PM, ietf@sergey.dev wrote: >> > Hi Loa, >> > In an adjacent thread ("mpls open dt & the first nibble discussion") I >> raised a question about why do we even expect to take something from IP >> numbering. Would appreciate your feedback on this one. >> > >> > >> > -----Original Message----- >> > From: mpls <mpls-bounces@ietf.org> On Behalf Of Loa Andersson >> > Sent: Saturday, April 17, 2021 1:13 AM >> > To: mpls <mpls@ietf.org> >> > Subject: [mpls] Available IP version numbers. >> > >> > DT, >> > >> > We had a discussion on how many IP version numbers are available. >> > >> > It should be remembered that in IANA “Reserved” really means “Reserved, >> do not assign”. >> > >> > 0,1,5,7,8,9 and 15 are reserved. >> > 2,3,10,11,12,13 and 14 are unassigned >> > 4 and 6 are assigned >> > >> > To make the reserved requires a standard track RFC. >> > >> > So we 7 IP version numbers available, that is a sufficient low number >> to make me nervous, if I owned the registry. >> > >> > I would nit count on having more IP version numbers assigned to “us”, >> especially since we already have an agreement (PWE3), accepting to get two >> numbers and committing to not use more. >> > >> > /Loa >> > >> > Sent from my iPhone >> > _______________________________________________ >> > 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 >> > >> >> _______________________________________________ >> 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 >
- [mpls] Available IP version numbers. Loa Andersson
- Re: [mpls] Available IP version numbers. Toerless Eckert
- Re: [mpls] Available IP version numbers. Haoyu Song
- Re: [mpls] Available IP version numbers. ietf
- Re: [mpls] Available IP version numbers. Joel M. Halpern
- Re: [mpls] Available IP version numbers. ietf
- Re: [mpls] Available IP version numbers. Greg Mirsky
- Re: [mpls] Available IP version numbers. Andrew G. Malis
- Re: [mpls] Available IP version numbers. Uma Chunduri
- Re: [mpls] Available IP version numbers. Uma Chunduri
- Re: [mpls] Available IP version numbers. Andrew G. Malis
- Re: [mpls] Available IP version numbers. Uma Chunduri
- Re: [mpls] Available IP version numbers. Toerless Eckert
- Re: [mpls] Available IP version numbers. ietf
- Re: [mpls] Available IP version numbers. Haoyu Song
- Re: [mpls] Available IP version numbers. Toerless Eckert
- Re: [mpls] Available IP version numbers. Uma Chunduri
- Re: [mpls] Available IP version numbers. ietf
- Re: [mpls] Available IP version numbers. Greg Mirsky
- Re: [mpls] Available IP version numbers. ietf
- Re: [mpls] Available IP version numbers. Stewart Bryant
- Re: [mpls] Available IP version numbers. Kireeti Kompella