Subject: [mpls] Available IP version numbers.

From: Loa Andersson <[email-masked]>
Date: Sat, 17 Apr 2021 16:13:23 +0800

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

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 17 Apr 2021 22:46:16 +0200

a) Any more insight into the reserved numbers ?
   If there are failed experiments (i think there might have been ?)
   That would be good to review to avoid similar errors.

b) I would not be concerned about exhaustion if we come up with one proposal
   that gives us good confidence of extensibility. 

c) Any backward compatibility reason for us not being able to use 8
   bits - out of which the first 4 bits of course can only use unassigned
   values.

Cheers
    Toerless

On Sat, Apr 17, 2021 at 04:13:23PM +0800, Loa Andersson wrote:
> It should be remembered that in IANA ???Reserved??? really means ???Reserved, do not assign???. 
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

-- 
---
[email-masked]

---

From: Haoyu Song <[email-masked]>
Date: Mon, 19 Apr 2021 16:29:13 +0000

I'm not so worried about the IP version exhaustion. We can always use the similar method as that used by MPLS to extend the SPLs. What I'm thinking is that in the future, perhaps in addition to the major version number, we should also have minor version numbers to allow gradual evolution of the protocol.

Haoyu

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Toerless Eckert
Sent: Saturday, April 17, 2021 1:46 PM
To: Loa Andersson <[email-masked]>
Cc: mpls <[email-masked]>
Subject: Re: [mpls] Available IP version numbers.

Cheers
    Toerless

On Sat, Apr 17, 2021 at 04:13:23PM +0800, Loa Andersson wrote:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C1e732284720e4630763c08d901e1e889%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637542892072705560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=uMoSsS982ZFrXqVKD64enAcIFXlsBjIBoZDGJxXlN3s%3D&amp;reserved=0

-- 
---
[email-masked]

_______________________________________________
mpls mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C1e732284720e4630763c08d901e1e889%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637542892072705560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=uMoSsS982ZFrXqVKD64enAcIFXlsBjIBoZDGJxXlN3s%3D&amp;reserved=0

---

From: <[email-masked]>
Date: Mon, 19 Apr 2021 11:53:23 -0700

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 <[email-masked]> On Behalf Of Loa Andersson
Sent: Saturday, April 17, 2021 1:13 AM
To: mpls <[email-masked]>
Subject: [mpls] Available IP version numbers.

DT,

/Loa

Sent from my iPhone

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 19 Apr 2021 15:04:02 -0400

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.

---

From: <[email-masked]>
Date: Mon, 19 Apr 2021 12:22:00 -0700

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 <[email-masked]> 
Sent: Monday, April 19, 2021 12:04 PM
To: [email-masked]; 'Loa Andersson' <[email-masked]>; 'mpls' <[email-masked]>
Subject: Re: [mpls] Available IP version numbers.

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.

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 19 Apr 2021 12:50:57 -0700

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 <[email-masked]> 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
>
> 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 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
>
> > 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.
> >
> >
> > 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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 19 Apr 2021 16:21:26 -0400

Also note that when 00 is the first nibble following the MPLS label stack,
the control plane is used to install a LIB entry for the BoS label that
identifies the payload, using either LDP for PWs and VPLS, or BGP for EVPN.
The payload cannot be distinguished by the packet data contents following
the 00 nibble, and in fact the payload format varies depending on the PW
type.

Cheers,
Andy

On Mon, Apr 19, 2021 at 3:51 PM Greg Mirsky <[email-masked]> wrote:

>> > So we 7 IP version numbers available, that is a sufficient low number
>> to make me nervous, if I owned the registry.
>> >

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 19 Apr 2021 13:27:23 -0700

>MPLS), there is no neeed for an IP version differentiation

As you quoted the "e.g.", it's absolutely needed to differentiate the IP
version number. Agree with the rest of your message.

Cheers!
--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 19 Apr 2021 13:29:17 -0700

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.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 19 Apr 2021 17:07:28 -0400

Uma,

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 <[email-masked]> wrote:

>     (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
> 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.
>
>
>
>> 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
>> <https://tools.ietf.org/html/rfc8469> RECOMMENDS using PW CW for
>> Ethernet PWs to avoid possible misinterpretation of the payload.
>>> 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.
>>>

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 19 Apr 2021 15:18:26 -0700

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 <[email-masked]> wrote:

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

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 20 Apr 2021 00:31:53 +0200

On Mon, Apr 19, 2021 at 04:29:13PM +0000, Haoyu Song wrote:
> I'm not so worried about the IP version exhaustion. We can always use the similar method as that used by MPLS to extend the SPLs.

Could be IMHO more efficient encoded than it was possible in MPLS.
First four bits = IPv10(10), nex four bits reserved for extension versions.

> What I'm thinking is that in the future, perhaps in addition to the major version number, we should also have minor version numbers to allow gradual evolution of the protocol.

What do you think is the most likely reason for requiring a mayor and/or minor version number ?
I can't come up wih a good example.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: <[email-masked]>
Date: Mon, 19 Apr 2021 15:35:40 -0700

Hi Greg, Uma,

Greg,

>Also, it could be G-ACh or BIER, respectively identified by 0x01 and 0x05 in the first nibble. 

Not quite. 

Identification by the first nibble is always a _guess_. LER always identifies payload by a label/FEC mapping (with further verifications of packet header from other protocol layers).  LSR can try to guess what’s inside by using the nibble. Nothing is guaranteed in this case.

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

An encapsulation other than IP might use, well, just about anything (just as your BIER example above).

If we want to stick to practical examples, CW is often not present (due to absence of L3-L4 ECMP LSR load-balancing in the core, or presence of entropy labels as an example). So immediately after BoS you encounter an Ethernet header (where the first nibble can be just about anything).

Uma,

> So it's critical to care for b (i) as has been discussed or being discussed for backward compatibility on this aspect..

0x0 fits the scenario, if nothing else is needed from this?

--

Sergey

From: Uma Chunduri <[email-masked]> 
Sent: Monday, April 19, 2021 1:29 PM
To: Greg Mirsky <[email-masked]>
Cc: [email-masked]; mpls <[email-masked]>
Subject: 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 <[email-masked] <mailto:[email-masked]> > 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 <[email-masked] <mailto:[email-masked]> > wrote:

Joel,
I agree with that.

--
Sergey

-----Original Message-----
From: Joel M. Halpern <[email-masked] <mailto:[email-masked]> > 
Sent: Monday, April 19, 2021 12:04 PM
To: [email-masked] <mailto:[email-masked]> ; 'Loa Andersson' <[email-masked] <mailto:[email-masked]> >; 'mpls' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [mpls] Available IP version numbers.

Yours,
Joel

On 4/19/2021 2:53 PM, [email-masked] <mailto:[email-masked]>  wrote:
> From: mpls <[email-masked] <mailto:[email-masked]> > On Behalf Of Loa Andersson
> To: mpls <[email-masked] <mailto:[email-masked]> >
> [email-masked] <mailto:[email-masked]> 
> [email-masked] <mailto:[email-masked]> 

_______________________________________________
mpls mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/mpls

---

From: Haoyu Song <[email-masked]>
Date: Mon, 19 Apr 2021 22:44:07 +0000

-----Original Message-----
From: Toerless Eckert <[email-masked]> 
Sent: Monday, April 19, 2021 3:32 PM
To: Haoyu Song <[email-masked]>
Cc: Loa Andersson <[email-masked]>; mpls <[email-masked]>
Subject: Re: [mpls] Available IP version numbers.

[HS] This is what I mean. When you run out of special values, you just use a special value to indicate that after it is the new and extended field of special values. 

[HS] With this, we can support minor innovations in a major version without needing a new version number each time, or to support experimental and incremental updates to the current version, which do not deserve a new version number.

Cheers
    Toerless

> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Cfc508945276249efb19208d90382f24a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637544683222529634%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=7gCU2UmwIIjiddMdI6LCNG8%2FfsjlIUK%2FM4UulOpDbJQ%3D&amp;reserved=0
> 
> -- 
> ---
> [email-masked]
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Cfc508945276249efb19208d90382f24a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637544683222539628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=HSSHpA6o9bbtEe0zj0dhjHCANpGt%2BD7olU8pMdT1ZOA%3D&amp;reserved=0

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 20 Apr 2021 01:02:22 +0200

> [HS] With this, we can support minor innovations in a major version without needing a new version number each time, or to support experimental and incremental updates to the current version, which…

The whole point IMHO of our next protocol is to have very easy incremental
extensibility withou the need of versioning. IMHO!

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 19 Apr 2021 16:11:00 -0700

Hi Sergey,

>Identification by the first nibble is always a _*guess*_. LER always
identifies payload by a label/FEC
>mapping (with further verifications of packet header from other protocol
layers).  LSR can try to guess
>what’s inside by using the nibble. Nothing is guaranteed in this case.

Your assessment is correct. Then this amounts to getting a new ethernet
code point; frankly to be "more"  foolproof. This may be well worth it, for
many functionalities envisioned (by many folks as documented by Stewart) in
the BoS engineering.

>0x0 fits the scenario, if nothing else is needed from this?

You need to deal with all the warts that come along with this technically
"unknown" value apart from dealing with many existing deployments on how
this is being used to process the rest of the stuff. But the
proposal/functionalities sought are much more invasive and it may need more
than 0x0 first nibble + may be a bSPL.

Cheers!
--
Uma C.

On Mon, Apr 19, 2021 at 3:35 PM <[email-masked]> wrote:

> Hi Greg, Uma,
>
>
>
> Greg,
>
> *>Also, it could be G-ACh or BIER, respectively identified by 0x01 and
> 0x05 in the first nibble. *
>
> Not quite.
>
> Identification by the first nibble is always a _*guess*_. LER always
> identifies payload by a label/FEC mapping (with further verifications of
> packet header from other protocol layers).  LSR can try to guess what’s
> inside by using the nibble. Nothing is guaranteed in this case.
>
>
>
> *> An encapsulation other than IP uses MPLS PW encapsulation. And the BoS
> LE is followed by PW CW or ACH. Note that RFC 8469
> PWs to avoid possible misinterpretation of the payload.*
>
> If we want to stick to practical examples, CW is often not present (due to
> absence of L3-L4 ECMP LSR load-balancing in the core, or presence of
> entropy labels as an example). So immediately after BoS you encounter an
> Ethernet header (where the first nibble can be just about anything).
>
>
>
> Uma,
>
> *> So it's critical to care for b (i) as has been discussed or being
> discussed for backward compatibility on this aspect..*
>
> *From:* Uma Chunduri <[email-masked]>
> *Sent:* Monday, April 19, 2021 1:29 PM
> *To:* Greg Mirsky <[email-masked]>
> *Cc:* [email-masked]; mpls <[email-masked]>
> *Subject:* Re: [mpls] Available IP version numbers.
>
>
>
> Hi Greg,
>
>
>
> +1
>
>
>
> 2 Broad categories here:
>
>
>

---

From: <[email-masked]>
Date: Mon, 19 Apr 2021 16:39:57 -0700

Hi Uma,

> This may be well worth it, for many functionalities envisioned (by many folks as documented by Stewart) in the BoS engineering.

Agree

> But the proposal/functionalities sought are much more invasive and it may need more than 0x0 first nibble + may be a bSPL.

Agree as well. 

I’m not against using a new nibble value; all I’m saying is that there’s been a lot of focus on discussing whether we can get it and how it is allocated (there’s a presumption of IANA allocation from IP versions space, which I doubt); but so far it is not clear whether we need it in the first place, and what exactly it is supposed to solve.

Thus my proposal would be to return to a more general discussion first, and, probably, we should start with objectives & requirements before we dig into the details.

Thank you,

--

Sergey

From: Uma Chunduri <[email-masked]> 
Sent: Monday, April 19, 2021 4:11 PM
To: [email-masked]
Cc: Greg Mirsky <[email-masked]>; mpls <[email-masked]>
Subject: Re: [mpls] Available IP version numbers.

Hi Sergey,

>Identification by the first nibble is always a _guess_. LER always identifies payload by a label/FEC 

>mapping (with further verifications of packet header from other protocol layers).  LSR can try to guess 

>what’s inside by using the nibble. Nothing is guaranteed in this case.

Your assessment is correct. Then this amounts to getting a new ethernet code point; frankly to be "more"  foolproof. This may be well worth it, for many functionalities envisioned (by many folks as documented by Stewart) in the BoS engineering.

>0x0 fits the scenario, if nothing else is needed from this?

You need to deal with all the warts that come along with this technically "unknown" value apart from dealing with many existing deployments on how this is being used to process the rest of the stuff. But the proposal/functionalities sought are much more invasive and it may need more than 0x0 first nibble + may be a bSPL.

Cheers!
--

Uma C.

On Mon, Apr 19, 2021 at 3:35 PM <[email-masked] <mailto:[email-masked]> > wrote:

Hi Greg, Uma,

Greg,

Not quite. 

Uma,

--

Sergey

From: Uma Chunduri <[email-masked] <mailto:[email-masked]> > 
Sent: Monday, April 19, 2021 1:29 PM
To: Greg Mirsky <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; mpls <[email-masked] <mailto:[email-masked]> >
Subject: Re: [mpls] Available IP version numbers.

Hi Greg,

+1

2 Broad categories here:

Thx!

--

Uma C.

Hi Sergey,

Regards,

Greg

Joel,
I agree with that.

--
Sergey

-----Original Message-----
From: Joel M. Halpern <[email-masked] <mailto:[email-masked]> > 
Sent: Monday, April 19, 2021 12:04 PM
To: [email-masked] <mailto:[email-masked]> ; 'Loa Andersson' <[email-masked] <mailto:[email-masked]> >; 'mpls' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [mpls] Available IP version numbers.

Yours,
Joel

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 19 Apr 2021 17:45:53 -0700

Hi Sergey,
thank you for a very interesting discussion. Please find a note inlined
under the GIM>> tag.

Regards,
Greg

On Mon, Apr 19, 2021 at 4:40 PM <[email-masked]> wrote:

> Hi Uma,
>
> > This may be well worth it, for many functionalities envisioned (by many
> folks as documented by Stewart) in the BoS engineering.
>
> Agree
>
>
>
> > But the proposal/functionalities sought are much more invasive and it
> may need more than 0x0 first nibble + may be a bSPL.
>
> Agree as well.
>
> I’m not against using a new nibble value; all I’m saying is that there’s
> been a lot of focus on discussing whether we can get it and how it is
> allocated (there’s a presumption of IANA allocation from IP versions space,
> which I doubt); but so far it is not clear whether we need it in the first
> place, and what exactly it is supposed to solve.
>
GIM>> AFAIK, there's no IANA registry for the first nibble of a payload
after the BoS LE. Each protocol defines a new value of the first nibble
with consideration of what other protocols use. For BIER in an MPLS network
Section 2.1.2 RFC 8296 defines the value of the Nibble field as 0b0101
(also providing a very good explanation of why that particular value was
selected). For a non-MPLS network Section 2.2.2 states that the
filed SHOULD be zeroed on transmission and ignored on receipt.

>
>
> Thus my proposal would be to return to a more general discussion first,
> and, probably, we should start with objectives & requirements before we dig
> into the details.
>
>
>
> Thank you,
>
> --
>
> Sergey
>
>
>
> *Sent:* Monday, April 19, 2021 4:11 PM
> *To:* [email-masked]
> *Cc:* Greg Mirsky <[email-masked]>; mpls <[email-masked]>

---

From: <[email-masked]>
Date: Mon, 19 Apr 2021 18:12:54 -0700

Thank you Greg,

I agree 100%.

--

Sergey

From: Greg Mirsky <[email-masked]> 
Sent: Monday, April 19, 2021 5:46 PM
To: [email-masked]
Cc: Uma Chunduri <[email-masked]>; mpls <[email-masked]>
Subject: Re: [mpls] Available IP version numbers.

Hi Sergey,

thank you for a very interesting discussion. Please find a note inlined under the GIM>> tag.

Regards,

Greg

On Mon, Apr 19, 2021 at 4:40 PM <[email-masked] <mailto:[email-masked]> > wrote:

Hi Uma,

Agree

Agree as well. 

GIM>> AFAIK, there's no IANA registry for the first nibble of a payload after the BoS LE. Each protocol defines a new value of the first nibble with consideration of what other protocols use. For BIER in an MPLS network Section 2.1.2 RFC 8296 defines the value of the Nibble field as 0b0101 (also providing a very good explanation of why that particular value was selected). For a non-MPLS network Section 2.2.2 states that the filed SHOULD be zeroed on transmission and ignored on receipt.

Thank you,

--

Sergey

From: Uma Chunduri <[email-masked] <mailto:[email-masked]> > 
Sent: Monday, April 19, 2021 4:11 PM
To: [email-masked] <mailto:[email-masked]> 
Cc: Greg Mirsky <[email-masked] <mailto:[email-masked]> >; mpls <[email-masked] <mailto:[email-masked]> >
Subject: Re: [mpls] Available IP version numbers.

Hi Sergey,

Cheers!
--

Uma C.

Hi Greg, Uma,

Greg,

Not quite. 

> An encapsulation other than IP uses MPLS PW encapsulation. And the BoS LE is followed by PW CW or ACH. Note that  <https://tools.ietf.org/html/rfc8469> RFC 8469 RECOMMENDS using PW CW for Ethernet PWs to avoid possible misinterpretation of the payload.

Uma,

--

Sergey

Hi Greg,

+1

2 Broad categories here:

Thx!

--

Uma C.

Hi Sergey,

Regards,

Greg

Joel,
I agree with that.

--
Sergey

-----Original Message-----
From: Joel M. Halpern <[email-masked] <mailto:[email-masked]> > 
Sent: Monday, April 19, 2021 12:04 PM
To: [email-masked] <mailto:[email-masked]> ; 'Loa Andersson' <[email-masked] <mailto:[email-masked]> >; 'mpls' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [mpls] Available IP version numbers.

Yours,
Joel

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 20 Apr 2021 15:28:13 +0100

I agree.

This is about pragmatically addressing an architecture violation that goes back many years.

In many ways this is a good example an architectural breach which seems to be a quick pragmatic fix by the implementers causing years of future pain.

- Stewart

> On 19 Apr 2021, at 20:22, [email-masked] wrote:
> 
> Joel,
> I agree with that.
>