Re: [mpls] Available IP version numbers.

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
>