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

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Tue, 23 February 2021 16:32 UTC

Return-Path: <zzhang@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 E935E3A003D; Tue, 23 Feb 2021 08:32:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.566
X-Spam-Level:
X-Spam-Status: No, score=-2.566 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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=juniper.net header.b=MPAXOCzh; dkim=pass (1024-bit key) header.d=juniper.net header.b=W2iimu7q
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 snYFIv4GPh8I; Tue, 23 Feb 2021 08:32:07 -0800 (PST)
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 4599D3A003F; Tue, 23 Feb 2021 08:32:07 -0800 (PST)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 11NFOdMI030447; Tue, 23 Feb 2021 07:32:59 -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=ahK+/F27cWmyM8K10SadwgHxREKnqYvPQQxA79P0WBs=; b=MPAXOCzhEgcatgjmmn7mzaN52UyL36vvgMKQD+J9DJf7LCndQ1tzMzJC1bZA//SoBQOi Z2ukXZUY5gNuWnIXSbomAifRoPHCo+jy3IN4Qr88Dt8Vynzm2ldXNSbjKb20vY/eocf5 v6oDUoc5CF+hfHnm4MNVtm23KAf3THU+KZ+aa+pCARXzKDzx/dEjLAcHoT0nWgMNea/i r6vf0YEQ1L1b2gEhl6K1JYXGpAJUcfwJu5Z8dV2Y1/soKWNcuORwSP63JcMSsuFE7vgX 5kwgsTvFALEv/lb2uvbhJ+TuqvZEWw+BYz9yHged5p9nYqqQPeC8DhxvjJ8cbO8QimYk VQ==
Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2172.outbound.protection.outlook.com [104.47.58.172]) by mx0b-00273201.pphosted.com with ESMTP id 36u17pe2mf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Feb 2021 07:32:59 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GtPXEIUShLSn2c/3X6zX89zDVvSSjHLqqoiLVZ65uw8r0950R8PvDyDXc5gL/q/YIv9X8Dk9NjhO3HPeHfJFzKg5RMqqzFx41d/rQiUX3SswlfOui6ZHCNx5r0FrDcWL6VDHAilUQjbjtzJCU0C8q/IfWKXtUX+c1VduTUo7Ztw6k/KUXkDTBd4ooPZoq3vT6CJmnCurYMHWuH675iOmmoHDAi27Qm5iejgTBp6Zw6p4rqnM4kEwUoJBtJ0wrnmERIxgAXVe8OOR4d24sfFcHoSLOIzyq8gR6m1T10//vyzbrQXXJdAkCzYICWHMYLC73DkIBV9qRuLfjGKWLGCRAg==
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=ahK+/F27cWmyM8K10SadwgHxREKnqYvPQQxA79P0WBs=; b=hQIYNKoohVw6REmdB7Axf3iHE+ddUovA7CEU3j3veQ9K7gqykJmQr0f8hWZFQywAPiguGpXyxzIyBv8HyRSNCakgyGsyG1e/gzYstLrseJ+4M6zzLN2F1chj7qXsCv8bDv3qmYjsoz5ernigrxFwGBqUFMEHdNkklSY5pMgD1Gvj/0FLqbz2Ye6m8HxgDhConvNG9SPejgvMjmIKLbElBBZfGXIjMEkx25MhmzeXjIGgrYV6hfgpo0gtbT90hOgeftDJISG4kriduEsMp7hxDOqYszAI9oXL3UMXDThXbi7huJsLfljOYcyFT91nrQvtbpAxBXTdH6oI4Jzem8T5AQ==
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=ahK+/F27cWmyM8K10SadwgHxREKnqYvPQQxA79P0WBs=; b=W2iimu7qqzkHs2maBHwFfi1f/Uyf5XaYOKLOpMBxdMpYitDtgYcdtDRoha77hOdi4FpkYgs3560WurVW1jhQ7Awnk5B6go+qIXn9p1PpmycsyTP3dIia5Y8c/hZ874Wc6UvrY2eX3NJHSqh+zBpyW2NEvb9zq0NnDVpz3uqWIpw=
Received: from MN2PR05MB5981.namprd05.prod.outlook.com (2603:10b6:208:c3::15) by MN2PR05MB6589.namprd05.prod.outlook.com (2603:10b6:208:e4::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.11; Tue, 23 Feb 2021 15:32:57 +0000
Received: from MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::e4b1:7d19:5f39:595b]) by MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::e4b1:7d19:5f39:595b%6]) with mapi id 15.20.3890.016; Tue, 23 Feb 2021 15:32:56 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: Stewart Bryant <stewart.bryant@gmail.com>, Rakesh Gandhi <rgandhi.ietf@gmail.com>, "Yangfan (IP Standard" <shirley.yangfan@huawei.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: [mpls] draft-zzhang-intarea-generic-delivery-functions
Thread-Index: Adbo7ZVM2l5i/x7jTG2A02P2JCK+DQABem8AAWyLcIAF6r4cgAAg0n9AAIy/k4AAGH8KsAAFlxOAAB4K6EA=
Date: Tue, 23 Feb 2021 15:32:56 +0000
Message-ID: <MN2PR05MB5981C0BD8418DBD016FF2ABED4809@MN2PR05MB5981.namprd05.prod.outlook.com>
References: <MN2PR05MB59813CFC28F62CC076364991D4AA0@MN2PR05MB5981.namprd05.prod.outlook.com> <F30F0C17-39A6-4D43-AC94-727BC2C9EEC4@gmail.com> <CAMZsk6fqgTXFys7fL-1aZpT-V1j_1MoZhwHyOxKEkFWJN2TJyw@mail.gmail.com> <CAMZsk6dPOUDNrGafkOVRgH02K4LWtxU_sCa7f60OZzLwn5Y2wQ@mail.gmail.com> <MN2PR05MB598178C9CAA547D000376178D4849@MN2PR05MB5981.namprd05.prod.outlook.com> <303C7C83-6AE7-41FC-98A6-EE87DA2AFDFE@gmail.com> <MN2PR05MB5981B0D2443568DEEF2D8206D4819@MN2PR05MB5981.namprd05.prod.outlook.com> <CA+RyBmVAVwNC+WY0Zx1uWf0Zw++GMi8nZGKJ_iJaksKDEjaVqg@mail.gmail.com>
In-Reply-To: <CA+RyBmVAVwNC+WY0Zx1uWf0Zw++GMi8nZGKJ_iJaksKDEjaVqg@mail.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.5.0.60
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=f3155001-43c5-4599-bc5a-e295a324bc28; 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-02-23T15:20:40Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
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: [71.248.165.31]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ff65e2fa-452f-4342-14c4-08d8d8104b71
x-ms-traffictypediagnostic: MN2PR05MB6589:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR05MB6589827CB48FE5E212C6A637D4809@MN2PR05MB6589.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: DrphzrFNbJMy7O9LoiuyESddU9E9lT8QW4wzcMXRVym+M6fuowCU42ffFgYVY9uDa+ayVa2gtA9OeuFojLMCT0cxCz5lemwXJR9QcHnjsHtz3HjllYeumB1caYnOXuJHXkuAYNzrwxOzUulWWZU2RQwYBW0KE/EmrNNQ9wMLN2pXB/19sB8AthY+V20Ak+s5kLF1gMNIgEyy1STA5rMfRYfxY7eZRpgjY99dWrJMnGb5upQzJm92O3cqBE+jy8vmkjDHV3GUorZqqin9LXWPUdjhdDxe3N/hL13fYDgGJFFOFJ4WyGf2Tttxtxf7q8K+xrZXH5rkmyhGaEW2sv55gHHs75yzALeWLgRKFG/XiRdDkdWW+2KL0Lj0Mx9owLgr5hr0uKChPoY6tMnJWHk2bwp2JlpH5CUxTl8lgVQuTJMVYTG82RfJKh7SkmBQVAMeWMvc112soXHl16cOyBiPWAY7LNXpFoYHmU19iS90KufKEpWsjXslPtOF/E2H4eoEgxNVu0uNyc84a2GZkW8YNe2x42K/Eir/dFQHLWwersMvmC9D58CpaOeR1RAo4sG5+deh0qSCCX6eqU5BhmApnb0gjQZJ/YWAOdRAar1PngNVvvznjo0SwY6/YPu4OOZayViZidxHBMTC0RXe/652Ng==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB5981.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(136003)(346002)(376002)(39860400002)(9326002)(8936002)(4326008)(26005)(86362001)(83380400001)(33656002)(8676002)(9686003)(66946007)(166002)(5660300002)(55016002)(186003)(6916009)(2906002)(6506007)(64756008)(66446008)(76116006)(316002)(52536014)(71200400001)(966005)(478600001)(7696005)(66556008)(53546011)(66476007)(54906003)(41533002)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: Hq7+H3GO9lpLXpsJMyUFJkuC/W5poGenzrLOtQ1ced+oflPgPZIeDT+EVCZqBBH1jzXgCTSTYgH7hzc14TAuESGv+eOGSuAyW5LLesHT78ROGJf+v26EERHhUc/JL/FYG08gy4Rc4IRka4g2ZkUk+8LaEnTIHWJDtYtp2h99UzAN96eV/KzL23SgUHqw2UHvSrEpeOJ/gIk7RVPi9K0+II2/Tk5AWu+tqRleGJ6ppm6OcamukTT+6q844S+RiiX8TFgCW2tMJkKomf68YLWwOTSE/EcVLXGDdY7Ftogvol0BbqMLo/Ay8Fn3c8fjm7gAwNGOQlSEuA2Y8Z1uXE76B/G+aj3LClN3aYPXL7L/vQB0Gak0hdYw4LFoombuLpAA3ar87TEbM8ZQ3pP1YRBsyyRnEjTuveAxi3+ATGyzfKr2uTiUieDQAmuaDvGSlku3ydiu/YyVD4DgrqV9VWmEAm9E6BT61itMkHAk99xMNeTQyvCYTarp8jZJO/5ZFD/NIq6OZNDR6Y4IhIvTJAYirgwecqkTujuLylpqdYJjhsf/yR3h4dVfNvkRb1m0MeEKBvsoW18lX+TpfvNW1C4GYtfHqwFmHU+JUccXBOTrK1H8fd2FFVoqcraFjtiG7T5+sGa/CWkeyu/H5jgvswsafrG7sIDkRFlJ7M2CKhBgbBp2Kw6Gsk1ir4xJiNo8t71tUIIFbtUpfNuieGxASrX5qbmPJqY1ahFKp+s6G7UgRPMRTVf8aEXzRyUK+28cwfftQ0gx1XbfOj3sGiGxeGh8lHZTjlzZb5k78/kiWXhRN9IXr3paCVXBypF4V+Bsf7N+u2AqTykLS7VtrYRmTb6ctzY8DX7Rg7ouqm78A9UQtPf2jjZNkAhweqz96f4cNjI5h//ghY6oLxx0KW0MRsFOcAOkCTuYYx7IGkRk19kYaUmJV+eRjsJLvtRLstb++iy10J+99Hj8O5xmr7gzNF1IfwcBkIk+jjENJ981eJ/+UA0aUsKt0sZKFVZjs91tXWm1DqeU9e970NYLwqsbT1Ce2qHwXuE4iKAszClHR9EoD0IqXKjTEFBQizIfLoce90RZSDXZEytLWJb5Tg3WqndpHdKZPJlryCvWO1LbdzjfjyWSrF4MTq4gDCqynGmaFLLN8fuNdEDx0REBqsz6oBXJKud8lO38JPWgJVJn18UWq0cSCZghAvb+M67SsbR7Peo0xt245t0MhDYDEEvbVkVEZR9seStOrJxyVOU/6kFue6GHXxJykE5xmvkyi8v7U4P12HIMNtTn3E5jSXM1HF74ESvLkjD6tqRRpGJWNWQ1g4eEko6l7utOsVzEzGqIKzkv
Content-Type: multipart/alternative; boundary="_000_MN2PR05MB5981C0BD8418DBD016FF2ABED4809MN2PR05MB5981namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB5981.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ff65e2fa-452f-4342-14c4-08d8d8104b71
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2021 15:32:56.8734 (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: D3BM0QPpeAewRm3CgtSz8VGviWM0HtXpFed37Y+Yqu/hO8mHYE2RZBMHWYwQqeEf5tB4/m4jwrCSoLrQ/iL/xg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6589
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 priorityscore=1501 lowpriorityscore=0 phishscore=0 impostorscore=0 bulkscore=0 clxscore=1015 mlxscore=0 malwarescore=0 suspectscore=0 adultscore=0 spamscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102230131
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/raeswQvDGw8sxqDxeM55WRi3_3s>
Subject: Re: [Pals] [mpls] 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 16:32:11 -0000

Hi Greg,

It does not create a new “network layer”. Rather, it provides a function shim/layer (?) between two points at a l2/l2.5/l3/whatever layer.
Yes if some OAM function can be extracted out to be independent of a l2/l2.5/l3/whatever layer, then a GDFH “this header” code point can be registered to indicate it is for OAM purpose and corresponding header format will be determined from the ‘this header’ code point.

As you can see in other emails of this thread, I am thinking that IOAM can be implemented as a GDFH. Of course that’s subject to further discussions.

Thanks for pointing out that I have the “This Header and Header Length” swapped in Figure 2. I’ll fix that.

Thanks.
Jeffrey

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Monday, February 22, 2021 8:00 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: Stewart Bryant <stewart.bryant@gmail.com>; Rakesh Gandhi <rgandhi.ietf@gmail.com>; Yangfan (IP Standard <shirley.yangfan@huawei.com>; mpls <mpls@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
Subject: Re: [mpls] draft-zzhang-intarea-generic-delivery-functions

[External Email. Be cautious of content]

Hi Jeffrey,
I have read the draft and find it very interesting. I've got a question, perhaps we can discuss:

  *   if I understand it correctly, GDFH shim creates a new network layer. How you envision OAM at that layer can be identified? BIER uses protocol type. MPLS - GAL. IP - ICMP and, in UDP transport, well-known port numbers as the destination. Could it be assigned value from This Header registry? (Note, that This Header and Header Length appear swapped in Fig.2 compared to Fig.3 and Fig.4)
Regards,
Greg

On Mon, Feb 22, 2021 at 2:44 PM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> wrote:
Hi Stewart,

GDF is for any transportations, MPLS being of the transportations.
Here the question is, in case of MPLS, how do we do it.

I did design it to advertise a GDF label so that we know that a GDFH is at BoS; and I make the GDFH start with 0000b so that it won’t be mistaken as an IP header.

I don’t see why using 0000b in GDFH is contending with IOAM (even if it uses 0000b) and PW CW?

I was incorrectly thinking that IOAM was using GAL, so I was thinking, if IOAM (which I think it is user traffic with OAM info embedded) could use GAL, then perhaps GAL’s restriction for user-traffic could be lifted, and in that case GDF go with G-ACH using GAL.

Now I realize that I can’t really use GAL. In that case, I think it’s better to be independent of PW and G-ACH – this is not only the fragmentation function.

Thanks.
Jeffrey

From: Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>
Sent: Monday, February 22, 2021 5:39 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Cc: Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>; Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>>; Yangfan (IP Standard <shirley.yangfan@huawei.com<mailto:shirley.yangfan@huawei.com>>; Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>; 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]

The way that a forwarder processing a PW  knows that a CW follows is because it is a parameter of the FEC of the PW label that is BoS.

The CW then described whether the payload is a PW user payload of an ACH using the 0001

IF you want to run OAM on an MPLS LSP as we do in MPLS-TP you have no CW so you need another method of indicating the presence of the ACH and the way that is done is with a GAL.

The cleanest way to put fragmentation information at the BoS is to create a new type MPLS payload construct the “fragwire” if you like push the metadata, push a label advertised by the recipient that says that this is what is being done, then just the delivery label.

You have to know that the target can do this, so the target can advertise or otherwise provide a label saying what it needs as an indicator.

Job done and it is a private matter between sender and receiver.

This is just reusing what is already in place today.

Indeed if you make this a PW type, you only need a very short draft and it is all done.

- Stewart


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

Hi Rakesh, Yangfan,

I agree that a GDFH can follow the IOAM header and the two do not contend.

It came to me though, the IOAM header could become a GDFH 😊 It can then be used for all transportations (MPLS, BIER, or even ethernet).

I see that in your -06 version you treat IOAM as  a G-ACH channel. That does not seem to go well with the following in RFC 5586:

   The G-ACh MUST NOT be used to transport user traffic.

However I am not against relaxing the above restriction a bit.
But I don’t understand why you need an “IOAM Indicator Label” – there is already a special label G-ACh Label (GAL).
For GDFH, I had designed to advertise regular labels to indicate that a GDFH follows (I am always a good citizen when it comes to requesting special labels). Seeing that G-Ach uses the GAL, and the following:


   The ACH used by CC Type 1 is depicted in figure below:



    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 1|Version|   Reserved    |         Channel Type          |

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



                    Figure 1: Associated Channel Header

If the user traffic restriction could be lifted, it’s tempting to treat GDFH as a G-Ach channel type. That way we don’t need to advertise GDFH labels.

To answer Yangfan’s question “what is the difference compared to G-AC” in another email: GDFH is for generic delivery function over different transports, and even when it is used over MPLS it is different from the (original intention of) G-ACH. However, as mentioned above, it’s tempting to treat GDFH as a channel type just to be able use the already assigned GAL.

Thanks.
Jeffrey

From: Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>>
Sent: Thursday, February 18, 2021 6:49 PM
To: Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>
Cc: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; 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,
Hi Xiao, Loa,
FYI:
I believe the latest revision (06) addresses this comment. Welcome your feedback on that.
https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-ioam-sr-06<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-gandhi-mpls-ioam-sr-06__;!!NEt6yMaO-gk!VXglGy7lcO2Pe-wXQDgZaYzzz0Ckq57ZSdkkJ0Sz5yTrNvCrxSb9ClooNfsG5fW-$>

Thanks for your review.
Regards,
Rakesh

On Tue, Jan 19, 2021 at 3:57 PM Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>> wrote:
Hi Stewart,
Thanks for your comments. If we have a mechanism like following, does that address the issue?

  1.  IOAM header is part of the MPLS encapsulation, any other control word is added after the IOAM header in the data packet.
  2.  The transit nodes can process the IOAM data field(s) after the EOS in data packets as it is proposed.
  3.  The decapsulating node removes the MPLS encapsulation including the IOAM header and then processes the other control word following it.
   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 0| Rsved | This Header   | Header Length | Next Header   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~              Variable field per “This header”                 ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   ~                 Payload Packet                                ~
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thanks,
Rakesh



On Tue, Jan 12, 2021 at 10:00 AM Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>> wrote:
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://datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/__;!!NEt6yMaO-gk!VXglGy7lcO2Pe-wXQDgZaYzzz0Ckq57ZSdkkJ0Sz5yTrNvCrxSb9ClooNQ3VcEYN$>.
>
> The initial version was posted to the tsvwg (https://tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00__;!!NEt6yMaO-gk!VXglGy7lcO2Pe-wXQDgZaYzzz0Ckq57ZSdkkJ0Sz5yTrNvCrxSb9ClooNdw0REUd$>). 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

_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!VXglGy7lcO2Pe-wXQDgZaYzzz0Ckq57ZSdkkJ0Sz5yTrNvCrxSb9ClooNd2pzrpq$>

Juniper Business Use Only



Juniper Business Use Only


Juniper Business Use Only