Re: [mpls] Available IP version numbers.

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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
>
>
>
> *From:* Uma Chunduri <[e-mail]>
> *Sent:* Monday, April 19, 2021 4:11 PM
> *To:* [e-mail]
> *Cc:* Greg Mirsky <[e-mail]>; mpls <[e-mail]>
> *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 <[e-mail]> 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
> <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 <[e-mail]>
> *Sent:* Monday, April 19, 2021 1:29 PM
> *To:* Greg Mirsky <[e-mail]>
> *Cc:* [e-mail]; mpls <[e-mail]>
> *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 <[e-mail]>
> 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 <[e-mail]> 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 <[e-mail]>
> Sent: Monday, April 19, 2021 12:04 PM
> To: [e-mail]; 'Loa Andersson' <[e-mail]>; 'mpls' <
> [e-mail]>
> 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, [e-mail] 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 <[e-mail]> On Behalf Of Loa Andersson
> > Sent: Saturday, April 17, 2021 1:13 AM
> > To: mpls <[e-mail]>
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
> >
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
> >
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>
>