From nobody Mon Jul 12 13:43:31 2021 Return-Path: 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 5CB273A0CF2; Mon, 12 Jul 2021 13:43:22 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 TnydhATHg9uS; Mon, 12 Jul 2021 13:43:17 -0700 (PDT) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 F29213A0E03; Mon, 12 Jul 2021 13:43:01 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id x16so17510589pfa.13; Mon, 12 Jul 2021 13:43:01 -0700 (PDT) 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=1UyZGv2PTuSPTSx2SxVRV7ADjLnEUEVobSSAUjupPOA=; b=pmSn48DIcSPdNJ7RxqlnX+uOpAMBHQg5S55aZVY46fKYa4JNtijEzkh+NToRtrw3k4 bLCSmcJKxkXQ4fV99kaZC5iIzUDrxtTNNUXIa0/lNctDcJe3Ay+aZh7drKposHT5voYb 9LTczFUq6ZbShHEV8PYGkionqQJ9Patc2MYaYfoRrqvVWpjZYk/5Qm5WOlsnDoujFTCh DJ8DIGTqVDQp+ZzAquNkeIOL7qvb0Y0d/d3IJawdV+rQvueNYDrhA7FJQ41uV04zJ7y+ EHQIMd7ACklnqdir2lROV4FkfK0fl2hFOym8eVjKsbtNpBSB/3sYdZPyq2+PDCkeGrjc eJJQ== 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=1UyZGv2PTuSPTSx2SxVRV7ADjLnEUEVobSSAUjupPOA=; b=T7z5NDNPJ3va21uUnid/z2hhwcyF8UDfusV6Y0xsB7+/lzt5OY0/Pudhkmk/rpYvZV vOpNNmucskbB7lEANljpHIMCsv6rhyJXYqeZ4kVSX6QP4E9WRZb9sYA4e5nCmkDGzdmZ fDESwpKJbx3heZ2nZM2gjSui8L4uYNqT482Nx6K1zo1pi7IM7fjJu7DUkIB92XIGz94r t1I68kJ22RW6/oN94bj2OLZvJpLm9tiiimAagCQFQFA4M+GUp3y2chDZgtSM/W09JfqM dzkV3IjLgoNMChMs9+FfGEKn/RIUymv14ykJqP12S2nqCbpQfkpuIYW/NN9CnlqjGsuG BOIw== X-Gm-Message-State: AOAM532BmlsiPA6fAaXJiot0r71abUsyn+xGILHkS7smAakSM56eFt8w VywsXD0VcSKWWQiqnxJdS7mfvzyRIzbhJVRvh8qKFsMuLgw= X-Google-Smtp-Source: ABdhPJy/NhI/bEJSdfY1dpE2TNXuo3kKrDljr/vxKuahUpEytqjxd4KK3hXBQfIT88hm0Ic4ZKmiClxPNuTlLyCvvsQ= X-Received: by 2002:a65:5c01:: with SMTP id u1mr895199pgr.181.1626122580213; Mon, 12 Jul 2021 13:43:00 -0700 (PDT) MIME-Version: 1.0 References: <2780a4de-a514-0ae0-bbe7-6c632aaf12e5@pi.nu> In-Reply-To: <2780a4de-a514-0ae0-bbe7-6c632aaf12e5@pi.nu> From: Kireeti Kompella Date: Mon, 12 Jul 2021 13:42:49 -0700 Message-ID: To: Loa Andersson Cc: "mpls@ietf.org" , "pals-chairs@ietf.org" , "spring-chairs@ietf.org" , "mpls-chairs@ietf.org" , DetNet Chairs Content-Type: multipart/alternative; boundary="000000000000c143d005c6f32a2d" Archived-At: Subject: Re: [mpls] Thoughts on Ancillary Data Indicators. X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 20:43:29 -0000 --000000000000c143d005c6f32a2d Content-Type: text/plain; charset="UTF-8" Hi Loa, See inline. On Thu, Jul 8, 2021 at 2:11 AM Loa Andersson wrote: > Design Team, > > We have discussed how to carry ancillary data in in an MPLS packet and > how to include indicators on the presences of such data in the label > stack since the design team started. I think we have some convergence > and that it is time to float an idea that could be the basis for a > consensus. Please note that the actual consensus call will be made on > the mpls wg mailing list, while this is for discussion preparing such a > consensus call in the design team. > > The proposals we have for indicators often rely on assignment of a base > special purpose label. The number of such labels are limited. > > I think we can agree on the following: > > - We want to limit the number of new assignments of base special purpose > labels as much as possible > > - We have a standardized associated channel, the GAL/GACH. We are not > going to change the associated channel. The associated will remain as > specified in RFC 5586. The ACH is found immediately after the label > carrying the Bottom of Stack (BoS) bit. > > - We therefore need a (base) special purpose label to serve as the > forwarding action indicator carrier. > The proposal in draft-kompella-mpls-mspl4fa does this, and at the same time, collapses the requests of 5 or 6 SPLs to a single SPL. - It is attractive to "re-purpose" the ELI to also fill the role as a > general (generic?) forwarding action indicator. This may be done by > using the TTL and TC fields of the ELI as flags indicating which > service is requested. > While I'd be happy if this was possible, backward compatibility MUST be maintained without compromising functionality. > However, in order to do this it must be shown that there is no > potential interference between the normal service supplied by the > ELI/EL and the services indicated by the flags. > > - If we can't demonstrate the non-interference then we should assign > specific forwarding indicator action base special purpose label and > leave the ELI/EL unchanged. > > - The flag field of the re-purposed ELI of the the specially assigned > forwarding action indicator label must be made extendable. These > labels "only" have 11 bits (8 bit TTL and 3 bit TC fields) that can > be used as flags. Already in the very preliminary discussions we have > had so far are almost using all the 11 bits, making the it necessary > to make the indicator extendable. > Actually, the draft already had such an extension in place; the details have been fleshed out a bit better in the new version (just posted). The bit fields have changed as a consequence of my chat with Haoyu; some have been removed, but more added, so all 11 bits have been used up. So the extension header will be needed. The -01 draft is clearer than the -00 draft on several fronts, and lists issues needing resolution. I'm sure more will come up after the MPLS WG meeting. Cheers, Kireeti. > /Loa > > > > -- > > 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 > --000000000000c143d005c6f32a2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Loa,

See inline.
On Thu, J= ul 8, 2021 at 2:11 AM Loa Andersson <loa@pi= .nu> wrote:
Design Team,

We have discussed how to carry ancillary data in=C2=A0 in an MPLS packet an= d
how to include indicators on the presences of such data in the label
stack since the design team started. I think we have some convergence
and that it is time to float an idea that could be the basis for a
consensus. Please note that the actual consensus call will be made on
the mpls wg mailing list, while this is for discussion preparing such a consensus call in the design team.

The proposals we have for indicators often rely on assignment of a base special purpose label. The number of such labels are limited.

I think we can agree on the following:

- We want to limit the number of new assignments of base special purpose =C2=A0 =C2=A0labels as much as possible

- We have a standardized associated channel, the GAL/GACH. We are not
=C2=A0 =C2=A0going to change the associated channel. The associated will re= main as
=C2=A0 =C2=A0specified in RFC 5586. The ACH is found immediately after the = label
=C2=A0 =C2=A0carrying the Bottom of Stack (BoS) bit.

- We therefore need a (base) special purpose label to serve as the
=C2=A0 =C2=A0forwarding action indicator carrier.

=
The proposal in draft-kompella-mpls-mspl4fa does this, and at th= e same time, collapses the requests of 5 or 6 SPLs to a single SPL.

- It is attractive to "re-purpose" the ELI to also fill the role = as a
=C2=A0 =C2=A0general (generic?) forwarding action indicator. This may be do= ne by
=C2=A0 =C2=A0using the TTL and TC fields of the ELI as flags indicating whi= ch
=C2=A0 =C2=A0service is requested.

Whil= e I'd be happy if this was possible, backward compatibility MUST be mai= ntained without compromising functionality.
=C2=A0
=C2=A0 =C2=A0However, in order to do this it must be shown that there is no=
=C2=A0 =C2=A0potential interference between the normal service supplied by = the
=C2=A0 =C2=A0ELI/EL and the services indicated by the flags.

- If we can't demonstrate the non-interference then we should assign =C2=A0 =C2=A0specific forwarding indicator action base special purpose labe= l and
=C2=A0 =C2=A0leave the ELI/EL unchanged.

- The flag field of the re-purposed ELI of the the specially assigned
=C2=A0 =C2=A0forwarding action indicator label must be made extendable. The= se
=C2=A0 =C2=A0labels "only" have 11 bits (8 bit TTL and 3 bit TC f= ields) that can
=C2=A0 =C2=A0be used as flags. Already in the very preliminary discussions = we have
=C2=A0 =C2=A0had so far are almost using all the 11 bits, making the it nec= essary
=C2=A0 =C2=A0to make the indicator extendable.

Actually, the draft already had such an extension in place; the det= ails have been fleshed out a bit better in the new version (just posted).

The bit fields have changed as a consequence of my = chat with Haoyu; some have been removed, but more added, so all 11 bits hav= e been used up. So the extension header will be needed.

The -01 draft is clearer than the -00 draft on several fronts, and li= sts issues needing resolution.=C2=A0 I'm sure more will come up after t= he MPLS WG meeting.

Cheers,
Kireeti.
=C2=A0
/Loa



--

Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@pi.nu
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa.pi.nu@gmail.com
Bronze Dragon Consulting=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pho= ne: +46 739 81 21 64

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--000000000000c143d005c6f32a2d--