Re: [mpls] Available IP version numbers.

Uma Chunduri <umac.ietf@gmail.com> Mon, 19 April 2021 22:18 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 851D33A4724 for <mpls@ietfa.amsl.com>; Mon, 19 Apr 2021 15:18:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 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_NONE=-0.0001, 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 qwxSRq2c0taJ for <mpls@ietfa.amsl.com>; Mon, 19 Apr 2021 15:18:45 -0700 (PDT)
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 B1DB63A46E5 for <mpls@ietf.org>; Mon, 19 Apr 2021 15:18:39 -0700 (PDT)
Received: by mail-yb1-xb30.google.com with SMTP id 82so40677539yby.7 for <mpls@ietf.org>; Mon, 19 Apr 2021 15:18:39 -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=Pk/7pSJv1c8bN9aeYNZ3IdS0h0F9vWZSjDaPYj99QpY=; b=VPJ6502T+UqkOUZPzZWfUG8W8CE1APDh/so+bmW6wwULAw/63ajBIOBcP+9TfGVhkX 0bTdvuJt4R3r2s5uz8NTuu0Rj2NFOyDJ5IIzYTvSPHsjVA2fY24BH61r1rmOr9ljnHeR L4rw0upI9ziEm+P64oy11OP+262D9LEXETaI7lG1ELBZpGv3yrOOx2sp4FttRvBwaEX2 0hwargQQQZooC215h0U+cAV3Lp7H5VmneI0Lnpl2nuGQeEMdYRF2S+Io8UtGvH53n7Hp cMUsvciv4+pPQTsGtxpMdPHOMgZitTTGzH/b0VYw2bhmvBwn4zrWS3wIxcYuTflfJgb7 ar2w==
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=Pk/7pSJv1c8bN9aeYNZ3IdS0h0F9vWZSjDaPYj99QpY=; b=BEanL5kUI34Qu/8H3xiTUlY0Wm4CI00A8BocGVcPB/vqN6OOi2XWqHP/Fuy3D0Pkv1 Q/i/XApRwNfeze9zdpc0I+yYVBNxcPV9ioJkRTDB/iWQTi213g05QNa+WjUboaCOpBB2 nRtGzF/DOA2N0PNBGKrzL19I+d9l9ylsiDpLd/BOE3VemPBQxUB8dh+WxbM+m9ftkzDQ 4z2nQ251mQ8X+J6OuaU0hJ/8olvgJh48dHXuHkvII5raEOy5zJmPG5Mw9Yj1jh0MsKFm /j0RFAvjZ2K4CZTiUf48VX/vPQZIGu8uiOamDROLXcMgLdZDQUru/QGb2Or6uuN25Auk xo0A==
X-Gm-Message-State: AOAM532WAysws+6tQT2WfO9UuUWN2mM+vsZ3nYLTwaIhIYek0KrIDF+1 iriqt6zB8AbVYPZxAvFoSwR3NcD0TV3w7Pof0zg=
X-Google-Smtp-Source: ABdhPJyT5TDDJ7J9IItqeItK+4iA9wz3QmSXH/jmcx9T/pH7W/kr2BebCBkhRdKJ9t0Tf6Mb+A+kWqxA6ETcZLb8xdc=
X-Received: by 2002:a25:38cf:: with SMTP id f198mr19843205yba.21.1618870717757; Mon, 19 Apr 2021 15:18:37 -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> <CAF18ct5NcrdBDvfGa=4mLjjFPZu=d56nq8bfHWKfnEepCjyORQ@mail.gmail.com> <CAA=duU2aZzowBCtsgXQHYmx3X=kM-e_LBZBQ7C319QQcm9DEPA@mail.gmail.com>
In-Reply-To: <CAA=duU2aZzowBCtsgXQHYmx3X=kM-e_LBZBQ7C319QQcm9DEPA@mail.gmail.com>
From: Uma Chunduri <umac.ietf@gmail.com>
Date: Mon, 19 Apr 2021 15:18:26 -0700
Message-ID: <CAF18ct4EC0dYpXjTXt4PMECh+8xwSWniqkg6VAe7prUBEOEQJQ@mail.gmail.com>
To: "Andrew G. Malis" <agmalis@gmail.com>
Cc: Greg Mirsky <gregimirsky@gmail.com>, mpls <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000011c29805c05ab67d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/m_1DVu8XqtdI7DaKRAWsD5LLruk>
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 22:18:51 -0000

Hi Andy,

I was for a moment thinking in the "ideal" world and hence thought of
non-IP circuits mentioned above is sufficient (at least this was how it
worked with the nodes on the vendor I worked in my past life). Thanks for
pointing to 8469 and the NANOG 2016 discussions on how wild things can be
with different versions of HW (with same vendors) or different vendors. But
I "still" failed to understand frankly, why an LSR for a L2 circuit  (no IP
provisioned at all) is thinking IPv4 and IPv6 by just seeing the 4 or 6 in
the first nibble (tell me cases/scenarios something other than buggy code
cases).

Yes, sure avoid 4 or 6 at all costs (wildy in agreement)  or as being
discussed get another code point other than 0,1,4,5,6 (as 8469 recommends
CWs as a recommended way for the original problem with 4 and 6).

Cheers!
--
Uma C.



On Mon, Apr 19, 2021 at 2:07 PM Andrew G. Malis <agmalis@gmail.com> wrote:

> Uma,
>
> > (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)
>
> This can only be true of LERs that have access to the LIB entry for the
> BoS label. An LSR in the middle of the network has no idea whether an MPLS
> packet carries IP or not. Unfortunately, too many always make the
> assumption that it's IP, and that's where we get into the ECMP issues
> discussed in RFCs 4928 and 8469.
>
> Cheers,
> Andy
>
>
> On Mon, Apr 19, 2021 at 4:29 PM Uma Chunduri <umac.ietf@gmail.com> wrote:
>
>> 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 mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>