Subject: [mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 24 Dec 2020 12:44:32 -0500

I've been asked to provide a pre-adoption MPLS-RT review of
draft-gandhi-mpls-ioam-sr-04.

I have a major concern that I believe needs to be addressed, either before
or after WG adoption (I defer to the WG chairs to make this decision). My
personal preference is that it be addressed by the authors prior to
adoption, but if it occurs following adoption, I would like to see it
addressed before it gets much further in the WG process.

My concern is as follows:

In Section 6 and Figure 1, 0x0010b (2 decimal) is used for the first nibble
following the MPLS label stack in order to avoid ECMP. This intent is fine,
but there is an issue with choosing this particular value. The first nibble
following the label stack is often (as we know) interpreted as an IP
Version Number. According to
https://www.iana.org/assignments/version-numbers/version-numbers.xhtml ,
0x0010b (2 decimal) is currently unassigned, so it COULD be assigned by
IANA, creating a future conflict.

We could request IANA to assign IP Version number 2 for this purpose, but I
believe that would be a very difficult sell to both IANA and the IESG, as
there are only a small number of IP Version numbers available.

Instead, I would suggest either of the two following alternatives:

1. Use the MPLS ACH (RFC 5586), starting with 0x0001b, and alter the packet
format in Figure 1 of this draft accordingly so that it follows the ACH's
general format but also includes the necessary fields for the draft's
purpose.

2. Use one of the IANA reserved IP version numbers instead of 0x0010b. I
would recommend 15 (0x1111b). There is reasonable certainty that this would
never actually ever be assigned by IANA.

The first alternative is my personal preference, but I would be OK with the
second as well.

Other comments:

Other than this issue, I found the draft to be well-written and easy to
follow, and generally ready for WG adoption.

Cheers,
Andy

---

From: Loa Andersson <[email-masked]>
Date: Mon, 28 Dec 2020 15:03:38 +0800

Working Group,

Andy and I have discussed this a bit off-line.

Andy,

I have now re-read the this  draft, other relevant drafts and the mail 
we have exchanged. I had earlier partly misunderstood and now think that 
your summary of the situation is basically correct.

However, I'd like to see more discussion on what we should do. In 
particular I'd like to see a comment from the authors on this.

You outline three different proposals:

1.  follow the draft and allocate 0x0010b from IP Version Numbers
     registry in the Version Numbers name space for this purpose
2.  use ACH
3.  use code point #15 from IP Version Numbers registry in the Version
    Numbers name space

To me it seems like 1 and 3 is the same, we ask for a code point from IP 
Version Numbers registry in the Version Numbers name space. IANA pick 
the code point for us.

Note 1: We can give a strong recommendation telling IANA which code 
point we want, but the decision is still with IANA.

Note 2: It seems like the chances that a Version number lower than 6 
will not be picked for an IP version, value 2 is unassigned and much 
easier to allocate than the reserved value 15.

Note 3: I think you are right that it is a hrd sell both to working 
group and the IESG to pick a value from this registry.

Authors.

It would be nice to hear from you on this discussion, but don't change 
the document until we have a reasonable consensus.

/Loa

On 25/12/2020 01:44, Andrew G. Malis wrote:
> I have a major concern that I believe needs to be addressed, either 
> before or after WG adoption (I defer to the WG chairs to make this 
> decision). My personal preference is that it be addressed by the authors 
> prior to adoption, but if it occurs following adoption, I would like to 
> see it addressed before it gets much further in the WG process.
> 
> In Section 6 and Figure 1, 0x0010b (2 decimal) is used for the first 
> nibble following the MPLS label stack in order to avoid ECMP. This 
> intent is fine, but there is an issue with choosing this particular 
> value. The first nibble following the label stack is often (as we know) 
> interpreted as an IP Version Number. According to 
> https://www.iana.org/assignments/version-numbers/version-numbers.xhtml 
> <https://www.iana.org/assignments/version-numbers/version-numbers.xhtml> 
> , 0x0010b (2 decimal) is currently unassigned, so it COULD be assigned 
> by IANA, creating a future conflict.
> 
> We could request IANA to assign IP Version number 2 for this purpose, 
> but I believe that would be a very difficult sell to both IANA and the 
> IESG, as there are only a small number of IP Version numbers available.
> 
> 1. Use the MPLS ACH (RFC 5586), starting with 0x0001b, and alter the 
> packet format in Figure 1 of this draft accordingly so that it follows 
> the ACH's general format but also includes the necessary fields for the 
> draft's purpose.
> 
> would recommend 15 (0x1111b). There is reasonable certainty that this 
> would never actually ever be assigned by IANA.
> 
> The first alternative is my personal preference, but I would be OK with 
> the second as well.
> 
> Other comments:
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: tom petch <[email-masked]>
Date: Mon, 28 Dec 2020 12:56:59 +0000

From: mpls <[email-masked]> on behalf of Loa Andersson <[email-masked]>
Sent: 28 December 2020 07:03
Working Group,

Andy,

<tp>

Why not use ACH?

Tom Petch

Authors.

/Loa

--

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 28 Dec 2020 09:31:41 -0800

Hi Loa, Andy, et al.,
I think that if someone is interested in how a similar problem (as I
understand what IOAM tries to achieve) was resolved, RFC 8169
<https://datatracker.ietf.org/doc/rfc8169/?include_text=1> might have
useful information. We've used ACH, Scratch Pad for collecting telemetry
(residence time), and TLV to carry the original PTP packet through the MPLS
domain.

Regards,
Greg

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 28 Dec 2020 14:05:06 -0500

Greg,

Thanks for the reminder! This is basically what I had in mind when I
suggested using the ACH.

Cheers,
Andy

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 28 Dec 2020 20:32:21 -0500

Thanks Andy, Loa and Greg.
Acking, we can go with a similar ACH based proposal.

Thanks,
Rakesh

On Mon, Dec 28, 2020 at 2:05 PM Andrew G. Malis <[email-masked]> wrote:

>>> > <
>>> https://www.iana.org/assignments/version-numbers/version-numbers.xhtml>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 29 Dec 2020 07:30:13 -0500

Rakesh,

Thanks, sounds good!

Cheers,
Andy

---

From: Loa Andersson <[email-masked]>
Date: Wed, 30 Dec 2020 12:12:38 +0800

Tom, et.al,

> particular I'd like to see a comment from the authors on this.

I don't think there is anything in the thread the says "don't use ACH", 
what I want is just to tie up the last lose ends before going to decision.

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Wed, 30 Dec 2020 12:30:25 +0800

Authors, reviewers and Working Grroup,

We have converged, and will go with an ACH based solution.

Authors,

I'd like to see this in the draft before adopting the draft, so you will 
need to post a new draft when I close MPLS-RT review (planned date 
January 5 or when I have all the MPLS-RT reviews).

/Loa

On 29/12/2020 09:32, Rakesh Gandhi wrote:
> On Mon, Dec 28, 2020 at 2:05 PM Andrew G. Malis <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Greg,
> 
>     On Mon, Dec 28, 2020 at 12:31 PM Greg Mirsky <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hi Loa, Andy, et al.,
>         I think that if someone is interested in how a similar problem
>         (as I understand what IOAM tries to achieve) was resolved, RFC
>         8169
>         <https://datatracker.ietf.org/doc/rfc8169/?include_text=1> might
>         have useful information. We've used ACH, Scratch Pad for
>         collecting telemetry (residence time), and TLV to carry the
>         original PTP packet through the MPLS domain.
> 
>         Regards,
>         Greg
> 
>         On Sun, Dec 27, 2020 at 11:04 PM Loa Andersson <[email-masked]
>         <mailto:[email-masked]>> wrote:
> 
>             Working Group,
> 
>             <https://www.iana.org/assignments/version-numbers/version-numbers.xhtml
>             <https://www.iana.org/assignments/version-numbers/version-numbers.xhtml>>
> 
>              > [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/mpls>
>              >
> 
>             -- 
> 
>             <mailto:[email-masked]>
>             <mailto:[email-masked]>
>             [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/mpls>
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mpls>
> 
> 

--

---

From: Mach Chen <[email-masked]>
Date: Wed, 30 Dec 2020 09:19:44 +0000

Hi, 

I've been asked to provide a pre-adoption MPLS-RT review of draft-gandhi-mpls-ioam-sr-04.

Below are my review comments:

1. I agree that it's more reasonable to leverage GAL/gACH with one or two new dedicated channel types for indicating the presence of iOAM data.

2. In addition, the draft proposes to support both E2E and hop-by-hop (HBH) options. It's nature to use GAL/gACH or the IOAM Indicator Label (IIL) to indicate the presence of iOAM data.  But for HBH case, each intermediate LSR is supposed to process the iOAM data, and the GAL or IIL is put at the bottom of the stack, how does an intermediate LSR know whether there is iOAM data present and it should process the iOAM data?  To scan the whole label stack to find the GAL/IIL or through other means (e.g., put an indicator label on the top the label stack, this may require that each LSR need to pop the IIL label firstly, then process the next label, and put the IIL label back onto the top when forwarding the packet to the next hop) ?  For either way, this needs to be explicitly defined in the document. 

I am OK with other parts of the draft, but the above comments would result in non-trivial updates to the draft, I would see an update before the WG adoption call.

Best regards,
Mach

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 31 Dec 2020 02:51:28 +0000

I have one concern on the usage of ACH. 
I am not sure if there is any restriction that Ach is only used for active/synthetic packet.

Best,
Tianran
-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Wednesday, December 30, 2020 12:13 PM
To: tom petch <[email-masked]>; Andrew G. Malis <[email-masked]>; mpls <[email-masked]>; mpls-chairs <[email-masked]>
Cc: [email-masked]
Subject: Re: [mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04

Tom, et.al,

> particular I'd like to see a comment from the authors on this.

I don't think there is anything in the thread the says "don't use ACH", what I want is just to tie up the last lose ends before going to decision.

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Thu, 31 Dec 2020 15:39:05 +0800

Tianran,

I'm not aware of such a restriction, if there were one wouldn't it have 
been applicable to RFC 8169?

/Loa

--

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 31 Dec 2020 06:48:38 -0500

Loa,

That's correct. It's the GAL that has the restriction, but not the ACH
header.

Cheers,
Andy

On Thu, Dec 31, 2020 at 2:39 AM Loa Andersson <[email-masked]> wrote:

> > To: tom petch <[email-masked]>; Andrew G. Malis <[email-masked]>;
> mpls <[email-masked]>; mpls-chairs <[email-masked]>