From nobody Mon Jul 12 13:57:21 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 2AA423A0E6D; Mon, 12 Jul 2021 13:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 SxMhOpKzjdJL; Mon, 12 Jul 2021 13:57:14 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 9D8893A0E76; Mon, 12 Jul 2021 13:57:13 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id u3so4787463plf.5; Mon, 12 Jul 2021 13:57:13 -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=EEM5QmOK27qJljY/WB8aXoo3iLvdmTs02Lybs+f5BI0=; b=sDVYcGNWNrDSch1KvuM68BgpteOyRqbFauQawSxlkQOBwyv0TXpXtJcjYVFLktksys jMarOwcxrULJwbqgG36n/b637ROfCKWIrOh23faRgdDgL6OKt9R9m1NSov7uOn0iESaK B1pUYaIllZnVFY1sBEJjSqpSZWoZ7GUoqkK4AGtoHp/QXrO93rei7xh5KqbDtcQQierZ UfkBc5lWydpKtYEKug37NeIyV8xOA4xdp1PjgOP3FRa5hmaS7Pg3E2Ju2F8OULh/j4Ca Ql/UB0KVOkmdQDYQF7Rzm+VIJPuzRbS/xkfSTmPguWDMg8SC8Tl7oPfmSjM7pKNS02Jr 6nIA== 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=EEM5QmOK27qJljY/WB8aXoo3iLvdmTs02Lybs+f5BI0=; b=YDsR0Di8hRFrR/O+ZrYb243GVP/zWl0on+T1dda/HDS3MzGriasilEOZThvZk6dyFA afUWZL8OOzbITpzNnGfwYOpHeTCHxLYPdGQ19uJf8kb5+VW9zsXpFKp9o5UvLF0SfLga A4oy2j5CzBbDn8RmdubU8rwstaoo7EgvDcIbJFnNF+E6knsyD4Fw9kk84R1rJi3mGB/0 l0G3AZDOvSezBONEefaHhQurFNI+U7C8csx3PxBzgF/QfEnbWh1ePc9KkJ17CJWmvjEQ eg+equi5K1YqPgdQmna1rLVBt5gECsmV5x8GgGPrwlJjw+O5xH60TU7hpHm1X6gsrsC9 FStA== X-Gm-Message-State: AOAM5335z0J9KT0US0J3c0VVXMoaaARtVF9KkXiBwUU5E3t5HvV5eLhZ PhqLCGX5wpg9Dcb2C+kjy8nkCGk0QkquLlt75Zk= X-Google-Smtp-Source: ABdhPJyNDrtNh8C+R1TomAH3cvhInpQpMY6n7/wrEY+ipw77Lj3Z+yeCowkvlgmEH/IBtkSJhuLR/Z3dL6flMUrBG2E= X-Received: by 2002:a17:90a:3b42:: with SMTP id t2mr16279498pjf.193.1626123432679; Mon, 12 Jul 2021 13:57:12 -0700 (PDT) MIME-Version: 1.0 References: <2780a4de-a514-0ae0-bbe7-6c632aaf12e5@pi.nu> <19321_1625747108_60E6EEA4_19321_162_1_53C29892C857584299CBF5D05346208A4CE11F46@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: <19321_1625747108_60E6EEA4_19321_162_1_53C29892C857584299CBF5D05346208A4CE11F46@OPEXCAUBM43.corporate.adroot.infra.ftgroup> From: Kireeti Kompella Date: Mon, 12 Jul 2021 13:57:01 -0700 Message-ID: To: bruno.decraene@orange.com Cc: Loa Andersson , "mpls@ietf.org" , "pals-chairs@ietf.org" , "spring-chairs@ietf.org" , "mpls-chairs@ietf.org" , DetNet Chairs Content-Type: multipart/alternative; boundary="00000000000090df4705c6f35d33" 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:57:20 -0000 --00000000000090df4705c6f35d33 Content-Type: text/plain; charset="UTF-8" Salut Bruno, The current use of the 11 bits falls under "simultaneous use of 6 flags" (plus an extension). Certainly, the semantics of these bits/flags can be defined on a per-administrative domain basis. It complicates the implementation for the vendor, though. If we can agree on a set of flags common to most SPs/CSPs, that would be a good start for the 6 flags. The extensions flags could be per-domain, and we have an idea for that (future version of draft). Cheers, Kireeti. On Thu, Jul 8, 2021 at 5:25 AM wrote: > Hi Loa, > > 1 clarification question. > > > - 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. > > Do you mean 11 possible use of a flag, or 11 simultaneous use of the 11 > flags within one network? > Given that MPLS is used within a trusted administrative domain, the > semantic of these bits could be defined on a per administrative domain > basis. This could allow for the definition/standardization of 10s of > usages, with the restriction of only allowing 11 running within on > AS/network. > > Thanks, > Regards, > --Bruno > > > -----Original Message----- > > From: Loa Andersson [mailto:loa@pi.nu] > > Sent: Thursday, July 8, 2021 11:11 AM > > > > 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. > > > > - 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. > > > > 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. > > > > /Loa > > > > > > > > -- > > > > Loa Andersson email: loa@pi.nu > > Senior MPLS Expert loa.pi.nu@gmail.com > > Bronze Dragon Consulting phone: +46 739 81 21 64 > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --00000000000090df4705c6f35d33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Salut Bruno,

The current use of t= he 11 bits falls under "simultaneous use of 6 flags" (plus an ext= ension).

Certainly, the semantics of these bits/flags ca= n be defined on a per-administrative domain basis.=C2=A0 It complicates the= implementation for the vendor, though.=C2=A0 If we can agree on a set of f= lags common to most SPs/CSPs, that would be a good start for the 6 flags.= =C2=A0 The extensions flags could be per-domain, and we have an idea for th= at (future version of draft).

Cheers,
Ki= reeti.

On Thu, Jul 8, 2021 at 5:25 AM <bruno.decraene@orange.com> wrote:
Hi Loa,

1 clarification question.

> - The flag field of the re-purposed ELI of the the specially assigned<= br> >=C2=A0 =C2=A0 forwarding action indicator label must be made extendable= . These
>=C2=A0 =C2=A0 labels "only" have 11 bits (8 bit TTL and 3 bit= TC fields) that can
>=C2=A0 =C2=A0 be used as flags. Already in the very preliminary discuss= ions we have
>=C2=A0 =C2=A0 had so far are almost using all the 11 bits, making the i= t necessary
>=C2=A0 =C2=A0 to make the indicator extendable.

Do you mean 11 possible use of a flag, or 11 simultaneous use of the 11 fla= gs within one network?
Given that MPLS is used within a trusted administrative domain, the semanti= c of these bits could be defined on a per administrative domain basis. This= could allow for the definition/standardization of 10s of usages, with the = restriction of only allowing 11 running within on AS/network.

Thanks,
Regards,
--Bruno

> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.nu]
> Sent: Thursday, July 8, 2021 11:11 AM
>
> Design Team,
>
> We have discussed how to carry ancillary data in=C2=A0 in an MPLS pack= et 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<= br> > 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<= br> > 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 bas= e
> 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 purpo= se
>=C2=A0 =C2=A0 labels as much as possible
>
> - We have a standardized associated channel, the GAL/GACH. We are not<= br> >=C2=A0 =C2=A0 going to change the associated channel. The associated wi= ll remain as
>=C2=A0 =C2=A0 specified in RFC 5586. The ACH is found immediately after= the label
>=C2=A0 =C2=A0 carrying the Bottom of Stack (BoS) bit.
>
> - We therefore need a (base) special purpose label to serve as the
>=C2=A0 =C2=A0 forwarding action indicator carrier.
>
> - It is attractive to "re-purpose" the ELI to also fill the = role as a
>=C2=A0 =C2=A0 general (generic?) forwarding action indicator. This may = be done by
>=C2=A0 =C2=A0 using the TTL and TC fields of the ELI as flags indicatin= g which
>=C2=A0 =C2=A0 service is requested.
>
>=C2=A0 =C2=A0 However, in order to do this it must be shown that there = is no
>=C2=A0 =C2=A0 potential interference between the normal service supplie= d by the
>=C2=A0 =C2=A0 ELI/EL and the services indicated by the flags.
>
> - If we can't demonstrate the non-interference then we should assi= gn
>=C2=A0 =C2=A0 specific forwarding indicator action base special purpose= label and
>=C2=A0 =C2=A0 leave the ELI/EL unchanged.
>
> - The flag field of the re-purposed ELI of the the specially assigned<= br> >=C2=A0 =C2=A0 forwarding action indicator label must be made extendable= . These
>=C2=A0 =C2=A0 labels "only" have 11 bits (8 bit TTL and 3 bit= TC fields) that can
>=C2=A0 =C2=A0 be used as flags. Already in the very preliminary discuss= ions we have
>=C2=A0 =C2=A0 had so far are almost using all the 11 bits, making the i= t necessary
>=C2=A0 =C2=A0 to make the indicator extendable.
>
> /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= =A0phone: +46 739 81 21 64

___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--00000000000090df4705c6f35d33--