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

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Wed, 30 June 2021 21:26 UTC

Return-Path: <zzhang@juniper.net>
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 A974E3A2BAF for <mpls@ietfa.amsl.com>; Wed, 30 Jun 2021 14:26:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.997
X-Spam-Level:
X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net header.b=1FOVoyDC; dkim=pass (1024-bit key) header.d=juniper.net header.b=D2t+DetW
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 tpS1tSp4mY07 for <mpls@ietfa.amsl.com>; Wed, 30 Jun 2021 14:26:20 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 538C13A2BAD for <mpls@ietf.org>; Wed, 30 Jun 2021 14:26:20 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 15ULP7SN009509; Wed, 30 Jun 2021 14:26:18 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=zxQY/Iu4iYXfRV4DYiYKpuN8BLrUv9Ea+ZWscxB92/A=; b=1FOVoyDCxWOREipfDlnRCkFpdD9vC5F4PV/rH8omjtEJKDeO2rLNuvjJG2VCr58EnsgS tfxDpz/d36VpQhj9nsGzb51oLcyNYeSG4lxgE3hG1DPWtXN2AQVMAvWT1g0Pg8A9mIzC HLIft64sAZ8X1WyGp3/z04zkjKjmqKpHm5BtmHFzD2sB6v2oygp7Gyg5NPeTiVZw3jIH q6FuycilaLgcHNO6wesdzIhqSc7s5habwzlPzCgocG4AdcAGH5hXJR3g7jeTDyPZh3Xq o2GjcRbkKQhE5jK5c+0AcU2+sVSYMwM69pfRWYHp9o2fnZdSj9OSvSCfg1R4EGs3n1lr 0A==
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2106.outbound.protection.outlook.com [104.47.70.106]) by mx0b-00273201.pphosted.com with ESMTP id 39gmnshfmw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Jun 2021 14:26:17 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LRVvIHhQ5aRPaYTVmzqGBLNMGC5ERtq9HjhfQyWPeyEVoXaYUvJpFyz/N/PuOBUHs1c1n6/7VRE+dHiyj6cGFn/PgR+o2qtpu+JfmwhH0EuuxxMdZagc+Oi1eyCEgfgh4pCwIEmjbeYCPP7CVx4FW6+3o+C7IkTuLTntjfdM7qH4MXNp/QDNLsccWGZ5HlaWU20fZKuDIsE8z1n05OfRRPyQkTr5Y0DjYvEltrPzE1dUdIRU4fChqVAw9xqqgvCtH9bunzdc+1iIUZ+HQnW+cKzeMwacpxNTezXnyWDxvYmEJjC9pADvi2unAnXZMZTdxBztvVioxsSQyqoX4p4DkA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zxQY/Iu4iYXfRV4DYiYKpuN8BLrUv9Ea+ZWscxB92/A=; b=e8NTmyHAwEQmbxMxgOonpjiTomwhSer49DDq7KvLO8nHXWiWpV9OqfVmEAiPwR+zeu4TTCJ62viMxL3iZjJ8iRQ/kHTCRmxUo27Vyod5h/aeLB3wIE8WnQc5vUsRn6B0xZ2wMNhnhHjWdtAnnjvxtnWGug42T7NNA+OGYPeCCk0wBeJx/bKgLy0SQf9t5PIEgvBWqnjnzIFAGtIF7oXFRKD123dsZPFqcB29Hz+BdASwi9Te5XfuhELuyV+mu7x/Xjmn0mLdMJcK+GpXcB6Hk0rW4FDMNkOz3aBOVfk/H7A0BcA5wIRF0OnEGaEJgCHYyqpKiwqXs5T6mI1q2edoJQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zxQY/Iu4iYXfRV4DYiYKpuN8BLrUv9Ea+ZWscxB92/A=; b=D2t+DetWTrjgkoYRfk+6Kw5OwVUE2qaycGfG0G3BnX/YOQ3rJu5yQFYM4NNifBvJpP4zp96C4ZIdxgfcpx+4jLAEMsm6rIERdtI85ssKz5qTZjjs8WuO1cnobDWs8B+xxB6MzPliU8jiimjt12txyzvOkh2wxfhvlKXvcj8gyIo=
Received: from BL0PR05MB5652.namprd05.prod.outlook.com (2603:10b6:208:6a::19) by BLAPR05MB7347.namprd05.prod.outlook.com (2603:10b6:208:29b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.8; Wed, 30 Jun 2021 21:26:14 +0000
Received: from BL0PR05MB5652.namprd05.prod.outlook.com ([fe80::454f:fd4:90e2:3b2f]) by BL0PR05MB5652.namprd05.prod.outlook.com ([fe80::454f:fd4:90e2:3b2f%6]) with mapi id 15.20.4287.022; Wed, 30 Jun 2021 21:26:14 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Loa Andersson <loa@pi.nu>, Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>, Stewart Bryant <stewart.bryant@gmail.com>
CC: "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS
Thread-Index: AQHXY0RmbAITnxhwMUWQkxpAfLtXgKsX0EoAgAAZVICAAFKAUIAADGgAgAADVWCABHeggIAQUdBA
Date: Wed, 30 Jun 2021 21:26:14 +0000
Message-ID: <BL0PR05MB565215105C5CB6D89CFB8666D4019@BL0PR05MB5652.namprd05.prod.outlook.com>
References: <c7d696de-4d83-6e3b-7d10-dc787fdabc73@pi.nu,> <MW4PR03MB639576D1C4B872AA0F5A8553F6309@MW4PR03MB6395.namprd03.prod.outlook.com> <202106170323552620410@zte.com.cn> <MW4PR03MB6395DE6E57E7CBF041ABE8E2F60E9@MW4PR03MB6395.namprd03.prod.outlook.com> <E512176A-02D5-4F74-8644-EAC4E3938AEF@gmail.com> <MW4PR03MB6395DA0A79E5882ECAC2B7E4F60E9@MW4PR03MB6395.namprd03.prod.outlook.com> <BL0PR05MB5652F9023D07DA3FC8479DDCD40E9@BL0PR05MB5652.namprd05.prod.outlook.com> <ed6341bc-5508-5fb6-f5c2-e55154c22f2e@pi.nu> <BL0PR05MB5652596A808CD766C250F369D40E9@BL0PR05MB5652.namprd05.prod.outlook.com> <1bd54f43-880e-07f9-93cd-7d0aba9266d0@pi.nu>
In-Reply-To: <1bd54f43-880e-07f9-93cd-7d0aba9266d0@pi.nu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.6.100.41
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=4215de4c-b1d5-4feb-83d9-6b961605301a; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-06-30T20:24:23Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
authentication-results: pi.nu; dkim=none (message not signed) header.d=none;pi.nu; dmarc=none action=none header.from=juniper.net;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 66469b21-d232-46f6-2565-08d93c0db0a3
x-ms-traffictypediagnostic: BLAPR05MB7347:
x-microsoft-antispam-prvs: <BLAPR05MB7347A2A95F0FFEAD4A60CD87D4019@BLAPR05MB7347.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: OfpVhl0K2Az19dkeuzVZqlMOEDsh0KJIwWlQK/hCeiD/vY0usEfd2NGxWgbVPw0/xfliEPGc9qJK1yldCwL1kHeP80+aA/f9//JfEsE67CHBPDd3wX7m0MiOaOt6o/1JL9GVAnAr9OPBIUrSdCZXpKifKWujpkE+MgOB+aPNemRDR+S9Gm/LQZP+BdBO2LZhk0xZrF5POexz8yHK7RtM9dGUi4ylfIZEyFBZvavzIFAzhmZ/vrzY6esLmvLxkF/L5mlohmx4/f1G/3AVR1jyY7sQKg7Vwk1YhGkPB9pln8YAW5QOjSmYejs4VM+Pnn54/NQAuZHNC00rH8so2J09jcIQOrRVMpkVCmOTwCQHjQZTOMkr8K2wSLCpFjb03Krkiv1sYz3msn1cE6XJublzsJtsTTs0NgJO6wzuETL0XsVmGwqlQKNQ7f3q3euxLCFwmI4ba2E720d8gh0xrl71vWCwV0lB6wpshlW8a3WLQqcLmD37IsD7bYW8GIMKpqbD1lIUqrv2cisigUJb6ANi4ij9hcQYk1Ay3teB+m8dNjTnxYDLoSoZ4qRf3A1LqemQ6JW3x5nvO4VSoX8HUxLqrP5V1jY54JIFVQQp5eBl8soOrZuR7zHtvMCpF3NEvGbhtbqH8W2IRrOImi+EInmYAJ7sTSE6Vf5tUaRFkxEcdA0bcYpWOkLQtOMdbU8fHZGnUVz6/vn1Zf9Ymv4GQFY4eCUvc4LWU2KErvgAWgZosImzRVm48CBir7TXTtYzZarJoR2LegZzpXTYL5YBHStPCA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5652.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(366004)(136003)(376002)(39860400002)(110136005)(83380400001)(7696005)(2906002)(4326008)(26005)(9686003)(30864003)(55016002)(186003)(52536014)(66556008)(64756008)(66476007)(478600001)(66946007)(76116006)(33656002)(8936002)(5660300002)(966005)(8676002)(122000001)(66446008)(53546011)(6506007)(86362001)(71200400001)(316002)(38100700002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: xg34s+Fo9fSKtJqCdlmf9/ptIjWaxMf+PGaAlcwd+tEwMG/KeYzOuVRLRrKuyweSpRCQXFvJuIVU3X/h/m8hmwqX7frLzblr46q6hpZR7SHAZkFXOsJd+dVbn+51lnXdFTUWNOwxJk0oNkSrcEkVYaWj+evuOhGC6kzSXwJnU/2ASZxPU77PRBODU5IZEN12aZ1haT0RSXCftacrbS4uokCdw0EZ4eCbkyUEleXuFNZmZvS4YKs0hoXsF3974AQWRYdLqeMb1C8JtrM/p1ZUhozRBXqKEU94v8y6PLb1y63Kxtn1D1j0oDC/gArWznMeWIdwajToeWUSNIarL8MJyucnGWDFipxjd92/A1bnqamTdIbO3zTCM5sYPdigghdgZ3c1J+FSa8cnngJ1V7zZZZuDeR+r9P4bLBYtVJX83clCGaGMHaCnQZHINdmQngsRnOPib3SEQNMU9Xo2KGBUCV60sCvYFL/hAjRsNtF917dnXsRf0el3p06WnL9NAWtiEZ7pRrG8Tx1vLH8riKLxCk5pq8A84aCU2UjW8RN59Amt2kJl+GXsKcd76ZnT0cilkPKhq2IdZY1yu1T+FBeRIuiZt2onS4H8RzK+yZbJ/icDzxuRBA+26qbyHT/lxI2wpYVtE3EdqyISUUtp7Uf7kLYjF9ghePfl2eHIlXdGnV7E3PZp44Lf4p4sTa5Fa17HtLRFQp9/ZOdMNv4t0TtgzPEaPvsKk2CGuoHXcOWcbUCY9SK4bXwYb7r3tsa1i7WAQ0V0qCuo4w7e4zuCxunMQALdsr7mCg7GqyS2C7XjKh8xQUJBK+SJ7l29rkfBANvrD6YXQOXmGkPOGtKZtavka0MFVio0mqaYUvmRqVuzHaZ5DHZb19khVeBSSy8DqkpF0qzxXBfo981b5ngjjn5ZV1cTxgepgDgE3gm7Ab/syrjchDgCzvDup9Lam8JmUF1dzbESlQ5llPQIDwF/AiEVtiqgmZJm33mPRROQa1j17sRrrr7w5RtYDuOQygI+wozbzOywb7uvoHkoF6/xQrpl1mwgFbuu6AGtTaQz6Bv0ns4Twttljru3h7p9DCvhDYalAP1LP2IOh62LYnWWLl7Nmav7rr6vagbc/k+0Dqvp7Urlw/AyS4OLyPFcsHroan5yCzcG4Vx5+dRmk9sWUrSdE6EPq5Sc/SjFKSwLr+maoYl3L3Gi9o6cy3hL5xDKE8xZtJODtMO83+RzavTAojZ7Ay7Y+PMHaAmi8HzxdY7aUZFLBgKmXiPxIkpLrxKsakhzVaGYs0LfKc0w1aVkIfynMlCCLXVU8zPAGMbT9oTuPg3PcN3cvnQr3upezrWplIxb
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5652.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 66469b21-d232-46f6-2565-08d93c0db0a3
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2021 21:26:14.4659 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: H6JiSGWOnEm2sv33Ov7JdDiVxmoHoU4Mee2m9HiGhzVhO+At38i60fhvrybZrvAsu+/daWG50qrqQZzglAEQdA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR05MB7347
X-Proofpoint-ORIG-GUID: wbVqxrraa2RurJ6Wu99ueYc2BYhN8wJ5
X-Proofpoint-GUID: wbVqxrraa2RurJ6Wu99ueYc2BYhN8wJ5
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-30_12:2021-06-30, 2021-06-30 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 malwarescore=0 bulkscore=0 mlxscore=0 adultscore=0 clxscore=1015 spamscore=0 priorityscore=1501 lowpriorityscore=0 mlxlogscore=999 impostorscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106300118
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/llvEZfxmfTZlSit45EqFx9i8k1E>
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, 30 Jun 2021 21:26:26 -0000

Hi,

Pardon me that I was not able to timely follow the discussions. I am slowly catching up - please allow me to reply to this old email even though there were a lot of newer ones because this one has better context than latter deeply-nested email. However I will refer to some latter email in this reply.

Please see zzh> below.

-----Original Message-----
From: Loa Andersson <loa@pi.nu>
Sent: Sunday, June 20, 2021 7:11 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Stewart Bryant <stewart.bryant@gmail.com>
Cc: mpls@ietf.org
Subject: Re: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS

[External Email. Be cautious of content]


Jeffrey,


On 17/06/2021 17:01, Jeffrey (Zhaohui) Zhang wrote:
> Hi Loa,
>
>> but I'd like to see the DT address multiple indicators in the stack and multiple sets of ancillary data after the BoS.
>
> I think the earlier emails of this email thread were talking about multiple indicators in the stack; for multiple set of ancillary data after the BoS, either the extended ACH or the proposed MPLS/generic extension headers or a merge of those proposals should be able to handle it. This is alluded to the DataAfterBOS wiki page.

hmm - yes partly, but there are several indicators proposed in several
drafts

  draft-gandhi-mpls-ioam-sr has an E"E indicaor and an HBH indicator

zzh> I consider this as a one of the extension header use case so does not need to be considered separately.

  draft-kompella-mpls-mspl4fa make use of TC field and TTL of a special
purpose label (FAI) as indicators

zzh> Except Bruno's proposal of using ELI/EL as an indicator, I think generally we are leaning towards using an SPL or XL+ESPL as a logical indicator. Draft-kompella allows a single SPL to achieve functions of otherwise multiple SPL or XL+ESPL, so for the purpose of discussions on the indicators, we can just focus on an SPL, which could either be a new SPL (w/ or w/o draft-kompella tricks) or we can extend the GAL.
Zzh> Several people have said we should not mess with GAL/ACH for this purpose and I am fine with that. However, when there is GAL(s) in the stack, since the data after the BoS must be ACH, we started talking about encoding ancillary data in ACH again. So - are we going to use GAL/ACH or not?

  draft-many-mpls-multiple-gal proposes to add a copy of the GAL higher
uop the stack so that LSRs with a too shallow maximun readable depth
might reach the GAL

  there has also been discussion about putting more than one GAL in the
stack, i.e. differerent GALs pointing to different ACHs.

Zzh> I thought we could not have different GALs pointing to different ACHs as mentioned in the email below (a non-BOS GAL would not have ACH following it).

  draft-song-mpls-eh-indicator have a list of potential indicators, that
is also telling if the EH should be processed on every EH capable node
or "just" at ingress and egress

zzh> I think Haoyu said later that he is now leaning towards the draft-kompella method.

The FAI might put ancillary data after the BoS.

I think we need to have a comprehensive discussion

- first what we want to have
- second how when re-direct by an indicator we find the
   ancillary data that belongs to that indicator.

Zzh> My understanding is this: A) we want  to indicate ancillary data after the BoS;  B) *Some people may* want to have different ancillary data with different indicators.
Zzh> I think A) is not difficult (it's still not clear to me whether GAL/ACH is still on the table).  B) is not feasible, for the same reason that ACH can only be after BoS. However, different ancillary data can be associated with different EHs which are altogether following a single indicator.

Zzh> Jeffrey

/Loa




>
> Thanks.
>
> Jeffrey
>
> -----Original Message-----
> From: Loa Andersson <loa@pi.nu>
> Sent: Thursday, June 17, 2021 10:46 AM
> To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Stewart Bryant <stewart.bryant@gmail.com>
> Cc: mpls@ietf.org
> Subject: Re: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS
>
> [External Email. Be cautious of content]
>
>
> DT,
>
> Responded to Jeffrey's mail, but it is intended to address the entire
> discussion.
>
> There seem to be enough issues to sort out around the GAL/ACH pair, and
> I was worried about a set of other indicators and the data that they
> might want to put "after the BoS". So far I have seen no real effort to
> address the interference's this might lead to.
>
> Further inline
>
>
> On 17/06/2021 16:15, Jeffrey (Zhaohui) Zhang wrote:
>> Hi,
>>
>> It’s not clear how we could put a GAL not at a BoS:
>>
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>      |                              ACH                              |
>>
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>      |                         ACH TLV Header                        |
>>
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>      |                                                               ~
>>
>>      ~                     zero or more ACH TLVs                     ~
>>
>>      ~                                                               |
>>
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>      |                                                               ~
>>
>>      ~                        G-ACh Message                          ~
>>
>>      ~                                                               |
>>
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>                         Figure 2: G-ACh Packet Payload
>>
>> If the GAL does not have S-bit set, wouldn’t a transit LSR treat any
>> 4-ocet field (i.e. those in the above Figure) after that GAL as a
>> label+TOS+S+TTL? If that 4-octet field has the S-bit set, the transit
>> LSR will think the label stack ends there even though that’s just part
>> of the ACH.
>>
>> Or are you saying that a GAL not at the BoS will not have the ACH
>> following it?
>
> Well, as far as I understand a GAL which does not have the NoS-bit set
> will have other labels after itself. The BoS-bit will be found deeper
> down stack and the ACH will immediately fo9llow the BoS.
>
> Yes there are issues here, but I'd like to see the DT address multiple
> indicators in the stack and multiple sets of ancillary data after the BoS.
>
> I think we need to nail down the relevant questiuons first, and start
> working on solutions after that.
>
> /Loa
>>
>> Jeffrey
>>
>> *From:*mpls <mpls-bounces@ietf.org> *On Behalf Of *Alexander Vainshtein
>> *Sent:* Thursday, June 17, 2021 5:07 AM
>> *To:* Stewart Bryant <stewart.bryant@gmail.com>
>> *Cc:* mpls@ietf.org
>> *Subject:* Re: [mpls] [EXTERNAL] Indicators in the stack and ancillary
>> data after the BoS
>>
>> *[External Email. Be cautious of content]*
>>
>> Stewart,
>>
>> I fully agree with your statement that “an old implementation that
>> received a ToS GAL not at BoS would at best throw an exception or worst
>> be unpredictable”.
>>
>> Regarding your statement “it is OK to have multiple GALs and GALs not at
>> BoS IFF the creator of the LSP ensured that all LSRs on the LSP,
>> including ECMP and FRR paths that found the GAL at ToS were known to be
>> able to process it correctly”:
>>
>>   1. I fully agree with this statement as a general restriction
>>   2. Quite a lot of things have to be done in order to make this
>>      restriction work including at least:
>>
>>       1. The definition of correct processing of GAL at ToS but not at
>>          BoS must be provided
>>       2. Advertisement of ability to process GAL not at BoS correctly in
>>          IGP and BGP must be defined
>>       3. Ability to set up network-wide paths that only cross nodes that
>>          process GAL correctly must be provided for different techniques
>>          (RSVP-TE, SR-TE, FlexAlgo. BGP-LU etc.)
>>
>> It is still possible that, after all this work, we shall find out  that
>> the benefits of supporting GAL at ToS but not BoS will be only available
>> in the networks where all the nodes support the new functionality
>> because presence of non-supporting nodes imposes too many restrictions
>> on connectivity and/or resilience.
>>
>> Regards,
>>
>> Sasha
>>
>> Office: +972-39266302
>>
>> Cell:      +972-549266302
>>
>> Email: Alexander.Vainshtein@rbbn.com <mailto:Alexander.Vainshtein@rbbn.com>
>>
>> *From:*Stewart Bryant <stewart.bryant@gmail.com
>> <mailto:stewart.bryant@gmail.com>>
>> *Sent:* Thursday, June 17, 2021 10:36 AM
>> *To:* Alexander Vainshtein <Alexander.Vainshtein@rbbn.com
>> <mailto:Alexander.Vainshtein@rbbn.com>>
>> *Cc:* Stewart Bryant <stewart.bryant@gmail.com
>> <mailto:stewart.bryant@gmail.com>>; gregory.mirsky@ztetx.com
>> <mailto:gregory.mirsky@ztetx.com>; mpls@ietf.org <mailto:mpls@ietf.org>
>> *Subject:* Re: [mpls] [EXTERNAL] Indicators in the stack and ancillary
>> data after the BoS
>>
>>      On 17 Jun 2021, at 07:45, Alexander Vainshtein
>>      <Alexander.Vainshtein@rbbn.com
>>      <mailto:Alexander.Vainshtein@rbbn.com>> wrote:
>>
>>      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.
>>
>>      */[[Sasha]] Great minds think alike! One useful step could be
>>      collecting the known actual behavior of popular implementations in
>>      this case, say, by running a survey among the vendors – what do you
>>      think?/*
>>
>> That is actually a considerable amount of work that will take a while.
>>
>> It seems to me that an old implementation that received a ToS GAL not at
>> BoS would at best throw an exception or worst be unpredictable.
>>
>> The original assumed processing model is to take the context of the PW
>> label or PW+FAT label, discover the GAL and then process the GAL in the
>> context of the PW label.
>>
>> When we extended GAL to apply to LSPs we again had the model that the
>> GAL operated in the context of the LSP label that preceded it for
>> context. It was still BoS.
>>
>> Putting the GAL further up the stack is a new behaviour.
>>
>> If it arrives at an LSR that knows the new semantic all is good.
>>
>> If it arrives at an LSR that does not know the new semantic then
>>
>> a) An error has occurred either in setting up the LSP, or in forwarding.
>>
>> b) The behaviour at the receiving node is unpredictable, but in any well
>> written implementation should just result in the packet being dropped
>> and counted as with any other Mal-formed packet.
>>
>> So I would think that it is OK to have multiple GALs and GALs not at BoS
>> IFF the creator of the LSP ensured that all LSRs on the LSP, including
>> ECMP and FRR paths that found the GAL at ToS were known to be able to
>> process it correctly.
>>
>> A GAL not at BoS and not at ToS should not be inspected or processed by
>> any LSR that did not know what it was doing, and to attempt to precess
>> it would be a violation of the normal MPLS processing model.
>>
>> - Stewart
>>
>>
>> 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.
>>
>>
>> Juniper Business Use Only
>>
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!RVgTGVbknjgIjv3x-q8ob1JglFKOP6qKkgAcCSPbeBMMj2AnexFnPevXopeK1a6u$
>>
>
> --
>
> Loa Andersson                        email: loa@pi.nu
> Senior MPLS Expert                          loa.pi.nu@gmail.com
> Bronze Dragon Consulting             phone: +46 739 81 21 64
>
> Juniper Business Use Only
>

--

Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert                          loa.pi.nu@gmail.com
Bronze Dragon Consulting             phone: +46 739 81 21 64

Juniper Business Use Only