Re: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS

gregory.mirsky@ztetx.com Wed, 16 June 2021 19:24 UTC

Return-Path: <gregory.mirsky@ztetx.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 C8E423A23C1 for <mpls@ietfa.amsl.com>; Wed, 16 Jun 2021 12:24:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 hz_hDPlns7ow for <mpls@ietfa.amsl.com>; Wed, 16 Jun 2021 12:24:02 -0700 (PDT)
Received: from mxus.zteusa.com (mxus.zteusa.com [4.14.134.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD243A23C0 for <mpls@ietf.org>; Wed, 16 Jun 2021 12:24:02 -0700 (PDT)
Received: from mse-us.zte.com.cn (unknown [10.36.11.29]) by Forcepoint Email with ESMTPS id 726101A4130958F52B49; Thu, 17 Jun 2021 03:24:01 +0800 (CST)
Received: from mgapp02.zte.com.cn ([10.36.9.143]) by mse-us.zte.com.cn with SMTP id 15GJNtkZ046771; Thu, 17 Jun 2021 03:23:55 +0800 (GMT-8) (envelope-from gregory.mirsky@ztetx.com)
Received: from mapi (mgapp01[null]) by mapi (Zmail) with MAPI id mid81; Thu, 17 Jun 2021 03:23:55 +0800 (CST)
Date: Thu, 17 Jun 2021 03:23:55 +0800
X-Zmail-TransId: 2af960ca4fcb2ca5cc73
X-Mailer: Zmail v1.0
Message-ID: <202106170323552620410@zte.com.cn>
In-Reply-To: <MW4PR03MB639576D1C4B872AA0F5A8553F6309@MW4PR03MB6395.namprd03.prod.outlook.com>
References: c7d696de-4d83-6e3b-7d10-dc787fdabc73@pi.nu, MW4PR03MB639576D1C4B872AA0F5A8553F6309@MW4PR03MB6395.namprd03.prod.outlook.com
Mime-Version: 1.0
From: gregory.mirsky@ztetx.com
To: Alexander.Vainshtein@rbbn.com
Cc: loa@pi.nu, mpls@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-us.zte.com.cn 15GJNtkZ046771
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/pUM3sboV2t-62nSHOmkqsyiEymo>
Subject: Re: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS
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: Wed, 16 Jun 2021 19:24:08 -0000

Hi Sasha,
I agree with all your comments regarding the GAL. Indeed, GAL in non-MPLS-TP environments may be placed anywhere in a label stack. But how an LSR acts in the case GAL is not BoS has been left under-defined in RFC 5586. As I understand it, you are concerned that any work on closing that gap would not be backward compatible with the existing implementations handling GAL. While that might be the case, I think that the Open DT may give it a try and investigate how the existing systems will handle GAL being not the BoS label.

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
E: gregory.mirsky@ztetx.com
www.zte.com.cn
------------------Original Mail------------------
Sender: AlexanderVainshtein
To: Loa Andersson;
CC: mpls@ietf.org;
Date: 2021/06/15 06:09
Subject: Re: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Loa and all,
I have to admit that I have not been following the work of the DT closely for the last month or so.
Therefore I may be asking some questions that have already been asked and even answered. In which case you can simply say so(hopefully with some reference).
However I still think these questions should be asked.
Please see these questions – with some clarifications –  inline below.
Regards,
Sasha
Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@rbbn.com
-----Original Message-----
From: mpls <mpls-bounces@ietf.org> On Behalf Of Loa Andersson
Sent: Tuesday, June 15, 2021 3:31 PM
To: mpls@ietf.org
Subject: [EXTERNAL] [mpls] Indicators in the stack and ancillary data after the BoS
Design Team,
When the Associated Channel first were desing it was assume that one associated channel per packet would be enough for the future.
[[Sasha]] Actually the initial GACh design (RFC 5586) has provided for a TLV to follow the GACh fixed header,  with the provision that the presence of such a TLV is inferred from the GACh type in the fixed header. However, this mechanism has never been used, and eventually GACh TLVs have been retired (RFC  7026).
I wonder if the need for multiple GACh in a packet could be addressed by GACh TLVs?
The rules for where the GAL (indicator for an associated channel) should be located in the stack and that there could only be one GAL in the stack was strictly specified.
[[Sasha]] GAL has been restricted to be just the BoS label in the MPLS-TP environments, but this restriction does not apply  “to other environments”.
However, I am not aware of any rules for handling GAL if it is exposed to the MPLS forwarder (i.e. becomes top of the stack) while being followed by some other labels. RFC 5586 only says that “A  receiving LSR, LER, or PE MUST NOT forward a G-ACh packet to  another node based on the GAL label”. This is quite different from the definition of handling for the Routing Alert label. From my POV:
·         Lack of these definitions effectively precludes usage of GAL in a non-BoS position
·         Any such definition, if introduced today, will not be backward compatible with the existing implementations.
Now we are where the development has taken us to a point where the GAL can be found at almost any position in the stack.
[[Sasha]] Please see my previous comment.
Further changes are discussed.
- As label stack has been growing there is a risk that some LSRs that
need to find the GAL might find that the GAL is below readable depth.
The proposed remedy is to allow entering a copy of the first GAL
higher in the stack, i.e. more than one GAL in the stack point to the
same ACH.[[Sasha]] The LSR normally looks just at the top label in the stack. If GAL is not in the top position, why should it react to it? And if it is in the top position but not BoS, how will the  packet be forwarded? In addition, GAL does not “point to an ACH”. It says that ACH immediately follows the BoS label, so I fail to understand how a GAL can point to a specific ACH.
- It has also been discussed to carry more than one ACH after the BoS,
i.e. you'll need more than one different GALs in the stack pointing to
different ACH's.[[Sasha]] By different GALs do you mean different reserved – or extended reserved – label values?
(I think the if this statement is true that would require a "slight",
but backwards compatible redesign of the GAL.)
- It has also been discussed to carry more then set of (the ACH is one)
ancillary data after the BoS, and e.g. FAI, GAL, EHI, OAM indicator,
etc. mixed in the label stack.
The issue is that the set of ancillary data after the BoS might will interfere and that we need a strong mechanism to find the ancillary data that "belongs to" a certain indicator.
I think that we first need to decide what is required and after that design a solution.
The correctness of statements about need to be verified and if necessary corrected.
/Loa
PS
Can someone tell me if I should use anxillary or ancillary?
--
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://clicktime.symantec.com/389rPq1ADpF9WRstEF2jdmj6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance  or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.