Re: [Pals] draft-zzhang-intarea-generic-delivery-functions

John E Drake <jdrake@juniper.net> Tue, 23 February 2021 15:50 UTC

Return-Path: <jdrake@juniper.net>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDCC3A2CF0; Tue, 23 Feb 2021 07:50:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.668
X-Spam-Level:
X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.57, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=1oMFtbe5; dkim=pass (1024-bit key) header.d=juniper.net header.b=Z52vkZwu
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 iVMquxGlEVfy; Tue, 23 Feb 2021 07:50:46 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 E6E5B3A2C74; Tue, 23 Feb 2021 07:49:59 -0800 (PST)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 11NFnfXq026467; Tue, 23 Feb 2021 07:49:58 -0800
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 : mime-version; s=PPS1017; bh=8H969qG0f7wmMlJ2C5ZF3qKLVZfX2IsqUvbvFgjHqdE=; b=1oMFtbe5MVKCRpT7wYyt2DCrPABBz/wMw3+Mnh+aRvm/SrR+Tfewyud8bhUusyS8lGPn 5kRc1IOJIqS8l0z6xwJivPD70+5ByitfKKengH5+sJ+CYEPqKqzbpFb64jelQzeEWV7Y nFzgyK5PJREGnXV6m04ySHBXO1MRRBgqwzepeibfPw5821pi7fn12nHYvvfpjIdDUeKc FJJhOw6V1LJyUfcrgSUXaWsXfrzOHZ35zK3w7C20Z0TP30yLB9nQ5SpTi0BQ+9itKwT8 0i1jJCSqiWKBbnU2xrnDm6JrJsUo8Q2hUHtWSZee0CIywRKZscI9RwRQKK44K0TwHLf5 dQ==
Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2168.outbound.protection.outlook.com [104.47.59.168]) by mx0a-00273201.pphosted.com with ESMTP id 36u193677q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Feb 2021 07:49:58 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LbEJzNPVjD+yo4JIJhE+yaRpOhsseb0nUIoWuOQm/U95uM2u18kKRL6Ykq8RmmA5xsmt25VH0Y8/3MqwkIGI7+GLWKFjC41+7iMXZokuwthVk3HDiWRTawUM0iwaT56bGw9Cc8VH0zw8wXOvJbfOQq03KtpFRqX7ifQGZ9SiJDjO5UHo7bzsNWcj+HYURSsreY7LHe2phGEtwCJsHCNUuZNQE0q630Z9PuGcSgdrA1f9m6j1AFXoWpmy/EzYKGJCWeLcVhee2vsoDXtzVfIPBbp5RMawMKc07weEadQG+3uhP+oMoXu8nbpsalwgrkQcqlao0jnvXnv0+EGPvipLTg==
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=8H969qG0f7wmMlJ2C5ZF3qKLVZfX2IsqUvbvFgjHqdE=; b=norDFsznnnikT6nFHWMHQ3L2OmvN2wSvHTs0H1wcnW4kiNMyK/3sTpg4y5h6+XOBe8NBmGy/3yQgcop+YC+AtuhV18PP4a6lgehuApEhmTutVdwysEN61e6XzhMB4iQhB7U9RL8nSDcdwRwhl8c9KWdi/nWyjScXI3z70xZmcYE8/qHrdCDkTdN6vU8bEOP4DA2mdJcelZl9jCkAYwbXh+aEs4e5RBaSVGV8vFccX7nRgevaC5LimfAXHW1hKlXLvuLPEHnwtQnqyywRBCFbZCAVziQGUqIss6ulzG8KjPl8Jqfh9q2L02zYCZvGoSA+L79J8/ArjQdb/waWVesDwQ==
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=8H969qG0f7wmMlJ2C5ZF3qKLVZfX2IsqUvbvFgjHqdE=; b=Z52vkZwu6/nLltrSeM203OGA/YN1Txae1LNFPX7moaIBrlzx73Lc0PlnBFX/sqdZTrtJ8aO+f0yHV1MLySMd1pOZ/xQRp67gNiqYMGZvHAIIX0LBszA8plRIn1Gar15I4zeyQgwAwvD1saGRzc0NvIqtHUeedchW5iTQtH0IiVI=
Received: from (2603:10b6:208:e3::23) by MN2PR05MB6624.namprd05.prod.outlook.com (2603:10b6:208:d8::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.15; Tue, 23 Feb 2021 15:49:43 +0000
Received: from MN2PR05MB6623.namprd05.prod.outlook.com ([fe80::15d:9352:e16c:49ab]) by MN2PR05MB6623.namprd05.prod.outlook.com ([fe80::15d:9352:e16c:49ab%7]) with mapi id 15.20.3846.029; Tue, 23 Feb 2021 15:49:43 +0000
From: John E Drake <jdrake@juniper.net>
To: Stewart Bryant <stewart.bryant@gmail.com>
CC: "Jeffrey (Zhaohui) Zhang" <zzhang=40juniper.net@dmarc.ietf.org>, Rakesh Gandhi <rgandhi.ietf@gmail.com>, mpls <mpls@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, Kireeti Kompella <kireeti@juniper.net>, Ron Bonica <rbonica@juniper.net>, "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, "pals@ietf.org" <pals@ietf.org>
Thread-Topic: draft-zzhang-intarea-generic-delivery-functions
Thread-Index: AQHXCfc3odWLKwa6pkyIprpMMJuzvKpl2yPAgAAENwCAAAGpIA==
Date: Tue, 23 Feb 2021 15:49:43 +0000
Message-ID: <MN2PR05MB662309742EC653680936A5E2C7809@MN2PR05MB6623.namprd05.prod.outlook.com>
References: <MN2PR05MB59813CFC28F62CC076364991D4AA0@MN2PR05MB5981.namprd05.prod.outlook.com> <F30F0C17-39A6-4D43-AC94-727BC2C9EEC4@gmail.com> <MN2PR05MB59817B1DBD97C4CDEAFF6CDBD4849@MN2PR05MB5981.namprd05.prod.outlook.com> <MN2PR05MB59816A0683CD84266BDB2059D4849@MN2PR05MB5981.namprd05.prod.outlook.com> <F09BD015-3AC2-4A07-9EAE-DCD2DC00D418@gmail.com> <MN2PR05MB5981E6ECADE8A4EACF446C8ED4819@MN2PR05MB5981.namprd05.prod.outlook.com> <ACA96A88-03EF-4BF9-9BB6-24B458148175@gmail.com> <MN2PR05MB598104C61F2C0A862E0A908BD4809@MN2PR05MB5981.namprd05.prod.outlook.com> <MN2PR05MB6623C35CD4D75583F320AD9AC7809@MN2PR05MB6623.namprd05.prod.outlook.com> <60BC74A2-8D94-4011-B77C-3C4830659915@gmail.com>
In-Reply-To: <60BC74A2-8D94-4011-B77C-3C4830659915@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.6.0.76
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-02-23T15:49:42Z; 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_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=ea681413-2b8f-4fe6-a5f5-e0e21bd1a106; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: b2456738-2866-47c8-8b43-08d8d812a390
x-ms-traffictypediagnostic: MN2PR05MB6624:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR05MB662451A1C394297F65E08D08C7809@MN2PR05MB6624.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: JsPrg/rnN8CvycffxvzsnRpExA/jn7hk4rwtAK8ALGh/fsjLxc0nxmkJTVStTav1jvBbjGIqJ9jsR5hibymewx2bRWlZ5iuJtWp6rZaiQ3Ol7uHtYPoZvPTFungLxeURDjJrxj1ELch4gOuiLgeC38wZz0JqLGgsihGEjVo4q0Gb85qq0WXBn2ghOMzRmeZUQbF2A0C2voKx6Gn3XOi76KpJD37jMLxOvvZjAnu22cwoGWjmeL2Ij/O6X4fYZEcxwKnV9Og/1OckDEYSUrvWMSgMYpiTkHs12aInqnYnVgJ6JpLqbm4/yz4AWCA7MZkKgeMm17Ng1O8LKCv9fCFVFq4Gr2CjZnT8zTgq7JRkng5huX+2nM74VMqpFMfxkEa1SOaZ5B5l+RLX1wY3Y+H0qUN7GurmnZi7SlU+BQmJnaiB2VEVEHEvjLbVbzHVoa7LlIIy7/yHfCGx9tMlt/sK0HBXtgLVlCkLPh/KevrvUmBat6mTLc1PmY7kpOHlGmUB0y7EMlVG4PRU7pjiAh2im3NfVigKDVfNTMg9Pjfh/PFYabgViwK2BRpmsloBM0AbQwwgkny+xC8eRIoGh0zzgpm66FMgmS7cSTeJLLpTI6h/OeI5D65jpEXsTRCFe8M03T5nSPWjFrPoN48pbxbQyw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6623.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(396003)(366004)(39860400002)(346002)(26005)(6916009)(66556008)(478600001)(4326008)(64756008)(76116006)(66446008)(66946007)(5660300002)(8936002)(66476007)(8676002)(52536014)(54906003)(6506007)(316002)(55016002)(966005)(7696005)(30864003)(9686003)(186003)(71200400001)(53546011)(83380400001)(166002)(33656002)(2906002)(86362001)(41533002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?h/jHT9Jy72iutW4NKp7CsW1g7jrQS4v51fVElzdzzLsdeo4Vx2JBYnh7EpCC?= =?us-ascii?Q?CcTedS8eT9TWxfZI8vWpu8Y7Lc4XjVljwk8dewIxhNgD6MjQu4ypWthZinsh?= =?us-ascii?Q?Ni7txLM02uIivob87wWxKhifVJ4LJu+geNiKkNF57DV0FiYl7Uzmp9r3fXdW?= =?us-ascii?Q?eeyrXTDULwr2ciYTcIq7Rwt58HUHIWIE2WpsqAoEPoBjwlWtxr0kOM/gYqWf?= =?us-ascii?Q?wenErAZi4p1R8+xQryhOcSil4FFQTH6/Q4jZUmhaGdkVrYcUaf2lxOWwb0UV?= =?us-ascii?Q?B51oVycj28RoIskGQ4yEZnpu4Mik5hwany4+1nBAAZnVp7B9kFoxFp1S/ZMb?= =?us-ascii?Q?tq+3ebzyXmVpXZJUjbK3O2yW0Hbb8psG2s+38iXR3hBdBee/ukIWKyBNkBSs?= =?us-ascii?Q?Az82AI+1DFmqBNRw554iuxFYAQe/nalvYQb2b5LEQKkrzLnKkOOemAx59P6B?= =?us-ascii?Q?mLmZNfbO/0on41QS/VMHiv6ZSBw9HZB2A84+ZpE1OyqNTvs5wmL/H5c51R7B?= =?us-ascii?Q?9scXJ56oX30G9jP3yrh+aMZSC0KQUhXaMOKEF7u2JknGHjKvsyOE+GpSqJHm?= =?us-ascii?Q?eOdswz3G8STP6BnCTGCRLHgQRZeVSOkiTdDLnqUrBzEtz05KHJlAZBg3hKqO?= =?us-ascii?Q?EEAcjBG4e84TjMPbYWoIK0/X0eF8lQjJNwnsJ/vRpb5KDxTaes2gq/Du3Zsz?= =?us-ascii?Q?w1k5nJCOjNntKYNgSlGOOQTBQiilYWb1mrRddYtCh0bbkOFIXWgpkt5139of?= =?us-ascii?Q?aqF5v8QeEjTFPTLAGASEnwQhJIng+sWst+fKS7dwIVNgCoyu1Q3vIpZ/EaS0?= =?us-ascii?Q?2W3yfN0mdiaHgyXErvuS1QsQL3+lSjkUThGzacr+TcOJXGcuM46TvrhrdDsV?= =?us-ascii?Q?TsQIctcXWZwYTYTebWLdi9Y2DWSfZ3SD3BMmfmg+ZahOt9xY5HYXfdJw4/1k?= =?us-ascii?Q?9T2JoENtb7iGPFiKkqXRtbsGG4k/UdKd2GxMr/6rELd7aXBF3CXHXQohTJfh?= =?us-ascii?Q?m9VK6imDDeJzkwtvNqbB+9stvyv7QE1DOL82RynEo1wWCaYsqwchJaA3HyCb?= =?us-ascii?Q?WvGESXm2HUjlolfD/ta6yInb9FEmj2GcrtwKCujKynyF0y1+xEB/287ffceo?= =?us-ascii?Q?g04l1OjOLDpM1TRS+MXpZ8cNepJN2rM73IctpmXhhhdiTd0HwYjou36ltdvZ?= =?us-ascii?Q?WlskO+B8Ze1dO0Z5D58E6NQMPSc3tnky+0Dew9dQuMQ/7Wica7lJsNenKZxy?= =?us-ascii?Q?wVE5BZu/Ob2ThniVBaSn4sONlfMXtLHcs8t5BuHAoA7dlfG/lOXMpJFl1GNq?= =?us-ascii?Q?dECtFdlT5PwEu80BESIN4MTy?=
Content-Type: multipart/alternative; boundary="_000_MN2PR05MB662309742EC653680936A5E2C7809MN2PR05MB6623namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6623.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b2456738-2866-47c8-8b43-08d8d812a390
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2021 15:49:43.6975 (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: IkeyyZu0yWSBDkBN5f36I3JgzpBEgeCxKjFo0lvzaxa78xAvuggF5anI+KHV0uyoRIEEh2Qr7AYtyejKujCUQQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6624
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-02-23_08:2021-02-23, 2021-02-23 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1015 suspectscore=0 lowpriorityscore=0 spamscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 mlxscore=0 mlxlogscore=999 impostorscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102230133
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/jBFndmDqOiPo-MbTikPQM6Op2zU>
Subject: Re: [Pals] draft-zzhang-intarea-generic-delivery-functions
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Feb 2021 15:50:50 -0000

Stewart,

That would be fine too.  The reason I suggested multiple G-ACh structures was to allow each function to evolve independently but it's not a big deal.  Multiple labels, each with the BoS set, was suggested during the MPLS-TP days (Niel Harrison, in particular, was a big proponent) but was shot down because it would apparently break existing hardware implementations.

Yours Irrespectively,

John



Juniper Business Use Only
From: Stewart Bryant <stewart.bryant@gmail.com>
Sent: Tuesday, February 23, 2021 10:36 AM
To: John E Drake <jdrake@juniper.net>
Cc: Stewart Bryant <stewart.bryant@gmail.com>om>; Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org>rg>; Rakesh Gandhi <rgandhi.ietf@gmail.com>om>; mpls <mpls@ietf.org>rg>; int-area@ietf.org; Kireeti Kompella <kireeti@juniper.net>et>; Ron Bonica <rbonica@juniper.net>et>; <rtg-ads@ietf.org> <rtg-ads@ietf.org>rg>; pals@ietf.org
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

[External Email. Be cautious of content]

Having an ACH channel type per set of structures, or a BoS label value per set of structures would be far more consistent with the MPLS model.

Stewart

On 23 Feb 2021, at 15:27, John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>> wrote:

Hi,
Why wouldn't we just use GAL/G-ACh for this as it is already a published RFC that was designed for things like this?   I.e., we could use a GAL and define families of G-ACh codepoints which describe exactly what is in the area between the MPLS label stack and the payload.  E.g.,  G-Ach for IOAM:  [value #1 = hop by hop IOAM w/ no subsequent metadata, value #2 = end to end IOAM w/ no subsequent metadata, value #3 = hop by hop IOAM w/ subsequent metadata, value #4 = end to end IOAM w/ subsequent metadata].  The subsequent metadata would then have the same basic structure.
Yours Irrespectively,

John


Juniper Business Use Only
From: mpls <mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Tuesday, February 23, 2021 10:19 AM
To: Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>; Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>>
Cc: mpls <mpls@ietf.org<mailto:mpls@ietf.org>>; int-area@ietf.org<mailto:int-area@ietf.org>; Kireeti Kompella <kireeti@juniper.net<mailto:kireeti@juniper.net>>; Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>; <rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>> <rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>>; pals@ietf.org<mailto:pals@ietf.org>
Subject: Re: [mpls] draft-zzhang-intarea-generic-delivery-functions

[External Email. Be cautious of content]

Hi Stewart,

GDFH has both a "this header" (for a particular function) and a "next header". One GDFH can point to another GDFH, who could also point to another header (e.g. MPLS).

IOAM could be integrated into GDF. I understand that this is just a thought and we have not concluded on that yet, but with that thought the headers would be like the following:

   Transport label + GDFH label (BoS) + GDFH (for IOAM) + GDFH (for other functions not already provided by PW itself) + PW label + PW payload or G-Ach

Depending on the situation, the GDFH (for IOAM) and GDFH (for other functions) could be swapped. The PW label is essentially another label stack - the earlier stack stopped at the GDFH label.

Now what if IOAM is not integrated into GDF? I see the following in its -06 revision:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | IOAM Indicator Label                  | TC  |1|  TTL          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
    |0 0 0 1|Version| Reserved      | IOAM G-ACh                    |  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
    | Reserved      | Block Number  | IOAM-OPT-Type |IOAM HDR Length|  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  I
    |                                                               |  O
    |                                                               |  A
    ~                 IOAM Option and Data Space                    ~  M
    |                                                               |  |
    |                                                               |  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
    |0 0 0 1|Version| Reserved      | Channel Type                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                                                               |
    ~                 Payload + Padding                             ~
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 5: Example MPLS Encapsulation with Another G-ACh with IOAM

I am not sure if that is a good idea:


  *   RFC 5586 says "The G-ACh MUST NOT be used to transport user traffic". To me IOAM traffic is user traffic with OAM information.
  *   It puts one G-Ach header after another G-Ach header. As far as I understand it, G-Ach does not have a "next header" concept and using 0001b to indicate that another G-Ach header follows is not safe.
  *   In case PW payload, the above will put the PW label before the IOAM label. Having those extra IOAM/G-Ach headers between the PW+IOAM label and PW payload adds complexity to the fast path processing.

Jeffrey

From: Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>
Sent: Monday, February 22, 2021 7:30 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Cc: Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>; int-area@ietf.org<mailto:int-area@ietf.org>; mpls <mpls@ietf.org<mailto:mpls@ietf.org>>; pals@ietf.org<mailto:pals@ietf.org>; Kireeti Kompella <kireeti@juniper.net<mailto:kireeti@juniper.net>>; Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>; <rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>> <rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

[External Email. Be cautious of content]

What happens if an operator wants to run both iOAM and GDFH at the same time and the packet is a PW packet?

What does the packet look like and how does the forwarder know what to do?

- Stewart

On 22 Feb 2021, at 22:49, Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> wrote:

Hi Stewart,

This thread started with your comment "Please see the note that I sent about iOAM who also want to sit after BoS ... and both of you want the same space that PALS and DetNet is already using", but now it seems that we're on the same page - GDFH starting with 0000b is fine and is not competing with IOAM or PW/DETNET CW?

Thanks.
Jeffrey

From: Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>
Sent: Monday, February 22, 2021 5:15 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Cc: Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>; int-area@ietf.org<mailto:int-area@ietf.org>; mpls <mpls@ietf.org<mailto:mpls@ietf.org>>; pals@ietf.org<mailto:pals@ietf.org>; Kireeti Kompella <kireeti@juniper.net<mailto:kireeti@juniper.net>>; Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>; <rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>> <rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

[External Email. Be cautious of content]

The DetNet CW is described in RFC8964 and is





      0                   1                   2                   3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |0 0 0 0|                Sequence Number                        |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                       Figure 5: DetNet Control Word



In all defined control words



The 0000 is simply ECMP defeat and has no other purpose.



0001 means ACH



An ACH is currently defined not to carry service/user data - it is a control/OAM channel.



You cannot assume anything about a payload starting 0000.



In MPLS the bottom label (alone) defines how you process the payload. So you know that you have a CW from the bottom label and by no other means.



In other words the the FEC of the bottom label and its associated parameters are the way that signalling protocol knows what instructions to give the forwarder, and the way that the forwarder knows what to do with the packet is from the instructions associated with the BoS label. This is the universal model for MPLS including for IP packets.



Stewart



On 19 Feb 2021, at 15:42, Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> wrote:

Hi Stewart,

I still have to read more about DetNet, but I am not sure if there is a real contention with PALS.

My understanding of 0000 nibble in PW control world is that it is only to prevent a transit node from mistaking the payload as IP. Is it supposed to indicate that any payload starting with 0000 is PW payload? I hope not.

Use of 0000 nibble in GDFH is also just to prevent transit nodes from mistaking it as IP. It does indicate it is GDFH. It should be able to co-exist with PW CW.

Thanks.
Jeffrey

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, February 18, 2021 10:35 PM
To: Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>
Cc: int-area@ietf.org<mailto:int-area@ietf.org>; mpls <mpls@ietf.org<mailto:mpls@ietf.org>>; pals@ietf.org<mailto:pals@ietf.org>; Kireeti Kompella <kireeti@juniper.net<mailto:kireeti@juniper.net>>; Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>; <rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>> <rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>>
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Stewart, all,

I apologize for not responding to this in time. I some how accidentally moved a few wg mailing list email folders to a place where I could not see so I missed all the discussions.
Let me catch up all the emails and then reply.

Thanks.
Jeffrey

-----Original Message-----
From: Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>
Sent: Tuesday, January 12, 2021 9:59 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Cc: Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>; int-area@ietf.org<mailto:int-area@ietf.org>; mpls <mpls@ietf.org<mailto:mpls@ietf.org>>; pals@ietf.org<mailto:pals@ietf.org>; Kireeti Kompella <kireeti@juniper.net<mailto:kireeti@juniper.net>>; Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>; <rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>> <rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

[External Email. Be cautious of content]


Thank you Jeffery

Please see the note that I sent about iOAM who also want to sit after BoS ... and both of you want the same space that PALS and DetNet is already using.

We plan to have a joint session on this hosted by PALS at the next IETF, but I think we also need to include the iOAM people.

This has scope to get very messy as we find new candidates for BoS metadata so we really need to take a holistic position to ensure the future health the MPLS protocol.

- Stewart


On 12 Jan 2021, at 14:27, Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> wrote:

Hi,

I just posted https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiItOdNuXbu_RIMekK2pkpOj4Mmj7b9MseV-Y$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiItOdNuXbu_RIMekK2pkpOj4Mmj7b9MseV-Y$> .

The initial version was posted to the tsvwg (https://urldefense.com/v3/__https://tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiItOdNuXbu_RIMekK2pkpOj4Mmj7b5lS_Jea$<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiItOdNuXbu_RIMekK2pkpOj4Mmj7b5lS_Jea$> ). After discussions/feedback we are re-homing it to intarea wg. This new version also contains quite some changes based on the comments and feedback that we received (special thanks to Stewart).

Comments and suggestions are appreciated.

Thanks.
Jeffrey

Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only

Juniper Business Use Only