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

Greg Mirsky <gregimirsky@gmail.com> Mon, 28 December 2020 17:31 UTC

Return-Path: <gregimirsky@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 62EF73A0CBD; Mon, 28 Dec 2020 09:31:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 3f1KfDcUVDya; Mon, 28 Dec 2020 09:31:55 -0800 (PST)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 C7DF23A0CBA; Mon, 28 Dec 2020 09:31:54 -0800 (PST)
Received: by mail-lf1-x12c.google.com with SMTP id x20so25371464lfe.12; Mon, 28 Dec 2020 09:31:54 -0800 (PST)
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=u2Jew65eApm5HKCMRE9u7l1VpHrkhOOvBPSxqh494sY=; b=SmcchR0Bxexh3twgn1YcNAkmnY9U94UGIu6ycvKSLLeKiO2gCn29Q+J5gOV4R0Uscr t3UYfKgk3lwFaNMhYRklSHs9msh/4HZMDojRYwLlaBo8tyQ3Zbgik7VXjRVq5PNhVKj6 kG0BIEZufyUFbUMyPRbOKnrO2MY5AyDIhc2+J3wqQdwlUJ84glk9KiQ7HOnOPf/f767V wmUHdJtQZsMk9yx4KP2lheDHMzqdal387NOJAzlL60zVAObs4i0/mKoaWxeiZZiLA3Ci v/RhHT79UenyHwOMYlWEe7y1fntCYg+39CF6b8QgHyvPDGgKfeXxsCnL0Ajz8u7iPzc9 vAXA==
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=u2Jew65eApm5HKCMRE9u7l1VpHrkhOOvBPSxqh494sY=; b=epnXwcovzdjC94zUO3XG/HKinCeuqUDacMwxRDjlwCz3+q/iPguv6xzS5uReCfxI2t 3Yo5zllbxNLjUGaHEQwzAmHiy9Q4veHhTWxnI1IEInVRYlvBi5NQidO+YSQv0z8bElpe oZCRkxKTnyuVl83qzPE38f0vlsGT6bEAtQOr619nVg1FklVqJzbCtUH7rz25OmiN8mII lqFWYhVanj3UhODD/IR6KVzXSHdShH417bWoiv+jE74RHBmTC21V0EJCNKafVgjIVXXQ /pegsIH0kPGWhiU6LFUoCeIZqa/AZxmIBSkFy4DxPqc9iFydm4aFreSzWpvTj3ns653K UaIA==
X-Gm-Message-State: AOAM532fUxEUEo9XwA7ge4S0VmTgIffpkCWHZak+aAdMm8IbtjI6pcMs MsSuIRudAbRf40koGH6MCBchEy4pQ9g98HXa6uQ=
X-Google-Smtp-Source: ABdhPJxy6tnp8yK7dzQEfBXurAyK6EyK1X5qVIhcMM7IF6b2lEO41lh3GD4J4YfcE5GC3v86u8RIeHosT7UwseWdJkQ=
X-Received: by 2002:a2e:2a86:: with SMTP id q128mr21918619ljq.158.1609176712540; Mon, 28 Dec 2020 09:31:52 -0800 (PST)
MIME-Version: 1.0
References: <CAA=duU21PHQoJP0cEX6o1K=EwUFqeH19YvcDPNJVKE9c2szS6w@mail.gmail.com> <46b1b623-a628-2373-4378-e70f0038b4f2@pi.nu>
In-Reply-To: <46b1b623-a628-2373-4378-e70f0038b4f2@pi.nu>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 28 Dec 2020 09:31:41 -0800
Message-ID: <CA+RyBmW+eZvx-_HBJU2FCA5z7TAXV-YO+dM2UrHf4X2ebxJLXA@mail.gmail.com>
To: Loa Andersson <loa@pi.nu>
Cc: "Andrew G. Malis" <agmalis@gmail.com>, mpls <mpls@ietf.org>, mpls-chairs <mpls-chairs@ietf.org>, draft-gandhi-mpls-ioam-sr@ietf.org
Content-Type: multipart/alternative; boundary="00000000000054f71d05b789a69d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/3ocNsZM36ToZMbECLxTwtV_dKc8>
Subject: Re: [mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04
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, 28 Dec 2020 17:31:57 -0000

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 <loa@pi.nu> wrote:

> 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'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
> > <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
> >
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls
> >
>
> --
>
> Loa Andersson                        email: loa@pi.nu
> Senior MPLS Expert                          loa.pi.nu@gmail.com
> Bronze Dragon Consulting             phone: +46 739 81 21 64
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>